AWS global infrastructure: Regions, Availability Zones, edge locations, and when to use more than one Region

Why this matters

Every resource you create in AWS lives somewhere physical. A virtual server runs in a particular building, a database sits on disks in a particular place, and a website's images may be copied to sites in dozens of cities. Where those things live decides how fast your users are served, what happens when a building loses power, and whether you are obeying a law that says customer records must stay in one country.

A manager signing off a project needs to know that "we run in one Availability Zone" means one fire or flood can take the service down. A salesperson answering a customer's questionnaire needs to say, correctly, where that customer's data is kept. A junior engineer picking a Region from a drop-down menu is making a legal and commercial decision as well as a technical one.

This is also one of the most predictable areas of the exam. The vocabulary is small, Region, Availability Zone and edge location, and almost every scenario turns on choosing the right one of the three for the problem described.

The lesson

AWS Regions, Availability Zones, and edge locations

An AWS Region is a separate geographic area of the world where AWS runs its infrastructure, such as a part of Europe, North America or Asia Pacific. Each Region is isolated from the others. When you create most resources, you choose the Region first, and the resource exists only there.

Inside each Region are several Availability Zones (AZs). An Availability Zone is one or more discrete data centres, a data centre being a building full of servers, storage and network equipment. Each AZ has its own redundant power, networking and connectivity. A Region is therefore the larger unit: a Region contains AZs, never the other way round, and a Region is not a single building.

An edge location is a smaller site in a city, separate from the Regions and their AZs. AWS has edge locations in many more cities than it has Regions. They do not run the full range of AWS services. Instead they serve a few services that need to be close to users, among them Amazon CloudFront, the AWS content delivery network (CDN), which keeps cached copies of content near viewers; Amazon Route 53, the AWS Domain Name System (DNS) service, which turns names like example.com into addresses; and AWS Global Accelerator.

Do not memorise how many Regions, AZs or edge locations exist. The numbers grow every year, and AWS publishes the current figures on its global infrastructure page.

High availability

High availability means a system keeps working when one of its parts fails. The opposite is a single point of failure: one component whose loss stops everything, such as one server, one power feed or one building.

On AWS, high availability is mostly a design choice made by the customer. AWS gives you independent AZs to build on, but if you put every server in one AZ, that AZ is your single point of failure. Making a larger server, or adding more servers in the same AZ, adds capacity but not availability, because they would all fail together.

Use of multiple Regions

Most AWS services are Regional: an Amazon EC2 instance, an Amazon RDS database or an Amazon S3 bucket belongs to the Region you created it in. A few services are global and are not tied to one Region. AWS Identity and Access Management (IAM) is the usual example: its users, groups, roles and policies apply across every Region in the account. CloudFront and Route 53 are also global services.

Because Regions are isolated, running in more than one Region is something you choose and set up. AWS does not copy your resources to other Regions for you. AWS does not move your content out of the Region you chose without your agreement, except where the law requires it. Otherwise, data you store in a Region stays there until you move or replicate it. That is why the choice of Region matters.

When choosing a Region for a workload, weigh four things:

• Compliance and data residency: a law or contract may require data to stay in a country or area.
• Proximity to users: a nearer Region means lower latency, the delay between a user's request and the reply.
• Service availability: not every service or feature is offered in every Region, and newly launched services often arrive in some Regions first. Check before you commit.
• Price: prices for the same service differ between Regions. Compare them on the service's pricing page or in the AWS Pricing Calculator.

Settings that apply to the whole account, such as the AWS Support plan or the IAM password policy, do not change with the Region and play no part in choosing one.

Benefits of edge locations

The main benefit of an edge location is lower latency. A user in Sydney fetching an image from a server in Europe waits for the request to cross the world and back. If CloudFront has a cached copy, a stored copy kept for fast reuse, at an edge location in Sydney, the user gets it from nearby instead.

Edge locations bring other benefits. They take load off the origin, the server or S3 bucket holding the master copy, because many requests are answered at the edge. Route 53 answers DNS queries from edge locations, so names resolve quickly worldwide. AWS Global Accelerator lets user traffic, including TCP and UDP traffic, join the AWS global network at the nearest edge location and travel the rest of the way on AWS's network rather than the public internet, which improves performance and availability. AWS Shield Standard, which every customer gets at no extra charge, protects CloudFront and Route 53 at the edge against common denial-of-service attacks.

An edge location is not a place to keep your primary data, run your database or store backups. It caches and routes; the Region holds the real thing.

How Regions, Availability Zones and edge locations fit together

Picture three layers. The Region is the area you choose. Inside it, several AZs give you separate failure domains to spread work across. Outside the Regions, the edge network sits close to users and speeds up delivery from whichever Region your application lives in.

Resources map onto these layers in a way worth knowing. An Amazon EC2 instance runs in one AZ inside the Region you pick, not across every AZ at once. An Amazon EBS volume, the virtual disk attached to an instance, also sits in one AZ. An Amazon EFS file system is created in a Region and can be reached from several AZs. IAM sits above all of them, as a global service. Two names that are not AZs come up as wrong answers: AWS Outposts is an AWS-managed rack installed in the customer's own building, and AWS Direct Connect is a private network link from a customer's premises into AWS. Neither is part of the edge network that serves public users.

Building high availability across several Availability Zones

The standard pattern is to run copies of each part of the application in at least two AZs:

• Run Amazon EC2 instances in several AZs behind Elastic Load Balancing. A load balancer receives all incoming requests and passes each one to a healthy instance. If one AZ fails, the load balancer sends traffic only to the healthy instances in the AZs still running. A load balancer works within one Region; it does not move traffic to another Region.
• Use an Auto Scaling group that spans the same AZs, so lost instances are replaced in a working AZ. Lesson 14 covers load balancers and auto scaling in more detail.
• For a database, use an Amazon RDS Multi-AZ deployment. RDS keeps a standby copy in a different AZ and fails over automatically, meaning it switches to the standby without anyone stepping in, if the primary has a problem. A snapshot, a point-in-time copy, can restore data later, but restoring one is a manual step, not automatic failover.

Many managed services do some of this for you. Amazon S3, for example, stores objects across several AZs in a Region by default, except in the storage classes designed for a single AZ, which lesson 18 covers.

Why Availability Zones fail independently

AZs are deliberately built so that a problem in one is unlikely to affect another. They are physically separate, each has independent power, networking and connectivity, and they do not share single points of failure. A fire, flood or power cut in one AZ should leave the others running.

They are still close enough to work together. The AZs in a Region are joined by high-bandwidth, low-latency, redundant links over the AWS network, so applications can copy data between them quickly. That is what makes synchronous replication, as in RDS Multi-AZ, practical. AZs can communicate freely, but AWS does not copy your instance data between them unless you set that up.

The phrase "independent power and networking" in a scenario is pointing at AZs. The phrase "different continents" is not: AZs are all inside one Region.

When a second Region is worth it: disaster recovery, continuity, latency and sovereignty

Multiple AZs protect against the loss of a data centre. They do not protect against the loss of a whole Region, because every AZ is inside it. Reach for a second Region when:

• Disaster recovery is required: getting systems back after a major event. Copy backups to a different Region, for example with AWS Backup or S3 replication, so a usable copy survives a Region-wide disaster. A second AZ, or taking backups more often in the same Region, does not achieve this.
• Business continuity is required: keeping the business running through that event, often by running a second copy of the application in another Region, ready to take over.
• Low latency for distant users matters: if most users are in Asia and the application runs only in North America, larger instances will not fix the slow responses. Running the application in a Region in Asia shortens the round trip. With the application in two Regions, Route 53 latency-based routing answers each user's DNS query with the Region that gives that user the lowest latency.
• Data sovereignty applies: a law says certain data must stay in a given country. Store that data in a Region in that country. Spreading it across AZs in some other Region, or caching it worldwide with CloudFront, does not meet the requirement, and edge locations are not where primary data is kept.

Extra Regions add cost and complexity, so they need a reason. "Getting access to the console" or "a cheaper Support plan" are never reasons.

What the exam is really asking

Match the failure to the layer. One server or one data centre failing points to multiple AZs. A whole Region failing points to a second Region. Slow delivery to users far away points to edge locations and CloudFront, or to a Region nearer the users. A rule about where data must live points to choosing the Region.