Application Load Balancer のアクセスログ - Elastic Load Balancing
アクセスログファイルアクセスログのエントリBucket permissions (バケットのアクセス許可)アクセスログの作成の有効化アクセスログの作成の無効化アクセスログファイルの処理

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

リクエストまたは接続のタイプ。有効な値は次のとおりです (その他の値は無視してください)。

  • http — HTTP

  • https — TLS 経由の HTTP

  • h2 — TLS 経由の HTTP/2

  • grpcs — TLS 経由の gRPC

  • ws — WebSockets

  • wss — TLS 経由の WebSockets

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 (二重引用符で囲まれます)。セッションが再利用される場合、この値は session-reused に設定されます。リスナーが HTTPS リスナーではない場合、この値は - に設定されます。

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 軽減モード」を参照してください。

コード 説明 分類

AmbiguousUri

リクエスト URI に制御文字が含まれています。

Ambiguous

BadContentLength

Content-Length ヘッダーに解析できない値または無効な数値が含まれています。

Severe

BadHeader

ヘッダーに NULL 文字またはキャリッジリターンが含まれています。

Severe

BadTransferEncoding

Transfer-Encoding ヘッダーに不正な値が含まれています。

Severe

BadUri

リクエスト URI に NULL 文字またはキャリッジリターンが含まれています。

Severe

BadMethod

リクエストメソッドの形式が正しくありません。

Severe

BadVersion

リクエストバージョンの形式が正しくありません。

Severe

BothTeClPresent

リクエストに Transfer-Encoding ヘッダーと Content-Length ヘッダーの両方が含まれています。

Ambiguous

DuplicateContentLength

同じ値を持つ複数の Content-Length ヘッダーがあります。

Ambiguous

EmptyHeader

ヘッダーが空であるか、スペースのみを含む行があります。

Ambiguous

GetHeadZeroContentLength

GET または HEAD リクエストの値を 0 とする Content-Length ヘッダーがあります。

Acceptable

MultipleContentLength

異なる値を持つ複数の Content-Length ヘッダーがあります。

Severe

MultipleTransferEncodingChunked

複数の Transfer-Encoding: chunked ヘッダーがあります。

Severe

NonCompliantHeader

ヘッダーに ASCII 以外の文字または制御文字が含まれています。

Acceptable

NonCompliantVersion

リクエストバージョンに不正な値が含まれています。

Acceptable

SpaceInUri

リクエスト URI に URL エンコードされていないスペースが含まれています。

Acceptable

SuspiciousHeader

一般的なテキスト正規化技術を使用して、Transfer-Encoding または Content-Length に正規化できるヘッダーがあります。

Ambiguous

UndefinedContentLengthSemantics

GET または HEAD リクエストに対して定義された Content-Length ヘッダーがありません。

Ambiguous

UndefinedTransferEncodingSemantics

GET または HEAD リクエストに対して定義された Transfer-Encoding ヘッダーがありません。

Ambiguous

エラー理由コード

ロードバランサーが認証アクションを完了できない場合、ロードバランサーはアクセスログの error_reason フィールドに次のいずれかの理由コードを保存します。また、ロードバランサーは対応する CloudWatch メトリクスを増分します。詳細については、「Application Load Balancer を使用してユーザーを認証するを参照してください。」を参照してください。

コード 説明 メトリクス

AuthInvalidCookie

認証 Cookie が無効です。

ELBAuthFailure

AuthInvalidGrantError

トークンエンドポイントからの認証付与コードが無効です。

ELBAuthFailure

AuthInvalidIdToken

ID トークンが無効です。

ELBAuthFailure

AuthInvalidStateParam

状態パラメータが無効です。

ELBAuthFailure

AuthInvalidTokenResponse

トークンエンドポイントからのレスポンスが無効です。

ELBAuthFailure

AuthInvalidUserinfoResponse

ユーザー情報エンドポイントからのレスポンスが無効です。

ELBAuthFailure

AuthMissingCodeParam

認証エンドポイントからの認証レスポンスに、「code」という名前のクエリパラメータがありません。

ELBAuthFailure

AuthMissingHostHeader

認証エンドポイントからの認証レスポンスに、ホストヘッダーフィールドがありません。

ELBAuthError

AuthMissingStateParam

認証エンドポイントからの認証レスポンスに、「state」という名前のクエリパラメータがありません。

ELBAuthFailure

AuthTokenEpRequestFailed

トークンエンドポイントからエラーレスポンス (2XX 以外) があります。

ELBAuthError

AuthTokenEpRequestTimeout

ロードバランサーは、トークンエンドポイントと通信できません。

ELBAuthError

AuthUnhandledException

ロードバランサーで処理されない例外が発生しました。

ELBAuthError

AuthUserinfoEpRequestFailed

IdP ユーザー情報エンドポイントからエラーレスポンス (2XX 以外) があります。

ELBAuthError

AuthUserinfoEpRequestTimeout

ロードバランサーは、IdP ユーザー情報エンドポイントと通信できません。

ELBAuthError

AuthUserinfoResponseSizeExceeded

IdP から返されたクレームのサイズが 11K バイトを超えました。

ELBAuthUserClaimsSizeExceeded

加重ターゲットグループへのリクエストが失敗した場合、ロードバランサーはアクセスログの error_reason フィールドに次のいずれかのエラーコードを保存します。

コード 説明

AWSALBTGCookieInvalid

加重ターゲットグループで使用される AWSALBTG Cookie は無効です。たとえば、Cookie 値が URL エンコードされている場合、ロードバランサーはこのエラーを返します。

WeightedTargetGroupsUnhandledException

ロードバランサーで処理されない例外が発生しました。

Lambda 関数へのリクエストが失敗した場合、ロードバランサーはアクセスログの error_reason フィールドに次のいずれかの理由コードを保存します。また、ロードバランサーは対応する CloudWatch メトリクスを増分します。詳細については、Lambda 呼び出しアクションを参照してください。

コード 説明 メトリクス

LambdaAccessDenied

ロードバランサーに、Lambda 関数を呼び出すアクセス権限がありませんでした。

LambdaUserError

LambdaBadRequest

クライアントリクエストヘッダーまたは本文に UTF-8 文字のみが含まれていないため、Lambda 呼び出しが失敗しました。

LambdaUserError

LambdaConnectionError

ロードバランサーが Lambda に接続できません。

LambdaInternalError

LambdaConnectionTimeout

Lambda への接続がタイムアウトしました。

LambdaInternalError

LambdaEC2AccessDeniedException

関数の初期化中に Amazon EC2 が Lambda へのアクセスを拒否しました。

LambdaUserError

LambdaEC2ThrottledException

関数の初期化中に Amazon EC2 が Lambda を調整しました。

LambdaUserError

LambdaEC2UnexpectedException

関数の初期化中に Amazon EC2 で予期しない例外が発生しました。

LambdaUserError

LambdaENILimitReachedException

ネットワークインターフェイスの制限を超えたため、Lambda は Lambda 関数の設定で指定された VPC のネットワークインターフェイスを作成できませんでした。

LambdaUserError

LambdaInvalidResponse

Lambda 関数からのレスポンスの形式が間違っているか、必須フィールドが含まれていません。

LambdaUserError

LambdaInvalidRuntimeException

指定されたバージョンの Lambda ランタイムはサポートされていません。

LambdaUserError

LambdaInvalidSecurityGroupIDException

Lambda 関数の設定で指定されたセキュリティグループ ID が無効です。

LambdaUserError

LambdaInvalidSubnetIDException

Lambda 関数の設定で指定されたサブネット ID が無効です。

LambdaUserError

LambdaInvalidZipFileException

Lambda は指定された関数の zip ファイルを解凍できませんでした。

LambdaUserError

LambdaKMSAccessDeniedException

KMS キーへのアクセスが拒否されたため、Lambda は環境変数を復号できませんでした。Lambda 関数の KMS アクセス権限を確認してください。

LambdaUserError

LambdaKMSDisabledException

指定された KMS キーが無効化されたため、Lambda は環境変数を復号できませんでした。Lambda 関数の KMS キー設定を確認してください。

LambdaUserError

LambdaKMSInvalidStateException

KMS キーの状態が無効であるため、Lambda は環境変数を復号できませんでした。Lambda 関数の KMS キー設定を確認してください。

LambdaUserError

LambdaKMSNotFoundException

KMS キーが見つからなかったため、Lambda は環境変数を復号できませんでした。Lambda 関数の KMS キー設定を確認してください。

LambdaUserError

LambdaRequestTooLarge

リクエストボディのサイズは 1 MB を超えています。

LambdaUserError

LambdaResourceNotFound

Lambda 関数は見つかりませんでした。

LambdaUserError

LambdaResponseTooLarge

レスポンスのサイズは 1 MB を超えています。

LambdaUserError

LambdaServiceException

Lambda 内部エラーが発生しました。

LambdaInternalError

LambdaSubnetIPAddressLimitReachedException

Lambda は、1 つ以上のサブネットに使用可能な IP アドレスがないため、Lambda 関数の VPC アクセスを設定できませんでした。

LambdaUserError

LambdaThrottling

リクエストが多すぎるため、Lambda 関数が調整されました。

LambdaUserError

LambdaUnhandled

Lambda 関数で処理されない例外が発生しました。

LambdaUserError

LambdaUnhandledException

ロードバランサーで処理されない例外が発生しました。

LambdaInternalError

LambdaWebsocketNotSupported

WebSockets は、Lambda でサポートされていません。

LambdaUserError

ロードバランサーがリクエストを AWS WAF に転送するときにエラーが発生すると、ロードバランサーはアクセスログの error_reason フィールドに次のいずれかのエラーコードを保存します。

コード 説明

WAFConnectionError

ロードバランサーが AWS WAF に接続できません。

WAFConnectionTimeout

AWS WAF への接続がタイムアウトしました。

WAFResponseReadTimeout

AWS WAF へのリクエストがタイムアウトしました。

WAFServiceError

AWS WAF が 5XX エラーを返しました。

WAFUnhandledException

ロードバランサーで処理されない例外が発生しました。

例

以下にログエントリの例を示します。読みやすくするためだけの目的で、テキストは複数の行に表示されています。

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 バケットを準備するには

  1. Amazon S3 コンソール (https://console.aws.amazon.com/s3/) を開きます。

  2. [既存のバケットを使用する場合はスキップ] [バケットの作成] を選択します。

  3. [既存のバケットを使用する場合はスキップ] [バケットの作成] ページで、以下の操作を実行します。

    1. [バケット名] にバケットの名前を入力します。この名前は、Amazon S3 内で既存の、すべてのバケット名の中で一意である必要があります。リージョンによっては、バケット名にその他の制限が設けられていることがあります。詳細については、「Amazon Simple Storage Service ユーザーガイド」の「バケットの制約と制限」を参照してください。

    2. [リージョン] で、ロードバランサーを作成したリージョンを選択します。

    3. [Create] を選択します。

  4. バケットを選択します。[Permissions]、[Bucket Policy] の順に選択します。

  5. 新しいバケットポリシーを作成する場合は、ポリシードキュメント全体をポリシーエディタにコピーし、プレースホルダーを対応する情報に置き換えます。既存のバケットポリシーを編集する場合は、ポリシードキュメントから新しいステートメント (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"
        }
    }
}

  6. [Save] を選択します。

アクセスログの作成の有効化

ロードバランサーのアクセスログの作成を有効にする場合は、ロードバランサーがログを保存する S3; バケットの名前を指定する必要があります。このバケットは、ロードバランサーと同じリージョンにあり、バケットにアクセスログを書き込む許可を Elastic Load Balancing に付与するバケットポリシーが必要です。バケットは、ロードバランサーを所有するアカウントとは別のアカウントが所有するものでもかまいません。

コンソールを使用してアクセスログの作成を有効にするには

  1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

  2. ナビゲーションペインで、[Load Balancers] を選択します。

  3. ロードバランサーを選択します。

  4. [Description] タブで、[Edit attributes] を選択します。

  5. [Edit load balancer attributes] ページで、以下を実行します。

    1. [アクセスログ] で [有効化] を選択します。

    2. [S3 の場所] に、プレフィックスを含めて S3 バケットの名前を入力します (たとえば my-loadbalancer-logs/my-app)。既存のバケットの名前や新しいバケットの名前を指定できます。既存のバケットを指定する場合は、このバケットを所有していること、および必要なバケットポリシーを設定したことを確認します。

    3. (オプション) バケットが存在しない場合は、[Create this location for me] を選択します。Amazon S3 内で既存の、すべてのバケット名の中で一意な名前を指定し、DNS 命名規則に従う必要があります。詳細については、Amazon Simple Storage Service ユーザーガイドでバケットの命名規則について参照してください。

    4. [Save] を選択します。

AWS CLI を使用してアクセスログの作成を有効にするには

modify-load-balancer-attributes コマンドを使用します。

Elastic Load Balancing が S3 バケットにテストファイルを作成したことを確認するには

アクセスログの作成をロードバランサーで有効にすると、Elastic Load Balancing は S3 バケットを検証し、テストファイルを作成して、バケットポリシーが必要なアクセス権限を指定するようにします。Amazon S3 コンソールを使用して、テストファイルが作成されたことを確認できます。テストファイルは実際のアクセスログファイルではなく、レコード例は含まれていません。

  1. Amazon S3 コンソール (https://console.aws.amazon.com/s3/) を開きます。

  2. [All Buckets] で、S3 バケットを選択します。

  3. アクセスログ用に指定したバケットに移動し、ELBAccessLogTestFile を探します。たとえば、コンソールを使用してバケットとバケットポリシーを作成した場合、パスは次のようになります。

    my-bucket/prefix/AWSLogs/123456789012/ELBAccessLogTestFile

アクセスログの S3 バケットを管理するには

アクセスログを有効にしたら、アクセスログを有効にしたバケットを削除する前に、必ずアクセスログを無効にします。これを行わないと、自分が所有していない AWS アカウントに、同じ名前で必要なバケットポリシーを持つ新しいバケットが作成された場合、Elastic Load Balancing がロードバランサーのアクセスログを、その新しいバケットに書き込んでしまう可能性があります。

アクセスログの作成の無効化

ロードバランサーのアクセスログの作成は、いつでも無効にできます。アクセスログの作成を無効にした後は、削除するまでアクセスログは S3 バケットに残されたままになります。詳細については、Amazon Simple Storage Service ユーザーガイドでバケットの使用について参照してください。

コンソールを使用してアクセスログの作成を無効にするには

  1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

  2. ナビゲーションペインで、[Load Balancers] を選択します。

  3. ロードバランサーを選択します。

  4. [Description] タブで、[Edit attributes] を選択します。

  5. [アクセスログ] で、[有効化] をクリアします。

  6. [Save] を選択します。

AWS CLI を使用してアクセスログの作成を無効にするには

modify-load-balancer-attributes コマンドを使用します。

アクセスログファイルの処理

アクセスログファイルは圧縮されます。Amazon S3 コンソールを使用してファイルを開くと、ファイルは解凍され、情報が表示されます。ファイルをダウンロードする場合、情報を表示するには解凍する必要があります。

ウェブサイトの需要が大きい場合は、ロードバランサーによって数 GB のデータ量のログファイルが生成されることがあります。このような大容量のデータは、行単位で処理できない場合があります。このため、場合によっては、並列処理ソリューションを提供する分析ツールを使用する必要があります。たとえば、次の分析ツールを使用するとアクセスログの分析と処理を行うことができます。

  • Amazon Athena はインタラクティブなクエリサービスで、Amazon S3 内のデータを標準 SQL を使用して簡単に分析できるようになります。詳細については、Amazon Athena ユーザーガイドの Querying Application Load Balancer logs を参照してください。

  • Loggly

  • Splunk

  • Sumo logic