ALBのヘルスチェックログ機能を検証してみました

記事タイトルとURLをコピーする

はじめに

2025年11月21日にAWSから発表されたApplication Load Balancer(ALB)のヘルスチェックログ機能について、実際にドキュメントを確認して検証してみました。

新機能の概要

新機能であるヘルスチェックログは、ターゲットへのヘルスチェックの結果情報をS3バケットに保存する機能です。従来は、ALBからターゲットにアクセスした際のエラー内容についてはユーザー側からは確認ができず、サポートとやり取りする必要がありました。今回のアップデートにより、サポートを介さずに迅速な調査が行えるようになります。

機能概要図

主な特徴は以下の通りです。

  • 詳細なデータ: ヘルスチェックが失敗した際の具体的な理由やタイムスタンプが確認できます
  • 自動配信: S3バケットに自動的にログファイルが配信されます(5分間隔)
  • 追加料金なし: 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/*"
    }
  ]
}

本題からは逸れますが、従来であればAWSアカウントIDを指定したバケットポリシーを利用していたかと思いまが、最近のアップデートでlogdelivery.elasticloadbalancing.amazonaws.comを利用したポリシーが記述できるようになったみたいですね。

続いて、ALBの属性タブにヘルスチェックログの項目が追加されていますので、こちらに先ほどのポリシーを設定したバケットを指定します。

ヘルスチェックログの設定画面

以上で設定は完了です。

ログの構造

まずは、S3バケットを覗いてみましょう。

ファイル名は以下のようになっています。

bucket[/prefix]/AWSLogs/aws-account-id/elasticloadbalancing/region/yyyy/mm/dd/health_check_log_aws-account-id_elasticloadbalancing_region_app.load-balancer-id_end-time_ip-address_random-string.log.gz

S3に保存されたヘルスチェックログ

5分おき、AZに分散されているALB毎にログが作成されていることが確認できます。Gzipで圧縮されており、1ファイルあたりのサイズは1KB未満ですね。ヘルスチェックの間隔にもよりますが、とりあえず有効にしても差し支えのない程度の料金に収まるのではないでしょうか。

なお、ログのファイル名やフォーマットについてはドキュメント)に記載があります。

続いて、ログの中身を見ていきます。ヘルスチェックログは以下の8つのフィールドで構成されています。

type(1) time(2) latency(3) target_addr(4) target_group_id(5) status(6) status_code(7) reason_code(8)

実際に、TargetとなっているFargateへのアクセスをセキュリティーグループで遮断してみました。

成功例

http 2025-12-18T08:45:57.850424Z 0.00481831 10.0.184.60:80 AlbAnd-MyFar-FECJNQUADRBF PASS 200 -

失敗例

http 2025-12-18T08:45:44.704945Z 5.005880426 10.0.169.98:80 AlbAnd-MyFar-FECJNQUADRBF FAIL - RequestTimedOut

通信不可のため、タイムアウトしていることがログから確認できました。

ユースケース

どういった場面で役に立つか考えてみました。

1. トラブルシューティングの高速化

従来はAWSサポートに問い合わせが必要だった詳細な失敗理由が、リアルタイムで確認できるようになりました。

2. パフォーマンス分析

ヘルスチェックのレイテンシ情報から、ターゲットの応答性能を継続的に監視できます。

注意点

いくつか注意したほうが良い点も記載しておきます。

  • リージョン制限: S3バケットはALBと同じリージョンに作成する必要があります。アカウントは別でも構いません
  • 暗号化: 現状サポートされるのはSSE-S3のみです
  • ログ配信間隔: 5分間隔での配信です。リアルタイムではありません

最後に

今回のアップデートで、障害のトラブルシューティングが迅速に行えるようになりました。

全てのAWS商用リージョン、GovCloud、中国リージョンで利用可能です。追加料金もS3ストレージコストのみという点も魅力的です。ALBを使用している環境では、ぜひ有効化を検討してみてください。

石田順一(記事一覧)

カスタマーサクセス部 CS3課