How To Choose an AWS Region

TL;DR Choosing the best AWS region for your organization is crucial for the success of your cloud infrastructure. Each region has varying levels of latency, cost, and fault tolerance. Picking the wrong one can even affect your team’s development speed, not to mention you may have to redo infrastructure work. It’s important to consider all the ramifications before deploying any resources. Read on to learn more.

Dillon Kanada
Cloud Solutions Architect
Get Help With Choosing An AWS Region!
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Contact form success icon

Thank you for getting in touch!

We will get back to you as soon as possible
(usually within one work day).

Table of Contents -

What is an AWS Region?

AWS regions are geographic locations used to deploy resources in their cloud service.

They can be identified by either their physical location (Ohio) or a unique identifier (us-east-2) that also provides decent insight about the general location and time of launch. There are currently 32 regions worldwide and new locations are constantly being added, although one can usually find an ideal location in the current list.

This is where AWS starts to shine. Regions within AWS are somewhat unique in the cloud space because rather than simply existing in a data center, they are defined as physical locations of clustered data centers. This is in stark contrast to GCP for example, which only defines their zones as single failure domains within a region yet include no mention of what that means. AWS makes sure to point out that their zones are isolated and physically separate from each other by between 1-100km with “ultra-low-latency” links to ensure instant networking. Nothing is entirely foolproof, but you have to admit, AWS leaves a lot less to chance with independent power, cooling, and even physical distance between zones, which can play a critical role in service reliability.

Diagram showing the relationship between AZS and Regions

There are other categories of “zones” scattered throughout their documentation, most notably Local Zones and Wavelength Zones. The former try to move compute and other resources closer to metropolitan areas for low latency, and the latter do the same but focus on the edges of 5G networks rather than large population centers

Local Zones can be an excellent addition for certain applications, especially if there is a need to handle traffic spikes or other events in certain cities.

How To Choose An AWS Region

With those key differences in mind we can finally discuss the hidden factors AWS likes to avoid discussing when they promote their global network.

Service Availability

One major thing Amazon likes to hide away is that not all their services are available in every region at launch.

Just as an example, Application Composer and Clean Rooms were two distinct services recently announced for general availability, but are still only available in a fraction (9 and 11 regions respectively) of the full 32 regions. AWS Backup also added support for Amazon Redshift, but the feature is suspiciously missing in Melbourne, Hyderabad, Zurich, and Spain. This is a common theme - even existing services will often receive delayed features when AWS engineers decide to take the scenic route.

Putting aside delays for a moment, there are many regions with a startling lack of even well established services. One example of this would be DocumentDB, released in January 2019 and still only available in 18 regions. The public chart offered by AWS is horrendously inconvenient for searching so if you want a quick overview I’ve compiled a list of services offered in each region and tallied the results which you can download below. You can also see service availability for some of the more commonly used solutions in AWS right now.

AWS Region Insights Download

Get the download for region insights on services, avg. resource costs, and number of zones per region.

Downloadable content image