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/backyard¹. 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.

Regions

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 year².

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 region³ was instead introduced at the same time as Availability Zones⁴. 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 24 regions, with another two 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 year⁵, 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 obviously⁶ 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-announcement⁷. 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.

Milan and South Africa were announced for the first half of 2020 while the trend line estimates put them at the end of the year, and clearly their release was in April. 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 useful⁸. Nonetheless, with the announcements in late 2020 I’ve added some estimates based on what AWS claims (for example, Spain will be between October 31, 2022 and March 31, 2023). In these cases the trendline seems more accurate, although Spain is likely to be a big outlier and we don’t have any dates for Indonesia.

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 started⁹ 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.

Availability Zones

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 time¹⁰, 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 AZs¹¹ 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 AZs¹² 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 this¹³.

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 737 days (787 before the openings in April 2020), 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.

As mentioned earlier, you can download the raw data I used for this as a CSV or a Numbers file .