ALBとEC2の「鉄壁」な関係：セキュリティグループ設計のベストプラクティス
現場のSREとして数々のインフラ構成を見てきましたが、未だに「とりあえずEC2のセキュリティグループ（SG）で全許可（0.0.0.0/0）にしておいて、ALB側で制御すればいいよね」という設計に出くわすことがあります。
これは、インフラ担当者としては「寝覚めの悪い設計」の筆頭です。ALB（Application Load Balancer）は強力なゲートウェイですが、バックエンドのEC2がALB以外からの直接アクセスを許容している状態は、内部ネットワークの防壁が崩壊しているのと同じ。今回は、ALBとEC2間のトラフィックを「ALBからのみ」に絞り込む、堅牢かつ実務的な設計手法を深掘りします。
—
なぜ「ALBからの通信のみ」に限定すべきなのか
まず、パケットの挙動を整理しましょう。ALBはパケットを「転送」するのではなく、クライアントとのTCPコネクションを一度終端（Terminated）し、ALBを始点としてEC2へ新しいリクエストを投げ直します。
もしEC2のSGが全開放されていると、誰かがALBのプライベートIP（またはVPC内の疎通性）を知った場合、ロードバランサーをバイパスして直接EC2を攻撃できてしまいます。これを防ぐために、「バックエンドのSGは、ALBのSGからのインバウンドのみを許可する」という原則を徹底します。
セキュリティグループ（SG）によるID参照の魔法
かつてはALBのIPリストを定期的に取得してSGに登録するような苦労がありましたが、現在は「セキュリティグループIDによる参照」を使うのが正解です。
- ALB用のSG（ALB-SG）: 0.0.0.0/0 からのHTTP/HTTPSを許可。
- EC2用のSG（App-SG）: インバウンドルールで「ALB-SG」からのトラフィックのみを許可。
この設定の素晴らしい点は、ALBのプライベートIPアドレスが変わろうと、インスタンスがスケールアウトして増えようと、AWSのコントロールプレーンが自動的にIDベースで通信を制御してくれることです。IPアドレスの管理から解放される、これぞクラウドネイティブな設計です。
—
実践：Terraformでの記述例
実務でそのまま使えるTerraformの定義例です。これを見ると、ALB-SGがEC2の「境界」を定義していることが一目で分かります。
# 1. ALBにアタッチするSG（外部からのアクセスを許可）
resource "aws_security_group" "alb_sg" {
name = "alb-security-group"
vpc_id = var.vpc_id
ingress {
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"] # インターネット公開
}
}
# 2. EC2（バックエンド）にアタッチするSG
resource "aws_security_group" "app_sg" {
name = "app-security-group"
vpc_id = var.vpc_id
ingress {
from_port = 8080 # アプリがListenしているポート
to_port = 8080
protocol = "tcp"
# ここが肝！IPではなくセキュリティグループIDを指定する
security_groups = [aws_security_group.alb_sg.id]
}
}—
トラブルシューティング：接続できない時の「リアルな挙動」
設計通りに設定しても、「503 Service Unavailable」や「Connection Timed Out」で泣きを見ることがあります。そんな時は以下の3点を確認してください。
1. X-Forwarded-For ヘッダーによるデバッグ
EC2側でWebサーバー（Nginx等）のログを見てください。ALB経由であれば、送信元IPとしてALBのプライベートIPが記録されます。もしログに何も流れてこないなら、SGの設定よりも先に、ALBのターゲットグループのヘルスチェックが失敗している可能性が高いです。
2. ヘルスチェックの疎通確認
ALBはターゲットグループで指定されたポートに対してヘルスチェックを行います。このポートがSGで許可されているか、またアプリケーションがそのポートでListenしているかを確認しましょう。
# EC2インスタンス内でポートがListenしているか確認
netstat -tulpn | grep 80803. NACL（ネットワークACL）の罠
SGはステートフルですが、NACLはステートレスです。インバウンドを許可しても、レスポンスを返すためのアウトバウンド（エフェメラルポート）が許可されていないと、通信は成立しません。VPCサブネットのNACL設定を確認し、許可されているか見直しましょう。
—
最後に：クラウドエンジニアとしての矜持
「とりあえず動く」設定と「攻撃耐性を備えた」設定の差は、運用フェーズに入った瞬間に露呈します。特にALBとEC2のSG連携は、クラウドインフラにおいて最も基本的かつ重要な守りの要です。
これから設計を行う皆さんは、ぜひ「IPアドレス直書き」の誘惑を断ち切り、SGのID参照によるクリーンな構成を追求してください。ネットワークの挙動を深く理解し、意図した通りのパケットフローを構築できた時、エンジニアとしての確かな手応えを感じられるはずです。
もし現場で不可解な通信断に直面したら、まずフローログを有効にして、パケットがどこでドロップされているか「目」で確認する。泥臭いですが、それが結局一番の近道ですよ。
コメント