【AWS】VPCエンドポイントって結局なに？NAT経由のS3アクセスをやめたら通信費が消えた話

はじめに

privateサブネットに置いたサーバから、なんとなくS3にアクセスできている。動いているから気にしていなかったのですが、ある日コストの内訳を眺めていて「あれ、NAT Gatewayのデータ処理料、思ったより高くない？」と引っかかりました。調べてみたら、S3とのやり取りがまるごとNAT経由になっていて、毎GBしっかり課金されていたんです。VPCエンドポイントを1つ足すだけでこの費用がゼロになると知ったときは、正直「もっと早く知りたかった」と思いました。

この記事は、その時に頭の中で整理したことをまとめたものです。テーマはシンプルで、次の2つに答えます。

• VPCエンドポイントって、そもそもAWSのリソースなの？
• それが無いと、いったい何が起きるの？

そのうえで、よく出てくる「Gateway型」と「Interface型」の違いも、丸暗記ではなく腑に落ちる形で整理します。

対象読者：VPCやサブネット、NAT Gatewayはなんとなく触ったことがあるAWS初級〜中級の人。「VPCエンドポイントって名前は聞くけど結局なに？」が口から出る人。

料金などの数値は執筆時点（2026年6月）の公式情報で裏取りしていますが、料金は改定されるので最後は必ず公式を確認してください。

結論を先に：VPCの外にいるS3への「専用の出口」

先に結論だけ持ち帰れるようにします。

VPCエンドポイントは、VPCの中に作れるAWSリソースのひとつです。そして役割は、VPCの外にいるAWSサービス（S3など）へ、インターネットを通らずに繋ぐための専用の出口を用意することです。

これが無いと、privateサブネットのサーバはわざわざNAT Gateway経由でインターネットに出てからS3に到達することになり、遠回りなうえにNATのデータ転送費がかかります。あるいはNATすら無ければ、そもそも繋がりません。

ここから先は、この結論を腑に落とすための話です。

そもそもVPCエンドポイントはAWSリソースなの？

結論から言うと、はい、れっきとしたAWSリソースです。

EC2やサブネットと同じように、マネジメントコンソールやTerraformで作成・削除でき、IDを持ちます。「機能」というより「自分のVPCの中に置くモノ」という感覚に近いです。

ただ、ここで一つややこしいポイントがあります。種類によって"実体"がかなり違うんです。私が最初に混乱したのもここでした。

• Interface型は、サブネットの中に ENI（仮想NIC＝プライベートIPを持つネットワークインターフェイス）が作られます。これはまさに「目に見えるモノ」で、IPを1つ消費します。だから時間で課金されます。
• Gateway型は、ENIを作りません。ルートテーブルに「この宛先はこのエンドポイントへ」という経路（ルート）が1行追加されるだけです。物理的なモノというより設定エントリに近く、だから無料です。

どちらも「VPCエンドポイント」というリソースの一種なのに、片方はIPを持つNICで、もう片方はルートの1行。最初はこの非対称さが飲み込めませんでした。後半でそれぞれをもう少し掘り下げます。

大前提：S3やDynamoDBは「VPCの外」にいる

VPCエンドポイントの話をするとき、絶対に外せない前提があります。それは——S3やDynamoDBは、あなたのVPCの中にはいないということです。

ここ、勘違いしていませんか？　私は最初、S3もなんとなくVPCの内側にある身内のサービスだと思い込んでいました。でも実際は違います。S3やDynamoDBはAWSが管理する巨大な共有サービスで、VPCの境界の外側にいます。

つまり、privateサブネットのサーバから見ると、S3は「インターネットの向こう側にいる相手」と同じ立ち位置なんです。同じVPC内の別サーバに話しかけるのとはわけが違う。この一点を押さえると、「なぜわざわざエンドポイントなんてものが必要なのか」が一気に腑に落ちます。

S3が「VPCの外」と聞くとセキュリティが不安になるかもしれませんが、もちろん認証（IAM）で守られています。ここで言いたいのは、あくまで「ネットワーク経路上、VPCの外にいる」という位置関係の話です。

VPCエンドポイントが無いとどうなる？

ここが本題です。S3がVPCの外にいる以上、エンドポイントが無いとどう繋ぐことになるのか。起きることは大きく3パターンあります。

パターン1：NAT経由で繋がるが、お金がかかる

privateサブネットのサーバが、NAT Gateway → Internet Gateway という経路を通って、S3のパブリックエンドポイント（パブリックIP）にアクセスするパターンです。動くことは動きます。実際、何も設定していなくても「なぜか繋がっている」のはたいていこれです。

問題はコストです。NAT Gatewayはデータ処理料を毎GB課金します。執筆時点の公式料金だと、NAT Gateway経由のデータ処理はus-east-1で1GBあたり約0.045ドル¹。これがGateway型エンドポイントを使えば0ドルになります。仮に月1TBのデータがS3とNAT経由で流れていたら、us-east-1ならそれだけで月45ドルが「本来払わなくていい費用」として消えていく計算です（東京リージョンは料金が高いぶん、実際の損失はもう少し膨らみます）。

私が最初に青ざめたのもまさにこれでした。S3への通信が全部NATを通っていて、転送量に応じてじわじわ課金されていたんです。Gateway型に切り替えたら、その費用がきれいに消えました。

パターン2：NATも無いと、そもそも繋がらない

privateサブネットにNAT Gatewayが無い場合。外に出る道そのものが無いので、S3へのアクセスはタイムアウトします。

「ローカルだと動いたコードが、privateサブネットのEC2に上げた途端S3に繋がらない」というハマり方をしたことがある人、けっこういるんじゃないでしょうか。原因はコードではなく経路、ということが多いです。VPCエンドポイントを置けば、NATを用意しなくてもS3に到達できるようになります。

パターン3：パブリックな経路を通るので、経路を統制しづらい

パターン1で繋がってはいても、通信はNAT Gateway・Internet Gatewayという「VPCの外向きの出口」を通り、S3のパブリックエンドポイント（パブリックIP）を相手にしています。ここは誤解しやすいので補足すると、S3やDynamoDB宛のトラフィックは、こうしてIGWを経由してもAWSのネットワーク内に留まり、パブリックインターネットそのものを横断するわけではありません（AWS公式ドキュメントにも、IGWを通るがAWSネットワークからは出ない旨が明記されています）。それでも、パブリックなエンドポイントを汎用の外向き経路から叩いていることに変わりはなく、S3向けの通信だけを切り分けて統制するのは難しいままです。

一方でVPCエンドポイントを使えば、S3向けの通信をパブリックな経路に流さず、AWS内部の専用経路に寄せられます。エンドポイントポリシーを併用すれば「どのバケットに触れるか」まで絞れます。セキュリティ要件の厳しい環境では「S3へのアクセスはパブリックな経路を経由しないこと」が条件になることもあり、その場合はエンドポイントが実質必須になります。コスト面だけでなく、この「専用経路に寄せる」という性質が効いてくる場面は意外と多いです。

「繋がっているから問題ない」と「最適な経路で繋がっている」は別物です。動作確認だけだと、遠回りでお金のかかる経路に気づけません。コストとセキュリティの観点で経路を一度見直すのをおすすめします。私はそれを怠って後から請求で気づいたクチです。

Gateway型とInterface型の違い

ここまでで「エンドポイントが要る理由」は見えたと思います。では実際に作るとき、Gateway型とInterface型のどちらを選ぶのか。両者は目的（インターネットを通らずにサービスへ繋ぐ）は同じですが、仕組み・対応サービス・料金が根本的に違います²。

数字だけ見ると、Gateway型はとにかく無料で軽い。Interface型はENIを持つぶんコストがかかるけれど、対応範囲が圧倒的に広い、という対比です。

Gateway型を一言で：ルートテーブルに無料の抜け道

Gateway型は、「ルートテーブルに無料の抜け道を1本追加する」イメージです。

S3かDynamoDB宛のパケットを、インターネット（NAT）ではなくAWS内部ネットワークへ流す経路を1行足すだけ。ENIを作らないのでIPも消費しないし、料金もかかりません。公式ドキュメントでも、Gateway型はPrivateLinkを使わない仕組みであることが明記されています³。

冒頭で触れた私のコスト削減も、やったことはこれだけです。S3向けの通信をNAT経由からGateway型エンドポイント経由に切り替えた。設定は驚くほど軽く、効果はデータ転送費まるごと、でした。

ひとつ注意点として、Gateway型は同一リージョン・同一VPCの中からしか使えません。オンプレや別リージョンのVPCからの到達には対応していないので、そこはInterface型の出番になります。

Interface型を一言で：サブネットに刺さる仮想NIC（ENI）

Interface型は、「サービスへの専用の仮想NIC（ENI）をサブネットに挿す」イメージです。

実体がプライベートIPを持つので、Gateway型では繋げない相手——S3/DynamoDB以外の大多数のAWSサービスや、PrivateLink経由で公開された外部・自社サービス——にも到達できます。さらに、VPCピアリングやオンプレからの到達も可能です。

その代わり、ENIを持つので時間課金とデータ処理料がかかります。たとえば2つのAZで24時間動かすと、1バイト流す前から月十数ドルのベース費用が乗ってきます⁴。だからInterface型は「必要なところにだけ置く」のが基本です。

たとえば、自社の別システムがPrivateLinkでサービスを公開していて、そこへVPC内から専用線的に繋ぎたい、というケース。これはGateway型では実現できず、Interface型の独壇場です。

ハマりどころ・補足

最後に、私や周りがつまずいた点をいくつか。

ひとつめ。Gateway型を作っても、ルートテーブルへの関連付けを忘れると効きません。「作ったのにまだNAT経由のまま」というときは、対象サブネットのルートテーブルにエンドポイントが紐づいているか確認してみてください（私は最初これで「あれ、無料にならない」と悩みました）。

ふたつめ。S3はGateway型とInterface型の両方に対応しています。普段のコスト削減ならGateway型で十分ですが、オンプレからS3へ直接プライベートに繋ぎたいといった要件があるとInterface型を選ぶことになります。同じS3でも目的次第で選択が変わる、というのは覚えておくと混乱しません。

みっつめ。アクセス制御まわりは、2つのタイプで持てる手段が違います。Gateway型はENIを持たないのでセキュリティグループは付けられませんが、エンドポイントポリシーで「どのプリンシパルがどのリソースに触れるか」を絞れます。一方Interface型はENIを持つぶん、セキュリティグループとエンドポイントポリシーの両方が使えます。つまりエンドポイントポリシー自体はどちらのタイプでも設定できる、というのが正確なところです（私は最初「ポリシーはGateway型だけの機能」と思い込んでいて、Interface型の設定画面でポリシー欄を見て「あれ？」となりました）。「ネットワーク経路を絞る」だけでなく「誰がどのバケットに触れるか」まで制御したいなら、このあたりも合わせて検討する価値があります。

まとめ

VPCエンドポイントは、VPCの中に置けるAWSリソースで、役割は「VPCの外にいるAWSサービスへ、インターネットを通らずに繋ぐ専用の出口」でした。

無いとどうなるかは、突き詰めると「遠回り（NAT経由）でお金がかかる」か「そもそも繋がらない」かのどちらか。そしてGateway型とInterface型の違いは、「ルートに足す無料の経路」か「IPを持つ有料の仮想NIC」か、という実体の差から全部導けます。

私はコストの内訳を眺めていてたまたま気づきましたが、動いているシステムほど経路は見直されにくいものです。もし「privateサブネットのサーバがS3とどう通信しているか」を最近確認していないなら、一度ルートテーブルを覗いてみると、地味に効くコスト削減が見つかるかもしれません。もし試して何か発見があったら、ぜひコメントで教えてください。

参考リンク

1. NAT Gatewayのデータ処理料は1GBあたり約0.045ドル（us-east-1。執筆時点の公式VPC料金ページで確認）。リージョンにより異なり、東京リージョン（ap-northeast-1）はこれより割高なので、東京中心の構成では実際の課金額はもう少し大きくなる。正確な値は必ず最新の公式料金で確認のこと。 ↩

2. 厳密にはVPCエンドポイントはこの2種類だけではなく、現在はGateway型・Interface型に加えて、Gateway Load Balancer型・Resource型・Service Network型がある（Gateway型以外はすべてPrivateLinkベース）。本記事はもっとも出番の多いGateway型とInterface型に絞って扱う。 ↩

3. Gateway型エンドポイントはAWS PrivateLinkを使わず、S3とDynamoDBのみに対応する旨が公式ドキュメントに明記されている。 ↩

4. $0.01/エンドポイント/AZ/時＋$0.01/GB（us-east-1基準。執筆時点の公式PrivateLink料金ページで確認）。2つのAZで24時間稼働させると月十数ドル（約14.6ドル）のベース費用になる。なお同一リージョン内のAZ間データ転送は無料。リージョンにより異なり、東京はやや割高。 ↩