AWS PrivateLinkとは：仕組み・VPCエンドポイントとの違いと料金・採用判断を実装者目線で解説

AWS PrivateLinkは、VPCからAWSのサービスや他アカウントのサービスへ、インターネットを経由せずプライベートに接続するための仕組みです。その実体は、サブネット内に作られるInterface型VPCエンドポイント（ENI）です。この記事では、PrivateLinkとエンドポイントサービス・NLBの関係、混同されやすいGateway型VPCエンドポイント（S3・DynamoDB）との違い、SSMやECR・Secrets Managerへの私設接続や自社サービスの私設公開といった構成を一次情報で整理します。AWS CLIでエンドポイントを作り、名前解決と疎通を確かめるところまでコマンドで示したうえで、VPCピアリングやTransit Gatewayとの使い分け、時間課金とデータ処理料からなる料金体系、そして採用すべき条件と見送るべき場面まで、ネットワーク設計で迷う論点を具体的に示します。

まとめ：AWS PrivateLinkの仕組み・料金と採用判断の要点

AWS PrivateLinkは、通信をAWSの内部ネットワークに閉じたまま、特定のサービスだけへ到達させる私設接続です。利用者はサブネットにInterface型VPCエンドポイントを作り、そこに割り当てられたプライベートIPを入口にしてサービスへアクセスします。インターネットゲートウェイもNATゲートウェイも経由しないため、外部にトラフィックを晒さずにマネージドサービスや他社SaaSへつなげます。

実装で最初につまずくのが、無料のGateway型VPCエンドポイント（S3・DynamoDB専用）との混同です。PrivateLinkにあたるのはInterface型のほうで、こちらは1AZあたりの時間課金と処理データ量に応じたGB課金が発生します。費用の規模感は、2026年9月時点の東京リージョンでエンドポイント1つにつき1時間0.014ドル、データ処理が月1PBまで1GBあたり0.01ドルでした。VPC全体を双方向につなぐVPCピアリングとは異なり、PrivateLinkは単一サービスへの片方向接続でCIDR重複の心配がない点が設計上の分かれ目です。採用可否に迷う場合は、本記事後半の判断基準を自社の構成へ当てはめてください。

AWS PrivateLinkの仕組みとInterface型エンドポイントの実体

PrivateLinkを設計へ落とすには、コンシューマー側のエンドポイントとプロバイダー側のサービスがどう対になるかを押さえます。ここを曖昧にすると、到達できない構成や、意図せず公開範囲を広げた構成を作り込みやすくなります。

インターネットを経由せず実現する私設接続という設計思想の勘所

従来、VPC内のサーバーからS3や外部サービスへ通信するには、パブリックサブネットとインターネットゲートウェイ、あるいはプライベートサブネットとNATゲートウェイを組み合わせ、いったんインターネット側へ出る経路が一般的でした。AWS PrivateLinkの公式ユーザーガイドはこの前提を置き換える仕組みとして位置づけており、通信はAWSのバックボーンに閉じたままサービスへ届きます。VPC内のサーバーがVPCへ配置されるEC2などの仮想サーバーである点は、Amazon EC2の仕組みを整理した記事で確認できます。専用線の敷設が数週間から数カ月かかるのに対し、PrivateLinkはコンソールから数分でエンドポイントを作成できる手軽さも設計上の利点です。

Interface型エンドポイント＝ENIとして働く通信の入口

PrivateLinkの実体は、指定したサブネットに作成されるInterface型VPCエンドポイントそのものです。これは仮想的なネットワークインターフェース（ENI）としてプライベートIPを1つ受け取り、そのIPがサービスへのトラフィックの入口になります。AWSサービスへのアクセス方式を説明した公式ページは、本番環境の推奨として1つのエンドポイントにつき最低2つのアベイラビリティゾーンの設定を挙げた公式の指針です。ENIが複数AZにあればラウンドロビンで健全なほうが選ばれ、1AZだけに作るとそのAZの不調で他AZのリソースからも到達できなくなります。エンドポイントのENIにはセキュリティグループを紐付けられるので、どのサーバーからのアクセスを許可するかをポート単位で絞り込めます。

プロバイダー側のエンドポイントサービスとNLBが担う公開の役割

PrivateLinkは、通信元のコンシューマーVPCにあるエンドポイントと、通信先のプロバイダーが公開するエンドポイントサービスの組み合わせで成り立ちます。プロバイダーはNetwork Load Balancer（NLB）、または検査用途のGateway Load Balancerを前段に置き、その背後のサーバー群をエンドポイントサービスとして差し出す立場です。コンシューマーはサービス名（com.amazonaws.vpce.ap-northeast-1.vpce-svc-xxxxのような識別子）を指定してInterface型エンドポイントを作成し、承認されると接続が確立します。自社サービスを共有する手順の公式ガイドが示すとおり、この方式ならプロバイダー側は自社のIPアドレス体系を相手に見せずにサービスだけを差し出せます。

VPCエンドポイントの2種類とInterface型・Gateway型の違い

PrivateLinkの理解を妨げる最大の原因が、名前の似たVPCエンドポイントに2種類あることです。両者は課金も経路制御の方式も別物で、PrivateLinkにあたるのは片方だけです。

Gateway型（S3・DynamoDB）とInterface型の根本的な違い

Gateway型VPCエンドポイントは、公式のゲートウェイエンドポイント解説のとおりS3とDynamoDBの2サービス専用で、ルートテーブルに宛先を書き加える方式で動きます。ENIを持たず、時間課金もデータ処理料も発生しない無料の仕組みで、PrivateLinkには含まれません。一方のInterface型がPrivateLinkの本体で、ENIを作り多数のAWSサービスや自社サービスへ私設接続します。S3のNATゲートウェイ回避によるコスト削減など、Gateway型を軸にした構成はVPCエンドポイントでNATゲートウェイを使わない理由を解説した記事が詳しく、本記事はInterface型（PrivateLink）の設計に絞って掘り下げます。

設計時は「S3・DynamoDBだけならGateway型で無料、それ以外や横断的な私設公開はInterface型」という切り分けが起点になります。S3は両方式に対応するため、ゲートウェイ経由の無料構成で足りるのか、Interface型でオンプレミスからも同じ名前解決を使いたいのかで選び分けます。

プライベートDNSで既存のサービス名を私設IPアドレスへ解決

Interface型エンドポイントには、プライベートDNSという機能があります。これを有効化すると、AWS側が隠しのプライベートホストゾーンを作り、たとえばSecrets Managerの既定のドメイン名が、パブリックIPではなくエンドポイントのプライベートIPへ解決されるようになります。アプリケーション側のエンドポイント設定を書き換えずに通信経路だけを私設化できる点が利点です。エンドポイントにはエンドポイントID.サービスID.リージョン.vpce.amazonaws.comというリージョナルDNS名と、AZ名を挟んだゾーナルDNS名の両方が作られ、AZ内で通信を閉じたいときは後者を指定します。プライベートDNS名の管理を説明した公式ページのとおり、VPCのenableDnsSupportとenableDnsHostnamesを有効にしておく前提があり、これを忘れると名前解決が想定どおりに切り替わりません。

AWS CLIでInterface型エンドポイントを作成し疎通を確かめる

PrivateLinkは概念を読むより、1つ作って名前解決の変化を見るほうが早く腹落ちします。ここではSSM用のエンドポイントを題材に、前提確認から作成、疎通確認までをコマンドで示します。

AWS CLIでSSM用のInterface型エンドポイントを作成する手順

作成前に押さえるのはVPCのDNS属性です。Interface型エンドポイントの作成手順を示した公式ページは前提条件として、プライベートDNSを使うならVPCのDNSホスト名とDNS解決を両方有効にすること、エンドポイント用のセキュリティグループでVPC内リソースからのHTTPSインバウンドを通すことを挙げています。指定しなければVPCの既定セキュリティグループが紐付き、意図しない許可範囲になりがちです。サブネットは1つのAZにつき1つだけ選べます。

# VPCのDNS属性を確認する（どちらも true であること）
aws ec2 describe-vpc-attribute --vpc-id vpc-0abc123 --attribute enableDnsSupport
aws ec2 describe-vpc-attribute --vpc-id vpc-0abc123 --attribute enableDnsHostnames

# 足りなければ有効化する
aws ec2 modify-vpc-attribute --vpc-id vpc-0abc123 --enable-dns-hostnames

# SSM用のInterface型エンドポイントを2つのAZに作成する
aws ec2 create-vpc-endpoint --vpc-endpoint-type Interface --vpc-id vpc-0abc123 --service-name com.amazonaws.ap-northeast-1.ssm --subnet-ids subnet-0a1 subnet-0b2 --security-group-ids sg-0endpoint --private-dns-enabled

DnsEntriesとncコマンドで名前解決と疎通を確かめる作業

作成後の確認で多くの人がつまずくのがpingです。Interface型エンドポイントはping要求に応答しない仕様で、公式ページはncまたはnmapを使うよう明記しています。疎通はTCPの443番で見るのが実務的な確認方法です。名前解決が私設IPへ切り替わったかどうかは、describe-vpc-endpointsが返すDnsEntriesと、VPC内のインスタンスから引いたdigの結果を突き合わせると判断できます。

# エンドポイントに割り当てられたDNS名を一覧する
aws ec2 describe-vpc-endpoints --vpc-endpoint-id vpce-099deb00b40f00e22 --query VpcEndpoints[*].DnsEntries

# VPC内のインスタンスから名前解決を確かめる（私設IPが返れば成功）
dig +short ssm.ap-northeast-1.amazonaws.com

# pingには応答しないのでTCP443で疎通を見る
nc -vz ssm.ap-northeast-1.amazonaws.com 443

もう1つ引っかかるのが共有サブネットです。VPC共有で他アカウントから渡されたサブネットには、VPCエンドポイントを作成も変更も削除もできないため、エンドポイントはサブネット所有者側で作る設計へ寄せます。

AWS PrivateLinkの主なユースケースと接続構成パターン

PrivateLinkが効くのは、通信を外部に出したくない、あるいはIPアドレス体系を相手に見せたくない場面です。代表的な3つの構成を、実装の判断とあわせて挙げます。

SSM・ECR・Secrets Managerなどマネージドサービスへの私設接続

プライベートサブネットのサーバーからSystems Manager（SSM）でセッションを張ったり、ECRからコンテナイメージを取得したり、Secrets Managerから資格情報を読み込んだりする通信を、インターネットへ出さずに完結できます。NATゲートウェイ経由の構成では処理データ量に応じた費用と外部露出が生じますが、Interface型エンドポイントに寄せると経路がAWS内部に閉じます。RDSのデータベースへ他VPCから私設アクセスする構成もこの一種で、対象サービスの詳細はAmazon RDSの仕組みを解説した記事を参照してください。どのサービスがInterface型に対応するかはPrivateLink対応サービスの一覧で随時更新されるため、構築前にIPv6対応の有無まで含めて確認します。

自社サービスやSaaSを他アカウント・他VPCへ私設で公開する構成

PrivateLinkは、AWSのマネージドサービスを使う側だけでなく、自社が提供する側にもなれます。NLBの背後に自社アプリを置いてエンドポイントサービスとして登録すると、顧客や別部門のVPCから、VPCピアリングを結ばずにサービスだけを私設で使ってもらえます。相手のアカウントIDを許可リストに登録して接続を承認する運用のため、公開範囲を明示的に管理できるのも実務上の利点です。SaaS事業者が顧客ごとに独立した接続点を提供する用途で広く採られている構成です。

オンプレミスからDirect Connect・VPN経由での到達

オンプレミスのデータセンターからPrivateLinkのエンドポイントへ届かせるには、Direct ConnectやSite-to-Site VPNでVPCと接続したうえで、Interface型エンドポイントのプライベートIPへ通信を向けます。見落とされがちなのが名前解決の経路です。VPC内の名前解決を担うRoute 53 ResolverはVPCの外から直接は使えず、オンプレミスからプライベートDNS名を引くにはResolverのインバウンドエンドポイントと転送ルールを併用します。これを飛ばすと経路はつながっているのにドメイン名がパブリックIPへ解決され、通信が外へ抜けてしまう落とし穴です。VPCやサブネット、ルーティングの初期設計はAWS環境構築の手順を整理した記事にまとめてあり、PrivateLinkはその上に載せる接続レイヤーとして設計します。

PrivateLinkとVPCピアリング・Transit Gatewayの使い分け

VPC間や外部との接続手段はPrivateLinkだけではありません。混同しやすいVPCピアリングやTransit Gatewayと、役割の違いを整理しておくと選定を誤りません。

接続粒度・通信方向・CIDR重複の観点で見るピアリングとの違い

VPCピアリングは2つのVPCをネットワークレベルで相互接続し、双方向にCIDR全体が見える関係を作ります。このためCIDRが重複しているVPC同士はピアリングできません。PrivateLinkは特定のサービスへ片方向で到達させるだけなので、コンシューマーとプロバイダーのCIDRが重なっていても影響を受けず、相手のネットワーク全体を見せずに済みます。多数のVPCへ全面的に相互接続したいならピアリングやTransit Gateway、サービス単位で最小限に露出したいならPrivateLink、という粒度の違いで選びます。

Transit GatewayやNAT Gatewayと役割が重ならない理由

Transit Gatewayは多数のVPCやオンプレミスを1つのハブに集約し、相互にルーティングするための土台です。NAT Gatewayはプライベートサブネットからインターネットへ出るための出口で、いずれもネットワーク全体の到達性を広げる方向に働きます。PrivateLinkはこれらと競合せず、むしろ組み合わせて使います。Transit Gatewayで社内網をつなぎつつ、外部SaaSへの接続だけPrivateLinkで私設化する、といった役割分担が実務的な設計です。SaaSとAWSの間のデータ連携をノーコードで組む仕組みはAmazon AppFlowとはで解説しています。出口をまとめて絞りたいのか、特定サービスへ閉じた経路を足したいのかで、選ぶ道具が変わります。

AWS PrivateLinkの料金体系と採用・見送りの判断基準

PrivateLinkは無料ではありません。同じ「VPCエンドポイント」でもGateway型が無料なのに対し、Interface型は課金対象で、台数と転送量で総額が動きます。ここを押さえて採用可否を言い切ります。

Interface型エンドポイントの時間課金とデータ処理料金

Interface型エンドポイントの費用は、エンドポイント1つをAZごとに置くことに対する時間課金と、通過したデータ量に応じた処理料の2軸で構成されます。2026年9月時点でAWSのPrice List APIから東京リージョンを引くと、エンドポイント1つあたり1時間0.014ドル、データ処理は月1PBまで1GBあたり0.01ドル、1PBを超えて5PBまでが0.006ドル、5PB超が0.004ドルという階層でした。単価はリージョンで変わるうえ改定もあるため、見積もり前にAWS PrivateLinkの公式料金ページで実値を確認します。本番推奨の2AZ構成なら時間課金だけで月あたり20ドル台前半、これに転送量分が乗る規模感です。検査用のGateway Load Balancerエンドポイントは1時間0.014ドルに1GBあたり0.0035ドルという別体系で、単価表を読み違えないよう区別します。少量の通信のためだけに多数のエンドポイントを並べると、NATゲートウェイを維持するより割高になる場合もあるため、本数と転送量の見積もりが費用設計の起点になります。

PrivateLinkを採用すべき条件と見送るべき場面の判断

PrivateLinkを採用すべきなのは、通信を外部に晒せない規制要件がある、相手にIPアドレス体系を見せずにサービスだけ提供したい、CIDRが重複するVPC間でサービス連携したい、のいずれかに当てはまるときです。この条件下では、ピアリングやNAT経由より安全でスコープが狭い接続を組めます。逆に見送るべきなのは、対象がS3・DynamoDBだけで無料のGateway型で足りる場合と、ごく小規模でセキュリティ要件も緩く、NATゲートウェイ経由の既存構成で十分な場合です。要件が薄いのに全サービスをInterface型へ置き換えると、AZごとの時間課金がかさんで費用倒れになります。ネットワーク設計や移行の判断に迷う場合は、AWS上のシステム構築を手がけるインフラ構築（AWS・Google Cloud・Azure）の受託開発で、要件に合わせた接続方式の選定から相談できます。

よくある質問

AWS PrivateLinkの理解でつまずきやすい論点を、実装者からよく寄せられる質問の形で整理します。

AWS PrivateLinkとVPCエンドポイントは同じものですか？

VPCエンドポイントにはGateway型とInterface型の2種類があり、PrivateLinkにあたるのはInterface型のほうです。Gateway型はS3とDynamoDB専用でルートテーブル方式・無料であり、PrivateLinkには含まれません。Interface型はENIとして多数のサービスへ私設接続する仕組みで、これがPrivateLinkの実体です。両者を同一視すると料金や対応サービスを取り違えるため、区別して設計してください。

AWS PrivateLinkの料金はどのくらいかかりますか？

Interface型エンドポイントは、AZごとの時間課金と処理データ量に応じたGB課金の2軸で費用が発生します。2026年9月時点の東京リージョンでは、エンドポイント1つにつき1時間0.014ドル、データ処理が月1PBまで1GBあたり0.01ドルという単価でした。本番推奨の2AZ構成なら時間課金は月20ドル台前半が目安になります。リージョンによって単価が変わるので、公式の料金ページで実値を確認してください。

PrivateLinkを使うとインターネットゲートウェイは不要になりますか？

PrivateLinkで到達させたいサービスへの通信については、インターネットゲートウェイもNATゲートウェイも経由せずに済みます。ただしOSのパッチ取得や、PrivateLink非対応の外部サイトへの通信が別途必要なら、その分の出口は依然として必要です。対象サービスがすべてInterface型に対応し、外部通信をなくせる構成に限り、出口そのものを削れます。

自社で開発したサービスもPrivateLinkで公開できますか？

公開できます。Network Load Balancerの背後に自社アプリを配置し、エンドポイントサービスとして登録すると、他アカウントや他VPCから私設で接続してもらえます。接続を求めてきたアカウントを許可リストで承認する運用のため、公開範囲を明示的に管理できる点も利点です。SaaSを顧客ごとに私設提供する用途で広く採られている方式です。

PrivateLinkとVPCピアリングはどちらを選ぶべきですか？

VPC全体を双方向につなぎたいならVPCピアリング、特定のサービスだけへ片方向で最小限に露出したいならPrivateLinkが基本の分岐です。CIDRが重複するVPC間ではピアリングを組めないため、その場合はPrivateLinkが有力な選択肢になります。相手のネットワーク全体を見せたくない、あるいはサービス単位で公開を絞りたい要件なら、PrivateLinkを軸に設計してください。

関連記事

• AWS VPCエンドポイントを使い、NATゲートウェイを使用しない理由とは？：無料のGateway型でS3通信のコストを抑える具体構成
• AWS環境構築の手順｜VPC・EC2・IAM・セキュリティグループの初期設計を解説：PrivateLinkを載せる前提となるVPCとネットワークの初期設計
• Amazon EC2とは？仕組み・インスタンスタイプと料金モデル・採用判断を解説：VPC内で動く仮想サーバーの構成と料金の基礎
• Amazon RDSとは？仕組み・対応エンジンと料金モデル・採用判断を解説：Interface型で私設アクセスする代表的なマネージドDB
• クラウドネイティブとは？CNCFの定義・構成技術と導入判断を解説：PrivateLinkが支えるクラウドネイティブ全体像の上位概念