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.
| Phase | Substance | Tools |
|---|---|---|
| Inform | Visualize who / what / how much | AWS Cost Explorer, GCP Billing Reports, Azure Cost Management |
| Optimize | Delete unused, right-size, apply discounts | AWS Compute Optimizer, Trusted Advisor |
| Operate | Governance, budget caps, continuous improvement organization | AWS 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.
| Model | Substance | Discount |
|---|---|---|
| On-demand | Pay as you use | Baseline (list price) |
| Reserved Instances (RI) | 1-3 year commit | Up to 70% off |
| Savings Plans | Usage commit (AWS) | Up to 70% off |
| Spot / Preemptible | Interruptible / spare capacity | Up to 90% off |
| Committed Use Discounts | Long-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 tag | Examples |
|---|---|
| Environment | prod / staging / dev |
| Project | project-alpha |
| Owner | team-a / foo@example.com |
| CostCenter | Department code |
| Service | web / 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.
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.
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.
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.
- Tag convention and visualization first — without sight, nothing improves.
- Pick pricing models at design time — retroactive fixes are huge cost.
- Management level matched to scale — dedicated FinOps for MVP is excess; mandatory at scale.
- AI usage cost as the new central axis — LLM 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 move | Why it is bad → what to do instead |
|---|---|
| Deciding the tagging convention after the resources exist | retrofitting never finishes and unattributed cost passes half the total → decide the convention early in design |
| Running development environments 24 hours a day | development 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 monitoring | unused purchases reach expiry and the loss is locked in → monitor utilisation before adding more |
| Emitting DEBUG logs in production | there 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 invoice | noticing after a full month of loss is too late → configure cost anomaly detection |
| Offering an LLM API with no per-user cap | a 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.
Related Articles
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.
Also popular with readers
📚 Series: Architecture Crash Course for the Generative-AI Era (22/95)