# REL 13. ディザスタリカバリ (DR) はどのように計画するのですか?
<a name="rel-13"></a>

バックアップと冗長ワークロードコンポーネントを配置することは、DR 戦略の出発点です。[RTO と RPO](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) は、ワークロードを回復するための目標です。これは、ビジネスニーズに基づいて設定します。ワークロードのリソースとデータのロケーションと機能を考慮して、目標を達成するための戦略を実装します。ワークロードのディザスタリカバリを提供することのビジネス価値を伝える際、中断の可能性と復旧コストも重要な要素となります。

**Topics**
+ [

# REL13-BP01 ダウンタイムやデータ消失に関する復旧目標を定義する
](rel_planning_for_recovery_objective_defined_recovery.md)
+ [

# REL13-BP02 復旧目標を満たすため、定義された復旧戦略を使用する
](rel_planning_for_recovery_disaster_recovery.md)
+ [

# REL13-BP03 ディザスタリカバリの実装をテストし、実装を検証する
](rel_planning_for_recovery_dr_tested.md)
+ [

# REL13-BP04 DR サイトまたはリージョンでの設定ドリフトを管理する
](rel_planning_for_recovery_config_drift.md)
+ [

# REL13-BP05 復旧を自動化する
](rel_planning_for_recovery_auto_recovery.md)

# REL13-BP01 ダウンタイムやデータ消失に関する復旧目標を定義する
<a name="rel_planning_for_recovery_objective_defined_recovery"></a>

 障害は、さまざまな方法でビジネスに影響を与える可能性があります。まず、障害が発生するとサービスの中断 (ダウンタイム) が発生する可能性があります。2 つ目は、障害によりデータが失われたり、一貫性がなくなったり、古くなったりする可能性があります。障害への対応方法と障害からの復旧方法をガイドするために、ワークロードごとに目標復旧時間 (RTO) と目標復旧時点 (RPO) を定義します。*目標復旧時間 (RTO)* は、サービスの中断から復旧までの最大許容遅延時間です。*目標復旧時点 (RPO)* は、最後に実行されたデータ復旧時点からの最大許容時間です。

 **期待される成果:** すべてのワークロードには、技術的な考慮事項とビジネスへの影響に基づいて指定された RTO と RPO があります。

 **一般的なアンチパターン:** 
+  復旧目標が指定されていない。
+  任意の復旧目標を選択する。
+  過度に寛大で、ビジネス目標を満たさない復旧目標を選択する。
+  ダウンタイムとデータ損失の影響を評価していない。
+  復旧時間ゼロやデータ損失ゼロなど、ワークロード設定では達成できないおそれのある非現実的な復旧目標を選択する。
+  実際のビジネス目標よりも厳格な復旧目標を選択する。これにより、ワークロードが必要とするよりもコストが高く、複雑な DR 実装を強いられている。
+  依存するワークロードの復旧目標と互換性のない復旧目標を選択する。
+  規制とコンプライアンスの要件を考慮していない。

 **このベストプラクティスを活用するメリット:** ワークロードに RTO と RPO を設定すると、ビジネスニーズに基づいて明確で測定可能な復旧目標を確立できます。これらの目標を設定すると、それに合わせてカスタマイズされたディザスタリカバリ (DR) 計画を作成できます。

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

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

 ディザスタリカバリ計画の指針となるマトリックスまたはワークシートを作成します。マトリックスで、ビジネスへの影響 (重大、高、中、低など) と、それぞれにターゲットとする関連する RTO と RPO に基づいて、異なるワークロードカテゴリまたは階層を作成します。次のマトリックスは、従うことができる例を示しています (RTO と RPO の値は異なる場合があります)。

![\[ディザスタリカバリマトリックスを示すチャート\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/images/disaster-recovery-matrix.png)


 各ワークロードについて、ダウンタイムとデータ損失がビジネスに与える影響を調査して理解します。影響は通常、ダウンタイムとデータ損失と共に大きくなりますが、影響の形状はワークロードタイプによって異なります。例えば、最大 1 時間のダウンタイムによる影響は小さいかもしれませんが、その後、影響が急速に拡大する可能性があります。影響には、財務上の影響 (収益の損失など)、評判上の影響 (顧客の信頼の喪失を含む)、運用上の影響 (給与の損失や生産性の低下など)、規制上のリスクなど、さまざまな形態があります。完了したら、ワークロードを適切な階層に割り当てます。

 障害の影響を分析するときは、次の質問を考慮してください。

1.  ビジネスに許容できない影響が生じる前にワークロードが利用できなくなる最大時間はどれくらいですか。

1.  ワークロードの中断により、ビジネスにどのような影響が及ぶでしょうか。財務、評判、運用、規制など、あらゆる種類の影響を考慮してください。

1.  ビジネスに許容できない影響が生じる前に、失われたり回復不能になったりする可能性のあるデータの最大量はどれくらいですか?

1.  失われたデータは、他のソース (*派生*データとも呼ばれます) から再作成できますか? その場合、ワークロードデータの再作成に使用されるすべてのソースデータの RPO も考慮してください。

1.  このワークロードが依存するワークロード (ダウンストリーム) の復旧目標と可用性の期待値は何ですか? ワークロードの目標は、ダウンストリームの依存関係の復旧能力を考慮して達成可能である必要があります。このワークロードの復旧能力を向上させる可能性のあるダウンストリーム依存関係の回避策または軽減策を検討してください。

1.  このワークロードに依存するワークロード (アップストリーム) の復旧目標と可用性の期待値は何ですか? アップストリームのワークロード目標によっては、このワークロードに、最初に想定されるよりも厳密な復旧能力が必要になる場合があります。

1.  インシデントのタイプに基づいて、さまざまな復旧目標がありますか? 例えば、インシデントがアベイラビリティーゾーンまたはリージョン全体に影響するかどうかに応じて、RTO と RPO が異なる場合があります。

1.  復旧目標は、特定のイベント中または 1 年のうちに変化しますか? 例えば、ホリデーショッピングシーズン、スポーツイベント、特別セール、新製品の発売などに合わせて、異なる RTO と RPO を設定できます。

1.  復旧目標は、どのような事業部門や組織のディザスタリカバリ戦略と整合していますか?

1.  考慮すべき法的または契約上の影響はありますか? 例えば、特定の RTO または RPO でサービスを提供する契約上の義務はありますか? それらを満たさなかった場合、どのような罰則が科される可能性がありますか?

1.  規制またはコンプライアンス要件を満たすために、データ整合性を維持する必要はありますか?

 次のワークシートは、各ワークロードの評価に役立ちます。このワークシートは、特定のニーズに応じて修正できます (質問を追加するなど)。

<a name="worksheet"></a>![\[ワークシート\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/images/worksheet.png)


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

1.  各ワークロードを担当するビジネスステークホルダーと技術チームを特定し、連携します。

1.  ワークロードが組織に与える影響について、重要度のカテゴリまたは階層を作成します。カテゴリの例としては、重要、高、中、低などがあります。カテゴリごとに、ビジネス目標と要件を反映する RTO と RPO を選択します。

1.  前のステップで作成したインパクトカテゴリの 1 つを各ワークロードに割り当てます。ワークロードがカテゴリにどのようにマッピングされるかを決定するには、ビジネスにとってのワークロードの重要性と中断やデータ損失の影響を考慮し、上記の質問を参考にしてください。これにより、ワークロードごとに RTO と RPO が作成されます。

1.  前のステップで決定した各ワークロードの RTO と RPO を検討します。ワークロードのビジネスチームと技術チームを関与させて、目標を調整する必要があるかどうかを判断します。例えば、ビジネスステークホルダーは、より厳格なターゲットが必要であると判断する可能性があります。あるいは、技術チームは、利用可能なリソースと技術的な制約で目標を達成できるようにターゲットを変更する必要があると判断することもできます。

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

 **関連するベストプラクティス:** 
+  [REL09-BP04 データの定期的な復旧を行ってバックアップの完全性とプロセスを確認する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_backing_up_data_periodic_recovery_testing_data.html) 
+  [REL12-BP01 プレイブックを使用して障害を調査する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_playbook_resiliency.html) 
+  [REL13-BP02 復旧目標を満たすため、定義された復旧戦略を使用する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html) 
+  [REL13-BP03 ディザスタリカバリの実装をテストし、実装を検証する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html) 

 **関連ドキュメント:** 
+  [AWS アーキテクチャブログ: ディザスタリカバリシリーズ](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/) 
+  [AWS でのワークロードの災害対策: クラウド内での復旧 (AWS ホワイトペーパー)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html) 
+  [AWS Resilience Hub による障害耐性ポリシーの管理](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resiliency-policies.html) 
+  [APN Partner: partners that can help with disaster recovery](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery) 
+  [AWS Marketplace: ディザスタリカバリに活用できる商品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery) 

 **関連動画:** 
+  [AWS re:Invent 2018: マルチリージョンアクティブ/アクティブアプリケーション用アーキテクチャパターン](https://youtu.be/2e29I3dA8o4) 
+  [Disaster Recovery of Workloads on AWS](https://www.youtube.com/watch?v=cJZw5mrxryA) 

# REL13-BP02 復旧目標を満たすため、定義された復旧戦略を使用する
<a name="rel_planning_for_recovery_disaster_recovery"></a>

ワークロードの復旧目標を満たすディザスタリカバリ (DR) 戦略を定義します。バックアップと復元、スタンバイ (アクティブ/パッシブ)、またはアクティブ/アクティブなどの戦略を選択します。

 **期待される成果:** 各ワークロードについて、定義され、実装された DR 戦略があり、ワークロードは DR 目標を達成できます。ワークロード間の DR 戦略では、再利用可能なパターンを利用します (以前に記載された戦略など)。

 **一般的なアンチパターン:** 
+  同じような DR 目標を持つワークロードについて、一貫性のない復旧手順を実装する。
+  DR 戦略は、災害が発生したときにアドホックに実装すればよいとする。
+  ディザスタリカバリが計画されていない。
+  復旧時にコントロールプレーンのオペレーションに依存する。

 **このベストプラクティスを活用するメリット:** 
+  定義された復旧戦略を使用すると、一般的なツールとテスト手順を使用できます。
+  定義された復旧戦略を使用すると、チーム間のナレッジ共有と、チームが所有するワークロードでの DR の実装が改善します。

 **このベストプラクティスを活用しない場合のリスクレベル:** 高 計画され、実装され、テストされた DR 戦略がなければ、災害発生時に復旧目標を達成できない可能性があります。

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

 DR 戦略は、プライマリロケーションでワークロードを実行できなくなった場合に復旧サイトでワークロードに耐えられる能力に依存します。最も一般的な復旧目標は、RTO と RPO です (「[REL13-BP01 ダウンタイムやデータ消失に関する復旧目標を定義する](rel_planning_for_recovery_objective_defined_recovery.md)」を参照)。

 単一の AWS リージョン内の複数のアベイラビリティーゾーン (AZ) にまたがる DR 戦略は、火災、洪水、大規模な停電などの災害イベントに対して影響を緩和できます。ワークロードを特定の AWS リージョンで実行できなくなるような、可能性の低いイベントに対する保護を実装する必要がある場合には、複数のリージョンを使用する DR 戦略を使用できます。

 複数のリージョンにまたがる DR 戦略を設計するときには、以下のいずれかの戦略を選んでください。戦略は、コストと複雑さが低く、かつ RTO と RPO が長い順にリストされます。リカバリリージョンとは、ワークロードに使用されるプライマリ以外の AWS リージョンを指します。

![\[DR 戦略を示す図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/images/disaster-recovery-strategies.png)


 
+  **バックアップと復元** (数時間での RPO、24 時間以下での RTO): データとアプリケーションを復旧リージョンにバックアップします。自動化されたバックアップまたは連続バックアップを使用すると、ポイントインタイムリカバリ (PITR) が可能であり、場合によっては RPO を 5 分間に短縮できます。災害の際には、インフラストラクチャをデプロイし (インフラストラクチャをコードとして使用して RTO を削減)、コードをデプロイし、バックアップされたデータを復元して、復旧リージョンで災害から復旧します。
+  **パイロットライト** (数分間の RPO、数十分間の RTO): コアワークロードインフラストラクチャのコピーを復旧リージョンにプロビジョニングします。データを復旧リージョンにレプリケートして、そこでバックアップを作成します。データベースやオブジェクトストレージなど、データのレプリケーションとバックアップのサポートに必要なリソースは、常にオンです。アプリケーションサーバーやサーバーレスコンピューティングなど、その他の要素はデプロイされませんが、必要なときには、必須の設定とアプリケーションコードで作成できます。
+  **ウォームスタンバイ** (数秒間の RPO、数分間の RTO): 完全に機能する縮小バージョンのワークロードを復旧リージョンで常に実行している状態に保ちます。ビジネスクリティカルなシステムは完全に複製され、常に稼働していますが、フリートは縮小されています。データは復旧リージョンでレプリケートされ、使用可能です。復旧時には、システムをすばやくスケールアップして本番環境の負荷を処理できるようにします。ウォームスタンバイの規模が大きいほど、RTO とコントロールプレーンへの依存は低くなります。これを完全にスケールアップしたものはホットスタンバイと呼ばれます。
+  **マルチリージョン (マルチサイト) アクティブアクティブ** (ゼロに近い RPO、ほぼゼロの RTO): ワークロードは複数の AWS リージョンにデプロイされ、そこからトラフィックにアクティブに対応します。この戦略では、複数のリージョン間でデータを同期する必要があります。2 つの異なるリージョンレプリカ内の同じレコードへの書き込みによって生じる矛盾を回避または処理する必要があり、これは複雑になることがあります。データレプリケーションは、データの同期に便利であり、特定のタイプの災害から保護しますが、ソリューションがポイントインタイムリカバリのためのオプションを含んでいない限り、データの破損や破壊からは保護しません。

**注記**  
 パイロットライトとウォームスタンバイの違いは、理解しにくいかもしれません。どちらも、プライマリリージョンアセットのコピーがある復旧リージョン内の環境を含みます。その違いは、パイロットライトが最初に追加アクションを取らなければリクエストを処理できないのに対して、ウォームスタンバイはトラフィックを直ちに (削減された能力レベルで) 処理できることです。パイロットライトでは、サーバーをオンにして、おそらく追加の (非コア) インフラストラクチャをデプロイし、スケールアップする必要があるのに対して、ウォームスタンバイでは、スケールアップするだけです (すべてが既にデプロイされ、実行しています)。RTO と RPO のニーズに基づいて、両者の中から選択してください。  
 コストが懸念事項であり、ウォームスタンバイ戦略での定義と同様の RPO および RTO 目標の達成を目指す場合は、パイロットライトアプローチを採用して、改善された RPO および RTO 目標を提供する AWS Elastic Disaster Recovery などのクラウドネイティブソリューションを検討することができます。

 **実装手順** 

1.  **このワークロードの復旧要件を満たす DR 戦略を決定します。**

    DR 戦略を選ぶということは、ダウンタイムとデータ損失の削減 (RTO と RPO) 、戦略を実装するコストと複雑性のトレードオフです。必要以上に厳格な戦略の実装は、不要なコストにつながるため避けてください。

    例えば、次の図では、許容可能な最大 RTO と、サービス復元戦略に費やすことができるコストの限界を決定しています。特定のビジネス目標の場合、パイロットライトまたはウォームスタンバイの DR 戦略は、RTO とコスト基準の両方を満たすことができます。  
![\[RTO とコストに基づく DR 戦略の選択を示すグラフ\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/images/choosing-a-dr-strategy.png)

    詳細については、「[ビジネス継続計画 (BCP)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html)」を参照してください。

1.  **選択した DR 戦略の実装パターンをレビューします。**

    このステップでは、選択した戦略の実装方法を理解します。戦略は、プライマリサイトと復旧サイトとしての AWS リージョンを使用して説明されています。ただし、単一リージョン内のアベイラビリティーゾーンを DR 戦略として使用することもでき、その場合は、これら複数の戦略の要素を利用します。

    以下の手順では、戦略を特定のワークロードに適用できます。

    **バックアップと復元**  

    バックアップと復元は、実装の複雑さが最も少ない戦略ですが、ワークロードの復元に必要な時間と労力が多く、より高い RTO と RPO につながります。常にデータのバックアップを取り、これらを別のサイト (別の AWS リージョンなど) にコピーすることをお勧めします。  
![\[バックアップと復元アーキテクチャを示す図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/images/backup-restore-architecture.png)

    この戦略の詳細については、「[AWS でのディザスタリカバリ (DR) アーキテクチャ、パート II: 迅速な復旧によるバックアップと復元](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/)」を参照してください。

    **パイロットライト** 

    パイロットライトアプローチでは、プライマリリージョンから復旧リージョンにデータをレプリケートします。ワークロードインフラストラクチャに使用されるコアリソースは復旧リージョンにデプロイされますが、これを機能するスタックにするには、やはり追加のリソースと依存関係が必要です。例えば、図 20 では、コンピューティングインスタンスはデプロイされていません。  
![\[パイロットライトアーキテクチャを示す図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/images/pilot-light-architecture.png)

    この戦略の詳細については、「[AWS でのディザスタリカバリ (DR) アーキテクチャ、パート III: パイロットライトとウォームスタンバイ](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)」を参照してください。

    **ウォームスタンバイ**。

    ウォームスタンバイアプローチでは、本番稼働環境の完全に機能する縮小コピーを別のリージョンに用意します。このアプローチは、パイロットライトの概念を拡張して、ワークロードが別のリージョンに常駐するため、復旧時間が短縮されます。復旧リージョンが完全なキャパシティでデプロイされた場合は、ホットスタンバイと呼ばれます。  
![\[図 21: ウォームスタンバイアーキテクチャを示す図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/images/warm-standby-architecture.png)

    ウォームスタンバイまたはパイロットライトを使用するには、復旧リージョンのリソースをスケールアップする必要があります。必要に応じてキャパシティが利用可能であることを保証するには、EC2 インスタンスの[キャパシティ予約](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html)の使用を検討してください。AWS Lambda を使用する場合、[プロビジョニングされた同時実行](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html)はランタイム環境を提供して、関数の呼び出しにすぐに応答する準備を整えることができます。

    この戦略の詳細については、「[AWS でのディザスタリカバリ (DR) アーキテクチャ、パート III: パイロットライトとウォームスタンバイ](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)」を参照してください。

    **マルチサイトアクティブ/アクティブ** 

    マルチサイトアクティブ/アクティブ戦略の一部として、複数のリージョンでワークロードを同時実行できます。マルチサイトアクティブ/アクティブは、デプロイされたすべてのリージョンからのトラフィックを処理します。DR 以外の理由でこの戦略を選択することもあります。可用性を高めるためや、グローバルオーディエンスにワークロードをデプロイするときに (エンドポイントをエンドユーザーに近づけるためや、そのリージョン内のオーディエンスに対してローカライズされたスタックをデプロイするため) 使用できます。DR 戦略としては、ワークロードがデプロイされている AWS リージョンの 1 つでワークロードをサポートできない場合、そのリージョンは隔離され、残りのリージョンを使用して可用性を維持します。マルチサイトアクティブ/アクティブは、運用が最も複雑な DR 戦略であり、ビジネス要件上、必須の場合のみ選択してください。  
![\[マルチサイトアクティブ/アクティブアーキテクチャを示す図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/images/multi-site-active-active-architecture.png)

    

    この戦略の詳細については、「[AWS のディザスタリカバリ (DR) アーキテクチャ、パート IV: マルチサイトアクティブ/アクティブ](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/)」を参照してください。

    **AWS Elastic Disaster Recovery** 

    ディザスタリカバリのためのパイロットライトまたはウォームスタンバイ戦略を検討している場合、AWS Elastic Disaster Recovery はより優れた代替アプローチを提供できる場合があります。Elastic Disaster Recovery は、ウォームスタンバイと同様の RPO と RTO ターゲットを提供できますが、パイロットライトの低コストアプローチを維持します。Elastic Disaster Recovery は、プライマリリージョンからリカバリリージョンにデータをレプリケートします。継続的なデータ保護を使用して、数秒で測定される RPO と数分で測定できる RTO を実現します。パイロットライト戦略と同様、データのレプリケートに必要となるリソースのみが復旧リージョンにデプロイされるため、コストが抑えられます。Elastic Disaster Recovery では、サービスがフェイルオーバーまたはドリルの一環として開始されたコンピューティングリソースの回復を調整します。  
![\[AWS Elastic Disaster Recovery の動作を説明するアーキテクチャ図。\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/images/drs-architecture.png)

    **データを保護するためのその他のプラクティス** 

    どの戦略でも、データ災害に対する緩和も必要です。連続的なデータレプリケーションは、特定のタイプの災害から保護しますが、戦略に、保存データのバージョニングまたはポイントインタイムリカバリのためのオプションが含まれていない限り、データの破損や破壊からは保護しません。復旧サイトにレプリケートしたデータもバックアップして、レプリカに加えて、ポイントインタイムバックアップを作成する必要があります。

    **単一の AWS リージョン内の複数のアベイラビリティーゾーン (AZ) の使用** 

    単一のリージョン内の複数の AZ を使用する場合、DR 実装は上記の戦略の複数の要素を使用します。まず、図 23 に示されているとおり、複数の AZ を使用して、高可用性 (HA) アーキテクチャを作成する必要があります。このアーキテクチャでは、[Amazon EC2 インスタンス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones)と [Elastic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones) にリソースが複数の AZ にデプロイされ、リクエストがアクティブに処理されるため、マルチサイトアクティブ/アクティブアプローチを使用します。このアーキテクチャはホットスタンバイでもあります。プライマリ [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) インスタンスが停止 (または AZ 自体が停止) すると、スタンバイインスタンスはプライマリに昇格されます。  
![\[図 24: マルチ AZ アーキテクチャを示す図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/images/multi-az-architecture2.png)

    この HA アーキテクチャに加えて、ワークロードの実行に必要なすべてのデータのバックアップを追加する必要があります。これは、[Amazon EBS ボリューム](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html)または [Amazon Redshift クラスター](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html)など、単一のゾーンに制約されるデータの場合に特に重要です。AZ に障害が発生した場合、このデータを別の AZ に復元する必要があります。可能な場合には、追加の保護層として、データバックアップも別の AWS リージョンにコピーしてください。

    単一リージョンに対するあまり一般的でない代替アプローチとして、マルチ AZ DR があります。これはブログ記事「[Amazon Application Recovery Controller を使用して回復力の高いアプリケーションを構築する、パート 1: 単一リージョンスタック](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)」で説明されています。ここでは、戦略は、AZ 間の分離をできるだけ高く維持して、リージョンのように動作させることです。この代替戦略を使用すると、アクティブ/アクティブまたはアクティブ/パッシブアプローチを選ぶことができます。
**注記**  
ワークロードによっては、規制によるデータレジデンシー要件があります。現在 AWS リージョンが 1 つだけの地域のワークロードにこれが該当する場合、マルチリージョンではビジネスニーズに適しません。マルチ AZ 戦略は、ほとんどの災害に対して良好な保護を提供します。

1.  **ワークロードのリソースと、それらの設定がフェイルオーバー前 (正常なオペレーション時) に復旧リージョンでどうなるかを評価します。**

    インフラストラクチャと AWS リソースには、[AWS CloudFormation](https://aws.amazon.com/cloudformation) などのコードとしてインフラストラクチャ、または Hashicorp Terraform などのサードパーティーツールを使用します。複数のアカウントとリージョンに単一の操作でデプロイするには、[AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html) を使用できます。マルチサイトアクティブ/アクティブとホットスタンバイ戦略の場合、復旧リージョンにデプロイされるインフラストラクチャはプライマリリージョンと同じリソースを持ちます。パイロットライトとウォームスタンバイ戦略の場合、デプロイされたインフラストラクチャを本番稼働で使用するには追加のアクションが必要です。CloudFormation [パラメータ](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html)および[条件付きロジック](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html)を使用すると、デプロイされるスタックがアクティブかスタンバイかを[単一のテンプレート](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/)で制御できます。Elastic Disaster Recovery を使用する場合、サービスがアプリケーション設定とコンピューティングリソースの復元をレプリケートおよび調整します。

    すべての DR 戦略では、データソースを AWS リージョン内でバックアップし、それらのバックアップをリカバリリージョンにコピーします。[AWS Backup](https://aws.amazon.com/backup/) は、これらのリソースのバックアップを設定、スケジュール、モニタリングする一元的なビューを提供します。パイロットライト、ウォームスタンバイ、およびマルチサイトアクティブ/アクティブの場合、[Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds) DB インスタンスまたは [Amazon DynamoDB](https://aws.amazon.com/dynamodb) テーブルなど、プライマリリージョンのデータを復旧リージョンのデータリソースにレプリケートする必要があります。したがって、これらのデータリソースはライブであり、復旧リージョンのリクエストに対応できます。

    リージョン間での AWS サービスの運用方法の詳細については、「[AWS のサービスによるマルチリージョンアプリケーションの作成](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)」に関するブログシリーズを参照してください。

1.  **必要なとき (災害発生時) に復旧リージョンをフェイルオーバーに備える方法を決定し、実装します。**

    マルチサイトアクティブ/アクティブの場合、フェイルオーバーとは、リージョンを隔離して、残りのアクティブリージョンに頼ることを意味します。一般に、これらのリージョンはトラフィックを受け入れる準備ができています。パイロットライトとウォームスタンバイ戦略の場合、復旧アクションとして、図 20 の EC2 インスタンスなど、不足しているリソースやその他の不足リソースをデプロイする必要があります。

    上記の戦略のすべてで、データベースの読み取り専用インスタンスを昇格して、プライマリの読み書きインスタンスにしなければならない場合があります。

    バックアップと復元の場合、バックアップからのデータの復元によって、EBS ボリューム、RDS DB インスタンス、DynamoDB テーブルなど、そのデータのリソースを作成します。インフラストラクチャを復元し、コードをデプロイする必要もあります。AWS Backup を使用して、データを復旧リージョンに復元できます。詳細については、「[REL09-BP01 バックアップが必要なすべてのデータを特定してバックアップする、またはソースからデータを再現する](rel_backing_up_data_identified_backups_data.md)」を参照してください。インフラストラクチャを再構築するには、[Amazon Virtual Private Cloud (Amazon VPC)](https://aws.amazon.com/vpc)、サブネット、セキュリティグループに加えて、EC2 インスタンスなどのリソースの作成も必要です。復元プロセスの大部分を自動化できます。詳細については、[このブログ記事](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/)を参照してください。

1.  **必要なとき (災害発生時) にフェイルオーバーするトラフィックを再ルーティングする方法を決定し、実装します。**

    このフェイルオーバー操作は、自動または手動で開始できます。ヘルスチェックまたはアラームに基づくフェイルオーバーの自動開始を使用するときには、不要なフェイルオーバー (誤ったアラーム) によって、使用できないデータやデータ損失などのコストが発生するため、注意が必要です。そのため、多くの場合、手動によるフェイルオーバーの開始が使用されます。この場合でも、フェイルオーバーのステップを自動化できるため、手動開始はボタンを押すようなものです。

    AWS サービスを使用するときに検討すべき、いくつかのトラフィック管理オプションがあります。1 つのオプションは、[Amazon Route 53](https://aws.amazon.com/route53) を使用することです。Amazon Route 53 を使用すると、1 つ以上の AWS リージョンの複数の IP エンドポイントを Route 53 ドメイン名に関連付けることができます。手動で開始されるフェイルオーバーを実装するには、[Amazon Application Recovery Controller](https://aws.amazon.com/application-recovery-controller/) を使用できます。これは、リカバリリージョンにトラフィックを再ルーティングするための高可用性データプレーン API を提供します。フェイルオーバーを実装するときには、「[REL11-BP04 復旧中はコントロールプレーンではなくデータプレーンを利用する](rel_withstand_component_failures_avoid_control_plane.md)」で説明されているように、データプレーン操作を使用し、コントロールプレーンを避けてください。

    これらのオプションの詳細については、「[ディザスタリカバリホワイトペーパー](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#pilot-light)」のセクションを参照してください。

1.  **ワークロードをフェイルバックする方法のプランを設計します。**

    フェイルバックとは、災害イベントの終息後、ワークロード操作をプライマリリージョンに戻すことを言います。インフラストラクチャとコードをプライマリリージョンにプロビジョニングするときには、一般に、最初に使用したのと同じステップに従い、コードとしてのインフラストラクチャとコードデプロイパイプラインに依存します。フェイルバックでの課題は、データストアを復元し、動作中の復旧リージョンとの一貫性を確認することです。

    フェイルオーバー状態では、復旧リージョンのデータベースはライブであり、最新データを保持しています。目的は、復旧リージョンからプライマリリージョンへ再同期して、最新であることを確認することです。

    いくつかの AWS のサービスは、これを自動的に行います。[Amazon DynamoDB グローバルテーブル](https://aws.amazon.com/dynamodb/global-tables/)を使用している場合、プライマリリージョンのテーブルが使用できなくなった場合でも、オンラインに復帰すると、DynamoDB が保留中の書き込みの伝播を再開します。[Amazon Aurora Global Database](https://aws.amazon.com/rds/aurora/global-database/) を使用していて、[管理された計画的なフェイルオーバー](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover) を使用している場合、Aurora Global Database の既存のレプリケーショントポロジは維持されます。そのため、プライマリリージョンの以前の読み書きインスタンスがレプリカになり、復旧リージョンから更新を受け取ります。

    これが自動でない場合、プライマリリージョンで復旧リージョンのデータベースのレプリカとしてデータベースを再確立する必要があります。多くの場合、これには、古いプライマリデータベースを削除して、新しいレプリカを作成する必要があります。

    フェイルオーバー後、復旧リージョンでの実行を続行できる場合は、これを新しいプライマリリージョンにすることを検討してください。その場合でも、上記のすべてのステップを実行して、前のプライマリリージョンを復旧リージョンにします。一部の組織は、計画的ローテーションを実行して、プライマリリージョンと復旧リージョンを定期的に (3 か月ごとなど) 交換しています。

    フェイルオーバーとフェイルバックに必要なすべてのステップをプレイブックに記載して、チームのメンバー全員が使用できるようにし、定期的にレビューする必要があります。

    Elastic Disaster Recovery を使用する場合、サービスはフェイルバックプロセスの調整と自動化のサポートを提供します。詳細については、「[フェイルバックの実行](https://docs.aws.amazon.com/drs/latest/userguide/failback-performing-main.html)」を参照してください。

 **実装計画に必要な工数レベル:** 高 

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

 **関連するベストプラクティス:** 
+ [REL09-BP01 バックアップが必要なすべてのデータを特定してバックアップする、またはソースからデータを再現する](rel_backing_up_data_identified_backups_data.md)
+ [REL11-BP04 復旧中はコントロールプレーンではなくデータプレーンを利用する](rel_withstand_component_failures_avoid_control_plane.md)
+  [REL13-BP01 ダウンタイムやデータ消失に関する復旧目標を定義する](rel_planning_for_recovery_objective_defined_recovery.md) 

 **関連ドキュメント:** 
+  [AWS アーキテクチャブログ: ディザスタリカバリシリーズ](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/) 
+  [AWS でのワークロードの災害対策: クラウド内での復旧 (AWS ホワイトペーパー)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html) 
+  [クラウド内での災害対策オプション](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html) 
+  [Build a serverless multi-region, active-active backend solution in an hour](https://read.acloud.guru/building-a-serverless-multi-region-active-active-backend-36f28bed4ecf) 
+  [Multi-region serverless backend — reloaded](https://medium.com/@adhorn/multi-region-serverless-backend-reloaded-1b887bc615c0) 
+  [別の AWS リージョンでのリードレプリカの作成](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.XRgn) 
+  [Route 53: Configuring DNS Failover](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html) 
+  [S3: クロスリージョンレプリケーション](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) 
+  [ とはAWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) 
+  [Amazon Application Recovery Controller とは](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html) 
+  [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html) 
+  [HashiCorp Terraform: 開始方法 - AWS](https://learn.hashicorp.com/collections/terraform/aws-get-started) 
+  [APN Partner: partners that can help with disaster recovery](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery) 
+  [AWS Marketplace: ディザスタリカバリに活用できる商品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery) 

 **関連動画:** 
+  [Disaster Recovery of Workloads on AWS](https://www.youtube.com/watch?v=cJZw5mrxryA) 
+  [AWS re:Invent 2018: マルチリージョンアクティブ/アクティブアプリケーション用アーキテクチャパターン (ARC209-R2)](https://youtu.be/2e29I3dA8o4) 
+  [Get Started with AWS Elastic Disaster Recovery \$1 Amazon Web Services](https://www.youtube.com/watch?v=GAMUCIJR5as) 

# REL13-BP03 ディザスタリカバリの実装をテストし、実装を検証する
<a name="rel_planning_for_recovery_dr_tested"></a>

復旧サイトへの定期的なテストフェイルオーバーを実施して、適切な動作と、RTO および RPO が満たされることを確認します。

 **一般的なアンチパターン:** 
+  本番環境ではフェイルオーバーを実行しない。

 **このベストプラクティスを活用するメリット:** ディザスタリカバリプランを定期的にテストすることで、必要なときに機能することや、チームが戦略の実行方法を把握していることを確認できます。

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

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

 回避すべきパターンは、まれにしか実行されない復旧経路を作ることです。例えば、読み取り専用のクエリに使用されるセカンダリデータストアがあるとします。データストアの書き込み時にプライマリデータストアで障害が発生した場合、セカンダリデータストアにフェイルオーバーします。もしこのフェイルオーバーを頻繁にテストしない場合、セカンダリデータストアの機能に関する前提が正しくない可能性があります。セカンダリデータストアの容量は、最後にテストしたときには十分だったかもしれませんが、このシナリオでは負荷に耐えられなくなる可能性があります。エラー復旧がうまくいくのは頻繁にテストする経路のみであることは、これまでの経験からも明らかです。少数の復旧経路を用意することがベストであるのはそのためです。復旧パターンを確立して定期的にテストできます。復旧経路が複雑な場合や重大な場合に復旧経路が正常に機能するという確信を持つには、本番環境でその障害を定期的に実行する必要があります。前述の例では、その必要性に関係なく、スタンバイへのフェイルオーバーを定期的に行う必要があります。

 **実装手順** 

1.  ワークロードを復旧用にエンジニアリングします。復旧経路を定期的にテストします。復旧指向コンピューティングは、回復を強化するシステムの以下の特性を特徴としています。隔離と冗長性、システム全体の変更のロールバック機能、正常性を監視し判断する機能、診断する機能、自動的な復旧、モジュラー設計、再起動する機能。復旧経路を訓練して、指定された時間内に指定された状態に復旧できるようにします。この復旧中にランブックを使用して問題を文書化し、次のテストの前に解決策を見つけます。

1. Amazon EC2 ベースのワークロードの場合、[AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html) を使用して DR 戦略のドリルインスタンスを実装および起動します。AWS Elastic Disaster Recovery は、ドリルを効率的に実行する機能を提供して、フェイルオーバーイベントの準備に役立つます。また、Elastic Disaster Recovery を使用すると、トラフィックをリダイレクトせずに、テストおよびドリル目的でインスタンスを頻繁に起動できます。

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

 **関連ドキュメント:** 
+  [APN パートナー: ディザスタリカバリを支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery) 
+  [AWS アーキテクチャブログ: ディザスタリカバリシリーズ](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/) 
+  [AWS Marketplace: ディザスタリカバリに活用できる商品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery) 
+  [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/) 
+  [AWS 上のワークロードのディザスタリカバリ: クラウドにおけるリカバリ (AWS ホワイトペーパー)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html) 
+  [AWS Elastic Disaster Recovery フェイルオーバーの準備](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html) 
+  [バークレー/スタンフォード大学の復旧指向コンピューティングプロジェクト](http://roc.cs.berkeley.edu/) 
+  [AWS Fault Injection Simulator とは](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) 

 **関連動画:** 
+  [AWS re:Invent 2018: マルチリージョンアクティブ/アクティブアプリケーション用アーキテクチャパターン](https://youtu.be/2e29I3dA8o4) 
+  [AWS re:Invent 2019: AWS のバックアップおよび復元、ディザスタリカバリソリューション](https://youtu.be/7gNXfo5HZN8) 

# REL13-BP04 DR サイトまたはリージョンでの設定ドリフトを管理する
<a name="rel_planning_for_recovery_config_drift"></a>

 ディザスタリカバリ (DR) 手順を成功させるには、DR 環境がオンラインになった後、機能やデータに損失を与えることなく、ワークロードがタイムリーに通常の操作を再開できる必要があります。この目標を達成するには、DR 環境とプライマリ環境の間でインフラストラクチャ、データ、設定を一貫して維持することが重要です。

 **期待される成果:** ディザスタリカバリサイトの設定とデータはプライマリサイトと同等であるため、必要に応じて迅速かつ完全な復旧が容易になります。

 **一般的なアンチパターン:** 
+  プライマリロケーションに変更が加えられたときにリカバリロケーションを更新しないため、構成が古くなり、リカバリ作業の妨げになる可能性がある。
+  プライマリロケーションとリカバリロケーション間のサービスの違いなどの潜在的な制限を考慮していないため、フェイルオーバー中に予期しない障害が発生する可能性がある。
+  DR 環境の更新および同期を手動プロセスに依存しているため、ヒューマンエラーや不整合のリスクが高まる。
+  設定のドリフトを検出できないため、インシデントが発生する前に DR サイトの準備状況が誤って認識される。

 **このベストプラクティスを活用するメリット:** DR 環境とプライマリ環境間の整合性により、インシデント後の復旧が成功する可能性が大幅に向上し、復旧手順が失敗するリスクが軽減されます。

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

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

 設定管理とフェイルオーバーの準備に対する包括的なアプローチは、DR サイトが一貫して更新され、プライマリサイトに障害が発生した場合に引き継ぐ準備ができていることを確認するのに役立ちます。

 プライマリ環境とディザスタリカバリ (DR) 環境の一貫性を実現するには、配信パイプラインがプライマリサイトと DR サイトの両方にアプリケーションを分散していることを確認します。適切な評価期間 (*時差デプロイとも呼ばれます*) 後に DR サイトに変更をロールアウトして、プライマリサイトの問題を検出し、問題が広がる前にデプロイを停止します。モニタリングを実装して設定のドリフトを検出し、環境全体の変更とコンプライアンスを追跡します。DR サイトで自動修復を実行し、完全な一貫性を保ち、インシデント発生時に引き継ぐ準備を整えます。

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

1.  DR リージョンに、DR プランを正常に実行するために必要な AWS のサービスと機能が含まれていることを確認します。

1.  Infrastructure as Code (IaC) を使用します。本番環境インフラストラクチャとアプリケーション構成テンプレートを正確に保ち、ディザスタリカバリ​​環境に定期的に適用します。[AWS CloudFormation](https://aws.amazon.com/cloudformation/) は、CloudFormation テンプレートで指定されている内容と実際にデプロイされている内容との間のドリフトを検出できます。

1.  CI/CD パイプラインを設定して、プライマリサイトや DR サイトを含むすべての環境にアプリケーションとインフラストラクチャの更新をデプロイします。[AWS CodePipeline](https://aws.amazon.com/codepipeline/) などの CI/CD ソリューションはデプロイプロセスを自動化できるため、構成ドリフトのリスクを軽減できます。

1.  プライマリ環境と DR 環境間のスタガーデプロイ。このアプローチでは、アップデートをまずプライマリ環境に展開してテストできるため、問題が DR サイトに伝播される前にプライマリサイトの問題を分離できます。このアプローチにより、欠陥が本番稼働サイトと DR サイトに同時にプッシュされるのを防ぎ、DR 環境の整合性を維持できます。

1.  プライマリ環境と DR 環境の両方でリソース設定を継続的にモニタリングします。[AWS Config](https://aws.amazon.com/config/) などのソリューションは、構成のコンプライアンスを強制し、ドリフトを検出するのに役立ち、環境間で一貫した構成を維持するのに役立ちます。

1.  設定ドリフト、データレプリケーションの中断、遅延を追跡して通知するアラートメカニズムを実装します。

1.  検出された設定ドリフトの修復を自動化します。

1.  プライマリ設定と DR 設定の間で継続的な整合性を検証するために、定期的な監査とコンプライアンスチェックをスケジュールします。定期的なレビューは、定義されたルールへのコンプライアンスを維持し、対処する必要がある不一致を特定するのに役立ちます。

1.  AWS プロビジョニングされた容量、Service Quotas、スロットル制限、設定とバージョンの不一致をチェックします。

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

 **関連するベストプラクティス:** 
+  [REL01-BP01 Service Quotas と制約を認識する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_aware_quotas_and_constraints.html) 
+  [REL01-BP02 アカウントおよびリージョンをまたいで Service Quotas を管理する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_limits_considered.html) 
+  [REL01-BP04 クォータをモニタリングおよび管理する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_manage_service_limits_monitor_manage_limits.html) 
+  [REL13-BP03 ディザスタリカバリの実装をテストし、実装を検証する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_dr_tested.html) 

 **関連ドキュメント:** 
+  [ による非準拠 AWS リソースの修復AWS Config ルール](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html) 
+  [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 
+  [AWS CloudFormation: スタックとリソースに対するアンマネージド型構成変更の検出](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html) 
+  [AWS CloudFormation: CloudFormation スタック全体のドリフトを検出する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html) 
+  [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 
+  [AWS 上のワークロードのディザスタリカバリ: クラウドにおけるリカバリ (AWS ホワイトペーパー)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html) 
+  [ でインフラストラクチャ設定管理ソリューションを実装するにはどうすればよいですか?AWS](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/?ref=wellarchitected)
+  [AWS Config ルール による非準拠 AWS リソースの修復](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html) 

 **関連動画:** 
+  [AWS re:Invent 2018: マルチリージョンアクティブ/アクティブアプリケーション用アーキテクチャパターン (ARC209-R2)](https://youtu.be/2e29I3dA8o4) 

 **関連する例:** 
+  [CloudFormation レジストリ](https://aws.amazon.com/blogs/devops/identify-regional-feature-parity-using-the-aws-cloudformation-registry/) 
+  [AWS のクォータモニタ](https://aws.amazon.com/solutions/implementations/quota-monitor/) 
+  [Amazon CloudWatch と AWS Lambda を使用して AWS CloudFormation の自動ドリフト修正を実装する](https://aws.amazon.com/blogs/mt/implement-automatic-drift-remediation-for-aws-cloudformation-using-amazon-cloudwatch-and-aws-lambda/) 
+  [AWS アーキテクチャブログ: ディザスタリカバリシリーズ](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/) 
+  [AWS Marketplace: ディザスタリカバリに活用できる商品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery) 
+  [Automating safe, hands-off deployments](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/) 

# REL13-BP05 復旧を自動化する
<a name="rel_planning_for_recovery_auto_recovery"></a>

 信頼性、オブザーバビリティ、再現性のあるテスト済みの自動復旧メカニズムを実装して、障害のリスクとビジネスへの影響を減らします。

 **期待される成果:** 復旧プロセスのために、十分に文書化され、標準化され、徹底的にテストされた自動化ワークフローを実装しました。リカバリオートメーションは、データ損失や利用不能のリスクが低い軽微な問題を自動的に修正します。重大なインシデントの復旧プロセスを迅速に呼び出し、プロセスの実行中に修復動作を観察し、危険な状況や障害が観察された場合はプロセスを終了できます。

 **一般的なアンチパターン:** 
+  復旧計画の一環として、障害が発生した、または劣化した状態にあるコンポーネントやメカニズムに依存する。
+  復旧プロセスに、コンソールアクセス (*クリックオペレーション*とも呼ばれます) などの手動による介入が必要である。
+  データ損失や利用不能のリスクが高い状況では、復旧手順を自動的に開始する。
+  機能していない、または追加のリスクをもたらす復旧手順 (*Andon コード*や*大きな赤色の停止ボタン*など) を中止するメカニズムを含めることができない。

 **このベストプラクティスを活用するメリット:** 
+  復旧オペレーションの信頼性、予測可能性、一貫性の向上。
+  目標復旧時間 (RTO) や目標復旧時点 (RPO) など、より厳格な復旧目標を達成する能力。
+  インシデント発生時に復旧が失敗する可能性が低くなります。
+  人為的ミスが発生しやすい手動復旧プロセスに関連する障害のリスクを低減します。

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

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

 自動復旧を実装するには、AWS のサービスとベストプラクティスを使用する包括的なアプローチが必要です。まず、ワークロードの重要なコンポーネントと潜在的な障害点を特定します。人間の介入なしにワークロードとデータを障害から復旧できる自動プロセスを開発します。

 Infrastructure as Code (IaC) の原則を使用してリカバリオートメーションを開発します。これで復旧環境をソース環境と一致させ、復旧プロセスをバージョン管理できます。複雑な復旧ワークフローを調整するには、[AWS Systems Manager Automations](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) や [AWS Step Functions](https://aws.amazon.com/step-functions/) などのソリューションを検討してください。

 復旧プロセスの自動化は大きなメリットをもたらし、目標復旧時間 (RTO) と目標復旧時点 (RPO) をより簡単に達成するのに役立ちます。ただし、ダウンタイムの増加やデータ損失など、予期しない状況が発生して障害が発生したり、独自の新しいリスクが発生したりする可能性があります。このリスクを軽減するには、進行中のリカバリオートメーションをすばやく停止する機能を提供します。停止したら、調査して修正のための手段を講じることができます。

 サポートされているワークロードについては、AWS Elastic Disaster Recovery (AWS DRS) などのソリューションを検討して、自動フェイルオーバーを提供します。AWSDRS は、マシン (オペレーティングシステム、システム状態設定、データベース、アプリケーション、ファイルを含む) をターゲット AWS アカウント と優先リージョンのステージング領域に継続的に複製します。インシデントが発生した場合、AWS DRS はレプリケートされたサーバーを AWS のリカバリリージョンで完全にプロビジョニングされたワークロードに変換する処理を自動化します。

 自動復旧のメンテナンスと改善は継続的なプロセスです。学んだ教訓に基づいて復旧手順を継続的にテストおよび改良し、復旧能力を強化できる新しい AWS のサービスや機能について最新情報を入手してください。

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

1.  **自動復旧の計画** 

   1.  ワークロードアーキテクチャ、コンポーネント、依存関係を徹底的に見直し、自動復旧メカニズムを特定して計画します。ワークロードの依存関係を*ハード*依存関係と*ソフト*依存関係に分類します。ハード依存関係とは、ワークロードがそれなしでは動作できず、代替品を提供できない依存関係です。ソフト依存関係は、ワークロードが通常使用しているものですが、一時的な代替システムやプロセスに置き換えたり、[グレースフルデグラデーション](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_graceful_degradation)によって処理できる依存関係です。

   1.  欠落または破損したデータを特定して復旧するプロセスを確立します。

   1.  復旧アクションが完了した後、復旧した定常状態を確認するための手順を定義します。

   1.  キャッシュの事前ウォーミングや入力など、復旧したシステムをフルサービス対応にするために必要なアクションを検討してください。

   1.  復旧プロセス中に発生する可能性のある問題と、それらを検出して修正する方法を検討します。

   1.  プライマリサイトとそのコントロールプレーンにアクセスできないシナリオを検討してください。プライマリサイトに依存することなく、復旧アクションを個別に実行できることを確認します。DNS レコードを手動でミューテーションすることなくトラフィックをリダイレクトするには、[Amazon Application Recovery Controller (ARC)](https://aws.amazon.com/application-recovery-controller/) などのソリューションを検討してください。

1.  **自動復旧プロセスの開発** 

   1.  ハンズフリーリカバリ用の自動障害検出とフェイルオーバーメカニズムを実装します。[Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) などのダッシュボードを構築して、自動復旧手順の進行状況と健全性について報告します。正常な復旧を検証する手順を含めます。処理中の復旧を中止するメカニズムを指定します。

   1.  自動的に復旧できない障害のフォールバックプロセスとして[プレイブック](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_testing_resiliency_playbook_resiliency)を構築し、[ディザスタリカバリプラン](https://aws.amazon.com/disaster-recovery/faqs/#Core_concepts)を考慮します。

   1.  [REL13-BP03](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_dr_tested.html) で説明されているように、復旧プロセスをテストします。

1.  **復旧に備える** 

   1.  復旧サイトの状態を評価し、重要なコンポーネントを事前にデプロイします。詳細については、「[REL13-BP04](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_config_drift.html)」を参照してください。

   1.  組織全体の関連するステークホルダーやチームが関与する復旧作業の明確なロール、責任、意思決定プロセスを定義します。

   1.  復旧プロセスを開始する条件を定義します。

   1.  必要に応じて、または安全と見なされた後に、復旧プロセスを元に戻してプライマリサイトにフォールバックする計画を作成します。

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

 **関連するベストプラクティス:** 
+  [REL07-BP01 リソースの取得またはスケーリング時に自動化を使用する](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_adapt_to_changes_autoscale_adapt.html) 
+  [REL11-BP01 ワークロードのすべてのコンポーネントをモニタリングして障害を検知する](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_withstand_component_failures_monitoring_health.html) 
+  [REL13-BP02 復旧目標を満たすため、定義された復旧戦略を使用する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_disaster_recovery.html) 
+  [REL13-BP03 ディザスタリカバリの実装をテストし、実装を検証する](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_dr_tested.html) 
+  [REL13-BP04 DR サイトまたはリージョンでの設定ドリフトを管理する](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_planning_for_recovery_config_drift.html) 

 **関連ドキュメント:** 
+  [AWS アーキテクチャブログ: ディザスタリカバリシリーズ](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/) 
+  [AWS 上のワークロードのディザスタリカバリ: クラウドにおけるリカバリ (AWS ホワイトペーパー)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html) 
+  [Amazon Route 53 ARC と AWS Step Functions を使用したディザスタリカバリオートメーションのオーケストレーション](https://aws.amazon.com/blogs/networking-and-content-delivery/orchestrate-disaster-recovery-automation-using-amazon-route-53-arc-and-aws-step-functions/) 
+  [AWS CDK を使用して AWS Systems Manager Automation ランブックを構築する](https://aws.amazon.com/blogs/mtbuild-aws-systems-manager-automation-runbooks-using-aws-cdk/) 
+  [AWS Marketplace: ディザスタリカバリに使用できる製品](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery) 
+  [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 
+  [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/) 
+  [Elastic Disaster Recovery の自動フェイルオーバーとフェイルバック](https://docs.aws.amazon.com/drs/latest/userguide/failback.html) 
+  [AWS Elastic Disaster Recovery リソース](https://aws.amazon.com/disaster-recovery/resources/) 
+  [APN パートナー: ディザスタリカバリを支援できるパートナー](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery) 

 **関連動画:** 
+  [AWS re:Invent 2018: マルチリージョンアクティブ/アクティブアプリケーション用アーキテクチャパターン (ARC209-R2)](https://youtu.be/2e29I3dA8o4) 
+  [AWS re:Invent 2022: AWS On Air ft. AWS Elastic Disaster Recovery の AWS フェイルバック](https://youtu.be/Ok-vpV8b1Hs)