What Hyperscaler Migration Guides Don't Tell You About Egress Costs

Every cloud migration guide starts the same way: estimate your compute, right-size your instances, pick a region, and start moving workloads. AWS, Azure, and GCP all publish detailed migration frameworks. They have checklists, cost calculators, and professional services teams ready to help you through the process.

What they don't have is a section titled "here's how we'll charge you to get your data back."

Egress fees are the most consistently underestimated line item in cloud migration TCO, and the hyperscalers' own migration tooling is designed to help you move in, not think clearly about what it costs to operate once you're there. I've talked to enough infrastructure teams in the Treasure Valley and across the Pacific Northwest to know that this isn't a niche problem. It's nearly universal.

---

The Calculator Shows What They Want You to See

AWS has a pricing calculator. Azure has one too. They're genuinely useful for estimating compute and storage costs. But watch what happens when you try to model egress.

The AWS calculator will show you data transfer costs if you manually add them. What it won't do is prompt you to think about all the ways data leaves your VPC in normal operations: API responses to end users, replication between availability zones, traffic between services in different regions, backups going to S3 from EC2, CloudFront origin fetches, database read replicas pulling from primary instances across AZ boundaries.

That last one surprises people. Traffic between availability zones within the same AWS region costs $0.01/GB in each direction. That's not a lot per gigabyte, but a busy application doing 50TB of cross-AZ traffic per month — which is not unusual for a distributed system — is paying $500/month just for that. Not for storage. Not for compute. For moving data between two buildings that are probably within 20 miles of each other.

The migration calculator you filled out didn't include that number, because you didn't know to put it in.

---

How the Real Bill Gets Built

Let me walk through a realistic scenario. A healthcare SaaS company migrates from a regional colo to AWS us-west-2 (Oregon). They have:

• A web application tier serving ~10TB of data per month to end users
• A backend API layer that moves another 8TB internally
• A PostgreSQL cluster with a read replica in a second AZ
• Nightly backups to S3
• CloudWatch logs and metrics

Here's what their egress math actually looks like:

Internet egress (first 10TB): $0.09/GB = $921.60
Internet egress (next 40TB, at scale): $0.085/GB = varies
Cross-AZ data transfer (DB replication, ~5TB/mo): $0.01/GB x 2 = $102.40
CloudFront origin fetches (if using CDN): $0.0085–$0.02/GB
Data transfer to S3 from EC2 (same region): free
S3 to internet (backups, exports): $0.09/GB

They estimated $1,200/month in data transfer costs based on the calculator. Their actual first bill showed $3,800. The difference was cross-AZ replication they hadn't modeled, CloudFront origin traffic they didn't anticipate, and a misconfigured logging agent that was shipping 2TB of verbose debug logs to CloudWatch every month.

That CloudWatch line item alone was $300/month. For logs they never looked at.

---

The Architecture Decisions You Make Early Will Cost You Later

Here's the part the migration guides really skip: egress costs aren't just a billing problem. They're an architecture feedback mechanism, and if you're not thinking about them before you design your cloud infrastructure, you'll end up paying for decisions that are expensive to reverse.

The most common trap is building a multi-region architecture because it sounds like the right thing to do for resilience, without actually modeling the data transfer costs between regions. AWS charges $0.02/GB for inter-region transfer. If you're running active-active across us-west-2 and us-east-1 and moving 20TB/month between them for replication, that's $400/month just for the pipe — before you've paid for any compute in the second region.

Another one: using managed services that quietly generate egress. RDS Multi-AZ deployments replicate synchronously across AZs. That replication traffic costs money. ElastiCache clusters in cluster mode move data between shards. API Gateway passes every request and response through AWS infrastructure, and while inbound is free, responses going back to clients count as egress.

None of this is hidden exactly — it's all in the pricing pages if you know to look. But the migration guides don't connect these dots for you, because connecting those dots might make you reconsider the migration.

---

What a Real TCO Calculation Looks Like

If you're doing a genuine TCO comparison — not a "how do we justify this to the board" exercise, but an actual engineering analysis — you need to account for these categories:

Data gravity costs. Where does your data live today, and where do your users and systems need to access it from? If you're a Boise-based company moving to AWS Oregon, you're adding 20-40ms of latency to every database query from your local systems. That's not just a performance issue — it affects how you architect caching layers, which affects how much data moves, which affects egress.

Operational data movement. Backups, log shipping, metrics, monitoring agents, deployment pipelines — all of this moves data. Estimate it before you commit to a pricing model.

Exit costs. This is the one nobody models. What does it cost to leave? AWS charges $0.09/GB to move data out to the internet. If you have 100TB of data and decide in two years that you want to move to a different provider or back to colo, that's a $9,000 exit fee just for the transfer — before you've paid for the engineering time to actually do the migration.

Support costs. AWS support plans start at 10% of your monthly bill for Business tier. On a $15,000/month bill, that's $1,500/month for support that routes through a ticket system. That's not the same as calling someone who actually knows your infrastructure.

I ran an ISP for years. I know what a real support call looks like — it's someone on the phone who can pull up your config, see what changed at 2am, and tell you in plain language what broke. That's not what you get with hyperscaler support at the Business tier.

---

The Idaho Angle Is Actually About Physics

There's a reason companies in Boise and the Treasure Valley keep ending up on AWS Oregon despite it not being the obvious choice on paper. It's the closest major AWS region. But "closest" is relative — us-west-2 is still 500+ miles away, and you're sharing that infrastructure with every other company in the western US.

Sub-5ms latency to a local data center versus 20-40ms from Oregon isn't just a performance number. It changes what your application architecture can look like. You can make synchronous database calls that would be too slow over a 35ms connection. You can run tighter timeouts. You can skip caching layers you'd otherwise need to compensate for the distance.

For a healthcare application with strict data residency requirements, the Idaho angle is also about compliance. Data that doesn't leave the state doesn't create the same audit surface as data moving through AWS's multi-tenant Oregon infrastructure. That matters for HIPAA risk assessments, and it matters for the conversations you have with your compliance team about where patient data actually lives.

---

Before You Sign the Enterprise Agreement

If you're in the middle of a hyperscaler migration evaluation, here's what I'd actually do before committing:

1. Pull 90 days of network flow logs from your current environment and categorize traffic by source/destination. This is the only way to get accurate egress estimates.
2. Build your architecture diagram first, then price every data flow — not just compute and storage.
3. Model the exit scenario. What does it cost to leave in 18 months if the bill is higher than projected?
4. Get a real number for support. Don't count on the free tier being adequate for production infrastructure.
5. Compare the total number, not the compute number. Compute is usually where hyperscalers are competitive. Everything around it is where the margin is.

The migration guides are written to get you to yes. Your job is to get to an accurate number before you commit.

---

If you're running a cost comparison for a Boise-area workload and want to see what flat-rate pricing without egress fees actually looks like on your specific traffic profile, talk to our infrastructure team about running the numbers — we'll work through the TCO with you directly, not through a sales cycle.