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.
Two lines sit outside that table because they are not cloud settings at all. The first is an integration retrying in a loop: a queue with no dead-letter policy bills you for compute, egress and log volume on every failed attempt, and the failure is silent by design — why integrations fail silently covers how to catch it before the invoice does. The second is the backend behind a mobile app, which runs whether or not anyone opens the app; the client-side decision in native or cross-platform moves the build cost, not that monthly line.
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. The review runs on time and materials against an agreed ceiling for the same reason: a fixed fee on an estate nobody has opened yet gets priced for the worst case, and you pay for that risk whether or not it turns up — fixed price or time and materials sets out how each shape behaves once the scope moves.
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.
Timelines, downtime and who owns the bill
How long does a cost review take, and what does it cost?
One to two weeks end to end for a single production account and its non-production environments, of which a few days are hands-on: read-only access to billing, metrics and the resource inventory, then a written list of findings ranked by saving against effort to fix. It runs longer where there are several accounts, more than one region, or services nobody currently owns. We bill it on time and materials against an agreed ceiling, and we do not take a percentage of what we save you — that model rewards the findings easiest to claim credit for over the ones actually worth doing.
Do the savings require downtime or a deploy freeze?
Most of them do not. Scheduled shutdown of non-production, storage lifecycle rules, log retention and sampling, and savings plans are billing or configuration changes with no production impact at all. Right-sizing needs a restart on most instance families, so it goes out as a rolling change through whatever window you already use — if you can deploy without downtime, you can resize without it. The exception is co-locating an application and database that currently sit in different zones, which moves a database and usually wants a maintenance window. We work inside your change process rather than asking you to freeze it.
What happens to the saving over the following year?
It drifts back, and the drift is predictable. Environments get created for a project and outlive it, instance sizes revert to whatever the template says, log volume grows with traffic, and a savings plan expires while nobody is watching the renewal. Without the three controls above — tagging that attributes cost per service and environment, infrastructure defined in code so a resize is a pull request, and a budget alert that messages a named person — expect to hand back a meaningful share of the first pass within a year. The review is the cheap part; the controls are what keep it.
Would moving to a cheaper provider save more than fixing this?
Rarely, and it is an expensive way to find out. Compare providers after right-sizing rather than before, because most of the headline gap closes once you stop paying for capacity you never used. Whatever gap is left then has to cover migration engineering, egress charges on the way out, relearning the managed services your team is already fluent in, and several months where nobody is fully at home in either environment. Move for a reason that survives that arithmetic — a managed service you genuinely need, a data residency requirement, a commercial agreement large enough to matter. We do not take provider migrations sold as cost-saving projects: if the case rests on the sticker price alone, we will walk you through the arithmetic and decline the work.
Who should own the cloud bill inside the business?
One named engineer with the authority to change infrastructure, working with finance on commitments. Finance alone cannot act, and "the platform team" owns it in the same sense that nobody does. The split that works: engineering owns per-service cost, made visible by tagging, so a rise has an explanation in minutes; finance owns savings plans and reserved capacity, because those are forecasts and cashflow decisions rather than technical ones. The budget alert routes to a person, not a channel. Twenty minutes a month on the five largest movers catches most of what would otherwise be a surprise at quarter end.
One line dominates our bill and nobody knows what it is. Where do we start?
Group the bill by usage type rather than by service. On AWS the answer is usually inside "EC2-Other", which quietly contains NAT gateway processing and cross-availability-zone transfer; in Azure, grouping cost analysis by meter does the same job. Switch on cost allocation tags and the Cost and Usage Report, trace the largest usage type down to resource IDs, and from there to the team that created them. If it is NAT gateway data processing, VPC gateway endpoints for S3 and DynamoDB often remove a large part of it. Do not delete anything until you can name the workload behind it.
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 — contact@canopussoft.com
- Phone / WhatsApp — +91 817 979 7732