During Andy Jassy’s keynote at re:Invent he spent an entire section talking about several new products that would extend AWS “Beyond the Region”. These were Local Zones, Wavelength, and the long awaited Outposts. In turn, these allow you to run AWS services in a mini-zone, in a Telco’s 5G data centre, and in your own datacenter/office/backyard1. While this will no doubt give some more options, the main way we’ll all be running our AWS services is still going to be within a Region. So let’s have a look at how these evolved over time.
When AWS became publicly available in 2006, it did so with a single Region. In public places (such as blog posts) it wasn’t called a Region yet. After all, when you have a single of anything you don’t need to name either the concept or the thing itself. At least not publicly. I wouldn’t be surprised if internally people started thinking of names long before we were introduced to them.
Regardless, it all started with the single Region that has had several names. It’s been called US Standard, US East, and more recently North Virginia. If you use API calls, you are probably familiar with its API name us-east-1. And of course, at the very start this Region was only for S3, with EC2 support not arriving until later that year2.
When S3 became available in Ireland, that still wasn’t called a Region. Instead in Werner Vogel’s blog post about it, he indicated this was a
<localconstraint> configuration. The concept of a region3 was instead introduced at the same time as Availability Zones4. As per the blog post:
Availability Zones give you additional control of where your EC2 instances are run. We use a two level model which consists of geographic regions broken down into logical zones. Each zone is designed in such a way that it is insulated from failures which might affect other zones within the region. By running your application across multiple zones within a region you can protect yourself from zone-level failures.
Of course, until EC2 became available in Ireland, this was still only applicable to the US Standard region. Once there were two Regions however, the number started growing. As Regions aren’t exactly quick or easy to build this took time until we reached the current number of 22 regions, with another four already announced. Let’s have a quick look at the data for that though. The raw data I use for this is available both as a CSV or a Numbers file.
In the above graph you can see how the number of Regions grew over the years. The first few years there was a Region per year5, until in 2011 four Regions opened shortly after each other. The next two years we only got a single region, but as that was Sydney it obviously6 counts as an important period. You can read the rest of the graph, and will see that we’re in a stable period with getting two new Regions per year.
But what if none of the Regions are in an area you’d like it to be? How long will it take for them to show up? Unfortunately, I’ve got a bit of bad news for you there. The time between a Region getting announced and the day it actually opens is getting longer and longer.
You may notice two entries missing from that graph. Ohio and Ningxia are the only Regions in the past four years that were opened without a pre-announcement7. I added in a trend line to see what this likely means for the newly announced regions, but in all honesty it doesn’t seem to match the ones in the announcement posts.
The next two to open are announced for the first half of 2020 while the trend line estimates them at the end of that year. On the other hand, it shows Spain as coming in early 2022, while AWS claims late 2022 or early 2023. So, yeah, predicting the future on unclear data like this doesn’t seem to be very useful8.
If you’ve paid attention to recent announcements, you will notice that I’ve left off one “future” Region. This is the Osaka Region. Osaka originally started9 as a local region with limited capabilities to offer customers in the Tokyo Region a geographically separate place for disaster recovery systems (presumably due to seismic dangers). Now however, AWS has announced that they’ll be expanding this to a full region in 2021. For hopefully obvious reasons, this is a very special case so I’ve left it out of everything.
That however brings us to that other mainstay we keep our services in: Availability Zones. As mentioned earlier, Availability Zones have been a part of AWS since 2008, but not every Region has the same number of Availability Zones. Most obvious in that regard is North Virginia, which has had 5 Availability Zones for a very long time10, while most others have been stuck with 2 or 3 zones.
However, while 5 (or now even 6) AZs is nice, the biggest win for regions is when they have at least 3 AZs. That is because over the years a number of services have come out that require at least 3 AZs. Possibly the most well-known of these is Aurora, which requires these AZs for its data storage, regardless of in how many regions you’ve got instances running.
This means that since 2015 there has been a lot of demand for having 3 AZs in a Region. Luckily, AWS has realised that as well and have in the past couple of years gone through a big effort of providing those 3 AZs. Every region since Paris in December 2017 has launched with 3 AZs11 and most existing regions have received a third AZ since then as well.
Looking at this in terms of the percentage of Regions with 3 AZs it’s even clearer how much of an improvement there has been, especially in the past 2 years. Although even now, there are still a couple of Regions that for some reason don’t have three Availability Zones.
The remaining regions with only 2 AZs12 are Beijing and Canada. It’s an interesting combination and I have no idea what to make of it. The Beijing Region is in many ways a special case, so I’m not too surprised that Region is one of the exceptions but I don’t know what AWS has against the Canada Region. To be fair, based on all this I expect that at least the Canada region will soon receive a third AZ, although for the accuracy of this post I hope it won’t come within hours of me posting this13.
I’ll finish this overview of Regions and Availability Zones with a final graph, showing how long it took for a Region to receive its third AZ since it was opened. On average it only took about 787 days, or a bit over 2 years, but that is mostly because there have been a number of Regions with three AZs on launch. Based on these numbers, if I had to give a reward for the least loved Region, it seems that Singapore is the “winner” having had to wait 2827 days (almost EIGHT YEARS!) for that third AZ. To put that into perspective, in the time between Singapore’s launch and that third Availability Zone, 14 completely new Regions were launched.
- Provided your backyard meets all of the security, power, and connection criteria. [return]
- Yes, I know, SQS came before or after S3 (depending on whether you count the beta) and was available before EC2 either way. That’s not really relevant for this though. [return]
- The capitalisation of the term didn’t come until later. [return]
- These had capitalisation from the start. [return]
- Except for 2008, which had no new regions as they were likely trying to figure out the concept. [return]
- For those of us in Australia at least. [return]
- Which technically means that you might be very lucky and your region will do the same. I wouldn’t count on it though. [return]
- Still fun though. [return]
- I couldn’t find a proper English version of this post, likely due to its limited access. [return]
- I couldn’t find a source that told me how many AZs North Virginia at different points in time. So for now I just assume that it had 5 since 2008. If you can point me at a source that says otherwise, please do so. [return]
- Likely a big factor in the increased time it takes to build a Region. [return]
- Once again ignoring the Osaka local region that right now still only has a single AZ. [return]
- Hopefully not much longer than that though, as it would be nice to be sure that every region I have access to has 3 AZs. [return]