今回はDR対策についてです。
■はじめに
AWSの設計原則の一つに「障害ありきの設計」（Design for Failure）と言うものがあります。
マルチAZ構成やマルチリージョン構成が「障害ありきの設計」の実装形態です。
ただし、目標復旧時間（RTO）や目標復旧時点（RPO）の要件により、どのような設計/実装形態にすべきかは変わってきます。
以降では、実装形態別に記載しております。
■実装形態について
AWSにおけるDR構成では、代表的な構成が4つ存在します。
① データのバックアップ＆リストア
② パイロットライト
③ ウォームスタンバイ
④ ホットスタンバイ
詳細は後述致します。
DR発動時のアクション、コスト、RTO、RPOの観点での評価も記載しております。
■① データのバックアップ＆リストア
別リージョンにデータのバックアップを取得しておく構成です。
例えばS3の「クロスリージョンレプリケーション」やAWSBackupの「クロスリージョンバックアップ」が該当します。
DR発動時：
別リージョンにあるデータを利用して復旧作業を行います。
コスト：
低い（データ保存先だけを用意、およびデータ量のみのため）
RTO：
長い（データのみであり、例えばAWSBackupからリストアするのに時間がかかることが多い）
RPO：
データがバックアップされたタイミングまで。
■② パイロットライト
DRサイト（＝DR用のリージョン）を事前に用意しておき、
メインサイトで利用しているスペックよりも低いものをDRサイトで常時稼働させておきます。
例えば、メインサイトのRDSのデータをDRサイト側のRDSにレプリケーションだけしておきます。
DR発動時：
DRサイト側でAPサーバを構築し、DRサイトに元々存在するRDSと連携させます。
※場合によってはDNSの切り替えも実施
コスト：
比較的低い（データ保存先として低スペックのRDSを用意するのみ）
RTO：
長い（APサーバ等を構築する時間がかかる。）
RPO：
最終データのレプリケーションタイミング（＝同期タイミング）まで。
■③ ウォームスタンバイ
パイロットライトの派生形です。
DRサイト（＝DR用のリージョン）にメインサイトと同構成を低スペックで事前に用意しておきます。
パイロットライトの場合にはRDSのみを用意してましたが、
ウォームスタンバイではWEB/APサーバも用意しておきます。
DR発動時：
WEB/APサーバが低スペックのままでは処理できない場合には、スケールアップを行います。
コスト：
比較的多い（低スペックとはいえ、WEB/APサーバやRDSを用意しているため。）
RTO：
比較的短い（低スペックとはいえ、構成自体は整っているため。）
RPO：
最終データのレプリケーションタイミング（＝同期タイミング）まで。
■④ ホットスタンバイ
DRサイト（＝DR用のリージョン）にメインサイトと同構成同スペックのものを事前に用意しておきます。
ウォームスタンバイでは低スペックのものを用意していましたが、ウォームスタンバイでは高スペック（メインサイトと同等）のものを用意しておきます。
DR発動時：
DNS名前解決先の変更のみを実施
コスト：
多い（メインサイトと全く同じものをDRサイトに作るため）
RTO：
短い（基本的にはDNS切り替えのみのため）
RPO：
最終データのレプリケーションタイミング（＝同期タイミング）まで。
以上です。
