Distributing the Cloud — AWS Architecture — Part 1
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.
However, the cloud makes knowing where your application is located harder. The cloud also makes it harder to proactively make your application more distributed. Some cloud providers don’t even expose enough information to let you know where, geographically, your application is running.
Luckily, larger providers like AWS are better. No, AWS won’t tell you specifically where, geographically, your application is running, since they do not disclose their actual data center locations (I worked at AWS, and I have no idea, specifically, where the data centers are located). While they 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.
First, let’s discuss some terms used within the AWS ecosystem.
An AWS Region is large area of cloud resources that represents a specific geographic area. In general, they represent a portion of an individual continent or country (such as Western Europe, Northeastern Asia-Pacific, and Eastern United States). They describe and document geographic diversity of cloud resources. They are typically composed of multiple Availability Zones (AZs).
An AWS Region is identified by a string representing it’s geographic location. For example, “us-east-1” is used for US East Coast, and “us-west-2” is used for US West Coast (Oregon).
AWS Availability Zone
An AWS Availability Zone is a subset of an AWS Region that represents cloud resources within a specific portion of a region, but are network topographically isolated from each other. They describe and document network topographical diversity of cloud resources. If two cloud resources are in different availability zones, then they can be assumed to be in distinct data centers, even if they are in the same AWS Region. If two cloud resources are in the same availability zone, they may potentially both be in the same data center, floor, rack, or even physical server.
An AWS Availability Zone is identified by a string beginning with the name of the region the AZ is in, followed by a letter ‘a’-’z’. For example, “us-east-1a”, “us-east-1b” and “us-east-1c” are all in the region “us-east-1”, while “us-west-1a” and “us-west-1b” are in the region “us-west-1”.
This is not a term used within AWS vocabulary, but we will use it as we map typical non-cloud terminology into AWS terminology.
A data center is a specific floor, building, or group of buildings that constitute a single location of system resources, such as servers.
Figure 1 shows at a high level what the AWS cloud architecture looks like.
AWS is composed of several AWS Regions (or just 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 are also 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.
In other words, AWS is designed to make availability zones as transparent as possible, but regions as visible as possible.
In the part 2 of this article, we’ll discuss availability zones and their connection to data centers, along with techniques for maintaining location diversity within an AWS environment.
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.
Originally published at www.leeatchison.com on March 3, 2016.