AWS Regions, AZs, Edge Locations and Data Centers
AWS is one of the most distributed cloud providers over the globe. AWS provides multiple AWS Regions, which are further divided into Availability Zones and Local Zones. Understanding AWS's Global Infrastructure is critical to having an application that can scale and also provide the lowest latency for its users.
An AWS Region is a physical location in the world that Amazon uses to host its infrastructure. AWS has one of the largest global footprints among cloud providers, clocking in at 26 regions at the time of writing this article!
AWS Regions are currently available in North America, South America, Europe, China, Asia Pacific, South Africa, and the Middle East. AWS continuously builds data centers in new regions. There are currently 8 new AWS Regions planned to be built.
AWS has currently one AWS Region in India, located in Mumbai. It has also planned to build another AWS Region in Hyderabad.
An AWS Region name has two components - a "Region Name" and a "Code". The Region Name consists of the general location of the AWS Region along with a city name. For example, US West (Oregon), US East (N. Virginia), and Europe (Frankfurt). The Code is a shortened version of the general location along with a number. The Codes for the region mentioned earlier are us-west-2, us-east-1, and us-central-1 respectively. Knowing both the Region Name and respective Code is important when choosing where to host your applications.
Current AWS Regions List
|AWS Region Name||Code|
|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|
|Africa (Cape Town)||af-south-1|
|Asia Pacific (Hong Kong)||ap-east-1|
|Asia Pacific (Jakarta)||ap-southeast-3|
|Asia Pacific (Mumbai)||ap-south-1|
|Asia Pacific (Osaka)||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|
|Middle East (Bahrain)||me-south-1|
|South America (São Paulo)||sa-east-1|
|Mainland China (Beijing)||cn-north-1|
|Mainland China (Ningxia)||cn-northwest-1|
In this section, we understood what AWS Regions are and the components of an AWS Region name. Let's dive deeper into understanding how to pick an AWS Region and what are Availability Zones.
Best Practices For Choosing AWS Regions
Choosing the right AWS Region for your application is critical for the success of your application and its growth. Let's look at five best practices for choosing the right AWS Region:
1) Proximity To Users
One of the most important factors in picking a region is the proximity to the application's users. The network latency is directly proportional to the distance between the user and the network. The closer your users are to an AWS Region, the lower the latency.
When you are choosing the first AWS Region for your application, try to select the region which will serve the maximum amount of potential new users. You can repeat this process for choosing the next region - pick regions that will serve the maximum amount of users with the lowest latency.
If you are unsure which region provides the best latency, you can run a few tests in these AWS Regions to determine which one has the lowest latency.
2) Service Offerings
Another factor is the service offerings in an AWS Region. AWS typically will try to have all its services (like AWS EC2, AWS S3, etc.) across all its regions, but sometimes there could be cases where some regions are missing a service - either temporarily or permanently. Hence, it is important you check if all the services you require for your application are present in the AWS Region you are planning to choose. You can refer to AWS's official documentation which lists the available services per region.
One more factor is larger AWS Regions are usually the first to offer newer services, features, and software releases. In case you plan to use the latest services from AWS as soon as they are available, then you might not be able to pick a smaller/newer AWS Region.
AWS services are priced differently from one AWS Region to another. Some regions have lower costs for certain services than other regions, which can result in a lower bill.
When choosing an AWS Region around a large area like North America, you can evaluate the cost of the services your application requires in each region per year and choose the region which costs the lowest but still offers good network latency.
4) High Availability and Fault Tolerance
After choosing an AWS region, you may also have to consider selecting a specific Availability Zone or AZ (which we will discuss in the next section) for your applications. AZs enable high availability and fault tolerance and hence should be chosen carefully. Most AWS Regions offer 3 AZs, but in case your application demands more AZs there are a few AWS Regions that offer up to 6 AZs.
Regarding high availability, you can choose to pick a completely different AWS Region to act as the Disaster Recovery Region or DR Region. Picking a DR Region depends on factors like latency between the Primary Region (your first region) and the DR Region, availability of services, and your disaster recovery strategy.
Finally, sometimes due to Government regulations or restrictions, you might be forced to choose only from a shortened list of AWS Regions that are compliant. In these cases, local regulation compliance overrides other evaluating factors.
For example, a country might pass a law stating that the bank information of its citizens should be stored within the country's borders. In such a case, using an AWS Region which is not present in this country for a bank application is not possible.
In conclusion, while picking an AWS Region keep the following factors in mind - latency, services, costs, availability, and compliance.
AWS Regions are further divided into Availability Zones or AZs short. An Availability Zone is essentially one physical data center located in an AWS Region. AZs have redundant power, networking, and connectivity. This enables applications to be more highly available, fault-tolerant, and scalable than what would be possible from a single data center.
AWS Regions have between 3 to 6 AZs each. The 26 AWS Regions offer a total of 84 Availability Zones. You can choose to deploy your application in one, a few, or all the AZs available, as per your application's requirements. Another strategy may involve deploying your databases to one AZ and your application layer to another AZ. AZs also help in achieving high availability in a single region by replicating databases/applications over multiple AZs.
Similar to AWS Regions, Availability Zones also follow a standard naming convention. AZs are named by using the AWS Region followed by a letter. For example, the AWS Region US West (Oregon) / us-west-2 has the availability zones as us-west-2a, us-west-2b, us-west-2c, and us-west-2d.
AWS Regions vs. Availability Zones
Both Regions and Availability Zones offer the flexibility to run highly available and fault-tolerant systems. But which of these two should you choose in case you want to make your application highly available?
There are three factors that you can consider while making this choice:
1) Distribution Scale
The first factor to consider to the distribution scale of your application - is your application serving one location or multiple locations? If your application needs to serve a global customer base with the lowest latency possible, then you need to consider multiple AWS Regions. On the other hand, if your application mainly serves one locale and can take a hit on latency for other locales, then choosing one AWS Region and deploying on multiple Availability Zones might be the optimal choice.
One more factor that can influence your distribution scale is regulations that dictate availability over multiple regions rather than just one region.
2) Maintainance Overhead
When scaling by AWS Region vs Availability Zone, the maintenance overhead is much higher while dealing with multiple AWS Regions. When you are locked to one AWS Region, managing multiple Availability Zones is relatively easy. But when you start to scale to different AWS Regions, then you need to manage AWS services independently in each region and also deploy your application separately in each of these regions. Hence, you might need dedicated teams to manage each region or write extensive Infrastructure as Code (IaC) to manage these regions.
Like the maintenance overhead, costs also go up while dealing with multiple regions. Billing is calculated per region and you need to account for the extra services you would employ to connect multiple regions (like VPC Peering).
So far we have learned what AWS Regions and Availability Zones are, and how to choose between these options when scaling your application. Let's now look at a relatively new infrastructure offered by AWS called AWS Local Zones.
AWS Local Zones
AWS Local Zones are an extension of an AWS Region which enable closer proximity to users resulting in lower latency. These are dedicated data centers located in an AWS Region but distributed in more than one city in that AWS Region. AWS currently offers Local Zones in 17 cities in the United States of America. In 2022, AWS announced the launch of 32 new Local Zones in metropolitan areas around the world.
AWS Local Zones are disabled by default and need to be enabled using the AWS Console. Once enabled, AWS Local Zones behave similarly to Availability Zones and can be used to launch EC2 Instances and utilize other AWS services. One drawback of AWS Local Zones is that they might not have all the services offered in an AWS Region. But AWS Local Zones still do offer the most commonly used services like Amazon Elastic Compute Cloud (EC2), Amazon Elastic Block Store (EBS), Amazon ElastiCache, and Amazon Relational Database Service (RDS).
The main difference between using the default Availability Zones present in an AWS Region vs using AWS Local Zones is the latency difference. AWS Local Zones are designed to provide single-digit millisecond latency to applications, compared to AWS Regions which provide tens of milliseconds of latency. This is very important for applications that depend on low latency. A few example use cases where AWS Local Zones can be beneficial are:
- Real-time multiplayer gaming over the cloud
- Media and entertainment content creation
- Machine learning inference
- Live video streaming
Since AWS Local Zones are an extension of AWS Regions, the naming convention uses the AWS Region followed by an identifier that indicates its physical location. For example, here are the AWS Local Zones present in US West (Oregon) / us-west-2:
|Parent Region||Zone Name||Location (metro area)|
|US West (Oregon)||us-west-2-den-1a||Denver|
|US West (Oregon)||us-west-2-las-1a||Las Vegas|
|US West (Oregon)||us-west-2-lax-1a||Los Angeles|
|US West (Oregon)||us-west-2-lax-1b||Los Angeles|
|US West (Oregon)||us-west-2-phx-1a||Phoenix|
|US West (Oregon)||us-west-2-pdx-1a||Portland|
|US West (Oregon)||us-west-2-sea-1a||Seattle|
- In this article, we first learned the core component of AWS's Global Infrastructure - AWS Regions. Then we understood what best practices to follow when choosing AWS Regions for your application.
- Then we explored Availability Zones (AZs) and how to choose between AWS Regions and AWS AZs when scaling your application to be highly available.
- Finally, we took a look at AWS Local Zones which offer ultra-low latency for your applications and followed up with the possible use cases for AWS Local Zones.
- Also, we understood the naming convention used for AWS Regions, Availability Zones, and AWS Local Zones.