The question this answers
What does this architecture cost to run, and which line item is the one nobody predicted?
The platform has to serve its users within a budget the business agreed before the architecture existed. Design decisions made in a review — a second region, a NAT per zone, debug-level logging, a cache in front of a cheap query — each commit money for as long as the system runs, and the engineers making them usually cannot see the number they are committing.
A model of which components drive spend and in what shape, so an architecture decision can be argued with its cost attached rather than discovered at the end of the quarter.
Ten drivers, and the three that surprise people
Infrastructure bills are made of a small number of meters. Learning the *shape* of each one — does it charge for existing, for use, or for spikes — is more durable than learning any price, because prices change every year and shapes do not. The panel below is the full driver list with relative weights for a mid-sized web platform. Treat the weights as a teaching illustration, never as a forecast for your system: an image-heavy media product and a batch analytics pipeline have completely different profiles.
Three items are marked as surprises, and they earn it. Data transfer surprises because moving bytes frequently costs more than storing them, and because nothing about the architecture diagram suggests that the arrow between two boxes has a meter on it — see Egress: Moving Data Costs Money, Not Just Storing It. NAT and load balancer charges surprise because they are infrastructure plumbing that nobody thinks of as a product; a per-zone NAT with a per-gigabyte processing charge quietly taxes every image pull and every log shipment. Observability surprises because it scales with traffic *and* with verbosity, so a debug flag left on in production can move it more than a traffic doubling would.
Idle capacity is on the list deliberately, and it is the largest single item in most real bills. Provisioned-but-unused compute is paid for at the same rate as compute doing work. That does not make it waste — some of it is the reliability budget that keeps a traffic spike from becoming an outage — but it does make it the first place to look, and Idle Capacity: Headroom or Waste? is where the headroom-versus-waste distinction gets made properly.
Bars are relative weights, not currency. Real rates depend on provider, region, commitment and volume.
Every architecture decision has a meter attached
The practical technique is to make the cost visible at the moment the decision is made, in the review, next to the availability and latency arguments. Not a price — you cannot know the price, and the guide is explicit that no figure here is a fact — but the *driver* and the *shape*. "We are adding a NAT per zone" becomes "we are adding three fixed hourly charges plus a per-gigabyte meter on all outbound traffic, in exchange for egress surviving a zone failure". That is a sentence a team can actually weigh.
The matrix maps common decisions to what they turn on. The pattern that emerges is worth naming: decisions that add *redundancy* multiply fixed costs, decisions that add *hops* add usage-shaped costs, and decisions that add *observability* add spiky costs that peak when you are already having a bad day. A design that adds all three at once — multi-region, service mesh, full-fidelity tracing — has tripled its cost surface before it serves a single extra user.
The second thing to establish is who sees the number. Cost data that only reaches finance produces a quarterly conversation about discounts. Cost data that reaches the engineers who created the line item produces architecture changes, which is where the real savings are. That requires attribution, which requires tagging, which is Cost per Service and the Attribution Problem.
| Decision | Meter it turns on | Shape | The honest counterweight |
|---|---|---|---|
| Add a second availability zone | Duplicate compute, a second NAT, cross-zone transfer | Fixed + usage | This is what surviving a zone failure costs — see Multi-Zone Deployment |
| Add a second region | Duplicate everything, plus continuous replication traffic | Fixed + usage | Often 1.8–2.2× the single-region bill for a requirement few products actually have |
| Split a monolith into services | Cross-zone traffic between services, more load balancers, more log streams | Usage | Network chatter that used to be a function call now has a meter on it |
| Add a managed cache | Node-hours, always on | Fixed | Worth it if it removes database load; pure cost if the query was already cheap |
| Turn on debug logging in production | Log ingestion, immediately, at multiples | Spiky | The single fastest way to move an observability bill |
| Serve media from the origin instead of a CDN | Internet egress at origin rates, on every request | Usage | A CDN usually costs less per GB than the origin egress it replaces — see CDN as Infrastructure |
| Autoscale on a slow signal | Overshoot: instances that scaled out and lingered | Spiky | A scale-in cooldown that is too conservative is a permanent cost |
| Keep every backup forever | Storage growing monotonically plus retrieval when tested | Fixed | Retention is a recovery decision with a bill — see Backup Strategy |
| Run your own database instead of managed | Instance-hours and engineer-hours | Fixed | The instance is cheaper and the on-call is not — see Managed vs Self-Hosted |
The cost view over a topology
The same overlay habit that produces the Security View produces a Cost View, and it is read the same way: take the topology you already have and annotate what each node and each edge meters. The edges matter as much as the nodes here, which is the part that catches people — a diagram where two boxes talk to each other across zones is a diagram with a meter on the arrow.
The topology below flags four things on an unremarkable design. A NAT per zone that all image pulls traverse. Cross-zone traffic between the API tier and the database standby. A log pipeline shipping to an external vendor, billed twice. And a development environment identical in size to production, running twenty-four hours a day to serve a team that works eight. None of these are architectural mistakes; all of them are decisions that were made without their cost attached.
That last one deserves emphasis because it is the easiest large saving in most organizations and it requires no architectural change at all. Non-production environments that run continuously to serve people who work business hours are paying roughly three times what they need to. Scheduled shutdown is unglamorous, low-risk and frequently worth more than a quarter of right-sizing work.
Key points
- Learn the shape of each meter — fixed, usage or spiky — not the price. Shapes survive the annual pricing change; prices do not.
- The line items that surprise teams are the ones that move bytes: data transfer, NAT processing, log ingestion.
- Idle capacity is usually the single largest item, and part of it is deliberately purchased reliability rather than waste.
- Attach the driver and the shape to every architecture decision in the review, where it can still change the design.
- Redundancy multiplies fixed costs, extra hops add usage costs, and observability adds spiky costs that peak during incidents.
- Cost data that only reaches finance produces discount negotiations; cost data that reaches engineers produces architecture changes.
The loop, answered
Every field is required, which is why no lesson here can recommend something without saying what it costs and what simpler thing to consider first.
- • Every provider resource is attached to one or more meters: time-based (per hour of existence), volume-based (per GB stored, transferred or ingested), or operation-based (per request or per invocation).
- • Usage is aggregated per account or project, per region, per service and per tag, then rated against a price book that varies by region, tier and commitment.
- • Commitments and reservations apply a lower rate in exchange for a promise of minimum usage over one to three years.
- • Cost and usage data is published as a detailed dataset, typically a day or more behind, which is why anomaly alerting is a separate mechanism from the bill.
- • Attribution to a team or service is only possible where tags were applied at resource creation — untagged shared resources have to be allocated by an agreed rule instead.
- • Set a budget with alerts at a rate threshold, not only at a monthly total, so a step change is caught on day two rather than after invoicing.
- • Review the top five line items monthly and ask what changed. It is a thirty-minute meeting that regularly finds more than a week of optimization work.
- • Tag at creation time and enforce it in the IaC module, because retroactive tagging never completes.
- • Schedule non-production environments off outside working hours before doing any clever optimization.
- • Revisit commitments as the architecture changes — a three-year reservation on an instance family you migrated away from is a pure loss.
- • Give every recurring cost an owner. Unowned line items grow indefinitely.
- • A silent step change: something scaled out, or a log level changed, and the new baseline is only visible on the invoice weeks later.
- • Optimization theatre: weeks spent shaving 5% off compute while data transfer and idle capacity, together larger, go untouched.
- • Cost-driven decisions that damage reliability — removing the standby, cutting headroom to zero, deleting backups — which is Idle Capacity: Headroom or Waste? read badly.
- • Untagged shared resources that nobody claims, so the largest costs are the least attributable.
- • Commitment lock-in: reserved capacity that no longer matches the architecture, paid for regardless.
- • A runaway loop — retry storms, recursive function invocations, a misconfigured crawler — that bills in hours what was budgeted for a month.
- • Compute cost tracks traffic if scaling works and tracks provisioned capacity if it does not, which is why scale-in matters as much as scale-out.
- • Data-transfer cost grows super-linearly when a system is decomposed, because internal calls that were free become metered network hops.
- • Storage grows monotonically and never scales down by itself; only a lifecycle policy makes it decrease.
- • Observability cost grows with traffic multiplied by verbosity multiplied by cardinality, and cardinality is the term with no natural ceiling.
- • The dimension that runs out first is usually organizational: past a few teams, nobody can attribute spend without tagging discipline that was not there from the start.
- • Cost anomalies are a security signal. Cryptomining on compromised compute, data exfiltration through egress, and a leaked key being used at scale all show up as unexplained spend before they show up anywhere else.
- • Billing data reveals architecture — service names, regions, resource counts. Treat access to it as production information.
- • Budget alerts that halt or throttle spend can become an availability risk; decide deliberately whether a budget stop is allowed to take production down.
- • Cost pressure is a common driver of insecure shortcuts: skipping a private endpoint, disabling audit logging, reducing environment separation. Name the security cost when it happens.
- • Three shapes: fixed (billed for existing), usage (billed for volume), spiky (billed for bursts you did not plan).
- • The dominant items in most bills are compute, idle capacity, managed databases and data transfer — in that rough order and with wide variance by workload.
- • The items that surprise are transfer, NAT processing and observability, all of which are invisible on an architecture diagram.
- • Every figure in this module is illustrative. Actual rates depend on provider, region, tier, commitment and negotiated agreement.
- • Daily spend rate by tag, which surfaces a step change in a day instead of a month.
- • Cost per unit of business value — per thousand requests, per active tenant — which is the only metric that distinguishes growth from waste.
- • Anomaly detection on the top line items, tuned to rate of change rather than absolute value.
- • Percentage of spend that is attributable, tracked as a health metric of the tagging discipline itself.
- • The signal that lies: total monthly spend. It rises with growth and hides a doubling of cost per request underneath an increase everyone expected.
- • For a small system, one budget alert and a monthly look at the top five line items covers nearly all the value. A cost-management platform is not the starting point.
- • A simpler architecture is the strongest cost control available: fewer components, fewer hops, fewer meters. Most cost work is undoing complexity that was never justified.
- • Provider-native cost tooling before third-party platforms, which are themselves priced as a percentage of the spend they analyse.
- • If the bill is small relative to engineering salaries, the correct decision is usually to stop optimizing and ship features — an honest answer that cost tooling vendors rarely give.
- • Making cost visible buys better architecture decisions; it costs tagging discipline, review time and the risk of optimizing the wrong thing enthusiastically.
- • Commitments cut the rate and remove flexibility precisely when a re-architecture would otherwise be attractive.
- • Cutting idle capacity saves money and consumes the buffer that absorbs traffic spikes and failover. That trade must be made deliberately.
- • Cost attribution needs tagging discipline that slows resource creation slightly and pays back only when there are enough teams to argue about the bill.
Where the bill actually comes from
fixed weight is committed at provision time; usage weight follows the workload. idle = 100% − 35% used → headroom 25% (chosen) + waste 40% (not chosen)
What people believe, and what is true
Cloud is cheaper than owning servers.
It converts capital expenditure into operating expenditure and buys elasticity. For a steady, predictable, high-utilization workload, owned hardware is frequently cheaper — see On-Premises vs Cloud.
Compute is the bill.
Compute is usually the largest single item and rarely a majority. Transfer, idle capacity, managed data services and observability together typically exceed it.
Cost optimization is a finance activity.
The large savings are architecture changes — remove a hop, add a CDN, fix the scale-in policy, delete an environment. Finance can negotiate a rate; only engineers can remove a meter.
We will optimize once it becomes a problem.
By then the architecture has been built around the expensive shape, and changing it costs a migration. Cost is cheapest to influence in the design review.