SES エンジニアをしながら個人開発をしている fumi（@fumikun_gengen）です。最近は AWS Certified Cloud Practitioner（CLF-C02）の範囲を勉強していて、公式ドキュメントを読み込む日が続いています。
困ったのが、Route 53 / CloudFront / Global Accelerator の 3 サービスが「全部グローバルサービス」として並ぶ問題で連続して詰まったことでした。自分のサイト（aws-cert-roadmap-lab.com）は S3 + CloudFront + Lambda + DynamoDB で動いているのに、学習を進める中で CloudFront の位置づけをうまく説明できない場面がありました。3 サービスを「静的 IP がある / キャッシュする / DNS を解く」の 3 軸で並べ直して、ようやく「全部グローバルだけど階層が違う」と言えるようになりました。本記事はそのプロセスと、整理した比較表を 自分のために学習サイトの比較ページとして増やした 話です。
詰まったきっかけは、学習中に出会った、ある 1 つのシナリオでした。「動画を世界中に配信したい / 静的 IP は不要 / キャッシュで高速化」という条件で、私は最初なぜか Global Accelerator を思い浮かべています。CloudFront を「自分が触っているもの」と思い込んでいたので、「グローバル」という単語に引っ張られた瞬間に、頭の中で 3 サービスの境界が崩れていたのだと後から気づきました。
「グローバル」という単語が 3 つ並ぶと、人は混同する
CLF-C02 の学習で最初に引っかかるのが、AWS マネジメントコンソールの右上の「リージョン」欄に 「Global」と表示されるサービス群です。IAM、Route 53、CloudFront、Global Accelerator がここに並びます。学習を始めたばかりの頃の私は、これを単純に「リージョンに縛られないサービスのカテゴリ」とだけ理解していました。
ところが学習を進めると、この「グローバル」が 文脈ごとに違う意味で使われていることに気づきます。たとえば、
- 「グローバルに配信したい」 → CloudFront の話
- 「グローバルな静的 IP が必要」 → Global Accelerator の話
- 「リージョン障害時にグローバル DNS でフェイルオーバー」 → Route 53 の話
公式ドキュメントを並べて読み直すと、3 サービスとも「edge」「worldwide」「global network」という単語を共有しているのが分かります。Route 53 公式は「globally distributed DNS servers」、CloudFront 公式は「worldwide network of data centers」、Global Accelerator 公式は「global service」「AWS global network」（AWS Docs より）。書き分けの語彙が薄いので、「3 つともグローバルなのに、なぜ場面ごとに区別されるのか」というのが最初の壁でした。
整理してしまえば、3 サービスは 役割の階層がそもそも違います。
- Route 53 = 名前を IP に変換する DNS 層
- CloudFront = HTTP/HTTPS をエッジでキャッシュする CDN 層
- Global Accelerator = TCP/UDP のパケットを最適経路で運ぶ L3/L4 層
「グローバル」というのは「リージョンに縛られない」という運用面の属性であって、3 つは違う OSI 層 で違う仕事をしているサービスです。ここを最初に確定させたかった、というのが本記事の出発点です。
Route 53 = DNS 階層の「グローバル」（最古層）
Route 53 の公式ドキュメント によると、Route 53 の主機能は次の 3 つです。
-
ドメイン登録（
example.comを取得・更新する） - DNS ルーティング（クエリに対して IP アドレスを返す）
- ヘルスチェック（エンドポイントの死活監視）
「グローバルサービス」と呼ばれる理由は、Route 53 の DNS サーバーが世界中のエッジロケーションに分散配置されていて、どこから問い合わせても近い場所から返ってくる、という運用面の話です。ここで返ってくるのは IP アドレスそのものであって、HTML や画像のような「コンテンツ」ではない、というのが CloudFront との最大の違いです。
CLF-C02 の範囲で押さえておきたいのが ルーティングポリシー 7 種です。私自身の弱点ノートにも書いていますが、暗記カードで覚えるなら次のキーワードと対応で十分まわります。
| こんなとき | 選ぶポリシー |
|---|---|
| A/B テストで 10%/90% に振り分け | 加重（Weighted） |
| 最もレイテンシーが低いリージョンへ | レイテンシー |
| ヘルスチェック連動で災害復旧（DR） | フェイルオーバー |
| GDPR でデータ主権を守りつつ振り分け | 位置情報（Geolocation） |
| 簡易な負荷分散で複数 IP を返す | 複数値回答 |
料金は AWS 公式の料金ページ によると、ホストゾーン 1 つあたり月 $0.50、標準 DNS クエリは 100 万件あたり $0.40 が目安です。CLF-C02 の範囲では数値を細かく覚える必要は薄いですが、「AWS エンドポイントに対するヘルスチェックは無料、AWS 外（外部エンドポイント）のヘルスチェックは有料」のような 無料になる対象の違いは押さえておきたいポイントです。
ここで覚えておきたいのは、Route 53 は静的 IP を持たないこと と、キャッシュはしないことです。次の CloudFront との対比で効いてきます。
aws-cert-roadmap-lab.com は CloudFront を前段に置いている構成なので、CloudFront は一応「自分で動かしたことのあるサービス」でした。にもかかわらず学習中にうまく説明できなかったというのは、実装は 1 サービスを深く動かす作業、学習は N サービスを並べて理解する作業、という軸の違いを自分が見落としていたからだと思うようになりました。手を動かしたことと、並べて説明できることは、制御している認知が違うんだと、このとき初めて言えるようになりました。
CloudFront = CDN 階層の「グローバル」（エッジキャッシュ）
CloudFront の公式ドキュメント によると、CloudFront は HTTP/HTTPS コンテンツのエッジキャッシュ配信 が本業です。世界中のエッジロケーションに HTML・画像・動画・JS・CSS・API レスポンス等をキャッシュしておき、エンドユーザーから一番近いエッジから配信する、という仕組みです。
CLF-C02 の範囲で押さえておきたいポイントを 4 つに絞ると、こうなります。
- 対応プロトコル: HTTP / HTTPS のみ（TCP/UDP 全般は扱えない）
-
静的 IP: なし。DNS 名（
d1234abcd.cloudfront.netの形）で運用する - TLS 終端: CloudFront エッジで TLS 終端できる（HTTPS → オリジンとは HTTP でも可）
- キャッシュデフォルト TTL: 24 時間（公式記述。最小 0 秒、最大は無制限）
料金は CloudFront → ビューワー へのデータ転送と HTTP リクエスト数で課金されますが、公式ドキュメントによると **「S3・ELB・API Gateway 等の AWS オリジンから CloudFront へのデータ転送は無料」**です（Introduction より）。「S3 で公開しているサイトの転送コストを下げたい」というときに CloudFront を前段に挟むのが定番になりやすい背景です。
自分のサイトでの実装側から見ると、CloudFront を選ぶ理由は単純で「S3 をオリジンにしたら、CloudFront を挟まないと HTTPS・カスタムドメイン・転送量割引のいずれも揃わない」からでした。ところが「TCP/UDP のゲーム用途で最適化したい」「静的 IP をクライアントに配布したい」のように、CloudFront では解決できない要件が混ざると、ここで CloudFront を選んでしまう。3 サービスの違いを理解していないと、こういう取り違えが起きる、という構造です。
Global Accelerator は、私はまだ業務でも個人開発でも触ったことがありません。これが AWS 学習者あるあるなのですが、「触ったことがないサービスをどうやって理解するか」が大きなテーマになります。私の答えは「比較表に 同じ軸で並べてしまう」でした。Route 53 と CloudFront は触ったことがあるので、その隣に Global Accelerator を 1 行差し込めば、触ったことのないサービスのほうも「他 2 つで何ができないか」の裏返しで理解できる、というのが自分にとっての擬似体験の方法です。
Global Accelerator = Anycast IP の「グローバル」（高速ルーティング）
Global Accelerator の公式ドキュメント によると、Global Accelerator は TCP / UDP のトラフィックを AWS バックボーン経由で最適化 + 静的 Anycast IP を提供するサービスです。CloudFront との最大の違いは HTTP/HTTPS に限定されないことと、静的 IP があることです。
公式記述で押さえたいポイントは次の通りです。
- 静的 IP: 標準アクセラレータはデフォルトで IPv4 の静的 IP を 2 個提供。デュアルスタック構成にすると IPv6 アドレスも追加される（核心は「静的 IP を 2 個提供する」）
- 配布元: 「The static IP addresses are anycast from the AWS edge network」（公式から引用）
- プロトコル: TCP / UDP どちらも可（任意ポート）
- キャッシュ: なし。経路最適化のみ
- ヘルスチェック: TCP でエンドポイント死活監視、ヘルス変化に対して 数秒以内でルート変更
料金は AWS 公式の料金ページ によると、1 アクセラレータあたり 時間 $0.025（月換算で約 $18）の固定費 + DT-Premium の従量課金（$0.007〜$0.105/GB のレンジ）です。CloudFront や Route 53 が「使った分だけ」なのに対して、Global Accelerator は 作っただけで月 $18 が確定する、という性質を覚えておくと「コスト最適化で停止候補になるのはどれか」を考えるときに引っかからずに済みます。
ユースケースは 静的 IP が必要な領域に偏ります。たとえば、
- ゲーム（TCP/UDP のリアルタイム通信）
- VoIP（音声通話）
- 金融取引（クライアント側ファイアウォールで IP ホワイトリストを要求される）
- フェイルオーバーの即時性が重要なアプリ
CloudFront が「コンテンツを世界中に キャッシュして配信する」のに対し、Global Accelerator は「パケットそのものを AWS バックボーンで最短経路に乗せる」と覚えると、両者の違いがブレません。
最初に作った比較表はもっと縦長で、「主目的 / グローバル属性 / 静的 IP / TCP-UDP / TLS 終端 / キャッシュ / ヘルスチェック / 典型ユースケース / 料金構造」みたいに 10 行近く並べていました。並べてはみたものの、実際に効いてくるのは結局「このケースでこの 3 つのどれを選ぶか」だけです。意思決定に効く軸だけ残したら、「静的 IP / キャッシュ / DNS 解決」の 3 軸まで圧縮できました。逆に言うと、それ以外の軸は 3 つを区別する役には立っていなかった、というのが整理する側の発見でした。
3 サービスを 3 軸（静的 IP / キャッシュ / DNS 解決）で並べる
ここまでの内容を、意思決定に効く 3 軸だけで並べ直すと次のようになります。
| 軸 | Route 53 | CloudFront | Global Accelerator |
|---|---|---|---|
| 静的 IP を持つか | ✗（DNS 名で運用） | ✗（DNS 名で運用） | ✓（IPv4 静的 IP を 2 個 / デュアルスタックで IPv6 追加） |
| コンテンツをキャッシュするか | ✗ | ✓（エッジ TTL 24h デフォルト） | ✗ |
| DNS 解決をするか（名前 → IP） | ✓ | ✗ | ✗ |
3 サービスを 1 つの表に並べた瞬間に、「全部グローバルだけど、できることはきれいに 1 つずつ違う」が見えるようになります。
実際の使い分けはこの 3 軸でほぼ片付きます。
- 「静的 IP が必要 / TCP/UDP のゲーム / クライアントに IP を配布」 → Global Accelerator
- 「画像・動画・JS/CSS を世界中で キャッシュ配信」 → CloudFront
- 「リージョン障害時に DNS でフェイルオーバー / GDPR のために 位置情報で振り分け」 → Route 53
「グローバル」というキーワードに引っ張られず、**「何をしてほしいか」**を主語に置き換えると、3 サービスのどれが当てはまるかは 3 軸のどれに ✓ が立つかで決まります。
この 3 軸テーブルを、CLF-C02 の学習のために作っている自分の学習サイト（aws-cert-roadmap-lab.com）の 比較ページに追加しました。サイトには用語集・比較・構成図などのコーナーがあって、3 サービスの「グローバル」混乱はこの「比較」セクションに置くのが一番自然だったからです。
比較ページの設計方針は単純で、
- 理解が曖昧だった点に気づくたびに 1 項目追加する（気づきドリブンの増殖）
- 意思決定に効く軸だけ残す（10 軸表は作らない）
- 「他に検討した軸」も小さく残す（同じ過ちを繰り返さないため）
の 3 つだけです。学習を進める中で別の 3 サービスを取り違えたら、その日のうちに比較ページに 1 項目足す、という運用を続けています。
まとめ
3 サービスの「グローバル」混乱は、3 軸の比較表 1 枚を作ったことでだいぶ整理できました。ここからは同じやり方で、他のドメイン（料金モデル / サポートプラン / AI・ML サービス / セキュリティ部品 / ガバナンス）も並べて整理していくつもりです。
比較ページに何を足すかは、学習していて「ここが曖昧だった」と気づくたびに 1 項目増える運用にしています。自分の弱点ノートから移植したものが今は並んでいますが、これからも少しずつ増えていくはずです。読んでくださった方も AWS を学習中なら、3 サービス混同は早めに 3 軸テーブルで潰しておくと、「グローバル」という単語に引っ張られずに済むと思います。
参照リンク
- Amazon Route 53 Developer Guide / Welcome
- Amazon CloudFront Developer Guide / Introduction
- AWS Global Accelerator Developer Guide / What is Global Accelerator
- Amazon Route 53 Pricing
- AWS Global Accelerator Pricing
- 比較ページ（本記事で追加した 3 サービス比較）: aws-cert-roadmap-lab.com/comparisons
- 過去記事（同じ CLF-C02 学習路線）: LPIC で踏んだ 3 つのつまずきが、AWS CLF-C02 の学習で 3 回助けられた話