ネットワーキング中級優先度高

NAT Gateway・NATインスタンス・VPCエンドポイントの違いを初心者向けに解説

プライベートサブネットからの通信設計で混同しやすいNAT Gateway、NATインスタンス、VPCエンドポイントの違いを、目的、料金、可用性、Gateway型とInterface型の使い分けの観点で整理します。

公開日: 2026-07-31/更新日: 2026-07-31

SAA-C03

比較対象サービス

サービス名をクリックすると、用語詳細ページで復習できます。

NAT GatewayNAT InstanceVPC Endpoint

結論

この3つは、どれも「プライベートサブネットに置いたリソースが外部と通信する」場面で登場します。

ただし、目的が正反対です。

NAT Gateway・NATインスタンスは、インターネットへ出るための仕組み
VPCエンドポイントは、インターネットへ出ないための仕組み

ここを取り違えると、設計も試験の選択肢も間違えます。

サービス	一言でいうと	主な使いどころ
NAT Gateway	AWSマネージドなNAT。プライベートサブネットからインターネットへ出るための仕組み	OSパッチ取得、外部APIの呼び出し
NATインスタンス	EC2上に自分で構築するNAT。同じく外へ出るための仕組み	学習・検証環境、極小構成でのコスト削減
VPCエンドポイント	AWSサービスへの通信を、インターネットを経由させずAWSネットワーク内で完結させる仕組み	S3・DynamoDBへの非公開アクセス、PrivateLink経由の内部通信

迷ったら、まずはこう判断します。

インターネット上の任意の宛先へ出たい：NAT Gateway
学習・検証目的で最小コストのNATを試したい：NATインスタンス
通信先がS3やDynamoDBなどのAWSサービスだけ：VPCエンドポイント
NAT Gatewayのデータ処理料金を減らしたい：VPCエンドポイントでS3向け通信を迂回させる

比較表

項目	NAT Gateway	NATインスタンス	VPCエンドポイント
目的	インターネットへ出る	インターネットへ出る	インターネットへ出ない
実体	AWSマネージドのNATサービス	自分で起動・管理するEC2インスタンス	ルートテーブルのエントリ（Gateway型）またはENI（Interface型）
通信できる相手	インターネット上の任意の宛先	インターネット上の任意の宛先	対応しているAWSサービスのみ
運用責任	AWSがパッチ適用・スケーリングを担当	OSのパッチ、監視、障害復旧まですべて自己責任	AWSマネージド
可用性	既定のzonalモードはAZ内で冗長で、マルチAZ構成ではAZごとに作成が必要（regionalモードはワークロードのあるAZへ自動拡張）	単一インスタンスは単一障害点。フェイルオーバーは自前設計	Gateway型はリージョン内で冗長。Interface型はAZごとにENIを配置
帯域	自動でスケール（最大100 Gbps）	インスタンスタイプのネットワーク性能が上限	1 AZあたり10 Gbpsから最大100 Gbpsへ自動スケール（AWS PrivateLinkのクォータ）
料金	時間課金 + データ処理量課金	EC2インスタンス料金（+EBS・データ転送）	Gateway型は追加料金なし。Interface型は時間課金 + データ処理量課金
セキュリティグループ	割り当て不可（サブネットのNetwork ACLで制御）	EC2なので割り当て可能	Interface型のENIに割り当て可能（Gateway型は不可）
インターネットゲートウェイ	必要（パブリックサブネットに配置）	必要（パブリックサブネットに配置）	不要
固有の落とし穴	AZごとに置かないとAZ間データ転送料が発生し、AZ障害時に道連れになる	送信元/送信先チェックの無効化が必須	Gateway型が使えるのはS3とDynamoDBの2サービスのみ
試験キーワード	managed NAT, per-AZ, outbound only	source/destination check, EC2-based NAT	gateway endpoint, interface endpoint, PrivateLink

初学者向け説明

NAT Gateway

NAT Gatewayは、プライベートサブネットのリソースがインターネットへ出ていくためのAWSマネージドサービスです。

パブリックサブネットにNAT Gatewayを置き、プライベートサブネットのルートテーブルで0.0.0.0/0の宛先をNAT Gatewayに向けます。

Private Subnet          Public Subnet
EC2 ──0.0.0.0/0──▶ NAT Gateway ──▶ Internet Gateway ──▶ Internet

通信の向きは外向き（アウトバウンド）だけです。インターネット側からNAT Gateway経由でEC2へ入ってくることはできません。

EC2にパブリックIPを付けずにOSパッチを取得したい、といった用途で使います。

NATインスタンス

NATインスタンスは、同じ役割をEC2インスタンス上に自分で構築したものです。

構成はNAT Gatewayとほぼ同じで、パブリックサブネットにEC2を置き、プライベートサブネットのルートテーブルをそのインスタンスに向けます。

Private Subnet          Public Subnet
EC2 ──0.0.0.0/0──▶ NAT Instance (EC2) ──▶ Internet Gateway ──▶ Internet

安価にできる一方、可用性・スケーリング・OSのパッチ適用がすべて自己責任になります。

さらに、NATインスタンスには固有の落とし穴があります。EC2は既定で「自分宛て以外のパケットを破棄する」動作をするため、送信元/送信先チェック（Source/Destination Check）を無効化しないと転送そのものが成立しません。

現在のAWSでは、本番用途では原則としてNAT Gatewayが推奨されます。

VPCエンドポイント

VPCエンドポイントは、AWSサービスへの通信をインターネットを経由させず、AWSネットワーク内で完結させるための仕組みです。

そもそもインターネットに出ないため、NAT GatewayもInternet Gatewayも不要です。

種類が2つあり、この違いが試験でも実務でも重要です。

Gateway型（Gateway Endpoint）

対応サービスはS3とDynamoDBの2つのみ
ルートテーブルにエントリ（プレフィックスリスト宛のルート）が追加される形で機能する
追加料金なし
ENIを作らないため、エンドポイント自体にセキュリティグループは割り当てられない
通信の宛先はサービスのパブリックエンドポイント（AWS管理のプレフィックスリストが持つIPレンジ）になるため、通信元インスタンス側のセキュリティグループで、プレフィックスリスト宛て（TCP 443）のアウトバウンドを許可する必要がある
VPC内からの通信が対象で、オンプレミスからDirect ConnectやVPN経由で直接使うことはできない

Interface型（Interface Endpoint / AWS PrivateLink）

多数のAWSサービスに対応（S3もInterface型で利用可能）
サブネット内にENI（プライベートIP）が作られる形で機能する
時間課金 + データ処理量課金が発生する
ENIに対してセキュリティグループを割り当てられる
オンプレミスからDirect ConnectやVPN経由でも到達できる

Private Subnet
EC2 ──▶ Gateway Endpoint ──▶ Amazon S3      （ルートテーブル経由 / 追加料金なし）
EC2 ──▶ Interface Endpoint (ENI) ──▶ AWS Systems Manager  （PrivateLink / 時間課金）

試験で問われるポイント

SAA-C03で問われやすいポイント

プライベートサブネットのEC2がインターネット上のリポジトリからパッチを取得したい → NAT Gateway
高可用性が要件なら、AZごとにNAT Gatewayを配置し、各AZのプライベートサブネットのルートテーブルを同一AZのNAT Gatewayに向ける
NAT Gatewayは時間課金とデータ処理量課金の両方が発生する。S3へ大量のデータを送っている構成では、S3のGateway型VPCエンドポイントを追加してNAT Gatewayを迂回させるとコストが下がる（頻出パターン）
「インターネットを経由せずにS3へアクセスしたい」→ Gateway型VPCエンドポイント
「オンプレミスからPrivateLink経由でAWSサービスへ到達したい」→ Interface型VPCエンドポイント
NAT Gatewayにはセキュリティグループを割り当てられない。制御はサブネットのNetwork ACLで行う
NAT Gatewayはアウトバウンド専用。インターネット側から接続を開始することはできない
NATインスタンスでは送信元/送信先チェックの無効化が必須
NATインスタンスはEC2なので、セキュリティグループを割り当てられる点がNAT Gatewayとの違いとして問われる
IPv6のアウトバウンド通信にはNAT GatewayではなくEgress-Only Internet Gatewayを使う
NAT Gatewayには、インターネットへ出るパブリック型と、VPC間・オンプレミス間の通信に使うプライベート型がある。単に「NAT Gateway」と言う場合は通常パブリック型を指す
この接続タイプ（パブリック/プライベート）とは別に、可用性モードとしてAZ単位で動作するzonalモードと、ワークロードのあるAZへ自動的に拡張しパブリックサブネットも不要なregionalモードがある。SAA-C03で問われるのは従来のzonalモード（＝AZごとに配置する構成）である

実務での使い分け

NAT Gatewayを選ぶケース

プライベートサブネットのEC2からOSパッチやライブラリを取得したい
外部のSaaS APIを呼び出したい
通信先がAWSサービスに限定できない
可用性・スケーリングの運用工数をかけたくない

例：

プライベートサブネットのアプリケーションサーバーからの外部API連携
yum / apt によるパッケージ更新
外部の決済ゲートウェイへの接続

NATインスタンスを選ぶケース

学習・検証環境で、NATの仕組み自体を理解したい
極小構成で、NAT Gatewayの固定費すら抑えたい
NATに加えて踏み台や特殊なパケット処理を同居させたい

実務の本番環境では、可用性とパッチ運用の負担からNAT Gatewayを選ぶのが基本です。

NATインスタンスを使う場合は、送信元/送信先チェックの無効化と、Auto Scalingなどによる復旧設計をセットで考えます。

VPCエンドポイントを選ぶケース

通信先がS3・DynamoDBなどのAWSサービスに限定できる
コンプライアンス要件で「通信をインターネットに出さない」ことが求められる
NAT Gatewayのデータ処理料金を削減したい
Systems Manager Session Managerでプライベートサブネットのインスタンスを操作したい（Interface型）

例：

S3へのログ・バックアップ転送（Gateway型）
DynamoDBへの読み書き（Gateway型）
Systems Manager経由でのメンテナンス（Interface型）

このプロジェクトでの位置づけ

このプロジェクトのMVPは、S3 + CloudFront + Lambda + DynamoDBが中心で、VPCを使わない構成です。

そのためNAT GatewayもVPCエンドポイントも直接は登場しません。

ただしSAA-C03では、VPCの経路設計は避けて通れない出題領域です。「どの通信をインターネットに出し、どの通信を出さないか」を図で描けるようにしておく必要があります。

よくある間違い

間違い1：VPCエンドポイントを「インターネットへ出るための仕組み」だと思う

VPCエンドポイントは、インターネットへ出ないための仕組みです。

NAT Gatewayとは目的が正反対で、代わりに使えるのは「通信先がVPCエンドポイント対応のAWSサービスである場合」に限られます。

間違い2：NATインスタンスで送信元/送信先チェックの無効化を忘れる

EC2は既定で、自分宛てではないパケットを破棄します。

NATインスタンスはパケットを転送するのが仕事なので、送信元/送信先チェックを無効化しない限り通信が通りません。

ルートテーブルとセキュリティグループが正しくても通信できない場合、まずここを疑います。

間違い3：NAT Gatewayを1つ作ればマルチAZ構成でも安心だと思う

NAT Gatewayは、既定のzonalモードではAZ単位のリソースです。

1つのAZにだけ置くと、そのAZの障害で他のAZのプライベートサブネットまで外部通信ができなくなり、AZ間のデータ転送料金も発生します。

可用性を求めるなら、AZごとにNAT Gatewayを作り、同一AZのルートテーブルから参照します。

なお、regionalモードを選べばAZごとの作成は不要になりますが、SAA-C03で問われるのはこのzonalモードを前提とした構成です。

間違い4：どのAWSサービスでもGateway型のVPCエンドポイントが使えると思う

Gateway型に対応しているのはS3とDynamoDBの2つだけです。

それ以外のサービスをVPC内に閉じて使いたい場合は、Interface型（PrivateLink）を使います。Interface型は追加料金なしではなく、時間課金とデータ処理量課金が発生します。

間違い5：NAT Gatewayにセキュリティグループを付けられると思う

NAT Gatewayにセキュリティグループは割り当てられません。

通信を制御したい場合は、NAT Gatewayを配置したサブネットのNetwork ACL、またはプライベートサブネット側のリソースのセキュリティグループで行います。

まとめ

3つの違いは、「インターネットへ出るのか、出ないのか」で整理すると迷いません。

NAT Gateway：マネージドで外へ出る。AZごとに配置。時間課金+データ処理量課金
NATインスタンス：EC2で自前構築。安価だが自己責任。送信元/送信先チェックの無効化が必須
VPCエンドポイント：外へ出ない。Gateway型はS3・DynamoDBのみで追加料金なし、Interface型はPrivateLinkで多数のサービスに対応し時間課金

SAA-C03では、この3つを組み合わせた「コストを下げつつ通信をインターネットに出さない構成」が繰り返し問われます。

次に学ぶ内容

比較で違いを理解したら、関連用語と模擬問題で知識を確認してください。資格試験では「似ているサービスの使い分け」が問われます。

比較一覧へ戻る AWS用語集を見る模擬問題を解く