# REL10-BP01 複数の場所にワークロードをデプロイする
<a name="rel_fault_isolation_multiaz_region_system"></a>

 ワークロードのデータとリソースを複数のアベイラビリティーゾーンに分散するか、必要に応じて複数の AWS リージョンにまたがって分散します。

 AWS のサービス設計の基本的な原則は、基盤となる物理インフラストラクチャを含む単一障害点を回避することです。AWS は、[リージョン](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/regions.html)と呼ばれる複数の地理的ロケーションで、クラウドコンピューティングリソースとサービスをグローバルに提供します。各リージョンは物理的および論理的に独立しており、3 つ以上の[アベイラビリティーゾーン (AZ)](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/availability-zones.html) で構成されています。アベイラビリティーゾーンは地理的には互いに近接していますが、物理的には分離され、隔離されています。アベイラビリティーゾーンとリージョン間でワークロードを分散すると、火災、洪水、気象関連の災害、地震、人為的ミスなどの脅威のリスクが軽減されます。

 ワークロードに適した高可用性を提供するロケーション戦略を作成します。

 **期待される成果:** 本番稼働ワークロードは、耐障害性と高可用性を実現するために、複数のアベイラビリティーゾーン (AZ) またはリージョンに分散されます。

 **一般的なアンチパターン:** 
+  本番稼働ワークロードを 1 つのアベイラビリティーゾーンにのみ存在させる。
+  マルチ AZ アーキテクチャでビジネス要件を満たせるときに、マルチリージョンアーキテクチャを実装する。
+  デプロイまたはデータが非同期化され、設定ドリフトやデータのレプリケート不足が発生する。
+  回復力要件とマルチロケーション要件がアプリケーションコンポーネント間で異なる場合に、コンポーネント間の依存関係を考慮しない。

 **このベストプラクティスを活用するメリット:** 
+  ワークロードは、電力や環境制御の障害、自然災害、アップストリームサービスの障害、AZ またはリージョン全体に影響を及ぼすネットワークの問題などのインシデントに対して、より耐性を持つようになります。
+  Amazon EC2 インスタンスの広範なインベントリにアクセスし、特定の EC2 インスタンスタイプを起動するときに InsufficientCapacityExceptions (ICE) が発生する可能性を減らすことができます。

 **このベストプラクティスを活用しない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>

 リージョンの少なくとも 2 つのアベイラビリティーゾーン (AZ) にすべての本番稼働ワークロードをデプロイして運用します。

 **複数のアベイラビリティーゾーンを使用する** 

 アベイラビリティーゾーンは、火災、洪水、竜巻などのリスクによる相関障害を回避するために、物理的に互いに分離されたリソースホスティングの場所です。各アベイラビリティーゾーンには、ユーティリティ電源接続、バックアップ電源、機械サービス、ネットワーク接続などの独立した物理インフラストラクチャがあります。この配置により、これらのコンポーネントのいずれかの障害は、影響を受けるアベイラビリティーゾーンのみに制限されます。例えば、AZ 全体のインシデントにより、影響を受けるアベイラビリティーゾーンで EC2 インスタンスが使用できなくなった場合でも、他のアベイラビリティーゾーンのインスタンスは引き続き利用できます。

 物理的に分離されているにもかかわらず、同じ AWS リージョン 内のアベイラビリティーゾーンは、高スループット、低レイテンシー (1 桁ミリ秒) のネットワークを提供できるほど近い位置にあります。ユーザーエクスペリエンスに大きな影響を与えることなく、ほとんどのワークロードのアベイラビリティーゾーン間でデータを同期的にレプリケートできます。つまり、アクティブ/アクティブまたはアクティブ/スタンバイの設定でリージョンのアベイラビリティーゾーンを使用できます。

 ワークロードに関連するすべてのコンピューティングは、複数のアベイラビリティーゾーンに分散する必要があります。これには、[Amazon EC2](https://aws.amazon.com/ec2/) インスタンス、[AWS Fargate](https://aws.amazon.com/fargate/) タスク、VPC にアタッチされた [AWS Lambda](https://aws.amazon.com/lambda/) 関数が含まれます。[EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/)、[Amazon Elastic Container Service (ECS)](https://aws.amazon.com/ecs/)、[Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/) などの AWS コンピューティングサービスは、アベイラビリティーゾーン間でコンピューティングを起動および管理する方法を提供します。必要に応じて別のアベイラビリティーゾーンでコンピューティングを自動的に置き換えるように設定して、アベイラビリティーを維持します。利用可能なアベイラビリティーゾーンにトラフィックを転送するには、コンピューティングの前に、Application Load Balancer や Network Load Balancer などのロードバランサーを配置します。AWS Load Balancer は、アベイラビリティーゾーンに障害が発生した場合に、トラフィックを利用可能なインスタンスに再ルーティングできます。

 また、ワークロードのデータをレプリケートし、複数のアベイラビリティーゾーンで使用できるようにする必要があります。[Amazon S3](https://aws.amazon.com/s3/)、[Amazon Elastic File Service (EFS)](https://aws.amazon.com/efs/)、[Amazon Aurora](https://aws.amazon.com/aurora/)、[Amazon DynamoDB](https://aws.amazon.com/dynamodb/)、[Amazon Simple Queue Service (SQS)](https://aws.amazon.com/sqs/)、[Amazon Kinesis Data Streams](https://aws.amazon.com/kinesis/data-streams/) などの一部の AWS マネージドデータサービスは、デフォルトで複数のアベイラビリティーゾーンにデータをレプリケートし、アベイラビリティーゾーンの障害に対して堅牢です。[Amazon Relational Database Service (RDS)](https://aws.amazon.com/rds/)、[Amazon Redshift](https://aws.amazon.com/redshift/)、[Amazon ElastiCache](https://aws.amazon.com/elasticache/) などの他の AWS マネージドデータサービスでは、マルチ AZ レプリケーションを有効にする必要があります。これらのサービスを有効にすると、アベイラビリティーゾーンの障害が自動的に検出され、利用可能なアベイラビリティーゾーンにリクエストがリダイレクトされ、復旧後に必要に応じて顧客の介入なしにデータの再レプリケートが行われます。使用する各 AWS マネージドデータサービスのユーザーガイドをよく読み、マルチ AZ 機能、動作、操作を理解してください。

 [Amazon Elastic Block Store (EBS)](https://aws.amazon.com/ebs/) ボリュームや Amazon EC2 インスタンスストレージなどのセルフマネージドストレージを使用している場合は、マルチ AZ レプリケーションを自分で管理する必要があります。

![\[3 つのアベイラビリティーゾーンにまたがってデプロイされる多階層アーキテクチャを示す図。Amazon S3 と Amazon DynamoDB は常に自動的にマルチ AZ です。ELB も 3 つのゾーンすべてにデプロイされます。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/images/multi-tier-architecture.png)


 **複数の AWS リージョン を使用する** 

 非常に高い耐障害性を必要とするワークロード (重要なインフラストラクチャ、医療関連のアプリケーション、厳格な顧客要件または義務付けられたアベイラビリティー要件を持つサービスなど) がある場合は、単一の AWS リージョン で提供できるものを超える追加の可用性が必要になることがあります。この場合、少なくとも 2 つの AWS リージョン にわたってワークロードをデプロイして運用する必要があります (データレジデンシー要件で許可されている場合)。

 AWS リージョン は、世界中のさまざまな地理的地域と複数の大陸にあります。AWS リージョン は、アベイラビリティーゾーンのみよりもさらに物理的に分離および隔離されています。AWS サービスは、いくつかの例外を除き、この設計を利用して、異なるリージョン間で完全に独立して動作します (*リージョンサービス*とも呼ばれます)。AWS リージョンal サービスの障害は、別のリージョンのサービスに影響を与えないように設計されています。

 複数のリージョンでワークロードを操作する場合は、追加の要件を考慮する必要があります。異なるリージョンのリソースは互いに独立しているため、各リージョンでワークロードのコンポーネントを複製する必要があります。これには、コンピューティングおよびデータサービスに加えて、VPC などの基盤インフラストラクチャが含まれます。

 **注:** マルチリージョン設計を検討するときは、ワークロードが 1 つのリージョンで実行できることを確認します。あるリージョンのコンポーネントが別のリージョンのサービスまたはコンポーネントに依存するリージョン間に依存関係を作成すると、障害のリスクが高まり、信頼性体制が大幅に弱まる可能性があります。

 マルチリージョンのデプロイを容易にし、一貫性を維持するために、[AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html) は AWS インフラストラクチャ全体を複数のリージョンにレプリケートできます。[AWS CloudFormation](https://aws.amazon.com/cloudformation/) は、設定ドリフトを検出し、リージョン内の AWS リソースが同期していないときに通知することもできます。多くの AWS サービスは、重要なワークロードアセットに対してマルチリージョンレプリケーションを提供します。例えば、[EC2 Image Builder](https://aws.amazon.com/image-builder/) は、使用する各リージョンへのビルドのたびに EC2 マシンイメージ (AMI) を発行できます。[Amazon Elastic Container Registry (ECR)](https://aws.amazon.com/ecr/) は、コンテナイメージを選択したリージョンにレプリケートできます。

 選択した各リージョンにもデータをレプリケートする必要があります。多くの AWS マネージドデータサービスは、Amazon S3、Amazon DynamoDB、Amazon RDS、Amazon Aurora、Amazon Redshift、Amazon Elasticache、Amazon EFS などのクロスリージョンレプリケーション機能を備えています。[Amazon DynamoDB グローバルテーブル](https://aws.amazon.com/dynamodb/global-tables/)は、サポートされている任意のリージョンでの書き込みを受け入れ、他のすべての設定済みリージョン間でデータをレプリケートします。他のサービスでは、他のリージョンに読み取り専用レプリカが含まれているため、書き込みのプライマリリージョンを指定する必要があります。ワークロードが使用する AWS マネージドデータサービスごとに、そのユーザーガイドとデベロッパーガイドを参照して、マルチリージョンの機能と制限を理解してください。書き込みの転送先、トランザクションの機能と制限、レプリケーションの実行方法、リージョン間の同期をモニタリングする方法に特に注意してください。

 AWS には、リクエストトラフィックをリージョンデプロイに非常に柔軟にルーティングする機能もあります。例えば、[Amazon Route 53](https://aws.amazon.com/route53/) を使用して DNS レコードを設定し、ユーザーに最も近い利用可能なリージョンにトラフィックを誘導できます。または、DNS レコードをアクティブ/スタンバイ構成で構成し、1 つのリージョンをプライマリとして指定し、プライマリリージョンに異常が発生した場合にのみリージョンレプリカにフォールバックすることもできます。[Route 53 ヘルスチェック](https://docs.aws.amazon.com/Route 53/latest/DeveloperGuide/dns-failover.html)を設定し、異常なエンドポイントを検出し、自動フェイルオーバーを実行し、さらに [Amazon Application Recovery Controller (ARC)](https://aws.amazon.com/application-recovery-controller/) を使用して、必要に応じて手動でトラフィックを再ルーティングするための高可用性ルーティング制御を実現できます。

 高可用性のために複数のリージョンで運用しないことを選択した場合でも、ディザスタリカバリ (DR) 戦略の一環として複数のリージョンを検討してください。可能であれば、ワークロードのインフラストラクチャコンポーネントとデータを、セカンダリリージョンの*ウォームスタンバイ*または*パイロットライト*構成でレプリケートします。この設計では、VPC、Auto Scaling グループ、コンテナオーケストレーター、その他のコンポーネントなどのプライマリリージョンからベースラインインフラストラクチャをレプリケートしますが、スタンバイリージョンの可変サイズのコンポーネント (EC2 インスタンスやデータベースレプリカの数など) を最小操作可能なサイズに設定します。また、プライマリリージョンからスタンバイリージョンへの継続的なデータレプリケーションも用意します。インシデントが発生した場合は、スタンバイリージョンのリソースをスケールアウトまたは拡張し、プライマリリージョンに昇格させることができます。

### 実装手順
<a name="implementation-steps"></a>

1.  ビジネス関係者やデータレジデンシーのエキスパートと協力して、リソースとデータをホストするためにどの AWS リージョン を使用できるかを決定します。

1.  ビジネスおよび技術の関係者と協力してワークロードを評価し、その耐障害性ニーズがマルチ AZ アプローチ (単一の AWS リージョン) で満たされるかどうか、またはマルチリージョンアプローチ (複数のリージョンが許可されている場合) が必要かどうかを判断します。複数のリージョンを使用すると可用性が高まりますが、複雑さとコストが増加する可能性があります。評価する際には、次の要素を考慮してください。

   1.  **ビジネス目的と顧客要件:** アベイラビリティーゾーンまたはリージョンでワークロードに影響を与えるインシデントが発生すると、どのくらいのダウンタイムが許容されますか? 「[REL13-BP01 ダウンタイムやデータ損失に関する復旧目標を定義する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html)」で説明されているように、復旧ポイントの目的を評価します。

   1.  **ディザスタリカバリ (DR) の要件**: どのような潜在的な災害に対して保険をかけたいですか? 単一のアベイラビリティーゾーンからリージョン全体まで、さまざまな影響範囲でデータ損失や長期的に利用不可になる可能性を考慮してください。アベイラビリティーゾーン間でデータとリソースをレプリケートし、1 つのアベイラビリティーゾーンで持続的な障害が発生した場合は、別のアベイラビリティーゾーンでサービスを復旧できます。リージョン間でデータとリソースをレプリケートする場合、別のリージョンでサービスを復旧できます。

1.  コンピューティングリソースを複数のアベイラビリティーゾーンにデプロイします。

   1.  VPC で、異なるアベイラビリティーゾーンに複数のサブネットを作成します。インシデント発生時でもワークロードを処理するために必要なリソースを収容できる大きさになるようにそれぞれを構成します。詳細については、「[REL02-BP03 拡張性と可用性を考慮した IP サブネットの割り当てを確実に行う](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_ip_subnet_allocation.html)」を参照してください。

   1.  Amazon EC2 インスタンスを使用している場合は、[EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) を使用してインスタンスを管理します。Auto Scaling グループの作成時に前のステップで選択したサブネットを指定します。

   1.  [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/AWS_Fargate.html) または [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/fargate.html)の AWS Fargate コンピューティングを使用している場合は、ECS Service の作成、ECS タスクの起動、または EKS の [Fargate プロファイル](https://docs.aws.amazon.com/eks/latest/userguide/fargate-profile.html)の作成の最初のステップで選択したサブネットを選択します。

   1.  VPC で実行する必要がある AWS Lambda 関数を使用している場合は、Lambda 関数の作成時に最初のステップで選択したサブネットを選択します。VPC 構成を持たない機能については、AWS Lambda が自動的に可用性を管理します。

   1.  ロードバランサーなどのトラフィックディレクターをコンピューティングリソースの前に配置します。クロスゾーン負荷分散が有効になっている場合、[AWS Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) と [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) は、アベイラビリティーゾーンの障害が原因で EC2 インスタンスやコンテナなどのターゲットに到達できない場合にそれを検出し、正常なアベイラビリティーゾーンのターゲットにトラフィックを再ルーティングします。クロスゾーン負荷分散を無効にする場合は、Amazon Application Recovery Controller (ARC) を使用してゾーンシフト機能を提供します。サードパーティーのロードバランサーを使用している場合、または独自のロードバランサーを実装している場合は、異なるアベイラビリティーゾーンにまたがる複数のフロントエンドでロードバランサーを設定します。

1.  ワークロードのデータを複数のアベイラビリティーゾーンにレプリケートします。

   1.  Amazon RDS、Amazon ElastiCache、Amazon FSx などの AWS マネージドデータサービスを使用する場合は、そのユーザーガイドを読んで、データのレプリケーションと耐障害性の機能を理解します。必要に応じてクロス AZ レプリケーションとフェイルオーバーを有効にします。

   1.  Amazon S3、Amazon EFS、Amazon FSx などの AWS マネージドストレージサービスを使用する場合は、高い耐久性が求められるデータに対してシングル AZ または 1 つのゾーン構成を使用しないでください。これらのサービスにはマルチ AZ 設定を使用します。各サービスのユーザーガイドを確認して、マルチ AZ レプリケーションがデフォルトで有効になっているか、有効にする必要があるかを判断します。

   1.  セルフマネージド型データベース、キュー、またはその他のストレージサービスを実行する場合は、アプリケーションの手順またはベストプラクティスに従って、マルチ AZ レプリケーションを調整します。アプリケーションのフェイルオーバー手順を理解します。

1.  AZ の障害を検出し、正常なアベイラビリティーゾーンにトラフィックを再ルーティングするように DNS サービスを設定します。Amazon Route 53 を Elastic ロードバランサーと組み合わせて使用すると、自動的にこれを実行できます。Route 53 は、ヘルスチェックを使用して正常な IP アドレスのみを持つクエリに応答するフェイルオーバーレコードで設定することもできます。フェイルオーバーに使用される DNS レコードでは、レコードキャッシュが復旧を妨げるのを防ぐために、短い有効期間 (TTL) 値 (60 秒以下など) を指定します (Route 53 エイリアスレコードは適切な TTL を提供します)。

 **複数の AWS リージョン を使用する場合の追加ステップ** 

1.  選択したリージョン全体で、ワークロードで使用されるすべてのオペレーティングシステム (OS) とアプリケーションコードをレプリケートします。必要に応じて、Amazon EC2 Image Builder などのソリューションを使用して Amazon EC2 マシンイメージ (AMI) をレプリケートします。Amazon ECR クロスリージョンレプリケーションなどのソリューションを使用して、レジストリに保存されているコンテナイメージをレプリケートします。アプリケーションリソースの保存に使用される Amazon S3 バケットのリージョンレプリケーションを有効にします。

1.  コンピューティングリソースと設定メタデータ (AWS Systems Manager Parameter Store に保存されているパラメータなど) を複数のリージョンにデプロイします。前のステップで説明したのと同じ手順を使用しますが、ワークロードに使用するリージョンごとに設定をレプリケートします。AWS CloudFormation などの Infrastructure as code (IaC) ソリューションを使用して、リージョン間で設定を均一に再現します。ディザスタリカバリにパイロットライト設定でセカンダリリージョンを使用している場合は、コンピューティングリソースの数を最小値に減らしてコストを削減し、それに応じて復旧までの時間を長くすることができます。

1.  プライマリリージョンからセカンダリリージョンにデータをレプリケートします。

   1.  Amazon DynamoDB グローバルテーブルは、サポートされている任意のリージョンから書き込むことができるデータのグローバルレプリカを提供します。Amazon RDS、Amazon Aurora、Amazon Elasticache などの他の AWS マネージドデータサービスでは、プライマリ (読み取り/書き込み) リージョンとレプリカ (読み取り専用) リージョンを指定します。リージョンレプリケーションの詳細については、各サービスのユーザーガイドとデベロッパーガイドを参照してください。

   1.  セルフマネージドデータベースを実行している場合は、アプリケーションの手順またはベストプラクティスに従って、マルチリージョンレプリケーションを調整します。アプリケーションのフェイルオーバー手順を理解します。

   1.  ワークロードで AWS EventBridge を使用している場合は、選択したイベントをプライマリリージョンからセカンダリリージョンに転送する必要がある場合があります。そのためには、セカンダリリージョンのイベントバスをプライマリリージョンの一致イベントのターゲットとして指定します。

1.  リージョン間で同じ暗号化キーを使用するかどうか、またどの程度使用するかを検討します。セキュリティと使いやすさのバランスをとる一般的なアプローチは、リージョンローカルデータと認証にリージョンスコープキーを使用し、グローバルスコープキーを使用して、異なるリージョン間でレプリケートされるデータの暗号化を行うことです。[AWS Key Management Service(KMS)](https://aws.amazon.com/kms/) は、リージョン間で共有されるキーを安全に分散および保護するための[マルチリージョンキー](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)をサポートしています。

1.  AWS Global Accelerator を検討して、正常なエンドポイントを含むリージョンにトラフィックを誘導することによって、アプリケーションの可用性を向上させます。

## リソース
<a name="resources"></a>

 **関連するベストプラクティス:** 
+  [REL02-BP03 拡張性と可用性を考慮した IP サブネットの割り当てを確実に行う](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_network_topology_ip_subnet_allocation.html) 
+  [REL11-BP05 静的安定性を使用してバイモーダル動作を防止する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_static_stability.html) 
+  [REL13-BP01 ダウンタイムやデータ損失に関する復旧目標を定義する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_objective_defined_recovery.html) 

 **関連ドキュメント:** 
+  [AWS グローバルインフラストラクチャ](https://aws.amazon.com/about-aws/global-infrastructure) 
+  [ホワイトペーパー: AWS 障害分離境界](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/availability-zones.html) 
+  [Amazon EC2 Auto Scaling のレジリエンス](https://docs.aws.amazon.com/autoscaling/ec2/userguide/disaster-recovery-resiliency.html) 
+  [Amazon EC2 Auto Scaling: 例: アベイラビリティーゾーン間でインスタンスを分散する](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ) 
+  [EC2 Image Builder の仕組み](https://docs.aws.amazon.com/imagebuilder/latest/userguide/how-image-builder-works.html#image-builder-distribution) 
+  [Amazon ECS がタスクをコンテナインスタンスに配置する方法 (Fargate を含む)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement.html) 
+  [AWS Lambda での回復力](https://docs.aws.amazon.com/lambda/latest/dg/security-resilience.html) 
+  [Amazon S3: オブジェクトレプリケーションの概要](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html) 
+  [Amazon ECR でのプライベートイメージレプリケーション](https://docs.aws.amazon.com/AmazonECR/latest/userguide/replication.html) 
+  [グローバルテーブル: DynamoDB を使用した複数リージョンレプリケーション](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html) 
+  [Amazon Elasticache for Redis OSS: グローバルデータストアを使用した AWS リージョン 間のレプリケーション](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Redis-Global-Datastore.html) 
+  [Amazon RDS の耐障害性](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/disaster-recovery-resiliency.html) 
+  [Amazon Aurora Global Database の使用](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html) 
+  [AWS Global Accelerator デベロッパーガイド](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html) 
+  [AWS KMS のマルチリージョンキー](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html) 
+  [Amazon Route 53: DNS フェイルオーバーの設定](https://docs.aws.amazon.com/Route 53/latest/DeveloperGuide/dns-failover-configuring.html) 
+  [Amazon Application Recovery Controller (ARC) デベロッパーガイド](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) 
+  [AWS リージョン間での Amazon EventBridge イベントの送受信](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cross-region.html) 
+  [AWS のサービスによるマルチリージョンアプリケーションの作成 (ブログシリーズ)](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/) 
+  [Disaster Recovery (DR) Architecture on AWS, Part I: Strategies for Recovery in the Cloud](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/) 
+  [AWS でのディザスタリカバリ (DR) アーキテクチャ、パート III: パイロットライトとウォームスタンバイ](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/) 

 **関連動画:** 
+  [AWS re:Invent 2018: マルチリージョンアクティブ/アクティブアプリケーション用アーキテクチャパターン](https://youtu.be/2e29I3dA8o4) 
+  [AWS re:Invent 2019: AWS グローバルネットワークインフラストラクチャの革新性とオペレーション](https://youtu.be/UObQZ3R9_4c)