Your application had a great month. Traffic doubled. Users were happy. Then the AWS bill arrived.
That's the moment most infrastructure teams realize they never actually understood how cloud bandwidth pricing works. They understood compute. They understood storage. But egress? That line item was an afterthought — until it wasn't.
This post breaks down how bandwidth pricing models actually function, what "flat-rate" means versus what providers claim it means, and how to think about this before a traffic spike makes the decision for you.
How Egress Pricing Becomes a Trap
The hyperscaler model is built around a simple idea: getting data in is free, getting data out costs money. AWS charges $0.09 per GB for the first 10TB of outbound transfer per month. Azure and GCP are in the same neighborhood. That sounds manageable until you do the math on a real application.
Say you're running a healthcare SaaS platform with 500 active users pulling down reports, images, and API responses throughout the day. At 2GB of egress per user per month, you're at 1TB. Fine — that's $90. But that same platform at 5,000 users is 10TB, and now you're paying $900 just for data transfer before you've touched a single compute instance. Add CDN transfer costs, inter-region traffic for redundancy, and the egress between your application tier and your database tier if they're in different availability zones — and the number climbs fast.
The real trap isn't the base rate. It's that egress costs scale with your success. The better your product does, the more it costs to run. That's a genuinely bad incentive structure, and it's not an accident.
What "Flat-Rate Bandwidth" Actually Means
Flat-rate bandwidth gets marketed in a few different ways, and they're not all the same thing.
The most common version is a committed port speed with unmetered transfer. You pay for a 1Gbps port, and you can push as much traffic through it as the port allows, 24/7. No per-GB charges. This is the model traditional colocation and dedicated hosting providers have used for decades. It's predictable, it's honest, and it rewards you for actually using what you're paying for.
A second version is bandwidth pooling with a monthly cap. You get X TB per month included, and then pay overages. This is what most VPS providers do. It looks like flat-rate until you hit the cap, at which point it behaves exactly like metered pricing. Read the fine print.
A third version — the one hyperscalers occasionally advertise — is egress discounts at scale. AWS will negotiate reduced egress rates if you're spending enough. But "enough" means you're already locked in, already dependent, and already negotiating from a weak position.
At IDACORE, flat-rate means flat-rate. Your virtual server or dedicated instance comes with a committed port allocation and no per-GB billing. If your application has a traffic spike, your bill doesn't change. That's the entire point.
The Spike Scenario: What It Looks Like in Practice
Let me walk through a concrete scenario because the abstract math doesn't land the same way.
A regional e-commerce company — let's say they're based in the Treasure Valley, selling outdoor gear — runs their stack on AWS. Normal monthly egress is around 8TB. Their Black Friday weekend hits, traffic goes up 4x, and they push 12TB in 72 hours. For the month, they've done 28TB of egress.
AWS pricing for that month:
- First 10TB: $0.09/GB = $921.60
- Next 40TB tier: $0.085/GB = $1,530 for the remaining 18TB
- Total egress bill: ~$2,451
That's on top of their compute, storage, and everything else. In a normal month, they'd have paid maybe $820 in egress. The spike cost them an extra $1,600 — which came directly out of the margin on the sale they just ran.
On a flat-rate model with a 1Gbps port, that same traffic spike costs them nothing extra. The port can handle it. The bill doesn't move.
Now, I'm not suggesting that flat-rate is always the right answer for every workload. If your traffic is genuinely tiny and unpredictable, pay-as-you-go compute with low egress might be fine. But if you're running any kind of user-facing application with real traffic, you should be doing this math before you need to.
Latency Is Part of the Bandwidth Story
Here's something that gets missed in the pure cost conversation: latency affects how much bandwidth you actually need.
When round-trip time is high, TCP throughput suffers. This is basic networking — the bandwidth-delay product means a connection with 40ms RTT can't fill a pipe as efficiently as one with 5ms RTT. For most web applications, this shows up as slower page loads, more retries, and longer-lived connections that tie up server resources.
If you're running infrastructure in AWS's us-west-2 region in Oregon, you're looking at 20-40ms to Boise depending on the specific path. That's not catastrophic, but it's not nothing either — especially for applications doing a lot of small, synchronous requests.
From our data center in Weiser, Idaho, we're consistently under 5ms to the Boise metro. That's not a marketing claim — it's geography. We're 85 miles from Boise. The speed of light doesn't care about our pricing model.
The practical implication: lower latency means more efficient TCP connections, which means you're doing more useful work with the same bandwidth. It's not a dramatic effect for every workload, but for high-frequency API traffic or database-heavy applications, it compounds.
Building a Bandwidth Budget That Doesn't Lie to You
If you're evaluating infrastructure costs — whether you're moving off a hyperscaler or building something new — here's how I'd approach the bandwidth piece.
Start with your actual egress profile. Pull 90 days of bandwidth data if you have it. Look at average, p95, and peak. The average will make you feel good. The peak is what you're actually paying for under metered pricing.
Model your spike scenarios. What does a 3x traffic event look like? A 10x event? For most SaaS products, these happen — product launches, press coverage, seasonal demand. Your infrastructure cost model should include them.
Account for all egress, not just user-facing traffic. Backups leaving the cloud cost money. Log shipping to a SIEM costs money. API calls to third-party services that require a response payload cost money. Add it up.
Compare total cost of ownership, not sticker price. A $200/month VPS with metered bandwidth at $0.01/GB might look cheaper than a $350/month instance with flat-rate bandwidth — until you're pushing 20TB a month.
Here's a quick way to find your egress break-even point:
flat_rate_premium = flat_rate_monthly_cost - metered_base_cost
break_even_gb = flat_rate_premium / per_gb_rate
# Example:
# flat_rate_monthly_cost = $350
# metered_base_cost = $200
# per_gb_rate = $0.09
flat_rate_premium = 350 - 200 # $150
break_even_gb = 150 / 0.09 # ~1,667 GB or ~1.6TB
If you're consistently pushing more than 1.6TB of egress per month in this example, flat-rate is already cheaper — and that's before you factor in any spike months.
Don't forget egress in your SLA thinking. Under metered pricing, a DDoS attack or traffic anomaly doesn't just hurt your performance — it directly increases your bill. Flat-rate pricing means anomalous traffic is an operational problem, not a financial one.
Idaho Data Residency Changes the Calculation
One more factor that's relevant for a specific but growing set of workloads: data residency.
Healthcare organizations, financial services companies, and government contractors operating in Idaho increasingly need to demonstrate that their data stays in Idaho. Not "in the US" — in Idaho. That's a compliance requirement that hyperscalers can't actually satisfy. AWS's us-west-2 is in Oregon. Azure's West US 2 is in Washington. GCP's us-west1 is in Oregon. None of those are Idaho.
When you're running HIPAA-scoped workloads or handling sensitive state government data, egress costs aren't just a financial concern — they're a compliance vector. Every time data moves across a region boundary, you need to account for where it went and why.
Our infrastructure doesn't leave Idaho. That's not a configuration option or a policy setting — it's a physical fact. The servers are here, the network terminates here, and your data stays here. For organizations that need to demonstrate Idaho data residency, that's not a nice-to-have. It's the whole game.
If you're running a user-facing application in the Treasure Valley and you've never actually modeled your egress costs against a flat-rate alternative, it's worth 30 minutes of your time. We've helped teams cut their monthly infrastructure spend by 30-40% just by moving off hyperscaler egress billing — and for healthcare and compliance-sensitive workloads, the data residency piece closes the deal before we even get to the pricing conversation. If you want to run the numbers on your actual traffic profile, talk to someone who's done this before — not a sales rep reading from a pricing sheet.
