Solving the real ROI question behind moving off US hyperscalers

Why your hyperscaler exit math keeps failing finance review

You run the numbers on leaving AWS. Compute is cheaper elsewhere. Storage is cheaper elsewhere. Then finance asks about egress fees, migration hours, and cutover risk, and the whole business case falls apart. Sound familiar? This isn't a bad migration plan, it's a broken cost model.

Most engineers comparing hyperscaler costs against alternatives only look at list prices for compute and storage. That's maybe 40% of the real picture. Here's the rest of it, and a framework to fix your ROI math.

Why the comparison breaks down

Hyperscalers don't really compete on compute price. They compete on making it painful to leave. That's baked into the architecture, not just the contract.

Egress fees are the real anchor. AWS charges roughly $0.09/GB after the first GB out. For a platform pushing 50TB/month (video, API responses, backups, CDN pulls), that's about $4,500/month just to move data, before touching anything else. This fee isn't about bandwidth cost, bandwidth is cheap. It's a moat.

Managed services lock you in harder than compute does. If you're on RDS, DynamoDB, SQS, and Lambda, you're not renting VMs, you're depending on proprietary APIs. Migrating off means rewriting your data access layer, not just moving instances. This is the line item most spreadsheets underestimate by 3-5x.

Reserved instance pricing hides a bad assumption. Finance often compares a competitor's list price to a hyperscaler's 3-year reserved rate and calls it a win for the hyperscaler. But that rate assumes flat usage for 36 months. Most SaaS workloads have seasonal spikes and growth curves. A 3-year commitment is a liability wearing a discount's clothes.

Support cost is invisible until you actually need it. A named TAM tier starts around $15,000/month, and you're still in a ticket queue for anything real. Compare that to a partner where a senior engineer just picks up.

The fix: five cost categories, not one

1. Baseline 12 months of actual spend, not one month

aws ce get-cost-and-usage \
  --time-period Start=2024-11-01,End=2025-11-01 \
  --granularity MONTHLY \
  --metrics 'UnblendedCost' \
  --group-by Type=DIMENSION,Key=SERVICE

Break it into compute, storage, egress, managed services, support, and RI amortization. Egress alone is usually 8-15% of total spend for content-heavy platforms, and it almost never makes the first draft of a migration business case.

2. Model the actual migration cost

This means:

• Engineering hours to replace managed-service dependencies (DynamoDB to Postgres, Lambda to containers, SQS to self-hosted queues)
• One-time data transfer cost to move the dataset out
• Parallel-run cost during validation (typically 4-8 weeks)
• A downtime contingency line, even with a zero-downtime plan

For a mid-sized SaaS app with a 2TB database and 15 microservices, expect 200-450 engineering hours. At 80 euros/hour loaded cost, that's 16,000-36,000 euros, upfront. Put it in the model.

3. Recalculate egress under the new architecture

# AWS us-east-1 to internet: $0.09/GB after first 1GB free
# EU provider with peering to major IXPs: $0.01-0.02/GB typical

# 50TB/month egress:
# AWS: 50,000GB * $0.09 = $4,500/month
# EU provider: 50,000GB * $0.015 = $750/month
# Annual difference: $45,000

Colocate with your CDN's regional PoPs and egress typically drops 40-70%.

4. Swap proprietary APIs for open standards

This is the highest-leverage move in the whole exit. It's what makes the savings durable instead of a one-time discount you slowly erode by re-adopting vendor tooling:

• DynamoDB → PostgreSQL or self-managed MongoDB
• Lambda → containers on Kubernetes or Nomad
• SQS/SNS → self-hosted RabbitMQ or Kafka
• CloudWatch → Prometheus + Grafana

5. Cut over with zero downtime

Replicate continuously, run both environments in parallel, lower DNS TTL ahead of time, keep the old environment warm for at least one billing cycle.

# 48-72 hours before cutover
example.com.  300  IN  A  203.0.113.10

# Monitor both origins during cutover
curl -s -o /dev/null -w '%{http_code} %{time_total}s\n' https://old-origin.example.com/health
curl -s -o /dev/null -w '%{http_code} %{time_total}s\n' https://new-origin.example.com/health

For database-backed apps, run logical replication for days beforehand, not a single export/import window.

How to know it actually worked

Track these for at least two full billing cycles:

• Total spend vs. your 12-month baseline, normalized for traffic growth
• Egress as % of total spend (expect 8-15% → 2-4% with good peering)
• p95/p99 latency on your top 10 endpoints, before and after
• Error rate and uptime, 30 days before vs. 30 days after
• Engineering hours on infra ops per month

One sanity check that matters: if spend drops 30% but p99 latency degrades 25%, you haven't won anything. You've just shifted cost into a metric that'll eventually cost you conversions.

Full framework and migration mechanics in the original piece: Solving the real ROI question behind moving off US hyperscalers

Originally published on binadit.com