One of the great things about AWS is that it’s so easy to get started with. So easy, you probably aren’t even thinking about things like what AWS regions your deployment should be based out of, after all the web console makes it frighteningly easy to get your EC2 instances up and running. You may also use other services such as storage, database, or any the many other available offerings inside the AWS console.
Since it is so easy, you’re probably creating all of your AWS resources inside the most common landing spot. That would be the US-East-1 Region which is also known as N-VIRG for North Virginia. The reason this is the most common place that people drop their AWS resources is that it is the default setting that shows up in your AWS console when you log in.
You can change the setting in the AWS console by choosing the region setting at the top right:
A list of available AWS regions.
There are more regions being added all of the time around the world. The AWS growth includes both in adding AWS regions and in adding Availability Zones (AZ) within regions. The default for launching EC2 instances into the default VPC will be be into any available subnet and AZ within that zone. You will be given a round robin result unless you choose to explicitly assign one:
AWS Default Availability Zone Option
When you’re launching into your now VPC the choices will be from the Availability Zones that you’ve created subnets in. This is where we start to get into some more interesting concepts. First we have to think about what services we are making use of, and then we select which region to hold them. There are lots of factors including:
- Location of the customers consuming the resource
- Cost
- Service availability
Region Unsupported – The Other AWS Challenge
At AWS re:Invent in 2016 it was announced that nearly 1,000 services that were added in the calendar year. That is an impressive sounding number but does come with a few caveats. What does 1,000 services actually mean? The fine print on the statement is that some services were added and then made available within new Regions and Availability Zones. This can have a bit of an amplifying effect on the statistics which we have to be careful of.
The reason we want to highlight that announcement is there are many services which are not yet available in some regions. This happens as the services move into higher demand from certain geographies and AWS makes the decision to add locally hosted versions of that particular service in a new area.
An example of a feature unsupported in a particular region
There is an assumption that any service that is not available within a region indicates that it is not needed locally. Please make sure that you plan accordingly during your deployment.
AWS Regions and AZ Diversity
The goal of our applications is to ensure they are available for the best possible cost and the best availability SLA based on the cost limits we face for our company. Designing your cloud-native application, stateless deployments into multiple AZs and Regions are going to become a standard practice that we should all draw on.
It may seem like a rare occasion that you lose access to a whole Region or one or more Availability Zones within a Region, but it does happen. The most recent event that showed us this was the Mirai botnet which launched a distributed denial-of-service (DDoS) attack on the world’s DNS infrastructure. This did cause widespread issues with DNS on the AWS Route 53 environment in a specific set of AZs and Regions. This quickly showed a lot of people that they needed to architect for diversity across the underlying services to make sure they didn’t get caught out again like that.
Regional Choice, Regional Cost
This brings us to a very important piece of information that we forget about sometimes. The per-hour cost of AWS services will be different within different AWS regions. This is because of a whole host of operational reasons such as power cost, amount of demand, other services, and much more. We don’t know exactly what the formula is because it is a propriety thing within the AWS environment itself. AWS does publish their pricing for every service within every region. The only catch with AWS pricing is that you do have to search by service within the console and this often leads to frustration. It’s not unlike trying to find a clock inside a casino. Both AWS pricing lookups and the missing clocks are by design.
When you design your resilient AWS environment with AWS regions, you will have to account for the cost as a part of the solution. Be careful that you include this in your requirements throughout the design. Regional pricing and other regional service availability will be a critical part of your architecture. If you were to depend on AWS Lex for example, you have to make sure that you can handle the latency of accessing it from where it resides in the US-East-1 Region. If you rely on servicing high speed delivery of content via an Edge service, you have to make sure that one is available in the area you are hoping to accelerate service delivery into.
There is a handy page for tracking the services that are located in each region which is available as a real-time resource for confirming services per-region. At the time of this writing there are 16 Regions and 42 Availability Zones. Make sure that you aren’t just putting everything into one AWS region. It’s up to us to design for resiliency with AWS.