Regions, AZs, and Edge Locations

Picture two of Diana's customers opening her app at the same moment — one in Tokyo, one in São Paulo. If her entire infrastructure runs in Frankfurt, both customers wait. The Tokyo user's request crosses the planet twice before getting an answer.

This is why AWS lays the world out in three layers: regions, availability zones, and edge locations. Every developer decision — where to launch a Lambda, where to put a database, where to cache an image — eventually hits this geography.

Regions Are Independent Worlds

A region is a geographically separated cluster of AWS data centers — us-east-1 in Virginia, eu-west-1 in Ireland, ap-northeast-1 in Tokyo. AWS operates over 30 regions globally.

Key facts to internalize:

• Most services are region-scoped — an S3 bucket, an RDS database, or a VPC lives in exactly one region;
• Data does not automatically replicate across regions. You have to opt in;
• A few services are global — IAM, Route 53, CloudFront, WAF;
• Region pricing differs. Compute in São Paulo costs more than in Ohio. When you create resources, you are always answering "which region?" — and forgetting to check is how teams end up with mystery resources in us-east-2.

Availability Zones Inside a Region

Each region contains multiple availability zones (AZs) — physically separate data centers within the same region, connected by very fast private fiber. Most regions have 3 to 6 AZs.

AZs exist for one reason: fault isolation. If one AZ loses power or floods, the others keep running. To build a fault-tolerant app on AWS, you spread your resources across at least two AZs:

• An EC2 fleet behind an Application Load Balancer with instances in us-east-1a, us-east-1b, us-east-1c;
• An RDS database with Multi-AZ enabled, so a standby in another AZ takes over within seconds if the primary fails;
• A DynamoDB table, which is automatically multi-AZ for you. For the exam: assume any single-AZ deployment is wrong unless the question specifically rules out high availability.

Edge Locations and CloudFront

Edge locations are a third layer — hundreds of small AWS sites scattered across cities worldwide, far more numerous than regions. They cache content close to users.

The flagship service here is Amazon CloudFront, the AWS content delivery network. When Diana's Tokyo user requests an image, CloudFront serves it from the nearest edge — often inside the same city — instead of crossing the ocean to the origin in Frankfurt.

Other services that ride on edge locations:

• Route 53 — DNS resolution from the closest edge;
• AWS Global Accelerator — TCP/UDP traffic routed over the AWS backbone;
• Lambda@Edge — Lambda functions that execute at CloudFront edges.

How to Choose a Region

Three factors usually decide:

• Latency — closer to users wins. Test with tools like cloudping.info;
• Compliance — EU data may have to stay in EU regions; some workloads must run in specific government regions;
• Service availability — newer services launch in us-east-1 first and may not exist in every region for months. A common rookie mistake: launching everything in us-east-1 because the AWS console defaults there, then wondering why European users complain about lag.