AWS has developed and created its highly available global infrastructure allowing users to deploy and manage their estates all across the world through the use of the following geographical components
- Regions
- Availability Zones
- Edge Locations
When architecting and designing your infrastructure it’s important to know where your data is being stored and where your instances and services are located. This is fundamental when designing and implementing a highly available and scalable network with low latency that abides by any data laws that may be in operation.
If you are studying for the AWS certifications it’s important to know the differences between Regions/Availability Zones and Edge Locations.
Available Regions
Your account determines the regions that are available to you. For example:
- An AWS account provides multiple regions so that you can launch Amazon EC2 instances in locations that meet your requirements. For example, you might want to launch instances in Europe to be closer to your European customers or to meet legal requirements.
- An AWS GovCloud (US) account provides access to the AWS GovCloud (US) region only. For more information, see AWS GovCloud (US) Region.
- An Amazon AWS (China) account provides access to the China (Beijing) region only.
The following table lists the regions provided by an AWS account. You can't describe or access additional regions from an AWS account, such as AWS GovCloud (US) or China (Beijing).
Code
|
Name
|
us-east-1
|
US East (N. Virginia)
|
us-east-2
|
US East (Ohio)
|
us-west-1
|
US West (N. California)
|
us-west-2
|
US West (Oregon)
|
ca-central-1
|
Canada (Central)
|
eu-central-1
|
EU (Frankfurt)
|
eu-west-1
|
EU (Ireland)
|
eu-west-2
|
EU (London)
|
eu-west-3
|
EU (Paris)
|
ap-northeast-1
|
Asia Pacific (Tokyo)
|
ap-northeast-2
|
Asia Pacific (Seoul)
|
ap-northeast-3
|
Asia Pacific (Osaka-Local)
|
ap-southeast-1
|
Asia Pacific (Singapore)
|
ap-southeast-2
|
Asia Pacific (Sydney)
|
ap-south-1
|
Asia Pacific (Mumbai)
|
sa-east-1
|
South America (São Paulo)
|
What is an Availability Zone?
Availability zones are effectively different Data Centres located within a Region. Each AZ (Availability Zone) is completely independent of others which enable them to reside in different areas within the same Region providing a level of Business Continuity in the event of a disaster. All AZ’s within the same region are linked by extremely low latency connections allowing for the built in high availability features from many of AWS services such as S3, RDS etc to communicate with each other.
Utilising multiple AZ’s when architecting your network is essential when designing a highly available network. Deploying infrastructure across more than one allows you to ensure your service remains operational should an AZ service go down unexpectedly.
The below shows a logical diagram of the EU Ireland Region which has 3 different AZ’s (eu-west-1a, eu-west-1b and eu-west-1c) all connected by multiple low latency links
What is an Edge Location
Edge locations are used in conjunction with the AWS CloudFront service which is a global Content Delivery Network service (more information on CloudFront can be found here). Edge Locations are deployed across the world in multiple locations to reduce latency for traffic served over CloudFront and as a result are usually located in highly populated areas.
The below Edge Locations currently exist (as of July 2015)
North America:
Ashburn, VA (3), Atlanta, GA, Dallas/Fort Worth, TX (2), Hayward, CA, Jacksonville, FL, Los Angeles, CA (2), Miami, FL, New York, NY (3), Newark, NJ, Palo Alto, CA, San Jose, CA, Seattle, WA, South Bend, IN, St. Louis, MO
South America:
Rio de Janeiro, Brazil, São Paulo, Brazil
EMEA:
Amsterdam, The Netherlands (2), Dublin, Ireland, Frankfurt, Germany (3), London, England (3), Madrid, Spain, Marseille, France, Milan, Italy, Paris, France (2), Stockholm, Sweden, and Warsaw, Poland
Asia Pacific:
Chennai, India, Hong Kong, China (2), Manila, the Philippines, Melbourne, Australia, Mumbai, India, Osaka, Japan, Seoul, Korea (2), Singapore (2), Sydney, Australia, Taipei, Taiwan, Tokyo, Japan (2)
As you can see from below, many of the Edge Locations are located some distance away from some of the Regions discussed earlier. Edge Locations are independent of Regions and Availability Zones.
Image courtesy of http://aws.amazon.com/security/sharing-the-security-responsibility/
Can I get any Service in any Region?
The simple answer is ‘no’, not all services are currently available in all regions. However AWS are constantly releasing new updates and increasing the availability of their services across the globe so this is constantly evolving. The best way to find out if the service you require exists in the region you want to deploy your infrastructure is to check the AWS Regional Product Services site.
Selecting a Region for a resource within the AWS Console
From within the AWS Console you can select the region you want to deploy your Service in. Once you have logged into the Console and are presented with the AWS dashboard, select the service you require, such as EC2.
From within the dashboard of the EC2 service you can change the Region in the top right corner by clicking on the currently select Region:
A dropdown list with then appear allowing you to select the most appropriate Region for your needs
When selecting your Region it’s generally best practise to host your infrastructure as close to the end users as possible to reduce latency.
Once you have selected the Region for your Service you wish to deploy your infrastructure in you can then deploy your EC2 instances. During your deployment of your EC2 instances at the Configure Instance Details screen you will be prompted to select an Availability Zone that resides within that Region.
Architecting your applications and services across multiple Availability Zones and multiple Regions provides is best practise when designing a highly available infrastructure network. Should any natural or other disaster at a particular AZ or Region you will be safe in the knowledge that your customers will not be affected due to your careful design.
By default many of the AWS services and functions operate across multiple AZs by design for these very same reasons, such as S3, RDS Multi AZ, ELB, AutoScaling to name but a few.