How We Cut a Client's AWS Bill by 62% Without Touching Features

Last quarter, a client came to us with an AWS bill of $24,000 per month that had been growing 15% month-over-month for two years. Nobody on their team could fully explain where the money was going — it had simply crept upward as the product grew, and each individual increase was too small to trigger action.

After a four-week infrastructure audit and optimization sprint, they now run at $9,200 per month — a 62% reduction, roughly $180,000 saved per year — with better performance and higher availability than before. We did not remove a single feature or degrade the product in any way. This is the walkthrough of exactly how.

The audit always finds the same things

Cloud waste is remarkably predictable. Across dozens of audits, the same handful of issues account for the majority of overspend, and this client was textbook:

• Oversized compute — EC2 instances running at 8% average CPU utilization, provisioned for a load that never materialized.
• Peak-sized databases — an RDS instance configured for a traffic spike that occurred once, eighteen months earlier, and never since.
• Data transfer costs — significant, invisible charges caused by poor network architecture.
• Unmanaged storage — S3 buckets with no lifecycle policies, accumulating data at full-price storage tiers forever.

The pattern is almost always the same: nothing was provisioned maliciously or stupidly. Each decision was reasonable at the time and simply never revisited as reality diverged from the original assumptions.

Reserved Instances and Savings Plans are free money

The fastest win required no architectural change at all. This client was running their entire fleet on On-Demand pricing — the most expensive way to pay for compute you use continuously.

Teams that run steady workloads on On-Demand are typically leaving 40–60% on the table. Committed-use discounts (Reserved Instances and Savings Plans) require analysis to buy correctly — you have to match commitments to genuinely stable baseline usage — but for any workload running more than ~70% of the time, they are mandatory, not optional.

This single change, applied carefully to their stable baseline, delivered the largest slice of the savings and took days, not weeks.

Data transfer is hidden in plain sight

Data-transfer charges are the costs teams almost never see coming, because they do not map to any resource you can point at in the console. On this account they came from a familiar set of mistakes:

• Routing traffic through NAT gateways where VPC endpoints would have kept it on the private network for a fraction of the cost.
• Fetching S3 objects across regions instead of from a co-located region.
• Chatty cross-AZ traffic between services that could have been co-located.

Fixing these required architectural changes rather than configuration toggles, which is why they took the most time — but they also delivered compounding returns, because they lowered the rate at which cost grew with traffic, not just the current bill.

Right-sizing requires observation, not assumptions

The temptation with an oversized instance is to guess a smaller size and hope. We do not do that, because a bad guess either wastes money or causes an outage.

Instead, we instrument the infrastructure with detailed CloudWatch metrics and observe actual utilization over 30 days before making any right-sizing recommendation. That window captures the real peaks and troughs — the month-end batch job, the weekly reporting spike — so the new size is safe under genuine load, not just under an average that hides the spikes. Right-sizing done on data rather than intuition is how you cut cost without introducing risk.

Where the 62% actually came from

Breaking down the total reduction by source is the most useful part of this story, because it shows there is no single silver bullet — the result is the sum of disciplined, unglamorous work:

1. Reserved Instance and Savings Plan purchases — 24%
2. EC2 right-sizing — 18%
3. Architecture changes to reduce data transfer — 12%
4. S3 lifecycle and storage optimization — 8%

The commitment-based savings were the fastest to realize. The architecture changes took the longest but delivered the most durable value, because they changed the shape of the cost curve going forward rather than just trimming today's bill.

The bottom line

Cloud cost optimization is not about being cheap — it is about paying for what you actually use instead of what you provisioned in a hurry two years ago. The waste is predictable, the fixes are well-understood, and the savings are frequently large enough to fund an additional engineer or extend a startup's runway by months. If your bill has been quietly climbing and nobody can fully explain why, that is not a billing problem. It is an architecture and observation problem — and it is almost always fixable without your users ever noticing a thing.