Cloud cost management is an architecture problem
Dashboards show where the money went. Architecture decides where it goes next.
By Xonique Editorial TeamEditorial Desk
Published · 7 min read
Cost programmes typically begin with a dashboard and a round of right-sizing. Savings appear, then erode. The erosion is a signal: the underlying design keeps generating the same spend.
Where the money usually is
| Area | Common cause | Structural fix |
|---|---|---|
| Data transfer | Chatty cross-zone services | Co-locate or batch |
| Storage | Everything on hot tiers | Lifecycle policies |
| Compute | Idle non-production environments | Scheduled shutdowns |
| Observability | Unbounded log retention | Sampling and retention tiers |
Make cost visible to the team that creates it
Attribution changes behaviour more reliably than a central mandate. Teams that see their own spend tend to fix it without being asked.
What to check before you commit
- Attribute spend to owning teams.
- Fix the top structural driver before optimising instances.
- Set retention policies on logs and storage.
- Re-check three months after each change.
A note on measurement
Teams that treat cloud cost work as an engineering project usually measure the wrong thing. Instrument the business outcome first — cycle time, cost per transaction, resolution rate, revenue retention — then work backwards to the technical metrics that move it.
- cloud economics
- architecture
- platform engineering