DOP弾力性に優れたクラウドソリューション
メディア配信企業がCloudFrontを使用して静的コンテンツをS3バケット（us-east-1）から配信しています。コンプライアンス要件により、S3障害時には自動的にus-west-2のS3バケットへフェイルオーバーし、エンドユーザーへのDNS変更や手動設定変更なしに継続配信できる構成が必要です。さらにフェイルオーバー発生時にはオペレーションチームへSNS通知を送ることも求められています。この要件を最小限の構成変更で実現する正しいアーキテクチャはどれですか？
ARoute 53フェイルオーバールーティングを設定し、プライマリS3バケットのヘルスチェックが失敗した場合にセカンダリリージョンの別CloudFrontディストリビューションへ切り替え、Route 53アラームからSNS通知を送信する
Route 53フェイルオーバーで別ディストリビューションに切り替えると、DNS伝播遅延によるダウンタイム増加と複数エンドポイント管理が必要になります。
BCloudFrontオリジングループでus-east-1 S3をプライマリ・us-west-2 S3をセカンダリとし、フェイルオーバー基準HTTPステータスコード（403/500/503等）を設定してCloudWatch 5xxエラー率アラームからSNSトピックに通知する
✓ 正解
CloudFrontオリジングループ（Origin Failover）は403・500・503などのエラーコードでセカンダリへ自動切替え、同じディストリビューション内で完結するため、エンドユーザー側は影響なく、CloudWatchアラームで即時通知可能です。
CLambda@Edgeをオリジンリクエストトリガーとして設定し、プライマリS3のHEADリクエストでヘルスチェックを実施して障害検知時にオリジンURLをus-west-2に書き換え、SNSトピックへPublishする
Lambda@Edgeはリクエストごとのヘルスチェックが遅延・コスト増を招きます。CloudFrontのネイティブ機能で対応できます。
Dus-east-1とus-west-2のS3バケットをオリジンとするCloudFrontディストリビューションをそれぞれ別に作成し、Route 53のフェイルオーバールーティングで2つのディストリビューションドメイン名を切り替えるよう設定する
複数ディストリビューション間のRoute 53フェイルオーバーはDNS TTLを超える遅延が発生し、「エンドユーザーへのDNS変更なし」と矛盾します。
解説
CloudFront のオリジンフェイルオーバー（オリジングループ）は、プライマリオリジンが指定 HTTP エラーコードを返した場合に自動でセカンダリへ切り替える機能です。CloudFront のエンドポイントもディストリビューション ID も変わらないため、エンドユーザー側への影響はゼロです。CloudWatch のリアルタイムメトリクスと SNS アラームを組み合わせることで、フェイルオーバー発生時の運用チームへの自動通知も実現できます。
選択肢 A は Route 53 フェイルオーバールーティングで別の CloudFront ディストリビューションへ切り替える構成ですが、DNS 伝播遅延が発生するためエンドユーザーへの影響を排除できません。
選択肢 C は Lambda@Edge でリクエストごとにヘルスチェックを行う構成ですが、全リクエストに追加レイテンシーとコストが発生するため最小限の構成変更とはいえません。
選択肢 D は 2 つの CloudFront ディストリビューションを Route 53 で切り替える構成ですが、DNS 伝播遅延の問題に加え、2 つのディストリビューションを個別に管理する運用コストも増加します。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDOPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →