Amazon CloudFrontリクエストのライフサイクルを図解する

本稿は、2025 年 10 月 17 日に公開された “Charting the life of an Amazon CloudFront request” を翻訳したものです。

Amazon CloudFront は、AWS ネイティブの Content Delivery Network (CDN) サービスです。CDN は、エンドユーザーにより近い世界中のエッジロケーションのネットワークを使用し、エッジでコンテンツをキャッシュすることで、Web アクセラレーションを提供します。しかし、CloudFront はそれ以上のことができます。エッジでの機能として、地理的フィルタリング、関数の実行、AWS Web Application Firewall (WAF) フィルタリングの実行など、さまざまな機能を備えています。この投稿では、CloudFront ディストリビューションへのクライアントリクエストのライフサイクルを探求し、特にこれらの機能の実行順序に注目します。この理解は、Web アプリケーションの配信最適化、Web アプリケーションのセキュリティ保護、および CDN 設定のトラブルシューティングにおいて不可欠です。

リクエストのライフサイクルを見ていく前に、CloudFront クライアントリクエストに関わるインフラストラクチャの構成要素を探ってみましょう。

図 1: CloudFront エッジロケーションと リージョン別エッジキャッシュ

エッジキャッシングの概要

CloudFront の Point of Presence (POP)、別名エッジロケーションは、リクエストが最初に到達するサーバーグループです。エッジロケーションは、リクエストに対して応答する(コンテンツがキャッシュされている場合)か、次のレイヤーに転送するかを判断します。エッジロケーションは世界中に分散配置されており、通常の AWS リージョンよりも小規模です。説明を分かりやすくするため、POP を 1 つの単位として考えることができます。図 1(公式 CloudFront ドキュメントより引用)は、この構成を示しています。

この概要説明で十分なケースもありますが、実際には CDN 設定のトラブルシューティング、キャッシング最適化、動的コンテンツ配信のパフォーマンス改善などのために、リクエスト-レスポンスの流れをより詳細に理解する必要があります。注目すべき点は、ビューワーからのリクエストとレスポンスが CloudFront ネットワーク内の複数のレイヤーを通過することです。POP では初期接続処理、負荷分散、キャッシング、CloudFront Functions の実行が行われ、リージョン別エッジキャッシュ (REC) では高度なキャッシュ最適化、Lambda@Edge の実行、オリジンサーバーへの接続、リクエストの折りたたみ、オリジンタイムアウト設定などが処理されます。また、キャッシュ効率をさらに向上させるオプション機能として Origin Shield を有効化できます。

HTTP(s) プロトコルに加えて、CloudFront はプロトコルの拡張機能もサポートしています。例えば、HTTP/2 上に構築されたオープンソースの Remote Procedure Call (RPC) フレームワークである gRPC や、TCP ベースのプロトコルである WebSocket があります。WebSocket は、リアルタイムアプリケーションで永続的な接続が必要な場合に、クライアントとサーバー間で長時間持続する双方向通信を実現するのに適しています。

本記事では HTTP(s) のリクエストとレスポンス処理に絞って解説し、gRPC と WebSocket 接続については別の記事で詳しく説明する予定です。

DNS 名前解決と POP

ユーザーが CloudFront 経由で Web サイトにアクセスするところから始まります(次の図を参照)。通常、Web サイトはカスタムドメイン名を CloudFront のドメイン名に紐付けて設定されています。CloudFront は DNS リクエストからユーザーの位置情報を判断し、そのリクエストを処理するのに最適なエッジロケーションの情報を DNS レスポンスとして返します。この際、CloudFront はインターネットネットワークの健全性、ネットワーク負荷など複数の要素を考慮して、ビューワーに最適な POP の IP アドレス(複数)を提供します。エンドユーザーの所在地に応じて、リクエストに応答するインフラを制限することで、コスト削減と異なる価格クラスの活用が可能です。CloudFront ディストリビューションで選択した価格クラスによって、ユーザーが利用できる POP が限定されます。また、CloudWatch Network Monitor と CloudWatch Internet Monitor を利用することで、AWS 上でホストされているアプリケーションのネットワークおよびインターネットのパフォーマンスと可用性について、運用上の可視性を得ることができます。

CloudFront で エニーキャスト静的 IP を使用している場合、DNS 解決によって最適な CloudFront POP を決定するプロセスは異なります。本記事では エニーキャスト IP を使用しないケースを想定しています。

図 2: CloudFront リクエストの経路

接続確立と TLS ネゴシエーション

DNS 名前解決が完了すると、クライアントアプリケーション(Web ブラウザやモバイルアプリなど、ビューワーと呼ばれます)は、最適な POP の IP アドレスリストを受け取ります。クライアントアプリケーションは、これらの IP のいずれかを使用して POP への接続を確立し、必要に応じて別の IP を使ってフェイルオーバーすることができます。CloudFront は IETF 標準に準拠し、ポート 80/443 で HTTP、HTTPS、WebSocket を受け付けます。すべての POP は AWS Shield Standard によって保護されており、UDP フラッドや SYN フラッドなどの一般的な DDoS ボリューメトリック攻撃から守られています。次のレイヤーでは、Secure Sockets Layer (SSL)/Transport Layer Security (TLS) 接続が正しく確立されているかを確認します。CloudFront ディストリビューションに設定されたセキュリティポリシーによって、使用可能なプロトコルと暗号スイートが定義されます。

リクエストルーティングと検証

リクエストはリクエストルーターに引き渡されます。POP のリクエストルーターは、クライアント接続を複数のキャッシュサーバーに負荷分散します。ここには重要なセキュリティレイヤーも存在し、クライアントからのリクエストが Request for Comments (RFC) に準拠しているか、不正または曖昧な構文による脅威が含まれていないかを確認することで、キャッシュサーバーを監視・保護しています。このレイヤーによって、キャッシュレイヤーに転送されるリクエストが適切なフォーマットで HTTP 仕様に準拠していることが保証されます。この段階で、CloudFront ディストリビューションの設定に基づき、許可されるプロトコル、HTTP メソッド、地理的制限が評価されます。

AWS WAF

リクエストの負荷分散とアクセス前のセキュリティチェックの後、CloudFront ディストリビューションで AWS WAF が有効化されている場合は、リクエストは AWS WAF のウェブアクセスコントロールリスト (ウェブ ACL) に設定されたルールによって処理されます。AWS WAF は Web アプリケーションファイアウォールであり、SQL インジェクション、クロスサイトスクリプティング、ボット攻撃、DDoS 攻撃などのアプリケーションレイヤーの攻撃からアプリケーションを守るために、リクエストを監視します。AWS WAF は、キャッシュビヘイビア、リクエスト/レスポンスヘッダーポリシー、CloudFront Functions や Lambda@Edge といったエッジコンピューティング関数などのコンテンツ処理ルールよりも必ず先に実行されます。

ビヘイビア

この段階で、ユーザーはビヘイビアセクションにて、CloudFront がリクエストをどのように処理するかを定義できます。ビヘイビアは URL のパスパターンごとに異なる設定を持つことができます。ビヘイビア設定では、使用するオリジン、許可する HTTP メソッド、キャッシュポリシー、関数の紐付け、そしてオリジンリクエストポリシーを指定します。オリジンリクエストポリシーでは、どのパラメータ(ヘッダー、クエリ文字列、Cookie)をオリジンに転送するかを定義します。また、機密情報を保護するためのフィールドレベル暗号化も設定可能です。

CloudFront キャッシング

CloudFront は、CloudFront Functions の Viewer Request 関数(設定されている場合)の実行後、POP のキャッシュに問い合わせを行います。POP 内には、キャッシュヒット率を最大化するための複数レイヤーのキャッシュが存在します。最初のレイヤーにオブジェクトがキャッシュされていない場合、リクエストは次のレイヤーへ、さらに次へと順次転送されていきます。ただし、無限にレイヤーを増やすことはできないため、各キャッシュスタック内のキャッシュサーバー数や、最初のレイヤーが参照できるピアの数には上限があります。POP 内のすべてのキャッシュレイヤーでオブジェクトが見つからない場合、リクエストは REC に転送されます。

REC

REC には POP と同様のキャッシュレイヤーがあり、キャッシュ容量の拡大と Lambda@Edge 関数の実行に必要なコンピューティングインフラを提供しています。REC は POP とオリジンサーバーの間に位置する大容量のキャッシュレイヤーとして機能し、キャッシュヒット率のさらなる向上、オリジンへのリクエスト削減、そして Lambda@Edge の実行基盤としての役割を果たします。

Lambda@Edge の ビューワーリクエスト関数を定義している場合、CloudFront が REC のキャッシュを確認する前に、この段階で実行されます。その後、REC のキャッシュにオブジェクトが存在しない場合、Lambda@Edge のオリジンリクエスト関数が実行されます。

CloudFront ディストリビューションで Origin Shield を有効化している場合、すべての REC はオリジンサーバーへリクエストを送る前に Origin Shield を経由するため、オリジンサーバーへの負荷を削減できます。Origin Shield はユーザーのオリジンサーバーに近い場所に配置され、オリジンへのトラフィック帯域幅とリクエスト数を減らすことで、キャッシング効率を高めます。

オリジン接続側の最終レイヤー (REC または Origin Shield) は、コンテンツオリジンとの間で永続的な接続を維持し、効率的なデータ転送を実現します。オリジンタイムアウト設定 (カスタムオリジンの場合) では、ユーザーは以下の値を調整することができます:

1. 接続試行回数: CloudFront がオリジンサーバーへの接続を試みる回数を設定します。
2. 接続タイムアウト: CloudFront がオリジンサーバーへの接続確立を試みる際の待機時間(秒)を指定します。
3. レスポンスタイムアウト: CloudFront がオリジンにリクエストを転送してからレスポンスを待つ時間、およびオリジンからレスポンスパケットを受信した後、次のパケットを受信するまでの待機時間を設定します。

オリジンリクエストポリシーでは、エッジからオリジンサーバーへ接続する際に使用する最小 SSL バージョンも定義されます。

オリジンからのレスポンス

リクエストがすべてのキャッシュレイヤー、REC、Origin Shield のいずれにも存在しない場合、オリジンサーバーから取得されます。オリジンはパブリック IP でアクセス可能なリソースですが、VPC オリジンと組み合わせることでプライベートリソースにすることも可能です。オリジンが URL で指定されている場合、この段階で DNS 名前解決が実行されます。これにより、Amazon Route 53 のレイテンシーベースルーティングや地理的位置情報ルーティングといったルーティングポリシーを活用して、最適なオリジンの場所を決定できます。

レスポンスは、リクエストとは逆の経路をたどって戻ります。オリジンサーバーからのレスポンスは REC に返されます。リクエストがキャッシュ可能で圧縮が有効な場合、レスポンスは圧縮されます。キャッシュの保持期間は CloudFront ビヘイビアのキャッシュポリシーで管理されます。Lambda@Edge のオリジンレスポンス関数が定義されている場合は、この段階で実行され、その結果が REC にキャッシュされます。Lambda@Edge のビューワーレスポンス関数が定義されている場合も実行されます。セキュリティ上の理由から、レスポンスに対して実行される関数はレスポンスボディの読み取りはできませんが、置き換えることは可能です。処理は POP へと続きます。CloudFront Functions の ビューワーレスポンス関数が定義されている場合は POP で実行され、最終的なコンテンツがクライアントに配信されます。図 2 は、このリクエスト/レスポンスの流れにおける主要なステップをまとめたものです。

まとめ

本記事では、ビューワーから Amazon CloudFront を経由してオリジンサーバーへと至る単一のリクエスト、そしてオリジンサーバーからビューワーへ戻るレスポンスの流れを追いながら、CloudFront が提供する様々なレイヤーと機能について解説しました。

各機能の実行順序と、それぞれがどのレイヤーで動作するかについて理解が深まったことと思います。ぜひこの知識を活かして、お使いの CloudFront 設定(キャッシュ設定、エッジ関数、AWS WAF、AWS Shield など)を見直し、CloudFront CDN の持つすべての力を最大限に活用してください。

著者について

翻訳は Solutions Architect の長谷川 純也が担当しました。