AWSネットワークにおけるSaaSへの接続方式まとめ〜PrivateLink編〜

本記事は夏休みクラウド自由研究2026 8/24付の記事です。

残暑見舞い申し上げます。皆様いかがお過ごしでしょうか。
AWS内製化支援「テクニカルエスコート」担当の間世田です。

今回は、SaaS提供する際の利用者とのAWSネットワークの接続パターンについて、初学者向けに解説を行いたいと思います。

本記事は以下のAWSドキュメントを参考にしています。なお、記事中のアーキテクチャ図は参考記事から引用を行なっています。

SaaS consumers operating on AWS - AWS Prescriptive Guidance

Learn about network connectivity options for SaaS providers and consumers operating in AWS, including AWS PrivateLink, V...

結論
AWSネットワークにおけるSaaSへの接続方式
1. AWS PrivateLink
まとめ

結論

SaaS提供者と利用者の双方がAWS環境を利用している場合、接続方式は主に以下4パターンがあります。

AWS PrivateLink
Amazon VPC Lattice
VPCピアリング
AWS Transit Gateway

本記事ではこのうち AWS PrivateLink を扱います。

個人的な考えですが、PrivateLinkを使った構成はサービス提供側・利用側ともに構築運用面とセキュリティの観点でメリットが多く、まず最初に検討すべき選択肢だと考えています。

AWSネットワークにおけるSaaSへの接続方式

AWS PrivateLink

概要

AWS PrivateLink経由でサービスを提供する方式です。PrivateLink配下にSaaSアプリケーションを構築します。

（引用：SaaS consumers operating on AWS）

PrivateLinkとは、自分のVPC内のクライアントから、別のVPCにあるサービスやリソースへプライベートIPアドレスで接続できるようにする仕組みです。AWSの単体のサービス名ではなく、AWSサービスを組み合わせた仕組みであることにご注意ください。

AWS PrivateLinkは、基本的にはNLBとVPCエンドポイントサービス、インターフェイス型VPCエンドポイントで構成されています。

NLBが不要になるケース

2024年12月のアップデートにより、リソース設定とリソースゲートウェイを使う方式が追加されました。この方式では、NLBなしでデータベースやドメイン名などのリソースへ直接アクセスできます。

AWS が AWS PrivateLink 経由での VPC リソースへのアクセスを発表 - AWS

AWS の新機能についてさらに詳しく知るには、 AWS が AWS PrivateLink 経由での VPC リソースへのアクセスを発表

これまで、ALBが必要な構成では、利用側のVPCエンドポイント → NLB → ALB → EC2 という2段のロードバランサー構成を取る必要がありました。このアップデート以降は、リソース設定のドメイン名ターゲットに内部ALBのDNS名を指定することで、利用側のリソースVPCエンドポイント → リソースゲートウェイ → ALB → EC2 という構成が取れます。

また、負荷分散が不要な場合については、利用側のVPCエンドポイント → リソースゲートウェイ → EC2といった単純な構成を取ることも可能になりました。

構成要素

サービス提供側とサービス利用側で必要な作業は以下の通りです。

NLBありの場合

サービス提供側
1. NLBをVPC内に作成し、サービスのフロントエンドとする
2. そのNLBを指定して、VPCエンドポイントサービスを作成する
3. 接続を許可するAWSアカウントを許可リストに登録する
4. サービス名を利用側に伝える
5. 利用側からの接続リクエストを承認する
サービス利用側
1. 自分のVPCにVPCエンドポイントを作成し、「サービス提供側」のエンドポイントサービスを指定する
2. サービス提供側が接続リクエストを承認すると、サービスが利用可能になる

NLBなしの場合（リソースエンドポイント方式）

サービス提供側
1. リソースが存在するVPCにリソースゲートウェイを作成する
2. 公開したいリソース（IPアドレス、ドメイン名など）をリソース設定として定義し、リソースゲートウェイに関連付ける
3. AWS RAM のリソース共有を作成し、利用側のAWSアカウントに共有する
サービス利用側
1. AWS RAM のリソース共有への招待を承諾する
2. 自分のVPCにリソースVPCエンドポイントを作成する

メリットとデメリット

PrivateLink方式の主なメリット・デメリットは以下の通りです。

メリット

CIDRの重複を許容できる
- サービス提供側は、利用側のアドレス設計を意識する必要がありません。VPCピアリングやTransit Gateway のように、VPC AのIPアドレスからVPC BのIPアドレスへルーティングするわけではないためです。
- 利用側のアプリケーションが通信する宛先は、自分のVPC内にあるエンドポイントのネットワークインターフェイスのプライベートIPアドレスです。このENIは利用側アカウントから見えますがAWSが管理し、VPCエンドポイントとエンドポイントサービスの間の接続を通じて提供側のへトラフィックが渡されます。VPC間でIPアドレスをルーティングする構成ではないため、双方のCIDRが重複していても成立します。
スケールしやすい
- 顧客が1社増えたときの提供者側の作業が、接続リクエストの承認だけで済みます。VPCピアリング接続やTransit Gatewayとは異なり、ルートテーブルを管理する必要がありません。
- VPCピアリングのような接続数のクォーターに当たりません。VPCピアリングの場合、1VPCあたり最大125という上限があり、VPCピアリングの制約が顧客数の制約につながってしまいます。

デメリット

同じアベイラビリティゾーンでSaaSサービスを提供・利用する必要がある
- （作り込みを行わなければ、）利用可能なAZは、提供側がNLBで有効化したAZに限られます。
- ap-northeast-1aのようなゾーン名はアカウントごとに異なる物理ゾーンにマップされる可能性があります。そのため、提供側と利用側は別アカウントである以上、ゾーン名ではなくアベイラビリティゾーンID（apne1-az1など）で確認する必要があります。
通信はサービス利用側の起点のみ
- 提供者側から利用者側のネットワークへ入る経路が存在しないため、通信は利用者側起点になります。提供者側から利用者側へ通信を行う場合は、別の仕組みを導入する必要があります。
- （ただし一方で、利用側はSaaSベンダーに自社ネットワークへの侵入経路を渡さずに済むため、メリットとも言えます。）

まとめ

このように、サービス提供者が持つのはPrivateLinkとその背後にあるSaaSアプリケーションだけで、顧客が10社でも1,000社でもこの数は変わりません。また、サービス提供者側の作業や考慮事項は上記の通り比較的少なく、運用負荷も大きくありません。このようなメリットの大きさから、AWS PrivateLinkは最もクラウドネイティブなSaaS統合方法と位置づけられます。

他の接続方式として、Amazon VPC Lattice、VPCピアリング、AWS Transit Gatewayがありますが、今回はここまでとします。