AWS上で複数のアカウントやVPCを運用するようになると、「共通で利用する便利なアプリケーション（住所確認、決済処理、共通データベース等）を1つのVPCにまとめて、他の子会社や外部アカウントから安全に利用させたい」 という要件が頻繁に出てきます。
しかし、セキュリティや運用の観点から以下のような課題に直面します。
- 「ネットワーク全体を繋ぎたくない（特定のアプリケーションだけを利用させたい）」
- 「接続元のVPCとIPアドレス（CIDR）が重複している」
- 「接続先のVPCごとに複雑なルートテーブルやルーティングの管理をするのが面倒」
この記事では、これらの課題をスマートに解決し、AWS SAA試験でも超頻出である 「AWS PrivateLink と Network Load Balancer (NLB)」 の構成について、初心者向けに図解を交えて徹底解説します！
💻 よくある設計課題（シナリオ）
あなたはある大手物流会社で、複数の事業部門が共通して利用する「住所確認アプリケーション」を提供しようとしています。
このアプリケーションは共有サービス用のVPC（Shared Services VPC）内で稼働していますが、セキュリティ担当者から以下の要件を課されました。
- アプリケーションへのアクセスは特定のAWSアカウントのみに限定し、その他の不要なアクセスは一切遮断する。
- インターネットを経由しない、セキュリティの高いプライベートなネットワーク環境で接続する。
- 接続元のVPCがどのようなIPアドレス帯（CIDR）を使っていても繋がるようにし、ルートテーブルの変更などのメンテナンス工数を最小限に抑える。
これらを満たす最適なネットワーク構成はどのような設計になるでしょうか？
🔑 目指すべき解決策：AWS PrivateLink ＋ NLB
この課題に対するベストプラクティスは、接続元のVPCと共有VPCの間を AWS PrivateLink（VPC エンドポイントサービス） で繋ぎ、裏側に NLB (Network Load Balancer) を配置する構成です。
構成の概要図
graph LR
subgraph ClientVPC ["クライアントの VPC (接続元)"]
ClientApp["接続元インスタンス"]
Endpoint["VPC エンドポイント<br/>(プライベートIP)"]
end
subgraph ProviderVPC ["Shared Services VPC (提供元)"]
NLB["Network Load Balancer (NLB)"]
SharedApp["住所確認アプリ"]
end
ClientApp -->|VPC内部のプライベートIP宛て| Endpoint
Endpoint == AWS PrivateLink (専用通信路) ==> NLB
NLB -->|トラフィックを分散| SharedApp
なぜ PrivateLink が最適なのか？
1. 特定のアカウントのプリンシパル（IAM）だけに公開を制限できる
PrivateLinkは、エンドポイントサービス側で「接続を許可するAWSアカウントID（または特定のIAMエンティティ）」をホワイトリスト登録できます。許可されていないアカウントからの接続はすべて自動で拒否されるため、極めて安全です。
2. ネットワーク全体を接続せず、サービス単位で露出する
VPCピアリングのように「ネットワーク全体を繋ぐ道路」を作るのではなく、共有サービスへアクセスするための「プライベートな窓口（VPCエンドポイント）」を接続元VPCに1つだけ出現させる技術です。これにより、接続元から提供元VPC内にある他の不要なリソースへのアクセスを完全に遮断できます。
3. IPアドレス（CIDR）の重複（衝突）があっても接続できる
VPCピアリングや後述するTransit Gatewayでは、接続し合うVPC同士のIPアドレス範囲（例: 10.0.0.0/16）が重複しているとルーティングが競合するため接続できません。
💡 なぜIPアドレスが重複しているとダメなのか？（郵便の例え） 同じ町内に「山田さん」の家が2つあり、番地も完全に同じ（例: 1丁目1番地）だった場合、郵便配達員はどちらの「山田さん」に手紙を届ければいいか分からなくなります。 ネットワークでも同様に、接続元が
10.0.0.0/16で、接続先も10.0.0.0/16だった場合、お互いに全く同じIPアドレス（例:10.0.1.5）が存在し得ます。この状態で通信を送ろうとしても、宛先が「自分のローカル内」なのか「接続先VPC」なのか判別できず、ルーターの設定（ルートテーブル）も競合エラーで登録できません。
しかし、PrivateLinkは接続元VPCの中に「自VPC内のプライベートIP（例: 10.0.5.50）」を持った専用のエンドポイント（窓口）を作成します。
接続元のインスタンスは、相手のIPアドレスを一切意識することなく、自VPC内の窓口宛てに通信を送るだけで良く、あとはAWSのシステムが自動で裏でアドレス変換（NAT）を行うため、IPアドレスの重複があっても全く問題なく繋がります。
4. ルーティングの管理（ルートテーブル）が不要
接続元は、自VPC内に出現したエンドポイントのプライベートIP（またはプライベートDNS名）宛てに通信を送るだけです。VPCを跨ぐための複雑なルートテーブルの設定変更（ルーティング設定）が不要なため、管理工数を劇的に抑えられます。
🧐 なぜ他の選択肢（ピアリング等）は不適切なのか？
a. VPC ピアリング
- 不適切である理由： VPCピアリングはネットワーク全体を相互接続するため、細かい制御が難しく、接続先から不要なリソースまで通信が通ってしまうリスクがあります。また、接続するVPC数が増えるにつれてルートテーブルの管理がメッシュ状に肥大化し、メンテナンス工数が増え続けます。さらに、IPアドレス（CIDR）の重複がある場合は接続できません。
c. ALB をインターネット経由で公開する
- 不適切である理由： インターネット経由でアクセスさせる構成は、「セキュリティの高いネットワーク環境（プライベート接続）」という要件に反します。
d. Transit Gateway
- 不適切である理由： Transit Gateway は大規模なハブアンドスポーク構成を組むための強力なサービスですが、これもVPC間の相互通信をルーティング制御するため、特定のアプリケーションだけにアクセスを制限する管理が複雑になります。また、IPアドレス重複に対応しづらく、設定の複雑さや初期費用・転送量コストも大きいため、「メンテナンス工数を抑える」という観点からはPrivateLinkに劣ります。
🎯 AWS SAA 合格に向けたおすすめの教材
AWS SAA（ソリューションアーキテクト – アソシエイト）の勉強をさらに進めたい方向けの、おすすめの優良教材です。
1. 【書籍】AWS教科書 AWS認定ソリューションアーキテクトアソシエイト テキスト＆問題集 第2版
試験範囲の網羅率が非常に高く、各サービスの仕組みが詳細な図解付きで体系的に学べる一冊です。今回解説したVPCエンドポイントやPrivateLinkの仕組みについても丁寧に書かれています。
2. 【Udemy】【SAA-C03版】これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座
ベストセラーとなっている動画教材です。ハンズオン（実際にAWS画面を操作するパート）が豊富で、実際にVPCやエンドポイントを作ってプライベート接続を検証できるため、本で学ぶよりも圧倒的にPrivateLinkの仕組みが腹落ちします。