The basics of AWS Regions and Availability Zones
We’re going to treat this article as a sort of AWS 101 — it’ll be a quick primer on AWS Regions and Availability Zones that will be useful for understanding the basics of how AWS infrastructure is organized.
We’ll define each section, then clearly list the current availability, and sprinkle in some best practices as well.
And don’t worry if all this comes too fast — if you’re new to AWS you can check out our AWS Fundamentals Learning Path to get you on a structured plan with hands-on AWS experience.
What are AWS Regions?
AWS Regions are separate geographic areas that AWS uses to house its infrastructure. These are distributed around the world so that customers can choose a region closest to them in order to host their cloud infrastructure there. The closer your region is to you, the better, so that you can reduce network latency as much as possible for your end-users. You want to be near the data centers for fast service.
What AWS Regions are currently available?
As of November 2019, there are 23 AWS Regions:
Region Name | Region |
US East (Ohio) | us-east-2 |
US East (N. Virginia) | us-east-1 |
US West (N. California) | us-west-1 |
US West (Oregon) | us-west-2 |
Asia Pacific (Hong Kong) | ap-east-1 |
Asia Pacific (Mumbai) | ap-south-1 |
Asia Pacific (Osaka-Local) | ap-northeast-3 |
Asia Pacific (Seoul) | ap-northeast-2 |
Asia Pacific (Singapore) | ap-southeast-1 |
Asia Pacific (Sydney) | ap-southeast-2 |
Asia Pacific (Tokyo) | ap-northeast-1 |
Canada (Central) | ca-central-1 |
China (Beijing) | cn-north-1 |
China (Ningxia) | cn-northwest-1 |
EU (Frankfurt) | eu-central-1 |
EU (Ireland) | eu-west-1 |
EU (London) | eu-west-2 |
EU (Paris) | eu-west-3 |
EU (Stockholm) | eu-north-1 |
Middle East (Bahrain) | me-south-1 |
South America (Sao Paulo) | sa-east-1 |
AWS GovCloud (US-East) | us-gov-east-1 |
AWS GovCloud (US-West) | us-gov-west-1 |
What AWS Regions have the most services?
Not all regions are created equally. These regions have more services than others in their general areas:
- Americas: US East (N. Virginia), US West (N. California)
- Asia Pacific: Singapore, Sydney, Tokyo
- EU: Frankfurt, Ireland
Best practices for choosing AWS Regions
In general, try to follow these best practices when you choose a region, to help ensure top performance and resilience:
- Proximity: Choose a region closest to your location and your customers’ location to optimize network latency.
- Services: Try and think about what are your most needed services. Usually, the newest services start on a few main regions then pop up in other regions later.
- Cost: Certain regions will cost more than others, so use built-in AWS calculators to do rough cost estimates to inform your choices.
- Service Level Agreement (SLA): Just as with cost, your SLA details will vary by region, so be sure to be aware of what your needs are and if they’re being met.
- Compliance: You may need to meet regulatory compliance needs such as GDPR by hosting your deployment in a specific — or multiple regions.
What are AWS Availability Zones?
An AWS Availability Zone (AZ) is the logical building block that makes up an AWS Region. There are currently 69 AZs, which are isolated locations— data centers — within a region. Each region has multiple AZs and when you design your infrastructure to have backups of data in other AZs you are building a very efficient model of resiliency, i.e. a core concept of cloud computing.
See the below image from AWS documentation for a visual representation of Availablity Zones within Regions.
Advice for using AWS Availability Zones
There are several reasons why a good strategy with regard to AZs comes in handy in several different situations. Just to cite some of the most common use cases, if you distribute your instances across multiple Availability Zones and one instance fails, you can design your application so that an instance in another Availability Zone can handle requests. This is like an emergency load balancer without using an actual load balancer.
In general, AWS Availability Zones give you the flexibility to launch production apps and resources that are highly available, resilient/fault-tolerant, and scalable as compared to using a single data center. Having more options and backups is better!
Accessing regions and availability zones via endpoints
There is one additional concept that can be helpful to be aware of when thinking about regions and AZs: endpoints.
In a nutshell, endpoints are specific URLs that act as an entry point for a web service, and many AWS services will have an endpoint based on its region/AZ. Endpoints aim to reduce further the latency of your applications, but not all AWS services support endpoints with regions/AZ data in the naming convention. Certain global services such as IAM will have a single endpoint: iam.amazonaws.com
, but a good way to think about it is that most services that are related to a resource (such as an EC2 instance or a DB) will have an endpoint that references its geographic location, such as dynamodb.eu-west-1.amazonaws.com
.