Cloud

Choose the AWS region closest to customers, unless you need to break this rule

In the latest in his cloud automation series, Nick Hardiman details how to choose an Amazon Web Services (AWS) region from the eight data centers around the world.

 

0_aws_logo.jpg
 

In part one of my cloud automation series on building a simple web service, I focused on details about the technology, the architecture, and the steps involved in the process. Part two covered automating the Puppet Labs automation system. Part three built virtual machines on the Amazon Elastic Compute Cloud (EC2) platform using the new Amazon Web Services (AWS) Command Line Interface (CLI) tools. Now I turn my attention to choosing an AWS region.

AWS run public cloud services from eight data centers around the world: three in the USA, one in Europe, three in Asia, and one in South America. Expect more in the future — Amazon is currently building another AWS region in China.

As an AWS customer, you can use any of these data centers. So, which one should you use? The closest one? The cheapest one? The most environmentally friendly one? Or maybe it's about the workload. If you are setting up a dev/test service in AWS, where do you put it?

List the AWS regions

If you are browsing the web, check out the AWS map of global infrastructure (Figure A).

Figure A

 

AWS_regions_FigA_032014.png
AWS global infrastructure
 

If you use the web-based AWS Management Console, you can find the list here.

1. Open the AWS console.

2. Find the EC2 dashboard.

3. Click the current region (mine is Ireland) in the top navbar. A drop-down list opens, with all eight regions listed (Figure B).

Figure B

 

AWS_regions_FigB_032014.png
 

If you are a CLI junky using the old EC2 API tools, run the long and descriptive ec2-describe-regions or the easy to type ec2dre — both commands do the same thing.

1. Open a CLI.

2. List the region names. 

 

nick:~ $ ec2-describe-regions
REGION  eu-west-1       ec2.eu-west-1.amazonaws.com
REGION  sa-east-1       ec2.sa-east-1.amazonaws.com
REGION  us-east-1       ec2.us-east-1.amazonaws.com
REGION  ap-northeast-1  ec2.ap-northeast-1.amazonaws.com
REGION  us-west-2       ec2.us-west-2.amazonaws.com
REGION  us-west-1       ec2.us-west-1.amazonaws.com
REGION  ap-southeast-1  ec2.ap-southeast-1.amazonaws.com
REGION  ap-southeast-2  ec2.ap-southeast-2.amazonaws.com
nick:~ $ 
 

The second column is a list of region names. The third field in each line is an FQDN for a URL (nerds love acronyms).

If you use the new AWS API tools, run aws ec2 describe-regions.

1. Open a CLI.

2. List the region names. 

 

nick:~ $ aws ec2 describe-regions
REGIONS	ec2.eu-west-1.amazonaws.com	eu-west-1
REGIONS	ec2.sa-east-1.amazonaws.com	sa-east-1
REGIONS	ec2.us-east-1.amazonaws.com	us-east-1
REGIONS	ec2.ap-northeast-1.amazonaws.com	ap-northeast-1
REGIONS	ec2.us-west-2.amazonaws.com	us-west-2
REGIONS	ec2.us-west-1.amazonaws.com	us-west-1
REGIONS	ec2.ap-southeast-1.amazonaws.com	ap-southeast-1
REGIONS	ec2.ap-southeast-2.amazonaws.com	ap-southeast-2
nick:~ $
 

Which region is geographically close to your customers?

If you are putting one machine in one location, why not put it close to your customers? This usually means the general public, but not always. If you are creating a middleware service used only by company machines, they are the customers.

So the basic rule is: pick a region close to the customers. The idea is the shortest piece of string between public cloud and client application means the lowest network latency and the quickest response.

If you live on the east coast of the USA, finding the closest region is easy — US East (N. Virginia). If you live on the west coast of Australia, the answer is not all that obvious — probably Asia Pacific (Singapore) but possibly US West (N. California).  

TurnKey Linux, the virtual appliance suppliers, automated the process for its customers. There's a map showing undersea cables (the planetary plumbing that makes the internet go) and Python code to find the nearest region.

Choosing based on latency, global warming, cost, and compliance

It's worth measuring the request/response time in each data center. You may find that picking the nearest data center doesn't matter as much as you may think. A human web surfer, waiting for a page to appear from the other side of the world while 100 application requests and 10,000 IP packets zip around in the background, may not even notice the extra travel time. The same web server may get a company intranet page from a neighbouring building and find the office network and the local ISP seem to be wading through treacle. If you want to get serious about network response times, talk to professionals like iTrinegy.

If there's not much difference between two data centers, get right-on. Pick the region that generates the least carbon. The Mastodon C analysts can tell you which one.

Price makes little difference. There are small variations in cost between regions, but no real deal-breakers. New services get rolled out in some regions first and not others, but the big compute and storage services are available in all regions.

If you work in a regulated industry, you may be legally bound to keep all customer data in the country. If you are dealing with private information and don't live in the right region, you may not be able to use AWS.

Pick a region

If you use the old-school command line tools, type in environment variables to match your region.

 

nick:~ $ export EC2_REGION=eu-west-1
nick:~ $ export EC2_URL=https://ec2.eu-west-1.amazonaws.com/
 

If you use the new tools, the region is in the configuration file.

 

nick:~ $ grep region .aws/config
region = eu-west-1
nick:~ $ 
 

You don't have to choose an Availability Zone.

The decision is not (yet) as simple as it could be

There is no simple web service for the general public that lets you type in your region requirements and get a simple answer out. If you have some development skill and want to build on TurnKey Linux's work, fill that gap.

Upcoming installments in this cloud automation series

  • Add AWS security groups
  • Work with cloud-init
  • Create the Puppet master
  • Create the Puppet agent
 

About

Nick Hardiman builds and maintains the infrastructure required to run Internet services. Nick deals with the lower layers of the Internet - the machines, networks, operating systems, and applications. Nick's job stops there, and he hands over to the ...

1 comments

Editor's Picks