How I Reduced AWS Costs by 40% (Without Breaking Production)

Most AWS bills are not expensive because the workload is expensive. They're expensive because nobody owns the number. It grows a few percent a month, everyone assumes it's "just what cloud costs," and eighteen months later you're paying for three environments that no human has logged into since the last reorg.

I took one client from roughly $28k/month to $17k/month — about a 40% cut — over six weeks, with zero customer-facing downtime. Here's the actual playbook, in the order I run it. No "turn off unused resources" hand-waving.

Step 0: Get the data before you touch anything

You can't cut what you can't see. Before any change, I turn on the boring stuff:

• Cost Explorer with grouping by service, then by tag. If nothing is tagged, that's finding number one.
• Cost Anomaly Detection so future spikes page someone instead of surprising you at month-end.
• A one-time export to S3 + Athena (the Cost and Usage Report) so I can ask real questions like "what does one tenant actually cost."

If your resources aren't tagged by team, service, and environment, every optimization after this is a guess. Tag first.

Step 1: Kill the zombies

The fastest money is the money you're spending on nothing.

• Unattached EBS volumes and old snapshots. These accrue silently for years. One account had 1.2 TB of orphaned gp2 volumes from terminated instances.
• Idle load balancers with no healthy targets.
• Elastic IPs not associated with a running instance — AWS charges for the ones you reserve but don't use.
• Old environments. The staging stack from a launch two quarters ago. The "temporary" data-migration box. Ask in Slack, wait 48 hours, then delete.

This alone was about 8% of the bill. It took an afternoon.

Step 2: Right-size compute honestly

Everyone over-provisions because under-provisioning gets you paged. Fair. But "safe" and "2x too big" are different things.

Pull two weeks of CloudWatch data and look at p95 CPU and memory, not average. My rule of thumb:

• p95 CPU under ~20% for two weeks → drop one instance size.
• Move last-generation instances to current gen. An m5 → m6i/m7i swap is often cheaper and faster for the same specs. Graviton (m7g) is cheaper still if your stack is ARM-friendly — most Node, Python, Go, and Java workloads are.

Right-sizing plus a Graviton migration on the API tier was another ~12%.

Step 3: Commit to what you actually use

Once the fleet is the right size, buy your baseline down. This is where the big, boring savings live:

• Compute Savings Plans for steady-state EC2/Fargate/Lambda. They're flexible across instance family and region, so you don't get locked to a size you'll outgrow. A 1-year, no-upfront plan is the sweet spot — meaningful discount, low commitment risk.
• Reserved Instances for RDS and ElastiCache, where you can't easily swap engines anyway.
• Cover roughly your p10 usage — the floor you're certain to run 24/7 — and leave the spiky top on on-demand or Spot.

Do this after right-sizing, never before. Commit to a bloated fleet and you've locked in the waste.

Step 4: Fix storage and data transfer

The line items nobody reads:

• S3 lifecycle rules. Transition logs and backups to Infrequent Access, then Glacier. Add Intelligent-Tiering for buckets with unpredictable access.
• Data transfer. Cross-AZ chatter and NAT Gateway egress are stealth costs. A misconfigured service pulling from S3 across a NAT Gateway instead of a VPC endpoint can cost thousands a month. VPC endpoints for S3 and DynamoDB are free.
• CloudFront in front of S3 so you're not paying origin egress for every asset request.

Step 5: Make it stick

A 40% cut that creeps back in six months isn't a win. The habits that hold the line:

• A monthly cost review with the number on a dashboard someone owns.
• Budgets + alerts per environment, not just account-wide.
• Cost as a line item in architecture decisions — "what does this cost at 10x traffic?" asked before the thing ships.

The honest caveat

Cost optimization has a floor. Past a point you're trading engineering hours for marginal savings, and engineering hours aren't free. The goal isn't the cheapest possible bill — it's a bill that maps to value, with no silent waste. Chase the 40%, not the last 3%.

---

I do this kind of work for startups and scale-ups — AWS, GCP, and Azure — alongside building the apps that run on top of it. If your cloud bill has quietly become a mystery, let's talk.