AWS Regions and Availability Zones
Task Two | Microsoft Azure: Part 1 | Overview of Azure Services
These two videos will introduce you to Microsoft Azure services, and will walk you through creating your first service within it.
AWS regions and availability zones. One of the most important and misunderstood fundamentals of AWS is the concept of regions and availability zones. It is imperative that you get a good feel of what these concepts refer to, and how they are different from each other, as they will guide your application architecture decisions. In particular, relating to geographic proximity to your end users, as well as highly available application design geared to minimize down time. Let us start with the larger view, and discuss AWS regions first.
You can think of AWS regions as fairly independent collections of data centers within a specific geographic area. In all cases, each AWS region is contained within the same country. As of the time of writing this course, the 11 AWS regions are as follows. To decode these, U. S.
East for instance, is the AWS region's name. Northern Virginia is its location, and US-East-1 is its identifier. Note that Gov Cloud and China are not automatically accessible for all users when signing up for an AWS account. Additionally, the China Beijing region is currently in a limited preview, where they are accepting applications from companies based in China. As you can see, regions exist within a single country, and in many cases, within a single state or even city.
You may also notice that they have unique codes or identifiers for each region. This will become very important later on. As for most AWS services, you have to choose which region to use before starting to interact with the service. So for example, if you want to start a new virtual machine in the Singapore AWS region, you have to explicitly choose that region first. AWS provides different API end points for each region.
The first part of the identifier, US, SA, EU, AP signifies which part of the world they are in. In other words, United States, South America, European Union, and Asia Pacific. Why is this important? There are several reasons. Perhaps the most important involves the location of your data. By choosing which region to store your data or run your applications, you will know in which country your data is stored. This can often be essential in cases where you process or store data that has to be contained within a particular country. Secondly, you may wish to host your data or run your applications in a location close to where your users will be, or perhaps close to where you are, if there is a lot of data to be uploaded or downloaded. Typically, the latency between locations more geographically distant may be longer, meaning that response times will be longer as well. Let us do an experiment to see which AWS regions are closest to us in terms of latency. You can also do this on your own, and the results will most likely be different due to your location. Let us go to the following web address: www.cloudping.info, and click the http ping button. After a little while, you will see different latency times come back. These are measured in milliseconds, ms, and you will probably see the timing vary a lot. You may want to choose a region with a relatively low latency time for your next project, to keep the delay to a minimum. Not all AWS services are bound by the AWS regions, however. One example of a service that operates across all of the nine core regions is identity and access management, IAM. It is therefore important to understand regional affinity policy on a service-by-service basis. All AWS regions were not created exactly equal either.
Most important for this introductory course is the fact that not all AWS services and products are available in every AWS region. The best way to verify if a specific service is available in a particular AWS region, is to check the official list provided by AWS, called products and services by region. At the time of writing this course, the Northern Virginia AWS region is the only one with all 38 AWS products and services listed.
It is important to note that this list changes frequently, as more services are being implemented in additional AWS regions around the world. Also, AWS is continuously expanding their global data center footprint by adding additional AWS regions. The latest addition was Frankfurt, coming online on October 23rd, 2014. Availability zones are closely related to the concept of AWS regions. A good way to think about availability zones is to consider an AZ as equivalent to a data center. An AWS region, thereby, can be thought of as a collection of availability zones. For several services, you have to explicitly choose not only which AWS region you wish to deploy to, but also which availability zone. This is true for virtual machines that are part of the compute service, called Elastic Compute Cloud, EC2. EC2 instances, that is what AWS calls their virtual machines, can only run inside an availability zone. This makes intuitive sense if you think of AZs as data centers. You must choose a data center for the virtual machine to run in.
Notice that some regions have more availability zones than others. With one exception, every AWS region has at least two availability zones, AZs. The exception is the China Beijing region, which has only one AZ. But in any case, it's still in limited preview. To specify an availability zone, you'd typically choose the corresponding letter for that AZ. For example, in the Singapore AWS region, there are two availability zones. If you recall, the Singapore AWS region had a unique end point identifier, called AP-Southeast-1.
To specify which availability zone you want to deploy something to, you simply add a letter at the end. The two availability zones in Singapore are designated as A or B. Therefore, the full identifier for these two AZs will be ap-southeast-1a, and ap-southeast-1b. It is important to note however, that even though the AZs are separate data centers, each AZ in an AWS region is interconnected with high speed, high capacity network connectivity. This allows you to deploy some EC2 instances in one, and some in the other availability zones at the same time for the same application. One of the main reasons for doing this is to have a fault-resilient architecture, where your application can continue working and serving your users, even if there's a catastrophic event that takes down an entire data center, AZ. We'll get into a lot more detail about this in the future courses. But hopefully, this already gives you a taste of the potential options for designing highly available applications in AWS.