SAP新しいソリューションのための設計
ある製造業の企業は、受発注を管理する基幹アプリケーションをオンプレミスのデータセンターで運用しており、AWSをディザスタリカバリ（DR）サイトとして利用する計画です。アプリケーションはLinux上のカスタムソフトウェアと自社構築のリレーショナルデータベースで構成され、リファクタリングは許可されていません。事業部門はRTOを30分以内、RPOを数秒〜数分と定めていますが、DRサイトを常時フル稼働させるコストは避けたいと考えています。平常時のDR環境コストを最小化しつつ、災害発生時には本番と同等の容量へ迅速に切り替えられる構成はどれですか。
AオンプレミスのデータベースのみをAmazon RDSのリードレプリカとしてAWSで常時稼働させ、アプリケーション層は停止状態のAMIとして保持し、災害時にCloudFormationでスケールアウトして起動する構成にする
自社構築のリレーショナルデータベースはAmazon RDSのマネージドリードレプリカに変換できず、アプリ層をAMIから起動・スケールする時間もかかるため、RPO数秒とRTO30分の要件を同時には満たせない。
BAWS Elastic Disaster Recovery（DRS）を導入し、ブロックレベルの継続的レプリケーションで低コストのステージングエリアにデータを複製し、災害時に本番容量のインスタンスとして起動する
✓ 正解
ブロックレベルの継続レプリケーションでRPOは秒単位、DR先は低コストのステージングエリアのみ稼働するため平常時コストを抑えつつ、フェイルオーバー時に本番容量で起動でき、書き換え不要でRTO30分も満たす。
CAWS Backupで日次バックアップを取得してDRリージョンへクロスリージョンコピーし、災害時に最新のリカバリポイントからインスタンスとボリュームを復元して本番トラフィックへ切り替える
AWS Backupの日次バックアップとクロスリージョンコピーはリカバリポイント間隔が長くRPOが数時間規模となり、復元にも時間を要するため、RPO数秒・RTO30分の要件を満たせない。
D本番と同一構成を縮小サイズでDRリージョンに常時稼働させるウォームスタンバイを構築し、災害時にAuto Scalingで本番容量までスケールアップしてRoute 53で切り替える
縮小構成とはいえ本番同一スタックをDRリージョンで常時稼働させるため平常時コストが高く、コストを最小化したいという制約に反する。RTO自体は満たせるがコスト要件で不適。
解説
AWS Elastic Disaster Recovery（DRS）はエージェントによるブロックレベルの継続的レプリケーションを行い、DR先では小さなステージングインスタンスのみを稼働させるため平常時コストが低く抑えられます。
継続レプリケーションによりRPOは秒単位、フェイルオーバー時は本番容量のインスタンスを短時間で起動できRTO30分以内を満たします。カスタムソフトのため書き換え不要で、OS/DBを問わず物理・仮想サーバをそのまま保護できます。
選択肢Aのパイロットライトは、自社構築DBをRDSリードレプリカ化できず、アプリ層の起動・スケールに時間がかかりRTO・RPO要件を満たしにくい。
選択肢CのAWS Backupは日次リカバリポイントのためRPOが数時間規模となり要件を満たせない。
選択肢DのウォームスタンバイはRTOは満たすが縮小構成を常時稼働させるため平常時コストが高く、コスト最小化の要件に反する。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSAPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →