AWS PrivateLink は、AWS サービスや自社サービスを インターネットを経由せずプライベートに公開 する仕組みです。 VPC 間の CIDR 重複を許容し、サービス単位での安全な提供を実現します。本記事では PrivateLink のエンドポイント種別と設計を SAA / SAP 両面から整理します。

SAA レベル：基礎概念

PrivateLink が解決する課題

従来、VPC から AWS サービス（S3, DynamoDB など）にアクセスするには NAT Gateway + インターネット経由 が必要でした。これには以下の課題があります：

データがインターネットを通る: セキュリティリスク
NAT Gateway コスト: データ転送料金が発生
パブリック IP 必要: プライベートサブネットから直接アクセス不可

PrivateLink はこれらを プライベート接続 で解決します。

SAA レベル：基礎概念

PrivateLink の核心は 「インターネットを通らずに AWS サービスや自社サービスにプライベートアクセス」 です。これにより、セキュリティ向上と NAT Gateway コスト削減を同時に実現できます。 SAA では「プライベートサブネットから S3 にアクセスする方法」として頻出です。

3 種類の VPC エンドポイント

PrivateLink には 3 種類のエンドポイント があります。この分類は SAA の超頻出です。

エンドポイント種別	対象	課金	アクセス方式
Gateway Endpoint	S3, DynamoDB のみ	無料	ルートテーブル経由
Interface Endpoint	多くの AWS サービス + 自社サービス	有料 (ENI)	ENI のプライベート IP
Gateway Load Balancer Endpoint	セキュリティアプライアンス	有料	GLB 経由の透過処理

SAA 試験のポイント

Gateway Endpoint は S3 と DynamoDB だけで、かつ無料 です。それ以外のサービスは Interface Endpoint（有料）を使います。「S3 へのプライベートアクセスは Gateway Endpoint で無料」という事実は SAA の定番問題です。

Gateway Endpoint の仕組み

Gateway Endpoint は ルートテーブルに経路を追加 して動作します。

VPC ルートテーブル:
  10.0.0.0/16   → local
  0.0.0.0/0     → NAT Gateway
  pl-xxx (S3)   → vpce-xxx (Gateway Endpoint)   ← 追加

ルートテーブルベース: ENI を持たない、サブネット単位で有効化
無料: データ転送料金なし
制限: S3 と DynamoDB のみ対応

Interface Endpoint の仕組み

Interface Endpoint は VPC 内に ENI を作成 し、プライベート IP でサービスに到達します。

[消費者 VPC]
  └── Private Subnet
        └── ENI (10.0.1.10) ← Interface Endpoint
              │
              ▼ (PrivateLink 経由)
        [AWS サービス / 自社サービス]

ENI ベース: プライベート IP を DNS で解決
有料: 時間料金 + データ転送料金
対応範囲広: SSM, Secrets Manager, KMS, その他多くの AWS サービス + 自社サービス

SAA 頻出

Interface Endpoint には プライベートホストゾーン (Private Hosted Zone) の DNS 名が割り当てられ、元のサービス DNS 名（例: ssm.us-east-1.amazonaws.com）が 自動的にエンドポイント IP に解決 されます。これでアプリ側の変更なしにプライベートアクセスが実現します。

SAP レベル：高度な設計シナリオ

自社サービスを PrivateLink で公開

SAP では 自社サービスを他アカウント/VPC に PrivateLink で提供 する設計が問われます。

SAP レベル：高度な設計シナリオ

PrivateLink を使うと NLB 背後の自社サービスを他 VPC にプライベート公開 できます。これが SaaS プロバイダが顧客に安全にサービスを提供する際の標準アーキテクチャです。 CIDR 重複を許容するため、顧客 VPC との統合が極めて容易になります。

[サービス提供者 VPC]
  └── NLB
        └── EC2 / ECS (アプリ)
              ▲
      [AWS PrivateLink サービス]
              ▲
[消費者 VPC (顧客)]
  └── Interface Endpoint (ENI)
        └── 顧客アプリからのアクセス

設計のステップ：

提供者側: NLB を作成し、その背後にアプリを配置
提供者側: NLB を PrivateLink サービスとして公開
消費者側: VPC エンドポイントを作成し、サービスに接続
DNS 設定: カスタム DNS 名でサービスを名前解決

CIDR 重複シナリオでの活用

PrivateLink の最大の強みは CIDR 重複を許容 することです。

シナリオ	Peering/TGW	PrivateLink
CIDR 重複 VPC 間接続	不可	可能
M&A で統合した VPC からのサービス利用	要 CIDR 再設計	そのまま接続可
複数顧客 VPC への SaaS 提供	顧客毎に CIDR 調整	CIDR 問わず提供可

設計上の制約

PrivateLink は 片方向（消費者→提供者） のみの通信です。提供者から消費者 VPC へのコールバックやPush通信はできないため、双方向通信が必要な場合は設計を変える（Webhook をパブリック経由にする等）必要があります。

Gateway Load Balancer Endpoint

3 つ目のエンドポイント種別である Gateway Load Balancer Endpoint (GLBE) は、セキュリティアプライアンス向けの特殊エンドポイントです。

透過的トラフィック処理: パケットを検査して元の宛先へ転送
サードパーティ製ファイアウォール/IDS 連携: Palo Alto, Fortinet 等と統合
ルートテーブルで制御: 特定経路を GLBE に向けて検査

[VPC]
  Subnet ──(route)── GLBE ── [GWLB] ── セキュリティアプライアンス
                                    └── (検査後) 元の宛先へ転送

GLBE の用途

GLBE は 「すべてのトラフィックをセキュリティアプライアンスに透過的に通す」 ための仕組みです。従来のインラインアプライアンス構成をクラウドで再現するために設計されました。 SAP の高度なネットワークセキュリティ設計で登場します。

DNS 設計とプライベートホストゾーン

PrivateLink を自社サービスで使う場合、DNS 設計 が重要です。

DNS 方式	説明	ユースケース
プライベートホストゾーン	カスタム DNS 名をエンドポイントにマッピング	分かりやすいサービス名
エンドポイントのデフォルト DNS	`<service-id>.vpce.amazonaws.com`	簡易セットアップ
インターフェース DNS 名上書き	既存 DNS 名をプライベートに差し替え	アプリ無変更で移行

DNS 設計のベストプラクティス

カスタム DNS 名 + プライベートホストゾーン を使うと、消費者側アプリは api.mycompany.internal のような分かりやすい名前でアクセスでき、かつその名前が各リージョンのエンドポイントに解決されます。グローバル展開での SAP 設計で必須の手法です。

クロスアカウント / クロスリージョン設計

PrivateLink は クロスアカウント・クロスリージョン で利用可能です。

クロスアカウント: 別 AWS アカウントのサービスをエンドポイント経由で利用
クロスリージョン: 別リージョンのサービスにも接続可能
アクセス制御: サービス提供者が消費者アカウント/ARN をホワイトリスト化

[アカウント A (提供者)]
  └── NLB → アプリ
        ▲ (PrivateLink, A の許可リストに B を追加)
[アカウント B (消費者)]
  └── VPC Endpoint → アクセス

許可リストの設計

提供者側は どのアカウント/ARN がエンドポイントを作成できるか を許可リストで管理します。これを怠ると、意図しないアカウントからサービスに接続されるリスクがあります。 SAP ではこのアクセス制御設計がセキュリティ論点として問われます。

コスト最適化設計

コスト要素	説明	最適化
Endpoint 時間料金	AZ ごとに発生	必要な AZ のみに配置
データ処理料金	GB あたり	大量トラフィックは要試算
Gateway Endpoint	無料	S3/DynamoDB は必ず Gateway を選ぶ