You can’t do anything in AWS without picking a region. You can’t navigate the console, launch a server, or even use the SDK. AWS resources have to exist in some physical location. So where should you pick? And based on what?
Many first-time AWS users pick the region closest to them. This is okay to get started, but you should also understand the implications (such as cost, latency, resilience, and regulations) when choosing an AWS region.
Which AWS region is closest to you? Review the AWS global infrastructure map to see your geographical distance to AWS regions. Use cloudping.info to see latency from your browser, cloudping.co for inter-region latency, or awsping (command line tool) to see latencies from a remote server.
The Closest AWS Regions To Major Cities
Some of you will want to just get started quickly and don’t need to know the fine details involved in picking a region. If that’s you, here are the closest geographic regions to some major cities around the world. Take your pick.
|America (San Francisco)
|Oregon / Northern California
|America (New York)
|Northern Virginia / Ohio
|United Kingdom (London)
|Israel (Tel Aviv)
|India (New Delhi)
If you want to calculate your AWS region more scientifically than picking based on geography alone there are a few techniques and tools that we’ll go through that you can use to create a shortlist of suitable regions.
When you have that shortlist, there are some factors to consider such as cost and functionality differences which we’ll also cover. Let’s start by looking at the different ways to find your closest region more accurately.
How To Shortlist AWS Regions
Your first stop when choosing an AWS region should be the AWS Global Infrastructure. On this part of the AWS website, you’ll find important details for each AWS region, such as the number of availability zones per region and proximity to edge locations. From here you can start to make a shortlist.
Don’t be fooled by choosing an AWS region based solely on geographic proximity (i.e drawing a line between two locations). Because data doesn’t travel the internet in direct lines, it has to follow the existing infrastructure of the internet within countries and between them.
Take a look at the infrapedia global internet infrastruture map (above), to see what I mean. You’ll want to take the global infrastructure into account when choosing a region, and consider running latency tests before finalising your choice (more on how to do that below!).
Find Your Nearest AWS Region From Your Browser
A neat way to find the AWS region closest to your current location is the website cloudping.info, created by Michael Leonhard. Cloud ping will show you all the latencies to different AWS regions straight-in your browser.
The main downside of this approach is that it doesn’t allow you to test speeds to regions from arbitrary locations other than your own. To test latencies from different locations we’ll need a tool we can run on different machines.
Find Your Nearest AWS Region Via The Command Line
If you need to automate the process of finding your nearest region, you can use AWS ping, by Eugene Kalinin, which you can find on GitHub.
The source code for AWS ping is quite simple (written in Go) should you needed to modify or extend it to suit your needs. You can use AWS ping to test latencies from different locations, or latencies between your shortlisted regions.
Find Latencies Between All AWS Regions
But, sometimes, the latency you’re after is the latency between the AWS regions themselves, for instance, if you already have a region already chosen.
Factors Which affect The AWS Region You Should Choose
Not all AWS regions are the same with regards to cost and functionality. We’ve looked at some ways you can shortlist AWS regions, but we’ve mostly discussed geographical distance and latency. Let’s now take a look at the factors to consider before finalising your AWS region choice.
Factor 1: Latency
As we’ve already discussed, latency to your customer is an important factor when choosing an AWS region. Be sure to factor in the internet infrastructure surrounding your chosen region, and not just the geographical distance, doing some testing of your own where you can. You’ll also want to test the latency between regions if you choose more than one.
If latency is important to you, there also other AWS services and tools that are worth researching, such as AWS local zones, and AWS edge locations, which allow you to lower the physical distance to your customer, and also advanced routing techniques like latency and geo-based routing which allow you to dynamically find the most performant service to route your customers.
Factor 2: Cost Differences
Not all services cost the same across all regions— the differences in the price can be quite drastic where your choice of region could nearly double your cloud bill. The best way to understand the variation is to add your predicted or current architecture into the the AWS cost calculator to compare between regions.
To give you an idea of the potential price differences, a t4g.xlarge (4 vcpus, 16 GiB RAM) EC2 instance with a 30GB EBS (GP2) will cost you 64.54 USD in North Virginia, as compared with 103.72 USD in Cape town.
Additionally, an often-overlooked cost factor is data transfer, which can be notoriously difficult to predict. Again, to get a high-level estimate of predicted transfer costs your best bet is to use the AWS cost calculator but instead of adding a service, search for “Data Transfer”.
Now of course most of you at this point will be thinking: “Which is the cheapest AWS region?” But pricing varies based on region, so it’s hard to definitively say which AWS region is cheapest. That being said, North Virginia is commonly reported as the cheapest region anecdotally.
Factor 3: Functionality Differences
Not all regions are given equal treatment when it comes to service rollout. AWS states: “Our general policy is to deliver AWS services, features and instance types to all AWS Regions within 12 months of general availability.” (source).
Whilst this is true in many cases, anecdotal evidence shows that some regions can wait years before a service becomes available. So if you want a cutting-edge service, it’s best to use one of the more actively updated regions (e.g. us-east-1). Find the full list of AWS services available in each region here.
Factor 4: Stability Differs Per Region
Not all regions have the same stability. The availability of services between regions has been known to differ, with North Virginia (us-east-1) being notoriously unstable as most service updates are rolled out to that region first.
Honest question: since us-east-1 can objectively be considered the least stable region, why would anyone use it, aside from strict latency requirements?
— Luc van Donkersgoed (@donkersgood) November 25, 2020
Because AWS doesn’t publish any region-specific availability data it’s hard to do a scientific region stability comparison. However in line with general best practices, for high availability, your workloads should be balanced across multiple availability zones, or even regions for redundancy.
Factor 5: Governance Requirements
The final factor to consider when choosing an AWS region are your legal obligations. For compliance with policies such as GDPR it could be necessary for you to store or process data within a certain region, so don’t forget to consider the requirements for locating your data and services when making your choice on which AWS region to choose.
Choose The AWS Region Right For You
Quite a bit of analysis can go into finding the closest, best-fitting AWS region. If you’re just starting with AWS you can choose a region based on practicality. However, when it comes to moving services to production, consider things like latency, cost and functionality before you make your final decision.
If you’re looking to learn more about AWS and the cloud, you should also check out My (Highly) Recommended Books & Courses, and check out the monthly Open Up The Cloud newsletter to stay up to date with cloud news!