AWS PrivateLinkとは?仕組み・VPCエンドポイントとの違いと料金・採用判断を実装者目線で解説
AWS PrivateLinkは、VPCからAWSのサービスや他アカウントのサービスへ、インターネットを経由せずプライベートに接続するための仕組みです。その実体は、サブネット内に作られるInterface型VPCエンドポイント(ENI)です。この記事では、PrivateLinkとエンドポイントサービス・NLBの関係、混同されやすいGateway型VPCエンドポイント(S3・DynamoDB)との違い、SSMやECR・Secrets Managerへの私設接続や自社サービスの私設公開といった構成を一次情報で整理します。VPCピアリングやTransit Gatewayとの使い分け、時間課金とデータ処理料からなる料金体系、そして採用すべき条件と見送るべき場面まで、ネットワーク設計で迷う論点を具体的に示します。
目次
まとめ:AWS PrivateLinkの仕組み・料金と採用判断の要点
AWS PrivateLinkは、通信をAWSの内部ネットワークに閉じたまま、特定のサービスだけへ到達させる私設接続です。利用者はサブネットにInterface型VPCエンドポイントを作り、そこに割り当てられたプライベートIPを入口にしてサービスへアクセスします。インターネットゲートウェイもNATゲートウェイも経由しないため、外部にトラフィックを晒さずにマネージドサービスや他社SaaSへつなげます。
実装で最初につまずくのが、無料のGateway型VPCエンドポイント(S3・DynamoDB専用)との混同です。PrivateLinkにあたるのはInterface型のほうで、こちらは1AZあたりの時間課金と処理データ量に応じたGB課金が発生します。VPC全体を双方向につなぐVPCピアリングとは異なり、PrivateLinkは単一サービスへの片方向接続でCIDR重複の心配がない点が設計上の分かれ目になります。採用可否に迷う場合は、本記事後半の判断基準を自社の構成へ当てはめてください。
AWS PrivateLinkの仕組みとInterface型エンドポイントの実体
PrivateLinkを設計へ落とすには、コンシューマー側のエンドポイントとプロバイダー側のサービスがどう対になるかを押さえます。ここを曖昧にすると、到達できない構成や、意図せず公開範囲を広げた構成を作り込みやすくなります。
インターネットを経由せず実現する私設接続という設計思想の勘所
従来、VPC内のサーバーからS3や外部サービスへ通信するには、パブリックサブネットとインターネットゲートウェイ、あるいはプライベートサブネットとNATゲートウェイを組み合わせ、いったんインターネット側へ出る経路が一般的でした。PrivateLinkはこの前提を変え、通信をAWSのバックボーンに閉じたままサービスへ届けます。VPC内のサーバーがVPCへ配置されるEC2などの仮想サーバーである点は、Amazon EC2の仕組みを整理した記事で確認できます。専用線の敷設が数週間から数カ月かかるのに対し、PrivateLinkはコンソールから数分でエンドポイントを作成できる手軽さも設計上の利点です。
Interface型エンドポイント=ENIとして働く通信の入口
PrivateLinkの実体は、指定したサブネットに作成されるInterface型VPCエンドポイントそのものです。これは仮想的なネットワークインターフェース(ENI)としてプライベートIPを1つ受け取り、そのIPがサービスへのトラフィックの入口になります。可用性を担保するため、通常は複数のアベイラビリティゾーンのサブネットにそれぞれエンドポイントを作り、AZごとにENIが1つずつ生成される構成が一般的です。エンドポイントの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)の設計に絞って掘り下げます。
| 観点 | Gateway型 | Interface型(PrivateLink) |
|---|---|---|
| 対象サービス | S3・DynamoDB | 多数のAWS・自社サービス |
| 接続の実体 | ルートテーブル | ENI(プライベートIP) |
| 料金 | 無料 | 時間課金+データ処理料 |
| 経路制御 | ルート追加 | プライベートDNS |
設計時は「S3・DynamoDBだけならGateway型で無料、それ以外や横断的な私設公開はInterface型」という切り分けが起点になります。S3は両方式に対応するため、ゲートウェイ経由の無料構成で足りるのか、Interface型でオンプレミスからも同じ名前解決を使いたいのかで選び分けます。
プライベートDNSで既存のサービス名を私設IPアドレスへ解決
Interface型エンドポイントには、プライベートDNSという機能があります。これを有効化すると、たとえばSecrets Managerの既定のドメイン名が、パブリックIPではなくエンドポイントのプライベートIPへ解決されるようになります。アプリケーション側のエンドポイント設定を書き換えずに通信経路だけを私設化できる点が利点です。既存コードへの影響を抑えて移行できます。ただしVPCのenableDnsSupportとenableDnsHostnamesを有効にしておく前提があり、これを忘れると名前解決が想定どおりに切り替わりません。
AWS PrivateLinkの主なユースケースと接続構成パターン
PrivateLinkが効くのは、通信を外部に出したくない、あるいはIPアドレス体系を相手に見せたくない場面です。代表的な3つの構成を、実装の判断とあわせて挙げます。
SSM・ECR・Secrets Managerなどマネージドサービスへの私設接続
プライベートサブネットのサーバーからSystems Manager(SSM)でセッションを張ったり、ECRからコンテナイメージを取得したり、Secrets Managerから資格情報を読み込んだりする通信を、インターネットへ出さずに完結できます。NATゲートウェイ経由の構成では処理データ量に応じた費用と外部露出が生じますが、Interface型エンドポイントに寄せると経路がAWS内部に閉じます。RDSのデータベースへ他VPCから私設アクセスする構成もこの一種で、対象サービスの詳細はAmazon RDSの仕組みを解説した記事を参照してください。どのサービスがInterface型に対応するかは公式ドキュメントで随時更新されるため、構築前に対応状況を確認します。
自社サービスやSaaSを他アカウント・他VPCへ私設で公開する構成
PrivateLinkは、AWSのマネージドサービスを使う側だけでなく、自社が提供する側にもなれます。NLBの背後に自社アプリを置いてエンドポイントサービスとして登録すると、顧客や別部門のVPCから、VPCピアリングを結ばずにサービスだけを私設で使ってもらえます。相手のアカウントIDを許可リストに登録して接続を承認する運用のため、公開範囲を明示的に管理できるのも実務上の利点です。SaaS事業者が顧客ごとに独立した接続点を提供する用途で広く採られている構成です。
オンプレミスからDirect Connect・VPN経由での到達
オンプレミスのデータセンターからPrivateLinkのエンドポイントへ届かせるには、Direct ConnectやSite-to-Site VPNでVPCと接続したうえで、Interface型エンドポイントのプライベートIPへ通信を向けます。オンプレミスのシステムから、インターネットを介さずにAWSのマネージドサービスや自社サービスを呼び出せるため、社内ネットワークの延長として扱える構成です。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、という粒度の違いで選びます。
| 方式 | 接続粒度 | 通信方向 | CIDR重複 |
|---|---|---|---|
| PrivateLink | 単一サービス | 片方向 | 影響なし |
| VPCピアリング | VPC全体 | 双方向 | 不可 |
| Transit Gateway | 多VPCハブ | 双方向 | 不可 |
Transit GatewayやNAT Gatewayと役割が重ならない理由
Transit Gatewayは多数のVPCやオンプレミスを1つのハブに集約し、相互にルーティングするための土台です。NAT Gatewayはプライベートサブネットからインターネットへ出るための出口で、いずれもネットワーク全体の到達性を広げる方向に働きます。PrivateLinkはこれらと競合せず、むしろ組み合わせて使います。Transit Gatewayで社内網をつなぎつつ、外部SaaSへの接続だけPrivateLinkで私設化する、といった役割分担が実務的な設計です。出口をまとめて絞りたいのか、特定サービスへ閉じた経路を足したいのかで、選ぶ道具が変わります。
AWS PrivateLinkの料金体系と採用・見送りの判断基準
PrivateLinkは無料ではありません。同じ「VPCエンドポイント」でもGateway型が無料なのに対し、Interface型は課金対象で、台数と転送量で総額が動きます。ここを押さえて採用可否を言い切ります。
Interface型エンドポイントの時間課金とデータ処理料金
Interface型エンドポイントの費用は、エンドポイント1つをAZごとに置くことに対する時間課金と、通過したデータ量に応じた処理料の2軸で構成されます。東京リージョンでは1AZ・1時間あたり0.01ドル台、処理データ1GBあたり0.01ドル前後が目安で、正確な単価はリージョンにより変わるため公式の料金ページで実値を確認します(2026年7月時点)。可用性のためにマルチAZで冗長化すると、AZの数だけ時間課金が積み上がる点に注意します。少量の通信のためだけに多数のエンドポイントを並べると、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軸で費用が発生します。東京リージョンでは1AZ・1時間あたり0.01ドル台、処理1GBあたり0.01ドル前後が目安ですが、リージョンにより単価が変わるため公式の料金ページで実値を確認します。マルチAZで冗長化するとAZ数だけ時間課金が積み上がる点も見積もりに含めてください。
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が支えるクラウドネイティブ全体像の上位概念