When setting up an EC2 instance or configuring a profile, you have the choice to set the Region and Availability Zone. If you were wondering how that mattered, you aren’t alone.
What’s the difference between Region and Availability Zone?
Regions are actual physical locations of Amazon computers. While they would like us to think of the cloud as some magical server in the sky, in reality there are big buildings all over the world full of servers. The Regions, shown in Table 1, are the actual physical locations of these servers.
Table 1: Regions and Availability Zones
| Code | Location | Region | Availability Zones |
| us-west-1 | Northern California | US West | 6 zones shared with us-west-2 |
| us-west-2 | Oregon | US West | 6 zones shared with us-west-1 |
| us-east-1 | Virginia | US East | 5 zones |
| ap-northeast-1 | Tokoyo | Asia Pacific | 2 zones |
| ap-southeast-1 | Singapore | Asia Pacific | 2 zones |
| ap-southeast-2 | Sydney | Australia | 2 zones |
| eu-west-1 | Ireland | EU | 3 zones |
| sa-east-1 | Sao Paulo | South America | 2 zones |
Availability zones are isolated areas inside regions that are designed to protect against failures in other availability zones. They have separate power, cooling and physical space.
Why should I pay attention?
Amazon is designed for global access. Their web site is global, and their servers are global. If you are using AWS you have the option to support a truly global architecture as well.
There are requirements that may cause you to carefully consider the location of your servers. These requirements are why you have the ability to choose your region.
Legal considerations
There are a number of privacy laws on the books – especially in Europe and the U.S. – that restrict the passing of government data outside the bounds of a region. AWS supports this, implicitly in the regional settings, and explicitly with GovCloud.
GovCloud is a physically restricted cloud service that is designed to explicitly prevent data from leaving the borders of the US. When building a governmental web application in the U.S. that’s probably your best path.
Regions implicitly segregate data, too. While regions are connected via the open internet, if you select the EU for your S3 instance, that’s where your data will be stored.
Guarding against failure
AWS does go down. It isn’t very common, but it happens. Regions and Availability Zones were created to protect against just such a happening. You must, however, architect your application against such a happening.
Regions are not duplicated among themselves by default. In order to create a truly fault-tolerant application, you must set up something like the Cross Region Read Replicas in Amazon RDS.
Plain old bits on the wire
Of course there is a much more straightforward reason for the correct management of regions: the actual physical distance between your application and your customers. Those bits still have to travel the wire, so make sure your application is close to the folks that use it.
Geographic restrictions
Under some circumstances, your content might be restricted to users only living in one geographic area. For instance, some content can’t – by law – be exported outside of the European Union.
I for one was surprised that the Region can’t be used for this restriction. CloudFront offers a geographic restriction, but it is one a list by country basis, and you set it up separately from the region.
How to make a plan
Long before you set up that EC2 instance, take careful stock of your situation. Consider your user location, your needs for fault tolerance and the legal landscape if your application. Then you can map out your regions to best make use of the AWS servers.
Subscribe