Regions, Availability Zones and edge locations

Zones fail independently, and that is the entire design

An Availability Zone is one or more discrete data centres with independent power, cooling and physical security, linked to the other zones in its Region by connections fast enough that you can treat them as one deployment. Those two properties together are why "run it in at least two zones, behind a load balancer" is the standard unit of high availability: the zones do not fail together, and the link between them is quick enough that spreading a single application across them is not a compromise.

The distractors offered against this are all real improvements to something else, which is what makes them work. More frequent snapshots protect the DATA and shorten how much work you lose; they do not keep the application answering, because restoring is an outage of its own. A larger instance adds capacity; it is still one instance in one zone. A content delivery network keeps cached assets alive for a while; every request that has to reach the application still arrives at the failed zone. Capacity, durability and availability are three different problems.

Choosing a Region: a filter, then three trade-offs

Four things decide where a workload goes, and the exam cares about the ORDER as much as the list. Compliance and data governance come first and behave differently from the rest: they are a hard constraint that removes Regions from consideration entirely. Your data stays in the Region you chose unless you deliberately move or replicate it, which is exactly what makes the choice of Region the control a regulator is asking about.

The remaining three are genuine trade-offs among whatever survives the filter: how close the Region is to the users or systems it serves, whether it offers every service the workload needs, and what it costs. A question that offers "the cheapest Region" or "the Region with the most Availability Zones" against a stated legal requirement is testing whether you know that one of the four is not a trade-off at all.

The edge is a different tier, not a smaller Region

Edge locations are far more numerous than Regions and far thinner: they exist to cache content with Amazon CloudFront, to answer DNS queries with Amazon Route 53, and to take traffic onto the AWS network early with AWS Global Accelerator. You do not launch instances or create volumes in one. When the same file is served to viewers on several continents, the second and subsequent requests in a city being answered from that city is the standard fix, and it beats copying the bucket into several Regions and routing people yourself.

Two related tiers are worth recognising so they can be told apart from edge caching. AWS Local Zones place compute and storage close to one specific metropolitan area, for an application that needs single-digit millisecond latency to users in that city. AWS Wavelength does the same thing inside mobile operators' networks. Both run your workload; an edge location caches somebody's response to it.

Nothing leaves a Region by itself

Almost everything you create is scoped to a Region: buckets, EBS volumes, snapshots, AMIs, VPCs, most service endpoints. Nothing crosses a Region boundary unless you deliberately copy it — an S3 Cross-Region Replication rule, a snapshot copy, an AMI copy, a cross-Region read replica. This single fact is behind most disaster-recovery questions, and the version of it people get wrong is that BACKUPS are Regional too: an event that takes out the Region takes the volumes and their snapshots with it.

Surviving the loss of a Region therefore takes two things, and a question will usually offer only one of them. Somewhere else to serve from — a stack deployed in a second Region — and something that notices the failure and redirects users to it, which is normally Route 53 health checks moving traffic at the DNS layer. Adding a fourth Availability Zone in the same Region is a real improvement to a different risk, which is why it is such a good distractor.