ログ・可観測性ツール
CloudFront標準アクセスログまたはALBアクセスログを貼り付けると形式を自動判定（手動選択も可能）し、「ログを解析」をクリックすると絞り込み可能な表になります。
すべてブラウザ内で処理され、ログの内容がアップロードされることはなく、AWSアカウントも不要です。
ログを解析すると、ここに表が表示されます。
CloudFrontとALBはAWSで最もよく使われる2種類のアクセスログですが、どちらも人間の目でそのまま読むには向いていません。CloudFrontのフィールドはログ有効化時に選んだ列構成やバージョンによって変わり、ALBは1行に30個以上のスペース区切りの値を詰め込み、その一部はダブルクォートで囲まれています。CloudFrontログ解析、ALBアクセスログ解析、ロードバランサーログ解析、あるいはELBログ 解析と呼び方は人それぞれですが、このAWSログ解析ツールは、サポートチケットやS3、CloudWatchのエクスポートからコピーしてきたログの断片を手元に置いて、どのエッジロケーションがリクエストを処理したのか、どのターゲットが502を返したのか、どのクライアントIPが特定のパスに集中アクセスしているのかを、Athenaのクエリを組まずに確認したいときのためのものです。
数百から数千行程度の一時的な調査に向いており、常設の分析パイプラインの代わりではありません。すべての処理はブラウザのタブ内で完結し、ログの内容がアップロードされることはなく、AWSアカウントやS3へのアクセス権限も不要です。
2つのAWS形式がそれぞれ自分のフィールドをどう宣言しているかに合わせて設計しています。
CloudFront標準ログは先頭に#Versionと#Fieldsの2行があり、各列の名前が順番に書かれています。このツールは固定のレイアウトを仮定するのではなく、この2行をそのまま読み取ります。AWSが将来フィールドを追加しても表は自動的に広がり、このツールの更新もバージョンの選択も必要ありません。
CloudFrontではキャッシュ結果（Hit、Miss、RefreshHit、Error）の内訳とTop edge locationを表示します。CDNの挙動がおかしいときに実際に確認する2点です。ALBでは実行されたアクションの内訳に加え、ロードバランサーのステータスコードとターゲットのステータスコードが一致しないリクエスト数を表示します。バックエンドの不調に気づく最初の兆候になることが多い数値です。
解析、絞り込み、書き出しの3ステップです。
CloudFront標準ログまたはALBアクセスログを貼り付けます。自動判定は最初の空でない行だけを見ます。#Version:で始まればCloudFront、最初の単語がhttp/https/h2/grpcs/ws/wssのいずれかならALBと判定します。どちらにも一致しない場合（例えばヘッダーなしのデータ行だけを貼り付けた場合）は、推測せずにドロップダウンから手動で選んでください。
入力中に自動で解析は走りません。これらのログはしばしば数千行にのぼり、1行あたりのフィールドが30を超えることもあるため、キー入力のたびに再マッチングするのは無駄です。「ログを解析」を1回クリックするか、ショートカットキーを使うと表が埋まります。
ステータスコード、パス、クライアントIP、そして（CloudFrontの場合は）edge locationの4つの絞り込みは、解析済みの行に対して即座に反映され、「ログを解析」を再度クリックする必要はありません。表の下の集計パネルも絞り込みに連動して更新され、キャッシュ結果や実行アクションの内訳、現在表示されている範囲の合計バイト数・平均/最大レイテンシーが表示されます。表示中の行はCSV、JSON、プレーンテキストとして書き出せます。
実際のAWSアクセスログのトラブルシューティング向けに作られた、フィールドマッピング・4つの絞り込み・形式別の統計。
列名はログ自身の#Fields行からそのまま取得されるため、表は常に貼り付けたログの実際のバージョン（ログ有効化時に選んだ独自のフィールド構成を含む）と一致します。
ALBにはヘッダー行がありませんが、AWSの公式ドキュメントには新しいフィールドは常に末尾に追加されると明記されています。このツールは既知の完全なフィールド一覧に対して各行のトークンを位置ベースでマッピングし、実際に一致した既知フィールド数を報告するため、末尾のフィールドが少ない古いログでもエラーにならずきれいに解析できます。
ステータスコードの範囲または完全一致、パスの部分一致または正規表現、クライアントIPの部分一致、そして（CloudFrontのみ）edge locationの部分一致で表を絞り込めます。いずれもログの再解析は不要です。
CloudFrontの行はx-edge-result-type（Hit、Miss、RefreshHit、Errorなど）で集計され、ALBの行はカンマ区切りのactions_executedの値で集計されます。さらにELBとターゲットのステータスコードが一致しないリクエスト数も表示します。
検出された形式と列数が一致しない行は、1始まりの行番号と元のテキストとともに一覧表示されるため、数行の異常なデータが件数から静かに消えることはありません。
現在絞り込まれて表示されている行だけを、表と同じ列構成で書き出せます。そのままスプレッドシートや他のツールに取り込めます。
フィールド判定・不正行の扱い・対応範囲の境界についての、当面変わらない具体的な仕様です。
CloudFrontやALBのアクセスログをオンラインで解析する前に、よく聞かれる質問です。
ALBにはヘッダー行がないため、このツールはAWSの公式ドキュメントに記載されたフィールド順序（type、time、elb、client:portから始まり、より新しいclassificationやip_addressまで）に沿って、各行のスペース区切りトークンを位置ベースで対応付けます。ALBを選択するか自動判定に任せて貼り付ければ、この対応関係は自動的に適用されます。
ログ有効化時の設定やバージョンによって変わるため、このツールはログ自身の#Fields行からフィールド名を読み取り、固定リストを仮定しません。ログを貼り付ければ、表の列見出しはそのログの実際のバージョンにおける本物のフィールド名になります。dateやc-ipから、fle-statusやsc-range-startのようなあまり見ないフィールドまで表示されます。
ステータスコードでELBとターゲットの値を比較し、一致しない件数を確認するのが手がかりになります。このツールはELBステータスコードとターゲットステータスコードが一致しないリクエストの件数を集計パネルに表示するので、ロードバランサー側の問題なのかターゲット側の問題なのかを切り分けやすくなります。
このツールは2つのログを自動的に結合しません。それぞれを個別に解析します。手動で突き合わせるために必要なフィールドは提供していて、CloudFront側のx-edge-request-idとx-forwarded-for、ALB側のtrace_idです。AWSのドキュメントでも、この値を両方のホップにまたがって関連付けに使うとされています。
CloudFrontを前段に置く構成では、ALBから見たクライアントはCloudFrontのエッジ側のIPになります。このツールはALBのclient:portフィールドをそのまま列として表示し、ポート番号を除いたIP部分でのクライアントIP絞り込みにも対応しているので、想定通りの値かどうかをその場で確認できます。
できます。貼り付けたテキストはどこにも送信されません。解析・絞り込み・書き出しはすべてブラウザタブ内のJavaScriptで完結し、サーバー側へのアップロードや保存、記録は一切なく、AWSアカウントやS3へのアクセス権限も求められません。
対応していません。このツールが読み取るのは従来の、タブ区切りのテキストログ形式（legacy形式、およびStandard Logging v2でのw3c出力オプション）だけです。Parquetはバイナリの列指向形式で、テキストとして貼り付けても意味のある解析ができないため、ブラウザ完結型のテキスト解析ツールとしては対象外にしています。
実際のログ行でこのツールがうまく解析できなかった？
CloudFront標準ログまたはALBアクセスログを貼り付けるだけで、数秒で絞り込み・書き出し可能な表が手に入ります。S3への接続もAWS認証情報もアップロードも不要です。
キャッシュヒット率を確認したいとき、特定のパスに集中アクセスしているクライアントを探したいとき、ターゲットグループが誤ったステータスコードを返している理由を調べたいときのために、このAWSログ解析ツールをブックマークしておいてください。
解析はすべてブラウザ内でローカルに行われます。