Understand AWS Regions vs. Availability Zones
It's easy to forget about data centers when you run workloads in the cloud. Learn how AWS Regions and Availability Zones differ, and how they affect cloud costs and configurations.
Even when you use the cloud, a physical data center still hosts your data. A data center's location can influence a cloud workload's latency, resiliency and cost. It may also impact the compliance rules that apply to your data.
So, choosing a location should not be taken lightly.
In AWS, you can specify where workloads run with AWS Regions and Availability Zones (AZs). Both enable cloud admins to increase the reliability of workloads through geography and gain some control over where apps and data physically reside. Learn the basics of AWS Regions and AZs, as well as how they differ and how they can influence your workloads.
What is an AWS Region?
An AWS Region is a cluster of data centers in a specific geographic area, such as the Northeastern United States or Western Europe.
Each AWS Region includes multiple AZs. However, each AZ is restricted to a specific AWS Region. You can use multiple AZs within one Region, but you can't use the same AZ across multiple Regions.
It is a best practice to choose a region that is geographically close to users; this reduces latency because data reaches the users more quickly.
This article is part of
What is public cloud? A definition and in-depth guide
In addition, organizations should ensure that the region they choose aligns with any compliance rules they need to meet. For example, regulators may require them to ensure that certain data resides within a specific country.
What is an AWS Availability Zone?
An AZ is a standalone data center or set of data centers within a Region. Each AZ operates independently, so a failure in one won't affect others. In disaster recovery plans, enterprises use multiple AZs to increase redundancy and reliability. However, you should not confuse AZs with Local Zones, Wavelength Zones and AWS Outposts.
AWS Local Zones
AZs shouldn't be confused with Local Zones, which are extensions of a Region. Local Zones let you choose more specific geographic locations, such as Boston or Los Angeles. They are not designed to increase workload redundancy. Their main purpose is to boost performance by hosting workloads in a specific local area. This can minimize latency in situations where users are concentrated in a particular geographic area.
AWS Wavelength Zones
Wavelength Zones are AWS infrastructure hosted in telecommunication providers' data centers. They minimize latency for workloads that need to connect to mobile networks, which is valuable for use cases like deploying IoT devices that rely on mobile networks for connectivity, and for streaming video to mobile devices. However, Wavelength Zones are typically not used for hosting standard applications.
AWS Outposts
AWS Outposts is an on-premises private cloud offering that lets customers build hybrid clouds by deploying AWS services at customers' own sites. Workloads hosted on Outposts are linked to a Region and Availability Zone. But, because the workloads don't reside in an AWS data center, you don't get the same availability guarantees that come with standard availability zones. Amazon considers an Outposts environment to be an "extension" of the AZ associated with it, not a core part of the AZ.
That said, you can mirror Outposts-based workloads across Availability Zones to increase resilience.
List of AWS Regions and AZs
As of October 2024, AWS offers 34 launched Regions and 108 AZs (see following table). Configurations are subject to change.
Availability Zones in a Region are named by letter -- for example, Availability Zone A or Availability Zone B. The code for an Availability Zone is its Region code followed by its specific letter. For example, the code for Availability Zone A in U.S. East (Northern Virginia) would be us-east-1a.
| Region name | Region code | Number of AZs |
| U.S. East (Northern Virginia) | us-east-1 | 6 |
| U.S. East (Ohio) | us-east-2 | 3 |
| U.S. West (Oregon) | us-west-2 | 4 |
| U.S. West (Northern California) | us-west-1 | 3 |
| AWS GovCloud (U.S.-East) | us-gov-east-1 | 3 |
| AWS GovCloud (U.S.-West) | us-gov-west-1 | 3 |
| Canada (Central) | ca-central-1 | 3 |
| Canada West (Calgary) | ca-west-1 | 3 |
| South America (São Paulo) | sa-east-1 | 3 |
| Europe (Frankfurt) | eu-central-1 | 3 |
| Europe (Ireland) | eu-west-1 | 3 |
| Europe (London) | eu-west-2 | 3 |
| Europe (Milan) | eu-south-1 | 3 |
| Europe (Paris) | eu-west-3 | 3 |
| Europe (Spain) | eu-south-2 | 3 |
| Europe (Stockholm) | eu-north-1 | 3 |
| Europe (Zurich) | eu-central-2 | 3 |
| Africa (Cape Town) | af-south-1 | 3 |
| Asia Pacific (Hong Kong) | ap-east-1 | 3 |
| Asia Pacific (Hyderabad) | ap-south-2 | 3 |
| Asia Pacific (Jakarta) | ap-southeast-3 | 3 |
| Asia Pacific (Malaysia) | ap-southeast-5 | 3 |
| Asia Pacific (Mumbai) | ap-south-1 | 3 |
| Asia Pacific (Osaka) | ap-northeast-3 | 3 |
| Asia Pacific (Seoul) | ap-northeast-2 | 4 |
| Asia Pacific (Singapore) | ap-southeast-1 | 3 |
| Asia Pacific (Tokyo) | ap-northeast-1 | 4 |
| Israel (Tel Aviv) | il-central-1 | 3 |
| Middle East (Bahrain) | me-south-1 | 3 |
| Middle East (UAE) | me-central-1 | 3 |
| Mainland China (Beijing) | cn-north-1 | 3 |
| Mainland China (Ningxia) | cn-northwest-1 | 3 |
| Australia (Sydney) | ap-southeast-2 | 3 |
| Australia (Melbourne) | ap-southeast-4 | 3 |
To verify which Availability Zones are available in each Region, use the command aws ec2 describe-availability-zones --region $REGION.
Compare AWS Regions vs. Availability Zones
Regions and AZs both isolate cloud workloads based on geographical location. They also use mirroring to increase a workload's redundancy and availability. This ensures workloads will remain available if one AZ fails. The same is true of workloads running in multiple cloud regions.
Beyond this similarity, Regions and AZs have different implications for how cloud environments operate and their expense.
Configuration
Configuring workloads for multiple AZs is simpler than configuring them for multiple Regions. For most AWS services, users can add or remove AZs within the AWS Console, simply by changing the AZ settings. With Regions, users typically have to deploy and configure workloads separately for each Region used.
Cost
Using multiple Regions or AZs will likely result in a higher overall cloud computing bill. On top of the cost to host redundant workloads, users also incur data egress fees when moving data between Regions.
It's easier to predict and optimize costs by keeping all workloads in the same Region. AWS prices most services on a per-Region basis. The cost of a given service is the same as long as it's hosted in a given Region, no matter which AZ you use within that Region.
When using multiple Regions, it becomes more difficult to predict costs. The price of an EC2 instance in one Region can be higher or lower than running the same instance type in a different Region. For example, compare the On-Demand c6a.large instance costs, as of 2024:
- $0.0765 in U.S. East (North Virginia)
- $0.0954 in U.S. West (Northern California)
When to use Regions vs. AZs
In general, AZs are the way to go for increased workload redundancy. They are simpler to manage from both a cost and an administrative perspective. They also provide the same level of redundancy as multiple Regions.
The main use cases for multiple AWS Regions is for disaster recovery and to serve users located in discrete locations. It also provides high availability and greater fault tolerance.
Editor's note: This article was updated to reflect new AWS Regions and Availability Zones.
Chris Tozzi is a freelance writer, research adviser, and professor of IT and society who has previously worked as a journalist and Linux systems administrator.
