Cloud Regions and Availability Zones: How to Choose a Location
Regions and availability zones decide latency, price, quotas, data residency, and fault tolerance. How AWS, Google Cloud, Azure, DigitalOcean, Hetzner, and BinaryLane structure locations, and how to choose.
Every cloud resource lives somewhere physical, and where you put it decides your latency, your legal exposure, your price, and how well you survive a data centre failure. Providers describe that “where” with two words: region and availability zone. This guide explains what each means, how AWS, Google Cloud, Azure, DigitalOcean, Hetzner, and BinaryLane name and structure their locations, and how to choose a location for a new deployment.
Regions and availability zones defined
A region is a geographic area, usually named after a city or a country, that contains one or more data centres. Regions are independent of each other: a resource created in one region does not appear in another, and most services replicate across regions only if you configure it.
An availability zone (AZ) is one or more data centres inside a region with separate power, cooling, and network connections from the other zones in that region. Zones are close enough to each other for low-latency private networking but far enough apart that a fire, flood, or power event in one should not take down the others. Spreading an application across zones is the standard way to keep it running when a single data centre fails.
Not every provider has both layers. The hyperscalers do. Many developer clouds expose a flat list of data centre locations with no zone concept, and you get zone-like separation only by using two different locations.
- Region
- Geographic area; the unit for pricing, quotas, data residency, and service availability
- Availability zone
- Isolated data centre group inside a region; the unit for fault tolerance
- Location or data centre
- What single-tier providers offer; behaves like a region without zones
How the providers name and structure locations
AWS
AWS regions have codes such as us-east-1 (Northern Virginia), eu-central-1 (Frankfurt), and ap-southeast-2 (Sydney). Each region contains multiple availability zones with a letter suffix, for example us-east-1a. Zone letters are mapped per account, so us-east-1a in one account may be a different physical zone in another. Newer regions are opt-in and must be enabled in the account before use. Service quotas, including the vCPU limits for EC2, are set per region.
Google Cloud
Google Cloud uses region names such as us-central1 and europe-west1, with zones named us-central1-a, -b, and so on. Resources are classed as zonal (a Compute Engine VM), regional (a regional persistent disk or Cloud Run service), or multi-regional (a Cloud Storage bucket in the US or EU location). Quotas are tracked per project and per region.
Azure
Azure regions use plain names such as East US, West Europe, and Australia East. Many regions contain availability zones numbered 1, 2, and 3, and Azure also pairs regions within the same geography for platform-level replication and staged updates. Subscription quotas for virtual machine vCPUs are per region and per VM family.
DigitalOcean, Hetzner, and BinaryLane
DigitalOcean lists data centre regions with short codes such as NYC3, FRA1, SGP1, and SYD1. Several cities have more than one numbered data centre, and Droplets in different data centres in the same city communicate over the public network unless a VPC spans them. Hetzner Cloud offers locations in Falkenstein, Nuremberg, and Helsinki in Europe, plus Ashburn and Hillsboro in the United States and Singapore in Asia, grouped into network zones (for example eu-central) that a private network can span. BinaryLane is an Australian provider with data centres in Australian cities including Sydney and Melbourne, which matters for organisations that must keep data onshore.
What changes when you change region
Choosing a region is not only a latency decision. Several things vary with it.
| Factor | Why it varies | What to check |
|---|---|---|
| Price | Land, power, and tax differ by country | The provider’s price list for the specific region and instance type |
| Service availability | New services and GPU types roll out to large regions first | The service’s region table in the provider documentation |
| Quotas | Limits are granted per region, not globally | The quota page filtered to your target region |
| Data residency | Regulations may require data to stay in a country or the EU | Your legal or compliance requirements before deployment |
| Latency | Distance to users and to dependent services | Round-trip time from your user base and from your other systems |
| Data transfer charges | Traffic leaving a region or crossing zones is often billed | The provider’s data transfer pricing page |
How to choose a location
- Start with legal constraints. If your data must stay in a jurisdiction, that eliminates most regions immediately. EU-based teams often start with Frankfurt, Amsterdam, or the Nordics; Australian teams often start with Sydney.
- Put compute near the data it reads. A web server in one region and a database in another adds round trips to every request. Keep tightly coupled components in the same region, and ideally in the same zone or connected by private networking.
- Then optimise for users. For a global audience, a content delivery network in front of a single region is usually simpler than running the application in many regions.
- Confirm the services you need exist there. Managed databases, GPU instances, and newer AI services are not in every region.
- Compare prices for the same instance size. The difference between regions can be meaningful for steady workloads.
- Check quota headroom in that region. On AWS, Google Cloud, and Azure, open the quota console for the region. On developer clouds, check the account-level server or Droplet limit.
Using zones for resilience
Once the region is chosen, spread stateless servers across at least two availability zones behind a load balancer, and use a managed database option that replicates across zones. On providers without zones, the equivalent is running in two locations in the same country and accepting slightly higher latency between them. Do not confuse zone redundancy with backup: a corrupt write replicates just as fast as a good one, so keep snapshots or object storage backups as well.
Where to go next
For an account on a provider with a full region and zone hierarchy, the listed variants are on the Buy AWS Accounts page. For European locations grouped into network zones, see the Buy Hetzner Accounts page. For Australian onshore hosting, see the Buy BinaryLane Cloud Account page.
Related reading in the Cloud Library:
- Cloud service quotas and limits explained
- Cloud networking basics: VPCs, subnets, firewalls, and floating IPs
- Hetzner Cloud explained: servers, projects, and networking
- BinaryLane explained: Australian cloud servers and data centres
Browse every guide in the Cloud Library, or compare two providers with different location models on the Hetzner vs DigitalOcean page.