System Architecture

Cloud Cost Management (FinOps)

Cloud Cost Management (FinOps)

About this article

This article is the System Architecture category’s final installment (11th) in the Architecture Crash Course for the Generative-AI Era series, covering cost management (FinOps) in cloud.

Cloud’s pay-as-you-go can be $1k or $100k a month depending on one decision. The article covers what makes bills balloon, the three phases of FinOps (continuous optimization of cloud-cost operation), pricing models, tag strategy, management levels by scale, and the LLM-era new cost lenses.

Before you read this

This article uses a good deal of infrastructure vocabulary — servers, networks and so on. If that is unfamiliar, reading the primers "Servers and the Cloud" and "How a Web Service Works" first makes it far easier to follow. You can also look anything up in the glossary as you read.

What is FinOps (cost management) in the first place

FinOps is, roughly speaking, “the ongoing activity of visualizing cloud usage costs and eliminating waste.”

Imagine your water bill. Leave a faucet running and the bill balloons; fail to shut off water to rooms nobody uses and it keeps flowing needlessly. Cloud is pay-as-you-go too, so instances left running, excessive logging, and abandoned resources routinely produce bills 3-10x the estimate. FinOps isn’t mere cost-cutting — it’s investment optimization with the framing “pay where it matters, cut waste.”

Why cost is considered at design time

First, because billing accidents of three to ten times the estimate are common. Egress, NAT gateways and per-call APIs all bill in ways that are easy to miss until the invoice arrives. The causes repeat with surprising consistency: development environments nobody stopped (billed around the clock, weekends included), logs emitted in volume (CloudWatch Logs charges exceeding the production running cost), traffic routed through a NAT gateway, database specifications sized “large, just in case”, old objects left sitting in S3, and the most easily missed of all — egress, the traffic leaving the cloud. Every one of them shares the same postscript: “we could have seen this at design time.” Second, because fixing it retroactively is expensive. Tagging conventions, account separation and instance choices are all far cheaper to set at the start than to retrofit. Rebuilding an architecture for cost is close to a one-way door; the choice between serverless and containers alone can differ by more than a factor of two depending on the request pattern. Third, because design and spending authority have to be paired. An engineer who can create resources but has no view of what they cost cannot make a cost-aware decision. Cost is a management approval domain: unless you agree the “governance of spending” at design time — up to $1k a month on the team’s judgement, $10k with management approval — engineering and management will argue at month end when the invoice lands.

The three phases of FinOps

FinOps spins through “Inform (visualize) -> Optimize -> Operate (operationalize).” Many companies skip even “visualize” and jump to savings tactics that don’t stick.

Three-Stage FinOps Cycle Run in order: Inform (Visualize) → Optimize → Operate Like water bills. Leaving the tap on = leaving cloud resources running Step 1 Inform Visualization Who is spending how much on what — make it visible AWS Cost Explorer GCP Billing Reports Azure Cost Management What you can't see, you can't improve Step 2 Optimize Optimization Delete unnecessary resources Optimize sizing, leverage discounts Compute Optimizer Trusted Advisor RI / Savings Plans Cut waste, focus on what's needed Step 3 Operate Operationalization Governance & budget caps Organize continuous improvement AWS Budgets Tag convention operations Weekly cost reviews Keep running through systems Run the cycle continuously Common Failure Skipping visualization, jumping to savings → Unknown effect, becomes hollow Correct Order Visualize → Optimize → Operationalize. Without Operate, it's a one-time effort
PhaseSubstanceTools
InformVisualize who / what / how muchAWS Cost Explorer, GCP Billing Reports, Azure Cost Management
OptimizeDelete unused, right-size, apply discountsAWS Compute Optimizer, Trusted Advisor
OperateGovernance, budget caps, continuous improvement organizationAWS Budgets, tag conventions, weekly reviews

Without going “visualize -> optimize -> operationalize” in order, short-term savings don’t stick and revert. Skipping the Operate phase (the org-level mechanism for keeping it going) leaves it as a one-time event.

The main pricing models

Cloud’s base pricing is pay-as-you-go, but long-term commitments offer significant discounts. Understanding models is mandatory because choices can halve the bill.

ModelSubstanceDiscount
On-demandPay as you useBaseline (list price)
Reserved Instances (RI)1-3 year commitUp to 70% off
Savings PlansUsage commit (AWS)Up to 70% off
Spot / PreemptibleInterruptible / spare capacityUp to 90% off
Committed Use DiscountsLong-term discount (GCP)Up to 57% off

Reserved for steady-load production, Savings Plans for variable load, Spot for batch — the standard pattern. RI is loss if unused, so coverage and utilization monitoring is part of operations.

The basis of visibility — a tagging strategy

The premise for cost visualization is “a tagging convention covering all resources.” Untagged resources show up as “unknown cost” on the invoice; nobody knows who used them or why.

Required tagExamples
Environmentprod / staging / dev
Projectproject-alpha
Ownerteam-a / foo@example.com
CostCenterDepartment code
Serviceweb / api / batch

“A mechanism to enforce tagging” (auto-stop untagged resources, etc.) combined with IaC is the modern standard. “Tag it later” never happens.

Decide the tag convention at the start of design. Bolting on after launch is hell.

How to choose — three scenarios by scale

If you are building solo or at a startup — budget alerts and zero fixed cost

Set a budget alert on day one and keep the fixed cost at zero: serverless and free tiers, with nothing running that does not need to. The single largest risk at this size is an unbounded API — put a per-user cap on anything that bills per call.

Personal / Startup: Ship in One Month Is Correcten.senkohome.com/arch-intro-case-startup/

If you are a small or mid-size SaaS — weekly review and automatic shutdown

Decide the tagging convention early, review cost weekly, and force development environments to stop at night and at weekends. Configure cost anomaly detection so you learn about a problem within a day rather than from the month-end invoice.

Small-Mid SaaS - Lean on Managed and Run with Few Peopleen.senkohome.com/arch-intro-case-saas/

If you are a large enterprise — a dedicated FinOps function and automated optimisation

A dedicated FinOps function, reserved instances bought against monitored coverage, and automated optimisation recommendations. At this scale the difference between a tagged and an untagged estate is the difference between managing cost and guessing at it.

Large-Enterprise Core: Design That Holds Up for Yearsen.senkohome.com/arch-intro-case-enterprise/

AI decision axes — LLM cost becomes the core of the new FinOps

With AI-driven development and AI utilization as the assumption, cost management moves from “humans optimize” to “AI suggests and auto-applies continuously.” AWS Cost Anomaly Detection and Compute Optimizer are already AI-based, and “anomaly detect -> root cause -> recommend -> auto-apply” is becoming standard.

Meanwhile, AI’s own usage cost becomes a new management target. LLM APIs scale to tens of thousands of dollars monthly fast; prompt caching, model selection, and per-user upper bounds are the new pillars of FinOps.

  1. Tag convention and visualization first — without sight, nothing improves.
  2. Pick pricing models at design time — retroactive fixes are huge cost.
  3. Management level matched to scale — dedicated FinOps for MVP is excess; mandatory at scale.
  4. AI usage cost as the new central axisLLM and AI-agent spending become the focus.

LLM API cost management is the new core of FinOps

As of 2026, LLM API usage costs are ballooning to match or exceed infrastructure costs. Claude/GPT-4 class models cost several to 15 dollars per million input tokens, with output at 3-5x that rate. Per-user-request cost reaches a few cents, so cost projections under traffic growth follow different math than traditional compute billing.

Three effective countermeasures: prompt caching (reusing responses for identical inputs), model routing (Haiku/small models for simple tasks, Opus/large models for complex tasks), and per-user usage caps.

AI-driven auto-recommendation for cost optimization

AWS Cost Anomaly Detection, Compute Optimizer, and Trusted Advisor already provide AI-based recommendations like “this EC2 instance has been below 5% CPU for 30 days — downsize it.”

With IaC-managed infrastructure, generating these recommendations as Terraform change PRs is also buildable. An operational flow where AI handles “anomaly detection -> root cause -> fix PR generation -> human approval” end-to-end is becoming standard.

Pitfalls and forbidden moves

Here are the six most dangerous ways a cloud bill explodes.

Forbidden moveWhy it is bad → what to do instead
Deciding the tagging convention after the resources existretrofitting never finishes and unattributed cost passes half the total → decide the convention early in design
Running development environments 24 hours a daydevelopment and staging together exceeding production is a frequent phenomenon → force a stop at night and at weekends with tags and a script
Buying reserved instances in bulk with no coverage monitoringunused purchases reach expiry and the loss is locked in → monitor utilisation before adding more
Emitting DEBUG logs in productionthere are many cases of a five-figure monthly logging bill → INFO and above, with shorter retention
Learning about a cost anomaly from the month-end invoicenoticing after a full month of loss is too late → configure cost anomaly detection
Offering an LLM API with no per-user capa prompt loop reaching a five-figure monthly bill overnight has happened → per-user caps and rate limiting are mandatory

Author’s note — the invoice that spanned the new-year break

A team rushing through year-end release work spun up GPU instances for verification, planned to “stop them later,” and went into the new-year break. On the first day back, the cost dashboard showed the monthly bill at over 10x normal, with the culprits being those forgotten GPU instances.

Personal-developer episodes exist: a verification r5.2xlarge left running over the weekend melted hundreds of dollars. Hundreds is funny; tens of thousands on GPUs isn’t.

The lesson: “‘Stop it later’ depends on human will, and almost always breaks down.” Embed mandatory auto-stop scripts at night/weekends with tags from day one. Defend cost with design, not willpower.

Don’t scold forgotten stops. Tilt the system to stop on its own.

What to decide — what is your project’s answer?

Articulate your project’s answer in 1-2 sentences for each:

  • Tag convention (Environment / Project / Owner / CostCenter)
  • Budget caps and alerts (monthly / weekly)
  • Pricing-model selection (on-demand / RI / Savings Plans)
  • Dev-environment auto-stop policy
  • Log retention and data-deletion policy
  • Cost-review cadence (weekly / monthly)
  • LLM / AI-service usage caps

Write your answers down as an ADR. A concrete guide to writing them is here.

[DevOps Architecture] Documentationen.senkohome.com/arch-intro-devops-docs/

Summary

This article covered cloud cost management (FinOps) — the patterns of bill explosion, 3-phase operation, tag strategy, management levels by scale, LLM-era topics.

Set the tag convention first, fold pricing models into design at design time, operationalize by scale. In this order, you avoid the “open the invoice and turn pale” incident.

This concludes the System Architecture category’s 11 articles. The next article opens the Software Architecture category — monolith vs microservices, language selection, API design, and other selection axes for software’s internal structure.

Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book

I hope you’ll read the next article as well.

📚 Series: Architecture Crash Course for the Generative-AI Era (22/95)