SAA-038
東京リージョンで稼働するWebアプリケーションについて、リージョン規模の障害が発生した際に大阪リージョンの待機環境へ自動的に切り替えたいです。利用者が使うドメイン名は変えられません。最も適した構成はどれですか？
選択肢
解説と正解
解説と正解を読む（先に自分で回答してから開くのがおすすめです）
正解：C. Route 53のフェイルオーバールーティングポリシーで東京をプライマリ、大阪をセカンダリとし、プライマリのレコードにヘルスチェックを関連付ける
解説
同じドメイン名を維持したままリージョン間で自動切り替えを行うには、Route 53のフェイルオーバールーティングポリシーとヘルスチェックを組み合わせます。プライマリのヘルスチェックが失敗すると、DNS応答が自動的にセカンダリのエンドポイントへ切り替わります。
選択肢ごとの解説
A. Auto Scalingグループを東京と大阪にまたがって作成し、東京側が異常になったら大阪でインスタンスを起動する
Auto Scalingグループは単一リージョン内の複数アベイラビリティーゾーンにまたがることはできますが、リージョンをまたぐことはできません。
B. Route 53の加重ルーティングで東京に重み100、大阪に重み0を設定し、障害を検知したら重みを手動で入れ替える
加重ルーティング自体は有効な機能ですが、重みの変更が手動である以上「自動的に切り替える」という要件を満たしません。障害検知から切り替えまでの時間も人の対応速度に依存します。
C. Route 53のフェイルオーバールーティングポリシーで東京をプライマリ、大阪をセカンダリとし、プライマリのレコードにヘルスチェックを関連付ける
正解です。ヘルスチェックの失敗回数と間隔で切り替え速度を調整でき、DNSレコードのTTLを短めにしておくことで反映も早くなります。
D. Application Load Balancerのターゲットグループに東京と大阪の両方のEC2インスタンスを登録し、ヘルスチェックで振り分ける
Application Load Balancer自体が東京リージョン内のリソースであるため、東京リージョン規模の障害ではALBごと利用できなくなり、リージョン間の切り替えにはなりません。IPアドレスタイプのターゲットグループとリージョン間VPCピアリングを使えば別リージョンのインスタンスをターゲット登録すること自体は可能ですが（インスタンスIDタイプのターゲットはロードバランサーと同じVPC内に限られます）、ALBが単一リージョンに依存する点は変わりません。
実務での使いどころ
Amazon Route 53 のルーティングポリシーは用途ごとに分かれている。シンプルルーティングは単一の宛先を返すだけ、加重ルーティングは指定した比率でトラフィックを分配（カナリアリリースや段階移行に利用）、レイテンシーベースルーティングはクライアントから見て最も遅延の小さいリージョンを返す、位置情報ルーティングは送信元の地理に応じて返す、そしてフェイルオーバールーティングはプライマリ / セカンダリの 2 系統を定義し、プライマリが異常なときだけセカンダリを返す。アクティブ / パッシブなディザスタリカバリ構成にはフェイルオーバールーティングが対応する。 自動切り替えの鍵は Route 53 ヘルスチェックである。ヘルスチェックは世界各地のチェッカーから対象のエンドポイント（IP またはドメイン名）へ定期的にリクエストを送り、既定では 30 秒間隔（高速なら 10 秒間隔）で失敗回数のしきい値を超えると Unhealthy と判定する。加えて、CloudWatch アラームの状態をヘルスチェックにする方式や、複数のヘルスチェックを AND / OR で束ねる計算されたヘルスチェックもある。切り替えは DNS 応答の変化として現れるため、実際の切り替わり速度は「ヘルスチェックの検知時間 + レコードの TTL + クライアント側リゾルバーのキャッシュ」に左右される。TTL を 60 秒程度に短くしておくのが定石で、より速い切り替えが必要なら AWS Global Accelerator のような DNS に依存しない方式を検討する。 SAA-C03 では「リージョン障害時に別リージョンへ自動フェイルオーバー」「同じドメイン名のまま切り替えたい」という要件でフェイルオーバールーティング + ヘルスチェックが正解になる。誤答には ALB や Auto Scaling グループをリージョンまたぎで使う構成が並ぶが、どちらもリージョン内のサービスであるという知識で切れる。加重ルーティングは「手動」である点が要件と噛み合わないという読み分けが問われる。