AWS Regions, AZs, Edge Locations and Data Centers

AWS Regions

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

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.

3) Costs

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.

5) Compliance

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.

Availability Zones

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.

3) Costs

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.