SOAネットワークとコンテンツ配信
ある企業は、本番 Web アプリケーションを us-east-1 と ap-northeast-1 の 2 リージョンで稼働させ、各リージョンの内部 Application Load Balancer（ALB）配下のプライベートサブネットに EC2 を配置しています。Route 53 のフェイルオーバールーティングでアクティブ／パッシブ構成の DR を実現したいのですが、内部 ALB はインターネットから到達できないため、通常のヘルスチェックが失敗します。最小の運用負荷でフェイルオーバーを正しく機能させる方法はどれですか。
ARoute 53 で内部 ALB の DNS 名を対象にした標準エンドポイントヘルスチェックを作成し、フェイルオーバールーティングに関連付ける
Route 53 の標準エンドポイントヘルスチェックはパブリックインターネット上のチェッカーから検査するため、プライベートサブネット内の内部 ALB には到達できず、ヘルスチェックが常に異常となりフェイルオーバーが正しく機能しません。
B内部 ALB のヘルス状態を表す CloudWatch アラームを作成し、それを参照する Route 53 ヘルスチェックを設定してフェイルオーバーレコードに関連付ける
✓ 正解
内部 ALB のメトリクスから作成した CloudWatch アラームを参照するヘルスチェックは、インターネット到達性に依存せずプライベートリソースの健全性を判定できます。追加インフラ不要で運用負荷も最小のため最適です。
C複数のエンドポイントヘルスチェックを束ねた Route 53 の計算ヘルスチェックを作成し、フェイルオーバールーティングに関連付ける
計算ヘルスチェックは複数の子ヘルスチェックの結果を論理合成する仕組みですが、束ねる子チェックがいずれも到達不可能なエンドポイントチェックであるため、根本的に内部 ALB の状態を判定できません。
Dヘルスチェック専用のパブリック NLB を各リージョンに配置し、それを対象にした Route 53 エンドポイントヘルスチェックを作成する
パブリック NLB を追加すれば到達性は得られますが、ヘルスチェック目的だけに公開エンドポイントを新設することになり、攻撃面の拡大と運用・コスト増を招くため最小負荷の要件に反します。
解説
Route 53 のグローバルヘルスチェッカーはパブリックインターネット経由でエンドポイントを検査するため、プライベートサブネット内の内部 ALB には直接到達できません。
この場合は CloudWatch メトリクスベース（アラームベース）のヘルスチェックを使います。内部 ALB の HealthyHostCount などのメトリクスから CloudWatch アラームを作成し、そのアラーム状態を参照する Route 53 ヘルスチェックを設定すれば、プライベートリソースの健全性を判定してフェイルオーバーレコードを切り替えられます。追加インフラが不要で運用負荷も最小です。
選択肢Aの標準エンドポイントヘルスチェックは、Route 53 のチェッカーがインターネットから内部 ALB に到達できないため常に失敗します。
選択肢Cの計算ヘルスチェックは、束ねる対象が同じく到達不可能なエンドポイントチェックであるため判定できません。
選択肢Dのパブリック NLB 追加は、不要な公開エンドポイントを増やしセキュリティと運用負荷を高めるため最適ではありません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSOAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →