AWS Multi-Region Fundamentals

Publication date: December 20, 2022 (Document revisions)

Abstract

This advanced, 300-level paper is intended for cloud architects and senior leaders building workloads on AWS who are interested in using a multi-Region architecture to improve resilience for their workloads. This paper assumes baseline knowledge of AWS infrastructure and services. It outlines common multi-Region use cases, shares fundamental multi-Region concepts and implications around design, development, and deployment, and provides prescriptive guidance to help you better determine whether a multi-Region architecture is right for your workloads.

Are you Well-Architected?

The AWS Well-Architected Framework helps you understand the pros and cons of the decisions you make when building systems in the cloud. The six pillars of the Framework allow you to learn architectural best practices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems. Using the AWS Well-Architected Tool, available at no charge in the AWS Management Console, you can review your workloads against these best practices by answering a set of questions for each pillar.

For more expert guidance and best practices for your cloud architecture—reference architecture deployments, diagrams, and whitepapers—refer to the AWS Architecture Center.

Introduction

Each AWS Region consists of multiple independent and physically separate Availability Zones within a geographic area. Strict logical separation between the software services in each Region is maintained. This purposeful design ensures that an infrastructure or services failure in one Region will not result in a correlated failure in another Region.

Most AWS customers can achieve their resilience objectives for a workload in a single Region using multiple Availability Zones (AZs) or Regional AWS services. However, a subset of customers pursue multi-Region architectures for three reasons.

• They have high availability and continuity of operations requirements for their highest tier workloads that they believe cannot be met in a single Region.

• They need to satisfy data sovereignty requirements (such as adherence to local laws, regulations, and compliance) which require workloads to operate within a certain jurisdiction.

• They need to improve performance and customer experience for the workload by running the workloads in locations closest to end users.

This paper focuses on high availability and continuity of operations requirements, and helps you navigate the considerations for adopting a multi-Region architecture for a workload. We describe fundamental concepts that apply to design, development, and deployment of a multi-Region workload, along with a prescriptive framework to help you determine whether a multi-Region architecture is the right choice for a particular workload. You need to ensure a multi-Region architecture is the right choice for your workload, because these architectures are challenging, and it’s possible that, if not done correctly, the overall availability of the workload can decrease.