0.導入
本記事では以下を記載します。
ALBのアクセスログをAthenaで分析するやり方および費用面に関する注意点を
以下のAWSドキュメントを参考にして、実際に設定を行いながら説明します。
なお、今回は内部ALBで行っていますが、外部向けALBでも設定の仕方は同じです。
Application Load Balancer のアクセスログを有効にする

目次
1.設定方法
1-1.S3バケットの作成
1-2.ALBアクセスログの設定
1-3.Athenaの設定
1-3-1.ワークグループ作成
1-3-2.データベース作成
1-3-3.テーブルの作成
1-4.クエリで分析
2.費用を抑えるポイント
2-1.Athenaの料金
2-2.アクセスログにライフサイクルを設定
2-3.クエリのスキャン量の上限設定
2-4.スキャンの対象範囲のデータ量を確認
2-5.ALBのモニタリングで確認

1.設定方法

1-1.S3バケットの作成
アクセスログを保管するS3バケットを作成します。
注意点としましては、バケットポリシーでELBがバケットにログを書き込めるよう設定する必要があります。
今回であれば東京リージョンのELBアカウントID(582318560864)をソースとして設定します。

{
"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/aws-account-id/*"
}
]
}

1-2.ALBアクセスログの設定
ALBのアクセスログを有効化します。
属性タブの編集をクリックし、アクセスログを有効化し先ほど作成したバケットを選択します。(プレフィックスも指定できます)

設定できれば属性タブにアクセスログの保存先が表示されます。

また、対象のバケットにAWSLogs/というフォルダが作成されます。

1-3.Athenaの設定
Athenaでアクセスログをクエリするための初期設定を行います。

1-3-1.ワークグループ作成
まずはAthenaのワークグループを作成します。デフォルトのprimaryを利用しても問題ありませんが
後述するワークグループによるクエリスキャン量制御の設定のために作成します。
左側のワークグループから「ワークグループを作成」をクリックし、名前を設定したら今回はデフォルト設定で作成します。
「ワークグループを作成」を選択

ワークグループの設定画面(今回はデフォルトで作成)

1-3-2.データベース作成
左側のクエリエディタをクリックし、右上のワークグループで先ほど作成したワークグループを選択します。
下記クエリを実行し、任意のデータベースを作成します。(今回はalb_db_test)
作成したら、左側のデータベースのプルダウンから、作成したデータベースを選択できるようなります。

1-3-3.テーブルの作成
先ほど作成したデータベースを選択し、
以下AWSドキュメントのクエリを拝借し、任意のテーブルを作成します。（今回はalb_logs)
ALB ログのテーブルの作成
LOCATIONに分析したいアクセスログのS3のパスを指定します。
テーブルの作成範囲は「2-4.スキャンの対象範囲のデータ量を確認」を参照ください。
例えば、以下のように分析したい日付のフォルダに行き「S3 URIをコピー」でパスをコピーできます。

作成したら、左側のテーブル欄に作成したテーブルが選択できるようになります。

1-4.クエリで分析
例として特定urlへのアクセス数を調べる以下クエリを実行します。
SELECT count(*) from alb_logs where request_url like '%特定url%'

SQL文の説明やその他のクエリの例文はここでは割愛します。
アクセスログにある各列やSELECTクエリの作成方法は以下ドキュメントに記載されています。
Application Load Balancer のアクセスログ
Athena SQLの使用

2.費用を抑えるポイント
Athenaはサーバーレスサービスで、クエリを実行するデータのスキャン量に応じて料金が算出されます。
思わぬ支出を避けるためポイントを以下に記載します。

2-1.Athenaの料金
東京リージョンの場合は、クエリ単位で1TBあたり USD5.00となります。
Amazon Athena の料金
100MBくらいのデータ量のスキャンを実施してみましたが、請求はありませんでしたので、少量であれば無料で使うことができます。
スキャンするデータ量に気をつければ予想外に料金が跳ね上がることをありませんが、
Lambdaでクエリ実行などを行う場合は、ループしないように気をつけましょう。

2-2.アクセスログにライフサイクルを設定
セキュリティ要件でアクセスログを何年も保管する必要がある場合は別ですが、
ALBアクセスログの保存期間をS3のライフサイクルルールで設定できます。
ライフサイクルを設定することでアクセスログの保管料(S3の料金)を抑えることができます。
また、アクセスログを全てスキャンするクエリを間違えて実行してしまったとしても傷が浅く済みます。
設定は以下のように行います。
対象バケットの管理タブから「ライフサイクルルールを作成する」を選択し
任意の日数後に削除するよう設定。

設定画面

設定後

2-3.クエリのスキャン量の上限設定
「1-3-1.ワークグループ作成」でも少し記載しましたが、
ワークグループごとにクエリのスキャン量の上限を設定できます。間違えて膨大の量をスキャンするクエリを実行してしまってもキャンセルされます。設定は以下のように行います。
対象ワークグループの「データ使用状況の制御」タブから管理を選択し、
1回あたりのクエリの最大スキャン量を指定します。


2-4.スキャンの対象範囲のデータ量を確認
バケット全体のアクセスログをスキャンする場合は
対象バケットのメトリクスタグでバケットサイズを確認できます。

アクセスログの日付ごとにデータ量を確認したい場合は、以下の方法で確認します。
対象日付のアクセスログのフォルダにアクセスし「S3 URIをコピー」をクリックします。

以下コマンドの[S3URI]の箇所にコピーしたS3 URIを代入して、AWS CLIで実行します。

aws s3 ls [S3URI] --recursive --human --sum

実行結果例

$ aws s3 ls s3://<バケット名>/AWSLogs/<アカウントID>/elasticloadbalancing/ap-northeast-1/2024/02/20/ --recursive --human --sum
~中略(オブジェクト一覧が表示されます)~
Total Objects: 201
Total Size: 898.3 KiB

月ごとや日付ごとで上記のコマンドを実行し、分析したい範囲と料金の折り合いをつけます。

2-5.ALBのモニタリングで確認
ALBのモニタリング機能でリクエスト数やターゲット応答時間を確認できます。
アクセスログのライフサイクルで設定した期間より前のデータも確認できます。
Athenaを実行すると費用が発生するので、まずはここで全体のアクセス数を確認します。
ALBのモニタリングでリクエスト数や傾向を確認することで、
年単位で分析しようとしたが、月毎に差異がないので、1ヶ月のサンプリングで十分だ、とか
月単位のサンプリングで分析しようとしたが、リクエスト数が少ないので年単位で分析しても費用が少なそうだ
など判断材料のひとつになるかと思います。

費用削減にはその他にデータの圧縮、バーティション化などございますが、
今回は初級ということでここまでといたします。

以上