AWS Global Infrastructure Explained: Regions, Availability Zones, Local Zones and Edge (2026)

AWS global infrastructure is the physical footprint everything else runs on: data centres grouped into Availability Zones, Availability Zones grouped into Regions, plus a set of edge and on-premises extensions that bring compute closer to users or into your own building. Understanding the hierarchy is the difference between an architecture that survives a data-centre failure and one that only looks like it does.

This guide explains each layer, how to choose a region, what multi-region really costs, and the patterns we use for clients who need resilience and compliance across the UK, US, Europe, the Gulf, Asia-Pacific and India.

The hierarchy: Regions, Availability Zones, data centres

A Region is a geographic area with its own cluster of data centres, its own set of AWS services, its own pricing and, for most services, its own isolated control plane. us-east-1 (N. Virginia), eu-west-2 (London), ap-south-1 (Mumbai) and me-central-1 (UAE) are regions. As of 2026 AWS operates well over 35 regions worldwide, with more announced each year, including regions built for specific sovereignty requirements such as the European Sovereign Cloud in Germany.

An Availability Zone (AZ) is one or more discrete data centres inside a region with independent power, cooling and networking, connected to the other AZs in that region by high-bandwidth, low-latency private fibre. Every region has at least three AZs. AZs are far enough apart that a single event (fire, flood, power failure) should not take out two, and close enough that synchronous replication works. Most AWS resilience guidance reduces to "run in at least two AZs", because that is the boundary AWS designs failures around.

A data centre is a building. You never address one directly; AZ names such as eu-west-2a map to physical AZs differently per AWS account, which is why you should use AZ IDs (euw2-az1) when coordinating across accounts.

Regional services (S3, DynamoDB, Lambda, SQS) are built to span AZs for you. Zonal resources (EC2 instances, EBS volumes, subnets, RDS single-AZ instances) live in one AZ and it is your job to spread them.

Extensions: Local Zones, Wavelength, Outposts, Dedicated Local Zones

• Local Zones put a subset of AWS compute, storage and database services in a metropolitan area that has no full region, connected back to a parent region. They exist for single-digit-millisecond latency to users in cities such as Los Angeles, Lagos, Delhi, Perth or Manila. Limited service catalogue; ideal for media, gaming, real-time apps and edge inference.
• Wavelength Zones embed AWS compute inside telecom operators' 5G networks for the lowest possible mobile latency.
• Outposts are AWS-managed racks (or 1U/2U servers) installed in your own data centre, running a subset of AWS services with the same APIs, for data-residency or latency requirements that cannot leave the building.
• Dedicated Local Zones are Local Zones built for a single customer or community, typically governments and regulated industries, with additional controls.

The edge: CloudFront, Route 53, Global Accelerator

AWS has several hundred edge locations and regional edge caches in over 100 cities. CloudFront serves cached content and runs Lambda@Edge and CloudFront Functions from them; Route 53 answers DNS from them; AWS Global Accelerator gives you two static anycast IPs that route users over the AWS backbone to the nearest healthy regional endpoint, which is the simplest way to get cross-region failover for TCP and UDP traffic without DNS TTL problems. AWS Shield absorbs DDoS at the edge before it reaches your region.

Choosing a region

Pick regions in this order of priority:

1. Compliance and data residency. If a regulator or contract says data stays in the UK, EU, India, Australia, Canada or the Gulf, that decides it. GDPR, the UK GDPR, India's DPDP Act, Australia's Privacy Act and APRA CPS 234, Canada's PIPEDA and Quebec Law 25, and the UAE's PDPL all shape region choice for our clients. AWS GovCloud (US) is for US federal and defence workloads and their suppliers, not a general option.
2. Latency to users. Measure it; do not assume. A London region serves the UK and much of Western Europe under 30 ms. Mumbai serves India; Sydney serves Australia and New Zealand; UAE (me-central-1) and Bahrain (me-south-1) serve the Gulf; Singapore serves Southeast Asia. For global audiences, put the origin where the data must live and use CloudFront and Global Accelerator for everyone else.
3. Service availability. New services and instance types launch in us-east-1, us-west-2 and eu-west-1 first. Check the regional services list before committing; a region that lacks the managed service you planned to use costs more in engineering than any latency it saves.
4. Cost. Prices vary by region, sometimes by 10 to 30 percent for the same instance. The US regions are usually cheapest; South America, some Asia-Pacific regions and the Gulf are dearer. Data transfer out and inter-region transfer are the hidden lines.
5. Capacity and quotas. Smaller regions can have constrained capacity for specific instance families or GPUs. If you depend on a particular instance type, confirm capacity, and use capacity reservations for critical workloads.

Multi-AZ first, multi-region second

Nearly every availability requirement is met by multi-AZ inside one region: an Auto Scaling group across three AZs behind an Application Load Balancer, Multi-AZ RDS or Aurora, S3 and DynamoDB doing their own replication. This gives you resilience to a data-centre loss with no cross-region complexity and no data-consistency questions.

Multi-region is justified when you need to survive a whole-region event (rare, but us-east-1 has had them), when a regulator requires geographic separation of DR, or when users on two continents need local write latency. It comes in four patterns, in increasing cost and complexity:

Pattern	RTO	RPO	Relative cost	Notes
Backup and restore	Hours	Hours	Lowest	Cross-region snapshot copies, infrastructure as code to rebuild. Good enough for many internal systems.
Pilot light	Tens of minutes	Minutes	Low	Data replicated continuously (Aurora Global Database, DynamoDB global tables, S3 replication); compute scaled to zero until needed.
Warm standby	Minutes	Seconds to minutes	Medium	A scaled-down copy of the full stack running in the second region; scale up and switch traffic on failure.
Active-active	Seconds	Near zero	Highest	Both regions serve traffic; needs conflict-tolerant data design and global routing (Route 53 or Global Accelerator).

Whatever the pattern, the failover has to be rehearsed. A DR region that has never been switched to is a line item, not a control. We schedule failover tests for managed estates and put the timing in the monthly report.

Networking across the footprint

Inside a region, VPCs span AZs and subnets are zonal. Between regions, VPC peering and Transit Gateway inter-region peering carry private traffic over the AWS backbone, encrypted. AWS PrivateLink keeps traffic to AWS services and partner services off the internet. For hybrid connectivity, Direct Connect locations exist in most major markets and can be used with a Direct Connect Gateway to reach VPCs in multiple regions from one link.

Design rule: never let the only path between two components be the public internet, and never let an AZ-level failure become a region-level outage because a NAT gateway, endpoint or bastion existed in one AZ only.

Cost across regions

The costs that surprise people are transfer costs: inter-AZ data transfer inside a region (small per-GB charge in each direction), inter-region transfer (higher), and internet egress (highest). Architectures that chatter across AZs at high volume, or replicate everything to a second region "just in case", pay for it monthly. The controls are VPC endpoints, keeping chatty services in the same AZ where the resilience trade-off allows, replicating only what DR actually needs, and CloudFront in front of anything public. Our cloud infrastructure services team reviews transfer lines in every monthly cost report because they are where the easy savings usually are.

What this means for a mid-size estate

For most of the clients we run, the right answer is one primary region chosen for residency and latency, three AZs, managed services with Multi-AZ on, a pilot-light or warm-standby DR region with a rehearsed failover, CloudFront and Global Accelerator for global users, and Terraform describing all of it so the DR region is provably the same as production. That design costs a fraction of active-active and covers every failure the estate has a realistic chance of seeing.

Frequently asked questions

How many AWS regions and Availability Zones are there?

More than 35 regions and over 110 Availability Zones as of 2026, with additional regions announced. The current list is on the AWS Global Infrastructure page; count from there rather than from any blog post, including this one.

What is the difference between a Region and an Availability Zone?

A Region is a geographic area with its own service endpoints and pricing. An Availability Zone is an isolated set of data centres inside a Region. You choose a Region for compliance and latency; you use multiple Availability Zones for resilience.

Which AWS region should a UK business use?

eu-west-2 (London) for UK data residency and lowest UK latency, with eu-west-1 (Ireland) as the usual DR pair. UK GDPR and most UK sector regulators are satisfied by UK or EU regions; check the specific requirement.

Which AWS region is best for India?

ap-south-1 (Mumbai) with ap-south-2 (Hyderabad) as the in-country DR pair, which satisfies RBI and DPDP data-localisation expectations for most workloads.

Is multi-region always better than multi-AZ?

No. Multi-AZ covers data-centre failure at low cost and complexity. Multi-region covers regional failure and geographic latency at significantly higher cost, and only delivers if failover is designed, automated and tested.

Can Techtweek design and run a multi-region AWS estate?

Yes. As an AWS Advanced Partner we design landing zones, region strategy and DR patterns, build them in Terraform, and run them 24/7 through our NOC monitoring services. Region choice and residency requirements are worked through with our compliance sister firm PraxisQ Consulting where certification is in scope.