Save yourself a lot of pain (and money) by choosing your AWS Region wisely

* Price calculations using AWS Price List API (2019-10-17)

Read full article.

Here is an excerpt below.

Choosing an AWS region is the first decision you have to make when you set up your AWS components. You can’t do anything in the AWS Management Console, SDK or CLI without choosing a region. Most AWS customers choose one based on proximity to themselves or to their end users, which sounds like a sensible thing to do.

However, proximity alone is not enough. There are a lot of other factors to consider when choosing a region. Since my goal is to make applications grow on AWS, I’m always looking for factors that will make a difference. For example, AWS cost, feature selection, as well as the speed and resiliency of your AWS components.

So let’s get started…

AWS Regions

You’re probably familiar with AWS Regions, but let me start with the basics, just in case. A region is a geographic area where AWS has data centers. Each region has 2 or more Availability Zones, which are independent data centers that are located close to each other. Availability Zones are used for redundancy and also for data replication. For services such as EC2, you can choose which AZ you want your instances to be launched into.

As of today, there are 16 public regions: N. Virginia, Ohio, Montreal, London, Paris, Ireland, Stockholm, Oregon, Singapore, Frankfurt, Seoul, Tokyo, Mumbai, Sao Paulo, N. California and Sydney. There are also 2 non-public regions in the US (GovCloud US-East and GovCloud US-West), 2 regions in China (Beijing and Ningxia) and 1 region in Japan (Osaka) that require a special application process.

If most of your users access your applications from within North America, then it typically makes sense to deploy your software in an AWS region located in the US or Canada. Sometimes, due to regulatory reasons you might be forced to choose a particular region - there are laws that mandate certain data to be stored in a particular country.

But there are a lot of other factors one has to consider when choosing a region. Here are a few…

Cost varies by region - choose the wrong one and you could end up paying a lot more

I use the AWS Price List API a lot. I use it to programmatically calculate the cost of every configuration I make. I wrote tools that calculate and sort total cost by region, and I discovered substantial differences in AWS price among regions. When I say substantial, I mean more than a 170% difference in some cases. For some regions, it’s not difficult to find a 30% or 75% price difference compared to the cheapest AWS region.

Take the following example:

1 ELB sends traffic to 5 c5.large instances running Amazon Linux in the same Availability Zone. Each instance has 20GB of EBS SSD storage, and each instance receives 100GB/month from the ELB and sends 1TB/month back to the ELB - therefore the ELB processes 5.1TB/month.

Here are some highlights from these results:

• N. Virginia is typically the cheapest region - there might be exceptions, but so far I haven’t encountered one.
• It costs 52% more to deploy this infrastructure in Sao Paulo compared to N. Virginia. It’s worth noting that price differences have decreased since the first time I published this article, when Sao Paulo was 92% more expensive.
• Not all regions in the US cost the same. N. California would cost 21% more compared to N. Virginia or Oregon. Considering geography, Oregon could be a much better alternative for this deployment (it’s relatively close to California and cheaper).
• I would consider N. Virginia to be my first option, unless latency to my end users is unacceptable (more on that below).
• I would avoid Sao Paulo, unless I absolutely had to deploy in that region due to really bad latency or regulation.

Reserved EC2 Instance Cost and Savings vary by region

If you use EC2, chances are it is an important portion of your AWS bill. In this case, it makes sense to consider purchasing Reserved EC2 instances and save in many scenarios up to 40% in EC2 compute cost. Well, it turns out EC2 Reserved pricing varies by region. Not only the final cost, but also the percentage of savings vs. On Demand pricing.

The following chart shows different EC2 Reserved scenarios by region for a Linux m5.large EC2 instance on a 1 year term, All Upfront. You can hover on the chart to see more details regarding final cost and savings vs. On Demand.

As you can see, there are regions where not only Reserved cost is higher, but also Reserved savings are lower. For example, in N. California cost is higher compared to other US regions and savings are about 30% compared to On Demand, while savings in other US regions are about 40%.

For more on EC2 Reserved Instances, you can take a look at this article in our blog.

Regions have different latencies and data transfer speeds

Let’s say you discover that a particular configuration is more expensive in its current region and now you want to find a cheaper alternative in a different region.

Let’s take the example of N. California and Oregon. In some configurations, N. California can be about 20% more expensive compared to N. Virginia. But Oregon is typically the same price as N. Virginia. Let’s say I can deploy most of my components in Oregon, but I’m concerned about latency.

I ran a test that measures latency between EC2 instances in different regions. The table below shows the average time in milliseconds it took for an EC2 instance in region A to receive a ping response from an EC2 instance in region B. My sample size is 1,000 requests per each calculated value.

A word of caution: there are many factors that can affect latencies, which can vary significantly depending on when you execute a test, AZs and even the specific EC2 instances the test was executed on. Therefore, I only take these tests as a very high level reference.

In this particular test Sydney is the region that performed the worst. It took an average of 434ms to ping EC2 instances in other regions. It was followed by Sao Paulo with 415ms and Singapore with 388ms.

Latency between Oregon and California was 41ms. Given that N. California compute costs are in some cases 20% higher than Oregon, moving compute power from N. California to Oregon might be a suitable alternative - if your application can tolerate an extra latency of 41ms. For some reason, this test execution showed a latency of 375ms between N. California and Oregon, which was unusually high.

Overall, Ohio and N. Virginia offer the best latency between two regions (23ms), which makes Ohio a great option as a failover region for applications deployed in N. Virginia.

I ran a similar test, but this time uploading a 1MB file from EC2 to S3. Ohio showed the best intraregion EC2-to-S3 transfer time across all regions, with 81ms.

… and one for 10MB from EC2 to S3. Ohio showed the best intraregion EC2-to-S3 transfer time across all regions, with 356ms.

Consider the type of resource that is most important to you (i.e. compute, data transfer, latency, storage, etc.)

From the ELB/EC2 example in this blog post, we could see a maximum price difference of 52% in a typical ELB and EC2 architecture. But if we look closer at specific resource requirements, the price differences can be even steeper. 

Or take a m5.large EC2 instance. If you launched one in Sao Paulo, you would pay 59% more compared to N. Virginia. If you thought N. California would be the same price as N. Virginia, you would actually pay 17% more.

That’s why it’s important that you understand what type of AWS resources your applications consume the most, so you can make a much better decision regarding your AWS region.

Not all services are available in all regions (some take a VERY long time before they are)

Let’s say you have a stable deployment in the N. California region and you are happy with EC2, Auto Scaling and S3 (although you would probably pay 20% more compared to other US regions). Do you want to create a serverless microservice that integrates with your existing applications in N. California? Well, you would have had to wait 500 days for API Gateway to be available in N. California (Nov 21st, 2016) from the day it was first announced (July 9th, 2015). Or more than 2 years for Lambda (November 21st, 2016) from the day it was first announced in N. Virginia (November 13th, 2014).

This can be a serious issue for your application, especially if you have a multi-region deployment and suddenly realize you don’t have all the AWS components you need in all the regions your application will be deployed to.

I put together the following table, which tracks AWS services that were announced in 2015 and the dates in which they were released in different regions:

And this table tells you how many days each region has been without a particular service, as of January 5th, 2018.

Out of this data sample, N. Virginia is the only region where all services are available from day 1. Of these services, Sao Paulo is the region where they’ve taken the longest to become available (average of 721 days, if at all), followed by N. California (509 days) and Singapore (385 days).

Ireland and Oregon are the two regions that follow N. Virginia in terms of feature availability.

Not all regions have the same number of Availability Zones

While all regions have at least 2 Availability Zones, the number of AZs varies by region. For example, North California has 3 Availability zones, while North Virginia has 6 AZs. Actually N. Virginia is the only region with 6 AZs. Ten regions have 3 Availability Zones and four regions have only 2 Availability Zones.

Why does this matter? If you are building an application with strict availability requirements, you should probably stay away from those four regions that only have 2 Availability Zones. If one AZ in those regions is temporarily unavailable (which can happen - for example June 4th, 2016) you would be left with only 1 AZ to process all your transactions. When there is only 1 AZ left, there will be various failover mechanisms triggered by AWS and by other customers, bringing more load to that one AZ, which will put your application in a potentially risky situation.

Basically, if you have high availability requirements then you should stick to those regions with 3 AZs (Tokyo, Sao Paulo, N. California, Ireland, Sydney, Singapore, Oregon, Ohio, Paris, Frankfurt) or N. Virginia, which has 6 AZs.

All data transfer between AWS regions costs the same, except for one region

Let’s say you want to create data backups between regions. Your main region is N. Virginia and you want to copy all your data to a different region. You would pay $0.02 per GB of data transferred to any region in the world, except Ohio. For Ohio, you would pay $0.01 per GB. This is makes Ohio the best option for data backups for N. Virginia, together with an expected lower latency.

Conclusions

• Building applications that will reliably grow starts with choosing the right AWS region.
• Not all regions are created equal! There are substantial differences in price, performance, number of AZs and product selection among AWS regions.
• If you want to have the cheapest prices, best selection of products and highest number of Availability Zones, it really comes down to N. Virginia. This region is followed closely by Ireland, Oregon and Ohio.
• Sometimes there are requirements that may force you into using a particular region, such as compliance and latency. Barring these, you should stick to any of these 4 regions, preferably N. Virginia.
• Choosing any region outside of N. Virginia, Ireland, Oregon or Ohio means you could end up with only 2 AZs, probably pay more and you will have to wait several weeks - even months - before new services are available.
• Of all regions, Sao Paulo is the one I’d recommend the least. Most architectures would cost almost double compared to the cheapest AWS regions and it has ranked last in all of my inter-region latency tests - plus, you would have to wait several months before new services are available in it.
• N. California is the US region I’d recommend the least. EC2 charges can be 15%-30% more expensive compared to N. Virginia and it also takes several months before new services are available in it. It took roughly two years before Lambda and API Gateway were available in this region! IoT took roughly one year and Machine Learning is not yet available. It took 117 days before ECS became available here.
• Ohio is a very interesting region to implement failover for N. Virginia. Oregon has been a very popular region for this purpose, so it’s good to have a new alternative with better latency and the lowest data transfer cost from N. Virginia. Ohio also has a decent service selection. Just keep in mind that there are some missing services compared to N. Virginia.

As you can see, there are a lot of factors to consider when choosing the right AWS region. Not everything is about proximity to your end users. Choosing your AWS region wisely can save you the pain of overspending thousands of dollars and potentially hindering the growth of your applications.