Regions and Availability Zones (AZs)

Access the interactive diagram for this lesson here. (It may ask you to create a free account in order to view. You do not need paid features to view this course’s content so you can ignore that!)

Regions and Zones

One of the key points we haven’t discussed yet is how many of the resources we can deploy in AWS need to be deployed in a specific region.

You see, the cloud is simply someone else’s computers. Those computers are physical pieces of equipment that have to reside somewhere.

That somewhere can, in large part, be decided by the customer — you.

The way you do that is by selecting an AWS Region.

The AWS infrastructure is distributed in locations all around the world. Amazon divides the world into Regions which are physical locations with AWS data centers. In each region, Amazon operates multiple, isolated, and physically separate availability zones. An Availability Zone consists of one or more discrete data centers, with redundant power, networking, and connectivity.

Choosing a region

When you start building your AWS infrastructure, you must select the region in which you will be deploying your resources.

You need to weigh in several parameters in order to choose the right region for you.

Legal and Regulatory Compliance

First of all, legal and regulatory compliance is an important factor that you need to consider. Many compliance frameworks, especially those dealing with the protection of personal data, have data residency requirements.

For example, if you’re processing or storing personal information of EU citizens, you need to comply with GDPR, the European General Data Protection Regulation. GDPR requires that you either keep personal data of EU citizens within the EU, or that you inform the citizen that you are transferring their data outside of the EU and that you implement additional security controls.

All of this means that you may want to choose a region according to data residency requirements.

Performance, Availability, and Cost

Second of all, another important aspect to consider is latency. It makes sense to choose a region with close proximity to the location of your user base to minimize latency.

Cost and service availability are two other factors worth taking into account. Some AWS services are priced differently from one region to another. Also, sometimes, newer services and features are deployed to regions gradually, which means that they may not be available to some of those regions for quite some time.

Availability Zones

As we mentioned a moment ago, each region has Availability Zones, or AZs.

An AZ is one or more data centers with redundant power, networking, and connectivity within that AWS Region.

When using AWS services, sometimes they are automatically deployed across AZs, while other times you have to manually select which AZ to deploy the resource into, and whether you want to deploy the services across multiple AZs or not.

The reason to use more than one AZ is to increase availability, fault tolerance, and scalability of your services.

If we look back to our Cloud Architecture Diagram, we can see that we have subnets deployed into two different AZs. We are then deploying duplicate instances across those AZs, as well as a database replica.

That way, if something happens to one of those AZs, like if there’s a natural disaster, a human error, or even a terrorist attack, it’s unlikely to cause the entire region to go down and instead would hopefully only affect one of those AZs.

If that’s the case, then our application can continue functioning as normal because we still have that secondary AZ.

That makes AZs a very valuable feature for business continuity.

Conclusion

That’s it for now in terms of talking about regions and zones…next, we need to talk about one more key aspect of cloud security: understanding shared responsibility.

Go ahead and complete this lesson, and I’ll see you in the next!