AWS 基礎 17

NAT Gateway → NAT Instance
安さと運用責任を交換する

Private Subnetの外向き通信はどこを通るのか。ルートをEC2に向けるだけでは終わらない、NATの正体と切替確認を一本につなぎます。

TL;DR

  1. NATはPrivate Subnetから外へ出る通信の中継点。
  2. NAT Instanceは停止できるが、可用性と転送設定を自分で管理する。
  3. Route Table変更後、ECSがECR・S3・Secrets Managerへ届いて初めて完了。

01NATは外出専用の中継点

Private SubnetのECSは、入口を公開せずに外部サービスへ接続する。

Private SubnetからNAT経由で外部へ通信する図
NATは外部からの入口ではなく、内部から開始した通信の往復を仲介する。

Public IPを持たないECSタスクでも、起動時にはECRからimageを取得し、S3とSecrets Managerから設定を読む。Private Subnetのdefault routeがNATを向くことで、この外向き通信が成立する。

役割を分ける：SGは通行許可、Route Tableは次の中継先、NATは送信元アドレスの変換。

02安さの代わりに何を背負うか

GatewayとInstanceは同じ用途でも、管理責任が違う。

NAT GatewayとNAT Instanceの比較図
Instanceの費用面の柔軟さは、自分で面倒を見る範囲が増えることとの交換。
観点NAT GatewayNAT Instance
管理AWS管理利用者管理
停止停止という運用をしないEC2として停止可能
転送設定組み込みIP forwarding・NATルールが必要
可用性・性能マネージドEC2構成に依存
向く場面可用性重視学習・小規模・費用重視

注意：本番の既存ルート切替は通信断につながる高リスク変更。費用だけで置換を決めない。

03切替は検証までが1セット

Route Table → EC2転送 → アプリ起動の順で確認する。

NAT切替と検証手順の図
最終確認は、ECSタスクが必要な外部サービスへ接続してHealthyになること。

障害時は Route → ENI/EC2状態 → IP forwarding → iptablesカウンタ → SG の順に追う。

結論

  1. NATはPrivate Subnetの外向き通信を成立させる中継点。
  2. NAT Instanceは費用を抑えやすい代わりに、転送・可用性・障害対応を利用者が担う。
  3. Route変更とECSの実通信確認を分けず、一つのリリースとして扱う。