(Update) If you are deploying services on AWS, you’ll want to have a clear understanding of each of these components, how they are linked, and how you can use them within your solution to YOUR maximum benefit. We take a closer look at them in this post AWS Global Infrastructure: Availability Zones, Regions, Edge Locations, Regional Edge Caches
When it comes to Amazon Web Services, there are two concepts that are extremely important and spanning across all the services, and that you simply can’t help but be aware of: Regions and Availability Zones. Both of them associate with most of the AWS stuff, and mastering them is crucial to get the best out of them. Nevertheless, many users underrate their importance or even completely ignore the concepts at the base of it. In this post, I’ll try to give you the simplest explanation ever of what are Regions and Availability Zones, and everything you should know to use them at your advantage.
First things first: Regions
Amazon EC2 is hosted in multiple locations all over the world.
It’s quite straightforward that resources geographically close to the client are served faster, so you can immediately get the rationale of creating so many regions all over the world: getting resources closer to who asks them. Right now, AWS has about 10 regions available, three of them in the US and the others spread over Europe, Asia, Pacific, and South America, but stay assured that more of them will be opened in the future.
For many of the AWS services, you will be asked in which region you want to deploy your resources. For example, if you launch an EC2 instance, you will be asked in which region to host it. Each region is totally isolated from the others, and they can talk only via the Internet. Actually, Regions are so isolated that when you view your resources, you’ll only see the resources tied to the region you’ve specified: AWS doesn’t replicate resources across regions automatically.
Splitting Regions in parts: Availability Zones
An Availability Zone is an isolated location inside a region. Each region is made up of several Availability Zones. Each Availability Zones belong to a single region. Also, each AZ (as AWS expert commonly call Availability Zones) is isolated, but the AZs in a region are connected through low-latency links. This picture from the AWS documentation probably explains the whole concept better than a thousand words:
So, we have 3 different scopes here: the whole AWS, Regions, and AZ. According to the AWS service, and specifically for EC2, each resource can belong to one of them. For example, IAM is global, AMIs are regional, instances belong to AZs, and so on.
Taking advantage of the Availability Zones
There are several reasons why a good strategy with regard to AZs might come in handy in several different situations. Just to cite some of the most common use cases, if you distribute your instances across multiple Availability Zones and one instance fails, you can design your application so that an instance in another Availability Zone can handle requests. A sort of emergency load balancer without using an actual load balancer.
Also, you can mix it with Elastic IP addresses to mask the failure of an instance in one Availability Zone: enough you remap the address to an instance in another Availability Zone. Not the best strategy in the long term, but enough quick-and-dirty to make your day in certain situations. Beware though: Amazon maps AZs independently for each account, so your us-east-1a might not be the same location as someone else’s us-east-1a, and you will never know what the actual mapping is.
One last bit of complexity: endpoints
There is one more concept around, and one that I have seen a lot of people getting lost about: endpoints. Long story short: there are several ways to access a service, a region and/or availability zones, and they are called endpoints. In other words, they are URLs acting as an entry point for a web service. Again, they aim to reduce even further the latency of your applications. Not all the AWS services support endpoints though. As I told you already, IAM is a typical example of a global service, and it’s the only endpoint is https://iam.amazonaws.com.
On the other end, stuff like DynamoDB might be accessed through URLs like https://dynamodb.eu-west-1.amazonaws.com. Not a totally new concept, then, neither yet another partition of the AWS resources: endpoints are just the door entrance to global, regional and AZ-related resources in the AWS world. Just as simple as that.