2026年7月23日に発表されたアップデートでALBのログをCloudWatch Logsに出力出来るようになりました。実際、どのように設定をするのか確認するため検証してみました。
これまでは分析のためにCloudWatch Logsで見たい、Logs Insightsを使いたいとなると、S3に置かれたログファイルをLambdaを使ってCloudWatchLogsにPutする構成を自分で組む必要があったので運用面で便利になって嬉しいですね。例えば以下のような記事です。
何が変わったか
ALBのログがCloudWatch Logsのvended logsとしてサポートされました。対象はアクセスログ、コネクションログ、ヘルスチェックログの3種類です。
ALBのログ配信先はCloudWatch Logs、Data Firehose、S3の3つから選べるようになったこととなります。
従来のS3へのログ保存の扱い
従来のS3へのログ保存も継続して使えるとのことですが、ドキュメントを見ると「レガシーログ（legacy logs）」 という扱いをされていました。
これまでは「属性」タブからアクセスログなどを有効化したりしていましたが、「ログ配信は統合タブで設定できます」との案内がコンソールにでていました。
Log delivery to CloudWatch, Kinesis Firehose, and S3 is configurable through an integration with Logging - by Amazon CloudWatch. Visit Logging in the Integrations tab .（CloudWatch、Kinesis Firehose、およびS3へのログ配信は、 Amazon CloudWatchのLoggingとの統合を通じて設定できます。統合タブのLoggingをご覧ください。）
S3へのログ配信は「属性」タブ、「統合」タブ どちらからも設定できます。
■属性タブ
■統合タブ
何が嬉しいか
CloudWatch Logsに出力することで嬉しいことは、即時性と可視性の向上だと思います。
S3に配信する際は5分間隔でログファイルが作成されると思いますが、CloudWatch Logsに配信する際は即時に配信されます。
その他にもCloudWatch LogsのLogs Insightsやメトリクスフィルターでアラームが作れるなど運用面で便利になると思います。
設定してみる（アクセスログ）
ALBの統合タブから「ログ記録」という箇所をクリックし、「追加」をクリックします。
従来にはなかった「Amazon CloudWatch Logsへ」というボタンが追加されています。
ログタイプを選べます。選択できるのは、S3などに配信できるものと同じです。
今回はアクセスログ（ALB_ACCESS_LOGS）を選択します。
ログタイプを選択すると、配信先ロググループ名が自動入力されます。
「/aws/vendedlogs/」のプレフィックスがついたロググループが自動作成されるみたいです。
出力形式はplainとjsonから選べます。
アクセスログで設定するとlog_stream_created_by_aws_to_validate_log_delivery_subscriptionsというログストリームが作成されているのが確認できました。
設定後に確認できたストリームは、S3配信の際に作成されるELBAccessLogTestFileと同じ役割かと思います。
同じログタイプで別の出力形式を選択してロググループ作成
アクセスログでjson と plain どちらもログ配信設定できるのかを確認してみました。
結論、どちらも作成できました。実際の運用ではあまり想定されないかもしれませんが一応気になったので検証しています。
ただ、この場合には同じストリームにログが流れます。見づらくなるのでロググループを明示的に分けたほうが良さそうです。（画像の上がplain・下がjsonです）
ログが届くまでの時間を測ってみる
CloudWatch LogsにALBログ配信できて嬉しいのは、確認できるまでの早さだと思います。従来のS3配信はロードバランサーノードごとに5分間隔でファイルが作られる仕様で、障害調査中の5分はかなり長く感じるかもしれません。
同じALBにS3配信とCloudWatch Logs配信の両方を有効にして、120リクエストを流したあと、それぞれどのくらいの時間でログが届くかを計測しました。
当然ですがCloudWatch LogsはS3に比べてかなり早いです。障害対応中には早くログみたい時があると思うのでありがたいですね。
| 配信先 | トラフィック終了から到着まで |
|---|---|
| CloudWatch Logs | 3秒 |
| S3（レガシー） | 271秒（4分31秒） |
コスト比較
運用面を考えるとコストのお話は欠かせませんよね。いくら便利とはいえどコストが激増したら導入は難しいです。
実際にどれだけのログ量になるか
同じALBに180リクエストを流して、S3とCloudWatch Logsの両方に配信した結果を比べました。
| 配信先 | 形式 | 課金対象のサイズ | 1リクエストあたり |
|---|---|---|---|
| S3 | plain（gzip圧縮） | 13,723 B | 約76 B |
| CloudWatch Logs | plain | 約97,300 B | 約541 B |
| CloudWatch Logs | json | 約219,600 B | 約1,220 B |
S3に置かれるログはgzipで圧縮されるので、非圧縮だと97,349バイトあるものが約1/7の13,723バイトまで縮みます。
一方でCloudWatch Logsは圧縮されないので同じplain形式でも7倍の差がつきます。
jsonを選ぶとフィールド名が全レコードに付くせいか、plainの2倍強となりました。jsonは読みやすいですが取り込み量が増えます。（この時代に人間の読みやすさよりAIにとっての読みやすさが大事だと思うのでここはAIと要相談）
月1億リクエストで試算する
1リクエストあたりの実測値をそのまま伸ばすと、こうなります。
| 構成 | 月間のログ量 | 取り込み | 保存 | 合計 |
|---|---|---|---|---|
| S3（gzip） | 約7.1 GiB | 無料 | 約0.18 USD | 約0.18 USD |
| CloudWatch Logs（plain） | 約50 GiB | 約38 USD | 約1.7 USD | 約40 USD |
| CloudWatch Logs（json） | 約114 GiB | 約86 USD | 約3.8 USD | 約90 USD |
S3に置くだけなら月0.2ドル弱で済んでいたものが、CloudWatch Logsに全部流すと40ドルから90ドルになります。200倍から500倍です。
実際の運用だとAthenaでS3にあるログを分析することになるかと思います。Athenaで全量をスキャンした場合の追加コストも調べてみました。
| 分析方法 | 1回のフルスキャン |
|---|---|
| Logs Insights（plain 50 GiB） | 約0.38 USD |
| Athena（gzip 7.1 GiB） | 約0.04 USD |
金額だけを見ればS3とAthenaの組み合わせが良さそうです。
金額面ではS3のほうが良さそうですが、分析しようとするとAthenaが必要です。Athenaを使うにはテーブル定義を書き、パーティションを設定し、クエリのたびにSQLを組み立てる必要があります。
CloudWatch Logsなら設定してすぐLogs Insightsで検索でき、メトリクスフィルターでアラームも作れます。今流れているリクエストを確認することもできます。このような設定・運用の手間が省けるのがCloudWatch Logsの利点な気がします。
なので、全部をCloudWatch Logsに流すのではなく、「障害調査中だけ有効にする」、「基本はS3に置いてCloudWatch Logsは絞ったログタイプだけにする」といった使い分けが現実的だと思いました。
まとめ
設定は簡単ですがコストはちょっと高くなります。個人的には基本的にS3配信で良いかと思いました。
リアルタイムで監視する要件があれば有効化するのが良さそうです。
決め方として、これまでのS3配信で足りるか、足りない場合はCloudWatch Logsへの配信を検討する。ただ常時CloudWatch Logsへの配信が必要かなどの観点で検討すると良いと思いました。
検証中に、公開して数十分でボットからのスキャンがアクセスログに記録されていました。検証用のALBでも、セキュリティグループは自分のIPに絞っておくのが良いと改めて思いました！