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

* 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. 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 20 public regions: N. Virginia, Ohio, N. California, Oregon, Cape Town, HongKong, Mumbai, Seoul, Singapore, Sydney, Tokyo, Montreal, Frankfurt, Ireland, London, Milan, Paris, Stockholm, Bahrain 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) 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. For some regions, it’s not difficult to find a 30% or 70% 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.

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 40%-42% 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.

EC2 ping

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.

EC2 ping

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

EC2 ping

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 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:

Product launches

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

Days delay

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.

AZ per region

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.

Inter-region data transfer


  • 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. 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. 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.

Ernesto Marquez


I am the Project Director at Concurrency Labs Ltd, ex-Amazon (AWS), Certified AWS Solutions Architect and I want to help you run AWS optimally, so your applications reliably generate revenue for your business.

Running an optimal AWS infrastructure is complicated - that's why I follow a methodology that makes it simpler to run applications that will support your business growth.

Do you want to learn more? Do you have other questions related to AWS? Click on the button below to schedule a free 30-minute consultation.

Do you have any comments or questions about this post, or my services?