Your cloud bill is an architecture problem

The monthly surprise

The pattern is familiar. Cloud adoption starts with a few projects and a modest bill. Two years later the invoice runs to many pages, grows faster than the business, and nobody can say with confidence which team, product or customer is responsible for which line.

The instinct is to treat this as a procurement problem: negotiate a discount, buy reserved capacity, move on. Discounts help, but they lock in whatever the architecture is doing today. If the architecture is wasteful, a discount only makes the waste cheaper.

A discount locks in whatever the architecture is doing today. If it is wasteful, you are only making waste cheaper.

Where cloud money actually goes

• Idle and oversized compute. Instances sized for a peak that never came, and non-production environments that run through nights and weekends.
• Forgotten storage. Snapshots, orphaned disks and old backups that outlive the systems they belonged to.
• Data transfer. Traffic between regions, zones and out to the internet is easy to overlook in a design review and expensive at scale.
• Managed services left at default tiers. Databases and caches provisioned for the largest case and never revisited.
• Lift-and-shift workloads. Applications moved as-is that still behave as if they were on fixed hardware, running flat out whatever the demand.

Make cost visible before you try to cut it

The FinOps Foundation describes the practice in three phases: inform, optimise and operate. Most organisations try to jump straight to optimise. Without the first phase, savings are guesswork and they rarely last.

1. Enforce taggingOwner, cost centre, environment and application tags on every resource, applied by policy rather than good intentions. Untagged spend is reported as its own line until it reaches zero.
2. Show teams their own billBreak costs down by the tags above and send each team its share. Cost that lands with the people who create it changes behaviour faster than any central review.
3. Set budgets and anomaly alertsAlerts on unusual daily spend catch a runaway job in hours rather than at the end of the month.
4. Track unit costCost per transaction, per customer or per environment tells you whether growth is efficient. Total spend alone cannot.

The architecture levers

Once costs are visible, the biggest reductions come from engineering decisions:

1. Rightsize, then scheduleMatch instance sizes to measured use, and switch off non-production environments outside working hours.
2. Scale with demandAutoscaling, containers and serverless functions turn fixed capacity into capacity that follows real load.
3. Choose storage tiers deliberatelyMove infrequently used data to cheaper tiers automatically, and set lifecycle rules so snapshots and backups expire.
4. Design for data localityKeep chatty services in the same zone or region, and cache content close to users to cut transfer charges.
5. Commit lastReserved instances, savings plans and committed-use discounts are powerful, but only after rightsizing, so you commit to the capacity you actually need.

Make it a habit, not a project

One-off cost reviews produce a satisfying dip followed by a slow climb back. Lasting control comes from building cost into the way the platform runs: guardrails in the landing zone, cost checks in design reviews, and a monthly conversation between engineering and finance about the numbers that matter.