04/REDUCE CLOUD COSTS
Our AWS bill doubled and nobody knows why.
The AWS invoice has grown steadily, and the growth does not track anything you recognise — not users, not traffic, not revenue.
Cost Explorer gives you totals by service, which tells you that EC2 is expensive without telling you which instances, why they exist, or whether anything still uses them.
Somebody suggests reserved instances or savings plans, but committing for a year to capacity you have not verified you need is how you make the problem permanent.
What you want first is not a discount. It is an explanation.
01/Why it happens
It is nearly always one of these three.
Nothing is ever switched off
Test environments, old load balancers, unattached volumes, orphaned snapshots and idle NAT gateways. Individually small, collectively a meaningful share of the bill, and invisible in a per-service total.
Everything was sized for the launch-day guess
Instances and databases get provisioned generously before real traffic exists, and then never revisited. The guess becomes the baseline and the baseline becomes permanent.
The architecture bills on a dimension nobody watches
Cross-availability-zone transfer, NAT gateway throughput, CloudWatch log ingestion, per-request charges on a chatty integration. These are design decisions that arrive as a line item.
02/What we do about it
The engagement, phase by phase.
Account for the spend
about a week
Cost and usage data pulled apart until every meaningful line has an owner and a reason. The output frequently includes resources nobody knew were running.
Produces
A breakdown by service, resource and environment
Separate waste from cost
a few days
Waste is anything nothing depends on. Cost is what the workload genuinely requires. Being honest about the second list is what makes the first one credible.
Produces
Two lists: waste to remove, and spend that is legitimate
Remove the waste
one to two weeks
Changes applied in reversible steps, safest first, each one verified before the next. Nothing is deleted without confirming what would notice.
Produces
Idle resources decommissioned, sized changes applied
Fix the architectural charges
scoped separately
Transfer patterns, log retention, request volumes. These need engineering rather than a console setting, and they are where the durable savings usually are.
Produces
Targeted changes to the design decisions that bill continuously
Make it visible
a few days
Resources tagged by environment and owner, budgets set, and an alert when spend moves unexpectedly — so the next drift is caught in days rather than quarters.
Produces
Tagging, budgets and alerts on cost anomalies
03/What done looks like
How you will know it worked.
- Every significant line on the bill has a named owner and a reason
- Idle and orphaned resources removed, with a record of what went
- Compute and databases sized against measured usage rather than an old guess
- Cost allocation tags applied consistently across environments
- A budget and an anomaly alert that reach a person who can act
- A written list of remaining savings, each sized against the work it takes
04/Honest caveats
Where this gets harder.
Every engagement has failure modes. Here are this one’s, before you commit to anything rather than after.
- Sometimes the honest finding is that the bill is roughly right for the workload. We will tell you that rather than manufacture savings by removing headroom you need.
- Aggressive rightsizing trades money for resilience. We mark which changes reduce headroom so the trade is yours to make deliberately.
- Savings plans and reserved instances only make sense after usage is stable. Committing first locks in the waste for a year.
- The largest savings are usually architectural, which means engineering work with its own cost. We will show you the payback period rather than only the saving.
05/Questions
Reduce cloud costs, asked about.
01How much can we expect to save?
We will not put a percentage on it before looking, because anyone who does is guessing. The accounting phase is short and produces a sized list of specific savings — at which point the question has a real answer.
02Will this affect performance or reliability?
Removing genuinely unused resources does not. Rightsizing can, which is why those changes are marked as trade-offs, applied in reversible steps, and verified against real load before we move on.
03Can you just tell us what to do and we will do it?
Yes. The findings document and the sized change list stand on their own, and plenty of teams take them and execute internally. We are happy to review the result if that helps.
Sound familiar?
Describe your version of it. You will get a reply from an engineer within one business day, including if we think you do not need us.