The AWS geography tax: why São Paulo costs 59% more than Virginia

Published November 10, 2025

A single m6g.xlarge instance gives you 4 vCPUs and 16 GiB of memory powered by AWS Graviton2 silicon. The server rack in North Virginia runs the exact same custom Annapurna processor as the rack in São Paulo, Tokyo, or Mumbai. The operating system image is identical. The performance characteristics are identical.

The invoice at the end of the month is not.

In US East (us-east-1), an on-demand Linux m6g.xlarge runs $0.1540 per hour ($112.42 per month). Launch that same instance in São Paulo (sa-east-1), and AWS bills you $0.2448 per hour ($178.70 per month)—a 59% premium for the same compute capacity.

Move across the globe to India, and the price swings in the opposite direction. In Mumbai (ap-south-1) and Hyderabad (ap-south-2), an m6g.xlarge drops to $0.1012 per hour ($73.88 per month), a 34% discount against the Virginia baseline.

Here is what the regional spread looks like across AWS’s global footprint, why geographical pricing disparities persist, and how to evaluate the tradeoff between round-trip latency and your cloud bill.

The global pricing spectrum

Across the 38 regions where AWS offers Graviton instances, hourly compute prices fall into distinct regional tiers.

The table below breaks down on-demand Linux pricing for m6g.xlarge and the newer Graviton3 m7g.xlarge, indexed against the standard US baseline (us-east-1):

You can explore pricing across all instance families and region combinations in our regional pricing directory and the instance explorer.

Why identical hardware costs different amounts

Cloud infrastructure feels abstract, but data centers are physical facilities subject to local real estate costs, power tariffs, tax jurisdictions, and supply chains. Several concrete factors explain the price variations.

1. Import tariffs and national taxes

The 59% price jump in São Paulo (sa-east-1) is primarily driven by Brazilian tax and trade policy rather than power or real estate costs.

Brazil imposes heavy import tariffs and indirect taxes on imported technology hardware. When AWS imports servers, switches, and optics into Brazil, the equipment is subject to multiple federal and state taxes:

• II (Imposto de Importação): Federal import tariff on foreign hardware.
• IPI (Imposto sobre Produtos Industrializados): Tax on manufactured goods.
• PIS / COFINS: Federal social integration and security revenue contributions applied to imports.
• ICMS (Imposto sobre Circulação de Mercadorias e Serviços): State value-added tax that compounds on top of the base import valuation.

Combined, these import fees can increase the landed capital expense of a server rack by 60% to 100% compared to deploying the same equipment in Virginia or Oregon. AWS amortizes that elevated capital expenditure directly into hourly runtime rates.

2. Energy and cooling costs

Running compute clusters requires megawatts of power for the silicon itself and additional energy for facility chillers and heat exchange systems.

• Low-cost power: Regions located near abundant hydroelectric generation or mature industrial grids (such as us-west-2 in Oregon or eu-north-1 in northern Sweden) benefit from industrial electricity rates as low as $0.04 to $0.07 per kilowatt-hour.
• High-cost power: Regions in dense metro centers or island grids (such as Tokyo, Singapore, and Frankfurt) face grid rates exceeding $0.20 to $0.30 per kWh, alongside higher cooling overhead in tropical climates.

3. Real estate and construction overhead

Building an Availability Zone requires massive parcels of land with diverse power feeds and redundant fiber rights-of-way. Buying land and securing industrial construction permits in Zurich, London, or Hong Kong costs multiples of what it takes to build a facility in rural Ohio or Virginia.

4. Regulatory compliance and specialized operations

Regions with specialized security or sovereignty boundaries require distinct operational setups:

• AWS GovCloud (us-gov-east-1 and us-gov-west-1): Subject to a ~26% premium. These facilities are restricted to US citizens on US soil and maintain strict compliance with ITAR, FedRAMP High, and DoD Impact Level 5 requirements.
• Zurich (eu-central-2): Carries a 31% premium driven by Swiss operational wage standards, strict banking data privacy mandates, and premium regional energy costs.

The storage and networking premium

The geography tax is not limited to virtual machines. Supporting infrastructure services mirror or exceed the compute markup.

Examining storage pricing reveals that EBS block storage incurs an even steeper penalty in high-cost regions:

• General Purpose SSD (gp3) in us-east-1: $0.080 per GB-month.
• General Purpose SSD (gp3) in eu-west-1 (Ireland): $0.088 per GB-month (+10%).
• General Purpose SSD (gp3) in eu-central-2 (Zurich): $0.1142 per GB-month (+43%).
• General Purpose SSD (gp3) in sa-east-1 (São Paulo): $0.152 per GB-month (+90%).

Provisioned IOPS above the free 3,000 baseline on gp3 cost $0.005 per IOPS-month in Virginia, but jump to $0.0095 per IOPS-month in São Paulo—a 90% increase.

If your workload runs 100 TB of gp3 storage with provisioned throughput, running in Brazil costs $15,200 per month for raw block volume capacity compared to $8,000 in North America.

Latency vs. cost: the architectural dilemma

When designing systems for international users, regional price spreads force an explicit architectural tradeoff: network latency versus operational expense.

Consider an engineering team serving users across Brazil and Argentina:

• Hosting in São Paulo (sa-east-1): End users experience 15ms to 35ms round-trip latency. Compute runs at a 59% premium and storage at a 90% premium.
• Hosting in Northern Virginia (us-east-1): End users experience 110ms to 140ms round-trip latency over subsea fiber routes. Compute and storage run at baseline pricing.

+--------------------------------------------------------------------+
|                      Latency vs. Cost Tradeoff                     |
+--------------------------------------------------------------------+
|  Option A: Local Deployment (sa-east-1)                            |
|  User (SP/BA) <--- 20ms ---> [ EC2 + EBS + RDS (sa-east-1) ]       |
|  Cost: +59% Compute, +90% Storage                                  |
+--------------------------------------------------------------------+
|  Option B: Edge Cached + US Origin (us-east-1)                     |
|  User (SP/BA) <-- 15ms --> [ CloudFront POP ] <-- 120ms --> [ App ]|
|  Cost: Baseline pricing + Data Transfer                            |
+--------------------------------------------------------------------+

When to stay in the cheap region

For many standard web and API workloads, full regional deployment in high-cost zones is wasteful:

1. Static and read-heavy dynamic sites: Putting a CloudFront distribution in front of an origin in us-east-1 delivers sub-20ms cached asset delivery in South America via local edge Points of Presence (POPs) in São Paulo, Rio de Janeiro, and Fortaleza, while keeping your databases and app servers on US pricing.
2. Asynchronous batch processing and analytics: Background queues, extract-transform-load (ETL) pipelines, model training, and log indexing have no user-facing latency requirements. Running batch pipelines in sa-east-1 or eu-central-2 burns budget with zero user benefit.
3. Internal tooling: Backoffice dashboards, internal APIs, and developer staging environments rarely justify a 59% geographical markup.

When the geography tax is mandatory

There are three scenarios where paying the regional premium is unavoidable:

1. Data residency and regulatory compliance: Legal frameworks such as Brazil’s LGPD, South Africa’s POPIA, or Swiss financial privacy laws often mandate that specific customer records and financial ledgers never leave national borders.
2. Interactive, write-heavy applications: Real-time collaborative tools, online gaming servers, and financial execution engines cannot tolerate an extra 120ms round-trip penalty on write requests.
3. High-frequency internal chatter: Microservice architectures that perform dozens of sequential synchronous network hops between services per user request. If a single page load triggers ten serial backend calls, a 120ms cross-region latency accumulates into a 1.2-second delay.

Managing the regional spread

If compliance or latency requirements require operating inside high-cost regions like São Paulo, Zurich, or Tokyo, mitigate the baseline markup with deliberate instance choices:

1. Adopt Graviton over x86: An m6g.xlarge in São Paulo ($0.2448/hr) is roughly 20% cheaper than an Intel m5.xlarge in that same region ($0.3040/hr). Switching architectures offsets a substantial portion of the regional tax.
2. Keep storage lean: Use gp3 rather than older gp2 volumes, rightsize provisioned IOPS, and aggressively tier inactive data to S3 Standard-IA or Glacier.
3. Split compute and data: Keep the primary database in the required regional zone while running asynchronous workers and data warehousing in lower-cost adjacent regions if data transfer rules allow.

Check current pricing and regional availability for all instance families in our instance explorer before locking in multi-region infrastructure plans.