ALBの新機能、CloudWatch Logsに統合されたログ記録を試してみた

はじめに

2026年7月23日、従来はS3バケットへの配信のみだったALBのアクセスログ・接続ログ・ヘルスチェックログを、Vended Logs APIによりCloudWatch Logsロググループへ直接配信できるようになりました。

https://aws.amazon.com/jp/about-aws/whats-new/2026/07/amazon-cloudwatch-logs/

※東京リージョン、2026年7月時点の料金

https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-logs.html

検証内容

検証環境

配信設定

配信設定は次の3ステップです。

1. put-delivery-source — ALBをログの配信元として登録する
2. put-delivery-destination — CloudWatch Logsロググループを配信先として登録する
3. create-delivery — 配信元と配信先を紐付け、フォーマットを指定して配信を作成する

対応するログタイプは次の3種類です。

• ALB_ACCESS_LOGS
• ALB_CONNECTION_LOGS
• ALB_HEALTH_CHECK_LOGS

出力フォーマットと区切り文字の選択肢を表にまとめました。

フィールドの取捨選択はできず、Access Logs 34項目・Connection Logs 15項目・Health Check Logs 10項目がすべて出力されます。

コンソールでは、新機能はIntegrationsタブから設定します。

従来のS3配信（レガシー）はAttributesタブから設定でき、引き続き利用可能です。

同一のdelivery sourceから、異なるフォーマット・異なるロググループへ複数のdeliveryを並行して作成できます。今回は次の3配信が同時に稼働することを確認しました。

ログ確認

JSON形式で配信したアクセスログを、CloudWatch Logs Insightsでクエリしました。

fields @timestamp, type, elb_status_code, client_port, request_line, user_agent, actions_executed, conn_trace_id, ip_address
| sort @timestamp desc
| limit 10

検証で送信した6リクエストがすべて配信されていることを確認しました。JSON形式ではCloudWatch Logs Insightsがフィールドを自動解析するため、typeやelb_status_codeといったフィールドを直接参照できます。

{
  "type": "http",
  "time": "2026-07-24T02:43:09.548878Z",
  "elb": "app/alb-cwlogs-test/xxxxxxxxxxxxxxxx",
  "client_port": "203.0.113.1:4979",
  "target_port": "-",
  "request_processing_time": "-1",
  "target_processing_time": "-1",
  "response_processing_time": "-1",
  "elb_status_code": "200",
  "target_status_code": "-",
  "received_bytes": "128",
  "sent_bytes": "197",
  "request_line": "GET http://alb-cwlogs-test-xxxxxxxxxx.ap-northeast-1.elb.amazonaws.com:80/path5 HTTP/1.1",
  "user_agent": "curl/8.18.0",
  "ssl_cipher": "-",
  "ssl_protocol": "-",
  "target_group_arn": "-",
  "trace_id": "Root=1-6a62d13d-447a49680bbf5e3336d518b3",
  "domain_name": "-",
  "chosen_cert_arn": "-",
  "matched_rule_priority": "0",
  "request_creation_time": "2026-07-24T02:43:09.548000Z",
  "actions_executed": "fixed-response",
  "redirect_url": "-",
  "error_reason": "-",
  "target_port_list": "-",
  "target_status_code_list": "-",
  "classification": "-",
  "classification_reason": "-",
  "conn_trace_id": "TID_ea38a7ed01f3f64b9375d9926c5f7020",
  "transformed_host": "-",
  "transformed_uri": "-",
  "request_transform_status": "-",
  "ip_address": "203.0.113.2"
}

フォーマット比較

同じリクエストを3フォーマットで出力して容量を比べました。なお、plain形式ではフィールドが自動解析されず、Logs Insightsでは@messageの1行テキストとして扱われます。parseコマンドで手動パースは可能です。

CSV形式（カンマ区切り）の出力例です。

http,2026-07-24T02:48:03.663959Z,app/alb-cwlogs-test/xxxxxxxxxxxxxxxx,203.0.113.1:4985,-,-1,-1,-1,200,-,132,197,"GET http://alb-cwlogs-test-xxxxxxxxxx.ap-northeast-1.elb.amazonaws.com:80/csv-test5 HTTP/1.1","curl/8.18.0",-,-,-,"Root=1-6a62d263-2f7e4aff1e45ff8f0ecb663e","-","-",0,2026-07-24T02:48:03.663000Z,"fixed-response","-","-","-","-","-","-",TID_7e837b9425ba30419301a6a9ba62062f,"-","-","-",203.0.113.3

レガシー互換形式（スペース区切り）の出力例です。

http 2026-07-24T02:48:03.663959Z app/alb-cwlogs-test/xxxxxxxxxxxxxxxx 203.0.113.1:4985 - -1 -1 -1 200 - 132 197 "GET http://alb-cwlogs-test-xxxxxxxxxx.ap-northeast-1.elb.amazonaws.com:80/csv-test5 HTTP/1.1" "curl/8.18.0" - - - "Root=1-6a62d263-2f7e4aff1e45ff8f0ecb663e" "-" "-" 0 2026-07-24T02:48:03.663000Z "fixed-response" "-" "-" "-" "-" "-" "-" TID_7e837b9425ba30419301a6a9ba62062f "-" "-" "-" 203.0.113.3

同一リクエスト5レコードでの容量比較です。

CSVとレガシー互換は区切り文字がともに1文字のため同一サイズです。JSONはキー名のオーバーヘッドにより、plain形式の約2.53倍のサイズになります。一方で、JSON形式はLogs Insightsでフィールドが自動解析されるため、クエリの利便性に優れます。

配信タイムラグ

実際どのくらいで届くのか、@timestampと@ingestionTimeの差を見てみました。配信遅延は約2〜3分で、S3レガシーの5分/ファイルよりやや速い結果でした。

※ @timestampはJSON内のtimeフィールドから自動マッピング、@ingestionTimeはCloudWatch Logsへの取り込み時刻

料金について

配信課金はVended Logsの料金体系です。東京リージョン、2026年7月時点の単価は以下のとおりです。

一方、従来のS3レガシーログは配信自体が無料で、S3の保存費のみ発生します。

plain形式はJSONの約40%のデータ量で済むため、Vended Logsの課金を抑えたい場合はplain形式が有利です。

S3 Parquet変換との組み合わせや長期保持を含めた実コスト比較は、続編で検証予定です。

まとめ

ALBのアクセスログ・接続ログ・ヘルスチェックログをCloudWatch Logsへ直接配信できるようになりました。Vended Logs APIはALBのARNを指定するだけで配信が始まるため、Amazon ECS Express ModeやElastic Beanstalk環境など、マネージドに作成されたALBへのログ追加も簡単です。続編ではS3 Parquet変換を含むコストなど、レガシー設定との比較を深堀り予定です。

参考リンク

https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-access-logs.html

https://aws.amazon.com/cloudwatch/pricing/