ALB環境でのWeb Serverインバウンド接続トラブルシューティング ── 1台だけつながらない原因の切り分け

概要

Application Load Balancer（ALB）で負荷分散されたWeb Server群のうち、1台だけがインターネットからの接続を受信できないというトラブルは、実務でも試験でも頻出のシナリオです。

このようなケースでは、ネットワークACLやSecurity Group、仮想セキュリティアプライアンスのルールセットが正しいことが確認済みであっても、接続できない原因が残ることがあります。この記事では「複数台のうち1台だけ」という条件に着目して、確認すべきポイントを整理し、ALBのターゲットグループとENI単位のSecurity Group設定という2つの観点からトラブルシューティングの手順をまとめます。

この記事のメリット

• ALB + Web Server構成におけるトラフィックフローを理解できる
• 「1台だけの問題」に対するトラブルシューティングの考え方を習得できる
• ENI単位のSecurity Group設定の重要性がわかる
• ALBターゲットグループの役割とヘルスチェックの仕組みを把握できる
• ルートテーブルやサブネット設定が1台固有の問題にならない理由を理解できる
• SCS試験でALB関連のトラブルシューティング問題を正確に判断できるようになる

技術解説

ALB + Web Server構成のトラフィックフロー

ALBを使用した一般的なWeb Server構成では、インターネットからのトラフィックは以下の経路をたどります。

flowchart LR
      Internet[インターネット] --> IGW[IGW] -->
  VSA[仮想セキュリティ<br>アプライアンス] --> ALB[ALB] --> EC2[Web
  Server<br>（EC2）]

各コンポーネントの役割は以下のとおりです。

このフローにおいて、ネットワークACL・Security Group・仮想アプライアンスのルールは、すべてのWeb Serverに共通して適用されます。そのため、これらのルールが正しければ、1台だけが接続を受信できない原因にはなりません。

トラブルシューティングの考え方：「1台だけの問題」はインスタンス固有の設定を疑う

複数のWeb Serverのうち1台だけが問題を起こしている場合、全サーバーに共通する設定ではなく、そのインスタンスに固有の設定に原因がある可能性が高くなります。この切り分けがトラブルシューティングの出発点です。

全サーバー共通の設定（1台だけの原因にならない）

• ネットワークACL：サブネット単位で適用されるため、同じサブネット内のサーバーには同一のルールが適用される
• ルートテーブル：サブネット単位で関連付けられるため、同じサブネット内のサーバーは同じルーティングを使用する
• 仮想セキュリティアプライアンスのルール：トラフィックの検査ルールは全トラフィックに共通で適用される
• 仮想アプライアンスからWeb Serverサブネットへのルート設定：ルーティングはサブネット単位のため、1台だけに影響しない

インスタンス固有の設定（1台だけの原因になりうる）

• ENIに設定されたSecurity Group：インスタンス（ENI）単位で異なるSecurity Groupを設定できる
• ALBターゲットグループへの登録：特定のインスタンスだけ登録されていない、またはヘルスチェックに失敗している可能性がある

ENI単位のSecurity Group設定の重要性

Security Groupは「ルールセットが正しい」ことと「正しいSecurity Groupがアタッチされている」ことは別の問題です。問題文で「Security Groupのルールセットは正しい」と言及されている場合でも、そのSecurity Groupが対象インスタンスのENIに正しく適用されているかは別途確認が必要です。

たとえば、以下のようなケースが考えられます。

• 問題のWeb ServerのENIに、Web Server用のSecurity Groupではなく別のSecurity Groupが誤ってアタッチされている
• インスタンスの再作成や設定変更時に、Security Groupの関連付けが外れた
• 複数のENIがアタッチされており、トラフィックを受信するENIに適切なSecurity Groupが設定されていない

EC2インスタンスには1つ以上のENI（Elastic Network Interface）がアタッチされており、Security GroupはENI単位で設定されます。同じVPC内のインスタンスであっても、ENIごとに異なるSecurity Groupを設定できるため、1台だけ異なる設定になっている可能性があります。

ALBターゲットグループの役割とヘルスチェック

ALBはターゲットグループに登録されたインスタンスにのみトラフィックを分散します。ターゲットグループに関連する問題として、以下の2つのパターンがあります。

パターン1: ターゲットグループに登録されていない

そもそもターゲットグループにWeb Serverが登録されていなければ、ALBからトラフィックが転送されません。インスタンスの追加や置き換え時に登録漏れが発生することがあります。

パターン2: ヘルスチェックに失敗している

ターゲットグループに登録されていても、ヘルスチェックに失敗してステータスが unhealthy になっているインスタンスにはトラフィックが転送されません。ただし、ALBにはフェイルオープンの仕組みがあり、アベイラビリティーゾーン内の健全なターゲット数が設定されたしきい値を下回った場合、そのゾーンの全ターゲット（unhealthy を含む）にトラフィックを送信します。デフォルトでは、このしきい値は「off」（1台でも healthy なターゲットがあれば通常どおり分散する）に設定されています。

ヘルスチェックの失敗原因としては以下が考えられます。

• Web Serverのアプリケーションが正常に動作していない
• ヘルスチェックのパス（デフォルト: /）が期待するHTTPステータスコード（デフォルト: 200）を返さない
• ヘルスチェックのレスポンスがタイムアウト（デフォルト: 5秒）している
• ヘルスチェックのポートがSecurity Groupで許可されていない

確認すべき項目の比較表

実践

ここでは、ALB環境で1台のWeb Serverだけがインターネットからの接続を受信できない場合のトラブルシューティング手順をコンソールで説明します。

前提条件

• リージョン: ap-northeast-1（東京）
• VPC・サブネットが構成済みの状態
• ALBが作成済みで、ターゲットグループにWeb Server（EC2インスタンス）が登録されている状態
• Web Server用のSecurity Group（HTTP 80番ポートを許可）が作成済みの状態

作成済みリソース一覧

手順1: ALBターゲットグループの登録状況を確認する

まず、問題のWeb Serverがターゲットグループに正しく登録されているかを確認します。

1. AWSマネジメントコンソールにログインし、右上のリージョンが「アジアパシフィック（東京） ap-northeast-1」であることを確認します。
2. 上部の検索バーに EC2 と入力し、表示された「EC2」を選択します。
3. 左側ナビゲーションの「ロードバランシング」→「ターゲットグループ」を選択します。
4. ターゲットグループの一覧から web-target-group を選択します。
5. 「ターゲット」タブを選択します。
6. 「登録済みターゲット」セクションで、以下の点を確認します。
   • 問題のWeb Server（web-server-1 など）が一覧に表示されているか
   • 表示されていない場合は、ターゲットグループに未登録であることが原因です
   • 表示されている場合は、「ステータス」列の値を確認します

手順2: ヘルスチェックのステータスを確認する

ターゲットグループに登録されている場合、ヘルスチェックのステータスを確認します。

1. 手順1の「ターゲット」タブで、各ターゲットの「ヘルスステータス」列を確認します。
2. 正常なWeb Serverは healthy と表示されます。
3. 問題のWeb Serverが unhealthy と表示されている場合、「ヘルスステータスの詳細」列に失敗の理由コードが表示されます。

主な理由コード:

4. ヘルスチェックの設定を確認するには、「ヘルスチェック」タブを選択します。
5. 以下の設定項目を確認します。

手順3: ターゲットグループにWeb Serverを登録する

問題のWeb Serverがターゲットグループに未登録だった場合、以下の手順で登録します。

1. 「ターゲット」タブで「ターゲットの登録」をクリックします。
2. 「使用可能なインスタンス」セクションで、問題のWeb Server（web-server-1 など）のチェックボックスを選択します。
3. ポートが正しいこと（例: 80）を確認します。
4. 「保留中として以下を含める」をクリックします。
5. 「ターゲットを確認」セクションに対象のインスタンスが表示されていることを確認します。

6. 「保留中のターゲットの登録」をクリックします。
7. 「ターゲット」タブに戻り、登録したインスタンスのステータスが initial（初回ヘルスチェック中）と表示されていることを確認します。
8. しばらく待ち、ステータスが healthy に変わることを確認します。

手順4: Web ServerのENIに設定されたSecurity Groupを確認する

ターゲットグループの登録に問題がなかった場合、または登録後もヘルスチェックが unhealthy のままの場合、ENIのSecurity Groupを確認します。

1. 左側ナビゲーションの「インスタンス」→「インスタンス」を選択します。
2. 問題のWeb Server（web-server-1 など）のチェックボックスを選択します。
3. 画面下部の「セキュリティ」タブを選択します。
4. 「セキュリティグループ」セクションに表示されているSecurity Groupの名前とIDを確認します。
   • web-server-sg がアタッチされているか
   • 他のWeb Server（正常に動作しているもの）と同じSecurity Groupがアタッチされているか
5. 正常に動作しているWeb Serverのセキュリティタブも同様に確認し、Security Groupを比較します。

Security Groupが異なる場合の修正手順

1. 問題のインスタンスが選択された状態で、画面上部の「アクション」をクリックします。
2. ドロップダウンメニューから「セキュリティ」→「セキュリティグループを変更」を選択します。
3. 「関連付けられたセキュリティグループ」セクションで、誤ったSecurity Groupの右側にある「削除」をクリックして外します。
4. 「セキュリティグループを追加」のドロップダウンで web-server-sg を検索・選択し、「セキュリティグループを追加」をクリックします。
5. 正しいSecurity Groupのみが表示されていることを確認します。

6. 右下の「保存」をクリックします。

手順5: 修正後の動作確認

Security Groupの変更またはターゲットグループへの登録が完了したら、動作を確認します。

1. 左側ナビゲーションの「ロードバランシング」→「ターゲットグループ」を選択します。
2. web-target-group を選択し、「ターゲット」タブを開きます。
3. 問題のWeb Serverのヘルスステータスが healthy に変わったことを確認します。ヘルスチェックの間隔と正常しきい値の設定によっては、ステータスの更新までに数十秒から数分かかる場合があります。

4. ALBのDNS名（例: web-alb-xxxxxxxxxx.ap-northeast-1.elb.amazonaws.com）にブラウザでアクセスし、正常にページが表示されることを確認します。
5. 複数回リロードして、問題のWeb Serverにもトラフィックが分散されていることを確認します。アクセスログやアプリケーション側でどのサーバーが応答しているかを確認できるようにしておくと、分散状況がわかりやすくなります。

まとめ

ALB環境で複数のWeb Serverのうち1台だけが接続を受信できない場合、トラブルシューティングの鍵は「1台だけの問題 → インスタンス固有の設定を疑う」という考え方です。

Security Group・ネットワークACL・仮想アプライアンスの「ルールセット」が正しいことが確認済みであっても、正しいSecurity Groupがそのインスタンスにアタッチされているか、ALBのターゲットグループに正しく登録されているかは別の確認事項です。特にSecurity Groupについては「ルールの正しさ」と「適用先の正しさ」を分けて考えることが重要です。

SCS試験では、問題文に「Security Groupのルールは正しい」「ネットワークACLは正しい」と書かれている場合、これらのルール自体を再確認する選択肢は除外できます。代わりに、インスタンス固有の設定（ENIへのSGの適用状況、ターゲットグループへの登録状況）を確認する選択肢を選ぶことがポイントです。

参照先

• Application Load Balancer のターゲットグループ – Elastic Load Balancing
• Application Load Balancer ターゲットグループのヘルスチェック – Elastic Load Balancing
• Elastic Network Interface – Amazon EC2
• Amazon EC2 インスタンスのセキュリティグループの変更 – Amazon EC2