What is an AWS Region?
AWS regions are geographic locations used to deploy resources in their cloud service.
They can be identified by either their physical location (Ohio) or a unique identifier (us-east-2) that also provides decent insight about the general location and time of launch. There are currently 32 regions worldwide and new locations are constantly being added, although one can usually find an ideal location in the current list.
This is where AWS starts to shine. Regions within AWS are somewhat unique in the cloud space because rather than simply existing in a data center, they are defined as physical locations of clustered data centers. This is in stark contrast to GCP for example, which only defines their zones as single failure domains within a region yet include no mention of what that means. AWS makes sure to point out that their zones are isolated and physically separate from each other by between 1-100km with “ultra-low-latency” links to ensure instant networking. Nothing is entirely foolproof, but you have to admit, AWS leaves a lot less to chance with independent power, cooling, and even physical distance between zones, which can play a critical role in service reliability.
There are other categories of “zones” scattered throughout their documentation, most notably Local Zones and Wavelength Zones. The former try to move compute and other resources closer to metropolitan areas for low latency, and the latter do the same but focus on the edges of 5G networks rather than large population centers
Local Zones can be an excellent addition for certain applications, especially if there is a need to handle traffic spikes or other events in certain cities.
How To Choose An AWS Region
With those key differences in mind we can finally discuss the hidden factors AWS likes to avoid discussing when they promote their global network.
Service Availability
One major thing Amazon likes to hide away is that not all their services are available in every region at launch.
Just as an example, Application Composer and Clean Rooms were two distinct services recently announced for general availability, but are still only available in a fraction (9 and 11 regions respectively) of the full 32 regions. AWS Backup also added support for Amazon Redshift, but the feature is suspiciously missing in Melbourne, Hyderabad, Zurich, and Spain. This is a common theme - even existing services will often receive delayed features when AWS engineers decide to take the scenic route.
Putting aside delays for a moment, there are many regions with a startling lack of even well established services. One example of this would be DocumentDB, released in January 2019 and still only available in 18 regions. The public chart offered by AWS is horrendously inconvenient for searching so if you want a quick overview I’ve compiled a list of services offered in each region and tallied the results which you can download below. You can also see service availability for some of the more commonly used solutions in AWS right now.
Resource Cost
The theory is pretty self explanatory - the goal is to reduce cloud costs whenever possible by properly sizing resources and budgeting projects. It’s commonly known that cloud providers will price regions differently depending on their own internalized costs, but it’s not commonly stressed just how extreme the savings can be for certain regions.
Price differences of 20-40% for some services aren’t uncommon depending on where you’re looking to store and process data.
Premiums can even reach as high as >100% so make sure to do some research in alternative regions to save on cost.
We’ve included a chart in the download with common AWS services and their current price for existing regions as an example. Pricing within America is almost always cheapest with the exception of Northern California, where you can usually find a 10-30% premium. Ireland and Stockholm are quite close but Stockholm comes in somewhat lower in most categories, so if price is important it’s the best option in Europe. Regions in Asia have less variation overall but Japan is a smidge more expensive in some cases, so it’s best to go with Seoul in that area unless you absolutely need a region in Japan.
Fault Tolerance
Thanks to the unique behavior of AZs mentioned previously in this article, they can play a huge role in selecting a region. The key benefit of AZs in a standard environment is providing a level of fault tolerance that would normally be difficult in a “regular” data center.
Nearly every AWS service has a convenient toggle or feature that lets you distribute compute, backups, or data across multiple AZs so that even if there’s a black swan event (rare but not impossible) your data is still safe and there’s a much higher chance you can stay up during the zonal outage.
Nearly all regions have 3 AZs at this point, which is a perfectly reasonable amount when you consider how cheap multi-zone deployments can be compared to a multi-region strategy. Amazon has taken steps in recent history to deploy at least 3 AZs in every region but there are still a few exceptions to the rule. Sao Paulo is currently only available in 2 AZs for older accounts, and Northern California has been temporarily limited as well for unknown reasons, although many speculate about capacity issues. A select few regions (Oregon, Tokyo, et cetera) are blessed with a fourth AZ, and Virginia famously has 6 AZs, which might contribute to its status as the most popular region from the provider. Again, details on this in the download.
Unfortunately, the same benefits that resulted in Virginia becoming an extremely popular region in North America have caused it to become one of the less reliable regions, which is another huge factor to consider when looking at fault tolerance in the cloud. In fact, a recent post by StatusGator shows the full extent of the problem. Not only were there over four times as many outages as the next region, the total duration was also vastly longer. The likely cause is due to Virginia’s popularity as a central location in America, but this is just something Amazon doesn’t really like to advertise about their platform. You have to go hunting for it in blogs (👋) and other sources to get the full picture.
When Should I Choose Multiple Regions?
Now that we’ve gone through the largest hidden factors that play an important role in choosing an AWS region, the new question becomes how to effectively scale. Most companies will quickly select a single region and deploy everything there to get off the ground.
It’s important to consider the future at this stage to make sure you don’t need a costly migration to optimize resources in the future.
If you have plans for expansion in Europe, it might make sense to start in Virginia, but when you eventually deploy a second environment in Frankfurt, suddenly the benefits of a coastal region no longer pay off and you’re losing out on the stability at Ohio.
Global Market
As mentioned above, any time you have a somewhat distributed user base the equation becomes much more complex. Certain tasks can stay performant even with a single region, but the easiest way to improve your service can often be offloading stateless resources to multiple regions and reducing their distance from end users.
The difference in latency between Oregon and Virginia might not be noticeable to an American, but jump to another continent and suddenly the multi-region strategy starts to make sense.
Disaster Recovery
Availability zones are vastly improved over a single data center, but they aren’t impervious to all issues. The minute your region has an outage or some form of data loss you’ll regret not pushing at least some of the environment out to multiple regions. The famous 3-2-1 backup strategy still applies even when you’re in the cloud, so if you want to be more tolerant to regional outages you should push for multi-region deployments.
High Availability
Lots of AWS services have native support for global access like S3 and CloudFront, but many others can be troublesome to implement compared to other clouds like GCP and Azure. Even so, it’s critical to make sure that your platform stays online even when there’s a regional outage, and in these cases multi-region is the safe option. The problem in this case is effectively leveraging AWS tools in a way that doesn’t completely bankrupt your company, because...
...multi-region is also famously easy to rack up exorbitant costs.
The Best AWS Region
Now that we’ve gone over some of the hidden metrics you should use when picking a region, there are hopefully some low hanging fruit that should make the decision easier.
- North America? Virginia and Oregon are the two clear winners, but Ohio is an excellent choice if you want more stability. Los Angeles is a tough one unless you absolutely need the low latency in southwestern states.
- Europe? Ireland is the clear frontrunner but Frankfurt is a common pick for its centrality and Stockholm can be an excellent choice for the reduced price.
- Asia Pacific? Tokyo and Seoul get points for having four AZs but finding a good region here is more about user proximity than anything else.
As mentioned above, the question becomes much less clear when you introduce global user bases, disaster recovery, and high availability into the mix. Sending backups to cold storage in another region is easy, but what if you want to prioritize cost at the same time?
How far should you go when addressing high availability, and what services can be skipped entirely or satisfied with native AWS equivalents? These are some of the more difficult questions you’ll need to answer when migrating to AWS, but if you’d like some help we’re always available for a chat! It’s always beneficial to get a second opinion on something that can affect the business years down the road.
