セキュリティグループの連鎖設計｜ALB→EC2→RDSを最小許可でつなぐ
セキュリティグループ（SG）は、EC2 や RDS などのリソースに付ける仮想ファイアウォールです。3層構成では、IPアドレスではなく「前の層のSG」を許可元に指定することで、必要な通信だけを通す設計にできます。
連鎖のさせ方
| SG | インバウンドで許可するもの |
|---|---|
| ALB 用 SG | HTTP(80) / HTTPS(443)：0.0.0.0/0（インターネット全体） |
| EC2 用 SG | HTTP(80)：ALB 用 SG から |
| RDS 用 SG | MySQL(3306)：EC2 用 SG から |
許可元に SG を指定すると、「その SG が付いたリソースからの通信」を許可する意味になります。Auto Scaling で EC2 が増えても、新しいインスタンスに同じ SG が付いていれば自動的に通信できるので、IPアドレスを管理する必要がありません。
実際に組んでみよう：ArchiCraft の実践編（セキュリティグループ設計）では、このルールを自分で設定して採点できます。また、サンドボックスで ALB → EC2 → RDS をつないで CloudFormation に書き出すと、この SG の連鎖がそのまま生成されます。
SG と ネットワークACL の違い
| セキュリティグループ | ネットワークACL | |
|---|---|---|
| 適用単位 | リソース（ENI） | サブネット |
| 状態 | ステートフル（戻りの通信は自動で許可） | ステートレス（戻りの通信も明示的に許可が必要） |
| ルール | 許可のみ | 許可と拒否 |
| 評価 | すべてのルールを評価 | 番号の小さい順に評価し、最初に一致したもので決定 |
よくあるひっかけ：「特定のIPアドレスからのアクセスを拒否したい」は SG ではできません（SG は許可しか書けない）。ネットワークACL の拒否ルール、または WAF の IP セットを使います。
よくある設定ミス
- RDS の 3306 を
0.0.0.0/0に開ける：DB がインターネットから狙われる。必ずアプリ層の SG に限定する - EC2 の SSH(22) を全開放：踏み台が必要なら Session Manager を使えば 22 番を開けずに済む
- ネットワークACLでエフェメラルポートを塞ぐ：ステートレスなので、戻りの通信（1024-65535 など）も許可しないと応答が返らない
- アウトバウンドを気にしすぎる：SG はステートフルなので、インバウンドで許可した通信の応答は、アウトバウンドのルールに関係なく返る
理解度チェック：EC2 から RDS につながらない。RDS の SG は「EC2 の SG から 3306」を許可している。次に確認すべきは？
EC2 に本当にその SG が付いているか、RDS と EC2 が同じ VPC にあるか（別 VPC なら SG 参照に制約がある）、ネットワークACLでエフェメラルポートの戻り通信が塞がれていないか、の順に確認します。
まとめ
- 許可元に「前の層の SG」を指定して連鎖させる
- SG はステートフル・許可のみ、NACL はステートレス・拒否も可
- DB のポートは絶対にインターネットへ開けない