サブネット/ルートテーブル/IGW/NATゲートウェイ難易度 標準無料
ある企業は VPC（10.0.0.0/16）内にプライベートサブネット（10.0.1.0/24）を作成し、そこに配置した EC2 インスタンス群からセキュリティパッチ配布サーバ（インターネット上）へ HTTPS でアクセスできるようにしたい。ただし、これらのインスタンスへインターネットから直接接続できてはならない（インバウンド接続は一切許可しない）。
この要件を満たす最も適切な設計を選べ。（単一選択）
- Aパブリックサブネットに NAT ゲートウェイ（Elastic IP 付き）を作成し、パブリックサブネットのルートテーブルに
0.0.0.0/0 → IGW、プライベートサブネットのルートテーブルに0.0.0.0/0 → NAT ゲートウェイを設定する - Bプライベートサブネットに NAT ゲートウェイを作成し、プライベートサブネットのルートテーブルに
0.0.0.0/0 → NAT ゲートウェイを設定する - C各 EC2 インスタンスにパブリック IP を割り当て、プライベートサブネットのルートテーブルに直接
0.0.0.0/0 → IGWを設定する - DVPC ピアリング接続を作成し、別 VPC 経由でインターネットへアクセスさせる
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
プライベートサブネットのインスタンスに「アウトバウンドのインターネットアクセスは必要だが、インバウンド接続は一切許可しない」という要件には、NAT ゲートウェイが最適解である。
- NAT ゲートウェイはパブリックサブネットに配置し、Elastic IP を割り当てる。パブリックサブネットのルートテーブルには
0.0.0.0/0 → インターネットゲートウェイ（IGW）のルートが必要。 - プライベートサブネットのルートテーブルには
0.0.0.0/0 → NAT ゲートウェイ IDを設定する。これによりプライベートサブネットのインスタンスはアウトバウンド通信（送信元アドレス変換＝SNAT）でインターネットへ出られる。 - NAT ゲートウェイは送信元からの接続に対する戻りの通信のみを通す（ステートフルな変換テーブルを保持）。インターネット側から新規にプライベートサブネットへ接続を開始することはできない＝インバウンド接続を許可しない要件を自然に満たす。
- Bインターネットへ出るための public NAT ゲートウェイはパブリックサブネットに作成し、Elastic IP の関連付けが必須であり、この構成では作れない。プライベートサブネットに作成できるのは private NAT ゲートウェイだが、こちらは Elastic IP を持てず、private NAT ゲートウェイから IGW へ向けたトラフィックは IGW 側で破棄されるため、いずれにせよインターネットへは抜けられない。
- Cこの構成はインスタンスへインターネットから直接到達可能にしてしまい、インバウンド接続を禁止する要件に反する。また IGW への直接ルートを持つ時点でそのサブネットは事実上パブリックサブネットになる。
- DVPC ピアリングは VPC 間のプライベート接続であり、インターネットへの出口を提供する仕組みではない（ピア先 VPC がインターネットゲートウェイを持っていても、ピアリング経由でその IGW を「借りる」ことはできない）。
ひっかけ： NAT ゲートウェイをプライベートサブネットに置くという誤り（B）が頻出。インターネット向けに使うなら NAT ゲートウェイ（public NAT ゲートウェイ）はパブリックサブネットに置くのが鉄則で、Elastic IP の関連付けも必須。なお「NAT ゲートウェイはプライベートサブネットに作れない」わけではない＝オンプレミスや他 VPC 向けの private NAT ゲートウェイはプライベートサブネットに作るが、そこから IGW へ流したトラフィックは破棄されるためインターネットの出口にはならない。
また「パブリック IP を直接割り当てて IGW ルートを引く（C）」はインバウンドも開いてしまう設計であり、要件（インバウンド禁止）に反する。
公式ドキュメント・関連Amazon VPC User Guide ― NAT gateways↗
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）