翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# クラウド内での災害対策オプション
AWS 内で利用できるディザスタリカバリ戦略は、低コストと複雑さの低いバックアップから、複数のアクティブなリージョンを使用したより複雑な戦略まで、4 つのアプローチに広く分類できます。アクティブ/パッシブ戦略では、アクティブなサイト (AWS リージョンなど) を使用してワークロードをホストし、トラフィックを処理します。パッシブサイト (別の AWS リージョンなど) が復旧に使用されます。パッシブサイトは、フェイルオーバーイベントがトリガーされるまでトラフィックをアクティブに処理しません。
ディザスタリカバリ戦略を定期的に評価してテストし、必要に応じて確実に呼び出すことが重要です。[AWS Resilience Hub](https://aws.amazon.com/resilience-hub/) を使用して、RTO と RPO の目標を達成する可能性が高いかどうかなど、 AWS ワークロードの耐障害性を継続的に検証および追跡します。
![\[ディザスタリカバリ戦略と各戦略のハイライトを示すグラフ。\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/disaster-recovery-workloads-on-aws/images/disaster-recovery-strategies.png)
*図 6 - ディザスタリカバリ戦略 *
[適切に設計され](https://aws.amazon.com/architecture/well-architected/)、可用性の高いワークロードのための 1 つの物理データセンターの中断または損失に基づく災害イベントの場合、ディザスタリカバリへのバックアップと復元のアプローチのみが必要になる場合があります。災害の定義が、物理的なデータセンターの中断や損失を超えてリージョンの定義である場合、またはそれを必要とする規制要件の対象である場合は、パイロットライト、ウォームスタンバイ、またはマルチサイトアクティブ/アクティブを検討する必要があります。
戦略とそれを実装する AWS リソースを選択するときは、AWS 内では通常、サービスを*データプレーン*と*コントロールプレーン*に分割することに注意してください。コントロールプレーンで環境を設定しつつ、データプレーンではリアルタイムのサービスを提供します。回復性を最大化するには、フェイルオーバーオペレーションの一部としてデータプレーンオペレーションのみを使用する必要があります。これは、データプレーンには通常、コントロールプレーンよりも高い可用性の設計目標があるためです。
## バックアップと復元
バックアップと復元は、データの損失や破損を軽減するための適切なアプローチです。このアプローチは、データを他の AWS リージョンにレプリケートすることでリージョンの災害を軽減したり、単一のアベイラビリティーゾーンにデプロイされたワークロードの冗長性の欠如を軽減したりするためにも使用できます。データに加えて、復旧リージョンにインフラストラクチャ、設定、アプリケーションコードを再デプロイする必要があります。エラーなしでインフラストラクチャを迅速に再デプロイできるようにするには、 [AWS CloudFormation](https://aws.amazon.com/cloudformation)や などのサービスを使用して、Infrastructure as Code (IaC) を使用して常にデプロイする必要があります[AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk)。IaC を使用しない場合、復旧リージョンでワークロードを復元するのが複雑になり、復旧時間が長くなり、RTO を超える可能性があります。ユーザーデータに加えて、Amazon EC2 インスタンスの作成に使用する [Amazon マシンイメージ (AMIs)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) を含むコードと設定も必ずバックアップしてください。を使用して[AWS CodePipeline](https://aws.amazon.com/codepipeline)、アプリケーションコードと設定の再デプロイを自動化できます。
![\[バックアップと復元のアーキテクチャを示すアーキテクチャ図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/disaster-recovery-workloads-on-aws/images/backup-restore-architecture.png)
*図 7 - バックアップと復元のアーキテクチャ *
### AWS サービス
ワークロードデータには、定期的に実行されるバックアップ戦略または継続的なバックアップ戦略が必要です。バックアップを実行する頻度によって、達成可能な復旧ポイントが決まります (RPO に合わせて調整する必要があります）。バックアップは、バックアップが作成された時点に復元する方法も提供する必要があります。point-in-timeリカバリによるバックアップは、以下のサービスとリソースを通じて利用できます。
+ [Amazon Elastic Block Store (Amazon EBS) スナップショット](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html)
+ [Amazon DynamoDB バックアップ](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.html)
+ [Amazon RDS スナップショット](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_CommonTasks.BackupRestore.html)
+ [Amazon Aurora DB スナップショット](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_CreateSnapshotCluster.html)
+ [Amazon EFS バックアップ](https://docs.aws.amazon.com/efs/latest/ug/awsbackup.html) (使用時 AWS Backup）
+ [Amazon Redshift スナップショット](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-snapshots.html)
+ [Amazon Neptune スナップショット](https://docs.aws.amazon.com/neptune/latest/userguide/backup-restore-overview.html)
+ [ Amazon DocumentDB](https://docs.aws.amazon.com/documentdb/latest/developerguide/backup_restore.html)
+ [ Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html)、[Amazon FSx for Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/using-backups-fsx.html)、[Amazon FSx for NetApp ONTAP](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/using-backups.html)、[Amazon FSx for OpenZFS ](https://docs.aws.amazon.com/fsx/latest/OpenZFSGuide/using-backups.html)
Amazon Simple Storage Service (Amazon S3) では、[Amazon S3 クロスリージョンレプリケーション (CRR)](https://aws.amazon.com/s3/features/replication/) を使用して、保存されたオブジェクトのバージョニングを提供しながら、DR リージョンの S3 バケットにオブジェクトを継続的に非同期的にコピーし、復元ポイントを選択できます。データの継続的なレプリケーションには、データのバックアップにかかる最短時間 (ゼロに近い時間) という利点がありますが、データの破損や悪意のある攻撃 (不正なデータ削除など) などの災害イベントやpoint-in-timeバックアップから保護できない場合があります。継続的レプリケーションについては、「AWS [Services for Pilot Light](#aws-services-1)」セクションを参照してください。
[AWS Backup](https://aws.amazon.com/backup) は、以下のサービスとリソースの AWS バックアップ機能を設定、スケジュール、モニタリングするための一元的な場所を提供します。
+ [Amazon Elastic Block Store (Amazon EBS) ボリューム](https://aws.amazon.com/ebs/)
+ [Amazon EC2 インスタンス](https://aws.amazon.com/ec2/)
+ [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds/) データベース ([Amazon Aurora](https://aws.amazon.com/rds/aurora/) データベースを含む）
+ [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) テーブル
+ [Amazon Elastic File System (Amazon EFS)](https://aws.amazon.com/efs/) ファイルシステム
+ [AWS Storage Gateway](https://aws.amazon.com/storagegateway/) ボリューム
+ [Amazon FSx for Windows File Server](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html)、[Amazon FSx for Lustre](https://docs.aws.amazon.com/fsx/latest/LustreGuide/using-backups-fsx.html)、[Amazon FSx for NetApp ONTAP](https://docs.aws.amazon.com/fsx/latest/ONTAPGuide/using-backups.html)、[Amazon FSx for OpenZFS](https://docs.aws.amazon.com/fsx/latest/OpenZFSGuide/aws-backup-and-fsx.html)
AWS Backup は、ディザスタリカバリリージョンなど、リージョン間でのバックアップのコピーをサポートしています。
Amazon S3 データの追加のディザスタリカバリ戦略として、[S3 オブジェクトのバージョニング](https://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html)を有効にします。オブジェクトバージョニングは、アクションの前に元のバージョンを保持することで、削除または変更アクションの結果から S3 内のデータを保護します。オブジェクトのバージョニングは、ヒューマンエラータイプの災害の軽減に役立ちます。S3 レプリケーションを使用して DR リージョンにデータをバックアップしている場合、デフォルトでは、レプリケート元バケットでオブジェクトが削除されると、[Amazon S3 はレプリケート元バケットにのみ削除マーカーを追加します](https://docs.aws.amazon.com/AmazonS3/latest/dev/delete-marker-replication.html)。このアプローチは、DR リージョン内のデータをソースリージョン内の悪意のある削除から保護します。
データに加えて、ワークロードを再デプロイし、目標復旧時間 (RTO) を満たすために必要な設定とインフラストラクチャもバックアップする必要があります。 [AWS CloudFormation](https://aws.amazon.com/cloudformation)は、Infrastructure as Code (IaC) を提供し、ワークロード内のすべての AWS リソースを定義して、複数の AWS アカウントと AWS リージョンに確実にデプロイおよび再デプロイできるようにします。ワークロードで使用される Amazon EC2 インスタンスを Amazon マシンイメージ (AMIsとしてバックアップできます。AMI は、インスタンスのルートボリュームと、インスタンスにアタッチされたその他の EBS ボリュームのスナップショットから作成されます。この AMI を使用して、EC2 インスタンスの復元されたバージョンを起動できます。[AMI は、リージョン内またはリージョン間でコピーできます](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/CopyingAMIs.html)。または、 [AWS Backup](https://aws.amazon.com/backup) を使用して、アカウント間および他の AWS リージョンにバックアップをコピーすることもできます。クロスアカウントバックアップ機能は、インサイダーの脅威やアカウントの侵害を含む災害イベントからの保護に役立ちます。 AWS Backup また、 は、インスタンスの個々の EBS ボリュームに加えて、EC2 バックアップ用の機能を追加し、インスタンスタイプ、設定された仮想プライベートクラウド (VPC)、セキュリティグループ、[IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)、モニタリング設定、タグなどのメタデータ AWS Backup も保存および追跡します。ただし、この追加メタデータは、EC2 バックアップを同じ AWS リージョンに復元する場合にのみ使用されます。
バックアップとしてディザスタリカバリリージョンに保存されているデータは、フェイルオーバー時に復元する必要があります。 は復元機能 AWS Backup を提供しますが、現在、スケジュールされた復元または自動復元は有効にしていません。AWS SDK を使用して APIs を呼び出すことで、DR リージョンへの自動復元を実装できます AWS Backup。これは定期的に繰り返されるジョブとして設定することも、バックアップが完了するたびに復元をトリガーすることもできます。次の図は、[Amazon Simple Notification Service (Amazon SNS) ](https://aws.amazon.com/sns/)と を使用した自動復元の例を示しています[AWS Lambda](https://aws.amazon.com/lambda/)。バックアップからのデータ復元はコントロールプレーンオペレーションであるため、スケジュールされた定期的なデータ復元を実装することをお勧めします。災害発生時にこのオペレーションが利用できなかった場合でも、最近のバックアップから運用可能なデータストアが作成されます。
![\[バックアップの復元とテストのワークフローを示す図。\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/disaster-recovery-workloads-on-aws/images/restore-test-backups.png)
*図 8 - バックアップの復元とテスト *
**注記**
バックアップ戦略にはバックアップのテストが含まれていなければなりません。詳細については、[「ディザスタリカバリのテスト](testing-disaster-recovery.md)」セクションを参照してください。実装の実践的なデモンストレーションについては、[AWS Well-Architected Lab: Testing Backup and Restore of Data](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) を参照してください。
## パイロットライト
*パイロットライト*アプローチでは、あるリージョンから別のリージョンにデータをレプリケートし、コアワークロードインフラストラクチャのコピーをプロビジョニングします。データベースやオブジェクトストレージなど、データのレプリケーションとバックアップのサポートに必要なリソースは、常にオンです。アプリケーションサーバーなどの他の要素にはアプリケーションコードと設定がロードされますが、「スイッチオフ」され、テスト中またはディザスタリカバリフェイルオーバーが呼び出されたときにのみ使用されます。クラウドでは、不要なリソースを柔軟にプロビジョニング解除し、必要なときにプロビジョニングできます。「スイッチオフ」のベストプラクティスは、リソースをデプロイせず、必要に応じてデプロイする設定と機能 (「スイッチオン」) を作成することです。バックアップと復元のアプローチとは異なり、コアインフラストラクチャは常に利用可能であり、アプリケーションサーバーをオンにしてスケールアウトすることで、フルスケールの本番稼働環境を迅速にプロビジョニングできます。
![\[パイロットライトアーキテクチャのリファレンスアーキテクチャ図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/disaster-recovery-workloads-on-aws/images/pilot-light-architecture.png)
*図 9 - パイロットライトアーキテクチャ*
パイロットライトアプローチは、アクティブなリソースを最小限に抑えることでディザスタリカバリの継続的なコストを最小限に抑え、コアインフラストラクチャ要件がすべて整っているため、ディザスタ時の復旧を簡素化します。この復旧オプションでは、デプロイアプローチを変更する必要があります。コアインフラストラクチャの変更を各リージョンに行い、ワークロード (設定、コード) の変更を各リージョンに同時にデプロイする必要があります。このステップは、デプロイを自動化し、Infrastructure as Code (IaC) を使用して複数のアカウントとリージョンにインフラストラクチャをデプロイすることで簡素化できます (プライマリリージョンへのフルインフラストラクチャデプロイと、DR リージョンへのスケールダウン/スイッチオフインフラストラクチャデプロイ）。リージョンごとに異なるアカウントを使用して、最高レベルのリソースとセキュリティの分離を提供することをお勧めします (侵害された認証情報がディザスタリカバリプランの一部である場合も同様）。
このアプローチでは、データ災害も軽減する必要があります。連続的なデータレプリケーションは、特定のタイプの災害から保護しますが、戦略に、保存データのバージョニングまたはポイントインタイムリカバリのためのオプションが含まれていない限り、データの破損や破壊からは保護しません。ディザスタリージョンでレプリケートされたデータをバックアップして、同じリージョンにpoint-in-timeバックアップを作成できます。
### AWS サービス
Backup [and Restore](#backup-and-restore) セクションで説明されている AWS のサービスを使用してpoint-in-timeバックアップを作成することに加えて、パイロットライト戦略では次のサービスも検討してください。
パイロットライトの場合、DR リージョンのライブデータベースとデータストアへの継続的なデータレプリケーションは、低 RPO の最善のアプローチです (前述のpoint-in-timeバックアップに加えて使用する場合）。AWS は、以下のサービスとリソースを使用して、データの継続的、クロスリージョン、非同期データレプリケーションを提供します。
+ [Amazon Simple Storage Service (Amazon S3) レプリケーション](https://aws.amazon.com/s3/features/replication/)
+ [Amazon RDS リードレプリカ](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.XRgn.Cnsdr)
+ [Amazon Aurora グローバルデータベース](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html)
+ [Amazon DynamoDB グローバルテーブル](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
+ [Amazon DocumentDB グローバルクラスター](https://docs.aws.amazon.com/documentdb/latest/developerguide/global-clusters.html)
+ [Amazon ElastiCache のグローバルデータストア (Redis OSS)](https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/Redis-Global-Datastore.html)
継続的レプリケーションでは、データのバージョンは DR リージョンでほぼすぐに使用できます。実際のレプリケーション時間は、[S3 オブジェクトの S3 Replication Time Control (S3 RTC)](https://docs.aws.amazon.com/AmazonS3/latest/dev/replication-time-control.html) や [Amazon Aurora グローバルデータベースの管理機能などのサービス機能](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-managing.html)を使用してモニタリングできます。 S3
ディザスタリカバリリージョンから読み取り/書き込みワークロードの実行にフェイルオーバーする場合は、RDS リードレプリカをプライマリインスタンスに昇格させる必要があります。[Aurora 以外の DB インスタンスの場合、プロセス](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.Promote)が完了するまでに数分かかり、再起動はプロセスの一部です。RDS によるクロスリージョンレプリケーション (CRR) とフェイルオーバーの場合、[Amazon Aurora グローバルデータベース](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html)を使用すると、いくつかの利点があります。グローバルデータベースは、専用インフラストラクチャを使用してデータベースをアプリケーションに完全に提供し、一般的なレイテンシーが 1 秒未満 (AWS リージョン内は 100 ミリ秒未満) でセカンダリリージョンにレプリケートできます。Amazon Aurora グローバルデータベースでは、プライマリリージョンでパフォーマンスの低下や機能停止が発生した場合、いずれかのセカンダリリージョンを昇格させて、リージョンが完全に機能停止した場合でも 1 分以内に読み取り/書き込みの責任を引き受けることができます。すべてのセカンダリクラスターの RPO ラグタイムをモニタリングするように Aurora を設定して、少なくとも 1 つのセカンダリクラスターがターゲット RPO ウィンドウ内にとどまるようにすることもできます。
DR リージョンにデプロイする必要があるリソースが少ないか小さいコアワークロードインフラストラクチャのスケールダウンバージョン。を使用すると AWS CloudFormation、インフラストラクチャを定義し、AWS アカウント間および AWS リージョン間で一貫してデプロイできます。 は事前定義された[擬似パラメータ](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/pseudo-parameter-reference.html) AWS CloudFormation を使用して、デプロイ先の AWS アカウントと AWS リージョンを識別します。したがって、[CloudFormation テンプレートに条件ロジック](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/conditions-section-structure.html)を実装して、スケールダウンされたバージョンのインフラストラクチャのみを DR リージョンにデプロイできます。EC2 インスタンスのデプロイの場合、Amazon マシンイメージ (AMI) はハードウェア設定やインストール済みソフトウェアなどの情報を提供します。必要な AMIs を作成し、プライマリリージョンとバックアップリージョンの両方にコピーする [Image Builder](https://docs.aws.amazon.com/imagebuilder/latest/userguide/what-is-image-builder.html) パイプラインを実装できます。これにより、これらの*ゴールデン AMIs *に、災害が発生した場合にワークロードを新しいリージョンに再デプロイまたはスケールアウトするために必要なものがすべて揃うようになります。Amazon EC2 インスタンスは、スケールダウンされた設定でデプロイされます (プライマリリージョンよりも少ないインスタンス）。本番トラフィックをサポートするようにインフラストラクチャをスケールアウトするには、[「ウォームスタンバイ](#warm-standby)」セクションの[Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling)」を参照してください。
パイロットライトなどのアクティブ/パッシブ設定の場合、すべてのトラフィックは最初にプライマリリージョンに送信され、プライマリリージョンが使用できなくなった場合はディザスタリカバリリージョンに切り替わります。このフェイルオーバー操作は、自動または手動で開始できます。ヘルスチェックまたはアラームに基づいて自動的に開始されるフェイルオーバーは、慎重に使用する必要があります。ここで説明したベストプラクティスを使用しても、復旧時間と復旧ポイントは 0 より大きくなり、可用性とデータの損失が発生します。不要な場合にフェイルオーバーした場合 (誤ったアラーム）、これらの損失が発生します。そのため、多くの場合、手動によるフェイルオーバーの開始が使用されます。この場合でも、フェイルオーバーのステップを自動化できるため、手動開始はボタンを押すようなものです。
AWS サービスを使用する際に考慮すべきトラフィック管理オプションがいくつかあります。
1 つのオプションは、[Amazon Route 53](https://aws.amazon.com/route53) を使用することです。Amazon Route 53 を使用すると、1 つ以上の AWS リージョンの複数の IP エンドポイントを Route 53 ドメイン名に関連付けることができます。次に、そのドメイン名で適切なエンドポイントにトラフィックをルーティングできます。フェイルオーバー時に、トラフィックを復旧エンドポイントに切り替え、プライマリエンドポイントから遠ざける必要があります。Amazon Route 53 ヘルスチェックは、これらのエンドポイントをモニタリングします。これらのヘルスチェックを使用すると、自動的に開始される DNS フェイルオーバーを設定して、トラフィックが正常なエンドポイントにのみ送信されるようにできます。これは、データプレーンで実行される信頼性の高いオペレーションです。手動で開始されたフェイルオーバーを使用してこれを実装するには、[Amazon Application Recovery Controller (ARC)](https://aws.amazon.com/route53/application-recovery-controller/) を使用できます。ARC では、Route 53 ヘルスチェックを作成できます。実際にはヘルスチェックは行われませんが、完全に制御できるオン/オフスイッチとして機能します。AWS CLI または AWS SDK を使用すると、この高可用性のデータプレーン API を使用してフェイルオーバーをスクリプト化できます。スクリプトは、プライマリリージョンではなく復旧リージョンにトラフィックを送信するように Route 53 に指示するこれらのスイッチ (Route 53 ヘルスチェック) を切り替えます。一部の が使用した手動で開始されたフェイルオーバーのもう 1 つのオプションは、加重ルーティングポリシーを使用し、プライマリリージョンとリカバリリージョンの重みを変更して、すべてのトラフィックがリカバリリージョンに転送されるようにすることです。ただし、これはコントロールプレーンオペレーションであるため、Amazon Application Recovery Controller (ARC) を使用したデータプレーンアプローチほどの回復力がないことに注意してください。
もう 1 つのオプションは、 を使用することです[AWS Global Accelerator](https://aws.amazon.com/global-accelerator/)。AnyCast IP を使用すると、1 つ以上の AWS リージョンの複数のエンドポイントを同じ静的パブリック IP アドレスに関連付けることができます。 AWS Global Accelerator その後、 はそのアドレスに関連付けられた適切なエンドポイントにトラフィックをルーティングします。[Global Accelerator ヘルスチェック](https://docs.aws.amazon.com/global-accelerator/latest/dg/about-endpoint-groups-health-check-options.html)はエンドポイントをモニタリングします。これらのヘルスチェックを使用して、 はアプリケーションの状態 AWS Global Accelerator をチェックし、ユーザートラフィックを正常なアプリケーションエンドポイントに自動的にルーティングします。手動で開始されたフェイルオーバーでは、トラフィックダイヤルを使用してトラフィックを受信するエンドポイントを調整できますが、これはコントロールプレーンオペレーションであることに注意してください。Global Accelerator は、広範な AWS エッジネットワークを使用してトラフィックをできるだけ早く AWS ネットワークバックボーンに配置するため、アプリケーションエンドポイントへのレイテンシーが低くなります。Global Accelerator は、DNS システム (Route 53 など) で発生する可能性のあるキャッシュの問題も回避します。
[Amazon CloudFront](https://aws.amazon.com/cloudfront/) はオリジンフェイルオーバーを提供します。プライマリエンドポイントへの特定のリクエストが失敗した場合、CloudFront はリクエストをセカンダリエンドポイントにルーティングします。前述のフェイルオーバーオペレーションとは異なり、後続のすべてのリクエストは引き続きプライマリエンドポイントに送信され、フェイルオーバーはリクエストごとに行われます。
### AWS Elastic Disaster Recovery
[AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/) (DRS) は、基盤となるサーバーのブロックレベルのレプリケーション AWS を使用して、サーバーがホストするアプリケーションとサーバーがホストするデータベースを任意のソースから に継続的にレプリケートします。Elastic Disaster Recovery を使用すると、 のリージョンを、オンプレミスまたは別のクラウドプロバイダーでホストされているワークロードとその環境のディザスタリカバリターゲット AWS クラウド として使用できます。EC2 で AWS ホストされているアプリケーションとデータベース (RDS ではない) のみで構成される場合、ホストされたワークロードのディザスタリカバリにも使用できます。Elastic Disaster Recovery は、パイロットライト戦略を使用して、ステージングエリアとして使用される [Amazon Virtual Private Cloud (Amazon VPC)](https://aws.amazon.com/vpc/) 内のデータのコピーと「スイッチオフ」リソースを維持します。フェイルオーバーイベントがトリガーされると、ステージングされたリソースを使用して、復旧場所として使用されるターゲット Amazon VPC にフルキャパシティデプロイが自動的に作成されます。
![\[Elastic Disaster Recovery AWS アーキテクチャを示すアーキテクチャ図。\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/disaster-recovery-workloads-on-aws/images/disaster-recovery-architecture.png)
*図 10 - AWS Elastic Disaster Recovery アーキテクチャ*
## ウォームスタンバイ
ウォームスタンバイアプローチでは、本番稼働環境の完全に機能する縮小コピーを別のリージョンに用意します。このアプローチは、パイロットライトの概念を拡張して、ワークロードが別のリージョンに常駐するため、復旧時間が短縮されます。このアプローチにより、テストをより簡単に実行したり、継続的なテストを実装したりして、災害から回復する能力の信頼性を高めることもできます。
![\[ウォームスタンバイアーキテクチャを示すアーキテクチャ図。\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/disaster-recovery-workloads-on-aws/images/warm-standby-architecture.png)
*図 11 - ウォームスタンバイアーキテクチャ *
**注：** [パイロットライト](#pilot-light)と[ウォームスタンバイ](#warm-standby)の違いを理解するのは難しい場合があります。どちらも、プライマリリージョンアセットのコピーを含む環境を DR リージョンに含めます。違いは、パイロットライトは追加のアクションを最初に実行しない限りリクエストを処理できないのに対し、ウォームスタンバイはトラフィックを (キャパシティーレベルを減らして) すぐに処理できることです。パイロットライトアプローチでは、サーバーを「オン」し、場合によっては追加の (非コア) インフラストラクチャをデプロイしてスケールアップする必要がありますが、ウォームスタンバイではスケールアップのみが必要です (すべてが既にデプロイされ、実行されています）。RTO と RPO のニーズを使用して、これらのアプローチから選択できます。
### AWS サービス
[バックアップ、復元](#backup-and-restore)、[パイロットライト](#pilot-light)の対象となるすべての AWS サービスは、データバックアップ、データレプリケーション、アクティブ/パッシブトラフィックルーティング、EC2 インスタンスを含むインフラストラクチャのデプロイのためにウォームスタンバイでも使用されます。
[Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) は、AWS リージョン内の Amazon EC2 インスタンス、Amazon ECS タスク、Amazon DynamoDB スループット、Amazon Aurora レプリカなどのリソースをスケールするために使用されます。[Amazon EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) は、AWS リージョン内のアベイラビリティーゾーン間で EC2 インスタンスのデプロイをスケーリングし、そのリージョン内の回復性を提供します。Auto Scaling を使用して、パイロットライトまたはウォームスタンバイ戦略の一環として、DR リージョンをフルプロダクション機能にスケールアウトします。たとえば、EC2 の場合は、Auto Scaling グループの*希望する容量*設定を増やします。この設定は、 を使用して手動で調整することも AWS マネジメントコンソール、AWS SDK を使用して自動的に調整することも、新しい希望する容量値を使用して AWS CloudFormation テンプレートを再デプロイすることもできます。 AWS CloudFormation パラメータを使用すると、CloudFormation テンプレートの再デプロイが簡単になります。DR リージョン[のサービスクォータ](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)が、本番環境の容量へのスケーリングを制限しないように十分に高く設定されていることを確認します。
Auto Scaling はコントロールプレーンのアクティビティであるため、それに依存すると、全体的な復旧戦略の耐障害性が低下します。これはトレードオフです。リカバリリージョンがデプロイされた本番稼働負荷全体を処理できるように、十分な容量をプロビジョニングすることを選択できます。この静的に安定した設定は、*ホットスタンバイ*と呼ばれます (次のセクションを参照）。または、プロビジョニングするリソースを減らしてコストを抑えることもできますが、Auto Scaling に依存します。一部の DR 実装では、初期トラフィックを処理するのに十分なリソースをデプロイし、低 RTO を確保してから、Auto Scaling を使用して後続のトラフィックを増やします。
## マルチサイトアクティブ/アクティブ
*マルチサイトアクティブ/アクティブ*または*ホットスタンバイアクティブ/パッシブ*戦略の一環として、複数のリージョンでワークロードを同時に実行できます。マルチサイトアクティブ/アクティブは、デプロイ先のすべてのリージョンからのトラフィックを処理しますが、ホットスタンバイは 1 つのリージョンからのトラフィックのみを処理し、他のリージョン (複数可) はディザスタリカバリにのみ使用されます。マルチサイトアクティブ/アクティブアプローチを使用すると、ユーザーはデプロイされている任意のリージョンでワークロードにアクセスできます。このアプローチはディザスタリカバリに対する最も複雑でコストのかかるアプローチですが、正しいテクノロジーの選択と実装により、ほとんどのディザスタの復旧時間をほぼゼロに短縮できます (ただし、データの破損はバックアップに依存する必要があり、通常はゼロ以外の復旧ポイントになる可能性があります）。ホットスタンバイは、ユーザーが単一のリージョンにのみ誘導され、DR リージョンがトラフィックを受け取らないアクティブ/パッシブ設定を使用します。ほとんどのお客様は、2 番目のリージョンで完全な環境を立ち上げる場合は、アクティブ/アクティブを使用するのが理にかなっています。または、両方のリージョンを使用してユーザートラフィックを処理したくない場合、ウォームスタンバイはより経済的で運用上それほど複雑ではないアプローチを提供します。
![\[マルチサイトアクティブ/アクティブアーキテクチャを示すアーキテクチャ図 (ホットスタンバイ用に 1 つのアクティブパスを非アクティブに変更）\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/disaster-recovery-workloads-on-aws/images/multi-site-active-active-architecture.png)
*図 12 - マルチサイトアクティブ/アクティブアーキテクチャ (ホットスタンバイの場合は 1 つのアクティブパスを非アクティブに変更) *
マルチサイトがアクティブ/アクティブの場合、ワークロードが複数のリージョンで実行されているため、このシナリオではフェイルオーバーのようなものはありません。この場合のディザスタリカバリテストでは、ワークロードがリージョンの損失にどのように反応するかに焦点を当てます。トラフィックは障害が発生したリージョンからルーティングされますか？ 他のリージョン (複数可) はすべてのトラフィックを処理できますか？ データ災害のテストも必要です。バックアップと復旧は依然として必要であり、定期的にテストする必要があります。また、データの破損、削除、難読化を伴うデータ災害の復旧時間は常に 0 より大きく、復旧ポイントは常に災害が発見される前のいずれかの時点になることに注意してください。マルチサイトアクティブ/アクティブ (またはホットスタンバイ) アプローチの複雑さとコストがほぼゼロの復旧時間を維持するために必要になった場合は、セキュリティを維持し、人為的災害を軽減するための人為的ミスを防ぐために、追加の努力を行う必要があります。
### AWS サービス
[バックアップと復元](#backup-and-restore)、[パイロットライト](#pilot-light)、[ウォームスタンバイ](#warm-standby)の対象となるすべての AWS サービスは、ここではpoint-in-timeデータバックアップ、データレプリケーション、アクティブ/アクティブトラフィックルーティング、EC2 インスタンスを含むインフラストラクチャのデプロイとスケーリングにも使用されます。
前述のアクティブ/パッシブシナリオ (パイロットライトとウォームスタンバイ) AWS Global Accelerator では、Amazon Route 53 と の両方をアクティブなリージョンへのネットワークトラフィックのルーティングに使用できます。ここでのアクティブ/アクティブ戦略では、どちらのサービスも、どのユーザーがどのアクティブなリージョンエンドポイントに移動するかを決定するポリシーの定義を有効にします。 AWS Global Accelerator では、各アプリケーションエンドポイントに転送される[トラフィックの割合を制御するようにトラフィックダイヤル](https://docs.aws.amazon.com/global-accelerator/latest/dg/about-endpoint-groups-traffic-dial.html)を設定します。Amazon Route 53 はこのパーセンテージアプローチと、地理的近接性やレイテンシーベースのポリシーなど、[利用可能な他の複数のポリシー](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)をサポートしています。[Global Accelerator は、AWS エッジサーバーの広範なネットワークを自動的に活用](https://docs.aws.amazon.com/global-accelerator/latest/dg/introduction-ip-ranges.html)して、トラフィックをできるだけ早く AWS ネットワークバックボーンにオンボードするため、リクエストのレイテンシーが低くなります。
この戦略による非同期データレプリケーションにより、ほぼゼロの RPO が可能になります。[Amazon Aurora グローバルデータベース](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html)などの AWS サービスは、専用インフラストラクチャを使用して、データベースをアプリケーションに完全に提供し、1 秒未満の一般的なレイテンシーで最大 5 つのセカンダリリージョンにレプリケートできます。アクティブ/パッシブ戦略では、書き込みはプライマリリージョンに対してのみ行われます。アクティブ/アクティブとの違いは、アクティブな各リージョンへの書き込みとのデータ整合性の処理方法を設計することです。読み取りローカルと呼ばれる*、ユーザーに最も近いリージョンから提供されるユーザー読み取り*を設計するのが一般的です。書き込みには、いくつかのオプションがあります。
+ *書き込みグローバル*戦略は、すべての書き込みを 1 つのリージョンにルーティングします。そのリージョンに障害が発生した場合、別のリージョンが書き込みを受け入れるように昇格されます。[Aurora グローバルデータベース](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html)は、リージョン間でリードレプリカとの同期をサポートしているため、*書き込みグローバル*に適しています。また、いずれかのセカンダリリージョンを昇格させて、読み取り/書き込みの責任を 1 分以内に引き受けることができます。Aurora は書き込み転送もサポートしています。これにより、Aurora グローバルデータベースのセカンダリクラスターは、書き込みオペレーションを実行する SQL ステートメントをプライマリクラスターに転送できます。
+ *書き込みローカル*戦略は、書き込みを最も近いリージョン (読み取りと同様) にルーティングします。[Amazon DynamoDB グローバルテーブル](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/globaltables.V2.html)では、このような戦略が可能になり、グローバルテーブルがデプロイされるすべてのリージョンからの読み取りと書き込みが可能になります。Amazon DynamoDB グローバルテーブルでは、*最後のライターが同時更新間の調整を獲得します*。
+ *書き込みパーティション戦略*は、書き込みの競合を避けるために、パーティションキー (ユーザー ID など) に基づいて特定のリージョンに書き込みを割り当てます。この場合、[双方向に設定された](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/) Amazon S3 レプリケーションを使用できます。現在、 は 2 つのリージョン間のレプリケーションをサポートしています。このアプローチを実装するときは、バケット A と B の両方で[レプリカ変更同期](https://docs.aws.amazon.com/AmazonS3/latest/dev/replication-for-metadata-changes.html)を有効にして、レプリケートされたオブジェクトのオブジェクトアクセスコントロールリスト (ACLs)、オブジェクトタグ、オブジェクトロックなどのレプリカメタデータの変更をレプリケートするようにしてください。アクティブなリージョンのバケット間で[削除マーカーをレプリケー](https://docs.aws.amazon.com/AmazonS3/latest/dev/delete-marker-replication.html)トするかどうかを設定することもできます。レプリケーションに加えて、データの破損や破壊イベントから保護するためのpoint-in-timeバックアップも戦略に含める必要があります。
AWS CloudFormation は、複数の AWS リージョンの AWS アカウント間で一貫してデプロイされたインフラストラクチャを強制する強力なツールです。[AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html) は、単一のオペレーションで複数のアカウントとリージョンにまたがる CloudFormation スタックを作成、更新、または削除できるようにすることで、この機能を拡張します。 AWS CloudFormation は YAML または JSON を使用して Infrastructure as Code を定義しますが、 [AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/) では使い慣れたプログラミング言語を使用して Infrastructure as Code を定義できます。コードは CloudFormation に変換され、AWS にリソースをデプロイするために使用されます。