CloudFront の標準アクセスログを活用する場面

本記事では、私が過去に CloudFront の標準アクセスログを参照した場面について記載します。
誰かの参考になりましたら幸いです。
CloudFront のアクセスログは以下のフィールドを出力します。

公開している WEB サイトでエラーが出て、問い合わせを受けたとき

公開している WEB サイトからエラーが出ているとき、出た後に、ユーザーからの問い合わせやシステム通知を受けて、調査を行うときに参照します。
該当時間のログファイルを S3 バケットからダウンロードします。ログファイルの名前やファイル内に記録されている時間は UTC 時間なので、注意してダウンロード・確認します。
CloudFront はエンドユーザーから直接リクエストを受ける構成になっていることが多いため、接続元クライアントの IP アドレスやデバイス、OS、ブラウザなどを特定できることが多いです。
CloudFront のバックエンドが ELB になっているような場合、ELB アクセスログの接続元 IP アドレスは CloudFront になっていることが多いです。その場合、ELB アクセスログの user_agent 列が「Amazon CloudFront」になっています。問題がそこで起きているときには、CloudFront 側のログを見ると良いかもしれません。

CloudFront のアクセスログから問題の原因を特定したあとの対応としては、CloudFront に付与している WAF (AWS WAF など)の設定を変更して、攻撃リクエストを拒否するようにしたり、WEBサーバー側の設定を変更することが多いです。(経験上。特定の IP アドレスやヘッダからのリクエストを拒否するようなルールを入れて、改善されるかみるetc)

以下のフィールドを参照し、攻撃の傾向を掴むために CloudFront のログを活用します。

どこから：c-ip (接続元クライアントの IP アドレス) を参照し、「特定の IP アドレスからのリクエストが多くないか？」を確認します。また、cs(User-Agent)を参照し、接続元のデバイスやOS、ブラウザを確認します。プログラムの場合は User-Agent が curl 等のコマンドになっていたりします。
どこに：cs-uri-stem (接続先パス)や、cs-uri-query (クエリ文字列) を参照し、公開しているサーバーのどこに接続しようとしているのかを確認します。cs-method (受信したHTTPメソッド) を参照し、どのようなメソッドなのか確認します。
エラーコード：sc-status を確認し、ステータスコードを確認します。

5． c-ip

リクエスト元のビューワーの IP アドレス (192.0.2.183 または 2001:0db8:85a3::8a2e:0370:7334 など)。ビューワーが HTTP プロキシまたはロードバランサーを使用してリクエストを送った場合、このフィールドの値はプロキシまたはロードバランサーの IP アドレスです。x-forwarded-for フィールドも参照してください。

6． cs-method

ビューワーから受信した HTTP リクエストメソッド。

7． cs(Host)

CloudFront ディストリビューションのドメイン名 (d111111abcdef8.cloudfront.net など)。

8． cs-uri-stem

パスとオブジェクトを識別するリクエスト URL の部分 (/images/cat.jpg など)。URL 内の疑問符 (?) およびクエリ文字列はログに含まれません。

9． sc-status

次のいずれかの値が含まれます。サーバーのレスポンスの HTTP ステータスコード (例: 200)。 000。この値は、サーバーがリクエストに応答する前に、ビューワーが接続を閉じたことを示します。サーバーがレスポンスの送信を開始した後にビューワーが接続を閉じた場合、このフィールドには、サーバーが送信を開始したレスポンスの HTTP ステータスコードが含まれます。

10． cs(Referer)

リクエスト内の Referer ヘッダーの値。これはリクエスト元のドメインの名前です。一般的なリファラーとして、検索エンジン、オブジェクトに直接リンクされた他のウェブサイト、ユーザー自身のウェブサイトなどがあります。

11． cs(User-Agent)

リクエスト内の User-Agent ヘッダーの値。User-Agent ヘッダーでリクエスト元 (リクエスト元のデバイスとブラウザのタイプなど) が識別されます。リクエスト元が検索エンジンの場合は、どの検索エンジンかも識別されます。

12． cs-uri-query リクエスト URL のクエリ文字列の部分 (ある場合)。

特定のエッジロケーションで障害が起きている可能性がある場合には、x-edge-location ヘッダも参考にします。この場合には AWS サポートに「エッジロケーション XXX に障害が起きていないか」を確認するくらいしかできることがありません。

3.　x-edge-location

リクエストを処理したエッジロケーション。各エッジロケーションは、3 文字コードと、割り当てられた任意の数字で識別されます (例: DFW3)。通常、この 3 文字コードは、エッジロケーションの地理的場所の近くにある空港の、国際航空運送協会 (IATA) の空港コードに対応します。(これらの略語は今後変更される可能性があります)。

キャッシュヒットしたかを確認したいとき

ログ内の他の列の値と合わせて、リクエストを受けたオブジェクトがキャッシュにヒットしたのか、そうでないのかも確認できます。

14．x-edge-result-type

サーバーが、最後のバイトを渡した後で、レスポンスを分類した方法。場合によっては、サーバーがレスポンスを送る準備ができたときから、サーバーがレスポンスを送り終わるまでの間に、結果タイプが変わることがあります。x-edge-response-result-type フィールドも参照してください。例えば、HTTP ストリーミングで、サーバーがキャッシュ内でストリームのセグメントを検出するとします。そのシナリオでは、このフィールドの値は、通常 Hit になります。この場合、サーバーがセグメント全体を配信する前にビューワーが接続を閉じると、最終結果タイプ (およびこのフィールドの値) は Error になります。 WebSocket 接続の場合、コンテンツがキャッシュ可能ではなく、オリジンに直接プロキシされるため、このフィールドの値は Miss になります。以下に示しているのは、可能な値です。

Hit – サーバーがキャッシュからビューワーにオブジェクトを渡しました。

RefreshHit – サーバーはキャッシュ内でオブジェクトを検出しましたが、オブジェクトの有効期限が切れていたため、サーバーはオリジンに問い合わせて、キャッシュ内に最新バージョンのオブジェクトがあるかどうかを確認しました。

Miss – キャッシュ内のオブジェクトでリクエストに対応できなかったため、サーバーはリクエストをオリジンに転送して結果をビューワーに返しました。

LimitExceeded – CloudFront クォータ (以前は制限と呼ばれていました) を超えたため、リクエストは拒否されました。

CapacityExceeded – リクエストの受信時にサーバーの容量不足でオブジェクトを渡すことができなかったために、サーバーから HTTP 503 ステータスコードが返されました。

Error – 通常、これはリクエストがクライアントエラーとなった (sc-status フィールドが 4xx 範囲内の値となる)、またはサーバーエラーになった (sc-status フィールドが 5xx 範囲内の値となる) ことを意味します。sc-status フィールドの値が 200 であるか、このフィールドの値が Error で、x-edge-response-result-type フィールドの値が Error でない場合は、HTTP リクエストは成功したが、クライアントがすべてのバイトを受信する前に切断されたことを意味します。

Redirect – サーバーは、ディストリビューション設定に従って HTTP から HTTPS にビューワーをリダイレクトしました。

なお、キャッシュヒット率を算出する場合には、「キャッシュ統計」画面から CSV をダウンロードしてみるのもいいです。
Hit件数、Miss件数など数字で確認できます。