AWS has announced a new region in Europe. This time the turn has arrived for Spain to host its own 3 Availability Zone region. With Dublin, Frankfurt, London, Paris, Stockholm already up and running and Milan due to start operations in early 2020, the new region in Spain will make the seventh AWS European region.

A new AWS region is always a big development for AWS enthusiasts. It opens possibilities for customers of all sizes in the given geographic region, public and private, and demonstrates the massive scale AWS Cloud is reaching every day. Those who already know me clearly understand why I jumped to write about this new region announcement. For those who don’t, while working mainly for Australian customers from Sydney, I am originally from Spain, and like to keep an eye on developments back home and hear from friends that work on the platform, who are even more excited than me for obvious reasons.

What is an AWS region?

I’ll take this opportunity to review what an AWS region is, and a few concepts that are worth understanding well to get the best out your AWS usage.

An AWS region is a geographical location formed by a series of physical data centres. AWS regions are designed to operate independently from other AWS regions. Note that regions are often commonly named after the city they are close to, like Ohio, Sydney or Frankfurt, and have AWS code names like us-east-2, ap-southeast-2 or eu-central-1.

This isolation offers many benefits to any workload running on AWS. Outages in a service in the North Virginia region will not affect users of the same service in the Sydney region.

Within a region AWS provides services such as Amazon S3, Amazon DynamoDB, Amazon EC2 or AWS Lambda, and as AWS customers we can use these services within that region.

Inside each region AWS maps one or more of the mentioned physical data centres to an Availability Zone, or AZ. Initially some regions opened to service with 2 AZs, but AWS is currently aiming at launching all new regions with 3 AZs and providing a third AZ to existing regions with only 2. Sydney region, for example, launched with 2 AZs and got the third in 2016.

An Availability Zone is a logical data centre that may be formed by more than 1 physical data centre. Each Availability Zone will have separate and redundant power supply and network, and all Availability Zones within a region will be physically separated to prevent more than 1 being impacted by floods, fires, or other natural disasters.

At the same time all Availability Zones are inter-connected via low latency, redundant private links that provide the necessary capacity for cross-zone communications and operations like replication. These connections give us the capacity to treat a region like a single abstract data centre, while benefiting from the Availability Zone isolation.

How to use all 3 Availability Zones

Knowing that designing our workloads to use all Availability Zones offers many advantages, we need to understand how this can be achieved. There are two types of services in AWS when it comes to Availability Zones,

  • zonal services, that explicitly expose the idea of Availability Zones. These are services like Amazon EC2, Amazon EBS or Amazon RDS, where we can decide and know in which Availability Zone we run an instance, and
  • regional services, that do not expose the concept of Availability Zones to us, but under the hood make use of them. These are services like Amazon DynamoDB or Amazon S3, which replicate data across all Availability Zones in a region.

What this means is that all services are either leveraging all Availability Zones on our behalf and for our benefit or allow us to explicitly leverage them and get the benefits.

Take for example a regional service like Amazon DynamoDB, an AWS key-value based database that delivers single-digit millisecond performance at any scale. With Amazon DynamoDB we interact from a regional perspective, but the service is managing the underlying infrastructure for us across Availability Zones, creating 6 copies of our data to ensure high availability in what the service calls partitions. There is no intervention from our side to work, define or allocate partitions when a table is created, grows or requires more read/write capacity. Partition management is taken care of entirely by the service.

On the other end we have zonal services like Amazon EC2 and Autoscaling. In an Autoscaling group we must explicitly tell the EC2 service to provision instances across all Availability Zones, and as the compute demand grows and the number of instances increase in response to that demand, Autoscaling will provision instances evenly spread across the Availability Zones for us. While Autoscaling handles the provisioning for us based on the metrics we define, we do play a role in defining in which Availability Zones the instances will be provisioned. If we don’t instruct Autoscaling to use all 3 Availability Zones we are missing the opportunity to leverage AWS’s full potential in case of a zone failure.

Reading through the documentation of various services we find that they all use in one way or another all 3 Availability Zones. Amazon S3 runs on 3 or more Availability Zones (except for the One Zone Storage class), Amazon EKS runs the Kubernetes control plane across 3 Availability Zones, and in the case of Amazon Aurora, while you decide in which Availability Zone you deploy your instance, the data is replicated 6 times across all 3 Availability Zones.

This still holds true when we look at regions like Canada (ca-central-1) with only 2 Availability Zones. In this case AWS manages a hidden Availability Zone from a zonal service point of view to still provide the same service level. In the example of Amazon S3 this means that the durability of 99.999999999% can still be provided.

Without going into much detail, I recommend watching one of the best keynotes from re:Invent 2018 for me, delivered by Dr. Werner Vogels, Chief Technology Officer at Amazon.com. In this keynote he goes through the concepts of blast radius, cell-based architectures and quorums, and how AWS uses these to design their services for failure because, his words, “everything fails, all the time”.

Back to the new region in Spain

We touched on the region names earlier on and mentioned that an AWS region common name is normally that of the city closer to it, yet the new region was announced as the AWS Europe (Spain) Region. Reading through the announcement I searched for the city where it would be located with no luck. I also read through Werner Vogels’ blog for confirmation on my findings, and again I found nothing there. There is no reference to Madrid or Barcelona, the two biggest cities in Spain. So, where will it be?

I reached out to a friend in Spain who pointed me to a media publication stating the new AWS region will be in the region of Aragon, roughly half-way between Madrid and Barcelona. We have until late 2022 or early 2023 to read official confirmation on the location and if the region name will remain as Spain, or if it will change and use that of the closest city. I guess if the name remains as announced, once again, we can smile and say that Spain is always a little bit different.

This article was written by Jesus Rodriguez, Cloud Solutions Architect at AC3. Jesus has over 8 years of experience in IT, Certified AWS Solutions Architect Professional, Certified AWS DevOps Professional, and Certified AWS Big Data - Specialty, with a strong focus on implementing, deploying and provisioning secure, high available, scalable and cost optimized applications utilizing the best AWS services for each use case.