翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# ディザスタリカバリ計画
ディザスタリカバリ (DR) は、企業のビジネス継続性とコンプライアンスにとって重要なサービスです。AMS はお客様と連携して、AMS での DR 戦略の計画、実装、維持を支援します。
AMS ランディングゾーン (LZ) は、マルチアカウントおよびシングルアカウントであり、ほとんどの災害対策シナリオを満たす AMS インフラストラクチャコンポーネントにネイティブ、マルチ AZ、高可用性を提供します。ただし、ビジネスの地理的カバレッジによっては、リージョンの保護が必要になる場合があります。クロスリージョンの可用性と DR には、別のリージョンで別の AMS アカウントが必要です (これは、マルチアカウントランディングゾーンとシングルアカウントランディングゾーンの両方に必要です）。
AMS は、このブログ[「Rapidly recover mission-critical systems in a disaster](https://aws.amazon.com/blogs/publicsector/rapidly-recover-mission-critical-systems-in-a-disaster/)」で説明されている AWS DR ガイダンスに準拠しており、次の 4 つのオプションをサポートしています。
+ マルチサイト (または高可用性）
+ ウォームスタンバイ
+ パイロットライト
+ バックアップと復元
これらのオプションと AMS サポートについては、以下のセクションで説明します。
## マルチサイトまたは高可用性 (HA)
HA ソリューションは通常、クラスタリングや同期レプリケーションなど、アプリケーションの組み込み機能によって提供されます。ユーザーは Prod ノードと HA/DR ノードの両方に移動します。DNS はノードを直接、または Elastic Load Balancer (ELB) を介してポイントします。
AMS クラウドアーキテクト (CA) は、Well-Architected-Review および DR 計画の一環として連携します。
HA DR AWSは、次の図に示すように、アプリケーションおよびネイティブのサービスと機能を使用します。
![\[DNS and CloudFront connecting users to production and HA/DR instances with data replication.\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/userguide/images/dr-ha.png)
DR サイトは、同じ でも異なる でもかまいません AWS リージョン。
**注記**
異なるリージョン (クロスリージョン) には、異なる Active Directory 環境があります。
**DR (フェイルオーバー) ステップ**: 自動フェイルオーバー。手動ステップは必要ありません。プライマリ LZ で障害が発生した場合、ユーザーは自動的に DR/HA ノードに再ルーティングされます。これは、DNS とアプリケーション設定の両方で実現されます。
HA DR メトリクス：
+ 目標復旧時点 (RPO): <5 分
+ 目標復旧時間と (RTO): <5 分
+ メンテナンス: 高 (アプリケーション設定、パッチ適用、SG または ALB、証明書など、両方の環境で同期変更が必要です）。
+ コスト: 高
## ウォームスタンバイ
「ウォームスタンバイ」という用語は、スケールダウンされたバージョンの環境がクラウドで実行されているディザスタリカバリ (DR) シナリオを説明するために使用されます。
データレプリケーションはアプリケーションレイヤーによって通常非同期的にオンラインインスタンスに処理されますが、残りのインスタンス (アプリケーション層やウェブ層など) はコストを節約するためにオフになる場合があります。ユーザーは本番稼働用サイトにのみ誘導されます。Elastic Load Balancer (ELB) などの他の AWS リソースも DR サイトで事前プロビジョニングされる場合があります。
AMS クラウドアーキテクト (CA) は、 Well-Architected-Review および DR 計画の一環として連携します。
ウォームスタンバイ DR AWSは、次の図に示すように、アプリケーションおよびネイティブのサービスと機能を使用します。
![\[Diagram showing DNS, ELB, production and DR site subnets with data replication and config updates.\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/userguide/images/dr-warm-standby.png)
DR サイトは、同じ でも異なる でもかまいません AWS リージョン。
**注記**
異なるリージョン (クロスリージョン) には、異なる Active Directory 環境があります。
**DR (フェイルオーバー) ステップ**：
1. データレプリケーションを中断し、DR サイトのデータインスタンスをマスターにする
1. 必要に応じてアプリケーション設定を更新する (新しい IP、サーバー名など）
1. DNS を DR サイト (ELB) にリダイレクトする
1. 必要に応じて AD の依存関係 (サービスアカウント、SPNs、GPOs など）
HA DR メトリクス：
+ 目標復旧時点 (RPO): <1hr
+ 目標復旧時間と (RTO): <1 時間 (インスタンス数とオーケストレーションによって異なります）
+ メンテナンス: 高 (アプリケーション設定、パッチ適用、セキュリティグループ (SG)、アプリケーションロードバランサー (ALB)、証明書など、両方の環境で同期変更が必要です）。
+ コスト: 中
## パイロットライト
このディザスタリカバリ (DR) アプローチでは、限られたコアサービスのセットに対して Prod 環境の一部をレプリケートします。インフラストラクチャのごく一部が常に実行されており、同時に変更可能なデータ (データベースやドキュメントなど) を同期します。一方、インフラストラクチャの他の部分はオフになり、テスト中のみ使用されます。バックアップとリカバリのアプローチとは異なり、最も重要なコア要素が DR ランディングゾーン (パイロットライト) で既に設定され、実行されていることを確認する必要があります。
AMS クラウドアーキテクトは、 Well-Architected-Review および DR 計画の一環としてお客様と協力して作業します。
パイロットライト DR は、次の図に示すように、アプリケーションおよび AWSネイティブのサービスと機能を使用します。
![\[Diagram showing DNS, production and DR site subnets with ELBs, instances, and data replication.\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/userguide/images/dr-pilot-light.png)
DR サイトは、同じ でも異なる でもかまいません AWS リージョン。
**注記**
異なるリージョン (クロスリージョン) には、異なる Active Directory 環境があります。
**DR (フェイルオーバー) ステップ**：
1. データレプリケーションを中断し、DR サイトのデータインスタンスをマスターにする
1. オフになっているインスタンスとインフラストラクチャを起動する
1. 必要に応じてアプリケーション設定を更新する (新しい IP、サーバー名など）
1. 必要に応じてインスタンスを ELB に追加する
1. DNS を DR サイト (ELB) にリダイレクトする
1. 必要に応じて AD の依存関係 (サービスアカウント、SPNs、GPOs など）
パイロットライト DR メトリクス：
+ 目標復旧時点 (RPO): <1hr
+ 目標復旧時間と (RTO): \$11 時間 (インスタンス数とオーケストレーションによって異なります）
+ メンテナンス: 中
+ コスト: 中
## バックアップと復元
このシンプルで低コストのディザスタリカバリ (DR) アプローチは、災害からの復旧時に使用するために、データとアプリケーションをどこからでも DR ランディングゾーンにバックアップします。
AMS Cloud Architect は、バックアップと DR の計画の一環としてユーザーと連携します。
バックアップと復元 DR は、次の図に示すように、AMS 自動ツールとプロセスを使用します。
![\[AMS 自動ツールを使用したバックアップと復元のプロセス。\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/userguide/images/dr-backup-and-restore.png)
次の 2 つのバックアップ方法とレプリケーション方法を使用できます。
+ EBS スナップショット (目標復旧時点 (RPO) > 1hr)、「EBS」と呼ばれる
+ AWS Elastic Disaster Recovery （目標復旧時点 (RPO) \$1 0.25 時間）、「DRS」と呼ばれます。
DR サイトは、同じ または別の にあることができます AWS リージョン。
**注記**
別のリージョン (クロスリージョン) には、別の Active Directory 環境があります。
**DR (フェイルオーバー) ステップ**：
1. スナップショットからインスタンスを復元する (プレースホルダーインスタンスを最初に使用して 2 ステップのプロセス）
1. アプリケーション設定を更新する (新しい IP、サーバー名など）
1. 必要に応じて他のインフラストラクチャを設定する (SG、ELB など）
1. DNS を DR サイト (ELB) にリダイレクトする
1. 必要に応じて AD の依存関係を更新または復元する (サービスアカウント、サービスプリンシパル名 (SPNs)、グループポリシーオブジェクト (GPOs) など）
DR メトリクスのバックアップと復元：
+ 目標復旧時点 (RPO): >1 時間または \$10.25 時間 (選択したソリューションによって異なります - EBS または DRE)
+ 目標復旧時間と (RTO): \$11 時間 (インスタンス数とオーケストレーションによって異なります）
+ メンテナンス: 高 (アプリケーション設定、パッチ適用、セキュリティグループまたはアプリケーションロードバランサー、証明書など、両方の環境で同期変更が必要です。
+ コスト: 中
### AMS での EBS スナップショットを使用した EC2 のディザスタ保護
前提条件:
+ AMS Prod Landing Zone (ソース）
+ AMS DR ランディングゾーン (DR ターゲット）
+ EC2 インスタンスで EBS スナップショットが有効になっている (AWS Backup）
スナップショットレプリケーションソリューション：
+ **クロス AZ**: 該当なし - EBS スナップショットは、 リージョン内で設計上高可用性です
+ **クロスリージョン**： AWS Backup
次の図は、AMS の EBS スナップショットからの EC2 復元プロセスを示しています。
![\[Diagram showing EC2 restore process from EBS snapshots, with production and DR site subnets.\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/userguide/images/dr-ebs-snapshots.png)
**AMS での EC2 DR ステップ**：
1. RFC をレイズして、EBS スナップショットをターゲットアカウントと共有します (クロスリージョン DR に必要）。
: 管理、アドバンストスタックコンポーネント、EBS スナップショット、共有
1. 送信先サブネット (DR サイトサブネット) にプレースホルダー EC2 AMS スタックを作成します。お客様がセキュリティグループと他の (ELB へのインスタンスの追加など) を割り当てるステップを同じスタックに組み合わせることができるため、CFN 取り込みを使用してスタックを作成することをお勧めします。
変更タイプ: CloudFormation テンプレートからのデプロイ、取り込み、スタック、作成
1. RFC をレイズして EC2 スタックボリュームの復元を実行します。
変更タイプ: 管理、アドバンストスタックコンポーネント、EC2 インスタンススタック、ボリュームの復元。
CT は、ステップ 1 で共有されたスナップショットからボリュームを復元し、ステップ 2 で作成されたプレースホルダーインスタンスにアタッチします。
ボリューム復元 CT 機能：
+ プレースホルダーインスタンスをシャットダウンする
+ スナップショットからボリュームを復元する
+ ボリュームをスワップアウトする
+ インスタンスを起動する
+ 古いドメインを残す
+ ホスト名の変更
+ 再起動します。AMS ブートストラップスクリプトは、起動時にインスタンスをターゲット (DR) ドメインに結合します。
ボリューム復元 CT 入力：
+ InstanceId (プレースホルダーインスタンス ID)
+ RootDeviceSnapshotId、復元されたルートボリュームの EBS スナップショット
+ EC2 インスタンスで復元されたすべてのボリュームを暗号化するための KMSKeyId、KMS キー識別子、または ARN
+ DeviceNames、最大 25 (オプション）
+ SnapshotIds、最大 25 (オプション）。復元するボリュームのスナップショットのリスト
### AMS での Elastic Disaster Recovery による EC2 のディザスタ保護
前提条件:
+ AMS Prod Landing Zone (ソース）
+ AMS DR ランディングゾーン (DR ターゲット）
+ まず、使用する予定のすべての の Elastic Disaster Recovery AWS リージョン サービスを初期化する必要があります。
Elastic Disaster Recovery コンソールにアクセスするための IAM ロールを DR ランディングゾーン (LZ) に作成します。
+ 重要: SSM ドキュメントは DRS 内で起動後アクションとして作成されます。このアクションは、PostLaunch 設定のすべてのサーバーで有効にする必要があります。
+ 送信先 (プレースホルダー) インスタンスには、タグキーAWSDRS」、値:AllowLaunchingIntoThisInstance」が必要です。プレースホルダーインスタンスは停止状態である必要があります。それ以外の場合、AMS は起動設定でプレースホルダーインスタンスを選択できず、Elastic Disaster Recovery はプレースホルダーインスタンスの上に復元できません。
AMS での EC2 の Elastic Disaster Recovery のセットアップと復元プロセスの図については、 [AWS Elastic Disaster Recovery （AWS DRS) の一般的なアーキテクチャ](https://docs.aws.amazon.com/drs/latest/userguide/Network-diagrams.html)を参照してください。
**AMS での Elastic Disaster Recovery を使用した EC2 DR ステップ**：
1. 適切なタグを使用して、送信先サブネット (DR サイトサブネット) にプレースホルダー EC2 AMS スタックを作成します。詳細については、前のセクションを参照してください。セキュリティグループの割り当てと、同じスタック内のインスタンス、EBS ボリューム、およびその他の (ELB へのインスタンスの追加など) タグ付けのステップを組み合わせることができるため、CFN 取り込みを使用してスタックを作成することをお勧めします。
変更タイプ: CloudFormation テンプレートからのデプロイ、取り込み、スタック、作成
1. プレースホルダーインスタンスを停止します。
変更タイプ: 管理、高度なスタックコンポーネント、EC2 インスタンス、停止
1. ステップ 1 で完了していない場合は、プレースホルダーインスタンスとその EBS ボリュームにキーAWSDRS」、値:AllowLaunchingIntoThisInstance」をタグ付けします。
変更タイプ: 管理、高度なスタックコンポーネント、タグ、更新。
1. ステップ 1 のプレースホルダーインスタンスを、**Launch into instance ID**, **DRS Launch Settings** for the source server のターゲットとして使用します。ソースサーバーの Elastic Disaster Recovery コンソールからインスタンス復旧ドリルを開始します。
**注記**
プレースホルダーインスタンスボリュームはアカウントに保持されます。これらのボリュームを削除するには、ディザスタリカバリオペレーションの最後に Management \$1 Advanced stack components \$1 EBS Volume \$1 Delete change type (ct-3e3h8u0sp5z80) を送信します。
Elastic Disaster Recovery の復元ワークフロー：
+ ターゲット (プレースホルダー) インスタンスは停止状態である必要があります
+ ボリュームをスワップアウトし、ソース (プレースホルダー) ルートボリュームを削除する
+ インスタンスを起動する
+ 起動後アクションを実行して、次の項目を完了します。
+ SSM エージェントをアクティブ化します。
+ ボリュームをスワップアウトし、ソース (プレースホルダー) ルートボリュームを削除します。
+ インスタンスを起動する
+ PostLaunchScript SSM ドキュメントを実行します。このドキュメントでは、次の操作を行います。
1. 古いドメインを離れます。
1. ホスト名を変更します。
1. 再起動します。AMS ブートストラップスクリプトは、起動時にインスタンスをターゲット (DR) ドメインに結合します。