Cloud Foundations · Tech Jacks Solutions

Cloud Regions and Availability Zones Explained (2026)

Last verified: June 17, 2026  ·  Format: Breakdown

Cloud regions and availability zones are the two words you meet on the very first screen of any cloud console, usually before you have built anything at all. A drop-down asks where you want to run, and the honest answer is that most people pick the nearest city and move on. That works until it does not: until an outage takes a data center offline, or a customer asks where exactly their records live. This breakdown explains what those terms mean, how AWS, Azure, and Google Cloud organize their global infrastructure, and why data residency turns a technical choice into a legal one.

We will keep it plain and practical: the difference between a region, a zone, and an edge location; how the three big providers count and structure theirs; what "zone-redundant" actually buys you; and what residency and GDPR ask of you. Infrastructure counts below are reported by each provider and were checked on June 17, 2026. These numbers move month to month, so confirm the current figures on the provider's own page before you design around them.

Region vs availability zone vs edge location

Region, availability zone, and edge location describe three different scales of cloud geography, and mixing them up leads to real mistakes. Start with the largest and work down.

Region: a geographic area you choose

A region is an independent geographic area, usually named for a city or area such as US East or West Europe, that contains multiple physically separate locations. When you deploy something to the cloud, the region is the first decision you make, and it sets the physical place where your data and compute live. Regions are isolated from one another by design, so a problem in one region does not cascade into another. That isolation is also what makes the region the unit that matters for data residency.

Availability zone: isolated infrastructure inside a region

An availability zone (AZ) is one or more physically separate data centers within a region, each with its own independent power, cooling, and networking. Zones inside a region are close enough for fast, low-latency links but far enough apart that a fire, flood, or power failure in one is unlikely to affect another. This is the core idea behind cloud resilience: you spread an application across two or three zones so the loss of a single data center does not take your service down. A region with three availability zones gives you three isolated failure domains to build across.

Edge location and point of presence: caching near users

An edge location, also called a point of presence (POP), is not where your application runs. It is a smaller facility, usually part of a content delivery network, that caches and serves content close to end users to cut latency. AWS reports more than 750 CloudFront points of presence as of June 17, 2026, far more than its regions, precisely because edge sites are about speed of delivery rather than where your workload and database live. Keep the distinction clear: regions and zones are where you compute and store; edge locations are how you deliver fast.

How AWS, Azure and Google Cloud structure regions and zones

All three major providers share the same region-and-zone model, but they count and describe it differently. The table below is a snapshot taken on June 17, 2026 from each provider's own infrastructure page; treat the totals as a moment in time, because every provider adds capacity continuously.

Counts are vendor-reported and change frequently. Verify on each provider's infrastructure page (linked below) before planning.

AWS: regions, AZs, and extra zone types

AWS reports 123 availability zones across 39 launched regions as of June 17, 2026, with at least three availability zones in every region and further regions announced, including Saudi Arabia and Chile. Alongside standard zones, AWS offers Local Zones (43 of them) that place compute closer to large population centers for latency-sensitive work, and Wavelength Zones (33) that sit inside telecom networks for mobile edge use. For workloads that must stay on-premises, AWS Outposts extends the same APIs into your own data center. For the wider AWS picture, see our AWS guides.

Azure: availability zones and update discipline

Microsoft Azure builds regions from availability zones that are physically separated, usually within about 100 kilometers of each other. Microsoft targets an inter-zone round-trip latency of under roughly 2 milliseconds and does not charge for data transfer between availability zones inside the same region, which removes a common cost objection to spreading across zones. Azure also rolls platform updates one availability zone at a time, so a maintenance event never hits every zone in a region at once. Our Azure guides go deeper on building zone-redundant services.

Google Cloud: zones and multi-regional services

Google Cloud structures each region as a set of zones, typically three or more in three or more data centers, and states an intent to provide a minimum of three distinct zones in general-purpose regions. A few newer regions, such as Stockholm, Mexico, Osaka, and Montreal, started in one or two data centers and are expanding. Google also offers multi-regional services, where products like Spanner, Firestore, and Cloud Storage replicate across regions so the workload survives the loss of an entire region. See our Google Cloud guides for service-level detail.

Zonal vs zone-redundant vs multi-regional

Once you understand zones, the next question is how your service uses them, because that choice decides what an outage actually costs you. Providers use three broad patterns, and Azure's naming captures them cleanly.

The practical reading is straightforward. A zonal deployment gives you control and locality but puts the redundancy work on you: if you pick one zone and that zone goes down, so does your resource unless you built a standby elsewhere. A zone-redundant deployment hands that work to the provider, which spreads the resource across zones and fails over automatically, so the loss of one availability zone is a non-event. Because Azure does not charge for in-region inter-zone transfer and targets sub-2-millisecond latency between zones, zone-redundant is often the sensible default for production services that need to stay up.

Above the zone sits the region. Multi-regional services such as Google Cloud's Spanner, Firestore, and Cloud Storage replicate data across regions so a workload survives the loss of an entire region, not just one zone. That resilience is the strongest tier available, and it is also where cost, latency, and, crucially, data residency come back into the conversation, because replicating across regions can mean replicating across borders.

Data residency, data sovereignty and GDPR

Here is where the region drop-down stops being a performance decision and becomes a compliance one. Data residency means that data is stored within a defined geographic boundary, such as a country or the European Union. Data sovereignty goes further: it holds that data is subject to the laws of the place it sits. Because a region is a fixed geographic area, the region you choose is the lever that controls both.

Under the EU's General Data Protection Regulation (GDPR), personal data about people in the EU often needs to stay in EU regions or be transferred only under specific safeguards. The important point for builders is responsibility: the cloud provider operates regions in many countries, but you are the one who chooses where your data is stored. Picking a Frankfurt or Stockholm region instead of a US region is, in practice, how a customer keeps EU personal data in the EU. Providers also offer dedicated tools for stricter cases, such as AWS Dedicated Local Zones, Azure's in-region multi-AZ deployments, and Google Cloud's Sovereign Controls offered with partners.

How to choose a region

With the vocabulary in place, the region choice becomes a short checklist rather than a guess. Weigh these four factors, roughly in this order, for most workloads.

• Compliance and residency first. If any law or contract requires data to stay in a country or bloc, that constraint eliminates regions before anything else does. Start here, not last.
• Latency to your users. Among the regions that satisfy residency, pick the one closest to the people or systems that call your service. Closer regions mean lower round-trip time.
• Service and feature availability. Not every service or instance type ships in every region on day one. Confirm the specific products you need are available in the region you want.
• Cost. Prices differ by region for the same service. Once compliance, latency, and availability are satisfied, cost is a reasonable tiebreaker, but it should rarely override the first three.

Then, inside that region, choose your resilience pattern: spread production services across multiple availability zones (zone-redundant) so a single data center failure is survivable, and reserve multi-regional replication for the workloads whose loss you genuinely cannot tolerate. If the cloud model itself is still new to you, our explainer on what cloud computing is sets the groundwork, and the cloud shared responsibility model explains where your obligations begin and the provider's end.

Who should care about regions and zones

Cloud regions and availability zones sound like an infrastructure detail, but they touch several roles differently. Here is how the main groups should read this.

What to watch with regions and zones

The model behind cloud regions and availability zones is clean, but a few traps catch people in practice. None of these are reasons to avoid the cloud; they are reasons to design with clear eyes.

Frequently Asked Questions