AWS Global Infrastructure 101: Learning About Regions and Availability Zones
Small updates made based on changes in 2019.
In their most recent earnings call (for Q3, 2019), Amazon reported that their Amazon Web Services division had generated $9 Billion in revenues. As impressive as that is, AWS and the entire cloud market still only represents a small slice of the total IT budget worldwide. In fact, while IDC projects the Public Cloud to be a ~$200 billion market by 2020, it also projects the total IT budget in 2020 to be $2.7 trillion. Public cloud adoption is accelerating but the market opportunity is even greater than most people think since we are nowhere near market saturation. The reality is that for most companies, AWS and other public clouds are largely untapped resources and many users are only beginning to familiarize themselves with what the Public Cloud has to offer.
To help those who are new to AWS and desire to learn more, I will be writing some 101 and 201 blog series that walk readers through some core concepts and services. Along with many of these posts, I will also be posting some whiteboard and demo videos.
The first such series will be on the important topic of Virtual Private Cloud or VPC. We will be walking though the components of a VPC, including what comes with a default VPC. That will be followed by a deep dive on how to build a custom VPC and the impact it will have on network and application designs. But before jumping into a discussion on Virtual Private Clouds, it is important we understand the concept of Regions and Availability Zones since they are foundational to building on top of AWS.
The AWS Global Infrastructure is currently comprised of 22 geographic Regions worldwide and 69 Availability Zones with plans for more Regions and Availability Zones in the future.
Amazon Web Services Region
A Region is a geographical location with a collection of Availability Zones mapped to physical data centers in that Region. Every Region is physically isolated from and independent of every other Region in terms of location, power, water supply, etc.. This level of isolation is critical for workloads with compliance and data sovereignty requirements where guarantees must be made that user data not leave a particular geographic region. The presence of Regions worldwide is also important for workloads that are latency sensitive and need to be located near users in a particular geographic area.
Inside each Region, you will find 2 or more Availability Zones with each AZ being hosted in separate data centers from another AZ. More later on why having at least 2 Availability Zones in a Region is important. The largest AWS Region, us-east-1, has 6 Availability Zones. The current standard for new AWS Regions moving forward is to have 3 or more Availability Zones whenever possible. When you create certain resources in a Region, you will be asked to choose an Availability Zone in which to host that resource.
While each Region is isolated physically from every other Region, they can communicate with each other over the Amazon Global Network. This global network is a redundant 100GBE private network that traverses the globe, running through and between each AWS Region. With regional connectivity, user cans build applications that are global in reach and can survive the failure of even an entire Region. AWS can also leverage connectivity between Regions to replicate data, such as S3 object storage data or Elastic Block Storage snapshots, at the users’ discretion. An example of this can be seen in the diagram below which was shared by Pinterest.
I talk more about Availability Zones below but what is worth noting here that by replicating data across regions and using Amazon’s Route 53 managed DNS, it is possible to survive or recover from the failure of an entire region since the failure of any region should have minimal to no impact on any other regions.
Amazon Web Services Availability Zone
An Availability Zone is a logical data center in a Region that is available for use by any AWS customer. Each AZ in a Region has redundant and separate power, networking and connectivity to reduce the likelihood of a two AZs failing simultaneously. A common misconception is that a single AZ = a single data center. In fact, each AZ is backed by 1 or more physical data centers with the largest AZ being backed by at least 5 data centers. While a single AZ can span multiple data centers, no two Availability Zones share a data center. Abstracting things further, to distribute resources evenly across the Availability Zones in a given Region, Amazon independently maps AZs to identifiers for each account. This means the us-east-1a Availability Zone for one account may not be backed by the same data centers or physical hardware as us-east-1a for another account. As pointed out to me by Corey Quinn from the Last Week in AWS Newsletter, the one odd exception is us-east-1f where accounts do share the same data centers and hardware.
In each Availability Zone, participating data centers are connected to each other over redundant low-latency private network links. Likewise, all Availability Zones in a region communicate with each other over redundant private network links. These Intra-AZ and Inter-AZ links are heavily used for data replication by a number of AWS services including storage and managed databases.
So why are Availability Zones such an important and foundational concept in Amazon Web Services? The diagram below illustrates a Region with 2 Availability Zones where only one of the AZs are being utilized. The architecture mirrors what a typical three-tier application running in a user’s single on-premises data center may look like. While there are redundant servers running in each tier, the data center itself is a single point of failure.
In contrast to this architecture, the diagram below illustrates the recommended practice of spanning an application across multiple Availability Zones. By placing cloud instances/virtual servers for each tier in each AZ, users are able to eliminate an AZ as a single point of failure. Amazon Elastic Load Balancers (ELB) situated at different application tiers ensure that even if an entire AZ goes offline, traffic will be directed to the appropriate AZ. It’s worth pointing out that the ELBs “live” outside the AZs and are therefore not impacted by the failure of any particular AZ. ELB is one of many AWS services that have a regional scope and can span across Availability Zones in a given Region. Other services like Route 53 is global in scope, as shown below, and provides services to multiple Regions.
This ability to leverage multiple Availability Zones is foundational for building a highly-available, fault-tolerant application using Amazon Web Services.
Next Up: Virtual Private Clouds
With a basic understanding of Regions and Availability Zones under our belts, we can move on to Virtual Private Cloud (VPC) — what they are and how they relate to Regions and Availability Zones. In the next post, I will break down the components of a VPC and explain the concept of a default VPC which is always assigned to each AWS account. Then we will walk through how to build custom VPCs and how a properly configured VPC design can lay the groundwork for building a highly secured production environment. So, stay tuned.
Originally published at cloudarchitectmusings.com on February 7, 2017.
