Core Cloud Architecture · Part 1 of 13

Regions, Availability Zones, and Edge Locations

The physical geography a request crosses before it reaches your code.

Every cloud provider's map is built from the same two nested pieces: a region, made of availability zones, which are themselves collections of one or more physical data centers. A third piece, the edge, sits outside that nesting. Edge locations are scattered far more densely than regions, closer to the people making requests, and a private backbone network connects them to the regions behind them. Each piece answers a different question: where data legally lives, what keeps a single failure from taking down the whole application, how to make a page load fast for someone on another continent.

Regions

A region is a large geographic area, usually named after a place like us-east-1 or europe-west1, that a provider treats as one independent deployment target. Each region has its own power, cooling, and networking, and by design a failure in one region should have no effect on any other. Most cloud resources are created inside a specific region, so the region is the first decision an architecture makes.

Regions matter for three reasons. Latency: a region near your users means shorter round trips. Data residency and sovereignty: some laws (parts of the EU's GDPR regime, certain government contracts, some financial and healthcare regulation) require that specific categories of data physically stay within a country or economic bloc, which only a region choice can guarantee. Availability and disaster recovery: a second region gives you somewhere to fail over to if an entire region goes down, which is rare.

Availability zones

A region is itself divided into availability zones (AZs), three or more in most regions (Google's documentation says three or more zones per region, and Azure's zone-enabled regions list three or four), each meant to be a physically separate facility (or cluster of facilities) with independent power, cooling, and networking, connected to the other AZs in the region by low-latency, high-bandwidth links. AWS describes an AZ as one or more discrete data centers, Azure as a logical grouping of one or more physically separate datacenters, and Google calls a zone a single failure domain within a region. An AZ is the main fault domain an architecture is designed around: a boundary such that a failure inside it (a power outage, a cooling failure, a fire, a rack failing) is contained and shouldn't propagate to another AZ in the same region. AWS and Azure also map zone names to physical zones differently for each account, so "zone 1" in your subscription may not be the same building as "zone 1" in someone else's.

This is the practical reason multi-AZ deployment exists: running identical infrastructure in two or three AZs within the same region means a single facility going dark doesn't take the application down, while round trips between AZs stay fast enough (AWS cites single-digit milliseconds, Azure targets about 2 ms) that most applications don't notice the difference from running in one.

Edge locations

Providers also operate edge locations (sometimes called points of presence, or POPs), numbering in the hundreds, far more numerous and far smaller than regions. An edge location typically doesn't host your application. It caches static content (images, scripts, video, API responses that don't change per request) and terminates network connections physically closer to the end user, so a request from Manila to an application hosted in Virginia doesn't have to make the entire round trip for content that hasn't changed. Some edges also run small pieces of your code, such as CloudFront Functions and Lambda@Edge. Caching at the edge is the mechanism behind a content delivery network (CDN).

The edge and the backbone

A request reaches a region in two stages. It first enters the provider's network at an edge location, where content can be cached and connections are terminated. From there it travels over the provider's backbone, a private long-haul network that links the edge locations, the regions, and the rest of the world. The edge is where a request lands; the backbone is the road it travels afterward. Each provider names and packages the two differently:

Each provider has one main edge service for web content: CloudFront on AWS, Cloud CDN on GCP, and Front Door on Azure. Edge counts change often; the figures above come from each provider's documentation as of October 2026.

The edge also protects the origin. Baseline protection against distributed denial-of-service (DDoS) attacks is built in on all three clouds: AWS Shield Standard for CloudFront, Cloud Armor's automatic protection for Google's global external Application Load Balancer, and Front Door's own DDoS protection. A WAF is the other piece. On AWS and GCP it is a separate product attached to the edge service (AWS WAF, Cloud Armor), while on Azure it is built into Front Door, where Premium adds Microsoft-managed rule sets and bot protection. Security Fundamentals covers both in more depth.

flowchart TD
  R[Region — e.g. us-east-1] --> AZ1[Availability Zone A]
  R --> AZ2[Availability Zone B]
  R --> AZ3[Availability Zone C]
  AZ1 --> DC1[Data center]
  AZ2 --> DC2[Data center]
  AZ3 --> DC3[Data center]
  U((User)) -->|nearest edge| E[Edge location — caches content, terminates connections]
  E -->|cache miss, over provider backbone| R
  

Regional vs. global services

Not every cloud service lives inside one region. DNS and content delivery are usually global: one DNS record applies everywhere, with no region selection at all. Core access management is global in the same way: AWS IAM users, roles, and policies belong to the account, and a Microsoft Entra tenant is not tied to a region. Sign-in services for an application's own users are different: Amazon Cognito user pools and AWS IAM Identity Center live in a region you choose. Object storage buckets and most managed databases are usually regional: created in one region, replicated elsewhere only if you explicitly set that up. Virtual machines and block disks are usually zonal: they live in one availability zone, and surviving that zone failing means running copies in others. Network scope varies as well. An AWS VPC and an Azure virtual network are regional, while a Google Cloud VPC network is global. Which category a service falls into decides what a regional outage takes down: a regional database failure is contained to that region, while a failure in a global service such as DNS can affect every region at once.

How much of this a startup needs

The options form a ladder, and the right rung depends on what's at stake if a piece of infrastructure disappears for an hour.

Multi-AZ within a single region is the usual early default. A second live region is a later decision, made for a named requirement: a law requiring EU customer data to stay in the EU, a contractual uptime guarantee (an SLA, or service level agreement) a single-region design can't meet, or users for whom even a rare regional outage is unacceptable. A cheaper recovery plan is backups copied to a second region plus infrastructure as code that can rebuild the environment there, which recovers in hours instead of minutes.