Your cloud bill is too high. Where does the money go, and how do you bring it down without degrading the service?

Attribution comes before optimisation

The first question is not "what can we turn off" but "whose is it". Until the bill is broken down by service, team, and environment, every efficiency conversation is a debate about anecdotes, and the loudest voice wins. Tagging, account or project separation, and cost allocation for shared services are prerequisites rather than housekeeping, and the shared-service allocation is the part people skip — a Kubernetes cluster, a data warehouse, and an observability platform will otherwise absorb most of the spend into a bucket with no owner.

Alongside attribution you need one unit cost. Cost per order, per active tenant, per thousand requests, per gigabyte ingested: something whose denominator is business volume. Without it you cannot distinguish a genuine efficiency gain from a quiet fall in traffic, and you cannot tell a growing business that a rising bill is fine. This is also the number that survives a change of CFO, because it converts an engineering activity into a margin conversation.

Where the money usually is

The shape varies, but the categories are consistent, and being able to reason about their relative weight matters more than any figure. The table below is a hypothetical to illustrate the reasoning — it is not a benchmark, and you should insist on measuring your own.

Category	Typical driver	Usual reason it is larger than expected
Compute	Instances or pods provisioned for peak, running at trough	Sizing set once at launch and never revisited; no scale-to-zero for spiky work
Storage	Everything on the hottest tier, retained forever	No lifecycle policy; snapshots and orphaned volumes nobody deletes
Data transfer	Cross-zone and cross-region chat, egress to users	A chatty service topology; replicas placed for redundancy, then talked to constantly
Managed services	Per-request and per-GB pricing on a hot path	A design that multiplies calls per user action
Telemetry	Log volume, metric cardinality, retention	Debug logging left on in production; high-cardinality labels; traces sampled at 100%
Non-production	Environments that mirror production and never sleep	Nobody owns switching them off

Two of those deserve emphasis because they are the ones senior candidates catch. Telemetry can become one of the largest lines in a mature estate, and it grows with cardinality rather than with traffic, so a single new label containing a user identifier can multiply a metrics bill without any change in load. And non-production is where waste is socially easiest to remove, which makes it the right first move politically even when it is not the biggest number.

The architectural decisions that write the bill

Right-sizing recovers waste. Architecture determines how much waste there is to recover, and the decisions that dominate are made long before anyone opens a cost console.

Where you place the boundary between services decides how much of your traffic crosses a zone. A synchronous fan-out of six calls per user action costs six times the network, six times the trace spans, and enough latency to justify more instances. Your multi-tenancy model — a stack per tenant against a shared pool — sets the floor under which cost cannot fall regardless of utilisation, and it is close to irreversible once contracts reference it. Your read model decides whether a dashboard scans a warehouse on every page load or reads a materialised view. Your consistency requirements decide whether you pay for synchronous cross-region replication. And your retention policy, usually set by a default nobody chose, decides the storage line for years.

The practical consequence is that cost belongs in design review as a named quality attribute with an estimate attached, in the same way latency is. A design document that states an expected cost per thousand requests, derived visibly from the call fan-out and the per-call pricing, is doing something a cost dashboard cannot do retrospectively.

Work in this order

Sequencing is where good answers separate themselves, because doing these steps out of order locks in the waste.

First, remove what is unused: orphaned volumes, idle load balancers, forgotten environments, dead pipelines. This is free and it changes the denominator for everything after.

Second, fix the demand: right-size against measured utilisation with headroom derived from tail load rather than from averages, set autoscaling floors honestly, and schedule non-production down out of hours.

Third, fix the design where the numbers justify it: batch or collapse chatty calls, cache the hot read, tier cold data, sample telemetry with a policy that keeps everything for errors and slow requests and thins the successful bulk.

Only then commit. Reserved capacity and savings plans are the largest single lever available, and they are also a promise to keep spending. Committing before right-sizing means buying a discount on waste and then being unable to remove the waste for a year, which is the most common self-inflicted wound in this area.

The reductions that are really reliability cuts

Some savings are not savings, they are a transfer of cost into the risk column, and an interviewer is listening for whether you can tell the difference under pressure. Collapsing to a single availability zone, removing a replica, dropping backup frequency, shortening retention below your recovery requirement, cutting instrumentation on the payment path, and running with no headroom for failover all reduce the bill immediately and correctly. They also change the probability distribution of your outages, and the trade is only legitimate if the service level was explicitly renegotiated with whoever owns the consequences.

The honest way to hold the line is to make the trade visible instead of refusing it outright. "We can save that amount by running one zone; the effect is that a zone failure becomes a full outage rather than a degraded one, and our current commitment says that is not acceptable. If you want to change the commitment, that is a conversation we can have." That phrasing keeps you in the room and puts the decision where it belongs.

The measurement everyone forgets

The reason cost programmes stall after the first quarter is not that engineers run out of ideas. It is that nobody can prove the last round of work mattered, so the next round loses its sponsor. The bill fell, traffic also fell, one team shipped a caching change, and another rolled back a scheduler — and with no unit cost and no per-team attribution, the improvement is indistinguishable from luck. Establish the unit metric and the per-team split before the first optimisation, publish it monthly, and accept that a rising absolute bill with a falling unit cost is a success you can defend.

Cost is an architectural output, not a procurement problem: attribute it, express it per unit of business volume, and never buy a commitment on capacity you have not yet earned the right to keep.