AWS認定資格 WEB問題集＆徹底解説
会員登録/ログイン

DevOpsエンジニア-プロフェッショナル

正解 B,E問題

分野3：回復性の高いクラウドソリューションタスクステートメント3.3：RTO・RPO 要件を満たす自動復旧プロセスの実装タスクステートメント3.1：回復性とビジネス要件を満たす高可用性ソリューションの実装

1 2 3 4

次の問題

問題文と選択肢

ある製薬会社は、解析装置が出力する測定データの共有領域として、東京リージョンの 1 つのアベイラビリティーゾーンに Amazon FSx for NetApp ONTAP のファイルシステムを配置しています。保護策は AWS Backup でバックアップを取得し、大阪リージョンの保管庫にコピーを保持しているだけです。

先日の復旧訓練では、大阪リージョンのコピーからファイルシステムを作り直して解析業務を再開するまでに数時間を要し、業務部門が定めた 1 時間という目標を大きく超えることが判明しました。あわせて、現在の配置ではファイルシステムが置かれた 1 つのアベイラビリティーゾーンが失われるだけで共有領域が使えなくなる点も指摘されています。

インフラ担当者を増員できないため、平常時に人手の作業が発生しない形で構成を見直す必要があります。取るべき対応を 2 つ選んでください。（2つ選択）

現在の配置を維持したまま AWS Backup の取得間隔を短くし、継続的バックアップを有効にして大阪リージョンの保管庫により細かい復旧ポイントを保持する。
大阪リージョンにも Amazon FSx for NetApp ONTAP のファイルシステムを用意し、東京側のボリュームとの間に NetApp SnapMirror の関係を定義してスケジュールに沿って差分を転送させる。切り替えが必要になった時点で転送先のボリュームを書き込み可能な状態にして公開する。
AWS Elastic Disaster Recovery でファイル共有を担うサーバーとそのデータを大阪リージョンへ継続的に複製し、障害時は大阪で Amazon EC2 インスタンスとして起動する。
東京リージョンの別のアベイラビリティーゾーンにもう 1 つファイルシステムを作成し、AWS DataSync のタスクを 15 分ごとに実行して両者の内容をそろえておく。
ファイルシステムを 2 つのアベイラビリティーゾーンにまたがる配置で作成し直し、書き込みが稼働系と待機系の両方のファイルサーバーに反映されてから完了する状態にしたうえで、片方のアベイラビリティーゾーンが失われても同じエンドポイントのまま利用を継続できるようにする。

解説頻出度★★★★★

この問題は、「単一 AZ 障害でも共有領域を止めない × 遠隔地から 1 時間以内に復旧 × 平常時は人手の作業ゼロ」の要件で、マルチ AZ 配置による同期複製と、リージョン間の SnapMirror によるレプリケーションという 2 段構えを選べるかがポイント

A. 現在の配置を維持したまま AWS Backup の取得間隔を短くし、継続的バックアップを有効にして大阪リージョンの保管庫により細かい復旧ポイントを保持する。

バックアップの取得間隔を短くするとRPO（失われるデータ量）は改善しますが、RTO（復旧までの時間）は改善しません。復旧はバックアップからファイルシステムを新規に作成する作業になるため、訓練で判明した「数時間」という所要時間はそのまま残ります。
さらに、ファイルシステムは単一アベイラビリティーゾーンに置かれたままなので、1 つの AZ が失われれば共有領域が使えなくなるという指摘も解消されません。
2 つの課題のどちらにも答えていない選択肢です。

正解

B. 大阪リージョンにも Amazon FSx for NetApp ONTAP のファイルシステムを用意し、東京側のボリュームとの間に NetApp SnapMirror の関係を定義してスケジュールに沿って差分を転送させる。切り替えが必要になった時点で転送先のボリュームを書き込み可能な状態にして公開する。

正解。NetApp SnapMirror は ONTAP のボリュームレプリケーション機能で、東京側のボリュームから大阪側のファイルシステムへスケジュールに沿って差分だけを転送します。平常時は自動で回り続けるため、人手の作業は発生しません。
転送先には常に最新に近いデータが存在するので、切り替え時はミラー関係を解除して転送先ボリュームを書き込み可能にするだけで業務を再開でき、バックアップから作り直す場合と比べて復旧時間を大幅に短縮できます。
1 時間という目標を満たすリージョン間の保護策として、FSx for NetApp ONTAP における定番の構成です。

C. AWS Elastic Disaster Recovery でファイル共有を担うサーバーとそのデータを大阪リージョンへ継続的に複製し、障害時は大阪で Amazon EC2 インスタンスとして起動する。

AWS Elastic Disaster Recovery は、EC2 インスタンスやオンプレミスのサーバーにエージェントを導入してブロックレベルで複製するサービスです。マネージドサービスである FSx for NetApp ONTAP のファイルシステムにエージェントを入れることはできず、そのままでは複製対象にできません。
採用するにはファイル共有を自前の EC2 サーバーで作り直すことになり、マネージドサービスを捨てて運用対象を増やす方向の変更になります。増員できないという前提に逆行します。
また東京側の単一 AZ 配置は変わらないため、AZ 障害への指摘も解消されません。

D. 東京リージョンの別のアベイラビリティーゾーンにもう 1 つファイルシステムを作成し、AWS DataSync のタスクを 15 分ごとに実行して両者の内容をそろえておく。

AWS DataSync による 15 分間隔のコピーは、あくまで別々の 2 つのファイルシステムの内容をそろえるだけで、片方が失われたときにクライアントが自動的にもう片方へ引き継がれるわけではありません。切り替えのたびにマウント先の変更という人手の作業が必要になります。
加えて転送中の差分は失われますし、コピー先も同じ東京リージョン内にあるため、リージョン規模の障害と 1 時間の復旧目標には何も寄与しません。
「定期的にそろえる」構成は、同期複製による自動フェイルオーバーの代替にはなりません。

正解

E. ファイルシステムを 2 つのアベイラビリティーゾーンにまたがる配置で作成し直し、書き込みが稼働系と待機系の両方のファイルサーバーに反映されてから完了する状態にしたうえで、片方のアベイラビリティーゾーンが失われても同じエンドポイントのまま利用を継続できるようにする。

正解。FSx for NetApp ONTAP のマルチ AZ 配置では、稼働系と待機系のファイルサーバーが別々のアベイラビリティーゾーンに置かれ、書き込みは両系に反映されてから完了する（同期複製）ため、AZ 障害時にもデータが失われません。
フェイルオーバーは自動で行われ、クライアントは同じエンドポイントのまま利用を継続できるので、切り替え作業も再マウントも不要です。
既存のファイルシステムを単一 AZ からマルチ AZ へ変換することはできないため、選択肢のとおりマルチ AZ 構成で作成し直してデータを移行するのが正しい手順になります。

構成図

［東京リージョン］
  AZ-a 稼働系ファイルサーバー ──同期複製──▶ AZ-c 待機系ファイルサーバー
    （同じエンドポイントのまま自動フェイルオーバー）
      │
      │ SnapMirror（スケジュール差分転送）
      ▼
［大阪リージョン］FSx for NetApp ONTAP 転送先ボリューム
      （切り替え時に書き込み可能化して公開）

これだけ覚える（記憶フック）
AZ 障害はマルチ AZ 配置、リージョン障害は SnapMirror。バックアップからの復元は RTO 数時間で間に合わない。

正解への思考ルート

問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。

要件	判断ポイント
1 つのアベイラビリティーゾーンが失われると共有領域が使えなくなる	単一 AZ 配置のままでは解決しない。マルチ AZ 配置（稼働系と待機系への同期書き込み＋自動フェイルオーバー）で冗長化する →選択肢（E）が正解、選択肢（A）を消す
遠隔地からの復旧に数時間かかり、目標の 1 時間を超えている	バックアップからの復元はファイルシステムを作り直す作業で時間がかかる。あらかじめ転送先を用意して待機させる方式に変える →選択肢（B）が正解、選択肢（A）を消す
平常時に人手の作業を発生させない（増員できない）	スケジュール実行の差分転送は無人で回る。エージェント導入や自前サーバーの運用は逆に手間が増える →選択肢（C）を消す
対象はマネージドサービスである FSx for NetApp ONTAP のファイルシステム	Elastic Disaster Recovery はエージェントを入れたサーバーを複製する仕組みで、マネージドなファイルシステムは対象外 →選択肢（C）を消す
障害時に同じエンドポイントで業務を続けられるか	定期コピーは切り替え時にマウント先の変更が必要で、同期複製＋自動フェイルオーバーの代わりにならない →選択肢（D）を消す

ひっかけポイント

選択肢 A の「バックアップ間隔を短くする」は改善に見えるが、効くのは RPO であって RTO ではない。本問が超過しているのは復旧「時間」の目標であり、間隔を詰めても復元作業そのものは短くならない
「AZ 障害対策」と「リージョン障害からの短時間復旧」は別々の課題。1 つの手で両方を満たそうとすると、どちらかが未解決のまま残る。2 つ選ぶ設問の意図はこの分離にある
選択肢 D の DataSync はファイル単位の定期コピーであり、同期複製ではない。15 分間隔という短さに惑わされず、「切り替え時に誰が何をするのか」を問い直すと人手の作業が残ることが見える
単一 AZ のファイルシステムを後からマルチ AZ に変換することはできない。選択肢が「作成し直す」と書いているのは正しい手順であり、「作り直し＝乱暴な案」と読んで消してしまわないこと

出題バリエーション

同じ知識が本番では条件を変えて出題されます。

問題文がこう変わったら	正解はこう変わる
「復旧目標が 24 時間でよく、コストを最優先したい」	AWS Backup のリージョン間コピーからの復元で十分となり、SnapMirror は過剰になる。
「ランサムウェアや誤削除から特定時点のファイルを戻したい」	ONTAP のスナップショットと SnapLock、AWS Backup のバックアップからの復元が正解軸に。
「Linux サーバー群から使う共有ファイルストレージで、AZ 障害に備えたい」	Amazon EFS（複数 AZ に自動冗長化）が正解軸に。ONTAP 固有の機能は不要になる。
「オンプレミスの NetApp ストレージから AWS へ移行したい」	SnapMirror によるクラウドへの複製や AWS DataSync が正解軸に（用途が DR ではなく移行になる）。
「複製先のデータを平常時から読み取り用途で活用したい」	SnapMirror の転送先ボリュームを読み取り専用で参照する構成や FlexClone の利用が論点になる。

AWS認定資格 WEB問題集＆徹底解説
会員登録/ログイン

A. 現在の配置を維持したまま AWS Backup の取得間隔を短くし、継続的バックアップを有効にして大阪リージョンの保管庫により細かい復旧ポイントを保持する。

C. AWS Elastic Disaster Recovery でファイル共有を担うサーバーとそのデータを大阪リージョンへ継続的に複製し、障害時は大阪で Amazon EC2 インスタンスとして起動する。

D. 東京リージョンの別のアベイラビリティーゾーンにもう 1 つファイルシステムを作成し、AWS DataSync のタスクを 15 分ごとに実行して両者の内容をそろえておく。

構成図

次の問題

会員機能

お役立ち情報

姉妹サイト

アンケート

サイト情報