CloudFront の PoP 選択はどう動いているのか - DNS ルーティングとキャッシュ階層の仕組み
CloudFront がユーザーのリクエストを最寄りの PoP にルーティングする DNS ベースのルーティングの仕組み、エッジロケーションとリージョナルエッジキャッシュの多層キャッシュ構造、キャッシュヒット率を左右する設計要因を解説します。
PoP (Point of Presence) とは何か
CloudFront の PoP は、世界中に分散配置されたキャッシュサーバー群です。2026 年 8 月時点で 750 以上の PoP が 100 以上の都市 (50 以上の国) に展開されています。さらに、CloudFront のインフラは通常の PoP (エッジロケーション) だけでなく、ユーザーとオリジンの間に位置するリージョナルエッジキャッシュ (REC)、そして通信事業者や ISP のネットワーク内部に設置される embedded POP という 3 種で構成されており、embedded POP は 2026 年 8 月時点で 1,140 以上・300 以上の都市に及びます。PoP の役割は、オリジンサーバー (S3 バケットや EC2 インスタンスなど) のコンテンツをキャッシュし、ユーザーに物理的に近い場所から配信することで、レイテンシを削減することです。東京のユーザーが米国バージニアの S3 バケットに直接アクセスすると、太平洋を横断する往復で 150〜200ms のレイテンシが発生します。東京の PoP にコンテンツがキャッシュされていれば、レイテンシは 5〜10ms に短縮されます。PoP のサイズは均一ではありません。東京、ロンドン、バージニアのような大規模 PoP は数千台のサーバーで構成され、大量のコンテンツをキャッシュできます。一方、小規模な都市の PoP は数十〜数百台で、キャッシュ容量は限られます。CloudFront はトラフィック量に応じて PoP のキャパシティを動的に調整しており、大規模イベント (スポーツ中継、製品発表など) の際には一時的にキャパシティを増強します。
PoP 選択の仕組み - ユーザーを最寄りの PoP に導く DNS ベースのルーティング
CloudFront がユーザーのリクエストを最寄りの PoP にルーティングする既定の仕組みは、DNS ベースのルーティングとネットワーク性能のマッピングです。ユーザーが CloudFront のディストリビューション URL (例: d1234.cloudfront.net) にアクセスすると、まず DNS 解決が行われます。CloudFront の DNS サーバーは、ユーザーの DNS リゾルバの IP アドレスから地理的な位置を推定し、レイテンシやネットワーク性能の測定データに基づいて最適な PoP の IP アドレスを返します。この既定の経路では、PoP ごとに異なる IP アドレスが割り当てられており、同一の IP アドレスを複数の PoP で共有するわけではありません。DNS ベースのルーティングだけでは、DNS リゾルバの位置とユーザーの実際の位置が異なる場合 (企業の集中 DNS サーバーを使用している場合など) に最適な PoP が選択されないことがあります。これを補うため、CloudFront は EDNS Client Subnet (ECS) にも対応しており、DNS リゾルバがユーザーの実際のサブネット情報を CloudFront の DNS に伝えることで、より正確な PoP 選択が可能になっています。
Anycast Static IPs - オプトインの静的 IP アドレス機能
既定の PoP 選択が前述の DNS ベースのルーティングであるのに対し、ネットワークレベルで最短経路を選ぶ Anycast は、CloudFront では既定の動作ではなく任意の追加機能として提供されます。2024 年 11 月に提供が始まった Anycast Static IPs は、ディストリビューションに固定の静的 IP アドレスの一覧を割り当てるオプトイン機能です。この機能を有効にすると、複数の PoP が同一の IP アドレス群をアナウンスし、BGP (Border Gateway Protocol) のルーティングによってパケットがネットワーク的に近い PoP へ到達します。ファイアウォールの許可リストに CloudFront の IP アドレスを登録したい場合や、配信元の IP アドレスを固定することが要件となる場合に利用します。既定のディストリビューションはローテーションする IP アドレスで配信されるため、この静的 IP 機能はあくまで任意の選択肢であり、標準の従量課金とは別に追加料金が発生します (2026 年 8 月時点)。
2 層キャッシュ - エッジロケーションとリージョナルエッジキャッシュ
CloudFront のキャッシュは 2 層構造になっています。第 1 層はエッジロケーション (PoP) で、ユーザーに最も近い場所にあります。第 2 層はリージョナルエッジキャッシュ (REC) で、エッジロケーションとオリジンサーバーの間に位置します。REC は世界に 15 箇所あり (2026 年 8 月時点)、エッジロケーションよりも大きなキャッシュ容量を持っています。リクエストの流れはこうです。ユーザーのリクエストがエッジロケーションに到着し、キャッシュにコンテンツがあれば即座に返します (キャッシュヒット)。エッジロケーションにキャッシュがなければ、REC に問い合わせます。REC にキャッシュがあればそこから返し、なければオリジンサーバーに取りに行きます。この 2 層構造の利点は、オリジンサーバーへのリクエスト数を大幅に削減できることです。人気のないコンテンツ (ロングテール) は個々のエッジロケーションではキャッシュから追い出されやすいですが、REC の大きなキャッシュ容量により保持される確率が高くなります。複数のエッジロケーションからのリクエストが REC に集約されるため、同一コンテンツについてオリジンへ向かうリクエストは 1 本にまとめられ、オリジンサーバーの負荷とスケーリングコストを抑えられます。
キャッシュヒット率を左右する設計要因
CloudFront のキャッシュヒット率は、設計次第で 50% にも 99% にもなります。キャッシュヒット率を決定する最大の要因はキャッシュキーの設計です。CloudFront はデフォルトで URL のフルパスをキャッシュキーとして使用しますが、クエリ文字列、ヘッダー、Cookie をキャッシュキーに含める設定にすると、同じコンテンツでもキャッシュキーが異なるため、キャッシュが分散してヒット率が低下します。たとえば、クエリ文字列にトラッキングパラメータ (utm_source、utm_medium など) が含まれる場合、同じページでもパラメータの組み合わせごとに別のキャッシュエントリが作られます。CloudFront のキャッシュポリシーで、キャッシュキーに含めるクエリ文字列をホワイトリスト方式で指定し、トラッキングパラメータを除外すれば、ヒット率が劇的に改善します。TTL (Time to Live) の設定も重要です。TTL が短すぎるとキャッシュが頻繁に無効化され、オリジンへのリクエストが増加します。静的アセット (画像、CSS、JS) は TTL を 1 年に設定し、ファイル名にハッシュを含める (app.a1b2c3.js) ことで、コンテンツ更新時に新しい URL でキャッシュを自動的に切り替える戦略が最も効果的です。
Origin Shield - 3 層目のキャッシュでオリジンを守る
2020 年に導入された Origin Shield は、REC とオリジンの間に追加のキャッシュ層を設ける機能です。Origin Shield を有効にすると、すべての REC からのオリジンフェッチが 1 つの Origin Shield ロケーションに集約されます。Origin Shield にキャッシュがあれば、オリジンへのリクエストは発生しません。Origin Shield の最大の効果は、キャッシュの「サンダリングハード問題」の緩和です。人気コンテンツの TTL が切れた瞬間、世界中の PoP から同時にオリジンへのリクエストが殺到する現象です。Origin Shield がなければ、15 の REC から同時にオリジンフェッチが発生しますが、Origin Shield があれば 1 つのリクエストに集約されます。Origin Shield の料金は従量課金 (オンデマンド) プランの場合、リクエスト数ベースで 1 万リクエストあたり 0.0090 USD です (2026 年 8 月時点)。課金対象は Origin Shield を「増分層」として経由するリクエストに限られ、キャッシュ可能なリクエストが Origin Shield と同じリージョンの REC を経由する場合はスキップされて課金されません (PUT や POST などの動的リクエストは常に増分層として課金されます)。オリジンサーバーの負荷軽減とスケーリングコストの削減を考慮すると、多くのケースで費用対効果が高い投資です。特に、オリジンが Lambda Function URL や API Gateway のように従量課金のサービスである場合、Origin Shield によるリクエスト削減がそのままコスト削減につながります。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトおよび公式ドキュメントです。最新の仕様 / 料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。