EC2 ネットワーク設定【IP・セキュリティ・VPC デザインパターン】

観点	セキュリティグループ（SG）	ネットワーク ACL（NACL）
適用単位	ENI／インスタンス	サブネット
ステート	ステートフル（戻りトラフィックは関連フローとして許可されやすい）	ステートレス（インバウンドとアウトバウンドを別ルールで明示）
ルール	許可のみ（拒否は暗黙）	許可と拒否
試験の典型	SSH/HTTP のポート開放	追加の IP ブロックやレガシー設計

プライベートサブネットのインスタンスがインターネットに出るには NAT ゲートウェイ／NAT インスタンス と ルートテーブル 0.0.0.0/0 → NAT が必要、という長文が頻出です。

ソース／宛先チェック（NAT など）

NAT ゲートウェイやルーティング用 EC2 では ソース／宛先チェックの設定が論点になることがあります。試験では「NAT に SG は付くが、パケット転送の仕組みはルートとチェック」など、VPC のルーティングとセットで読む問題が出ます。

🏗️ VPC 3 層アーキテクチャ設計（試験頻出）

典型的な本番環境では、VPC を複数サブネット層に分けることで、セキュリティと可用性を両立します。

┌─── Public Subnet（AZ-1）
│    ├─ ALB/NLB（インターネット向けエントリーポイント）
│    └─ NAT Gateway（プライベートサブネットのアウトバウンド）
│
├─── Public Subnet（AZ-2）
│    └─ NAT Gateway（冗長性）
│
├─── Private Subnet - Application Tier（AZ-1/AZ-2）
│    ├─ EC2（アプリケーション層）
│    └─ SG: ALB からのポート許可のみ
│
└─── Private Subnet - Data Tier（AZ-1/AZ-2）
     ├─ RDS マルチ AZ
     ├─ ElastiCache
     └─ SG: APP層 SG をソースにポート許可

レイヤー別セキュリティグループ設計

レイヤー	サブネット配置	インバウンドルール	アウトバウンド	役割
Web 層	Public	インターネット 80/443	データ層へのポート	ALB/NLB
APP 層	Private	Web 層 ALB SG	データ層ポート + NAT へのアウトバウンド	EC2 アプリ
Data 層	Private	APP 層 EC2 SG	不要（通常通信開始しない）	RDS/ElastiCache

インバウンド/アウトバウンドの通信フロー

インターネット → Web 層（ALB）→ APP 層（EC2）→ Data 層（RDS）

ALB の SG: インターネット 0.0.0.0/0:80,443 → 許可
EC2 の SG: ALB SG をソースに指定 → 許可（参照型ルール）
RDS の SG: EC2 SG をソースに 3306 → 許可

プライベートサブネット → インターネット（パッチ適用など）

EC2 のアウトバウンド: 0.0.0.0/0:443 → NAT Gateway へ
ルートテーブル: 0.0.0.0/0 → nat-xxxxx

🔌 NAT Gateway vs NAT Instance（比較）

項目	NAT Gateway	NAT Instance
マネージド	AWS 管理	自分で EC2 を管理
高可用性	各 AZ に単独配置（冗長化推奨）	EC2 ですから単一障害点
スループット	最大 100 Gbps	インスタンスタイプに依存
料金	時間課金 + データ処理料	EC2 インスタンス + 転送料
NAT64/DNS64	✓ サポート	× なし
推奨用途	ほぼすべて	レガシー環境のみ