VPCエンドポイント（VPC endpoint）は、VPC内のリソースがインターネットを経由せずにAWSのサービスへ接続するための入口です。プライベートサブネットからS3へ書き込む、SSM Session Managerでインスタンスに入る、といった用途でNATゲートウェイの代わりに使われます。ただし「VPCエンドポイントに寄せればコストが下がる」という説明は半分しか当たっていません。ゲートウェイ型は無料ですが、インターフェース型はAZごとに時間課金が発生するため、通信量が少ないサービスではむしろ割高になります。この記事では2種類の違い、東京リージョンの実単価をもとにした損益分岐点、AWS CLIでの作成手順を整理します。
まとめ
VPCエンドポイントには5つのタイプがありますが、AWSサービスへの接続で使うのはゲートウェイ型とインターフェース型の2つです。ゲートウェイ型はS3とDynamoDB専用で追加課金がなく、ルートテーブルにルートを1本足すだけなので、この2サービスは条件を問わず入れて損がありません。一方インターフェースエンドポイント（AWS公式の日本語ドキュメントでは「インターフェイスエンドポイント」表記）はサブネットにENIを作る方式で、東京リージョンでは1エンドポイントあたり0.014 USD/時をAZごとに支払います。2AZ構成なら月20.44 USDの固定費です。NATゲートウェイのデータ処理料0.062 USD/GBに対しインターフェース型は0.010 USD/GBなので、差額0.052 USD/GBでこの固定費を回収する分岐点は月393GBになります。これを下回るサービスにインターフェース型を作ると支出は増えます。以下では判断に必要な仕様と単価、作成手順、そして2025年11月に追加されたリージョナルNATゲートウェイでこの計算が変わるのかどうかまで見ていきます。
VPCエンドポイントの役割とNATゲートウェイとの分担
プライベートサブネットからAWSサービスへ届かせる2つの経路
プライベートサブネットのEC2からS3やSSMを呼ぶとき、経路は2つしかありません。1つはNATゲートウェイ経由でパブリックなサービスエンドポイントへ出る経路、もう1つがVPCエンドポイント経由でAWSネットワーク内を通る経路です。AWSのドキュメントはVPCエンドポイントを、利用者がエンドポイントサービスやリソースへ接続するために作成するもの、と定義しています。プライベートIPアドレスで接続させるのはAWS PrivateLinkを使うタイプの動作であり、後述のゲートウェイ型は当てはまりません。
接続先の種類に応じてエンドポイントのタイプが分かれます。AWS CLIのcreate-vpc-endpointが受け付けるタイプはInterface、Gateway、GatewayLoadBalancer、Resource、ServiceNetworkの5種類で、既定値はGatewayです。GatewayLoadBalancerは検査アプライアンス群への転送、ResourceはAWS RAMで共有されたデータベースやEC2インスタンスなどのリソースへの接続、ServiceNetworkはVPC Latticeのサービスネットワークへの接続に使います。S3やSSMといった通常のAWSサービス接続で選ぶのは、はじめの2つに絞られます。
NATゲートウェイとインターネットゲートウェイの担当範囲
NATゲートウェイはプライベートサブネットのインスタンスが外部と通信するためのNATサービスで、接続は必ずVPC側から始まります。外部からインスタンスへ接続を開始することはできません。帯域は5Gbpsから始まり100Gbpsまで自動でスケールし、パケット処理は毎秒100万から1000万まで伸びます。IPv4アドレス1つにつき、宛先IPアドレス・宛先ポート・プロトコルの組み合わせが同じ通信を55,000セッションまで同時に張れます。この上限はプライマリ1つとセカンダリ7つの計8アドレスまで引き上げ可能ですが、パブリックNATゲートウェイに関連付けられるElastic IPアドレスは既定で2つまでなので、8まで増やすにはクォータ緩和の申請が要ります。
ここで誤解されやすいのが、ゲートウェイエンドポイントを使わずにインターネットゲートウェイ経由でS3にアクセスした場合の経路です。AWSのドキュメントは、この通信はインターネットゲートウェイを通過するがAWSネットワークからは出ないと明記しています。つまりゲートウェイエンドポイントを入れる主な理由は「通信が公衆網に出てしまうから」ではありません。プライベートサブネットからNATを介さずに到達できること、そしてNATのデータ処理料を払わずに済むことが実利です。VPC内外の接続方式全体の整理はAWSのネットワーク接続方式まとめ（VPC内・VPC間・オンプレ・インターネットの選び分け）にまとめています。
ゲートウェイ型とインターフェース型の違い
ゲートウェイエンドポイントの適用範囲と課金されない条件
ゲートウェイエンドポイントが対応するのはAmazon S3とDynamoDBの2サービスだけです。AWS PrivateLinkは使いません。作成時に選んだルートテーブルへ、AWSマネージドプレフィックスリストを宛先、エンドポイントIDをターゲットとするルートが自動で追加されます。このルートは閲覧できますが編集も削除もできません。AWSはゲートウェイエンドポイントの利用に追加料金はかからないと明記しています。
注意点は経路の適用範囲です。ルートは最長一致で選ばれるため、0.0.0.0/0でインターネットゲートウェイへ向くルートがあってもエンドポイントルートが優先されます。ただしプレフィックスリストはリージョン固有なので、別リージョンのS3宛の通信はインターネットゲートウェイへ流れます。また、エンドポイントを関連付けたルートテーブルに紐づくサブネットだけが対象で、それ以外のサブネットのインスタンスはパブリックエンドポイントを使い続けます。1つのルートテーブルに同じサービスのエンドポイントルートを2本持つことはできません。
インターフェースエンドポイントのENIとプライベートDNS
インターフェースエンドポイント（AWS公式の日本語表記はインターフェイスエンドポイント）は、指定したサブネットにエンドポイントネットワークインターフェース（ENI）を作り、そのプライベートIPアドレスへ通信を向ける方式です。AZごとに1サブネットを指定でき、割り当てられたIPアドレスはエンドポイントが存在する間は変わりません。
AZを1つしか指定しないと、そのAZが障害を起こしたときに他のAZのリソースまでサービスへ到達できなくなります。ENIが1つしかなく、VPC内の全サブネットからの通信がそのIPに解決されるためです。AWSは本番環境ではエンドポイントごとに最低2つのAZを設定するよう推奨しています。複数AZにENIがある場合はラウンドロビンで振り分けられます。同一AZ内で完結させたいなら、ゾーン単位のプライベートエンドポイント名かENIのIPアドレスを直接指定してください。
プライベートDNSを有効にすると、VPC側でDNSホスト名とDNS解決の両方が有効になっていることを条件に、AWS管理の非表示プライベートホストゾーンが作成されます。これによりSDKが使う標準のリージョナルエンドポイント名がENIのプライベートIPへ解決されるため、アプリケーション側の接続先を書き換えずに済みます。逆に言えば、VPCのDNS設定が無効だとプライベートDNSは機能しません。なおRoute 53 ResolverはVPCの外からは使えないため、オンプレミスからエンドポイントを利用するにはResolverエンドポイントとルールが別途必要です。
S3で2種類のどちらを選ぶかの基準
S3とDynamoDBは両方のタイプに対応しており、同じVPCで併用もできます。AWSのドキュメントが挙げる違いは次のとおりです。
| 観点 | ゲートウェイ型 | インターフェース型 |
|---|---|---|
| 使用するIP | S3のパブリックIP | VPCのプライベートIP |
| DNS名 | 通常のS3名のまま | エンドポイント固有名が必要 |
| オンプレミスから | 不可 | 可 |
| 他リージョンのVPCから | 不可 | ピアリング・TGW経由で可 |
| 課金 | なし | あり |
判断は単純で、VPC内から使うだけならゲートウェイ型で足ります。オンプレミスや別リージョンのVPCからS3へプライベートに到達させたい場合だけインターフェース型を追加してください。他リージョンのVPCから使うにはVPCピアリングかTransit Gatewayが前提になるため、経路側の設計はAWS Transit Gatewayとは｜仕組み・VPC Peeringとの違い・料金を解説と合わせて検討します。
S3のインターフェースエンドポイントには制約もあります。FIPSエンドポイント、ウェブサイトエンドポイント、レガシーのグローバルエンドポイント、S3ダッシュリージョンエンドポイントは使えません。リージョンをまたぐCopyObjectとUploadPartCopyも対象外です。TLSはバージョン1.0と1.1に加えて1.3も非対応と明記されており、ハイブリッドポスト量子TLSも同じく対象外です。TLS 1.3を必須にしているクライアントを通す設計にはできない点に注意してください。
エンドポイントポリシーによる到達範囲の制限
VPCエンドポイントにはエンドポイントポリシーをアタッチできます。IAMポリシー言語で書くJSONドキュメントで、Principal要素が必須、サイズ上限は空白込み20,480文字です。ポリシーを付けずに作成すると、次の既定ポリシーが自動で付きます。
{
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "*",
"Resource": "*"
}
]
}
つまり作りっぱなしのエンドポイントは全許可です。社内のバケットだけに書き込みを限定するといった絞り込みは、ここをカスタムポリシーへ差し替えて行います。なおaws:PrincipalAccountやaws:SourceVpcのようにシステム生成の識別子を参照するグローバル条件キーには、ワイルドカードと数値条件演算子を使えません。VPC側でパブリックアクセスそのものを封じる方向の統制についてはAmazon VPC Block Public Accessとは何か？その背景と重要性で扱っています。
NATゲートウェイとの料金比較と損益分岐点
東京リージョンの単価
AWSが公開しているPrice List（ap-northeast-1、2026年8月時点）の値は次のとおりです。金額はUSD、月額は730時間換算です。
| 対象 | 時間単価 | データ処理 | 月額(730時間) |
|---|---|---|---|
| NATゲートウェイ（ゾーナル） | 0.062（1台） | 0.062 / GB | 45.26 / 台 |
| リージョナルNATゲートウェイ | 0.062（AZごと） | 0.062 / GB | 45.26 / AZ |
| インターフェースエンドポイント | 0.014（AZごと） | 0.010 / GB | 10.22 / AZ |
| ゲートウェイエンドポイント | 0 | 0 | 0 |
| Gateway Load Balancerエンドポイント | 0.014 | 0.0035 / GB | 10.22 |
| リソースエンドポイント | 0.028（リソースごと） | 0.010 / GB | 20.44 / リソース |
インターフェースエンドポイントのデータ処理料は月1PBまでが0.010 USD/GBで、1PBを超えると0.006、5PBを超えると0.004へ下がります。見落とされやすいのは時間課金の単位です。インターフェース型もリージョナルNATゲートウェイも「AZごと」に課金されるため、2AZへ展開すれば時間あたりの支払いは2倍になります。
インターフェース型が得になる通信量の試算
インターフェース型の固定費を、NATゲートウェイとのGB単価差で何GB分回収できるかを計算します。次のスクリプトを実行しました。
# ap-northeast-1 (2026-08 time point) unit prices in USD
NAT_HOUR = 0.062 # NAT gateway per hour
NAT_GB = 0.062 # NAT gateway data processing per GB
IFE_HOUR = 0.014 # interface endpoint per hour per AZ
IFE_GB = 0.010 # interface endpoint data processing per GB
HOURS = 730 # hours per month
AZ = 2 # number of AZs
fixed = IFE_HOUR * HOURS * AZ
per_gb_saved = NAT_GB - IFE_GB
print("interface endpoint fixed cost : %.2f USD per month" % fixed)
print("saving per GB : %.3f USD" % per_gb_saved)
print("break even traffic : %.1f GB per month" % (fixed / per_gb_saved))
nat_fixed = NAT_HOUR * HOURS * AZ
print("nat gateway fixed cost : %.2f USD per month" % nat_fixed)
print("endpoint count that matches : %.2f" % (nat_fixed / (IFE_HOUR * HOURS * AZ)))
for gb in (100, 393, 500, 2000):
nat = NAT_GB * gb
ife = fixed + IFE_GB * gb
print("%5d GB -> nat %7.2f / endpoint %7.2f / diff %+7.2f" % (gb, nat, ife, ife - nat))
出力は次のようになります。
interface endpoint fixed cost : 20.44 USD per month
saving per GB : 0.052 USD
break even traffic : 393.1 GB per month
nat gateway fixed cost : 90.52 USD per month
endpoint count that matches : 4.43
100 GB -> nat 6.20 / endpoint 21.44 / diff +15.24
393 GB -> nat 24.37 / endpoint 24.37 / diff +0.00
500 GB -> nat 31.00 / endpoint 25.44 / diff -5.56
2000 GB -> nat 124.00 / endpoint 40.44 / diff -83.56
2AZ構成のインターフェースエンドポイント1本は月20.44 USDの固定費で、NATゲートウェイとのGB単価差0.052 USDでこれを回収するには月393GBの通信が必要です。月100GB程度しか流れないサービスにエンドポイントを作ると、NATのままより月15 USD高くつきます。逆に月2TB流れるサービスなら月83 USD下がる計算です。判断材料は「そのサービス宛の通信量」であって、サービスの重要度ではありません。
エンドポイントを増やすほど割高になる構成
インターフェース型を推奨しない場面をはっきり書きます。少量の通信が多数のサービスに散っている環境では、エンドポイントを並べるほど支出が増えます。2AZ分のNATゲートウェイの固定費は月90.52 USDで、インターフェースエンドポイント1本（2AZ）の20.44 USDで割ると4.43です。つまり5本目のエンドポイントを作った時点で、固定費だけでNATゲートウェイ2AZ分を超えます。しかもNATゲートウェイを完全に撤去できない限り、その時間課金は残り続けます。
現実的な順番は次のとおりです。まずS3とDynamoDBのゲートウェイエンドポイントを入れます。ここは無料なので検討の余地がありません。次にVPCフローログやNATゲートウェイのCloudWatchメトリクスで宛先別の通信量を測り、月400GBを超えるサービスだけインターフェース型へ移します。SSMのようにセッション接続のためだけに必要なエンドポイントは、通信量ではなくNATを撤去できるかどうかで判断してください。全アウトバウンドをエンドポイントで賄えてNATを消せるなら、NATの固定費90.52 USDがそのまま浮くためです。
リージョナルNATゲートウェイ登場後のコスト設計
2025年11月19日、NATゲートウェイにリージョナル可用性モードが追加されました。従来のゾーナルNATゲートウェイはAZごとに作成してAZごとにルートを引く必要がありましたが、リージョナルモードではVPCを指定して1つ作るだけで、ワークロードのあるAZへ自動的に拡張・縮退します。AWS CLIでは可用性モードを指定して作成します。
aws ec2 create-nat-gateway \
--region ap-northeast-1 \
--vpc-id vpc-0abc123 \
--availability-mode regional
指定できる値はzonalとregionalの2つです。リージョナルモードではパブリックサブネットが不要で、AWSがルートテーブルを自動作成しインターネットゲートウェイ宛のルートを入れます。IPアドレスはAZあたり最大32個まで割り当てられ、ゾーナルの8個より多くの同時接続を捌けます。1アドレスにつき、同一宛先への同時接続上限が55,000ずつ増える計算です。IPアドレスとAZ拡張をAWSに任せる自動モードと、自分で管理する手動モードがあり、AWSは自動モードを推奨しています。制約として、プライベートNATには対応せず、制約付きAZでも利用できず、新しいAZへの拡張には最大60分かかります。プライベートNATが必要な用途はゾーナルモードのままにしてください。
コスト面で誤解しやすいのは、リソースが1つに見えるからといって時間課金も1本分になるわけではない点です。AWSの料金ページは、リージョナルNATゲートウェイは各AZに構成されている時間ごとに課金されると明記し、3AZに広がっていれば時間単価の3倍が請求されるという計算例を載せています。東京リージョンなら2AZで0.062×2×730＝90.52 USD/月となり、ゾーナルNATゲートウェイを2台並べた場合と同額です。データ処理料も0.062 USD/GBのまま変わりません。したがって、通信量の多い宛先をVPCエンドポイントへ逃がすという判断は、リージョナルモードへ移行しても一切変わりません。
リージョナルモードで実際に効くのは、ワークロードが消えたAZの時間課金が自動的に外れる点です。AWSは、ワークロードの変化でいずれかのAZからサポートが外れると、時間課金はアクティブなAZだけを反映するよう自動調整されると注記しています。ゾーナル構成にありがちな「使われなくなったAZのNATゲートウェイを消し忘れて課金され続ける」形の無駄は起きにくくなります。逆に言えば、削減できるのは運用ミス由来のコストであって、単価そのものではありません。
AWS CLIによる作成手順と疎通確認
サービス名の確認とゲートウェイエンドポイントの作成
エンドポイント作成にはサービス名が必要です。利用可能なサービス名は次のコマンドで検索します。
aws ec2 describe-vpc-endpoint-services \
--region ap-northeast-1 \
--filters 'Name=service-name,Values=*s3*'
S3のゲートウェイエンドポイントは、ルートテーブルIDを指定して作成します。サブネットやセキュリティグループの指定は不要です。
aws ec2 create-vpc-endpoint \
--region ap-northeast-1 \
--vpc-id vpc-0abc123 \
--vpc-endpoint-type Gateway \
--service-name com.amazonaws.ap-northeast-1.s3 \
--route-table-ids rtb-0abc123
指定したルートテーブルに、S3のプレフィックスリストを宛先とするルートが自動追加されます。ルートテーブルは後から関連付けを増やせますが、そのルートテーブルに紐づくサブネットのインスタンスだけが対象になる点は変わりません。
インターフェースエンドポイントの作成とプライベートDNS有効化
インターフェース型はサブネットとセキュリティグループを指定します。2AZ以上に展開し、プライベートDNSを有効にする構成が推奨されています。
aws ec2 create-vpc-endpoint \
--region ap-northeast-1 \
--vpc-id vpc-0abc123 \
--vpc-endpoint-type Interface \
--service-name com.amazonaws.ap-northeast-1.ssm \
--subnet-ids subnet-0a1b2c3d subnet-4e5f6a7b \
--security-group-ids sg-0abc123 \
--private-dns-enabled
セキュリティグループはENIに付くため、VPC内のクライアントからのHTTPS（TCP 443）を許可しておく必要があります。ここを絞りすぎて疎通しない事例が多い箇所です。
つながらないときの切り分け
作成後の状態は次のコマンドで確認します。
aws ec2 describe-vpc-endpoints \
--region ap-northeast-1 \
--vpc-endpoint-ids vpce-0abc123 \
--query "VpcEndpoints[].[VpcEndpointType,State,PrivateDnsEnabled,NetworkInterfaceIds]"
切り分けはタイプごとに見る場所が違います。ゲートウェイ型で到達しないなら、対象サブネットのルートテーブルにエンドポイントルートが入っているか、別リージョンのバケットを叩いていないかを確認します。インターフェース型で到達しないなら、まずインスタンス上でサービスのDNS名を引き、返るアドレスがVPC内のプライベートIPかどうかを見ます。パブリックIPが返るならプライベートDNSが無効か、VPCのDNSホスト名・DNS解決が無効です。プライベートIPが返るのにタイムアウトするなら、原因はENIのセキュリティグループかクライアント側のアウトバウンド制限に絞られます。
よくある質問
VPCエンドポイントとNATゲートウェイはどちらが安いですか？
通信量によって逆転します。東京リージョンの単価では、インターフェースエンドポイントを2AZに置く固定費が月20.44 USD、NATゲートウェイとのデータ処理料の差が0.052 USD/GBなので、そのサービス宛の通信が月393GBを超えるとエンドポイントのほうが安くなります。それ未満なら高くつきます。S3とDynamoDBのゲートウェイエンドポイントは無料なので、この計算の対象外です。
ゲートウェイエンドポイントとインターフェイスエンドポイントの違いは何ですか？
ゲートウェイ型はルートテーブルにルートを追加する方式で、対象はS3とDynamoDBのみ、追加料金はかかりません。インターフェース型はサブネットにENIを作りプライベートIPで受ける方式で、多くのAWSサービスに対応し、AZごとの時間課金とデータ処理料が発生します。オンプレミスや他リージョンのVPCからアクセスできるのはインターフェース型だけです。
S3にはどちらのエンドポイントを使えばよいですか？
VPC内のリソースから使うだけならゲートウェイ型で十分です。無料で、S3の通常のDNS名がそのまま使えます。オンプレミスから接続する、VPCピアリングやTransit Gateway経由で他リージョンのVPCから接続する、といった要件がある場合にインターフェース型を追加します。両方を同じVPCで併用することもできます。
VPCエンドポイントを作ってもサービスにつながらないのはなぜですか？
タイプごとに原因が分かれます。ゲートウェイ型では、対象サブネットのルートテーブルがエンドポイントに関連付けられていない、または別リージョンのリソースを参照しているケースが典型です。インターフェース型では、プライベートDNSが無効、VPCのDNSホスト名とDNS解決が無効、ENIのセキュリティグループでTCP 443が閉じている、のいずれかがほとんどを占めます。まずDNS解決の結果がプライベートIPかどうかを見ると切り分けが早く終わります。
リージョナルNATゲートウェイを使えばVPCエンドポイントは不要になりますか？
不要にはなりません。リージョナルNATゲートウェイの時間課金はAZごとに発生するため、2AZにワークロードがあればゾーナルNATゲートウェイを2台置いた場合と同額です。データ処理料も0.062 USD/GBのままなので、通信量の多い宛先をエンドポイントへ逃がすコスト上の理由は残ります。変わるのは可用性と運用の手間、そしてワークロードが消えたAZの課金が自動的に外れる点です。なおリージョナルモードはプライベートNATに対応していないため、その用途ではゾーナルモードを使います。
