James Thew - Fotolia


Provision regionally with AWS availability zones

To design a highly available public cloud in AWS, it's best to provision regionally -- placing applications in regions closest to end customers. Knowing which availability zone to choose is step one.

Amazon is a global infrastructure-as-a-service provider, with customers from more than 190 countries provisioning AWS services. Some say that to succeed in the global marketplace, you need to think globally and act locally. The same is true when building a cloud architecture -- provision regionally; design locally. With public cloud, that starts with the right AWS availability zone.

To understand how to do this in AWS, it helps to understand Amazon's global infrastructure footprint.

Amazon's data centers are spread across 10 regions: North Virginia (US-East-1); Northern California (US-West-1); Oregon (UW-West-2); EU/Ireland (EU-West-1); Singapore (AP-Southeast-1); Tokyo (AP-Northeast-1); Sydney (AP-Southeast-2); São Paulo (SA-East-1); Beijing for limited preview; and GovCloud (US-Gov-West-1), which is an isolated AWS Region designed for U.S. government agencies. Each region has multiple availability zones (AZs), each of which has one or more data centers within it.

There are 51 edge locations across Amazon regions positioned for optimal content delivery using CloudFront. So, if you are serving up a Web page, content delivery for it occurs quickly no matter where you are geographically located.

AZs are geographically separate from other AZs in the same region and are designed to provide infrastructure redundancy in the event of an abnormal outage, such as Godzilla attacks, earthquakes, someone spilling coffee in a server, etc. In the rare event that one AZ goes down, services can be switched to another AZ -- assuming the cloud architecture is prepared for this contingency.

The number of AZs per region differs, and the total number of zones is steadily expanding. The largest and most used zone is US-East-1. Availability zones in the same region are interconnected using redundant, high-speed network cables offering low-latency response times. However, AWS regions are connected to each other only through the public Internet.

When you deploy AWS services globally, it's not enough to launch them without taking into consideration how to provision them across regions and AZs. Systems are expected to be online 24/7 and instantly available. There is a direct correlation between sluggish systems and user satisfaction, usability and productivity.

Provision your cloud regionally

To provision regionally, put applications and data into the regions where customers live. Spinning up Elastic Compute Cloud (EC2) instances or other AWS Services in multiple regions allows you to use Route 53's Latency Based Routing (LBR) feature, which automatically routes end users to the region with the lowest latency. No matter where a user is located, application performance is improved because LBR directs user requests only to systems with the quickest response.

Data residency or data sovereignty requirements may also contribute toward designing cloud storage so that enterprise data remains in specific regions. Countries such as Germany, India and Canada, for example, place compliance constraints on data to prevent organizations from storing personal information outside of the country's borders.

Design your cloud locally

Replicate services across AWS availability zones in specific regions to protect against unexpected outages. AWS CloudWatch can detect problems and send alerts; but to provide true availability, point Route 53 to an elastic load balancer (ELB) that's connected to replicated EC2 instances across multiple AZs. Replicating across AZs means that, if EC2 instances or email systems go down in one AZ, the ELB will reroute traffic to healthy systems. Your IT team won't need to manually intervene.

Amazon Simple Storage Service (S3), AWS CloudWatch, Amazon Simple Queue Service and the ELB are inherently designed to work across AZs. S3 objects are replicated across AWS availability zones inside regions.

About the author:
Russ Vanderpool, who holds MSCS and MBA degrees, is a technologist interested in using cloud technology to deliver solutions, help companies better serve customers and identify new businesses. He has hands-on experience as an architect and developer and a business adviser across the finance, energy, education, technology and nonprofit sectors. Russ has architected and built a cloud infrastructure for a green tech company, and while working for Japan's largest systems integration firm, he developed proprietary object-oriented database visualization software for that market.

Next Steps

Control costs through cloud regions and availability zones

Dig Deeper on AWS instances strategy and setup