How much does AWS region actually change your bill?

Published June 18, 2026 · Updated October 17, 2026

Run the same instance type in São Paulo instead of Virginia and you’ll pay 59% more per hour on compute alone. Attach a GP3 volume and that storage costs 90% more. Route traffic through a NAT Gateway and the hourly rate doubles. That’s the difference between a $1,000/month workload and a $1,850/month one, for identical hardware, zero code changes, zero migration effort beyond picking a different dropdown.

The advice “just check your region’s pricing” is correct but useless without real numbers across real services. This guide prices three things every production workload uses (an EC2 instance, block storage, and a NAT Gateway) across every standard AWS region, then works through what that means for architecture decisions. For the pricing tool itself, see the instance explorer, where every instance’s detail page carries a full regional pricing matrix; for what a specific region carries end to end, see the per-region instance browser.

Three metrics, every standard region

We picked three items that show up on nearly every AWS bill:

1. m6i.xlarge: 4 vCPU, 16 GiB, Intel Ice Lake, Linux, on-demand. The workhorse general-purpose instance.
2. GP3 storage: the default EBS volume type, price per GB-month at baseline (3,000 IOPS, 125 MB/s included).
3. NAT Gateway hourly rate: the fixed charge for running a NAT Gateway, before any per-GB data processing fees.

All prices are from AWS’s August 2026 price list. Baseline is us-east-1 (N. Virginia). Every number is on-demand, no commitments.

This guide prices a fixed three-item basket so every region can be compared on identical items. To price a basket that matches your own footprint instead — your region pairs, your instance counts, your storage and egress volumes — use the region cost comparison tool.

The full table

The markup is not uniform across services

A region doesn’t carry one markup. Each service has its own pricing geography, and they sometimes diverge sharply.

Geographic summary

Average premium over us-east-1 by region group, across all three metrics:

Three regions break from their geographic group so consistently they deserve their own line: Zurich carries the highest storage markup in Europe, Hong Kong runs the most expensive NAT Gateway in APAC, and São Paulo costs 59% to 107% more than Virginia depending on the metric.

What the numbers actually show

Storage markups are wider than compute markups. São Paulo’s EC2 premium is +59%, bad but predictable for the region. Its GP3 premium is +90%, half again worse. Zurich is +32% on compute but +43% on block storage. If your workload is storage-heavy (databases, data lakes, media processing), the bill impact of region choice is larger than compute-only estimates suggest.

NAT Gateway pricing swings the hardest. The NAT Gateway hourly rate in São Paulo is $0.093/hr versus $0.045/hr in Virginia, a 107% premium that more than doubles the base rate. Tokyo runs +38%, Hong Kong +44%. The per-GB data processing charge follows the same pattern. Any architecture that routes significant traffic through NAT gets hit twice: once on the fixed hourly charge, again on every gigabyte processed.

Mumbai is cheap for compute, expensive for networking. Mumbai’s m6i.xlarge costs only 5% more than Virginia, one of the cheapest regions in the table. But its NAT Gateway rate is +24%, the single highest NAT premium of any region with a sub-10% compute markup. If you’re running a microservices architecture with many internal NAT-routed calls, Mumbai’s networking costs can dwarf what you saved on instance hours.

us-west-1 (N. California) is not a cheap US region. It carries a 17% compute premium, 20% storage premium, and 7% NAT premium over Virginia, which is worse than Stockholm, Ireland, and several APAC regions. If you’re in the US West and have no latency requirement for California specifically, us-west-2 (Oregon) is identically priced to Virginia.

Stockholm is the cheapest European region by a wide margin. At +4% average premium, its uplift is about a quarter of Frankfurt’s (+18%), and it’s cheaper than every other EU region. If your workload needs to be in Europe for GDPR compliance but doesn’t require a specific country, Stockholm saves 10 to 14 percentage points of markup compared to Paris or Frankfurt.

Is us-east-1 actually always cheapest?

For these three metrics, yes. us-east-1, us-east-2, and us-west-2 are tied at exactly the same price on all three items: $0.192/hr, $0.08/GB-month, $0.045/hr.

This isn’t universally true for every instance type. As covered in detail in the Graviton vs. x86 guide, some arm64 instance families (like c7g.xlarge) are cheaper in Mumbai and Hyderabad than in Virginia. But for the x86 Intel instance measured here and for storage and networking, Virginia/Ohio/Oregon is the baseline.

What “not latency-pinned” means

Before treating the spread above as pure upside, check what “my workload isn’t pinned to a region” claims. Two things have to both be true:

1. Your users don’t care which region serves them, or you’re already serving them through a CDN/edge layer that hides the origin’s location.
2. Nothing else in your architecture is anchored to the current region: no RDS instance, no S3 bucket holding warm data, no VPC peering to another account, no compliance boundary that says data-at-rest stays in a given country.

If the first isn’t true, say a low-latency API serving mostly EU traffic from eu-west-1, the discount from moving to us-east-1 is real on the compute line, but you’re trading it for round-trip latency to every request. A user in Frankfurt talking to Virginia instead of Ireland picks up roughly 80 to 100ms of additional round-trip time versus 10 to 15ms locally. For a batch job or an internal API that’s irrelevant. For a synchronous user-facing request, that’s often the whole latency budget gone before your application does any work.

If the second isn’t true, read the next section. That’s where “cheaper region” quietly turns into “cheaper compute, plus a new recurring bill you didn’t have before.”

The cost that doesn’t show up on the instance price

Moving compute to a cheaper region doesn’t move the rest of your stack with it. Anything that stays behind (a database, an object store, another service your app calls) now talks to your compute across a region boundary, and that traffic is metered. Real inter-region rates from the pricing data, per GB, all under Data Transfer in the networking pricing reference:

AWS doesn’t charge for inbound transfer ($0/GB). The charge lands on the outbound side and scales with distance: same-continent hops run $0.02/GB, transoceanic hops run $0.09 to $0.16/GB.

Run the numbers before you move. An application server doing a modest 500GB/month round trip to a database left behind in the old region adds $10 to $80/month depending on the path, every month, indefinitely. A chattier service, one making many small cross-region calls per request instead of one bulk sync, pays the same per-GB rate but also picks up the same latency penalty described above on every call, since the traffic is now crossing a real physical distance instead of staying in one AWS region’s local network.

The decision checklist

Work through this in order. A “no” on data residency stops the process entirely; the others are about whether the arbitrage is worth collecting.

1. Is there a legal or contractual reason data has to stay in a specific country or region? GDPR data residency clauses, government contracts, industry-specific regulation. If yes, your region choice is fixed regardless of price, and you can stop here.
2. Does the workload serve end users who care about latency? Check current p50/p95 response times. If users are already 60ms+ from your region, moving further away costs you response time you may not have to spend. If they’re on a CDN or the workload is internal/batch, this doesn’t apply.
3. What else lives in the current region that this workload talks to? List every database, cache, queue, and bucket it touches per request. Each one that stays behind becomes a cross-region transfer line using the networking pricing reference rates above. Price it out before moving, not after the bill arrives.
4. Is the discount big enough to survive the move cost? Check your actual instance type’s regional pricing matrix on its detail page. Some instance families see 60%+ spread; others, particularly Graviton families where APAC regions already beat us-east-1, offer less room to gain by moving away from Virginia specifically. A 5% spread isn’t worth an infrastructure migration; a 55%+ spread on a large, steady-state fleet usually is.
5. Are there compensating non-price factors in the current region? Newer instance generations, GPU availability, and specific managed-service features sometimes roll out to us-east-1 and a handful of others first. Confirm your target region actually offers everything you use by checking the per-region instance browser for that region before committing, not after.

Making the call

Clear yes. Stateless, compute-heavy batch or internal workloads with no user-facing latency requirement, no regulatory pin, and nothing left behind to pay cross-region transfer on. Move the whole stack, compute and storage together, to the cheapest viable region and collect the full 55 to 60% spread most x86 families show against São Paulo-tier pricing, or whatever the real spread is for your instance type.

Worth pricing out carefully. Workloads where most of the stack moves but one or two dependencies (a legacy database, a partner integration) stay behind. Run the transfer-volume math from the checklist before committing; if the monthly transfer bill is under maybe a fifth of the compute savings, it’s still a clear win.

Stay put. User-facing services with a real latency budget, anything under data residency obligation, or workloads where the “cheaper” region doesn’t actually undercut your current one once you check the real number. c7g.xlarge in us-east-1 is a good example of a family where the assumption “just move to Virginia” is backwards.

Bottom line: between Virginia and São Paulo the spread is roughly 59% on compute, 90% on storage, and 107% on networking. Whether to chase it depends on what stays behind and what it costs per GB to keep talking to it.

Next steps

• Price your own workload across regions →: pick the regions you run in and a candidate, enter your instance counts and volumes, and see the same basket priced line by line in each
• Compare specific instance types → to find the right size for your workload
• Explore all regions → for the full region catalog with availability details
• Check EBS pricing →: storage costs vary by region too, and they add up
• See how markups split by service →: the same analysis expanded to include RDS, ElastiCache, DynamoDB, and S3