Understanding AWS Regions and Availability Zones for Enhanced Application Reliability

Every day at Rackspace, we talk to new AWS users seeking guidance on how to best take advantage of this powerful public cloud platform. While we have hundreds of AWS specialists ready to talk to you about your specific goals, we also try to provide more general, introductory materials for new AWS users whenever possible. Some of the earliest and most common questions we field from customers revolve around regions and availability zones in the AWS global infrastructure, both of which are foundational to understanding how to build applications on AWS. The AWS global infrastructure is currently comprised of 16 AWS regions worldwide and 42 availability zones, with two additional regions scheduled to come online in 2017.

AWS regions

An AWS 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 does not leave a particular geographic region. The presence of AWS 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 two or more availability zones with each zone hosted in separate data centers from another zone. I’ll explain more later on why having at least two zones in a region is important. The largest AWS region, us-east-1, has five zones. Moving forward, new AWS regions will have three or more zones whenever possible. When you create certain resources in a region, you will be asked to choose a zone in which to host that resource.

AWS availability zones

An availability zone is a logical data center in a region available for use by any AWS customer. Each zone in a region has redundant and separate power, networking and connectivity to reduce the likelihood of two zones failing simultaneously. A common misconception is that a single zone equals a single data center. In fact, each zone is backed by one or more physical data centers, with the largest backed by five. While a single availability zone can span multiple data centers, no two zones share a data center. Abstracting things further, to distribute resources evenly across the zones in a given region, Amazon independently maps zones 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 as us-east-1a for another account. In each zone, participating data centers are connected to each other over redundant low-latency private network links. Likewise, all zones in a region communicate with each other over redundant private network links. These intra and inter-zone links are heavily used for data replication by a number of AWS services including storage and managed databases. Why are availability zones such an important and foundational concept in Amazon Web Services? The diagram below illustrates a region with two zones where only one is 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 zones. By placing cloud instances/virtual servers for each tier in each zone, users are able to eliminate a single point of failure. Amazon Elastic Load Balancers situated at different application tiers ensure that even if an entire zone goes offline, traffic will be directed to the appropriate one. It's worth pointing out that the ELBs "live" outside the zones and are therefore not impacted by the failure of any particular one. ELB is one of many AWS services that have a regional scope and can span across 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 zones is foundational for building a highly available, fault-tolerant application using AWS.

Next up: virtual private clouds

With a basic understanding of regions and availability zones under our belts, we can move on to virtual private clouds, or VPCs — what they are and how they relate to regions and availability zones. In the next post, I’ll 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’ll 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. Stay tuned! Are you new to AWS? Do you have questions about your AWS workloads? Visit Rackspace to find out how our certified AWS professionals can help you.