AWS regions and availability zones explained

The hierarchy: Region, Availability Zone, data centre

The structure nests. At the top is the Region — a distinct geographic area, such as one anchored in Ireland or in northern Virginia, that operates independently of every other Region. Inside each Region sit multiple Availability Zones (AZs). An AZ is one or more physical data centres with its own independent power, cooling and networking, deliberately sited far enough from its sibling AZs that a localised event — a fire, a flood, a power-grid failure — should not take out more than one of them. At the bottom is the data centre itself: the actual buildings full of servers, which you never interact with directly.

Two further layers extend the picture. Edge locations — the points of presence used by CloudFront, AWS’s content delivery network — are far more numerous than Regions and sit close to end users in cities worldwide, caching content and accelerating delivery; they serve traffic but do not host your general-purpose workloads. Local Zones extend a Region by placing selected compute and storage close to large population centres, for applications that need very low latency to users in a particular metro area. Both are extensions of the core Region-and-AZ model, not replacements for it.

Why AZs are separated — and connected

The design of an Availability Zone balances two requirements that pull in opposite directions. Isolation demands distance: AZs have independent power, cooling and network connectivity, and enough physical separation that a disaster affecting one is very unlikely to affect another. But usefulness demands closeness: the AZs within a Region are linked by high-bandwidth, low-latency private fibre, so an application can run across several of them and behave almost as if it were in one place — replicating data between AZs synchronously, spreading servers behind a load balancer, failing over in seconds.

This is the trick that makes cloud resilience practical. Achieving the same thing yourself would mean building and connecting multiple physically separate data centres — the sort of investment only the largest enterprises could ever justify. On AWS, running across multiple AZs is a checkbox and an architectural habit, not a construction project.

How this maps to resilient design

The hierarchy gives you two distinct levels of protection, and the vocabulary matters. Multi-AZ is the everyday resilience pattern: run your application in two or more Availability Zones within one Region, so the failure of a single AZ — rare, but real — leaves the others serving traffic. Managed services lean into this: relational databases can replicate synchronously to a standby in another AZ, load balancers distribute across AZs by design, and auto scaling replaces lost capacity in the zones that remain. Multi-AZ is the baseline the AWS exams and AWS’s own guidance treat as the norm for production workloads.

Multi-Region is the stronger, costlier level: running or replicating your application across two or more Regions entirely. Because Regions are independent, this protects against the failure of a whole Region and also serves global audiences from locations near them. The trade-offs are real — replication across regions is asynchronous in most patterns, cross-region data transfer is charged, and the operational complexity is significantly higher — so multi-Region is a deliberate choice for disaster recovery and global reach, not a default. Understanding which problems need which level is precisely the judgement scenario questions test.

How to choose a region

With many Regions available, the choice is a weighing of a few factors:

• Latency to your users — closer is faster; an application serving one country usually belongs in the nearest Region, with CloudFront’s edge locations helping for content delivered globally.
• Data residency and compliance — laws and contracts often require certain data to stay in a particular country or jurisdiction, which can make the choice for you. Because Regions are isolated, data does not leave one unless you move it.
• Service availability — not every AWS service or feature launches in every Region at the same time; newer capabilities typically reach the largest Regions first, so check that what you need is available where you want it.
• Price — AWS pricing varies by Region, reflecting local operating costs, so the same architecture can cost noticeably different amounts in different places. The current rates are on AWS’s pricing pages.

Region-scoped versus global services

A subtlety that trips up newcomers: most AWS services are region-scoped, but a few are global. When you create a resource — a virtual server, a database, a network — you create it in a specific Region, and the console shows you one Region at a time; a resource in one Region is invisible from another, and this is by design. But some services are global by nature: IAM, which manages identities and permissions, applies across your whole account rather than per Region; Route 53, the DNS service, answers queries worldwide; CloudFront operates across the edge network rather than inside any single Region.

The mental model that helps: services whose job is inherently about your whole account or the whole internet are global; services that run workloads and store data live in a Region. Knowing which is which saves genuine confusion — the classic beginner mistake is creating a resource, switching Regions without noticing, and concluding it has vanished.

Why this is foundational for every certification

Regions and Availability Zones appear on every AWS exam, from the first to the last, because they are the substrate of every other topic. Cloud Practitioner (CLF-C02) tests the definitions directly — what Regions, AZs and edge locations are and why the global infrastructure matters. The Solutions Architect – Associate (SAA-C03) turns them into design decisions: nearly every scenario about high availability, disaster recovery or latency is really a question about deploying across AZs or Regions. The CloudOps Engineer – Associate (SOA-C03) tests operating and troubleshooting workloads across this topology. Learn the model well now — genuinely understand why an AZ failure and a Region failure are different problems with different answers — and a large fraction of exam scenarios become applications of one idea you already own.