What would be the purpose of the company spreading their AWS resources across multiple Regions

When considering the various issues which can cause a website or application to become unresponsive one of the big concerns is outages.  This can be in the form of server hardware failure, software bugs, power outages, internet routing issues and natural disasters.   When trying to figure out the best way to mitigate the damages incurred by these events deploying a highly available cloud architecture is a huge part.

So what is a highly available cloud architecture?  Well it consists of many parts which will be custom fitted to the project depending on project size, geographic targeting, expected traffic and traffic spikes.  A startup company with low traffic and a small budget may only require two availability zones with a single server instance in each zone while a large project with global reach may require multiple availability zones spread out over multiple regions with many servers in each zone.

What is an availability zone?  In Amazon’s AWS platform availability zones are individual data centers scattered around the world. Within those data centers, are the servers, storage, and network that make up the AWS infrastructure and provide Cloud services. Every AWS region has more than one availability zone, and all of the zones within a given region are connected to each other.

What’s the benefit of using multiple availability zones?  Well, there are several benefits, first being lower latency.  When it comes to latency, it makes a lot more sense to have the servers that provide a given application located relatively close to the end users that will access that application. Latency is a big issue in the application world, and Amazon address is this by distributing its servers and storage, placing those resources closer to their customers’ end users.  Additionally, customers can deploy their applications and instances across availability zones, and design their environment so that if one availability zone fails, the instances in the other availability zone will become active, and continue the work of the servers in the failed availability zone, until such time as service can be restored.

This provides the benefit of allowing AWS customers who have infrastructure spread across more than one zone are better able to deal with outages in application downtime. With this kind of design, AWS customers are able to mitigate many of the outages that cloud applications are often subject to, and is another benefit of using the AWS platform.

See the AWS Architecture Center for more information

The basics of AWS Regions and Availability Zones

We’re going to treat this article as a sort of AWS 101 — it’ll be a quick primer on AWS Regions and Availability Zones that will be useful for understanding the basics of how AWS infrastructure is organized.

We’ll define each section, then clearly list the current availability, and sprinkle in some best practices as well.

And don’t worry if all this comes too fast — if you’re new to AWS you can check out our AWS Fundamentals Learning Path to get you on a structured plan with hands-on AWS experience.

What are AWS Regions?

AWS Regions are separate geographic areas that AWS uses to house its infrastructure. These are distributed around the world so that customers can choose a region closest to them in order to host their cloud infrastructure there. The closer your region is to you, the better, so that you can reduce network latency as much as possible for your end-users. You want to be near the data centers for fast service.

What AWS Regions are currently available?

As of November 2019, there are 23 AWS Regions:

What AWS Regions have the most services?

Not all regions are created equally. These regions have more services than others in their general areas:

• Americas: US East (N. Virginia), US West (N. California)
• Asia Pacific:  Singapore, Sydney, Tokyo
• EU: Frankfurt, Ireland

Best practices for choosing AWS Regions

In general, try to follow these best practices when you choose a region, to help ensure top performance and resilience:

• Proximity: Choose a region closest to your location and your customers’ location to optimize network latency.
• Services: Try and think about what are your most needed services. Usually, the newest services start on a few main regions then pop up in other regions later.
• Cost: Certain regions will cost more than others, so use built-in AWS calculators to do rough cost estimates to inform your choices.
• Service Level Agreement (SLA): Just as with cost, your SLA details will vary by region, so be sure to be aware of what your needs are and if they’re being met.
• Compliance: You may need to meet regulatory compliance needs such as GDPR by hosting your deployment in a specific — or multiple regions.

What are AWS Availability Zones?

An AWS Availability Zone (AZ) is the logical building block that makes up an AWS Region. There are currently 69 AZs, which are isolated locations— data centers — within a region. Each region has multiple AZs and when you design your infrastructure to have backups of data in other AZs you are building a very efficient model of resiliency, i.e. a core concept of cloud computing.

See the below image from AWS documentation for a visual representation of Availablity Zones within Regions.

Advice for using AWS Availability Zones

There are several reasons why a good strategy with regard to AZs comes in handy in several different situations. Just to cite some of the most common use cases, if you distribute your instances across multiple Availability Zones and one instance fails, you can design your application so that an instance in another Availability Zone can handle requests. This is like an emergency load balancer without using an actual load balancer.

In general, AWS Availability Zones give you the flexibility to launch production apps and resources that are highly available, resilient/fault-tolerant, and scalable as compared to using a single data center. Having more options and backups is better!

Accessing regions and availability zones via endpoints

There is one additional concept that can be helpful to be aware of when thinking about regions and AZs: endpoints.

In a nutshell, endpoints are specific URLs that act as an entry point for a web service, and many AWS services will have an endpoint based on its region/AZ. Endpoints aim to reduce further the latency of your applications, but not all AWS services support endpoints with regions/AZ data in the naming convention. Certain global services such as IAM will have a single endpoint: iam.amazonaws.com, but a good way to think about it is that most services that are related to a resource (such as an EC2 instance or a DB) will have an endpoint that references its geographic location, such as dynamodb.eu-west-1.amazonaws.com.

Why does AWS have multiple regions?

What is the purpose of AWS regions?

What is the advantage of launching application across multiple zones?

Which of the following is a benefit of deploying workloads in multiple AWS regions?