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. 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. 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. 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.
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.
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.
AZs shouldn't be confused with AWS 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. They are valuable if your users are concentrated in a relatively small area, as they help reduce latency and meet strict compliance requirements.
List of AWS Regions and AZs
As of April 2022, AWS offers 26 launched Regions and 84 AZs (see table below). Configurations are subject to change.
|Number of AZs
|US East (Northern Virginia)
|US East (Ohio)
|US West (Oregon)
|US West (Northern California)
|AWS GovCloud (US-East)
|AWS GovCloud (US-West)
|South America (São Paulo)
|Middle East (Bahrain)
|Africa (Cape Town)
|Asia Pacific (Hong Kong)
|Asia Pacific (Mumbai)
|Asia Pacific (Seoul)
|Asia Pacific (Singapore)
|Asia Pacific (Sydney)
|Asia Pacific (Tokyo)
|Asia Pacific (Osaka)
|Asia Pacific (Jakarta)
|Mainland China (Beijing)
|Mainland China (Ningxia)
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 US East (Northern Virginia) would be us-east-1a.
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 your cloud environment operates and what it costs.
Whether you use multiple Regions or AZs, you're likely to end up with a higher overall cloud computing bill. On top of the cost to host redundant workloads, you also incur data egress fees when you move data between Regions.
It's easier to predict and optimize costs if you keep 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 you use 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 April 2022:
- $0.0765 in US East (North Virginia)
- $0.0848 in US West (Northern California)
Configuring workloads for multiple AZs is simpler than configuring them for multiple Regions. For most AWS services, you can add or remove AZs within the AWS Console; you just need to change the AZ settings. With Regions, you'll typically have to deploy and configure your workloads separately for each Region you want to use.
When to use Regions vs. AZs
In general, if you're looking just for increased workload redundancy, AZs are the way to go. 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.