CloudFrontヘッダー制御とFunction活用術：設定と実践ガイド

CloudFrontヘッダー制御とFunctionによる動的処理の全体像

CloudFrontとヘッダー制御がもたらすビジネスメリット

現代のWebシステムにおいて、コンテンツデリバリーネットワーク（CDN）の活用はもはや標準的なインフラ構成となっています。総務省の調査によると、2024年時点での日本国内企業のクラウドサービス利用率は80.6%に達しており、WebシステムにおけるCloudFrontのようなCDNの重要性が高まっています。CloudFrontを導入することで、ユーザーへのコンテンツ配信の高速化と安定稼働を実現できるだけでなく、エッジ側でのヘッダー制御によって、オリジンサーバーに手を加えることなく多岐にわたる処理を柔軟に実現できます。

具体的には、レスポンスヘッダーポリシーを活用して、セキュリティヘッダー（例：Strict-Transport-SecurityやX-Content-Type-Options）を自動的に付与したり、CORS（Cross-Origin Resource Sharing）設定を行ったりすることが可能です。これにより、開発サイクルを短縮しつつ、Webアプリケーションのセキュリティレベルとユーザー体験を同時に向上させることが期待できます。また、オリジンサーバーの負荷軽減にも寄与し、スケーラビリティの高いアーキテクチャを構築する上で欠かせない要素となります。

CloudFront Functionsが拓くエッジでの高度な動的処理

CloudFront Functionsは、CloudFrontのエッジロケーションでJavaScriptベースの軽量な関数を直接実行できるサービスです。その最大の特長は、AWS公式ドキュメントによると1ms未満という極めて短い起動時間と、低コストで大量のリクエストを高速に処理できる点にあります。この特性から、レイテンシーが極めて重要な処理に特化しており、動的なヘッダー操作、リクエストURIの書き換え、シンプルな認証・認可ロジック、デバイス種別に応じたリダイレクトなど、特定のユースケースで非常に高いパフォーマンスを発揮します。

Functionsは、HTTPリクエストおよびレスポンスのヘッダーとクエリ文字列の操作に特化しています。例えば、リクエストヘッダーの値を条件にキャッシュ制御ヘッダーを動的に変更したり、特定のパスへのアクセスを認証トークンで制限したりといったことが可能です。複雑な処理やリクエストボディへのアクセスが必要な場合はLambda@Edgeが適していますが、Functionsはこれらの要件がない場合に、ユーザー体験を損なうことなく、きめ細やかなリクエスト処理を実現するための強力なツールとなります。

ヘッダーポリシーとFunctionsの連携による最適化戦略

CloudFrontにおけるヘッダー制御は、「レスポンスヘッダーポリシー」と「オリジンリクエストポリシー」、そして「CloudFront Functions」を組み合わせることで、より高度な最適化が可能です。レスポンスヘッダーポリシーは、オリジンからのレスポンスに対してCloudFrontが静的にヘッダーを付与・削除する設定で、主にセキュリティヘッダーの統一的な適用などに利用されます。一方、オリジンリクエストポリシーは、リクエストヘッダー（Hostヘッダー、カスタムヘッダーなど）をオリジンに転送するか否か、どのヘッダーをキャッシュキーとするかを制御し、キャッシュヒット率に直接影響します。

これらの固定ポリシーでは実現できない動的な判断や条件分岐に基づくヘッダー操作を可能にするのがCloudFront Functionsです。例えば、特定のリクエストパスやユーザーエージェントに応じて、異なるキャッシュ制御ヘッダーを付与するといった柔軟な処理が実現できます。Functionsは、Viewer Request（リクエストがオリジンに到達する前）やViewer Response（レスポンスがビューアーに返される前）のイベントで実行できるため、リクエストとレスポンスの両方で動的なヘッダー制御を行うことが可能です。これらを適切に組み合わせることで、キャッシュ効率と動的な処理を両立させた、堅牢かつ柔軟なコンテンツ配信基盤を構築できます。

出典：総務省「令和7年版 情報通信白書」、AWS「Amazon CloudFront デベロッパーガイド」

ヘッダー転送・追加・削除・書き換えの具体的な設定手順

レスポンスヘッダーポリシーでセキュリティとCORSを設定する

CloudFrontのレスポンスヘッダーポリシーは、オリジンサーバーからのレスポンスに対し、エッジ側でHTTPヘッダーを付与したり削除したりするための機能です。これにより、オリジンサーバーのコードを改修することなく、セキュリティ強化やCORS（Cross-Origin Resource Sharing）設定を効率的に行えます。設定手順としては、まずCloudFrontコンソールにアクセスし、「ポリシー」メニュー内の「レスポンスヘッダー」を選択して新しいポリシーを作成します。

ポリシー作成画面では、「セキュリティヘッダー」のセクションでStrict-Transport-Security、X-Content-Type-Options、X-Frame-Optionsなどのヘッダーを簡単に有効化できます。各ヘッダーの有効期限や値をニーズに合わせて設定してください。また、CORSが必要な場合は、「CORS」セクションでAccess-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Headersなどのヘッダーとその値を指定します。ポリシーを保存した後、対象のCloudFrontディストリビューションのビヘイビア設定を編集し、作成したレスポンスヘッダーポリシーをアタッチすることで、設定が適用されます。これにより、すべてのレスポンスに一貫したセキュリティヘッダーが付与され、Webアプリケーションの安全性が向上します。

オリジンリクエストポリシーによるキャッシュ動作の最適化

オリジンリクエストポリシーは、CloudFrontがオリジンサーバーにリクエストを転送する際に、どのリクエストヘッダー、クエリ文字列、クッキーを含めるかを制御する重要な設定です。この設定は、CloudFrontのキャッシュ動作、特にキャッシュヒット率に直接的な影響を与えるため、慎重な設計が求められます。キャッシュ効率を最大化しつつ、オリジンが必要とする情報を適切に伝達するためのバランスを見つけることが重要です。

設定のポイントは、どのヘッダーをキャッシュキーに含めるか、すなわち「キャッシュポリシー」と「オリジンリクエストポリシー」の整合性です。例えば、ユーザーごとに異なる値を持つヘッダー（セッションIDなど）をキャッシュキーに含めてしまうと、ユーザーごとに個別のキャッシュが生成され、キャッシュヒット率が大幅に低下する可能性があります。CloudFrontコンソールでオリジンリクエストポリシーを作成する際は、「HTTPヘッダー」「クエリ文字列」「Cookie」の各セクションで、オリジンに転送する必要がある項目のみを選択し、「キャッシュキーに含める」設定は必要最小限に絞り込みます。特にHostヘッダーの転送は、後述するオリジン側の問題を引き起こす可能性もあるため、その必要性を十分に検討した上で設定してください。

CloudFront Functionsで動的なヘッダー操作を実装する

CloudFront Functionsを使用することで、固定のポリシー設定では実現できない、条件に基づいた動的なヘッダー操作をエッジで実装できます。これは、特定のリクエストパスやクエリ文字列、またはユーザーエージェントなどの情報に基づいて、異なるヘッダーを追加、変更、削除したい場合に非常に有効です。FunctionsはJavaScript（制限付き環境）で記述され、高速に実行されるため、ユーザー体験を損なうことなくリアルタイムな処理が可能です。

具体的な実装手順としては、CloudFrontコンソールで「関数」メニューから新しい関数を作成し、JavaScriptコードを記述します。コード内では、event.request.headersオブジェクトやevent.response.headersオブジェクトを操作することで、リクエストまたはレスポンスのヘッダーを自由に操作できます。例えば、event.request.headers['x-custom-header'] = { value: 'my-value' };のようにヘッダーを追加したり、delete event.request.headers['cookie'];のようにヘッダーを削除したりできます。関数が完成したら、対象のCloudFrontディストリビューションのビヘイビア設定に移動し、「関数アソシエーション」で作成した関数を「ビューワーリクエスト」または「ビューワーレスポンス」イベントに紐付けます。これにより、エッジでの柔軟かつ高速な動的ヘッダー制御が実現し、よりパーソナライズされたコンテンツ配信が可能になります。

出典：AWS「Amazon CloudFront デベロッパーガイド」

Hostヘッダー制御やFunction利用による高度なリクエスト処理例

Hostヘッダーの転送とオリジンのマルチドメイン対応

Hostヘッダーは、クライアントがどのドメイン名を要求しているかを示すHTTPヘッダーであり、Webサーバーが複数のドメイン名を一つのIPアドレスでホストする、いわゆるバーチャルホスト環境で特に重要です。CloudFrontを利用する場合、デフォルトではCloudFrontのドメイン名（例：d1234.cloudfront.net）がオリジンに転送されることがあります。しかし、オリジンサーバーがexample.comのようなカスタムドメイン名でのHostヘッダーを期待している場合、元のHostヘッダーをオリジンに転送する必要があります。

この設定はCloudFrontのオリジンリクエストポリシーで行います。CloudFrontコンソールで新しいオリジンリクエストポリシーを作成し、「Hostヘッダー」を「含める」または「ホワイトリスト」に追加してオリジンに転送するよう設定します。これにより、オリジンサーバーはクライアントがどのドメインを要求しているかを正確に判断し、適切なコンテンツを提供できるようになります。ただし、HTTPS通信を利用するカスタムオリジンの場合、転送されたHostヘッダーとオリジンサーバーに設定されたSSL/TLS証明書のドメイン名が一致しないと、証明書検証エラー（SNI関連）が発生する可能性があります。この点については、オリジンサーバー側の証明書設定を事前に確認し、対応したドメイン名が含まれているかを検証することが不可欠です。

Functionsを用いた認証トークンの検証とリクエスト書き換え

CloudFront Functionsは、エッジで簡易的な認証ロジックを実装し、リクエストを動的に書き換える強力な手段を提供します。例えば、リクエストヘッダー（例：Authorizationヘッダー）やクエリ文字列に含まれる認証トークンを抽出し、その有効性をエッジで簡易的に検証する、といったユースケースが考えられます。FunctionsのJavaScriptコード内でトークンの形式や署名をチェックし、無効なトークンが検出された場合は、オリジンに到達する前にリクエストを特定のエラーページにリダイレクトしたり、ステータスコードを401 Unauthorizedに変更したりできます。

さらに、認証が成功した場合でも、セキュリティ上の理由から認証トークンを含むヘッダーを削除してからオリジンに転送する、といった処理も可能です。これにより、オリジンサーバーに到達する前に不正なリクエストをフィルタリングし、サーバー側の負荷を軽減しつつ、セキュリティを向上させることができます。Functionsは非常に高速に実行されるため、ユーザー体験に影響を与えることなくリアルタイムな認証処理を実現できる点が大きなメリットです。ただし、複雑な認証ロジックや外部の認証プロバイダーとの連携が必要な場合は、Functionsの機能制限（外部ネットワークアクセス不可など）を考慮し、より高機能なLambda@Edgeの利用を検討する方が適切かもしれません。

デバイス種別や地理情報に基づく動的なコンテンツ配信

CloudFront Functionsは、リクエストヘッダーの情報を活用してコンテンツ配信を動的に制御する際にも効果を発揮します。例えば、User-Agentヘッダーを解析して、リクエスト元のデバイスがスマートフォン、タブレット、PCのいずれであるかを判定し、それぞれに最適化されたコンテンツパスにリクエストを書き換えたり、デバイスに応じたリダイレクトヘッダーを付与したりすることが可能です。これにより、単一のCloudFrontディストリビューションで、異なるデバイスに最適なユーザー体験を提供できます。

また、CloudFrontはリクエスト元の地理情報をヘッダーとしてオリジンに転送する機能（例：CloudFront-Viewer-Country、CloudFront-Viewer-Cityなど）を提供しています。Functionsとこれらのヘッダーを組み合わせることで、特定の国からのアクセスをブロックしたり、地域に応じた言語のコンテンツに誘導したりする動的なルーティングも実装できます。例えば、日本のユーザーには日本語ページを、アメリカのユーザーには英語ページを自動的に表示させることが可能です。Functionsの実行はエッジで行われるため、オリジンサーバーの負荷を軽減し、ユーザーは常に最速でパーソナライズされたコンテンツにアクセスできるようになります。

出典：AWS「Amazon CloudFront デベロッパーガイド」

CloudFrontヘッダー設定で陥りやすい落とし穴と注意点

キャッシュヒット率を低下させるヘッダー転送の設定ミス

CloudFrontのヘッダー設定で最も注意すべき落とし穴の一つは、不必要に多くのリクエストヘッダーをオリジンに転送し、かつそれらをキャッシュキーに含めてしまうことです。これは特に、オリジンリクエストポリシーで「すべてのヘッダーを転送」を選択したり、キャッシュポリシーで「特定のカスタムヘッダーをキャッシュキーに含める」設定を行ったりした場合に発生しやすくなります。例えば、毎回異なるセッションIDや認証トークンを含むヘッダーをキャッシュキーに含めてしまうと、リクエストごとにユニークなキャッシュが生成されてしまい、キャッシュヒット率が大幅に低下する原因となります。

キャッシュヒット率の低下は、オリジンサーバーへの負荷増加やコンテンツ配信の遅延に直結し、CDN導入のメリットを大きく損ねてしまいます。この問題を避けるためには、キャッシュポリシーでキャッシュキーに含めるヘッダーを必要最小限に絞り込むことが重要です。具体的には、コンテンツのキャッシュに影響しないヘッダー（例：User-AgentやRefererなど）はキャッシュキーから除外し、オリジンリクエストポリシーでオリジンに転送する必要があるヘッダーのみを選択的に転送するように設定することが推奨されます。設定変更後は、必ず十分な検証を行い、キャッシュ動作が期待通りになっているかを確認してください。

Functionsの機能制限とLambda@Edgeとの使い分け

CloudFront Functionsは非常に高速で軽量なエッジコンピューティング環境ですが、その機能にはいくつかの重要な制限があります。最大の制限は、リクエストボディにアクセスできない点です。そのため、POSTリクエストのペイロードを解析して処理するといった操作には対応していません。また、Functionsは外部ネットワークへのアクセス（他のAWSサービスAPIや外部APIの呼び出しなど）や、ファイルシステムへのアクセスも許可されていません。さらに、実行時間やメモリの制約も厳しく、重い計算処理には向きません。

これらの制限を超えるような、より複雑な処理や、リクエストボディへのアクセスが必要な場合は、Lambda@Edgeの利用を検討する必要があります。Lambda@Edgeは、Functionsよりも起動時間は長いものの、Node.jsやPythonなどのランタイムを使い、より広範なAWSサービスとの連携、外部APIコール、リクエストボディへのアクセスが可能です。どちらのサービスを選択するかは、要件の複雑さ、許容されるレイテンシー、開発の容易さ、そしてコストを総合的に考慮して判断することが重要です。シンプルなヘッダー操作やURI書き換えにはFunctions、より高度なロジックや外部連携が必要な場合はLambda@Edgeという使い分けが一般的です。

Hostヘッダー転送によるHTTPSオリジンでのSNI問題

カスタムオリジンでHTTPS通信を利用している場合、Hostヘッダーの転送設定は特に注意が必要です。CloudFrontがオリジンにリクエストを転送する際、デフォルトではCloudFrontのドメイン名がHostヘッダーとしてオリジンに送られます。しかし、オリジンリクエストポリシーでクライアントから受け取った元のHostヘッダーを転送するように設定すると、オリジンサーバー側でSNI（Server Name Indication）に関連する問題が発生する可能性があります。

具体的には、オリジンサーバーに設定されたSSL/TLS証明書が、CloudFrontが転送したHostヘッダーのドメイン名（例：www.example.com）と一致しない場合に、証明書検証エラーとなり、コンテンツの取得に失敗する恐れがあります。これは、オリジンサーバーがそのHostヘッダーに対応する証明書を提示できないために起こります。この問題を避けるためには、オリジンサーバーの証明書が、CloudFrontが転送するHostヘッダーのドメイン名（エイリアスドメインなど）に対応しているか、またはワイルドカード証明書を使用しているかを確認することが不可欠です。適切な証明書設定が行われているか、事前に十分な検証を行うことが強く推奨されます。

出典：AWS「Amazon CloudFront デベロッパーガイド」

【ケース】Hostヘッダー不一致によるオリジンエラーを解決する

架空のケース：既存システム移行時のHostヘッダー問題

ここに架空のケースを紹介します。とある企業が、長年運用してきたオンプレミスのレガシーWebシステムをAWSのEC2インスタンスへ移行し、フロントエンドにCloudFrontを導入しました。移行後、Webサイト自体は正常に表示されるものの、一部の重要なAPIリクエストが403 Forbiddenや502 Bad Gatewayエラーとなる問題が発生しました。開発チームがエラーログを調査したところ、APIサーバーがリクエストのHostヘッダーを厳密に検証しており、想定されたドメイン名（例：api.legacy-app.com）と異なるHostヘッダーが送られてきた場合にエラーを返していることが判明しました。

この問題は、CloudFrontがオリジンにリクエストを転送する際に、デフォルト設定のままクライアントが指定した元のHostヘッダーではなく、CloudFront自体のドメイン名（例：d1234abcd.cloudfront.net）をHostヘッダーとして送っていたことが原因でした。APIサーバーは、受け取ったHostヘッダーが自身の想定するapi.legacy-app.comと一致しないため、不正なリクエストと判断してアクセスを拒否していたのです。これは、CloudFrontのデフォルト設定が、オリジンサーバーのバーチャルホスト設定やセキュリティポリシーと競合した典型的な事例と言えます。

解決策：オリジンリクエストポリシーでHostヘッダーを転送する

上記のHostヘッダー不一致によるオリジンエラーを解決するためには、CloudFrontの「オリジンリクエストポリシー」を適切に設定し、クライアントから受け取った元のHostヘッダーをオリジンに転送する必要があります。この設定により、APIサーバーは正しいHostヘッダーを受け取ることができ、エラーを解消できる可能性があります。

具体的な手順は以下の通りです。まず、AWSマネジメントコンソールでCloudFrontサービスにログインし、「ポリシー」メニュー内の「オリジンリクエスト」を選択して新しいポリシーを作成します。ポリシーの作成画面で、「HTTPヘッダー」セクションを展開し、「Host」を選択して「含める」設定にします。この新しいポリシーを保存した後、対象のCloudFrontディストリビューションのビヘイビア設定を編集します。APIリクエストが対象となるパス（例：/api/*）のビヘイビアに対し、先ほど作成したオリジンリクエストポリシーをアタッチします。これにより、クライアントがapi.legacy-app.comと指定したリクエストは、CloudFrontを経由してもHostヘッダーがapi.legacy-app.comのままオリジンに転送されるようになります。設定変更後は、必ずCloudFrontのキャッシュがクリアされるのを待つか、手動でキャッシュを無効化し、動作検証を実施してください。

改善後の検証と今後の注意点

オリジンリクエストポリシーの変更とCloudFrontのデプロイが完了したら、必ずAPIリクエストが正常に処理されるか、複数のエンドポイントや異なる環境から動作検証を実施します。ブラウザの開発者ツールやAPIクライアントツール（Postmanなど）を活用し、リクエストヘッダーが正しくオリジンに転送されていること、そして期待通りのレスポンス（200 OKなど）が得られていることを確認してください。特に、HTTPS通信を利用している場合は、Hostヘッダー転送によってオリジンサーバーのSSL/TLS証明書検証に問題が生じていないか（SNI問題）を入念にチェックすることが重要です。

今後の注意点として、新たなオリジンを追加したり、既存のオリジンの設定を変更したりする際には、そのオリジンがどのようなHostヘッダーを期待しているかを事前に確認する習慣をつけることが重要です。必要に応じてオリジンリクエストポリシーを調整し、Hostヘッダーの不一致によるエラーを未然に防ぎましょう。また、Hostヘッダーをキャッシュキーに含めることでキャッシュヒット率が低下する可能性もあるため、オリジンリクエストポリシーとキャッシュポリシーのバランスを常に意識し、転送するヘッダーは必要最小限に留めるよう心がけることが、CloudFrontを効率的に運用するための鍵となります。