背景
ALB・EC2（Tomcat）・RDS MySQLの3層構成をAWSコンソールで手動構築するハンズオンをやりました。今回のポイントは「なぜセキュリティグループを3段階に分けるのか」という設計思想と、ALB特有の制約です。
1. ALBは3段階のSG設計で守られている
インターネット → ALB SG（0.0.0.0/0でHTTP:80のみ許可）
→ EC2 SG（ALB SGからのみ8080を許可）
→ RDS SG（EC2 SGからのみ3306を許可）
一見「ALB SGを全開放して大丈夫か」と思いますが、これは正しい設計です。ALBは不特定多数のユーザーが使うWebサービスの入口なので全開放が前提。EC2の安全性は次の段階、「EC2 SGがALB SGからのみ8080番を受け付ける」というSG-to-SG制御によって守られています。インターネットから直接ポート8080にアクセスすることはできません。
2. ALBは必ず2つ以上のAZのサブネットが必要
ALBを作成する際、VPCを選択すると「少なくとも2つのAZのサブネットを指定してください」というバリデーションが入ります。これはALBが高可用性のため複数AZにまたがって配置される仕様のためで、1つのAZだけを選ぶとエラーになります。今回のハンズオンでサブネットが4つ（パブリック2+プライベート2）必要になっているのはこのためです。
3. ヘルスチェックが「Healthy」になるまでトラフィックは転送されない
ステータス: initial → healthy / unhealthy
ALBはターゲットグループに登録したEC2に対して定期的にHTTPリクエストを送り、正常（HTTP 200）が返るか確認します。unhealthyのままだとALBはそのEC2にトラフィックを一切転送しません。EC2が「実行中」になった後もTomcatの起動に5〜10分かかるため、「EC2は起動しているのにALB経由でアクセスできない」という状態がしばらく続くのは想定内の挙動です。
4. EC2の直接アクセスとALB経由アクセスの違いを体感できる
http://（EC2のパブリックIP） ← 表示されない（SGでブロック）
http://（ALBのDNS名） ← 表示される
EC2のパブリックIPに直接アクセスしても何も表示されません。ポート8080がALB SGからのみ許可されているためです。これが3層構成の核心で、EC2のIPアドレスが変わってもALBのDNS名は変わらないため、クライアント側は常に同じアドレスでアクセスし続けられます。
5. トラブルシューティングは「どの段階で詰まっているか」で切り分ける
| 症状 | 原因の階層 |
|---|---|
| ALBに繋がらない（タイムアウト） | ALB SGのインバウンドルール |
| 502エラー | EC2（Tomcat未起動） |
| 503エラー | ターゲットグループにHealthyなインスタンスがない |
| Unhealthyが続く | EC2 SGのアウトバウンドルールが変更されている |
3段階のSG設計を理解していると、どのエラーがどの階層の問題かを素早く切り分けられます。
まとめ
ALB + EC2 + RDSの3層構成は、「ALB SGは全開放・EC2 SGとRDS SGは前段のSGからのみ許可」という3段階のSG-to-SG制御が設計の核心です。ALBの2AZ要件とヘルスチェックの仕組みを理解しておくと、トラブルシューティングも迷わず進められます。