Cloud cost programmes follow a familiar arc. Spend grows uncomfortably, leadership demands action, a team spends six weeks finding savings, the bill drops, everyone declares victory, and eighteen months later spend is higher than before. The savings were real; the mechanism that produced them was a one-off effort rather than a change in how decisions get made.
01Attribution before optimisation
You cannot manage spend that is not attributable. If the bill is one large number, nobody owns any part of it, and every optimisation is a central team negotiating with engineers who have no visibility into what their choices cost.
Enforce tagging - team, service, environment - and enforce it at provisioning time rather than auditing afterwards. Untagged resources should be blocked or automatically flagged, because retroactive tagging campaigns are miserable and never complete. The goal is that every team can see their own spend, broken down by service, trending over time.
- Mandate tags at provisioning; block or quarantine untagged resources.
- Report spend per team and per service, not just organisation totals.
- Track unit cost - spend per customer or per transaction - not absolutes.
- Make the dashboards self-serve so teams do not need to ask.
02Unit cost is the metric that matters
Total spend rising is not inherently bad. A business growing 60% with spend growing 40% is improving. A business flat with spend growing 40% has a problem. Absolute numbers cannot distinguish these, and organisations that track only totals oscillate between panic and complacency.
Track cost per unit of business value - per customer, per transaction, per active user, whatever fits your model. This reframes the conversation from cutting to efficiency, and it makes genuine improvements visible even during growth when the total bill is climbing regardless.
03Where the money usually is
Cost distribution is remarkably consistent across organisations. The largest opportunities are rarely exotic - they are idle resources, over-provisioning, and data transfer that nobody modelled.
| Source | Typical waste | Fix |
|---|---|---|
| Idle non-production | Running 168h/week, used 40 | Scheduled shutdown outside hours |
| Over-provisioned compute | 2-4x actual need | Right-size from observed utilisation |
| Orphaned storage | Volumes and snapshots long detached | Lifecycle policies, scheduled cleanup |
| Cross-AZ data transfer | Often invisible until large | Zone-aware routing and placement |
| Old snapshots and backups | Accumulating indefinitely | Retention policy, enforced |
| On-demand for steady load | 30-60% above committed pricing | Commitments once usage is stable |
04Commit only to what you have measured
Reserved capacity and savings plans offer substantial discounts for committing to a usage level. They are also a one-to-three year obligation, and over-committing based on projected growth that does not materialise locks in spend for capacity you never use.
Commit to your measured floor - the level of usage that has been stable for months - and leave headroom on demand. Layer additional commitments as the floor rises. This captures most of the discount with almost none of the risk, and it avoids the trap of a commitment made during a growth spurt that becomes an anchor during a slowdown.
05Make it continuous, not a campaign
The reason savings evaporate is that the optimisation was an event while the spending decisions are continuous. Every new service, every provisioning choice, every architecture decision adds cost, and if none of those decisions surface cost information, the bill drifts back up regardless of what was cleaned up.
Put cost in the normal flow of engineering work: estimated cost impact in design review for significant changes, anomaly alerts when a service's spend jumps, and a regular review where teams see their own trend. The aim is engineers making informed trade-offs routinely, not a central team policing them periodically.
- Alert on cost anomalies per service, not just organisation-wide.
- Include cost estimates in design review for substantial changes.
- Give teams a budget they own rather than a mandate they resent.
- Automate cleanup - lifecycle policies and shutdown schedules beat reminders.
Topics
Marcus Hale
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.