What are Amazon Web Services Availability Zones?
When I talked about Amazon Web Services Regions a couple of weeks ago, I said:
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.
Note the plural data centres.
If we look closely at any Region, we’ll see that it’s usually made up of several data centres and rarely just one. Each one of these is an Availability Zone, and we identify it by suffixing the Region’s code with a letter;
c, and so on.
The London Region of
eu-west-2, for example, is made up of three Availability Zones:
So, what’s an Availability Zone?
An Availability Zone is a data centre with two characteristics:
- Availability Zones are independent.
- Availability Zones have high-speed, low-latency connections to other Availability Zones in the same Region.
What do we mean by independence? We mean things like:
- Each Availability Zone has its own independent processing hardware.
- Each Availability Zone has its own independent data storage hardware.
- Each Availability Zone has its own independent power supply.
- Each Availability Zone has its own independent connection to the Internet.
- Each Availability Zone is physically distant from the others to reduce the risk of a disaster affecting multiple locations.
The independence of these Availability Zones allows them to go offline without taking the entire Region with them. As long there’s at least one Availability Zone up and running within a Region, that Region is available.
But what could cause an Availability Zone to go offline? Don’t AWS build in redundancies to keep hardware running?
Let’s be clear, here: Availability Zones are aspects of redundancy. The Region stays up, but its Availability Zones come and go.
There are any number of reasons why a site could go offline. These outages can be planned or unplanned. For example:
- AWS could plan to take an Availability Zone offline to upgrade the networking equipment.
- AWS could plan to take an Availability Zone offline to preemptively replace hardware nearing the end of its life.
- An Availability Zone could suffer an unexpected power failure.
- An Availability Zone could suffer an unexpected Internet connectivity failure.
Spreading across Availability Zones
You might be thinking, what if you’ve got an EC2 instance running in an Availability Zone when it goes offline? What if you’ve got data stored in an Availability Zone when it goes offline?
Applications have to run somewhere, right? Data has to be stored somewhere, right? What happens to your stuff in that Availability Zone when it’s down for maintenance or burned down by dragons?
The short answer is: Applications running in that Availability Zone are terminated. The hardware has evaporated, and taken your stuff with it.
But one of the core concepts of cloud computing is that hardware is ephemeral.
Let’s think back to the old days. Let’s say you had an application that you needed to serve to your users, so you bought a server and installed your app. The server sat under your desk. You owned it. No-one was going to turn it off, because it was yours.
You can’t transfer that same mindset to the cloud. Hardware in the cloud is relatively short-lived, paid for by the hour and never owned outright.
Put simply, a cloud-native application would be developed to scale; to recognise that many copies of itself are running on many different machines, and to be able to share their work between themselves.
Think of your application running on a swarm of short-living servers, rather than a single long-living one. If an Availability Zone goes offline, your application responds by spawning new instances in the remaining Availability Zones.
This multiplicity allows an application to inhabit multiple Availability Zones and be resilient to outages. It also allows an application to scale out into more instances to accomodate demand, and to scale in by terminating instances which are no longer needed.
Which Availability Zone should I use?
The short answer is: it doesn’t matter which Availability Zone you use.
It’s far more important that you balance across multiple Availability Zones rather than picking one special one.
I’ll go into more detail for this another time. I love this stuff. Believe it, it’s kinda thrilling when you see an application you deployed scale out and survive a hardware failure without any humans needing to react at all.
Where are these Availability Zones, physically?
Something else I said about Amazon Web Services Regions a couple of weeks ago was:
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.
Let me clarify that slightly: you can choose a specific Availability Zone, but you’ll never know exactly which data centre it is.
Let’s say the three data centres in London have these addresses:
|Blue Business Park|
|Yellow Business Park|
|White Business Park|
Now, when a new user signs up for Amazon Web Services, an Availability Zone code is randomly assigned to each physical address.
So my random allocation could look like this:
|Physical address||My Availability Zones|
|Blue Business Park||
|Yellow Business Park||
|White Business Park||
When you sign up, you’ll probably get a different random allocation:
|Physical address||My Availability Zones||Your Availability Zones|
|Blue Business Park||
|Yellow Business Park||
|White Business Park||
Why does AWS randomise the allocations? Well, it’s most likely because the choice is so irrelevant that – more often than not – folks just pick whichever Availability Zone is selected for them by default. In London, this means most folks will choose to deloy their applications and data to
eu-west-2a was the same physical data centre for everyone then it would get swamped almost immediately, while the other data centres remained relatively unused.
By randomising the Availability Zones, we could both choose
eu-west-2a and our demand would be balanced between Yellow Business Park and White Business Park.
And Amazon Web Services will never, ever, ever reveal the physical addresses of their data centres. They don’t want to deal with the security nightmare, and I don’t blame them.
Let’s test those low-latency networks
Deploying your application across Availability Zones can make it resilient, but it does introduce some miniscule latency. Just like with Regions, data doesn’t travel instantaneously; network conditions and routing decisions will always add some delay.
If you really, truly, absolutely need to shave every possible millisecond off your network requests, then you can deploy your services into the same Availability Zone.
Does it really make a difference?
Let’s try it out!
First, I deployed a couple of EC2 instances to
eu-west-2b, and I pinged one from the other.
Not familiar with “ping”? Check out my introduction to ping then come back when you’re ready
Here are the results of pinging an instance in
PING 18.104.22.168 (22.214.171.124) 56(84) bytes of data. 64 bytes from 126.96.36.199: icmp_seq=1 ttl=254 time=1.04 ms 64 bytes from 188.8.131.52: icmp_seq=2 ttl=254 time=1.09 ms 64 bytes from 184.108.40.206: icmp_seq=3 ttl=254 time=1.16 ms 64 bytes from 220.127.116.11: icmp_seq=4 ttl=254 time=1.11 ms 64 bytes from 18.104.22.168: icmp_seq=5 ttl=254 time=1.13 ms 64 bytes from 22.214.171.124: icmp_seq=6 ttl=254 time=1.17 ms 64 bytes from 126.96.36.199: icmp_seq=7 ttl=254 time=1.08 ms 64 bytes from 188.8.131.52: icmp_seq=8 ttl=254 time=1.14 ms --- 184.108.40.206 ping statistics --- 8 packets transmitted, 8 received, 0% packet loss, time 7009ms rtt min/avg/max/mdev = 1.043/1.118/1.170/0.060 ms
That’s pretty fast at pretty much just a millisecond for a ping to get across London and back again.
But what if we ping an EC2 instance in the same Availability Zone? Reckon it’s quicker?
Here, I launched a second EC2 instance in
eu-west-2a, and pinged it from the first.
PING 220.127.116.11 (18.104.22.168) 56(84) bytes of data. 64 bytes from 22.214.171.124: icmp_seq=1 ttl=254 time=0.533 ms 64 bytes from 126.96.36.199: icmp_seq=2 ttl=254 time=0.476 ms 64 bytes from 188.8.131.52: icmp_seq=3 ttl=254 time=0.521 ms 64 bytes from 184.108.40.206: icmp_seq=4 ttl=254 time=0.586 ms 64 bytes from 220.127.116.11: icmp_seq=5 ttl=254 time=0.491 ms 64 bytes from 18.104.22.168: icmp_seq=6 ttl=254 time=0.696 ms 64 bytes from 22.214.171.124: icmp_seq=7 ttl=254 time=0.462 ms 64 bytes from 126.96.36.199: icmp_seq=8 ttl=254 time=0.515 ms --- 188.8.131.52 ping statistics --- 8 packets transmitted, 8 received, 0% packet loss, time 7175ms rtt min/avg/max/mdev = 0.462/0.535/0.696/0.070 ms
Look at that! Only half a millisecond for a ping across the same Availability Zone!
It’s pretty unlikely that you’ll ever need to shave fractions of milliseconds off your latency – but if you ever do, then there you go.