AWS ELBのトラブルシューティングとよくあるエラー対処法を初心者向けに徹底解説！

1. ELBトラブルシューティングの基本：原因を特定する3つのステップ

1. ELBトラブルシューティングの基本：原因を特定する3つのステップ

AWSのELB（Elastic Load Balancing）は、アクセスを複数のサーバーに振り分ける「交通整理」の役割を果たします。トラブルが発生した際、初心者がまず行うべき基本ステップは以下の3点です。どこに問題があるかの「切り分け」を最初に行うのが解決の近道です。

① ログとメトリクスで現状を把握する

まずは、Google CloudWatch（クラウドウォッチ）を使って「何が起きているか」を数値で確認しましょう。例えば、エラーが急増しているのか、特定の時間帯だけ発生しているのかをグラフで視覚的に判断できます。

より詳細な調査には「アクセスログ」が有効です。ELBを通過したすべてのリクエストが記録されており、以下のような形式でエラーを確認できます。

# アクセスログのイメージ（簡略化）
# [タイムスタンプ] [ELB名] [クライアントIP] [ターゲットIP] [リクエスト処理時間] [ELBのステータスコード] [ターゲットのステータスコード]
2026-02-01T13:00:01 my-elb 192.168.0.1 10.0.1.50 0.001 502 502

② ヘルスチェックのステータスを確認する

ELBは、接続先のサーバー（ターゲット）が正常に動いているかを定期的に確認しています。マネジメントコンソールの「ターゲットグループ」画面で、ステータスが「Healthy（正常）」になっているか確認してください。「Unhealthy（異常）」の場合は、ELBがそのサーバーを切り離している状態です。

③ ネットワーク疎通とセキュリティ設定の確認

そもそも通信が許可されているかを確認します。Linuxコマンドが使える環境であれば、curlコマンドを使って、サーバー単体で応答があるかテストしてみるのが一般的です。

curl -I http://10.0.1.50/health
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 15

このように「200 OK」が返ってこない場合は、セキュリティグループの設定や、アプリケーション自体が停止している可能性が高いと判断できます。この3つのステップを順番に踏むことで、複雑に見えるネットワークトラブルもスムーズに解決へと導けます。

2. よくあるエラーと原因

2. よくあるエラーと原因

初心者が遭遇しやすいELBのエラーをまとめました。

• ターゲットが「Unhealthy」になる：ヘルスチェックの設定が正しくない、またはアプリケーションが応答していない。
• 504 Gateway Timeout：バックエンドサーバーが応答に時間をかけすぎている。
• 502 Bad Gateway：ターゲットインスタンスがエラーを返している。
• SSL証明書エラー：HTTPS（エイチティーティーピーエス）通信で証明書の設定ミスがある。
• 接続ができない：セキュリティグループやネットワークACLが通信を遮断している。

3. ヘルスチェックに関するトラブル

3. ヘルスチェックに関するトラブル

ヘルスチェックとは、ELBがバックエンドのサーバーが正常に動いているかを監視する仕組みです。失敗が続くと「Unhealthy」と判定され、リクエストが送られなくなります。

解決のポイントは以下の通りです。

• 正しいパス（例：/health）を指定しているか確認する
• アプリケーションがリクエストに応答するよう設定する
• タイムアウトや間隔の値を適切に調整する

4. ネットワークとセキュリティ設定の問題

4. ネットワークとセキュリティ設定の問題

ELBがバックエンドに接続できない原因の多くは、セキュリティグループやネットワークACLの設定ミスです。

チェックすべきポイントは以下です。

• ELBのセキュリティグループが正しいポート（HTTP:80、HTTPS:443）を許可しているか
• ターゲットインスタンスのセキュリティグループがELBからのアクセスを許可しているか
• VPC（ブイピーシー、仮想ネットワーク）のルートテーブルやACLに問題がないか

5. SSL証明書エラーの対処法

5. SSL証明書エラーの対処法

HTTPSを利用する場合、SSL証明書の設定ミスで接続できないことがあります。

主なチェック項目は以下です。

• 証明書が有効期限切れになっていないか
• 正しいドメイン名の証明書を設定しているか
• 証明書チェーン（中間証明書）が正しく設定されているか

AWS Certificate Manager（エーダブリューエス サーティフィケート マネージャー）を使うと、証明書の発行と更新が簡単になります。

6. レスポンスコードエラーの解析

6. レスポンスコードエラーの解析

アクセスログを確認すると、HTTPステータスコードが記録されています。例えば、500系エラーが多い場合はアプリケーション側に原因がある可能性があります。

• 502 Bad Gateway → ターゲットが異常終了している
• 503 Service Unavailable → ターゲット数が不足している
• 504 Gateway Timeout → 処理時間が長すぎる

これらのエラーはアプリケーションの調整やスケーリングで改善できます。

7. トラブルシューティングに役立つツール

7. トラブルシューティングに役立つツール

AWSにはトラブル解決を支援する便利なサービスがあります。

• CloudWatch（クラウドウォッチ）：メトリクスやログを監視する
• VPC Flow Logs（ブイピーシー フローログ）：ネットワーク通信を記録して解析する
• AWS X-Ray（エックスレイ）：リクエストの流れを可視化してボトルネックを特定する

これらを組み合わせることで、問題の原因を素早く特定できます。

まとめ

まとめ

AWSを利用したインフラ構築において、AWS ELB（Elastic Load Balancer）のトラブルシューティングは避けて通れない重要なスキルです。本記事では、初心者が直面しやすいエラーの種類から、具体的な解決策、そして効率的な調査方法までを詳しく解説してきました。

エラーを未然に防ぐためのチェックリスト

ELBのトラブルを未然に防ぎ、高可用なシステムを維持するためには、設計段階からの意識が大切です。特に以下のポイントは、不具合が発生した際にも真っ先に確認すべき項目となります。

• ヘルスチェックパスの妥当性： アプリケーション側で200 OKを返す専用のエンドポイント（例: /healthcheck）を用意しているか。
• セキュリティグループの連動： ELBからのインバウンド通信を、ターゲットとなるインスタンス側で許可しているか。
• アイドルタイムアウト設定： 重いバッチ処理やファイルアップロードがある場合、デフォルトの60秒で足りているか。
• クロスゾーン負荷分散： アベイラビリティーゾーン間でのトラフィックの偏りを防ぐ設定が有効か。

実践的な調査コマンドと設定例

トラブルが発生した際、エンジニアが真っ先に行うのは「現場（サーバー）」の状態確認です。例えば、ELBが「Unhealthy」を返している場合、まずはターゲットのEC2内でWebサーバーが正しく応答しているかをローカルで確認する必要があります。

以下のコマンドは、Linuxサーバー内部から自分自身のHTTPステータスを確認する際によく使われます。

curl -I http://localhost/health
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 15
Connection: keep-alive

もし、ここで「Connection refused」や「404 Not Found」が出る場合は、ELBの問題ではなく、サーバー内のWebアプリケーション（ApacheやNginx）の設定不備であることが特定できます。

IaCによる設定ミス防止（Terraformの例）

手動によるマネジメントコンソールでの設定は、入力ミスや手順漏れが発生しやすいものです。最近の開発現場では、Terraform（テラフォーム）などのInfrastructure as Codeツールを使い、設定をコード化して管理するのが主流です。これにより、セキュリティグループの「許可し忘れ」といった人為的ミスを劇的に減らすことができます。

以下は、Application Load Balancer (ALB) のリスナーとターゲットグループを定義する際のコードサンプルです。

# ALBリスナーの定義
resource "aws_lb_listener" "front_end" {
  load_balancer_arn = aws_lb.main.arn
  port              = "80"
  protocol          = "HTTP"

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.app_tg.arn
  }
}

# ターゲットグループのヘルスチェック設定
resource "aws_lb_target_group" "app_tg" {
  name     = "my-app-tg"
  port     = 80
  protocol = "HTTP"
  vpc_id   = aws_vpc.main.id

  health_check {
    path                = "/health"
    interval            = 30
    timeout             = 5
    healthy_threshold   = 2
    unhealthy_threshold = 2
    matcher             = "200"
  }
}

このように、設定値を明確にコードとして残しておくことで、「なぜ通信できないのか」をチームメンバーと共有・レビューしやすくなります。

AWS CLIを活用したステータス確認

コンソール画面が開けない環境や、自動監視スクリプトを組みたい場合には、AWS CLIが非常に強力です。現在のターゲットのヘルス状態を一括で取得するコマンドを覚えておくと、トラブル発生時の初動が早くなります。

aws elbv2 describe-target-health --target-group-arn arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
{
    "TargetHealthDescriptions": [
        {
            "Target": {
                "Id": "i-0abcdef1234567890",
                "Port": 80
            },
            "TargetHealth": {
                "State": "unhealthy",
                "Reason": "Target.ResponseCodeMismatch",
                "Description": "Health check target responded with 404"
            }
        }
    ]
}

上記の出力結果から、ターゲットが「unhealthy」である理由が「404（パスが見つからない）」であることを瞬時に判断できます。

最後に

ELBは非常に高度に抽象化されたサービスですが、その裏側にあるのは標準的なネットワーク技術（TCP/IP、HTTP/HTTPS、DNS）です。トラブルが起きたときは、パケットが今どこにあり、どこで止まっているのかを一つずつ紐解いていくことが解決への近道です。CloudWatchのメトリクス（HTTPCode_ELB_5XXなど）を監視し、異常を検知した際にアラートが飛ぶように設定しておくことも、プロフェッショナルな運用には欠かせません。