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



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

1. Open the AWS console.

Find the EC2 dashboard.

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



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
REGION sa-east-1
REGION us-east-1
REGION ap-northeast-1
REGION us-west-2
REGION us-west-1
REGION ap-southeast-1
REGION ap-southeast-2
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 eu-west-1
REGIONS sa-east-1
REGIONS us-east-1
REGIONS ap-northeast-1
REGIONS us-west-2
REGIONS us-west-1
REGIONS ap-southeast-1
REGIONS 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=
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