症状
EC2にSSH/HTTPで繋がらない。タイムアウトする。VPC系の「繋がらない」は、確認する順番さえ知っていれば大半が数分で切り分けられます。
診断フロー（上から順に）
1. インスタンスは健在か
- インスタンスの状態が
runningか - ステータスチェック（2/2 checks）が通っているか
2. セキュリティグループ（インスタンス単位・ステートフル）
- インバウンドに必要なポート（22/80/443等）と送信元が許可されているか
- 送信元は自分のIP？
0.0.0.0/0？ SG参照？ 想定と合っているか - ステートフルなので戻りの許可は不要
3. NACL（サブネット単位・ステートレス）
SGが正しいのに繋がらないなら次はここ。
- インバウンド・アウトバウンド両方にルールが必要（ステートレス）
- 戻りの通信用にエフェメラルポート（1024-65535）の許可があるか
- ここの「戻り許可漏れ」がNACL事故の定番です
4. ルートテーブル
- パブリックサブネットのつもりなら
0.0.0.0/0 → igw-xxxのルートがあるか - 「パブリック/プライベートはルートテーブル次第」— サブネット名ではなくルートで決まる
5. パブリックIPの有無
- インスタンスにパブリックIP（またはEIP）が付いているか
- プライベートサブネットのインスタンスに外から直接は届かない（踏み台 or SSM経由）
6. OS側
- OSのファイアウォール（firewalld/ufw）やsshdの設定
- そもそもサービスが起動しているか
チェックの時短ワザ
VPC Reachability Analyzer を使うと、2点間の到達性がどこで遮断されているかを自動で解析してくれます。手作業の切り分けで詰まったら投入。
そもそも設計で防ぐ
「とりあえずパブリックサブネットに置く」構成は事故のもと。公開はALBだけ、アプリ・DBはプライベートへ——という現場の基本形をZennで図解しています:
https://zenn.dev/naoto_tech_AI/articles/aws-04-vpc-design-in-practice