導入
Transit Gatewayは「ネットワーク全体をつなぐ」ための仕組みでした。一方で、「特定の1つのサービスだけをプライベートに公開したい／消費したい」という、もっと限定的なニーズもあります。VPC全体を丸ごとつなぐのではなく、サービス単位で安全に橋渡しするのが AWS PrivateLink です。
説明
AWS PrivateLink は、VPCを越えてサービスをプライベートに公開・消費する仕組みです。利用側のVPCには インターフェイスVPCエンドポイント（ENI） が作られ、公開側は エンドポイントサービス（VPC Endpoint Service） として自分のNetwork Load Balancer（NLB）の背後にあるサービスを公開します。
TGWとの決定的な違いは、ネットワーク全体をつなぐか、1つのサービスだけをつなぐかです。PrivateLinkでは相手のVPC内部のルーティングテーブルやIPレンジを一切気にする必要がなく、CIDRが重複していても利用できます。これはマルチテナントSaaS提供や、買収した会社のVPCとCIDRが被っている場合などに極めて有効です。
flowchart LR
subgraph ConsumerVPC["利用者VPC"]
C["アプリ"] --> EP["インターフェイス<br/>VPCエンドポイント"]
end
subgraph ProviderVPC["提供者VPC"]
NLB["Network Load Balancer"] --> SVC["サービス"]
end
EP -- "PrivateLink<br/>（AWSネットワーク内）" --> NLB
| 比較 | VPCピアリング/TGW | PrivateLink |
|---|---|---|
| 接続の単位 | VPC全体のネットワーク | 特定の1サービスだけ |
| CIDR重複 | 不可（ルーティングが破綻） | 問題なし |
| 双方向の可視性 | 相手VPCの内部が見える | 提供者の内部は見えない（サービスだけ公開） |
| 向いている用途 | 社内の多数VPCの相互接続 | SaaS提供、部門をまたいだサービス提供 |
なお VPCエンドポイント（Gateway型／S3・DynamoDB向け） はPrivateLinkとは別物で、AWSのパブリックサービスにインターネットを経由せずアクセスするための機能です。PrivateLinkは自分たちが作ったサービス（NLB配下）を公開する用途に使う点を区別してください。
具体例
TGWでは解けない2つのシーンで、PrivateLinkが真価を発揮します。
- SaaS事業者が、多数の顧客に自社APIだけを提供したい … 顧客のVPCと自社VPCを丸ごとつなぐ（ピアリング/TGW）のは、双方の内部が見えてしまい危険だし、顧客ごとにCIDR調整も必要で非現実的。→ PrivateLinkなら、NLB配下のそのAPIサービス1つだけを公開。顧客は自分のVPCにインターフェイスエンドポイントを作るだけで、提供者側の内部ネットワークは一切見えない。
- 買収した子会社のVPCとCIDRが重複しているが、特定APIだけ連携したい … ネットワーク全体をつなぐ方式はCIDR重複で破綻する。→ PrivateLinkは相手のIPレンジを気にしないので、CIDRが被っていてもそのサービスを消費できる。
判断軸は「ネットワーク全体をつなぐか、1つのサービスだけ橋渡しするか」。全体接続はTGW、サービス単体（特にSaaS提供やCIDR重複）はPrivateLink。TGWと混同せず、この一線で選び分けます。
読んでみよう
「異なる部門・異なる会社（買収先など）のVPCとCIDRが重複していて、それでも特定のAPIだけ連携したい」という要件が出たら、PrivateLinkが最有力候補です。「ネットワーク全体か、サービス単体か」の区別がTGWとPrivateLinkを選び分ける鍵になります。