* Price calculations using AWS Price List API
Choosing an AWS region is the first decision you have to make when you set up your AWS components. For most services, 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 more than 30 public regions: N. Virginia, Ohio, N. California, Oregon, Cape Town, Hong Kong, Mumbai, Seoul, Singapore, Sydney, Melbourne, Tokyo, Osaka, Jakarta, Hyderabad, Montreal, Frankfurt, Ireland, London, Milan, Paris, Stockholm, Zurich, Spain, Bahrain, UAE and Sao Paulo. There are also 2 non-public regions in the US (GovCloud US-East and GovCloud US-West), 2 regions in China (Beijing and Ningxia) that require a special application process. This number is constantly changing, as new regions are added very frequently.
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. For some regions, it’s not difficult to find a 30% or 70% price difference compared to the cheapest AWS region. For the purpose of this article, I included only a subset of relevant regions (given the very high number of regions available and the fact that new ones are frequently launched by AWS).
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.
Monthly cost:
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 Reserved cost is higher. Lately, I’ve noticed that Reserved savings are comparable across regions. For example, in the scenario below Reserved savings vs. On Demand are about 41%-45% in most regions.
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.
Please note that latencies vary over time and this is just an example for this particular test.
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.
For example, 1TB of EC2 data transfer out to the internet costs about $150 in Sao Paulo or $154 in Cape Town, compared to about $90 in N. Virginia (a 67% and 71% difference, respectively)
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 back in 2016 you had a stable deployment in the N. California region and you were happy with EC2, Auto Scaling and S3 (although you would probably pay 20% more compared to other US regions). If back then you wanted to create a serverless microservice to integrate it with your existing applications in N. California, then you would have had to wait about 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 close to 2 years for Lambda (November 21st, 2016) from the day it was first launched in N. Virginia (January 14th, 2015).
Things haven’t changed much since then. For example, Sagemaker was released in N. California almost 3 years after its launch in N. Virgina back in November, 2019. AWS Backup took almost 1 year to be released in N. California from the time it was announced in N. Virginia. There are many similar examples for other regions and services. 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 was without a particular service:
Here are some more recent examples of services launched in 2018, 2019 and 2020:
And how many days it took for them to be launched in other regions:
Out of this data sample, N. Virginia is the only region where all services are available from day 1. There are some regions which are notorious for taking a long time to get the latest services: Sao Paulo, N. California and Singapore are some examples.
Ireland and Oregon are the two regions where new services and features are in most cases available at the same time as N. Virginia.
Not all regions have the same number of Availability Zones
While all regions have at least 3 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. Most regions have 3 Availability Zones and there are some regions with 4 AZs.
If you’re building an application with very strict availability requirements, then choosing a region with at least 4 AZs might be the best option.
Data transfer between AWS regions can also vary.
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 data transferred to 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.
Keep in mind that these prices vary according to the data origin region. There are regions where intra-region data transfer can start at $0.09 per GB (or even more).
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 likely 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. Many architectures would cost close to 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.
- 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 could be 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.
