AWSのCDN（cloudfront）を使用すると、cloudfront前後でHTTPヘッダーが書換えられたり（変化）・追加されたりします。
ALB経由時でHTTPヘッダーの変化確認方法と同様に、cloudfront前後で具体的にどういう変化が起きているのか検証し確認していましました。
レジュメ
環境・前提条件
User → Cloudfront → EC2
- AWS cloudfront
- ALBのバックエンドにEC2(Linux+apache+php)サーバーを構築しHTTPヘッダーを出力するページ（test.php）用意
- User側のブラウザツールとしてPostmanを使用
環境を作り、cloudfront前後でHTTPヘッダーがどう変化・付与されるか確認してみました。
結論、Cloudfrontを経由するとHTTPリクエストヘッダーに追加されるヘッダー一覧
- HTTP Request（※普通はしないけど不正チェックしていました）
- X-Amz-Cf-Id (追加)
- Via (追加)
- X-Forwarded-For (追加)
- Upgrade-Insecure-Requests (追加)
- CloudFront-Is-Mobile-Viewer (追加)
- CloudFront-Is-Tablet-Viewer (追加)
- CloudFront-Is-SmartTV-Viewer (追加)
- CloudFront-Is-Desktop-Viewer (追加)
- CloudFront-Viewer-Country (追加)
- CloudFront-Forwarded-Proto (追加)
※通常はこんな事をする人はいないと思いますが、HTTP Requestの書き換え・チェックを確認するために、cloudfrontをブラウザのProxy設定として設定し、HTTP Requestをカスタマイズしてリクエストしてみました。
HTTP Request以外は、cloudfrontを経由するとこで通常付与されるヘッダー情報になります。
以下、今回の結論を導いた検証結果情報になります。
Cloudfront前のHTTPリクエストヘッダー
Cloudfront前のリクエストヘッダーをまともに調査しようとすると、UserとCloudfrontの間にパケットキャプチャーを仕掛けなければならなくなるので、近しくなる情報としまして、まず「Userが直接EC2に接続しに行った場合のHTTPリクエストヘッダー」を調査しました。
Userが以下の設定でcloudfrontにアクセスしに行ったときの、EC2が受け取ったHTTPリクエストヘッダーの出力に相当します。
EC2側の出力としましては、
HTTP Request Headers
| HTTP Request | GET /test.php HTTP/1.1 |
| User-Agent | PostmanRuntime/7.26.5 |
| Accept | */* |
| Cache-Control | no-cache |
| Postman-Token | cccb6f74-a896-4cdd-a761-1664b3e5eb3f |
| Host | ec2-***.ap-northeast-1.compute.amazonaws.com |
| Accept-Encoding | gzip, deflate, br |
| Connection | keep-alive |
HTTP Response Headers
| Upgrade | h2,h2c |
| Connection | Upgrade |
| X-Powered-By | PHP/5.4.16 |
実際に、Userが以下の設定でcloudfrontにアクセスしに行った場合のHTTPレスポンスヘッダーには、もっとヘッダー情報が追加されます。キャッシュヒットしたかキャッシュミスしたかの情報がわかる「x-cache」ヘッダーもあります。
追加されるHTTPレスポンスヘッダーについて詳しくは以下のリンクを参照してください。
Cloudfront後のHTTPリクエストヘッダー
こちらは、実際にCloudfrontからEC2が受け取ったHTTPリクエストヘッダーです。
Userが以下の設定でCloudfrontにアクセスしに行ったときの、EC2が受け取ったHTTPリクエストヘッダーの出力です。
EC2側の出力としましては、
HTTP Request Headers
※下の表は、画像のデータとは異なり、chimeでつなげた場合のHTTPリクエストヘッダーになります。異なる情報ですみません。
| HTTP Request | GET /test.php HTTP/1.1 |
| Host | cf.****.*** |
| User-Agent | Mozilla/5.0 (Windows NT 10.0; Win64; x64) |
| X-Amz-Cf-Id | Zshae0Mv***** |
| Connection | Keep-Alive |
| Via | 1.1 06f682****.cloudfront.net (CloudFront) |
| X-Forwarded-For | 18*.**.**.** |
| Accept-Language | ja |
| Accept | text/html,application/xhtml+xml,application/xml;q=0.9 |
| Accept-Encoding | gzip, deflate |
| Upgrade-Insecure-Requests | 1 |
| CloudFront-Is-Mobile-Viewer | false |
| CloudFront-Is-Tablet-Viewer | false |
| CloudFront-Is-SmartTV-Viewer | false |
| CloudFront-Is-Desktop-Viewer | true |
| CloudFront-Viewer-Country | JP |
| CloudFront-Forwarded-Proto | http |
HTTP Response Headers
| Upgrade | h2,h2c |
| Connection | Upgrade |
| X-Powered-By | PHP/5.4.16 |
HTTP Requestヘッダーテスト。イレギュラー的にProxyとしてcloudfront URL設定した場合
ALBはProxyサーバーのロードバランサーとして機能するかどうか確認した時と同様に、イレギュラーなHTTP Requestヘッダーをcloudfrontが受け付けた時の挙動を確認しました。
■ パターン１
- UserのProxy設定に「cloudfront DNS名」を設定
- UserのURL Requestは「適当なURLのhttp://a.b.c/test.php」
cloudfrontの出力画面としましては、エラーとなりました。
■ パターン２
- UserのProxy設定に「cloudfront DNS名」を設定
- UserのURL Requestは「URLのhttp://<cloudfront DNS名>/test.php」
cloudfrontの出力画面としましては、正常となりました。
つまり、cloudfrontはHTTP Requestヘッダーをチェックしています。