AWS Architecture

First, let’s discuss some terms used within the AWS ecosystem.

Architecture Overview

Figure 27-1 shows at a high level what the AWS cloud architecture looks like. AWS is composed of several AWS regions, which are geographically distributed around the globe in order to provide high-quality access to most locations in the world. The AWS regions each have connections to the Internet. The AWS regions themselves also are connected among themselves, but they use long-distance network connections similar to the rest of the Internet.

Figure 17-1.  

Figure 27-1. AWS data center architecture

A single AWS region is composed of one or more AWS availability zones. The AZs within a single region are connected via an extremely high-speed hub network link, as shown in Figure 27-2. The goal is to make access between any two servers within a region to have similar performance characteristics without concern for the AZ in which they are located.

A given AZ is composed of one or more data centers, depending on the size of the AZ.

Figure 17-2.  

Figure 27-2. AWS region and availability zone network performance

As you can see, the network topography is designed to make it easy to build an application within a single region but distributed across availability zones. This distribution is designed to give redundant systems failover opportunities in light of problems with individual data centers, while maintaining the ability for the independent components to communicate with one another at high speeds transparently, without regard to the availability zone they are in.

While you cannot pick what data centers your servers are located in, by putting two servers in two different availability zones, you are guaranteeing that the two servers are in two different data centers.

However, regions are designed so that an entire application would be contained within a single region, and not require high-speed communications with components contained in other regions. Instead, if an application wants to be in multiple regions, multiple copies of the application are typically run independently, one copy within each region desired. This makes it possible for individual geographic regions to have access to an instance of an application locally without suffering the cost of long distance communication links. This is shown in Figure 27-3. This model is supported by the AWS network traffic costing model, which typically allows traffic between AZs within a single region to be free, while traffic destined between regions or out from a region to the Internet to be charged appropriately.

Figure 17-3.  

Figure 27-3. Customer architecture

This architecture is important not only from a cost standpoint, but also from a latency standpoint (region-to-region network latency is higher than AZ-to-AZ). Additionally, this structure gives your application the ability to support various governmental regulations, such as EU Safe Harbor.²

Availability Zones Are Not Data Centers

Within a given account, an EC2 instance in one AZ (such as us-east-1a) and an EC2 instance in another AZ (such as us-east-1b) may safely be assumed to be in distinct data centers.

However, this is not necessarily true when you are using more than one AWS account. When you create an EC2 instance in account 1 that is in AZ us-east-1a, and an EC2 instance in account 2 that is in AZ us-east-1c, these two instances might, in fact, be in the same data center. They may actually be located on the same physical server!

Why is this the case? It is because the AZ names do not statically map directly to specific data centers. Instead, the data center(s) used for “us-east-1a” in one account might be different than the data center(s) used for “us-east-1a” in another account.

When you create an AWS account, they “randomly” create a mapping of availability zone names to specific data centers. This means that one account’s view of “us-east-1a” will be physically present in a very different location than another account’s view of “us-east-1a”. This is demonstrated in Table #table(awsazmappings). Here we show an arbitrary number of data centers (arbitrarily numbered 1 through 8) within a single region. Then, we show a possible mapping between AZ names and those data centers for four sample accounts.

Table 27-3. Unexpected availability zone mappings.

From this, you’ll notice a few things. First, a single AZ for an account can, in fact, be contained in multiple distinct data centers. This means the two EC2 instances you create within a single account and a single AZ may be on the same physical server, or they could be in completely different data centers. Second, two EC2 instances created in different accounts may or may not be in the same data center, even if the AZs are different.

For example, in Table 27-3, if account #1 creates an instance in us-east-1b, and account #3 creates an instance in us-east-1d, those two instances will both be created in data center #3.

This is important to keep in mind for one simple reason: just because you have two EC2 instances in two accounts in two different AZs, does not mean they can be assumed to be independent for availability purposes.

As discussed in Two Mistakes High, maintaining independence of replicated components is essential for availability and risk management purposes. However, when using multiple AWS accounts, the AWS AZ model does not enforce this. The AZ model can be used to enforce this only when dealing within a single AWS account.

Why would you ever want to use more than one AWS account? Actually, this is fairly common. Many companies create multiple AWS accounts used by different groups within the company. AWS might do this for billing purposes, permissions management, or other reasons. Sometimes security policies dictate the use of multiple AWS accounts.

Ever Wonder Why?

[note]Ever wonder why, when AWS announces an outage, they will say that an outage impacts “some availability zones” in a given region, but they do not say which ones?

The reason is because of how the system is mapped: if they have a problem in, say DC#4, that might mean your “us-east-1a,” whereas for the next person it might be “us-east-1c.” They cannot give the name of a specific AZ, because the name of the AZ is different for each account.

Why does AWS use this weird mapping? One of the main reasons is for load balancing. When people launch EC2 instances, they tend not to launch them evenly distributed across all availability zones. In fact, “us-east-1a” is a more common AZ for people to launch EC2 instances than “us-east-1e.” This is governed as much by human nature as anything. If AWS did not do this artificial remapping, AZs earlier in the alphabet would be overloaded, whereas AZs later in the alphabet would be less loaded. By creating this artificial mapping, they are able to load balance usage more effectively.

Maintaining Location Diversity for Availability Reasons

How do you ensure that AWS resources you launch have redundant components that are guaranteed to be located in different data centers and therefore risk tolerant to outages?

There are a couple things you can do. First, make sure that you maintain redundant components in distinct AZs within a single account. If you have redundant components that are in multiple accounts, make sure you maintain redundancy in multiple AZs within each account individually. Don’t compare AZs across accounts.

AWS — Mapping Availability Zones in Multiple Accounts

It is possible in AWS to determine if two availability zones in two different accounts are potentially in the same data center or not. Doing this requires use of the AWS Resource Access Manager and the AWS console.

Login to the AWS console and click on the “Resource Access Manager” service³. On this page, look for the section titled “Your AZ ID” (at the time this was written, it was in the right hand column, about half way down). Figure 27-4 gives an example of what this section looks like.

What you will see is a mapping of AWS Availability Zone names (such as us-east-1a, and us-east-1b) to what are called AZ IDs. You can think of an AZ ID as essentially the name of a specific physical data center.

Figure 17-4.  

Figure 27-4. AWS AZ mapping to data center IDs for a given region in a given account.

The AZ IDs are numbers that are consistent for all AWS accounts. While you cannot compare AZ Names (such as us-west-2a) across accounts, you can compare AZ IDs (such as usw2-az2) across accounts. Using the AZ ID, you can determine if two availability zones in two different accounts are in the same data center or not.

This table provides the Availability Zone Name to AZ ID mapping for a given account in a given AWS region. To check the AZ ID for a different account, login to the console using that account. To check the AZ ID mapping for a different region, select the desired region from the region dropdown in the console’s upper right hand corner.