Application Load Balancer のアクセスログ
Elastic Load Balancing は、ロードバランサーに送信されるリクエストについての詳細情報をキャプチャしたアクセスログを提供します。各ログには、リクエストを受け取った時刻、クライアントの IP アドレス、レイテンシー、リクエストのパス、サーバーレスポンスなどの情報が含まれます。これらのアクセスログを使用して、トラフィックパターンを分析し、問題のトラブルシューティングを行うことができます。
アクセスログの作成は、Elastic Load Balancing のオプション機能であり、デフォルトでは無効化されています。ロードバランサーのアクセスログの作成を有効にすると、Elastic Load Balancing はログをキャプチャし、圧縮ファイルとして指定した Amazon S3 バケット内に保存します。アクセスログの作成はいつでも無効にできます。
アクセスログに対する追加料金はありません。Amazon S3 のストレージコストは発生しますが、Amazon S3 にログファイルを送信するために Elastic Load Balancing が使用する帯域については料金は発生しません。ストレージコストの詳細については、Amazon S3 の料金
アクセスログファイル
Elastic Load Balancing は各ロードバランサーノードのログファイルを 5 分ごとに発行します。ログ配信には結果整合性があります。ロードバランサーでは、同じ期間について複数のログが発行されることがあります。これは通常、サイトに高トラフィックがある場合に発生します。
アクセスログのファイル名には次の形式を使用します。
bucket
[/prefix
]/AWSLogs/aws-account-id
/elasticloadbalancing/region
/yyyy
/mm
/dd
/aws-account-id
_elasticloadbalancing_region
_app.load-balancer-id
_end-time
_ip-address
_random-string
.log.gz
- bucket
-
S3 バケットの名前。
- prefix (プレフィックス)
-
バケットのプレフィックス (論理階層)。プレフィックスを指定しない場合、ログはバケットのルートレベルに配置されます。
- aws-account-id
-
所有者の AWS アカウント ID。
- region
-
ロードバランサーおよび S3 バケットのリージョン。
- yyyy/mm/dd
-
ログが配信された日付。
- load-balancer-id
-
ロードバランサーのリソース ID。リソース ID にスラッシュ (/) が含まれている場合、ピリオド (.) に置換されます。
- end-time
-
ログ作成の間隔が終了した日時。たとえば、終了時間 20140215T2340Z には、UTC または Zulu 時間の 23:35~23:40 に行われたリクエストのエントリが含まれます。
- ip-address
-
リクエストを処理したロードバランサーノードの IP アドレス。内部ロードバランサーの場合、プライベート IP アドレスです。
- random-string
-
システムによって生成されたランダム文字列。
ログファイル名の例は次のようになります。
s3://my-bucket/prefix/AWSLogs/123456789012/elasticloadbalancing/us-east-2/2016/05/01/123456789012_elasticloadbalancing_us-east-2_net.app.my-loadbalancer.1234567890abcdef_20140215T2340Z_172.160.001.192_20sg8hgm.log.gz
必要な場合はログファイルを自身のバケットに保管できますが、ログファイルを自動的にアーカイブまたは削除するにように Amazon S3 ライフサイクルルールを定義することもできます。詳細については、Amazon Simple Storage Service ユーザーガイドの「オブジェクトのライフサイクルの管理」を参照してください。
アクセスログのエントリ
Elastic Load Balancing は、ターゲットに到達しなかったリクエストを含め、ロードバランサーに送信されたリクエストを記録します。たとえば、クライアントが誤った形式のリクエストを送信した場合や、リクエストに応答できる正常に動作しているターゲットがない場合も、そのリクエストは記録されます。Elastic Load Balancing はヘルスチェックリクエストをログに記録しません。
各ログエントリには、ロードバランサーに対して行われた 1 つのリクエスト (または WebSocket の場合は接続) の詳細が含まれます。WebSocket の場合、エントリは接続を閉じた後にのみ書き込まれます。アップグレードされた接続を確立できない場合、エントリは HTTP または HTTPS リクエストと同じです。
Elastic Load Balancing はベストエフォートベースでリクエストを記録します アクセスログは、すべてのリクエストを完全に報告するためのものではなく、リクエストの本質を把握するものとして使用することをお勧めします。
[Syntax] (構文)
次の表は、アクセスログのエントリのフィールドを順に示しています。すべてのフィールドはスペースで区切られています。新しいフィールドが導入されると、ログエントリの最後に追加されます。予期していなかったログエントリの最後のフィールドは無視する必要があります。
フィールド | 説明 |
---|---|
type |
リクエストまたは接続のタイプ。有効な値は次のとおりです (その他の値は無視してください)。
|
time |
ロードバランサーがクライアントに対してレスポンスを生成した時刻 (ISO 8601 形式)。WebSocket の場合、これは接続を閉じる時間です。 |
elb |
ロードバランサーのリソース ID。アクセスログエントリを解析する場合、リソース ID にはスラッシュ (/) を含めることができます。 |
client:port |
リクエストを送信したクライアントの IP アドレスとポート。 |
target:port |
このリクエストを処理したターゲットの IP アドレスとポート。 クライアントがリクエスト全体を送信しなかった場合、ロードバランサーはターゲットにリクエストをディスパッチできず、この値が - に設定されます。 ターゲットが Lambda 関数の場合、この値は - に設定されます。 リクエストが AWS WAF によってブロックされた場合、この値は - に設定され、elb_status_code の値は 403 に設定されます。 |
request_processing_time |
ロードバランサーがリクエストを受け取った時点からターゲットにリクエストを送信するまでの合計経過時間 (ミリ秒精度の秒単位)。 ロードバランサーがリクエストをターゲットにディスパッチできない場合、この値は -1 に設定されます。この状況が発生するのは、ターゲットがアイドルタイムアウト前に接続を閉じた場合か、クライアントが誤った形式のリクエストを送信した場合です。 登録済みターゲットからアイドルタイムアウトまで応答がない場合にも、この値は -1 に設定される場合があります。 |
target_processing_time |
ロードバランサーがターゲットにリクエストを送信した時点から、そのターゲットが応答ヘッダーの送信を開始した時点までの合計経過時間 (ミリ秒精度の秒単位)。 ロードバランサーがリクエストをターゲットにディスパッチできない場合、この値は -1 に設定されます。この状況が発生するのは、ターゲットがアイドルタイムアウト前に接続を閉じた場合か、クライアントが誤った形式のリクエストを送信した場合です。 登録済みターゲットからアイドルタイムアウトまで応答がない場合にも、この値は -1 に設定される場合があります。 |
response_processing_time |
ロードバランサーがターゲットから応答ヘッダーを受け取った時点から、クライアントへの応答の送信を開始した時点までの合計経過時間 (ミリ秒精度の秒単位)。これには、ロードバランサーでの待機時間と、ロードバランサーからクライアントへの接続の取得時間の両方が含まれます。 ロードバランサーがリクエストをターゲットに送信できない場合、この値は -1 に設定されます。この状況が発生するのは、ターゲットがアイドルタイムアウト前に接続を閉じた場合か、クライアントが誤った形式のリクエストを送信した場合です。 |
elb_status_code |
ロードバランサーからの応答のステータスコード。 |
target_status_code |
ターゲットから応答のステータスコード。この値は、ターゲットへの接続が確立され、ターゲットが応答を送信した場合のみ記録されます。それ以外の場合は、- に設定されます。 |
received_bytes |
クライアント (リクエスタ) から受け取ったリクエストのサイズ (バイト単位)。HTTP リクエストの場合、これにはヘッダーが含まれます。WebSocket の場合、これは接続でクライアントから受信した合計バイト数です。 |
sent_bytes |
クライアント (リクエスタ) に返される応答のサイズ (バイト単位)。HTTP リクエストの場合、これにはヘッダーが含まれます。WebSocket の場合、これは接続でクライアントに送信した合計バイト数です。 |
"request" |
クライアントからのリクエスト行は二重引用符で囲まれており、次の形式を使用してログに記録されます。HTTP メソッド + プロトコル://ホスト:ポート/uri + HTTP バージョン。ロードバランサーは、リクエスト URI を記録するときに、クライアントから送信された URL をそのまま保持します。アクセスログファイルのコンテンツタイプは設定されません。このフィールドを処理するときは、クライアントが URL を送信した方法を考慮してください。 |
"user_agent" |
リクエスト元のクライアントを特定する User-Agent 文字列 (二重引用符で囲まれます)。この文字列は、1 つ以上の製品 ID (製品[/バージョン]) から構成されます。文字列が 8 KB より長い場合は切り捨てられます。 |
ssl_cipher |
[HTTPS リスナー] SSL 暗号。リスナーが HTTPS リスナーではない場合、この値は - に設定されます。 |
ssl_protocol |
[HTTPS リスナー] SSL プロトコル。リスナーが HTTPS リスナーではない場合、この値は - に設定されます。 |
target_group_arn |
ターゲットグループの Amazon リソースネーム (ARN)。 |
"trace_id" |
X-Amzn-Trace-Id ヘッダーのコンテンツ (二重引用符で囲まれます)。 |
"domain_name" |
[HTTPS リスナー] TLS ハンドシェイク中にクライアントから提供される SNI ドメイン (二重引用符で囲まれます)。クライアントが SNI をサポートしない場合、あるいはドメインが証明書と一致せず、デフォルトの証明書がクライアントに提示された場合、この値は - となります。 |
"chosen_cert_arn" |
[HTTPS リスナー] クライアントに提示される証明書の ARN (二重引用符で囲まれます)。セッションが再利用される場合、この値は |
matched_rule_priority |
リクエストに一致したルールの優先度の値。ルールが一致した場合、この値は 1~50,000 になります。一致するルールがなく、デフォルトのアクションが実行された場合、この値は 0 に設定されます。ルールの評価中にエラーが発生した場合は、-1 に設定されます。その他のエラーの場合は、- に設定されます。 |
request_creation_time |
ロードバランサーがクライアントからリクエストを受け取った時刻 (ISO 8601 形式)。 |
"actions_executed" |
リクエストの処理時に実行されるアクション (二重引用符で囲まれます)。この値は、実行されるアクション で説明されている値を含めることができるカンマ区切りリストです。形式が正しくないリクエストなどでアクションが実行されない場合、この値は - に設定されます。 |
"redirect_url" |
HTTP レスポンスのロケーションヘッダーのリダイレクトターゲットの URL (二重引用文字で囲む)。リダイレクトアクションが実行されなかった場合、この値は - に設定されます。 |
"error_reason" |
エラー理由コード (二重引用符で囲まれます)。リクエストが失敗した場合、これは エラー理由コード で説明されているいずれかのエラーコードになります。実行されたアクションが認証アクションを含まない、またはターゲットが Lambda 関数ではない場合、この値は - に設定されます。 |
"target:port_list" |
このリクエストを処理したターゲットの IP アドレスとポートのスペース区切りのリスト (二重引用符で囲まれます)。現在、このリストには 1 つの項目を含めることができ、target:port フィールドと一致します。 クライアントがリクエスト全体を送信しなかった場合、ロードバランサーはターゲットにリクエストをディスパッチできず、この値が - に設定されます。 ターゲットが Lambda 関数の場合、この値は - に設定されます。 リクエストが AWS WAF によってブロックされた場合、この値は - に設定され、elb_status_code の値は 403 に設定されます。 |
"target_status_code_list" |
ターゲットの応答からのステータスコードのスペース区切りのリスト (二重引用符で囲まれます)。現在、このリストには 1 つの項目を含めることができ、target_status_code フィールドと一致します。 この値は、ターゲットへの接続が確立され、ターゲットが応答を送信した場合のみ記録されます。それ以外の場合は、- に設定されます。 |
"classification" |
desync 緩和の分類 (二重引用符で囲まれます)。リクエストが RFC 7230 に準拠していない場合、可能な値は Acceptable、Ambiguous、および Severe です。 リクエストが RFC 7230 に準拠している場合、この値は - に設定されます。 |
"classification_reason" |
分類理由コード (二重引用符で囲まれます)。リクエストが RFC 7230 に準拠していない場合、これは 分類の理由 で説明されている分類コードの 1 つです。リクエストが RFC 7230 に準拠している場合、この値は - に設定されます。 |
実行されるアクション
ロードバランサーは、実行されたアクションをアクセスログの actions_executed フィールドに格納します。
-
authenticate
— ロードバランサーは、ルール設定で指定されているように、セッションを検証し、ユーザーを認証し、ユーザー情報をリクエストヘッダーに追加しました。 -
fixed-response
— ロードバランサーは、ルール設定で指定された固定レスポンスを発行しました。 -
forward
— ロードバランサーは、ルール設定で指定されているように、リクエストをターゲットに転送しました。 -
redirect
— ロードバランサーは、ルール設定で指定されているように、リクエストを別の URL にリダイレクトしました。 -
waf
— ロードバランサーは、リクエストをターゲットに転送する必要があるかどうかを判別するために、リクエストを AWS WAF に転送しました。これが最終アクションである場合、AWS WAF はリクエストを拒否する必要があると判別しました。 -
waf-failed
— ロードバランサーはリクエストを AWS WAF に転送しようとしましたが、このプロセスは失敗しました。
分類の理由
リクエストが RFC 7230 に準拠していない場合、ロードバランサーはアクセスログの classification_reason フィールドに次のいずれかのコードを保存します。詳細については、「desync 軽減モード」を参照してください。
コード | 説明 | 分類 |
---|---|---|
|
リクエスト URI に制御文字が含まれています。 |
Ambiguous |
|
Content-Length ヘッダーに解析できない値または無効な数値が含まれています。 |
Severe |
|
ヘッダーに NULL 文字またはキャリッジリターンが含まれています。 |
Severe |
|
Transfer-Encoding ヘッダーに不正な値が含まれています。 |
Severe |
|
リクエスト URI に NULL 文字またはキャリッジリターンが含まれています。 |
Severe |
|
リクエストメソッドの形式が正しくありません。 |
Severe |
|
リクエストバージョンの形式が正しくありません。 |
Severe |
|
リクエストに Transfer-Encoding ヘッダーと Content-Length ヘッダーの両方が含まれています。 |
Ambiguous |
|
同じ値を持つ複数の Content-Length ヘッダーがあります。 |
Ambiguous |
|
ヘッダーが空であるか、スペースのみを含む行があります。 |
Ambiguous |
|
GET または HEAD リクエストの値を 0 とする Content-Length ヘッダーがあります。 |
Acceptable |
|
異なる値を持つ複数の Content-Length ヘッダーがあります。 |
Severe |
|
複数の Transfer-Encoding: chunked ヘッダーがあります。 |
Severe |
|
ヘッダーに ASCII 以外の文字または制御文字が含まれています。 |
Acceptable |
|
リクエストバージョンに不正な値が含まれています。 |
Acceptable |
|
リクエスト URI に URL エンコードされていないスペースが含まれています。 |
Acceptable |
|
一般的なテキスト正規化技術を使用して、Transfer-Encoding または Content-Length に正規化できるヘッダーがあります。 |
Ambiguous |
|
GET または HEAD リクエストに対して定義された Content-Length ヘッダーがありません。 |
Ambiguous |
|
GET または HEAD リクエストに対して定義された Transfer-Encoding ヘッダーがありません。 |
Ambiguous |
エラー理由コード
ロードバランサーが認証アクションを完了できない場合、ロードバランサーはアクセスログの error_reason フィールドに次のいずれかの理由コードを保存します。また、ロードバランサーは対応する CloudWatch メトリクスを増分します。詳細については、「Application Load Balancer を使用してユーザーを認証するを参照してください。」を参照してください。
コード | 説明 | メトリクス |
---|---|---|
|
認証 Cookie が無効です。 |
|
|
トークンエンドポイントからの認証付与コードが無効です。 |
|
|
ID トークンが無効です。 |
|
|
状態パラメータが無効です。 |
|
|
トークンエンドポイントからのレスポンスが無効です。 |
|
|
ユーザー情報エンドポイントからのレスポンスが無効です。 |
|
|
認証エンドポイントからの認証レスポンスに、「code」という名前のクエリパラメータがありません。 |
|
|
認証エンドポイントからの認証レスポンスに、ホストヘッダーフィールドがありません。 |
|
|
認証エンドポイントからの認証レスポンスに、「state」という名前のクエリパラメータがありません。 |
|
|
トークンエンドポイントからエラーレスポンス (2XX 以外) があります。 |
|
|
ロードバランサーは、トークンエンドポイントと通信できません。 |
|
|
ロードバランサーで処理されない例外が発生しました。 |
|
|
IdP ユーザー情報エンドポイントからエラーレスポンス (2XX 以外) があります。 |
|
|
ロードバランサーは、IdP ユーザー情報エンドポイントと通信できません。 |
|
|
IdP から返されたクレームのサイズが 11K バイトを超えました。 |
|
加重ターゲットグループへのリクエストが失敗した場合、ロードバランサーはアクセスログの error_reason フィールドに次のいずれかのエラーコードを保存します。
コード | 説明 |
---|---|
|
加重ターゲットグループで使用される AWSALBTG Cookie は無効です。たとえば、Cookie 値が URL エンコードされている場合、ロードバランサーはこのエラーを返します。 |
|
ロードバランサーで処理されない例外が発生しました。 |
Lambda 関数へのリクエストが失敗した場合、ロードバランサーはアクセスログの error_reason フィールドに次のいずれかの理由コードを保存します。また、ロードバランサーは対応する CloudWatch メトリクスを増分します。詳細については、Lambda 呼び出しアクションを参照してください。
コード | 説明 | メトリクス |
---|---|---|
|
ロードバランサーに、Lambda 関数を呼び出すアクセス権限がありませんでした。 |
|
|
クライアントリクエストヘッダーまたは本文に UTF-8 文字のみが含まれていないため、Lambda 呼び出しが失敗しました。 |
|
|
ロードバランサーが Lambda に接続できません。 |
|
|
Lambda への接続がタイムアウトしました。 |
|
|
関数の初期化中に Amazon EC2 が Lambda へのアクセスを拒否しました。 |
|
|
関数の初期化中に Amazon EC2 が Lambda を調整しました。 |
|
|
関数の初期化中に Amazon EC2 で予期しない例外が発生しました。 |
|
|
ネットワークインターフェイスの制限を超えたため、Lambda は Lambda 関数の設定で指定された VPC のネットワークインターフェイスを作成できませんでした。 |
|
|
Lambda 関数からのレスポンスの形式が間違っているか、必須フィールドが含まれていません。 |
|
|
指定されたバージョンの Lambda ランタイムはサポートされていません。 |
|
|
Lambda 関数の設定で指定されたセキュリティグループ ID が無効です。 |
|
|
Lambda 関数の設定で指定されたサブネット ID が無効です。 |
|
|
Lambda は指定された関数の zip ファイルを解凍できませんでした。 |
|
|
KMS キーへのアクセスが拒否されたため、Lambda は環境変数を復号できませんでした。Lambda 関数の KMS アクセス権限を確認してください。 |
|
|
指定された KMS キーが無効化されたため、Lambda は環境変数を復号できませんでした。Lambda 関数の KMS キー設定を確認してください。 |
|
|
KMS キーの状態が無効であるため、Lambda は環境変数を復号できませんでした。Lambda 関数の KMS キー設定を確認してください。 |
|
|
KMS キーが見つからなかったため、Lambda は環境変数を復号できませんでした。Lambda 関数の KMS キー設定を確認してください。 |
|
|
リクエストボディのサイズは 1 MB を超えています。 |
|
|
Lambda 関数は見つかりませんでした。 |
|
|
レスポンスのサイズは 1 MB を超えています。 |
|
|
Lambda 内部エラーが発生しました。 |
|
|
Lambda は、1 つ以上のサブネットに使用可能な IP アドレスがないため、Lambda 関数の VPC アクセスを設定できませんでした。 |
|
|
リクエストが多すぎるため、Lambda 関数が調整されました。 |
|
|
Lambda 関数で処理されない例外が発生しました。 |
|
|
ロードバランサーで処理されない例外が発生しました。 |
|
|
WebSockets は、Lambda でサポートされていません。 |
|
ロードバランサーがリクエストを AWS WAF に転送するときにエラーが発生すると、ロードバランサーはアクセスログの error_reason フィールドに次のいずれかのエラーコードを保存します。
コード | 説明 |
---|---|
|
ロードバランサーが AWS WAF に接続できません。 |
|
AWS WAF への接続がタイムアウトしました。 |
|
AWS WAF へのリクエストがタイムアウトしました。 |
|
AWS WAF が 5XX エラーを返しました。 |
|
ロードバランサーで処理されない例外が発生しました。 |
例
以下にログエントリの例を示します。読みやすくするためだけの目的で、テキストは複数の行に表示されています。
HTTP エントリ例
次の例は、HTTP リスナーのログエントリです (ポート 80 からポート 80)。
http 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188
192.168.131.39:2817 10.0.0.1:80 0.000 0.001 0.000 200 200 34 366
"GET http://www.example.com:80/ HTTP/1.1" "curl/7.46.0" - -
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337262-36d228ad5d99923122bbe354" "-" "-"
0 2018-07-02T22:22:48.364000Z "forward" "-" "-" "10.0.0.1:80" "200" "-" "-"
HTTPS エントリ例
次の例は、HTTPS リスナーのログエントリです (ポート 443 からポート 80)。
https 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188
192.168.131.39:2817 10.0.0.1:80 0.086 0.048 0.037 200 200 0 57
"GET https://www.example.com:443/ HTTP/1.1" "curl/7.46.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337281-1d84f3d73c47ec4e58577259" "www.example.com" "arn:aws:acm:us-east-2:123456789012:certificate/12345678-1234-1234-1234-123456789012"
1 2018-07-02T22:22:48.364000Z "authenticate,forward" "-" "-" "10.0.0.1:80" "200" "-" "-"
HTTP/2 エントリ例
HTTP/2 ストリームのログエントリの例を次に示します。
h2 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188
10.0.1.252:48160 10.0.0.66:9000 0.000 0.002 0.000 200 200 5 257
"GET https://10.0.2.105:773/ HTTP/2.0" "curl/7.46.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337327-72bd00b0343d75b906739c42" "-" "-"
1 2018-07-02T22:22:48.364000Z "redirect" "https://example.com:80/" "-" "10.0.0.66:9000" "200" "-" "-"
WebSocket エントリの例
WebSocket 接続のログエントリの例を次に示します。
ws 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188
10.0.0.140:40914 10.0.1.192:8010 0.001 0.003 0.000 101 101 218 587
"GET http://10.0.0.30:80/ HTTP/1.1" "-" - -
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337364-23a8c76965a2ef7629b185e3" "-" "-"
1 2018-07-02T22:22:48.364000Z "forward" "-" "-" "10.0.1.192:8010" "101" "-" "-"
安全な WebSocket エントリの例
安全な WebSocket 接続のログエントリの例を次に示します。
wss 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188
10.0.0.140:44244 10.0.0.171:8010 0.000 0.001 0.000 101 101 218 786
"GET https://10.0.0.30:443/ HTTP/1.1" "-" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2
arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337364-23a8c76965a2ef7629b185e3" "-" "-"
1 2018-07-02T22:22:48.364000Z "forward" "-" "-" "10.0.0.171:8010" "101" "-" "-"
Lambda の関数のエントリの例。
成功した Lambda 関数へのリクエストのログエントリ例を次に示します。
http 2018-11-30T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188
192.168.131.39:2817 - 0.000 0.001 0.000 200 200 34 366
"GET http://www.example.com:80/ HTTP/1.1" "curl/7.46.0" - -
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337364-23a8c76965a2ef7629b185e3" "-" "-"
0 2018-11-30T22:22:48.364000Z "forward" "-" "-" "-" "-" "-" "-"
失敗した Lambda 関数へのリクエストのログエントリ例を次に示します。
http 2018-11-30T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188
192.168.131.39:2817 - 0.000 0.001 0.000 502 - 34 366
"GET http://www.example.com:80/ HTTP/1.1" "curl/7.46.0" - -
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337364-23a8c76965a2ef7629b185e3" "-" "-"
0 2018-11-30T22:22:48.364000Z "forward" "-" "LambdaInvalidResponse" "-" "-" "-" "-"
Bucket permissions (バケットのアクセス許可)
アクセスログの作成を有効にするときは、アクセスログの S3 バケットを指定する必要があります。バケットは、次の要件を満たしている必要があります。
要件
-
バケットは、ロードバランサーと同じリージョンに配置されている必要があります。
-
このバケットは、バケットにアクセスログを書き込む許可を Elastic Load Balancing に付与するバケットポリシーが必要です。バケットポリシーは、バケットのアクセス許可を定義するためにアクセスポリシー言語で記述された JSON ステートメントのコレクションです。各ステートメントには 1 つのアクセス許可に関する情報が含まれ、一連のエレメントが使用されます。
Amazon S3 が管理する暗号化キー (SSE-S3) を使用して、Amazon S3 アクセスログバケットに対してサーバー側の暗号化を有効にできます。
詳細については、Amazon Simple Storage Service ユーザーガイドの Amazon S3 が管理する暗号化キーによるサーバー側の暗号化 (SSE-S3) を使用したデータの保護 を参照してください。
オプション
次のいずれかのオプションを使用してアクセスログの S3 バケットを準備します。
-
Elastic Load Balancing コンソールを使用してバケットを作成し、アクセスログを有効にするには、アクセスログの作成の有効化 にスキップし、コンソールでバケットとバケットポリシーを作成するオプションを選択します。
-
既存のバケットを使用し、Amazon S3 コンソールを使用して必要なバケットポリシーを追加するには、以下の手順を使用しますが、「[既存のバケットを使用する場合はスキップ]」と示されているステップはスキップします。
-
バケットを作成し、Amazon S3 コンソールを使用して必要なバケットポリシーを追加するには (例えば、AWS CLI または API を使用してアクセスログを有効にする場合)、以下の手順を使用します。
アクセスログの Amazon S3 バケットを準備するには
Amazon S3 コンソール (https://console.aws.amazon.com/s3/
) を開きます。 -
[既存のバケットを使用する場合はスキップ] [バケットの作成] を選択します。
-
[既存のバケットを使用する場合はスキップ] [バケットの作成] ページで、以下の操作を実行します。
-
[バケット名] にバケットの名前を入力します。この名前は、Amazon S3 内で既存の、すべてのバケット名の中で一意である必要があります。リージョンによっては、バケット名にその他の制限が設けられていることがあります。詳細については、「Amazon Simple Storage Service ユーザーガイド」の「バケットの制約と制限」を参照してください。
-
[リージョン] で、ロードバランサーを作成したリージョンを選択します。
-
[Create] を選択します。
-
-
バケットを選択します。[Permissions]、[Bucket Policy] の順に選択します。
-
新しいバケットポリシーを作成する場合は、ポリシードキュメント全体をポリシーエディタにコピーし、プレースホルダーを対応する情報に置き換えます。既存のバケットポリシーを編集する場合は、ポリシードキュメントから新しいステートメント (
Statement
要素の [ と ] の間のテキスト) をコピーします。[アベイラビリティーゾーンと Local Zones] 次のポリシーを使用します。バケットの名前とプレフィックスのプレースホルダー、Elastic Load Balancing の AWS アカウントの ID のプレースホルダー (ロードバランサーのリージョンに基づく)、および AWS アカウント ID のプレースホルダーを更新します。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::
elb-account-id
:root" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::bucket-name
/prefix
/AWSLogs/your-aws-account-id
/*" }, { "Effect": "Allow", "Principal": { "Service": "logdelivery.elb.amazonaws.com" }, "Action": "s3:GetBucketAcl", "Resource": "arn:aws:s3:::bucket-name
" } ] }以下の表には、バケットポリシーで
elb-account-id
の代わりに使用するアカウント ID が含まれています。リージョン リージョン名 Elastic Load Balancing アカウント ID us-east-1
米国東部(バージニア北部) 127311923021 us-east-2
米国東部 (オハイオ) 033677994240 us-west-1
米国西部 (北カリフォルニア) 027434742980 us-west-2
米国西部 (オレゴン) 797873946194 af-south-1
アフリカ (ケープタウン) 098369216593 ca-central-1
カナダ (中部) 985666609251 eu-central-1
欧州 (フランクフルト) 054676820928 eu-west-1
欧州 (アイルランド) 156460612806 eu-west-2
欧州 (ロンドン) 652711504416 eu-south-1
ヨーロッパ (ミラノ) 635631232127 eu-west-3
欧州 (パリ) 009996457667 eu-north-1
欧州 (ストックホルム) 897822967062 ap-east-1
アジアパシフィック (香港) 754344448648 ap-northeast-1
アジアパシフィック (東京) 582318560864 ap-northeast-2
アジアパシフィック (ソウル) 600734575887 ap-northeast-3
アジアパシフィック (大阪) 383597477331 ap-southeast-1
アジアパシフィック (シンガポール) 114774131450 ap-southeast-2
アジアパシフィック (シドニー) 783225319266 ap-southeast-3
アジアパシフィック (ジャカルタ) 589379963580 ap-south-1
アジアパシフィック (ムンバイ) 718504428378 me-south-1
中東 (バーレーン) 076674570225 sa-east-1
南米 (サンパウロ) 507241528517 us-gov-west-1
*AWS GovCloud (米国西部) 048591011584 us-gov-east-1
*AWS GovCloud (米国東部) 190560391635 cn-north-1
*中国 (北京) 638102146993 cn-northwest-1
*中国 (寧夏) 037604701340 * これらのリージョンには個別のアカウントが必要です。詳細については、AWS GovCloud (米国西部)
および 中国 (北京) を参照してください。 [Outpost] 以下のポリシーを使用します。バケットの名前とプレフィックスのプレースホルダー、および AWS アカウントの ID のプレースホルダーを更新します。
{ "Effect": "Allow", "Principal": { "Service": "logdelivery.elb.amazonaws.com" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::
bucket-name
/prefix
/AWSLogs/your-aws-account-id
/*", "Condition": { "StringEquals": { "s3:x-amz-acl": "bucket-owner-full-control" } } } -
[Save] を選択します。
アクセスログの作成の有効化
ロードバランサーのアクセスログの作成を有効にする場合は、ロードバランサーがログを保存する S3; バケットの名前を指定する必要があります。このバケットは、ロードバランサーと同じリージョンにあり、バケットにアクセスログを書き込む許可を Elastic Load Balancing に付与するバケットポリシーが必要です。バケットは、ロードバランサーを所有するアカウントとは別のアカウントが所有するものでもかまいません。
コンソールを使用してアクセスログの作成を有効にするには
Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/
) を開きます。 -
ナビゲーションペインで、[Load Balancers] を選択します。
-
ロードバランサーを選択します。
-
[Description] タブで、[Edit attributes] を選択します。
-
[Edit load balancer attributes] ページで、以下を実行します。
-
[アクセスログ] で [有効化] を選択します。
-
[S3 の場所] に、プレフィックスを含めて S3 バケットの名前を入力します (たとえば
my-loadbalancer-logs/my-app
)。既存のバケットの名前や新しいバケットの名前を指定できます。既存のバケットを指定する場合は、このバケットを所有していること、および必要なバケットポリシーを設定したことを確認します。 -
(オプション) バケットが存在しない場合は、[Create this location for me] を選択します。Amazon S3 内で既存の、すべてのバケット名の中で一意な名前を指定し、DNS 命名規則に従う必要があります。詳細については、Amazon Simple Storage Service ユーザーガイドでバケットの命名規則について参照してください。
-
[Save] を選択します。
-
AWS CLI を使用してアクセスログの作成を有効にするには
modify-load-balancer-attributes コマンドを使用します。
Elastic Load Balancing が S3 バケットにテストファイルを作成したことを確認するには
アクセスログの作成をロードバランサーで有効にすると、Elastic Load Balancing は S3 バケットを検証し、テストファイルを作成して、バケットポリシーが必要なアクセス権限を指定するようにします。Amazon S3 コンソールを使用して、テストファイルが作成されたことを確認できます。テストファイルは実際のアクセスログファイルではなく、レコード例は含まれていません。
Amazon S3 コンソール (https://console.aws.amazon.com/s3/
) を開きます。 -
[All Buckets] で、S3 バケットを選択します。
-
アクセスログ用に指定したバケットに移動し、
ELBAccessLogTestFile
を探します。たとえば、コンソールを使用してバケットとバケットポリシーを作成した場合、パスは次のようになります。my-bucket
/prefix
/AWSLogs/123456789012
/ELBAccessLogTestFile
アクセスログの S3 バケットを管理するには
アクセスログを有効にしたら、アクセスログを有効にしたバケットを削除する前に、必ずアクセスログを無効にします。これを行わないと、自分が所有していない AWS アカウントに、同じ名前で必要なバケットポリシーを持つ新しいバケットが作成された場合、Elastic Load Balancing がロードバランサーのアクセスログを、その新しいバケットに書き込んでしまう可能性があります。
アクセスログの作成の無効化
ロードバランサーのアクセスログの作成は、いつでも無効にできます。アクセスログの作成を無効にした後は、削除するまでアクセスログは S3 バケットに残されたままになります。詳細については、Amazon Simple Storage Service ユーザーガイドでバケットの使用について参照してください。
コンソールを使用してアクセスログの作成を無効にするには
Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/
) を開きます。 -
ナビゲーションペインで、[Load Balancers] を選択します。
-
ロードバランサーを選択します。
-
[Description] タブで、[Edit attributes] を選択します。
-
[アクセスログ] で、[有効化] をクリアします。
-
[Save] を選択します。
AWS CLI を使用してアクセスログの作成を無効にするには
modify-load-balancer-attributes コマンドを使用します。
アクセスログファイルの処理
アクセスログファイルは圧縮されます。Amazon S3 コンソールを使用してファイルを開くと、ファイルは解凍され、情報が表示されます。ファイルをダウンロードする場合、情報を表示するには解凍する必要があります。
ウェブサイトの需要が大きい場合は、ロードバランサーによって数 GB のデータ量のログファイルが生成されることがあります。このような大容量のデータは、行単位で処理できない場合があります。このため、場合によっては、並列処理ソリューションを提供する分析ツールを使用する必要があります。たとえば、次の分析ツールを使用するとアクセスログの分析と処理を行うことができます。
-
Amazon Athena はインタラクティブなクエリサービスで、Amazon S3 内のデータを標準 SQL を使用して簡単に分析できるようになります。詳細については、Amazon Athena ユーザーガイドの Querying Application Load Balancer logs を参照してください。