We all know the value of distributing an application across multiple data centers. The same philosophy applies to the cloud. As we put our applications into the cloud we need to watch where in the cloud they are located. How geographically and network topologically distributed our applications are is just as important as with normal data centers.
While Amazon AWS won’t tell you specifically where your application is running, they do give you enough information to make diversification decisions. Interpreting and understanding this information, and using it to your advantage, requires an understanding of how AWS is architected.
In part 1 of this article, we talked about the AWS Architecture of regions and availability zones. In part 2, we will go into more detail about how availability zones are structured, and how we can utilize this information.
First, a bit of recap.
Figure 1 shows at a high level what the AWS cloud architecture looks like.
Figure 1: AWS Data Center Architecture
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 between themselves, but using long distance network connections similar to the rest of the internet.
Within a single region, there are multiple availability zones. These AZs are connected via an extremely high speed network, in order to make access between any two servers within a single region be very fast, independent of which availability zone they are actually located in.
A given availability zone is composed of one or more data centers, depending on the size of the availability zone.
Figure 2: AWS Region and AZ Network Performance
Figure 2 shows the network topography within a region. As you can see, AWS 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 each other transparently without regard to the availability zone they are in.
However, regions are designed so that an entire application should 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 allows individual geographic regions to have access to an instance of an application locally, without suffering the cost of long distance communications links. This is shown in Figure 3.
Figure 3: Customer Architecture
This model is supported by the AWS network traffic costing model, which typically allows traffic between availability zones within a single region to be free, while traffic destined between regions or out from a region to the internet to be charged appropriately.
This architecture is important not only from a cost standpoint, but from a latency standpoint, since region-to-region network latency is higher than AZ-to-AZ latency. Additionally, the regions high level geographic location is well known, so your application can support governmental regulations, such as those required by EU Safe Harbor.
Availability Zones And Data Centers
It is important to note that selecting a particular availability zone is not the same thing as picking a particular data center. Not only is this because a single availability zone can be composed of multiple data centers, but because:
Your AZ us-east-1a is not the same availability zone as my us-east-1a
That’s right, you and I have a different view of what data centers a particular availability zone is located in. We will discuss this, and the ramifications of this, in the part 3 of this article.
Architecting for Scale
Want to learn more about this and other topics in availability, scalability, and cloud computing? Get my book, Architecting for Scale, published by O’Reilly Media.