AWS Global Infrastructure Explained: Regions, Availability Zones, Edge Locations, and Local Zones

Simple explanation

Think of AWS infrastructure like a chain of hospitals. A region is a full hospital campus in a city, with every department and specialty you need. Each campus has multiple buildings (Availability Zones) with their own power and water, so if one building has a power cut, the others keep running. Out in the suburbs, there are small urgent care clinics (edge locations) that handle quick, common needs close to where people live, but they cannot do major surgery. And in rare cases, there is a pop-up medical unit (Local Zone) set up in a remote town, or an ambulance with equipment (Wavelength Zone) parked inside a stadium for instant response.

• Region – a geographic area (like Northern Virginia or Frankfurt) with a full set of AWS services. This is where you run most workloads.
• Availability Zone (AZ) – an isolated data center cluster within a region. You spread workloads across AZs for fault tolerance.
• Edge location – a small point of presence near end users, used for caching (CloudFront) and DNS (Route 53). Not for running servers.
• Local Zone – an extension of a region placed in a specific city, for workloads that need very low latency to that metro area.
• Wavelength Zone – AWS compute embedded inside a telecom provider’s 5G network, for ultra-low-latency mobile apps.

Why this matters

The location you choose for your workloads is one of the most consequential early decisions in any AWS project. It affects five things directly:

• Latency – a server in the same continent as your users responds noticeably faster than one on the other side of the world. Every additional network hop adds delay.
• Resilience and high availability – spreading resources across multiple AZs means a data center failure does not take your application offline. This is the foundation of highly available design in AWS.
• Disaster recovery – if you need to survive the loss of an entire region, you need a disaster recovery strategy that spans multiple regions. This is expensive and complex, so most teams start with multi-AZ instead.
• Compliance and data residency – laws like GDPR, PDPA, and sector-specific regulations may require your data to stay within certain borders. Region choice is how you enforce that.
• Cost – AWS pricing varies by region. The same EC2 instance type can cost noticeably more in some regions. Data transfer between regions and out to the internet also adds to your bill, as explained in How Billing Works in AWS.

How AWS global infrastructure works

AWS organizes its infrastructure into three scopes: global, regional, and zonal. Understanding which scope a service belongs to tells you how it behaves and how you design around it.

• Global services operate across all regions automatically. IAM, Route 53, and CloudFront are global. You do not pick a region when using them.
• Regional services run in a specific region but are replicated across AZs within it. S3, DynamoDB, and Lambda are regional. When you create an S3 bucket in eu-west-1, it stays in eu-west-1.
• Zonal services are tied to a specific AZ within a region. An EC2 instance or an EBS volume runs in one AZ. If that AZ goes down, the instance goes with it unless you have designed for failover.

The hierarchy flows like this: the AWS backbone connects all regions. Each region contains multiple AZs. Edge locations sit at the perimeter of this network, close to population centers. Local Zones and Wavelength Zones extend regional capacity into specific metros and telecom networks.

Regions

A region is a cluster of data centers in a specific geographic area. Each region is completely isolated from every other region. A failure in us-east-1 (Northern Virginia) does not affect eu-central-1 (Frankfurt). When you create most AWS resources, you choose a region, and that resource stays there.

AWS operates regions across North America, South America, Europe, the Middle East, Africa, and Asia Pacific, with new regions announced regularly. Some regions (like GovCloud and China) have restricted access and special compliance properties.

How to choose a region

Choosing a region is not complicated, but getting it wrong means either slow performance or an expensive migration later. Ask these questions in order:

1. Where are your users? Pick the region closest to the majority of your traffic. If your users are in Germany, eu-central-1 is a strong default.
2. Do you have compliance or data residency requirements? Some regulations require data to stay in a specific country. This narrows your options immediately.
3. Does the region have the services you need? Not all AWS services are available in every region. Newer services often launch in us-east-1 first and expand later. Check the AWS Regional Services List before committing.
4. What does it cost? Pricing varies between regions. us-east-1 is typically the cheapest reference point. But do not choose a distant region just to save a few percent. The latency trade-off usually costs more in user experience than you save on the bill.
5. Do you need cross-region disaster recovery? If so, pick a secondary region in a different geographic area. See Multi-Region Architectures in AWS for guidance on when this is worth the complexity.

A sample of commonly used regions:

# List all available regions using the AWS CLI
aws ec2 describe-regions --query 'Regions[*].RegionName' --output table

# Check the region your CLI is currently configured for
aws configure get region

Availability Zones

Each region contains multiple Availability Zones, typically three or more. An AZ is one or more physically separate data centers with independent power, cooling, and networking. The AZs within a region are close enough for high-speed, low-latency connections between them, but far enough apart that a single event (fire, flood, power grid failure) is unlikely to affect more than one.

Going back to the hospital analogy: if one building on the campus loses power, patients can be treated in another building a few minutes away. Both buildings have their own generators and water supply, but they share the same campus and can transfer patients quickly. That is exactly how AZs work within a region.

Why multi-AZ is the default production pattern

A single-AZ deployment is a single point of failure. If that AZ goes down (and AZ-level incidents do happen), your application goes with it. Multi-AZ is the standard for production workloads because it gives you fault tolerance within a region without the cost and complexity of multi-region.

Most AWS services make multi-AZ straightforward. An Auto Scaling group distributes EC2 instances across AZs automatically. RDS Multi-AZ maintains a standby replica in a different AZ with automatic failover. ECS and EKS spread tasks and pods across AZs when configured with multiple subnets.

AZ naming is account-specific

AZ names follow the pattern region-code + letter: us-east-1a, us-east-1b, us-east-1c. But the letter-to-physical-location mapping differs between AWS accounts. Your us-east-1a is not necessarily the same physical building as another account’s us-east-1a. AWS randomizes this deliberately to distribute load evenly across its data centers.

If you need to coordinate AZ placement across accounts (for example, for cross-account networking), use AZ IDs like use1-az1 instead of AZ names. AZ IDs map consistently to physical locations regardless of account.

# List Availability Zones in the current region
aws ec2 describe-availability-zones \
  --query 'AvailabilityZones[*].{Name:ZoneName,State:State,AzId:ZoneId}' \
  --output table

Edge locations

Edge locations are small points of presence that AWS operates around the world, far more numerous than regions. They sit at the edge of the AWS network, in or near major cities, close to end users. Their purpose is to reduce latency for specific services, not to run general workloads.

Think of edge locations like ATMs for a bank. They are everywhere, they handle the most common transactions quickly, but you cannot walk up to one and open a business account. For that, you go to a full branch (a region).

Edge locations are used by:

• CloudFront – AWS’s content delivery network. Static files, API responses, and media are cached at edge locations so users fetch them from a nearby server instead of your origin region.
• Route 53 – DNS queries resolve at the nearest edge location, cutting DNS lookup latency.
• AWS Shield – DDoS protection is applied at the edge, absorbing attack traffic before it reaches your origin.
• Lambda@Edge and CloudFront Functions – run lightweight code at edge locations to customize request and response handling without a round trip to your region.

Local Zones and Wavelength Zones

Local Zones

A Local Zone is an extension of a parent region placed in a specific metropolitan area. It provides a subset of AWS services (EC2, EBS, ECS, and others) with single-digit millisecond latency to that city. Local Zones appear as additional AZs in your account and connect back to the parent region over the AWS backbone.

Local Zones exist for a specific scenario: your users are in a city that is far from the nearest full region, and your workload has strict latency requirements that a full region cannot meet. Examples include real-time video rendering, live streaming, and interactive media production.

Wavelength Zones

Wavelength Zones embed AWS compute and storage inside telecommunications providers’ 5G networks. Traffic from a mobile device on that 5G network reaches the Wavelength Zone without ever leaving the telecom network, which removes the latency of routing back to an AWS region. This is designed for ultra-low-latency mobile applications like connected vehicles, real-time game streaming, and AR/VR.

Do you need either of these?

Region vs Availability Zone vs edge location vs Local Zone vs Wavelength Zone

When to use what

Here is how common scenarios map to infrastructure choices:

• Web app serving one country or continent. One region close to your users, resources spread across multiple AZs, CloudFront in front for static assets. This covers the vast majority of production workloads.

• Global static site or API. One origin region, CloudFront edge caching worldwide, Route 53 latency-based routing if you add a second region later.

• Low-latency workload in a specific city. Check if a Local Zone exists for that metro. If it does and your latency requirement is strict, opt in and run the latency-sensitive part there while keeping the rest in the parent region.

• Mobile app needing ultra-low latency on 5G. Wavelength Zone, but only after confirming your telecom partner has a Wavelength deployment in the target market.

• Disaster recovery across regions. Pick a primary and a secondary region in different geographic areas. Design your recovery strategy based on your RPO and RTO requirements. See Disaster Recovery Strategies in AWS for the trade-offs between pilot light, warm standby, and active-active.