AWS Regions for Dummies

During the 3rd week of the AWS re:Invent 2020, AWS senior vice president of Global Infrastructure and Customer Support, Peter DeSantis, gave a keynote on AWS's global infrastructure. During this keynote he explained many interesting inner workings of AWS data centers and the new Graviton2 chips.

There is one topic that I am rather interested in, which is how AWS regions work, and how they are different from other public cloud providers. I am aware of these differences before, but Peter's keynote made it more vibrant.

What are AWS Regions and Availability Zones (AZs)?

AWS has the concept of a Region, which is a physical location around the world where we cluster data centers. We call each group of logical data centers an Availability Zone. Each AWS Region consists of multiple, isolated, and physically separate AZ's within a geographic area.

An Availability Zone (AZ) is one or more discrete data centers with redundant power, networking, and connectivity in an AWS Region.

AZ’s are physically separated by a meaningful distance, many kilometers, from any other AZ, although all are within 100 km (60 miles) of each other.

Before there was AWS, Amazon tried to make its data centres on the west coast more resilient. The obvious way is to set up another data centre on the other side of the continent, as far away as possible. However that brings a problem, it is impossible to achieve read-after-write consistency over that distance. So they needed to bring the data centres closer to each other, but not too close. In the end, Amazon found out that if they are placed 10s of miles apart, you can effectively isolate most physical hazards from each other while still achieving full synchronization.

The AWS Regions inherited this design. Each Region contains multiple AZs with speed comparable to local connections while physically separated enough to be outside of any reasonable blast radius. This multi-AZ layout is mandatory for all AWS Regions. In other words, no AZs, no Region.

Moreover, the software and services powering each Region are also separated. They don't talk or depend on other Regions so any Region failures will not affect any other ones. Of course, global services such as IAM and CloudFront are different. They are limited, highly scrutinized, and carefully managed.

What about other clouds?

In comparison, for other clouds, AZ is an optional feature. The description of AZs is also vague. Words such as "usually" and "select" are just not good enough.

So what gives?

Some of the common questions and statements we hear when people are talking about AWS and other clouds are,

  • XXX cloud has more regions than AWS.
  • ZZZ is going to open up an NZ region.
  • Why doesn't AWS have an NZ region?
  • When is AWS going to open an NZ region?

Now you get the idea, for AWS to open up a Region, it is significantly more complex and requires more investments than a single data center. Everything inside and connecting these AZs must meet AWS's strict criteria. So naturally, each Region would need to have more customers to fill a single data center in order to be financially viable. At this moment, we have yet to see any customer's need not able to be fulfilled in the Sydney (ap-southeast-2) Region. Some of the valid reasons for not able to use Sydney are data sovereignty and latency. However, organizations with such requirements are very rare.

Conclusion

Only AWS provides a truly resilient and fault-tolerant cloud infrastructure across all of their Regions. Other public cloud providers simply cannot provide the same capability and consistency. So if you are really serious about your workload and data, there is no other cloud provider to consider.

This article was written by Patrick Li, Cloud Solutions Architect at AC3 and AWS APN Ambassador.