週6Route 53 / CloudFront

2026-09-07（月）Route 53, CloudFront

この記事の目次
  1. この範囲の全体像
  2. 重要キーワード・サービス一覧
  3. 試験で問われる比較ポイント
  4. ひっかけ注意ポイント
  5. 一問一答セルフテスト

1. 【この範囲の全体像】

本範囲は、高可用でスケーラブルなクラウドデザインを実現する上で不可欠なドメイン名前解決および広域トラフィック管理サービスである Amazon Route 53 について学習します [p.164]。

単なるIPアドレスへのマッピング（名前解決）にとどまらず、AWS特有の制約をバイパスする Aliasレコード [p.165]、システムの目的（低遅延、高可用、地域制限など）に合わせてアクセスをインテリジェントに制御する トラフィックルーティングポリシー [p.165, p.166]、そして障害発生時に自律的な切り替えを行う DNSフェイルオーバー [p.167] の仕組みを理解します。

試験では、システムの要件に合わせて最も適切なレコード仕様やルーティング設計をロジカルに選択できる能力が問われます [p.165]。

2. 【重要キーワード・サービス一覧】

キーワード 説明
Amazon Route 53 [p.164] 可用性と信頼性に極めて優れたフルマネージドな「権威DNS（DNS問い合わせに対してドメイン情報を自ら保持し、直接回答を返すDNS）」サービス [p.164]。
ホストゾーン (Hosted Zone) [p.165] ドメイン名（例：example.com）配下の各種DNSレコード（Aレコード、CNAMEレコード等）を論理的にまとめて一括管理するための設定空間 [p.165]。
Zone Apex (APEXドメイン / 裸のドメイン) [p.165] example.com のように、www や app などのホスト名（サブドメイン）を含まない、ドメイン名の一番親階層（親ルート）にあたる記述形式のこと [p.165]。
Aliasレコード (エイリアスレコード) [p.165] Route 53独自の拡張仕様。DNSの国際標準であるCNAMEレコードとは異なり、Zone Apexに対してもロードバランサー（ALB）やCloudFront等のAWSリソースを直接安全にマッピングでき、かつその名前解決に関するDNS問い合わせ料金（クエリ課金）が完全無料になる機能 [p.165]。
トラフィックルーティングポリシー [p.165] クライアントからのDNS問い合わせに対して、どのエンドポイント（サーバー等の宛先）のIPアドレスを返すかを制御するための判定ルール（シンプル、加重、レイテンシー、位置情報、フェイルオーバー、複数値回答など） [p.165, p.166]。
トラフィックフロー (Traffic Flow) [p.166] 遅延やフェイルオーバー、加重などの複数の複雑なルーティングルールを組み合わせた巨大な意思決定モデルを、グラフィカルなWebビジュアルエディターを使い、直感的に設計・バージョン管理して公開できる機能 [p.166]。
DNSフェイルオーバー [p.167] 「Route 53 ヘルスチェック」と連動し、プライマリのWebサーバーやロードバランサーの稼働状況を死活監視し、異常を検知した際に全自動で正常なスタンバイリソースやS3上の静的Sorryページへ名前解決先を切り替える高可用性アーキテクチャ [p.165, p.167]。

3. 【試験で問われる比較ポイント】

① レコード定義の落とし穴：CNAMEレコード vs Aliasレコード [p.165]

外部リソースへのルーティングを行う際、標準的なDNS仕様か、AWS特化型のアプローチかを選択する境界です [p.165]。

比較項目 CNAMEレコード [p.165] Aliasレコード (エイリアスレコード) [p.165]
Zone Apexへの設定 設定不可（RFC標準の厳格な制限により、example.comなどの親ルートにはCNAMEを設定できない） [p.165]。 設定可能（標準DNS制限を安全にバイパスし、親ドメインに直接AWSリソースをアタッチできる） [p.165]。
名前解決の課金特性 有料（CNAMEを介した名前解決クエリが発生するたびに通常料金が発生） [p.165]。 完全無料（ALB、CloudFront、S3等へのAlias名前解決にかかるAPIクエリ料金は無料） [p.165]。
マッピング対象 任意のFQDN（他社クラウドやオンプレミスサーバーのドメイン名も可） [p.165]。 特定のAWS提供リソース（ALB、NLB、CloudFrontディストリビューション、S3バケット等） [p.165]。
決定的な選定シグナル 「 サブドメイン www.example.com から、外部の特定のドメイン名へトラフィックを転送させたい 」 「 ルートドメイン example.com に対し、Application Load Balancer (ALB) や CloudFront を直接安全かつ最安値で紐付けたい 」 [p.165]。

② 目的別・ルーティングポリシーの徹底使い分け [p.165, p.166]

「どのような動機でユーザーのアクセスをコントロールしたいか」によって、ポリシーを選択します [p.165, p.166]。

ルーティングポリシー [p.165, p.166] 主な動作と仕組み [p.165, p.166] 主な試験上の用途・選定キーワード [p.165, p.166]
シンプル [p.165] 1つのレコードに対して標準的に1つの宛先を回答する最も標準的な名前解決 [p.165]。 「 特定のWebサーバーやAWSリソース（ALBなど）に対して、1対1でシンプルに解決させたい 」 [p.165]。
加重 (Weighted) [p.166] 宛先ごとに指定した任意の比率（例：90%と10%）に基づいて、トラフィックを分散解決させる [p.166]。 「 新システムの一部お披露目のためのA/Bテストや、段階的にトラフィックを流すカナリアデプロイを実行したい 」 [p.166]。
レイテンシー [p.166] 複数のリージョンの中で、ユーザーにとってネットワーク接続遅延（ミリ秒）が最も少ないサーバーへ自動的に誘導する [p.166]。 「 マルチリージョン構成において、世界中のユーザーに対してアプリケーションへの最速のネットワーク応答性（低遅延）を提供したい 」 [p.166]。
位置情報 (Geolocation) [p.166] ユーザーがアクセスしている物理的な場所（国や大陸、都道府県など）を元にしてルーティングを振り分ける [p.166]。 「 アクセス元の言語や現地のプライバシー保護法（例：EUのGDPR）に準拠した現地の特定のリージョンへ確実にアロケーションしたい 」 [p.166]。
フェイルオーバー [p.165] 通常はプライマリに接続させ、ヘルスチェック異常検知時にセカンダリ（Sorryページ等）へ自動迂回させる [p.165, p.167]。 「 本番のEC2サーバー群がクラッシュした際、手動介入なしで自動的にS3上の静的Webサイト（Sorryページ）へ切り替えたい（DR対策） 」 [p.165, p.167]。
複数値回答 (Multivalue) [p.166] 1つのレコードに最大8つの正常なIPアドレスを登録し、ランダムかつヘルスチェック正常なIPのみをクライアントに返却する [p.166]。 「 ELBを構築するコストを節約しつつ、DNSレベルのみで複数の正常なWebサーバー群へ簡易的にトラフィックを分散・リトライ処理させたい 」 [p.166]。

4. 【ひっかけ注意ポイント】

  • ひっかけ①：Zone Apex（裸のドメイン）に、ロードバランサーのアドレスをアタッチするために「CNAME」を選定する罠 [p.165]

    • 罠: 「現在運用中のシステムで、サブドメインなしのメインドメインである example.com（Zone Apex）に対する全トラフィックを、新しく構築した Application Load Balancer（ALB）のDNS名にマッピングさせたい。このため、RFC標準に従ってCNAMEレコードをホストゾーンに登録した [p.165]。」
    • なぜ間違いか: DNSの国際標準規格（RFC）の仕様上、Zone Apex（サブドメインのつかないルート）に対してCNAMEレコードを割り当てることは絶対に許されていません [p.165]。これを登録しようとするとDNSエラーになるか、ドメイン自体の名前解決（MXレコードによるメール受信等）に致命的な損壊を招きます。
    • 正しい解決策: Route 53固有の拡張機能である 「 Alias（エイリアス）レコード（Aレコードのエイリアスオプションをオンにする） 」 を使用します [p.165]。これであればZone ApexへのALBやCloudFront等のAWSリソース（FQDN）の直接アタッチが可能で、クエリの発生コストも無料に最適化されます [p.165]。

  • ひっかけ②：アプリケーションの応答速度（レスポンス遅延）を極小化したい要件に「位置情報（Geolocation）」を指定させる罠 [p.166]

    • 罠: 「世界中からアクセスされるWebアプリケーションにおいて、世界各地のユーザーのネットワーク応答レイテンシー（遅延）を最小に抑えてユーザー体験を高めるため、位置情報ルーティングをアタッチして各ユーザーに最も地理的に近いリージョンへトラフィックをマッピングした [p.166]。」
    • なぜ間違いか: 位置情報（Geolocation）ルーティングは、あくまで「ユーザーがどこの国や地域に所属しているか」という静的な国土地理情報を元に通信を振り分けるのみです [p.166]。これは、実際のインターネット回線の物理的な混雑状況、通信キャリアの経路距離、ミリ秒単位の伝送遅延情報を測定・計算していません [p.166]。
    • 正しい解決策: ネットワークパフォーマンスの極大化、つまり「遅延（レイテンシー）の最小化」という要件が明示されている場合は、実際の遅延値をAWS側がリアルタイム測定して最適化する 「 レイテンシールーティングポリシー 」 を確実に選定する必要があります [p.166]。

  • ひっかけ③：DNSフェイルオーバーを設定するだけで「Route 53 ヘルスチェック」を関連付け忘れる罠 [p.165, p.167]

    • 罠: 「本番のWebサーバー（EC2）が被災した際に、自動的にS3静的Webサイト上のSorryページに切り替わるように、Route 53でフェイルオーバーレコード（プライマリ：EC2、セカンダリ：S3）を設定して動作させた。これで自動的なDR復旧が完璧にいつでも稼働する [p.165, p.167]。」
    • なぜ間違いか: フェイルオーバー（DR自動化）は、Route 53が「プライマリが現在ダウンしている（異常である）」という動作状態を動的に検出できていることが前提となります [p.167]。プライマリ側のDNSレコード設定において、「Route 53 ヘルスチェック」を明示的に作成して関連付け（アタッチ）しておかない限り、サーバーが物理的に100%クラッシュしてもRoute 53はダウン状況を検知できず、永遠に被災したIPアドレスをユーザーに返し続け、Sorryページへの切り替えは機能しません [p.165, p.167]。
    • 正しい解決策: フェイルオーバールーティングを組む際は、必ず監視対象リソースに適合した 「ヘルスチェック（Health Check）」を作成し、プライマリレコードに明示的に紐付けておく 必要性があります [p.165, p.167]。

5. 【一問一答セルフテスト】

選択肢を選ぶと、その場で正誤と解説が表示されます。