ALBのアクセスログをS3へ出力する際のバケットポリシーの記載方法

この記事を書いたメンバー:

榊原慶太

ALBのアクセスログをS3へ出力する際のバケットポリシーの記載方法

目次

BeeXの榊原です。今回はALBのアクセスログをS3に出力する際のS3バケットポリシーの記述についてまとめます。主に「Access Denied for bucket: xxx. Please check S3bucket permission」で困っている方の参考になれば幸いです。

前提

想定構成は以下の通りです。同一アカウント、リージョン内を想定しています。
※構成図から省いていますが、検証部分ではALBとEC2のペアをもう一つ追加しています。



基本説明

バケットポリシーのおさらい

バケットポリシーはS3バケットへのアクセスをバケット単位で管理するポリシーですが、今回の内容を抑えるにあたり重要な内容は下記の内容です。引用元はAWS Blackbelt S3 セキュリティ編です。

今回は同じアカウント内のケースなので、バケットポリシーかIAMポリシーのどちらかで明示的な許可が必要です。

ALBはロードバランサー、あるいはターゲットグループ作成時に自動で作成される、サービスにリンクされたロール「AWSServiceRoleForElasticLoadBalancing」を利用します。

Elastic Load Balancing は、 という名前のサービスにリンクされたロールAWSServiceRoleForElasticLoadBalancingを使用して、ユーザーに代わって他の AWS のサービスを呼び出します。

AWSServiceRoleForElasticLoadBalancing は elasticloadbalancing.amazonaws.comサービスを信頼してロールを引き受けます。

<省略>

AWSServiceRoleForElasticLoadBalancing ロールを手動で作成する必要はありません。このロールは、ロードバランサーまたはターゲットグループの作成時に Elastic Load Balancing によって作成されます。
(引用元:Elastic Load Balancing のサービスにリンクされたロール

サービスにリンクされたロールは、アクセス権限の閲覧は可能ですが、編集はできません。

IAM 管理者は、サービスにリンクされたロールのアクセス許可を表示できますが、編集することはできません。(引用元:IAM ロール

よって、今回バケットポリシーで明示的にALBに対しアクセス許可を与える必要があります。ここでアクセス許可がない場合はALBの属性からアクセスログの設定をする際、「Access Denied for bucket: xxx. Please check S3bucket permission」と下画面のようにエラーが表示されます。

では、どのような記載がバケットポリシーに必要か見ていきましょう。

具体的に記載すべきバケットポリシーの内容

今回は東京リージョンなので下記内容を記載します。

 {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::582318560864:root"
      },
      "Action": "s3:PutObject",
      "Resource": "s3-bucket-arn/*"
    }
  ]
}

アカウントID部分の「582318560864」の値は固定(東京リージョン以外だと別の値)です。ご自身のアカウントIDを間違えて入れないよう注意してください。Resource部分はS3バケットはご自身のS3バケットの内容に書き換えてください。詳細はこちらのAWSの公式ドキュメントをご覧ください。Denyを利用する方法もありますが、今回は割愛します。

プレフィックスについて

アクセスログを出力する際のプレフィックスですが結論から言うと、設定したプレフィックスの下に自動で「/AWSLogs/アカウントID」が記載される形で格納されます。例えばプレフィックスに「s3://test-sakaki-bucket/testALB01」と設定するとS3には「s3://test-sakaki-bucket/testALB01/AWSLogs/アカウントID/」の下にアクセスログが格納されます。

※プレフィックスリストにAWSLogsを含むことはできませんでした。


アクセスログが正常に設定できたら、このプレフィックスリスト下に「ELBAccessLogsTestFile」が作成されます。中身を確認すると以下のように出力されました。(一部マスクしています)

Enable AccessLog for ELB: app/ALB名/XXX at 2025-01-29T07:47:25.944Z

実際にやってみた

CloudFrontとEC2についてはメインでないため、構築手順は省略します。
「testALB20250129」、「testALB20250129-02」のALBを2つ用意しました。

属性を編集してアクセスログを同じS3バケットに出力します。今回はどちらも「s3://test-sakaki-bucket/testALB03」としました。

どちらのALBにもCloudFrontを介して接続しました。しばらく時間がたってからS3バケットを確認すると、ELBAccessLogTestFileがあるディレクトリにさらにelasticloadbalancingのフォルダが追加されていました。


さらにそこから掘り進めていくと下記のようにログが格納されていました。フォルダ構成は「設定したプレフィックス/AWSLogs/アカウントID/elasticloadbalancing/リージョン/年/月/日」となっています。

ALB毎にフォルダは分割されないので、プレフィックスを設定する際はALB毎に判別がつくよう設定しましょう。

短いですが、本記事は以上です。ここまでお読みいただきありがとうございました。

※余談ですが、S3のVPCエンドポイントがなくともアクセスログ自体は出力されました。バケットポリシーが正しく書けて入ればALBとS3間の通信経路は特に心配しなくてよさそうです。

カテゴリー
タグ

この記事を書いたメンバー

榊原慶太
榊原慶太

技術検証、re:Invent参加、AWS資格全冠のための勉強教材等、幅広く記事にしています。皆様のお役に立てば幸いです。最近は会社ブログメインで記事投稿しています。

Pick upピックアップ

Search記事を探す

キーワード

SAPシステムや基幹システムのクラウド移行・構築・保守、
DXに関して
お気軽にご相談ください

03-6260-6240 (受付時間 平日9:30〜18:00)