How much does AWS region actually change your bill?

Published June 18, 2026

Run the same instance type in Sao Paulo instead of Virginia and you’ll pay 57 to 60% more per hour. That’s the difference between a $1,000/month fleet and a $1,580/month one, for identical hardware, zero code changes, zero migration effort beyond picking a different dropdown.

So if nothing about your workload actually requires a specific region (no users clustered nearby, no data residency law, no latency budget measured in milliseconds), is chasing the cheapest region free money? Mostly no, but the reasons why are more specific than “network costs eat the savings.” This guide works through the real spread in our pricing data, what’s driving it, and where the savings get clawed back, so you can tell the difference between arbitrage and a false economy. 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.

The real spread

Pulled straight from the pricing dataset, on-demand Linux, filtered to standard AWS regions (no Local Zones, Wavelength, or GovCloud, which push the range even wider):

Two things jump out. First, the spread clusters around 57 to 62% for most instance types, well past the “prices vary slightly by region” impression AWS’s own docs give. Second, c7g.xlarge breaks the pattern: Mumbai beats Virginia there by a wide margin, and the top-to-bottom spread more than doubles. Worth a closer look before assuming a rule of thumb holds.

Is us-east-1 actually always cheapest?

Mostly, but not always. Checking six common instance types across every standard region:

• m7i.xlarge, m6i.xlarge, r6i.large, t3.medium: us-east-1 is the outright cheapest region, tied with us-east-2 and us-west-2 to the fraction of a cent.
• c7g.xlarge: ap-south-1 and ap-south-2 (Mumbai and Hyderabad) both undercut us-east-1, $0.0982/hr against $0.145/hr. us-east-1 ranks 6th out of 32 regions for this instance.
• c7i.xlarge: ap-southeast-5 and ap-southeast-7 (Malaysia and Thailand) edge out us-east-1, $0.17494/hr against $0.1785/hr. us-east-1 ranks 5th out of 33.

“us-east-1 is cheapest” is a good prior, not a guarantee. It holds for most Intel/AMD (x86_64) families in our data, and breaks for some Graviton (arm64) families, where AWS’s newer, higher-capacity Asia-Pacific regions occasionally undercut it. If your workload can already run on arm64, see Graviton vs. x86, then check the actual number for your instance type on its detail page rather than assuming Virginia wins by default.

What’s completely consistent across every instance type checked here: sa-east-1 (São Paulo) is the most expensive standard AWS region, every time, by a wide margin. af-south-1 (Cape Town), ap-east-1 (Hong Kong), and eu-central-2 (Zurich) round out the expensive end consistently too. This tracks infrastructure age and volume more than geography: US regions and established Asia-Pacific hubs (high capacity, older infrastructure investment, denser competition) sit at the cheap end, while newer or lower-volume regions across South America, Africa, the Middle East, and some smaller Asia-Pacific markets sit at the expensive end. AWS’s per-region pricing broadly tracks local infrastructure cost and utilization, not a flat global markup.

What “not latency-pinned” actually means

Before treating the spread above as pure upside, be honest about what “my workload isn’t pinned to a region” is actually claiming. 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:

Inbound transfer is priced at $0/GB across the board; AWS doesn’t charge to bring data in. The charge is entirely on the outbound side, and it 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 instance price difference is a one-time fact you look up once. The cross-region transfer bill is a new recurring line item that keeps accruing for as long as the split architecture exists. It only stops being a bill if you move everything, compute, storage, database, together, which is a materially bigger project than re-pointing an Auto Scaling Group at a new region.

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: the spread is real and often larger than intuition suggests, roughly 57 to 60% between the cheapest and most expensive standard region for most instance types, sometimes over 100% for specific arm64 families. us-east-1 is usually but not always the cheapest option, so check the actual number for your instance type rather than assuming it. The number that decides whether to chase it isn’t the compute discount. It’s what stays behind, and what it costs per GB to keep talking to it.