Amazon CloudFrontに2019年12月から追加されていたアクセスログの7つの新フィールドについて確認してみた

はじめに

清水です。AWSが提供する高速・高パフォーマンスなコンテンツ配信サービス(CDN)であるAmazon CloudFront、少し前ですが2019年12月にアクセスログに7つの新たなフィールドを追加する機能アップデートがありました。（2019/12/12にポストされた内容です。）

• Amazon CloudFront now provides seven new data fields in access logs
• Amazon CloudFront がアクセスログに 7 つの新しいデータフィールドを提供

本エントリではこの、2019年12月にCloudFrontのアクセスログに新たに追加された7つのフィールドについてまとめてみます。なおこのアップデートについて、ユーザが個別に機能を有効にする必要はなく、自動的に適用されています。気がついたらCloudFrontアクセスログのフィールドが増えていた、という状況です。（実際はフォーラムにて告知がありましたし、CloudFront利用のユーザ宛にメールでの通知も行っていたかと思います。）ただし、7つの新フィールドはログファイルの各エントリの最後に追加されており、従来のログファイル形式との下位互換があるとのことです。

ちなみに、Amazon CloudFrontのアクセスログへの新フィールド追加、これがはじめてのことではありません。例えば2015年7月にも新フィールド追加のアップデートがあったことが、以下のDevelopers.IOのエントリでも確認できます。（このタイミングでx-forwarded-forなどが追加されていました。）

• 【新機能】Amazon CloudFrontのアクセスログに新フィールドが追加されました！ | Developers.IO

新しく追加された7つのフィールド

新しく追加された7つのフィールドについて、そのフィールド番号と簡単な内容をまとめます。詳細については、下記Amazon CloudFront 開発者ガイドの該当ページを参照ください。

• 「ウェブディストリビューションのログファイル形式 」 / アクセスログの設定および使用 - Amazon CloudFront

フィールド番号27 「c-port」

閲覧者（クライアント）からのリクエストのポート番号です。基本的にはエフェメラルポートになるかと思います。

フィールド番号28 「time-to-first-byte」

サーバー上で測定される、リクエストを受信してから応答の最初のバイトを書き込むまでの秒数です。小数点表記で1秒以下に対応しています。

フィールド番号29 「x-edge-detailed-result-type」

フィールド番号14のx-edge-result-typeがErrorの場合、このフィールドにエラーの詳細が入ります。例えば、CloudFrontがオリジンのドメイン名を解決できなかった、などです。これらに該当したエラーメッセージが記されます。詳細は開発者ガイドを参照ください。フィールド番号14のx-edge-result-typeがErrorでない場合、このフィールドにはx-edge-result-typeと同じ値が入ります。

フィールド番号30 「sc-content-type」

レスポンスのHTTP Content-Typeヘッダの値が入ります。例えばtext/htmlなどです。

フィールド番号31 「sc-content-len」

レスポンスのHTTP Content-Lengthヘッダの値が入ります。

フィールド番号32 「sc-range-start」

レスポンスにHTTP Content-Rangeヘッダが含まれている場合、範囲の開始値が入ります。Content-Rangeヘッダが含まれない場合はハイフン（-）です。

フィールド番号33 「sc-range-end」

レスポンスにHTTP Content-Rangeヘッダが含まれている場合、範囲の終了値が入ります。Content-Rangeヘッダが含まれない場合はハイフン（-）です。

実際のアクセスログで7つのフィールドを確認してみた

実際にこの7つの新フィールドが追加されたCloudFrontのアクセスログを確認してみたいと思います。以下が実際のアクセスログです、わかりやすそうなものを2行、抜粋してみました。

2020-04-30      00:39:44        NRT57-C4        32183   XXX.XXX.XXX.XXX    GET     d1234567890.cloudfront.net    /mp4/bbb.mp4    206     https://www.example.com/mp4/bbb.mp4     Mozilla/5.0%20(Macintosh;%20Intel%20Mac%20OS%20X%2010_14_6)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/81.0.4044.122%20Safari/537.36        -       _ga=GA1.2.108710XXXX.155626XXXX Miss    -08m1Vzuuzh4Loa2JgngL5dha0Un1rKCGaOyurTRShT8ziXXXXXXXX== www.example.com https   77      0.011   -       TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256     Miss    HTTP/2.0        -       -       6586    0.006   Miss    video/mp431779   276103168       276134946
2020-04-30      01:00:45        NRT57-C4        1276    XXX.XXX.XXX.XXX    GET     d1234567890.cloudfront.net    /mp4/bbb.mp4    502     https://www.example.com/mp4/    Mozilla/5.0%20(Macintosh;%20Intel%20Mac%20OS%20X%2010_14_6)%20AppleWebKit/537.36%20(KHTML,%20like%20Gecko)%20Chrome/81.0.4044.122%20Safari/537.36        -       _ga=GA1.2.108710XXXX.155626XXXX Error   tepY34TbHmHQqlpV4b0lEh-iJ_WY184SCtSa0-2WHpw9ZXXXXXXXXX== www.example.com https   42      0.012   -       TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256     Error   HTTP/2.0        -       -       51641   0.012   OriginConnectError      text/html        1033    -       -

横に長いので、awkコマンドで7つの追加されたフィールドだけを抜粋してみます。

$ awk -F " " '{print $27, $28, $29, $30, $31, $32, $33}' cloudfront-logfile.txt
6586 0.006 Miss video/mp431779 276103168 276134946
51641 0.012 OriginConnectError text/html 1033 - -

アクセスログ発生時の状況ですが、mp4ファイル（Big Bug BUNNY）をApache httpdにホストさせ、キャッシュさせない設定のCloudFront経由でアクセスしました。ブラウザはChromeを使用しています。Chromeでmp4ファイルを直接開くと、Partial Request（部分リクエスト）を行いファイル全体を一度に取得するのではなく、一部分のみ取得が行われます。

デベロッパーツールで確認すると、ちょうど以下のタイミングです。

ここで先ほどのログファイルの1行目を振り返ってみると、フィールド番号30にはContent-Typeのvideo/mp4、フィールド番号31にはContent-Lengthヘッダーの値が、またフィールド番号32、33のContent-Rangeが含まれている場合の開始終了範囲も確認できます。

続いてログファイル2行目ですが、こちらはあえてCloudFrontのオリジンとなるApache httpdのサービスを停止させてみました。Webブラウザ側にはCloudFrontのレスポンスとして「502 ERROR」が表示されたのですが、新しく追加されたフィールドのひとつ、フィールド番号29には「OriginConnectError」ということで、CloudFrontにオリジンが接続できなかった旨が記載されています。

まとめ

Amazon CloudFrontのアクセスログファイルに2019年12月に新しく追加された7つのフィールドについて確認してみました。個人的に、特に印象的なのはフィールド番号29の「x-edge-detailed-result-type」でした。エラー発生時の問題解決に役立ちそうです。またフィールド番号32と33はPartial Requestの際の確認に有益ではないでしょうか。

また繰り返しになりますが、7つの新フィールドはログファイルの各エントリの末尾に追加されており、下位互換をとっています。既存の処理系で新フィールドは意識せずとも引き続き動作するかと思いますが、これを契機に新フィールドについても解析してみてはいかがでしょうか。例えばAmazon AthenaでAmazon CloudFrontのログをクエリする場合でも、テーブル作成の例が新フィールドを含めたものに更新されています。（2019/12/14には更新されていたようです。）

• Amazon CloudFront ログのクエリ - Amazon Athena