How to choose the right AWS region for your business

Imagine you’re an e-commerce company and the holiday season is approaching. This time of year can make or break your brand, and an outage or Insufficient Capacity Error (ICE) is your worst nightmare. To ensure your service can meet the rise in demand, you request an additional 4,000 instances to support peaks in demand in a specific Availability Zone (AZ) within AWS’s N.California region. But unfortunately, this particular AZ cannot support your needs. So instead, you use two AZs in N.California. Problem solved right? 

Not exactly. While this solves the capacity issue, the enormous cross-AZ data transfer costs mean this is not a viable solution, as the fees will add up to hundreds of thousands of dollars, which you didn’t budget for.

After a deeper dive into your options, you find out that migration to the Oregon region will satisfy your future demand while saving your organization 20% on EC2. Additionally, the move to Oregon is ideal due to a requirement to have this environment located next to a co-location (on-premise data center hosted by a third party) that is close to strategic customers in the area.

This scenario is just one example of the many situations I experienced in my previous role as a TAM (Technical Account Manager) at AWS in which customers had to change regions to accommodate their future growth, budgeting concerns, and other strategic initiatives. 

There are many factors to consider when choosing a region. In my experience, customers operate under the false assumption that cloud infrastructure is infinite, which can make the process of selecting regions quite confusing. As of now (April 2022), AWS has 26 regions with 84 AZs, and not all of them have unlimited capacity or host the same amount or types of infrastructure. 

So how can you select the best fit from the get-go? By figuring out several key metrics and needs. Three of the most important points to think about are latency and performance, capacity management, and, of course, cost. 

1. Latency and performance

Latency and performance are key factors when you run your infrastructure on the public cloud. You can use CDNs to cache your static content and use other network accelerators, but in many cases, you may still want to locate your systems close to your customers, so the location of your customers is probably one of the key reasons for choosing a region. Many customers operate their systems in different continents than their users, but wherever possible, resist this temptation.

Local Zones is another service AWS released a couple of years ago to help place infrastructure closer to customers. These zones gives customers infrastructure capacity that is connected to the main regions and are located in metropolitan areas with no AWS regions present. This gives you the ability to run compute resources even closer to users, but there is a surcharge to take into consideration. Currently, there are 17 local zones available in AWS, but the company plans to add 30 more this year. AWS also announced Wavelength Zones, which are located in the datacenters of Telco providers, providing a closer presence to mobile users.

2. Capacity management

If you’re running large-scale applications that need thousands of instances during peak hours, you may find yourself running out of EC2 capacity (though this is a rare situation, it may occur in popular regions).

Likewise, using a small region may cause you to get ICE (Insufficient Capacity Error) and result in an interruption of your service. One option for overcoming ICE is to be instance-flexible. While AWS provides a variety of options for instance types with different processors, in most cases, there are multiple instance types that can do the job you need. Being flexible can help you avoid ICE because if your optimal choice is unavailable, you can always work with others as well.

In addition to challenges related to ICE, when running in a small region, you may find yourself missing a new feature or service that you would receive in a larger region (for example, when EKS was released, it wasn’t initially available in the N.California region). AWS policy is to deliver AWS services, features, and instance types to all AWS Regions within 12 months of their general availability.

Several regions generally receive new features and services first (N. Virginia, Ireland, and Oregon), but pushing new code and services might result in service disruption as well.

Another consideration is AZ capacity. Since each AZ’s capacity varies, if your system is bound to one AZ with less capacity, you may get an ICE when you run EC2 Spot Instances or launch new On-Demand instances. This risk motivates customers to run on the larger regions like N.Virginia, Oregon, and Ireland, which offer the most capacity in the majority of their AZs. Another option is using the AWS Spot placement score feature, which helps get more visibility and accessibility to the greatest number of instances, enabling customers to determine which region will enable them to get more capacity for Spot Instances.

3. Costs

Cost management is one of the most challenging aspects of the cloud. You start with small workloads and then once you choose a region, it’s difficult to shop around across regions and compare the unit cost of the most common instance types. Instead, you need to check the price of the most common types of instances that you are planning to use (For example M5.large) in each region. As an example, Frankfurt is a much more expensive region than Ireland, and you may find up to a 15% price difference between the same instances in these regions when you check the AWS pricing page. 

Regional data transfer costs are another aspect to take into account. While cross-regional data transfers can be expensive, AWS has created a special rate between N.Virginia and Ohio ($0.1/GB), the same price that is normally allocated for data transfers between AZs.  

While the three factors I’ve focused on here are the main ones that should drive your choice, there are others. A few final tips:

1. Plan and build your solution so it will be agile enough to move with the minimum effort required.
2. Wherever possible, choose one of the largest regions. Larger regions tend to be less expensive because AWS’s pricing model works on an economy of scale, whereas larger regions have a lower TCO. This discount is passed on to customers.
3. Consult with AWS representatives. Map the managed services you will require and make sure that they are all supported in the region you choose.

As you can see, there are many variables you will have to consider when selecting an AWS region. Doing some homework in advance can save you from the tremendous headache of changing your region later on. So do the research, understand your needs/use case, and thoroughly examine your long-term requirements before making your choice. 

Aviram Levy is Head of Product Enablement at Zesty. He has 16 years of professional experience in the IT and cloud industry, most recently as a TAM at AWS.