Where cloud spend actually leaks
Six findings recur on almost every cost review we run, and none of them require re-architecting anything. They are unglamorous, they are mostly configuration, and together they usually account for the bulk of what a first pass recovers.
Most cloud overspend is configuration, not architecture. Instances sized from an old guess, non-production environments running around the clock, orphaned storage, unnecessary cross-zone transfer, no commitment on steady baseline load, and logs retained forever. Each is fixable without touching application code.
The six findings
1. Instances sized for launch day
Provisioned from an estimate made before anyone had real traffic, and never revisited. Peak CPU sits in single figures while you pay for headroom that was hypothetical two years ago.
The fix: right-size against ninety days of actual metrics rather than intuition, and set a calendar reminder to repeat it. On AWS, Compute Optimizer will do the analysis; the work is having someone act on it.
2. Staging running at 3am on a Sunday
Non-production environments are billed 168 hours a week and used for roughly 45. Development, staging and QA together often cost a meaningful fraction of production, for machines nobody touches outside office hours.
The fix: scheduled shutdown outside working hours. This is a scheduled task and a tag, and it is the single highest ratio of saving to effort on this list. Mind the time zones if your team spans several — we run a dedicated evening shift for US Eastern overlap, and that shift needs its environments awake.
3. Orphaned volumes and snapshots
Storage attached to instances terminated long ago, plus snapshots created during an incident in 2024 with no retention policy. Nothing alerts on this because nothing is broken.
The fix: inventory, delete what is genuinely unreferenced, then apply lifecycle rules so it cannot silently accumulate again. Do the deletion deliberately and slowly — the one snapshot that mattered is always the one somebody deletes in a hurry.
4. Cross-zone chatter
Application and database sitting in different availability zones, paying data transfer charges on every query. It is invisible on an architecture diagram and clearly visible on a bill once you know to look.
The fix: co-locate the chatty pair, or cache what crosses the boundary. Multi-zone redundancy is worth paying for; accidental multi-zone conversation is not.
5. No commitment on stable baseline load
Capacity that never varies, billed at on-demand rates indefinitely. If a workload has a floor it never drops below, that floor is a commitment you could be making.
The fix: savings plans or reserved capacity sized to the floor, never the peak. Committing to your average is how organisations end up locked into capacity they later have to grow around.
6. Logs retained forever in hot storage
Debug-level logging written to the fastest storage tier, with no sampling and no tiering, years after anyone last read a line of it.
The fix: sample high-volume debug output, tier older logs to cheaper storage, and set retention to match your actual policy rather than to infinity. Check the compliance requirement first — sometimes the answer genuinely is seven years, and then it belongs in cold storage, not hot.
| Finding | Why it happens | Effort to fix |
|---|---|---|
| Over-provisioned instances | Sized before real traffic existed, never revisited | Low — data plus a change window |
| Non-prod running 24/7 | Nobody owns the off switch | Lowest — a schedule and a tag |
| Orphaned storage | Deletion is nobody's task and nothing alerts | Low, but do it carefully |
| Cross-zone transfer | Invisible on the architecture diagram | Medium — may need a move |
| No savings plan | Requires a forecast nobody was asked for | Low — a finance decision |
| Infinite log retention | Default settings, never revisited | Low — policy plus lifecycle rules |
Scroll the table sideways for the full comparison.
Where we advise against Kubernetes
If you run fewer than about ten services and have no platform engineer, Kubernetes will cost more in operational attention than it returns. A managed container runtime — ECS on Fargate, Azure Container Apps or Cloud Run — gives you the same deployment story with a fraction of the moving parts, and nothing stops you moving to Kubernetes later if scale genuinely demands it.
We say this on most first calls and it regularly reduces the size of the engagement. What we will not do is stand up a cluster you have nobody to operate, hand over the kubeconfig and call that a platform.
We report what we found and what it saved. We do not quote a percentage in advance, because the honest number depends entirely on what is already in your account — and if there is nothing meaningful to recover, we say so and stop rather than manufacturing findings.
Making the saving stick
A one-off cost review is worth doing and will drift back within a year unless three things change.
- Tagging that means something. Cost attributed per environment and per service, so "why did the bill go up" has an answer in minutes rather than a week.
- Infrastructure defined in code. If environments are reproducible, right-sizing is a pull request rather than an archaeology exercise. Nothing should exist because someone clicked it into being.
- A budget alert with an owner. Not a dashboard nobody opens — a threshold that messages a named person when spend deviates from the trend.
How we set those up, and the rest of the platform work around them, is covered on cloud, DevOps and modernisation. Where regulated data or residency requirements shape the architecture, security and compliance sets out what we build and what we explicitly do not certify. If you would rather someone watched this continuously than once, dedicated teams and AMC support covers how that is structured.
Other guides from the delivery team are collected on the insights index.
Related reading
Send last month's bill and a description of your deploy.
Those two things tell us most of what we need. An engineer replies within one business day with the specific items we would look at first.
- Email — [email protected]
- Phone / WhatsApp — +91 817 979 7732