コンソールにサインインする
Elastic Load Balancing
Application Load Balancer

AWS ドキュメント » Elastic Load Balancing » Application Load Balancer » Application Load Balancer を監視する » Application Load Balancer のアクセスログ

Application Load Balancer のアクセスログ

Elastic Load Balancing は、ロードバランサーに送信されるリクエストについて、詳細情報を収集するアクセスログを提供します。各ログには、リクエストを受け取った時刻、クライアントの IP アドレス、レイテンシー、リクエストのパス、サーバーレスポンスなどの情報が含まれます。これらのアクセスログを使用して、トラフィックパターンの分析や、問題のトラブルシューティングを行うことができます。

アクセスログの作成は、Elastic Load Balancing のオプション機能であり、デフォルトでは無効化されています。ロードバランサーのアクセスログの作成を有効にすると、Elastic Load Balancing はログをキャプチャし、圧縮ファイルとして指定した Amazon S3 バケット内に保存します。アクセスログの作成はいつでも無効にできます。

S3 バケットに対して、Amazon S3 管理の暗号化キーによるサーバー側の暗号化 (SSE-S3) を有効にした場合、各アクセスログファイルは、S3 バケットに保存される前に自動的に暗号化され、アクセス時に復号されます。暗号化あるいは復号化されたログファイルにアクセスする方法に違いがないため、特別なアクションを実行する必要はありません。各ログファイルは、一意のキーで暗号化されます。この一意のキー自体が、定期的に更新されるマスターキーで更新されます。詳細については、Amazon Simple Storage Service 開発者ガイドの「Amazon S3 で管理された暗号化キーによるサーバー側の暗号化 (SSE-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_load-balancer-id_end-time_ip-address_random-string.log.gz
bucket

S3 バケットの名前。

プレフィックス

バケットのプレフィックス (論理階層)。プレフィックスを指定しない場合、ログはバケットのルートレベルに配置されます。

aws-account-id

所有者の AWS アカウント ID。

リージョン

ロードバランサーおよび S3 バケットのリージョン。

yyyy/mm/dd

ログが配信された日付。

load-balancer-id

ロードバランサーのリソース ID。リソース ID にスラッシュ (/) が含まれている場合、ピリオド (.) に置換されます。

end-time

ログ作成の間隔が終了した日時。たとえば、終了時間 20140215T2340Z には、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_my-loadbalancer_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 はベストエフォートベースでリクエストを記録します。アクセスログは、すべてのリクエストを完全に報告するためのものではなく、リクエストの本質を把握するものとして使用することをお勧めします。

構文

次の表は、アクセスログのエントリのフィールドを順に示しています。すべてのフィールドはスペースで区切られています。新しいフィールドが導入されると、ログエントリの最後に追加されます。予期していなかったログエントリの最後のフィールドは無視する必要があります。

フィールド 説明

type

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

  • http — HTTP

  • https — HTTP over SSL/TLS

  • h2 — HTTP/2 over SSL/TLS

  • ws — WebSockets

  • wss — WebSockets over SSL/TLS

timestamp

ロードバランサーがクライアントに対してレスポンスを生成した時刻 (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 に設定されます。

matched_rule_priority

リクエストに一致したルールの優先度の値。ルールが一致した場合、この値は 1～50,000 になります。一致するルールがなく、デフォルトのアクションが実行された場合、この値は 0 に設定されます。ルールの評価中にエラーが発生した場合は、-1 に設定されます。その他のエラーの場合は、- に設定されます。

request_creation_time

ロードバランサーがクライアントからリクエストを受け取った時刻 (ISO 8601 形式)。

"actions_executed"

リクエストの処理時に実行されるアクション (二重引用符で囲まれます)。この値は、次のような値を含むことができるカンマ区切りリストです: waf、waf-failed、authenticate、redirect、fixed-response、forward。形式が正しくないリクエストなどでアクションが実行されない場合、この値は - に設定されます。

"redirect_url"

HTTP レスポンスのロケーションヘッダーのリダイレクトターゲットの URL (二重引用文字で囲む)。リダイレクトアクションが実行されなかった場合、この値は - に設定されます。

"error_reason"

エラー理由コード (二重引用符で囲まれます)。リクエストが失敗した場合、これは「エラー理由コード」で説明されているいずれかのエラーコードになります。実行されたアクションが認証アクションを含まない、またはターゲットが Lambda 関数ではない場合、この値は - に設定されます。

エラー理由コード

ロードバランサーが認証アクションを完了できない場合、ロードバランサーはアクセスログの 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

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

コード 説明 メトリクス

LambdaAccessDenied

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

LambdaUserError

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

例

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

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" "-" "-"

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" "-" "-"

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/" "-"

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" "-" "-"

安全な 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" "-" "-"

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"

バケットのアクセス許可

アクセスログの作成を有効にするときは、アクセスログの S3 バケットを指定する必要があります。バケットは、次の要件を満たしている必要があります。

要件

  • バケットは、ロードバランサーと同じリージョンに配置されている必要があります。

  • このバケットは、バケットにアクセスログを書き込む許可を Elastic Load Balancing に付与するバケットポリシーが必要です。バケットポリシーは、バケットのアクセス許可を定義するためにアクセスポリシー言語で記述された JSON ステートメントのコレクションです。各ステートメントには 1 つのアクセス許可に関する情報が含まれ、一連のエレメントが使用されます。

次のいずれかのオプションを使用してアクセスログの S3 バケットを準備します。

オプション

  • バケットを作成する必要があり、コンソールを使用してアクセスログの作成を有効にする場合は、アクセスログの作成の有効化にスキップし、コンソールでバケットとバケットポリシーを作成するオプションを選択します。

  • アクセスログのバケットを作成する必要があり、AWS CLI を使用している場合は、次の手順を使用してバケットを作成し、必要なバケットポリシーを手動で追加します。

  • すでにアクセスログ用のバケットがある場合、次の手順のステップ 1 に従って Amazon S3 コンソールを開き、ステップ 4 に進んでバケットポリシーを追加または更新します。

必要なアクセス権限を持つ Amazon S3 バケットを作成するには

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

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

  3. [既存のバケットを使用する場合はスキップ] [バケットの作成] ダイアログボックスで、以下の操作を実行します。

    1. [Bucket Name] に、バケットの名前 (例: my-loadbalancer-logs) を入力します。この名前は、Amazon S3 にある既存のすべてのバケット名と異なる必要があります。リージョンによっては、バケット名にその他の制限があることがあります。詳細は、Amazon Simple Storage Service 開発者ガイドの「Bucket Restrictions and Limitations」を参照してください。

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

    3. [Create (作成)] を選択します。

  4. バケットを選択し、[Permissions] を選択します。

  5. [バケットポリシー] を選択します。バケットにポリシーがすでにアタッチされている場合、 必要なステートメントを既存のポリシーに追加できます。

  6. [Policy generator] を選択します。[AWS Policy Generator] ページで、次の操作を実行します。

    1. [Select Type of Policy] で、[S3 Bucket Policy] を選択します。

    2. [Effect] で、[Allow] を選択します。

    3. [プリンシパル] で、S3 バケットへのアクセス権を Elastic Load Balancing に付与する次のいずれかの AWS アカウント ID を指定します。ロードバランサーとバケットのリージョンに対応するアカウント ID を使用します。

      リージョン リージョン名 Elastic Load Balancing アカウント ID
      us-east-1 米国東部（バージニア北部） 127311923021
      us-east-2 米国東部 (オハイオ) 033677994240
      us-west-1 米国西部 (北カリフォルニア) 027434742980
      us-west-2 米国西部 (オレゴン) 797873946194
      ca-central-1 カナダ (中部) 985666609251
      eu-central-1 欧州 (フランクフルト) 054676820928
      eu-west-1 欧州 (アイルランド) 156460612806
      eu-west-2 欧州 (ロンドン) 652711504416
      eu-west-3 EU (パリ) 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-south-1 アジアパシフィック (ムンバイ) 718504428378
      sa-east-1 南米 (サンパウロ) 507241528517
      us-gov-west-1* AWS GovCloud (US-West) 048591011584
      us-gov-east-1* AWS GovCloud (米国東部) 190560391635
      cn-north-1* 中国 (北京) 638102146993
      cn-northwest-1* 中国 (寧夏) 037604701340

      * これらのリージョンには個別のアカウントが必要です。詳細については、「AWS GovCloud (米国西部)」および「中国 (北京)」を参照してください。

    4. [Actions] で PutObject を選択し、Elastic Load Balancing が S3 バケットにオブジェクトを保存するのを許可します。

    5. [Amazon リソースネーム (ARN)] に、S3 バケットの ARN を次の形式で入力します。[aws-account-id] に、ロードバランサーを所有している AWS アカウントの ID (たとえば、123456789012) を指定します。アカウント ID にはワイルドカードを指定しないでください。他のアカウントによるバケットへのアクセスログの書き込みが許可される場合があります。複数のアカウントで 1 つのバケットを使用してロードバランサーのアクセスログを保存するには、バケットポリシーでアカウントごとに 1 つの ARN を指定します。その際、各 ARN で対応する AWS アカウント ID を使用します。 

      arn:aws:s3:::bucket/prefix/AWSLogs/aws-account-id/*

      us-gov-west-1 リージョンを使用している場合は、arn:aws ではなく arn:aws-us-gov の ARN 形式を指定することに注意してください。

    6. [Add Statement]、[Generate Policy] を選択します。ポリシードキュメントは次の例のようになります。 

      {
  "Id": "Policy1429136655940",
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1429136633762",
      "Action": [
        "s3:PutObject"
      ],
      "Effect": "Allow",
      "Resource": "arn:aws:s3:::my-loadbalancer-logs/my-app/AWSLogs/123456789012/*",
      "Principal": {
        "AWS": [
          "797873946194"
        ]
      }
    }
  ]
}

    7. 新しいバケットポリシーを作成する場合は、ポリシードキュメント全体をコピーし、[Close] を選択します。

      既存のバケットポリシーを編集する場合は、ポリシードキュメントから新しいステートメント (Statement 要素の [ と ] の間のテキスト) をコピーし、[Close] を選択します。

  7. Amazon S3 コンソールに戻り、必要に応じてポリシーをテキストエリアに貼り付けます。

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

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

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

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

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

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

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

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

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

    1. [Enable access logs] を選択します。

    2. [S3 location] に、プレフィックスを含めて 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. https://console.aws.amazon.com/s3/ にある Amazon S3 コンソールを開きます。

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

  3. テストログファイルがある場所に移動します。パスは次のようになります。

    my-bucket/prefix/AWSLogs/123456789012/ELBAccessLogTestFile

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

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

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

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

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

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

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

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

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

  5. [Edit load balancer attributes] ページで、[Enable access logs] をオフにします。

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

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

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

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

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

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