What are Amazon Web Services Regions?
Recapping Virtual Private Clouds
When we talked about VPCs, I said:
VPCs allow you to create private networks where you can isolate resources and configure their accessibility.
Now, let’s talk about where on Planet Earth these resources exist.
We might like to think that the Internet transcends geography. When you visit a website, do you really care if the server is in London, Dublin or San Francisco?
You probably don’t care. If it works then that’s enough, right?
But all those applications and databases need to be running on hardware somewhere.
Every piece of hardware that makes up Amazon Web Services exists within a data centre.
Amazon are super-paranoid about sharing details about their data centres, so here’s a video about one of Google’s data centres instead.1
I’ve visted two data centres during my career, and let me tell you; physical security is taken super seriously. I’m pretty sure the security staff in the US data centre were armed. I didn’t test them.
Just imagine the damage a villain could do if they stole a hard drive, or plugged in some of their own malicious hardware. The financial and reputational damage would be catastrophic.
The risk isn’t just to Amazon’s business either, but also to the uncountable businesses that rely on AWS for daily operations. One brutal attack against just one data centre could wreak havoc on the global economy. No more Netflix. No more chill.
I mean, look at how well things went for the Empire after rebels broke into their data centre on Scarif and stole a single hard drive.
Amazon Web Services Regions
There are Amazon Web Services data centres all over the world, and they’re grouped into named Regions. All the data centres in London, for example, make up the London Region. Similarly, all the data centres in North Virginia make up the North Virginia Region.
Amazon Web Services’ documentation convention is to use lower-case region for geographic areas, and capital-case Region for the groups of data centres. So, North Virginia is a region within the United States of America, and it’s also an Amazon Web Services Region.
As an AWS customer, you get to choose where in the world your code runs. Well, generally. You can choose a Region, but you can’t choose a specific data centre. You can choose to deploy an application to the London Region, but you’ll never know the physical address of the specific data centre in London that was randomly chosen for you.
So every Region has a name, and also a code, like
us-east-1. This is used for describing Regions programmatically, via scripts and API calls.
At the time of writing in April 2019, these are the available Regions:
|US East (N. Virginia)||us-east-1|
|US East (Ohio)||us-east-2|
|US West (N. California)||us-west-1|
|US West (Oregon)||us-west-2|
|Asia Pacific (Mumbai)||ap-south-1|
|Asia Pacific (Seoul)||ap-northeast-2|
|Asia Pacific (Singapore)||ap-southeast-1|
|Asia Pacific (Sydney)||ap-southeast-2|
|Asia Pacific (Tokyo)||ap-northeast-1|
|South America (São Paulo)||sa-east-1|
If you’re special then you might even have a few more Regions available to you.
- US GovCloud East (
us-gov-east-1) and US GovCloud West (
us-gov-west-1) are extra-special isolated Regions for the United States Government, presumably where they hold data about all their reverse-engineered extraterrestrial technology.
- Osaka (
ap-northeast-3) is available only to Japanese accounts.
- Bejing (
cn-north-1)and Ningxia (
cn-northwest-1) are available only to Chinese accounts.
Choosing and switching between Regions
Amazon Web Services accounts operate across Regions. You don’t need to create a new account for each Region; your single account can deploy anywhere.
When you’re logged into the AWS Console, you can see which Region you’re currently in at the top-right of the screen. To switch to a different Region, just click it and choose the Region you want.
Sometimes, the Region at the top of the screen will just say Global and you won’t be able to change it. This is because some things in AWS – like IAM resources, for example – automagically exist across all Regions.
These things are the exceptions to the rule, and are exceptions specifically for the things that need to operate across Regions.
A database needs to exist on hardware somewhere, but our identities are cosmic.
A few gotchas
There are a few things you should bear in mind while you’re zipping around all these Regions.
A lot of folks trip up when they can’t see any EC2 instances (or RDS instances, etc) running and assume there aren’t any running at all.
You’ve got to rememember that these lists will only show you the things in this Region. You could have EC2 instances (or RDS instances, etc) running and accruing costs in other Regions, and you won’t know unless you look. It’s vital that you keep an eye on your billing to prevent surprises.
And speaking of costs, be aware that each Region has its own pricing. A
t2.micro instance, for example, could be fractions of pennies cheaper or more expensive in other Regions. The difference might be negligible, but you should check before you deploy into a new Region.
Does it matter which one I pick?
If you’re just prototyping and experimenting, it probably doesn’t matter. Don’t waste time thinking about it. Deploy to North Virginia (
us-east-1) and you’ll be fine.
But when you’re thinking about deploying some real customer-facing services, which Regions should you deploy to?
Ah, you’ll have to come back next week for that one.
If you liked this then you’ll love my introduction to Amazon Web Services Availability Zones!