Cloud spend has grown 60% in a year while revenue grew 15%. The CFO wants a 30% reduction. How do you respond?

Change the metric before accepting the target

Absolute spend is the wrong frame. Cost per unit of business value — per order, per active user, per gigabyte processed — is what shows whether the system is becoming more or less efficient, and it changes what the conversation is about.

A 60% rise against 15% growth means unit cost rose roughly 40%. That is a real finding and a specific problem, rather than an indiscriminate cutting exercise. It also means the target should be expressed as a unit-cost improvement, which survives the business growing.

Attribute before optimising

Most organisations that believe they have a cost problem have an attribution problem: one number nobody owns.

Mandatory, enforced tagging — owner, service, environment, cost centre. Four tags, applied by the deployment pipeline, with policy refusing untagged resources. Plus a published rule for shared costs, which otherwise grow until they dominate the report and nobody can act on any of it.

Without this, nothing below the level of the whole estate can be analysed, and every subsequent step is guesswork.

Then act, in order of return and reversibility

Waste elimination first — no trade-off, no architectural change. Unattached volumes, unassociated static IPs, old snapshots and images, load balancers with no targets, incomplete multipart uploads, and non-production running overnight and at weekends, which alone is frequently the largest single item.

Commitment coverage — cover the steady-state baseline at 70–85%, not the peak, with flexible commitments where re-architecture is likely and staggered expiry dates.

Instance family and architecture — ARM-based instances typically give 20–40% better price-performance, and newer generations are cheaper per unit of performance and routinely unused because nobody revisits the choice. Match the family to the workload's actual CPU-to-memory ratio.

Rightsizing, carefully. Not to the average: peak, fault-domain redistribution — below (N−1)/N — and the queueing curve all need headroom. The honest savings are in non-production and in workloads sized once at launch.

Storage lifecycle and telemetry cost, where the ratio is commonly 10–30% of infrastructure and grows silently.

Architecture changes last, because they take longest: caching to cut backend load, egress reduction through private endpoints and zone-aware routing, and consolidating low-traffic services whose cost per request is dominated by idle cost.

Say what a 30% cut would cost

Some of the target is achievable without trade-off. Beyond that point, be explicit: reduced headroom means reduced availability, and cutting telemetry trades a visible cost for longer incidents. Present the tranche that is free, the tranche that costs engineering time, and the tranche that costs reliability — and let the business choose.

Make it not recur

The annual cost-cutting campaign fails because nothing changes in how decisions are made. FinOps as an operating cycle — inform, optimise, operate — with per-team cost visibility, cost as a factor in design review, anomaly detection, and forecast-based budget alerts. Engineering teams own their costs; central function provides tooling and benchmarks.

What a strong answer adds

Naming the likely cause of the 40% unit-cost rise rather than treating it as diffuse: a new workload with poor economics, a cache hit rate that fell, a change that increased cross-zone traffic, or telemetry growth. Cost anomalies usually have a specific cause and a specific date, and finding it is faster than a broad optimisation programme.