The cloud bill has doubled year on year while revenue grew 20%. The CFO wants a plan. What is your approach?
Show the full answer Hide the answer
Establish unit economics before proposing cuts
The headline number is not actionable. Cost per transaction, per customer or per order tells you whether the business is getting less efficient or simply larger.
If unit cost is flat and volume doubled, the bill is behaving correctly and the conversation is about growth rather than waste. If unit cost rose, there is a specific regression to find. Establishing which one is true takes a day and changes the entire plan.
Then attribute
Cost by team, by service and by environment, from tagging. Where tagging is incomplete, fixing it is the first task, because everything else depends on it.
The recurring findings, in rough order of size:
- Non-production. Frequently thirty to fifty percent of spend, running at full size overnight and at weekends. Scheduling it off is the fastest available saving and it affects nobody.
- Idle and orphaned resources. Unattached volumes, unused load balancers, environments from finished projects, snapshots from years ago.
- Over-provisioning. Instances sized for a peak that never arrived, with utilisation in single digits.
- Data transfer. Cross-zone and egress charges, usually unmodelled and occasionally the largest single line.
- Commitment coverage. Predictable baseline running at on-demand rates.
Sequence by effort against saving
Scheduling and cleanup are days of work with immediate effect. Rightsizing is weeks. Commitment purchasing needs a stable baseline first, or you commit to the wrong shape. Architectural change — caching, storage tiering, moving off an expensive managed service — is months and belongs after the easy savings have bought credibility.
The part that makes it stick
Showback: monthly cost per team, broken down by service, visible to the team. It changes behaviour faster than any central optimisation, because the team that owns the forgotten cluster is the only one who knows it is not needed.
Central optimisation finds it once. Visibility stops it recurring.