I Cut Our Cloud Bill by 40% in One Afternoon

The fastest way to audit a cloud bill is to map spend to utilization — not just to service totals. AWS Cost Explorer shows what you spent. It does not show what you should have spent. That gap is where the waste lives. For our account, it was 40% of the total bill, sitting undetected for eight months.

I connected our AWS account to SpendArk. Setup took three minutes — read-only IAM credentials, nothing to install. Within minutes it surfaced recommendations sorted by dollar amount. CPU and memory utilization appeared alongside monthly cost per instance. The waste was immediately obvious.

Before that, I had tried AWS Cost Explorer manually. It's useful for one thing: telling you what you spent. It won't tell you that a specific instance is running at 6% CPU. That distinction matters. I also pulled up Cost Explorer and filtered by service to map where money was going. Our breakdown before the audit:

• EC2 (compute): $1,140/mo
• RDS (databases): $520/mo
• S3 (storage): $180/mo
• Data transfer: $310/mo
• CloudWatch / misc: $250/mo

The headline felt vaguely reasonable for a SaaS product. That's exactly why I had never questioned it. One unique insight here: the most dangerous cloud bills are the ones that feel reasonable. A bill that doubles overnight gets noticed. One that drifts up 8% per month for eight months does not — until you do this audit.

Zombie resources — infrastructure running with no active workload — account for a significant share of cloud waste across teams of all sizes. Flexera's 2025 State of the Cloud report identifies idle resources as the top optimization opportunity cited by cloud practitioners for the fifth consecutive year. SpendArk flagged eleven of them in our account. The categories surprised me.

The staging EC2 box was the most embarrassing. It had been running for three months since we wrapped a feature. Nobody deleted it because nobody owned it. That single accountability gap cost $62/mo for 90 days. The RDS snapshots were the most avoidable — we had switched to automated backups but never cleared the manual ones. This kind of cloud waste and overprovisioning is standard for teams without a regular audit cadence.

The practical fix was simple: use CloudTrail to verify no access in 90+ days, then delete. Deleting took 45 minutes. Zero engineering judgment required. Nothing was in use. The useful pattern here is the CloudTrail check — it removes the psychological friction of "what if something breaks." If the last API call was 3 months ago, it won't break.

Savings: $180/mo. Effort: one hour.

Right-sizing is where most cloud cost guides go vague. They say "right-size your instances" without showing the numbers. Here are the numbers. According to Gartner (2025), the average cloud workload uses less than 30% of its provisioned compute capacity. Our numbers were worse.

Our production API ran on an m5.2xlarge (8 vCPU, 32 GB RAM) at an average of 6% CPU and 18% memory. We had sized it for peak traffic two years ago and never revisited it. An m5.large (2 vCPU, 8 GB RAM) handles our current peak with headroom. That single change: $312/mo down to $72/mo. A 77% cost reduction for one instance type change.

Our dev/staging environment was running the same instance sizes as production. Dev does not need production-grade compute. Dropping those to t3.mediums saved another $80/mo. This is a pattern Harness (2025) identified across their customer base: 58% of non-production environments are the same size as production, despite usage being a fraction of peak.

I did this carefully. For the production API change, I spun up the smaller instance in parallel, ran it under load for a week, watched the metrics, then terminated the larger one. Total downtime: zero. The parallel-run approach added a week of calendar time but only two hours of actual work. Do not resize in place and hope — validate first.

Savings: $320/mo. Effort: one week of calendar time, a few hours of actual work.

Reserved instances and Savings Plans deliver 30–72% discounts over on-demand pricing (AWS pricing docs, 2025). Yet Harness (2025) found that 58% of developers have not adopted reserved pricing at all. The reason is usually fear of commitment — but that fear is mostly unfounded when you use the right plan type.

After right-sizing, I checked which instances had run continuously for 6+ months with no sign of termination. Three qualified clearly: the production API server, the production database, and the background job worker. All had 100% uptime for the prior six months. Stable workloads are exactly what reserved pricing is designed for.

I bought 1-year Savings Plans (no-upfront) for all three. No-upfront means you pay nothing today — you commit to an hourly rate for a year and still get the discount. The discount on our workload mix came out to 37% on those instances. The key insight most teams miss: AWS Compute Savings Plans apply to any EC2 instance regardless of family, size, OS, or region. You are not locked into a specific instance type. For a detailed comparison of how reserved vs spot vs on-demand pricing stacks up, see our dedicated guide.

One critical point: I only committed to reserved pricing after the right-sizing step was done and stable. Buying a reserved instance for a size you're about to change locks in the wrong discount. Get the size right first. Then commit.

Savings: $400/mo. Effort: 30 minutes to buy the Savings Plans.

The reason this waste sat undetected for eight months: no alerts. The bill arrived, I paid it, I assumed roughly-stable meant roughly-fine. Cloud bills are not utility bills. They grow with every resource you forget and every instance you never revisited.

I set up three things to prevent a repeat:

1. AWS Budget alerts. I created a monthly budget at $1,500 — our new expected spend — with alerts at 85% ($1,275) and 100% ($1,500). Hitting 85% before month-end triggers an email. I can investigate before we overshoot.

2. Per-service anomaly detection. AWS Cost Anomaly Detection is free. It emails you when any service spends significantly above its historical baseline. I enabled it for EC2, RDS, and data transfer separately. New unexpected charges now show up within 24 hours — not at month-end.

3. SpendArk scheduled scans. Weekly scans, every Monday. A short report shows new idle resources, instances with dropped utilization, and fresh recommendations. Two minutes to review. If we spin up a test environment and forget it, SpendArk flags it within a week — not eight months from now.

This step costs nothing. It requires one setup session. The ROI is permanent.

Here's what the bill looked like before and after, and what drove each change:

Before: $2,400/mo. After: $1,440/mo. Annual difference: $11,520.

Eight months at $960/mo in unnecessary spend is $7,680 gone. The only reason it happened is treating the cloud bill like a utility bill — just pay it and move on. Electricity bills don't grow when you forget to turn something off. Cloud bills do. Every resource you forget to delete and every instance you never revisited is a recurring charge with no expiry date.

If you haven't audited your cloud bill in the last six months, you almost certainly have some version of this. The categories are consistent across teams: zombie resources, oversized instances, no reserved pricing on stable workloads, no alerts. The dollar amounts vary. The patterns don't. Flexera (2025) confirms this — idle resources and rightsizing are the top two optimization opportunities named by cloud practitioners year after year, at organizations of every size.