[イラスト図解で学ぶAWS] プライベートサブネットのアクセス手段をすっきり整理

はじめに

S3 へアクセスするときは Gateway Endpoint を無料で利用できる一方で、Parameter Store へアクセスする場合は Interface Endpoint の料金が発生します。また、外部サービスへ通信する場合は NAT Gateway が必要になるケースもあります。

AWS を学び始めた頃、私は

「なぜサービスによって接続方法やコストが違うのだろう？」

と疑問に思いました。

実は、これらの違いは単なる料金体系の違いではありません。AWS では、各サービスの特性に応じて異なる通信方式が提供されています。

たとえば、S3 のように大量のデータを扱うサービスには、Gateway Endpoint という専用の通信経路が用意されています。Gateway Endpoint 自体には利用料金がかからず、インターネットを経由せずに S3 へ接続できます。

大量のデータ転送に対して毎回高額な通信コストが発生すると、利用者にとって大きな負担になります。そのため、S3 や DynamoDB のように利用頻度や転送量が大きくなりやすいサービスには、コストを抑えやすい接続方式が用意されているのではないかと考えられます。

一方で、Parameter Store や Secrets Manager のような API ベースのサービスでは、Interface Endpoint を利用してサービスごとにプライベート接続を行います。こちらは利用料金が発生しますが、必要なサービスだけに専用の接続経路を用意できるという特徴があります。

このように、AWS の通信方式やコストモデルは、サービスの用途や特性に応じて設計されています。

本記事では設定手順そのものではなく、「なぜその通信方式なのか」という考え方に焦点を当てます。

この記事では、VPC 内通信、Gateway Endpoint、Interface Endpoint、NAT Gateway の違いを整理しながら、

• なぜその接続方式が必要なのか
• なぜコストが異なるのか
• どのような場面で使い分けるのか

を、イラストを交えながら分かりやすく解説します。

⚠️ おねがい
本記事は、AWS初学者が自身の勉強のためにハンズオンや公式ドキュメントを通じて学んだ内容を、イメージ重視で整理したものです。一部の細かい仕様や例外的な構成については簡略化して記載しています。
もし内容に誤りや、より良い設計思想などがありましたら、コメント欄にて優しくご指摘いただけますと幸いです。

---

📘 プライベートサブネットからの通信パターン選択フロー

下記のフローチャートでは、EC2から通信する場合にリソースの性質によって、どのアクセス手段を選ぶべきかをフローチャートにしました。

プライベートサブネットからの通信手段

フローチャートで挙げた 4 つの通信パターンについて、以下に詳細をまとめます。
通信先の性質がそれぞれ異なるため、選ぶべき通信方法や発生するコストにも大きな違いがあります。

※ S3 や DynamoDB には Interface Endpoint を利用する特殊な構成も存在しますが、一般的な利用では Gateway Endpoint が選択されることがほとんどです。そのため、本記事では割愛します。

通信パターン	代表的な接続先	コスト（時間単位）	イメージ
VPC 内通信	RDS / Aurora	🟩 無料 （※同一AZ内）	🏠 家の中で直接会話
Gateway	S3 / DynamoDB	🟩 無料	🛣️ 専用の無料道路
Interface	SSM / SQS / API	🟧 約0.6〜1円 / 時	🚪 サービス毎のドア
NAT Gateway	GitHub / 外部API	🟥 約10円 / 時＋通信量	🌐 共通の外部出口

🏠 VPC内通信 【基本無料】

同じ家（VPC）内での通信です。

• 通信先: すでに VPC 内に存在している各リソース（RDS等）
• 経路: 新たな通信経路を作成する必要がない（デフォルトのLocalルートを使用）
• コスト: 同一 AZ 内であれば追加コストは発生しない
• 注意: 異なる AZ 間を跨ぐ通信は、別途データ転送料（片道 $0.01/GB）が発生

📦 Gateway Endpoint 【無料】

S3 や DynamoDB 専用に、AWS が用意している特別な通信経路です。

• 通信先: Amazon S3 / DynamoDB
• 経路: ルートテーブルを書き換えるだけの直接ルート（インターネットは経由しない）
• コスト: 完全無料（維持費もデータ処理量も0円）
• 特徴: 大量データを扱うサービス向けに、コストを気にせず利用できる最強の専用経路

🧩 Interface Endpoint 【低〜中コスト】

AWS API へ安全にアクセスするための「専用の小さな扉（ENI）」を VPC 内に作成します。

• 通信先: 各種 AWS API サービス（SSM / SQS / Secrets Manager 等）
• 経路: VPC 内に設置したプライベートIPを持つネットワークインターフェース（ENI）経由
• コスト: 「利用するサービス数」×「配置するAZ数」の維持費 ＋ データ処理量（$0.01/GB）が発生
• 特徴: セキュリティを高められる反面、利用するサービスや冗長性を増やすほどコストが蓄積していくため注意が必要

🛜 NAT Gateway 【高コスト】

インターネットや外部 API へアクセスするための「大きな共通出口」です。

• 通信先: 外部インターネット、SaaS、VPCエンドポイント未対応の AWS サービス全般
• 経路: パブリックサブネットに配置した共通ゲートウェイを経由し、インターネットへ
• コスト: 高額な維持費（約 $45/月） ＋ 高めのデータ処理量（$0.062/GB）が発生
• 特徴: 1つ作ればVPC内の複数リソースで共有可能、幅広い外部通信を丸ごと処理できる

ご紹介した4つのパターンは、それぞれ通信範囲、アクセス方法、そしてコスト構造が明確に異なります。
「なぜそのアクセス方法を選ぶべきなのか」「どうしてこのコストがかかるのか」を整理することで、無駄のない最適なVPC設計が見えてきます。

それでは次から、プライベートサブネットに配置された EC2 を例に、それぞれの具体的な挙動と仕組みを順番に見ていきましょう！

---

☎ 身内同士の通信

同じ VPC 内のリソース同士（例：EC2、RDS など）であれば、すでに同じネットワーク上に存在しているため、特別な通信経路を用意する必要はありません。

そのため、VPC 内通信は AWS における最もシンプルな通信方式です。

ただし、同じ VPC 内であっても通信を許可する設定は必要です。

AWS では、この許可にあたる仕組みが セキュリティグループ（Security Group） です。

それでは、EC2 から RDS に接続する例を見てみましょう。

1.1 VPC内通信の設定

①接続するEC2を確認します。当然ながらプライベートIPアドレスを持っています。

ENIも確認できます。

②同様に、RDSも確認します。RDSの場合はエンドポイントが表示されます。

ENIも確認できます。

つまり、EC2 と RDS はどちらも VPC 内に存在し、通信可能な体を持っているわけです。

④RDS のセキュリティグループで、EC2 のセキュリティグループからの接続を許可します。
セキュリティグループの設定
タイプ： MySQL/Aurora（ポート 3306）
ソース： EC2 が使用しているセキュリティグループ

このセキュリティグループの設定により、RDSのMySQL ポートは、指定した EC2 からの通信を許可し、EC2とRDSは接続可能な状態になりました。

⑤EC2→RDSへの接続確認
それでは、EC2からRDSへの接続テストを行います。EC2にログインし、MySQLクライアントを使って接続を確認します。

画面の通り、EC2からRDS（MySQL）へ正常にログインできました。これでVPC内通信が正しく構成されていることが確認できました。

1.2 なぜ VPC 内通信は無料なのか？

実際に VPC 内通信を設定してみると、必要だったのはセキュリティグループで通信を許可する設定だけでした。

私は最初、「本当にこれだけで通信できるのだろうか？」 と少し不思議に思いました。

しかし、VPC 内のリソースの状態をよく考えてみると、EC2 も RDS もすでに同じネットワーク（VPC）の中に作成されています。
また、両方ともENIを持っています。

🧩 ENI（Elastic Network Interface）とは？

ENI は、EC2 や RDS が VPC 内で通信するために必要な “ネットワークの体” のような存在です。
ENI があることで、リソースは VPC 内で通信主体として振る舞うことができます。

ENI が持つ役割

• プライベート IP を持つ
• サブネットに所属する
• VPC 内で通信できる状態になる

つまり、

ENI がある＝通信主体として存在できる

ということです。

---

EC2 と RDS は同じ VPC 内に存在し、それぞれが ENI とプライベートIPアドレスを持っています。そのためAWSが提供するVPC内部のルーティング機能によって相互通信が可能になります。

つまり、

• 同じネットワークに存在しているため、新しい通信経路（ルート）を作る必要がない
• 各リソースがすでに ENI を持っているため、新しい通信窓口（ENI）を追加する必要もない

という状態です。言い換えるなら、
「同じ建物の中にすでにいるので、新しい道路や受付を作らなくても、ドア（セキュリティグループ）さえ開ければすぐに会話できる状態」
なのです。

そのため、VPC 内通信では新しいネットワーク経路を作る必要がなく、「誰を部屋に入れるか」という門番（セキュリティグループ）の許可設定だけで通信が成立します。

そして、既存のネットワークの中で通信がすべて完結し、追加の通信リソースを消費しないからこそ、同一 AZ 内であれば 追加の通信コストが完全無料（0円） になります。

裏側では AWS の膨大なネットワーク設備や転送処理がフル稼働しているはずですが、それを追加料金なしで利用者に使わせてくれるのは、AWS はなかなかの太っ腹ですね。

---

💡 構造が分かると見えてくる、実務のプチ注意点

「同じ建物の中だから無料」という仕組みが分かると、実務でよくある以下の例外にも納得がいきます。

• 別のアベイラビリティゾーン（AZ）と通信する場合：同じ建物（VPC）でも「別の階（AZ）」へデータを移動させるため、データの交差点を通るための「データ転送料（約$0.01/GB）」がわずかに発生します。

2. S3 / DynamoDBのGateway Endpoint通信

🛣️大容量データ用の専用道路

S3 と DynamoDB は、どちらもVPCに属さない（VPCの外側にある）AWSのサービスであり、いずれも大容量データを扱うことを前提としています。

この大容量データをプライベートサブネットから安全かつ効率的に通信できるよう、AWSは Gateway Endpoint（ゲートウェイエンドポイント） という専用の接続経路を用意してくれています。これを作成することで、インターネットを一切経由せず、エンドポイント利用料金なしでS3 / DynamoDBへアクセスでS3 / DynamoDBへアクセスできるようになります。

---

💡 もしもシミュレーション：もしS3でInterface Endpointしか使えなかったら？

ここで、S3へのアクセスにGateway Endpoint（無料）が使えず、他のサービスと同じInterface Endpoint（有料）しか選択肢がなかった場合を仮定して、実際のコストを試算してみます。

前提条件：

• インターフェースエンドポイントの時間単価（東京リージョン）：約 0.014 USD/時間
• データ処理料金：1GB あたり 0.01 USD
• 1ヶ月の稼働時間：約 730時間
• 月間のデータ転送量：1TB（≒ 1024GB） のログやバックアップを保管する場合

コスト計算：

1. エンドポイント時間料金
   0.014 USD/時間 × 730時間 ≒ 10.22 USD
2. データ処理料金
   0.01 USD/GB × 1024GB ≒ 10.24 USD

🔥 合計：約 20.5 USD / 月（1つのエンドポイントあたり、日本円で約3,000円）

このように、もしInterface Endpoint（ENI課金）しか利用できなかった場合、大量データを扱うたびにコストが雪だるま式に積み上がってしまいます。
利用者が「こんなクラウド、困るド」と感じてしまうほど高額な通信コストが発生しないよう、AWS は S3 / DynamoDB に対して無料の専用経路を提供しているのではないかと考えられます
※AWS が公式にその理由を公表しているわけではありませんが、S3 や DynamoDB は大量のデータ転送が前提となるサービスであるため、このような設計になっていると考えると理解しやすいでしょう。

2.1 Gateway Endpoint作成

それでは、Gateway Endpoint作成を実際に作成します。

①S3GatewayEndPonintサービスの選択

サービス名：com.amazonaws.【対象のec2が属するVPCのリージョン】.s3

タイプ：GateWay※１

※１
S3やDynamoDBにも「Interface型エンドポイント」を作成する選択肢自体は存在します。しかし、これはオンプレミス環境から専用線（Direct Connectなど）を経由してS3にアクセスする場合などの特殊なユースケースで使用するものです。同じVPC内のEC2からアクセスする場合は、完全無料で利用できる「Gateway型」を使用するのが一般であるため、本記事では対象外としています

②VPC・ルートテーブルの選択

VPC：対象のEC2が属するVPC
ルートテーブル：対象の EC2 が属するサブネットのルートテーブル （マルチ AZ 構成の場合は、各 AZ のルートテーブルを選択）

③EC2 → S3 のアクセス動作確認

ec2から下記のS3のバケット一覧を取得するコマンドを発行します。
aws s3 ls S3://【取得対象S3バケット名】

対象バケットのオブジェクトが取得されて、プライベートサブネットEC2からS3へのアクセスを確認できました。

2.2 Gateway Endpoint はS3への「道案内」

ここで注目したいのは、Gateway EndpointではS3（AWS内部サービス）に対してルートテーブルを設定するという点です。後ほど登場する Interface Endpoint ではセキュリティグループを設定しますが、Gateway Endpoint ではルートテーブルを設定します。

この違いは、

• Gateway Endpoint = S3へ向かう「通信経路（道）」を作る仕組み
• Interface Endpoint = AWSサービスへ接続する「扉」を作る仕組み

という役割の違いから生まれています。

作成した Gateway Endpoint を確認すると、選択したルートテーブルが関連付けられていることが分かります。

私は実際に設定してみて、

「なぜ Gateway Endpoint はルートテーブルを設定するのに、セキュリティグループは設定しないのだろう？」

「アクセス制御は本当に大丈夫なのだろうか？」

と疑問に思いました。

その答えは、Gateway Endpoint が通信を許可する仕組みではなく、S3 へ向かう専用の通信経路（道）を作る仕組みだからです。

S3 Gateway Endpoint は、VPC のルートテーブルに S3 向けの経路を追加することで機能します。つまり、Gateway Endpoint の役割は S3 へのルート情報を提供することです。

一方で、Gateway Endpoint 自体は ENI（Elastic Network Interface）を作成しません。

セキュリティグループは ENI に対して適用される仮想ファイアウォールであるため、ENI を持たない Gateway Endpoint にセキュリティグループを設定することはできません。

そのため、Gateway Endpoint のアクセス制御はセキュリティグループではなく、

• Endpoint Policy
• S3 Bucket Policy
• IAM Policy

によって実施します。

これは、ルートテーブルが「どこへ進むか」を決める経路案内役であり、「誰を通すか」を判断する仕組みではないためです。
Gateway Endpoint は実体となる通信窓口（ENI）を持たず、単なる道路案内のようにルートテーブルへ経路を追加する仕組みです。

例えるなら、Gateway Endpoint は S3 へ向かう専用道路案内を作る仕組みです。道路案内そのものに入場チェックはありません。代わりに、道路の先にある建物（S3）が受付を行い、「誰が利用できるか」を判定します。

そのため、Interface Endpoint のようなセキュリティグループの設定も不要で、エンドポイント利用料金も発生しません。
また、また、通信はAWS内部ネットワークを利用するため、インターネット公開を必要としない構成を実現できます。
S3 や DynamoDB はバックアップ・ログ保管・データ分析など大量データ転送を伴うサービスであるため、このようなシンプルで低コストな接続方式が採用されていると考えると理解しやすいでしょう。

（もちろん裏側では AWS がネットワークを維持しているはずですが、利用者は無料で利用できます。大量データを扱う S3 や DynamoDB 向けに無料の専用道路を提供してくれるあたり、AWS はかなりの太っ腹です。）

3. Interface Endpoint通信

🚪 専用の小さな扉でAWSサービスへ接続

Interface Endpoint は、VPC 内に AWS サービス専用の ENI（Elastic Network Interface）を作成し、プライベートサブネットからインターネットを経由せずに AWS API へアクセスできる仕組みです。

SSM や Secrets Manager などの AWS サービスは、同じ AWS 上に存在していても VPC の外側で提供されています。そのため、プライベートサブネット内の EC2 からアクセスするには、何らかの外部通信経路が必要になります。

この通信を NAT Gateway で実現することもできますが、API の呼び出しのような小規模な通信に対しては、NAT Gateway は少し大げさです。たとえるなら、ケーキを一切れだけ食べたいのにホールケーキを丸ごと買うようなものです。

そこで AWS は、必要なサービスだけに接続するための小さな専用扉として Interface Endpoint を提供しています。

3.1 EC2 → Parameter Store を Interface Endpoint でアクセス

それでは、プライベートサブネット内の EC2 から AWS API である Parameter Store にアクセスしてみましょう。

Parameter Store の値を取得するためには、API 本体を提供する Systems Manager（SSM）と、認証を担当する STS（Security Token Service）の VPC エンドポイント（Interface Endpoint）を利用します。

このように Interface Endpoint はサービスごとに役割が分かれているため、1 つの値を取得するだけでも複数のエンドポイントが必要になることがあります。

その代わり、これらを構成することで、認証から API 呼び出しまでの通信をインターネットを経由せずに完結させることができます。

3.1.1　SSMマネージャーのインターフェースエンドポイント作成

では、SSMマネージャーのインターフェースエンドポイントを作成します。

①エンドポイントサービス用のセキュリティグループの作成

インターフェースエンドポイントを作成する前に、先にインターフェースエンドポイント用のセキュリティグループを作成します。
下記のインバウンドルールを設定します。
タイプ：HTTPS
ソース：EC2のセキュリティグループ

EC2からアクセス(HTTP通信）を受け入れるセキュリテイグループが作成できました。

②エンドポイントサービスの選択

それでは、インターフェースエンドポイントを作成します。
どの AWS サービスに対する扉を作るかを選択します。ここではSSMを指定します。
サービス：** com.【対象VPCのリージョン】.ssm **

③セキュリティグループ設定

インターフェースエンドポイントの通信許可を設定します。
セキュリティグループ：上記の①でセキュリティグループ

これで、EC2からアクセスできるインターフェースエンドポイントを作成できました。

④インターフェースエンドポイント作成確認

作成したインターフェースエンドポイントを作成するとネットーワークインタフェース（ENI）が作成されています。
つまり、通信の窓口が作成されたのです。

STSエンドポイントの作成は省略します。

④EC2 → Parameter Store のアクセス動作確認

それでは、ec2に接続して、下記コマンドを入力します。

aws ssm get-parameter
--name "test-param-key"
--with-decryption
--query "Parameter.Value"
--output text

プライベートサブネット内の EC2 から、AWS Systems Manager Parameter Store の値を正常に取得できることを確認しました。

3.2 Interface Endpoint は外部AWSサービスへの専用窓口（ENI）を作る

Interface Endpoint を作成すると、Gateway Endpoint との違いがはっきり分かります。

エンドポイント種類	ENI有無	通信先への接続手段	アクセス制御
Gateway Endpoint	無	ルートテーブルで経路案内（道）	通信先で制御
Interface Endpoint	有	ENI（専用窓口）を経由して接続	セキュリティグループで制御

Gateway Endpoint は S3 や DynamoDB へ向かうための「道」を作る仕組みです。そのため ENI は作成されず、通信制御は S3 バケットポリシーや IAM ポリシー側で行います。

一方、Interface Endpoint は VPC 内に ENI（Elastic Network Interface）を作成します。

ENI は IP アドレスを持った実体のあるネットワークインターフェースであり、EC2 と同様にセキュリティグループを関連付けることができます。

そのため Interface Endpoint では、

• どのリソースからアクセスできるのか
• どのポートで通信を許可するのか

をセキュリティグループによって制御します。

つまり、Interface Endpointは単なる道路案内ではなく、AWSサービスへ接続するための「専用の受付（窓口）」をVPC内に新しく建築する仕組みです。

同じエンドポイントという名前でも、その構造とコストの理由は真逆です。

• Gateway Endpoint（無料）
  • 道路の案内板を書き換えるだけ。警備員も不要。
• Interface Endpoint（有料）
  * VPC内に実際の受付（ENI）を設置。不審者を防ぐ警備員（セキュリティグループ) も常駐するため、1サービスごとに維持費が発生。

このように、専用の受付をVPC内に常時キープしてもらうためのコストだと考えれば、非常に正当な対価です。むしろ、これほど安全な仕組みをこの少額で提供してくれるAWSは、とても太っ腹だと言えます。

4. NAT Gateway での通信

🌐外部サービスへの共通出口

最後に、NAT Gateway を利用した接続方法を確認します。
これまで紹介した Gateway Endpoint や Interface Endpoint は、特定の AWS サービスへ接続するための専用経路でした。
一方、NAT Gateway はプライベートサブネットからインターネット全般へアクセスするための共通出口です。
NAT Gateway には時間料金とデータ処理料金が発生するため、学習用途や小規模環境ではコストが気になるサービスでもあります。
それでも NAT Gateway が広く利用される理由は、大きく次の 2 つです。

① 専用エンドポイントが存在しない通信先へ接続するため

Gateway Endpoint や Interface Endpoint は、AWS が提供する特定サービス向けの機能です。

そのため、以下のような AWS 管理外のサービス へ接続する場合は利用できません。

• GitHub
• Slack
• 外部決済サービス
• 外部の天気情報 API

また、

• yum
• dnf
• apt

などのパッケージリポジトリも一般的にはインターネット上に存在するため、プライベートサブネットからアクセスするには NAT Gateway などのインターネット接続手段 が必要になります。

② 複数のサービスを一括で通信できるため

利用する AWS サービスが多岐にわたる場合、Interface Endpoint を多数作成すると月額料金が積み重なります。
そのため、利用するサービス数や通信量によっては、NAT Gateway に通信を集約したほうがコスト面や運用面で有利になる場合があります。
（小さなケーキをたくさん買うと、ホールケーキより高くなることがありますよね）

NAT Gateway が必要となる理由

• 専用エンドポイントが存在しない外部サービスへアクセスできる
• 様々な通信をまとめて扱える共通出口として利用できる

つまり NAT Gateway は、プライベートサブネットに配置されたリソースが外の世界と通信するための総合ゲートウェイなのです。

4.1　NAT Gatewayの作成

それでは、最後にNatGeteWayを作成してみましょう。

①VPCのメニューから「NATゲートウェイ」を選択して作成します。

ここで画面のメニューに注目してみましょう。先ほどのGateway型とInterface型は、どちらも「エンドポイント」という共通のメニュー内から作成していました。しかし、NATゲートウェイはそれ自体が独立したメニューになっています。
このメニュー配置の違いこそが、特定のサービスしか通さないエンドポイントと、インターネット全体への共通出口となるNATゲートウェイの「役割（レベル）の違い」を表していると言えます。

②NAT Gatewayの設定

下記を設定します。
名前：任意の名前
VPC:【パブリックサブネットを持つVPC】
接続タイプ：パブリック
接続タイプにプライベートがありますが、外部に接続できないタイプなので今回の説明対象から除外します。

③ルートテーブルの設定

NAT Gatewayが作成したら、対象のEC2のプライベートサブネットのルートテーブルに下記のルートを追加します。
この設定により、プライベートサブネットからの外部通信要求が、パブリックサブネットに作成されたNatゲートウェイに送信されて、外部通信が可能になります。
送信先：0.0.0.0/0
ターゲット：【作成したNATゲートウェイ】

NAT Gatewayの設定は、Gateway Endpointと同じルートテーブルに対して行います。

同じルートテーブルに設定を追加しますが、その「宛先と実体」の性質は大きく異なります。

サービス	道案内の宛先	必要なリソース（実体）
Gateway	AWS内部（S3などの特定サービスのみ）	ユーザー側でENIやパブリックIPの管理不要
NAT Gateway	外部インターネット全般（不特定多数）	ENI（物理的な窓口）＋ パブリックIP

同じルートテーブルに設定を追加しているように見えても、
その「行き先」と「案内役の実体」はまったく別物です。

Gateway Endpoint は AWS 内部の特定サービスへ向かう専用通路で、追加の設備は不要です。
しかし NAT Gateway は、外の世界へ出るための建物の玄関であり、玄関を維持するための窓口（ENI）や住所（パブリック IP）が必要になります。そのため、利用にはコストが発生します。
たとえるなら、同じ建物の中の別の部屋へ行くのであれば、気軽なスタイルで移動できますが、外の街へ出るのであれば、外出靴を履いたり、財布や身分証を持ったりと、外出のための準備が必要になるようなものです。

④IPアドレスの確認

作成されたNAT Gateway を確認すると、ElasticIPアドレスが関連づけられています。外部向けにPublicIPアドレスが設定されているのです。


作成された NAT Gateway を確認すると、Elastic IP が関連付けられていることが分かります。
Elastic IP は AWS が提供する固定のパブリック IP アドレスです。

プライベートサブネット内の EC2 がインターネットへ通信する際、
外部からは NAT Gateway に割り当てられた Elastic IP から通信しているように見えます。

つまり、NAT Gateway はプライベート IP を Elastic IP に変換（NAT変換）しながら、
インターネットとの通信を中継しているのです。
（IPアドレスはお見せすることはできませんが、ElasticIPアドレス（タイプ：パブリックIP）とNAT Gatewayに関連付けられたIPアドレスと、ElasticIPアドレスは同じIPアドレスです。）

####　⑤EC2 → 外部API のアクセス動作確認
EC2に接続し、下記天気情報APIを実行します。
curl https://www.jma.go.jp/bosai/forecast/data/forecast/160000.json

天気情報が表示されて、外部APIとの通信を確認できました。

4.2 NAT Gateway のみで通信できることを確認する

NAT Gateway は、インターネットや AWS サービスへの通信を集約する共通の出口です。
そのため、Gateway Endpoint や Interface Endpoint を削除した場合でも、NAT Gateway が存在すれば AWS サービスへアクセスできるケースがあります。
最後に、実際にエンドポイントを削除した状態で通信を確認してみましょう。

①エンドポイントの削除

前項で作成制したインターフェース型のエンドポイントとS3のゲートウェイ型エンドポイントを削除します

インターフェース型のエンドポイントとS3のゲートウェイ型エンドポイントが存在しない状態になりました。

②S3ゲートウェイ型のエンドポイントが無い状態で、S3にアクセス

S3のゲートウェイ型エンドポイントが存在しない状態で、EC2から下記コマンドを入力します。
aws s3 ls s3//【取得対象S3バケット名】

先ほど作成したS3のゲートウェイ型エンドポイントが無い状態でも、NatGatewayが配置されていたら、S3にアクセスできることを確認できました。

③インターフェース型のエンドポイントが無い状態で、AWS内のAPIにアクセス

次に、パラメータストアの値に取得に必要なSystems Manager（SSM） と、認証（sts)の二つのVPC エンドポイント（Interface Endpoint） が無い状態で、
下記コマンドを入力します。
aws ssm get-parameter
--name "test-param-key"
--with-decryption
--query "Parameter.Value"
--output text

先ほど作成したインターフェース型のエンドポイントが無い状態でも、NatGatewayが配置されていたら、SSMマネージャーのパラメータストアの値が取得できることを確認します。

4.3 NAT Gateway は外部への「共通出口」

ハンズオンでは、NAT Gatewayの設定をGateway Endpointと同じルートテーブルに対して行いました。

Gateway EndpointがAWS内部サービス（S3など）限定のルートだったのに対し、NAT Gatewayは特定宛先以外の通信全般（0.0.0.0/0）への道案内です。当然、AWS管轄外の外部インターネットと通信するためには、世界共通のパブリックIPの用意や、強固なセキュリティ中継（NAT変換）が必要になり、その分コストも高くなります。
実際、ここまで見てきた通信方式の中で、NAT Gatewayは最も広い範囲をカバーしています。ハンズオンの最後に行ったようにゲートウェイ型、インターフェース型のエンドポイントが存在しない状態でも、各リソースにアクセスできています。

種類	カバー範囲
VPC内通信	VPC内のリソースのみ
Gateway型	S3 / DynamoDB のみ
Interface型	特定のAWSサービスごと
NAT Gateway	インターネット全体（不特定多数）

🪙 筆者の本音：やっぱり AWS 様は……？

とはいえ、学習目的や個人開発で NAT Gateway を立ち上げるときは、筆者は今でも毎回心臓がドキドキします。そして検証のコマンドを叩き終えた瞬間、秒速でリソースを削除します。　
1ヶ月で何千円もかかるなんて、AWSはさすがにちょっとぼったくりです

……と言いたいところですが、世界中のインターネットのあらゆる宛先への通信を、インフラの運用保守の手間なしで、完璧かつ安全に超高速でさばいてくれるこの圧倒的な性能を考えると――。

やっぱり、AWSは太っ腹です。

5. まとめ

以上、プライベートサブネットの EC2 が他の AWS サービスや外部 API にアクセスする際の 4 つの通信パターンを整理しました。

通信パターン	実態（何が作られる？）	役割（どこへ行く？）	コスト	コスト理由
VPC 内通信	追加リソースなし	VPC 内のローカル通信	🟩 無料 （※同一AZ内）	既存IP同士の通信だけで成立するため
S3 Gateway Endpoint	実体なし（ENIなし）	S3 への専用道路	🟩 無料	AWS内部の通路設定だけで成立するため
Interface Endpoint	ENI（窓口）が作られる	特定の AWS API	🟧 約0.6〜1円 / 時	サービスごとに通信窓口を作る必要があるため
NAT Gateway	ENI＋パブリックIP（実体あり）	インターネット全体	🟥 約10円 / 時＋通信量	外部通信を安全に中継する物理的窓口が必要になるため

これらの視点から見ると、AWS は単に料金を変えているのではなく、通信先の特性や利用用途に応じて、最適な通信方式を使い分けていることが、分かります。

「どうやってアクセスするのか（設定手順）」を暗記するだけではなく、「なぜその通信方式が用意されているのか」「なぜそのコストになるのか」を理解できれば、AWS の設計思想が見えてきます。

この記事が、同じように AWS の通信方式やコストの違いに悩んでいる方の理解の助けになれば幸いです。

おわりに

実はこの記事を書くきっかけは、私が SAP 試験の勉強中に「プライベートサブネットからのアクセス方法は覚えることが多くて大変だな」と感じたことでした。

多くの解説記事は設定手順に重点が置かれている一方で、「なぜその通信方式なのか」「なぜコストが異なるのか」といった背景まで説明されているものはあまり多くありません。そのため、なかなか理解が深まらず苦労した記憶があります。

そこで今回は、自分自身の学習内容を整理する目的も兼ねて、各通信方式の役割や考え方をまとめてみました。

AWS を使い慣れている方にとっては当たり前の内容かもしれません。しかし、かつての私と同じように、「VPC エンドポイントや NAT Gateway の違いがいまひとつ理解できない」と悩んでいる方の助けになれば、とてもうれしく思います。

この記事を読んでくださった皆さんが、AWS 認定試験でプライベートサブネット関連の問題を自信を持って解けるようになり、さらに実務においても適切な通信方式の選択やコスト最適化の判断ができるようになることを願っています。

そして私自身も、そのレベルを目指して引き続き学んでいきたいと思います。