こんにちは！しろみです！
一人アドベントカレンダーの4日目は、Application Load Balancer(以下 ALB)のログをS3に保管する際の設定方法についてを執筆していこうと思います。
また、かつて筆者がハマってしまったひっかけについても記事の中で触れていこうと思います。
ALBのアクセスログとは
ざっくりと解説をするとシステムにアクセスがあった際に、ALBに対してどのようなアクセスがあったかを記録しているログです。
ログの保管目的としては、下記のようなものがあります。
- アクセスが急増した時の分析
- アクセス増加となるような要因があったか
- 例えばECサイトだと、取り扱っている商品がテレビ放映された
- 特定の芸能人が●●大使になり、キャンペーンを打ち出した
- アクセス増加となるような要因があったか
いわゆる何かがあった際の調査を目的として保管されていることの多いログとなります。
また、分析の際によく使う情報として、「アクセスしている人のIPアドレス」も使用することがあります。
なぜこの話をピックアップしたかについてはこの後の話で触れていきます。
保管用S3バケットの作成
アクセスログの保管先となるS3バケットがAWSアカウント内に存在する必要があります。
今回はもともと作成していたS3バケットを使用するため、こちらの内容については省略します。
保管用S3バケットのバケットポリシーの設定
ALBからS3バケットに対して、アクセスをするためのバケットポリシーの設定が必要となります。
公式ドキュメントには下記の記載があります。
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "logdelivery.elasticloadbalancing.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket/prefix/AWSLogs/123456789012/*"
}
]
}
下記の内容については、自身の環境に読み替える必要があります。
amzn-s3-demo-bucket
アクセスログの保管先に使用するS3バケット名
123456789012
自身のAWSアカウントID
ALBにて、S3バケットにアクセスログを出力する設定をする
アクセスログを記録したいALBを選択し、「属性」タブを選択します。
下のほうにスクロールすると、現在アクセスログを記録する設定がどうなっているかを確認することが出来ます。
現在はオフのため、出力する設定はされていない状態です。
右となりの「編集」ボタンをクリックし、設定の編集画面に移ります。
下のほうにスクロールをすると、アクセスログを有効化する設定があるため、チェックボックスにチェックをします。
その後、保管したいS3バケットのURIを入力します。
amzn-s3-demo-bucket/prefix/AWSLogs/123456789012/
S3バケットポリシーで指定したこちらの内容ですが、下記については正常に設定できていた場合、自動で作成されます。
- AWSLogs
- 123456789012(自分のAWSアカウントID)
設定内容が入力出来たら、「保存」ボタンを押し反映させます。
実際にALBへアクセスがあった際に、下記のようにgz形式のファイルで保存がされます。
アクセスログの中身を確認すると、このような形でアクセスの内容が記録されていることが確認できます。
筆者がかつて引っかかっていたこと
ALBのアクセスログには多彩な情報が含まれております。その中には「アクセス元のIPアドレス」も記録されております。
公式ドキュメントの内容を引用する形で一部ご紹介します。
https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/load-balancer-access-logs.html
アクセスログはどのようなものなのかについて
アクセスログのエントリ
Elastic Load Balancing は、ターゲットに到達しなかったリクエストを含め、ロードバランサーに送信されたリクエストを記録します。たとえば、クライアントが誤った形式のリクエストを送信した場合や、リクエストに応答できる正常に動作しているターゲットがない場合も、そのリクエストは記録されます。Elastic Load Balancing はヘルスチェックリクエストをログに記録しません。
各ログエントリには、ロードバランサーに対して行われた 1 つのリクエスト (または WebSocket の場合は接続) の詳細が含まれます。WebSocket の場合、エントリは接続を閉じた後にのみ書き込まれます。アップグレードされた接続を確立できない場合、エントリは HTTP または HTTPS リクエストと同じです
アクセス元IPアドレスについては、どのような内容で記録されるかについて
client:port (4)
リクエストを送信したクライアントの IP アドレスとポート。ロードバランサーの前にプロキシがある場合、このフィールドにはプロキシの IP アドレスが含まれています。
今回の記事で書いていくひっかけとしては上記の内容です。
当時の筆者はアクセス元のIPアドレスが記録されているという内容から、このIPアドレスは純粋なアクセス元IPアドレスだと間違えたまま調査をしてしまっておりました。
ところがこのALBのアクセスログには下記のようなひっかけがあります。
必ずしも記録されているIPアドレス = 純粋なアクセス元IPアドレスではない
このお話で紹介する純粋なアクセス元IPアドレスとは次の事を指します。
- システムやサービスの利用者のIPアドレス
ドキュメントにはクライアントのIPアドレスって書いてあるじゃんと思う方もいらっしゃるかもしれません。
しかしながら、下記の言葉もセットで記載されております。
ロードバランサーの前にプロキシがある場合、このフィールドにはプロキシの IP アドレスが含まれています。
プロキシという言葉が記載されているように、ALBよりも上位に何かしらのサービス、機器がある場合そのサービス・機器のIPアドレスが記録されることとなります。
よくある構成の一例として、下記のような構成があります。
- CloudFrontやAkamaiなどのCDNを活用
- そのオリジンとして、ALBが存在
- 配下のEC2にアクセスが割り振られる
この場合、ALBから見たアクセスはCloudFrontやAkamaiなどといったCDNからのアクセスとなります。
そのため、ALBのアクセスログ上にはCloudFrontやAkamaiのIPアドレスが記録されることとなります。
その仕様を知らなかった筆者は記録されている内容について勘違いをしたまま調査を進めておりました。
そのため、下記の事をお伝えしたいと考えております。
その環境はどのような構成になっているかを押さえておく
構成を正しく把握できていない場合、今回以外のしくじりも起こりえます。
一例をあげると「許可設定をサーバー内のファイヤウォールに追加したけど接続が出来ない」といったしくじりも発生します。原因としては上位の機器にもファイヤウォールが存在し、そこにも許可設定が必要といったものがあげられます。
全てを頭で覚えるのが難しいものにせよ、構成図を見ながら設定箇所を洗い出す、アクセスの流れがどのように来ているか、アクセスの流れを制御しているものは何か、許可・拒否をしているものはないか
といった整理をする習慣をつけるといった心構えは必要となります。
余談
余談ですが、それならサーバー内のミドルウェア(例えばApache)のログから調査すればIPアドレスが分かるじゃんと思う方もいらっしゃるかもしれません。
確かにその通りではありますが、そこにもひっかけがあったりします。こちらのお話については明日の記事にて紹介をしていこうと思います。
最後に
拙い記事となりましたが、ALBの出力設定やひっかけポイントについてご紹介いたしました。
ここまでご拝読をいただきありがとうございます。