導入
パブリックサブネットとプライベートサブネットでは、インターネットとのつながり方がまったく違います。「入ってくる通信」と「出ていく通信」を分けて考えるのがポイントです。
説明
インターネットゲートウェイ（IGW） は、VPCとインターネットを結ぶ出入り口です。1つのVPCに1つだけアタッチでき、パブリックサブネットのルートテーブルに「インターネット宛はIGWへ」という経路を設定することで、双方向の通信が可能になります。
一方、プライベートサブネットのリソース（例：OSアップデートが必要なアプリケーションサーバー）が、外部からはアクセスされたくないが、自分からは外部へ通信したい（パッケージの取得など）場合に使うのが NATゲートウェイ です。
- パブリックサブネットに配置し、Elastic IPを持つ
- プライベートサブネットからの「外向き」通信だけを中継する
- 外部からプライベートサブネットへの通信は開始できない（一方向）
- 高可用性のため、利用するAZごとにNATゲートウェイを1つずつ作るのが推奨構成（1つのNATゲートウェイのAZが落ちると、他AZのプライベートサブネットが道連れで通信不能になるため）
これらを組み合わせた代表構成が パブリック／プライベート3層構成 です。
flowchart LR
Internet(("インターネット")) <--> IGW["インターネット<br/>ゲートウェイ"]
IGW <--> ALB["パブリックサブネット<br/>ALB"]
ALB --> App["プライベートサブネット<br/>アプリ層(EC2)"]
App --> DB["プライベートサブネット<br/>DB層(RDS)"]
App -->|"外向き通信のみ"| NAT["NATゲートウェイ<br/>(パブリックサブネット)"]
NAT <--> IGW
具体例
先ほどの3層構成で、プライベートサブネットのアプリサーバーに1つ悩みが生まれます。「OSやライブラリのセキュリティ更新は外部から取りに行きたい。でも外部から直接アクセスされるのは絶対に避けたい」。
- IGWを直接使えるようにする（＝パブリックサブネットに置く）と、外部から到達可能になってしまい本末転倒。
- そこでNATゲートウェイをパブリックサブネットに置き、プライベートのアプリサーバーの外向き通信だけを中継させる。サーバーは更新を取りに行けるが、外部からこのサーバーへ通信を開始することはできない（一方向）。
さらにSAAの落とし穴が可用性です。NATゲートウェイを1つのAZだけに置くと、そのAZが落ちたとき他のAZのプライベートサブネットまで外に出られなくなる。そこで利用する各AZにNATゲートウェイを1つずつ置くのが推奨構成。「外に出たいが入られたくない＝NATゲートウェイ、しかもAZごとに冗長化」がSAAの定番です。
読んでみよう
「NATゲートウェイは外向き専用」という一方向性がSAAの頻出ポイントです。「プライベートサブネットのEC2からインターネット上のアップデートを取得したいが、外部から直接アクセスはされたくない」という文言を見たら、迷わずNATゲートウェイを選んでください。