最初に押さえるべき 4 つのポイント
❌ PrivateLink なし（従来の接続）
公道（インターネット）を通るため、IGW / NAT やパブリック IP が必要。セキュリティ設定が複雑で、攻撃表面が広がる。
✅ PrivateLink あり（プライベート接続）
地下通路（PrivateLink）で直結。インターネットに出ないため、IGW / NAT もパブリック IP も不要で安全。
PrivateLink の接続フローを図解
サービス提供者（Provider）と利用者（Consumer）の 2 つの役割を、オフィスビルのたとえで理解しましょう。
PrivateLink の 4 つの強み
各特徴をオフィスビルの地下通路のたとえと一緒に理解しましょう。
VPC エンドポイントは 3 種類ある
PrivateLink を使うのは「Interface 型」と「Gateway Load Balancer 型」です。Gateway 型は PrivateLink を使いません。
Interface エンドポイント
サブネットに ENI（ネットワークインターフェース）を作成し、プライベート IP でサービスにアクセスします。PrivateLink の本体。
Gateway エンドポイント
ルートテーブルにエントリを追加して S3 / DynamoDB にアクセス。ENI は作成されず、PrivateLink は不使用。無料。
Gateway LB エンドポイント
GWLB（Gateway Load Balancer）と連携し、トラフィックを透過的にセキュリティアプライアンスに転送。PrivateLink を使用。
| 比較項目 | 🔌 Interface | 🚪 Gateway | 🔍 Gateway LB |
|---|---|---|---|
| PrivateLink 使用 | ✅ はい | ❌ いいえ | ✅ はい |
| ENI 作成 | ✅ あり（Private IP 付与） | ❌ なし（ルートテーブル方式） | ✅ あり |
| 対象サービス | 多数の AWS サービス、自作サービス | S3、DynamoDB のみ | GWLB 連携サービス |
| 料金 | 有料（時間＋データ転送） | 無料 | 有料 |
| Security Group | ✅ 適用可能 | ❌ 不可（ポリシーで制御） | ✅ 適用可能 |
| たとえ | 🏢 ビル間の地下通路の入口 | 🏢 ビル内の直通エレベーター | 🏢 通路のセキュリティ検査窓口 |
VPC エンドポイントサービスの作り方
自分のサービスを PrivateLink 経由で他の VPC / アカウントに公開する手順を、たとえと一緒に理解しましょう。
⚖️ NLB（Network Load Balancer）を作成する
サービスを提供する VPC に NLB を作成し、ターゲットグループに EC2 やコンテナを登録します。PrivateLink は NLB を通じてトラフィックをルーティングするため、NLB は必須です（特定ケースでは GWLB も可）。
# NLB を作成 aws elbv2 create-load-balancer \ --name my-privatelink-nlb \ --type network \ --scheme internal \ --subnets subnet-aaa111 subnet-bbb222 # ターゲットグループを作成 aws elbv2 create-target-group \ --name my-service-targets \ --protocol TCP \ --port 443 \ --vpc-id vpc-provider123 \ --target-type instance
📡 VPC エンドポイントサービスを作成する
NLB を指定して Endpoint Service を作成します。これにより、他の VPC / アカウントが PrivateLink 経由で接続できる「窓口」が登録されます。
# エンドポイントサービスを作成（NLB を指定） aws ec2 create-vpc-endpoint-service-configuration \ --network-load-balancer-arns \ arn:aws:elasticloadbalancing:ap-northeast-1:111111111111:loadbalancer/net/my-privatelink-nlb/abc123 \ --acceptance-required # → ServiceId: vpce-svc-0xxxxxxxxxxxx が返される # acceptance-required = 接続リクエストを手動承認するかどうか
🔑 アクセス許可を設定する
特定の AWS アカウント / IAM プリンシパルにアクセスを許可するか、「*」で全員に公開します。--acceptance-required を有効にしておけば、接続リクエストを個別に承認／拒否できます。
# 特定のアカウントにアクセス許可 aws ec2 modify-vpc-endpoint-service-permissions \ --service-id vpce-svc-0xxxxxxxxxxxx \ --add-allowed-principals \ "arn:aws:iam::222222222222:root" \ "arn:aws:iam::333333333333:root"
🔌 Consumer 側で VPC Endpoint (Interface) を作成する
許可された Consumer アカウントが、Provider の Endpoint Service の Service Name を指定して Interface Endpoint を作成します。ENI が自動的にサブネットに作成されます。
# Consumer 側で VPC Endpoint (Interface) を作成 aws ec2 create-vpc-endpoint \ --vpc-id vpc-consumer456 \ --vpc-endpoint-type Interface \ --service-name \ com.amazonaws.vpce.ap-northeast-1.vpce-svc-0xxxxxxxxxxxx \ --subnet-ids subnet-ccc333 subnet-ddd444 \ --security-group-ids sg-consumer789
✅ Provider 側で接続を承認する
acceptance-required が有効な場合、Provider 側で接続リクエストを手動承認します。承認後、Consumer は PrivateLink 経由でサービスを利用開始できます。
# Provider 側で接続リクエストを承認 aws ec2 accept-vpc-endpoint-connections \ --service-id vpce-svc-0xxxxxxxxxxxx \ --vpc-endpoint-ids vpce-0yyyyyyyyyyyy
🛡️ セキュリティ：多層防御の仕組み
PrivateLink のセキュリティは「地下通路の多重セキュリティ」のイメージです。入口の鍵、ガードマン、ID チェック、監視カメラの 4 層で守ります。
PrivateLink はこんな場面で活躍する
企業での実際の使いどころを 4 つ紹介します。
SaaS サービスへのプライベート接続
金融機関が Datadog や Snowflake などの SaaS をインターネット経由ではなく PrivateLink 経由で利用。コンプライアンス要件を満たしつつ、安全にモニタリングやデータ分析を行える。
マルチアカウント環境の共有サービス
AWS Organizations の複数アカウントから、共有サービス VPC に配置した内部 API や認証基盤に PrivateLink 経由でアクセス。VPC ピアリングの管理爆発を回避。
医療データのセキュアなアクセス
HIPAA 準拠が求められる医療システムで、患者データを扱う S3 や RDS へのアクセスをプライベートネットワーク内に閉じ、規制要件を満たす。
マイクロサービス間のプライベート通信
EC コマースの決済サービスと注文サービスが異なる VPC にある場合、PrivateLink でプライベートに接続。パブリックインターネットを通らない低レイテンシーな通信を実現。
PrivateLink と VPC ピアリング：どう使い分ける？
どちらも VPC 間をプライベートに接続する方法ですが、目的とスケーラビリティが大きく異なります。
🔗 PrivateLink
一方向の「サービス提供→利用」に特化。何百 VPC でもスケール。CIDR 重複 OK。
🤝 VPC ピアリング
双方向の「対等な接続」。数が増えると N×N のメッシュが爆発。CIDR 重複 NG。
| 比較項目 | 🔗 PrivateLink | 🤝 VPC ピアリング |
|---|---|---|
| 通信方向 | 一方向（Consumer → Provider） | 双方向 |
| CIDR 重複 | ✅ OK（ENI 経由なので問題なし） | ❌ NG（ルーティング衝突） |
| スケーラビリティ | ✅ 高い（1 対多） | ⚠️ 低い（N×N のメッシュ） |
| クロスアカウント | ✅ 対応 | ✅ 対応 |
| 主な用途 | サービス公開・SaaS・API | VPC 間の全面的な通信 |
| たとえ | 🏢 出前サービス（注文方向のみ） | 🏢 隣のビルとドアで直結（自由往来） |
💰 コストの考え方
Interface Endpoint（PrivateLink）には「時間料金」と「データ処理料金」の 2 つがかかります。Gateway Endpoint（S3 / DynamoDB）は無料です。
PrivateLink を運用するための推奨事項
🔒 最小権限の原則を適用
Endpoint Policy と Allowed Principals で接続先・接続元を厳密に制限する。「*」（全公開）は本当に必要な場合のみ使用。
🌐 Private DNS を有効化
Interface Endpoint の Private DNS を有効にすると、既存アプリのコード変更なしでプライベート接続に切り替えられる。
🔄 複数 AZ にエンドポイントを配置
高可用性のため、少なくとも 2 つの AZ にエンドポイントを作成。Provider 側の NLB も複数 AZ に配置。
📊 VPC Flow Logs で監視
ENI に関連するトラフィックを Flow Logs で記録・分析し、不正アクセスやトラフィックパターンの異常を検知。
🛡️ Security Group は必ず設定
Interface Endpoint の ENI にはデフォルトで全トラフィック許可の SG がつく場合がある。必ず適切なインバウンドルールに絞り込む。
🏷️ タグ付けで管理しやすく
Endpoint / Endpoint Service にプロジェクト名・環境名のタグを付与し、コスト配分やリソース管理を効率化。
よくある問題と解決策
accept-vpc-endpoint-connections で承認する。
よくある質問
🔗 PrivateLink = Interface Endpoint
「PrivateLink」が登場したら Interface Endpoint（ENI ベース）を思い出す。Gateway Endpoint は PrivateLink を使わない。
⚖️ NLB / GWLB が必須
自作サービスを PrivateLink で公開するには NLB または GWLB が必須。ALB は不可。
🌐 CIDR 重複 OK
PrivateLink は CIDR 重複を許容する。VPC ピアリングは CIDR 重複 NG。これは頻出の差別化ポイント。
💰 S3 は Gateway が無料
S3 向けに「コスト最適化」が問われたら Gateway Endpoint を選ぶ。Interface Endpoint は有料。