Why Reserved Instance Discounts Don't Fix the Real Problem With Your AWS Bill

AWS sends you a report showing you could save 40% by committing to reserved instances. Your finance team gets excited. You sign a one-year commitment. Three months later, your bill is still climbing.

Sound familiar?

Reserved instances are real savings — I'm not going to tell you they're a scam. But they're a discount on a number that was already wrong. And that distinction matters more than most people realize when they're staring down a $60K monthly AWS bill trying to figure out where it went.

The Discount Is Real. The Baseline Is the Problem.

Here's the thing about reserved instance pricing: it assumes the on-demand rate is the correct reference point. AWS wants you anchored to that number. When they show you "save up to 72% with a 3-year commitment," they're showing you savings relative to a price they set specifically to make commitments look attractive.

You're not saving 72% compared to what the workload should cost to run. You're saving 72% compared to the most expensive way to run it on their platform.

The actual cost drivers on most AWS bills I've seen aren't the instance hourly rates. They're:

• Egress fees. AWS charges $0.09/GB to move data out of their network. If you're running a data-intensive application — backups, video, analytics pipelines, database replication — this number compounds fast. A company moving 50TB/month is paying $4,500 just in egress before a single instance runs.
• Idle and over-provisioned resources. Reserved instances lock you into capacity. If your workload changes — a product pivot, a customer churn event, seasonal variation — you're paying for instances you're not using. You've traded flexibility for a discount on waste.
• Inter-region and inter-AZ transfer. This one catches people off guard. Moving data between availability zones in the same region isn't free. At $0.01/GB each direction, a multi-AZ architecture with significant internal traffic adds up in ways that don't show up until you're digging through Cost Explorer line items.
• Managed service markups. RDS, ElastiCache, MSK — these services are convenient, but you're paying a significant premium over running equivalent software on compute you control. The reserved instance discount applies to some of these, but the baseline markup remains.

Commit to a reserved instance and you've locked in your rate on the instance. You haven't touched any of the above.

What Cost Explorer Shows You vs. What's Actually Happening

AWS Cost Explorer is a genuinely useful tool, and I don't want to dismiss it. But it's designed to surface savings opportunities within AWS — not to question whether AWS is the right place for a given workload.

The recommendations it generates are optimized for AWS retention. It will suggest rightsizing from an m5.2xlarge to an m5.xlarge. It will suggest reserved instances. It will suggest Savings Plans. All of these are legitimate optimizations within the platform.

What it won't tell you is that the same workload runs for 35% less on a comparable instance somewhere else, with no egress fees and flat pricing you can actually budget against.

I've watched engineering teams spend weeks doing Cost Explorer-driven optimization work — tagging resources, rightsizing instances, purchasing reservations — and end up with a bill that's 15% lower than it was. That's real money. But if the starting point was $80K/month, you've gotten to $68K. Is that the outcome you were trying to reach?

The Commitment Problem Nobody Talks About

Reserved instances require you to predict the future. One year, or three years, of a specific instance type in a specific region. AWS has added more flexibility over time — convertible reserved instances let you change instance families — but you're still making a bet on your infrastructure shape staying roughly constant.

Startups get burned by this constantly. You buy reservations based on current architecture, then you refactor, migrate a service, or your traffic pattern changes. Now you're paying for capacity you're not using, and you can sell reserved instances on the marketplace, but rarely at full value and never quickly.

Larger companies have a different version of the same problem. Multi-team environments where different groups are buying reservations independently, often overlapping, sometimes for workloads that get deprecated. The RI inventory becomes its own management problem. I've talked to infrastructure leads who have a spreadsheet specifically for tracking which reservations are actually being used.

The underlying issue is that the commitment model transfers risk to you in exchange for the discount. AWS gets guaranteed revenue. You get a lower rate — if your usage matches the commitment. If it doesn't, you've paid for the discount without capturing it.

A Real Example of What the Full Picture Looks Like

A healthcare SaaS company running on AWS us-west-2 came to us with a monthly bill around $42K. They had already done the reserved instance work — roughly 60% of their compute was on reservations. They thought they were optimized.

When we looked at the actual bill breakdown:

• $18K in EC2 (mostly reserved, so the rate was decent)
• $9K in RDS (reserved instances applied, but the managed service markup was still significant)
• $7K in data transfer — egress to their customers, inter-AZ replication, S3 access patterns
• $5K in CloudWatch, WAF, load balancers, and other services that don't have reservation options
• $3K in S3 storage and request costs

The reservations had done their job on the compute line. But 57% of the bill was in places reservations don't touch.

We moved their primary workload — the application tier and database — to IDACORE infrastructure in Weiser. The data stays in Idaho, which matters for their HIPAA obligations. Latency to their Boise-area customer base dropped from the 20-30ms they were seeing from Oregon to under 5ms. And their monthly infrastructure cost landed at $27K — not because we have magic pricing, but because flat-rate compute with no egress fees and no managed service markups is just structurally cheaper for this type of workload.

They kept a small AWS footprint for specific services where it made sense. That's usually the right answer — not "abandon AWS entirely" but "stop running everything there by default."

What Actually Fixes a Cloud Bill

Reservations are a tactical tool. They make sense when you have stable, predictable workloads and you're confident in your architecture for the next 12-36 months. Use them for that.

But if you want to actually get your infrastructure spend under control, the work is different:

Audit where your money actually goes. Not the top-line number — the line items. Egress, data transfer, managed service fees, idle resources. You need to know the real composition of your bill before you can address it.

Evaluate workload fit. Some things belong on AWS. Lambda functions with unpredictable traffic spikes, services that need tight integration with AWS-native tooling, global distribution — these are reasonable cases. A database that runs 24/7 serving customers in one metro area? That's not a hyperscaler workload. You're paying hyperscaler prices for a predictable, regional workload.

Model the actual alternatives. Not just "AWS vs. Azure" — that's just trading one egress fee structure for another. Look at what the workload costs on infrastructure that doesn't charge for data movement. The math is often more dramatic than people expect.

Stop optimizing the wrong thing. A 40% reserved instance discount on 30% of your bill is a 12% total reduction. Eliminating egress fees on a data-heavy workload can be a 15-20% reduction by itself, with no commitment required.

The companies that actually get cloud costs under control aren't the ones who got most aggressive with reservations. They're the ones who questioned the assumption that every workload belongs on the same platform.

---

If your AWS bill has started feeling like a fixed cost you just accept rather than something you can actually control, it's worth pulling the actual line-item breakdown and looking at what reservations are and aren't touching. For workloads serving the Treasure Valley and Pacific Northwest — especially anything with data residency requirements or consistent regional traffic — we've seen the numbers come out significantly better on IDACORE infrastructure. If you want to run the comparison against your actual bill, get a cost breakdown from our team.