Why Your AWS Bill Keeps Growing Even When Your Traffic Doesn't

You audit your application logs. Traffic is flat. CPU utilization hasn't budged. You haven't provisioned a single new instance this quarter. And yet your AWS bill is 15% higher than it was six months ago. Sound familiar?

This isn't a mystery. It's by design.

Hyperscaler pricing is architecturally complex in ways that make costs grow passively — without any change in your actual workload. I've watched companies burn through budget increases year over year while their infrastructure needs stayed essentially static. The bill grows because the billing model is built to grow. Understanding exactly how that works is the first step to stopping it.

---

Egress Fees Are a Tax on Your Own Data

Let's start with the one that catches everyone off guard the first time.

AWS charges you to move data out of their network. Not into it — out. Every time your application serves a response to a user, every time you pull a backup to an off-site location, every time you replicate data to a non-AWS system, you're paying egress fees. The rate varies by region and volume, but you're typically looking at $0.09 per GB for the first 10TB out of us-east-1, dropping slightly at higher tiers.

That sounds manageable until you do the math on a real workload. A SaaS application serving 5TB of data per month to end users is paying roughly $450/month just in egress — before a single compute instance, storage bucket, or database query. Scale that to 50TB and you're at $4,000+ per month in fees that have nothing to do with your compute capacity.

The particularly frustrating part is that this cost grows with your success. More users, more egress. More API calls, more egress. Grow your business and your egress bill grows with it, even if your infrastructure footprint stays identical. There's no equivalent on-premises cost. There's no equivalent at a provider that doesn't charge for outbound traffic.

We don't charge egress fees at IDACORE. That's not a footnote — it's a structural difference in how the pricing model works.

---

Idle Resources You Forgot About Three Months Ago

Here's a scenario I've seen play out more times than I can count. Your team spins up a dev environment for a project in Q1. The project wraps up in Q2. The environment doesn't get torn down because nobody owns that cleanup task, and it's not causing any visible problems. By Q4, you've got four of these ghost environments running.

Each one is paying for:

• Reserved or on-demand instance hours
• Attached EBS volumes (which bill whether or not the instance is running)
• Elastic IPs that aren't associated with a running instance ($0.005/hour — small, but it adds up)
• Snapshot storage from automated backups of volumes nobody needs anymore

AWS doesn't tell you this is happening. There's no alert that says "this environment has had zero traffic for 90 days." The billing dashboard shows you line items, not context.

A practical way to catch this is to run a cost allocation report filtered by last-accessed date on your EBS volumes and S3 buckets. For EC2, look at CloudWatch metrics for instances with CPU utilization under 2% over a 30-day period. You'll find things.

# List EBS volumes not attached to any instance
aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[*].{ID:VolumeId,Size:Size,Created:CreateTime}' \
  --output table

That command alone has saved teams hundreds of dollars a month just by making the problem visible.

---

The Reserved Instance Trap

Reserved Instances are AWS's answer to the question "how do we get customers to commit to spending before they know what they'll need?" You pay upfront or commit to a 1-3 year term in exchange for a discount off on-demand pricing. The pitch is compelling — up to 72% savings.

The problem is that RIs are tied to specific instance types, regions, and sometimes operating systems. When your architecture evolves — and it will — those reservations don't evolve with it. You end up with reservations for m5.xlarge instances when you've migrated to m6i.xlarge. You've got us-west-2 reservations after you decided to consolidate in us-east-1. The reservations keep billing. The discount you're getting is on capacity you're not using.

AWS has improved RI flexibility over the years with Convertible RIs and Savings Plans, but the fundamental issue remains: you're making financial commitments to a platform that changes its instance types, pricing, and recommended architectures faster than most teams can track. The complexity of optimizing RI coverage is a job in itself — some companies hire people specifically to manage it.

Compare that to flat monthly pricing where you know what you're paying for a given configuration and that number doesn't change based on whether you chose the right commitment tier eighteen months ago.

---

Support Tiers That Charge You to Ask Questions

This one doesn't show up in infrastructure cost analyses, but it's real money.

AWS's free support tier gives you access to documentation and community forums. If you want to talk to an actual engineer, you're starting at $29/month for Developer support — which gets you business-hours email access. Business support, which gives you 24/7 access and response time SLAs, starts at the greater of $100/month or 10% of your monthly AWS charges.

If you're spending $30,000/month on AWS infrastructure, you're paying $3,000/month just to have someone respond to your support tickets with reasonable urgency. That's $36,000/year for support that, in my experience, often means waiting for a tier-1 rep to read from the same documentation you already checked.

I've been on both sides of infrastructure support calls. There's a difference between talking to someone who has actually managed BGP routing tables and peered at an internet exchange, and talking to someone working through a decision tree. The former can tell you what's actually wrong. The latter escalates.

At IDACORE, support is handled by the same team that built and operates the infrastructure. When you call with a problem, you're talking to someone who knows the network topology because they designed it. That's not a selling point — it's just how a small operator with 30 years of experience works.

---

Why "Optimizing" AWS Costs Is a Full-Time Job

There's an entire ecosystem of third-party tools — CloudHealth, Spot.io, Apptio Cloudability — built specifically to help you understand and reduce your AWS bill. The existence of this ecosystem tells you something important: the problem is big enough and persistent enough that companies will pay for additional software to manage costs on software they're already paying for.

AWS itself has Cost Explorer, Trusted Advisor, and Compute Optimizer. These are genuinely useful tools. But using them well requires dedicated time, expertise, and ongoing attention. Every architecture change potentially creates new cost implications. Every new AWS service you adopt comes with its own pricing model to understand.

This is the hidden cost that rarely shows up in the initial "cloud migration will save us money" analysis. The operational overhead of managing a hyperscaler relationship — understanding pricing, optimizing reservations, auditing idle resources, managing support tiers — is real engineering time that could be spent on your actual product.

A healthcare SaaS company we work with moved their non-PHI workloads to IDACORE after spending six months trying to get their AWS costs under control. Their previous bill was running $40,000/month. They'd hired a cloud cost consultant for $8,000 to audit the environment. The consultant found savings, but implementing them required architecture changes that took another quarter. By the time they finished the optimization project, they'd spent more on the effort than they'd saved in the first year.

Their comparable workload at IDACORE runs $26,000/month. Flat. No reserved instance strategy to manage. No egress fees eating into the savings. No support tier surcharge. The data stays in Idaho, which matters for their compliance posture even on the non-PHI side.

---

What to Actually Do About It

If you're staying on AWS, the highest-ROI actions are:

1. Audit unattached EBS volumes and unused Elastic IPs. The script above is a starting point. These are pure waste.
2. Set up billing alerts at 80% and 100% of expected monthly spend. You want to know about anomalies before the invoice arrives.
3. Review your RI coverage quarterly. Mismatched reservations are money you've already committed to spending on nothing.
4. Tag everything. Cost allocation by team, project, or environment is impossible without consistent tagging, and without it you can't have the internal conversations that lead to cleanup.

If you're evaluating alternatives, the question to ask any provider is simple: what does my bill look like if my traffic doubles? At IDACORE, the answer is straightforward — your compute and storage costs scale, and that's it. No egress multiplier. No support tier recalculation. No pricing complexity that requires a consultant to navigate.

---

If the scenario in this article sounds like your last three quarterly reviews, it might be time to run the actual numbers on what a comparable workload costs outside of a hyperscaler. We're 85 miles from Boise, your data stays in Idaho, and we can put together a specific cost comparison for your actual workload — not a generic calculator estimate. Get a real cost breakdown for your infrastructure.