AWS VPC間でのプライベート接続の方式
はじめに
ITコンサルタントとして働いているのですが、最近は社内のクロスアカウントでのサービス間通信方式を設計してプロジェクトを進めるという経験が増えてきました。
実際の構築はSIerにお任せするとはいえ、設計の意思決定には自分が絡む以上「なんとなく理解している」だけでは心もとない場面も出てきます。
今後も似たようなシチュエーションに遭遇しそうなので、学習した内容をアウトプットするという意味も込めて記事にします。同じように「なんとなく分かるけど選び方が分からない」という方の参考になれば嬉しいです。
1. 主要な接続方式
まず3つの方式を並べると、こんな感じになります。
| 方式 | 通信方向 | 推移的ルーティング | スケーラビリティ | 相対コスト |
|---|---|---|---|---|
| VPC Peering | 双方向 | ❌ 不可 | △ (接続数が増えると複雑) | 低 |
| AWS PrivateLink | 単方向（消費者 → 提供者） | ✅ 不要（エンドポイント経由） | ✅ 高い | 中 |
| Transit Gateway + RAM | 双方向 | ✅ 可能 | ✅ 高い | 高 |
それぞれ見ていきましょう。
2. VPC Peering によるプライベート接続
概要
2つのVPC間にプライベートな経路を張る、一番シンプルな方法です。クロスアカウント・クロスリージョンにも対応しています。
「まずこれを理解すればVPC間接続の入門完了」という感じで、概念自体はわかりやすいです。ただ後述する制約に後から気づいて「あ、これじゃ要件を満たせない…」となるケースが結構あるので、先に制限を把握しておくのが大事だと思います。
┌─────────────────────────┐ ┌─────────────────────────┐
│ Account A │ │ Account B │
│ │ │ │
│ ┌───────────────────┐ │ │ ┌───────────────────┐ │
│ │ VPC-A │ │ │ │ VPC-B │ │
│ │ 10.0.0.0/16 │◄─┼─────────┼─►│ 10.1.0.0/16 │ │
│ │ │ │Peering │ │ │ │
│ └───────────────────┘ │Connection│ └───────────────────┘ │
└─────────────────────────┘ └─────────────────────────┘
設定手順
Step 1：ピアリング接続のリクエスト（Account A側）
Step 2：ピアリング接続の承認（Account B側）
Step 3：ルートテーブルの設定（両アカウントで実施）
Step 4：セキュリティグループの設定
メリット・デメリット
✅ メリット
- 設定がシンプルで理解しやすい
- データ転送コストが低い（同一リージョンは無料）
- レイテンシが低い
❌ デメリット
- CIDRの重複は不可。事前に全VPCのIPアドレス計画が必要
- 推移的ルーティング不可。A↔B、B↔Cのピアリングがあっても、A↔Cは通信できない
- VPCが増えると接続数が爆発的に増加（フルメッシュ問題）
向いているケース
- VPCの数が少なく（3〜5個程度）、1対1の接続で要件が満たせる場合
- CIDRが重複していない環境が確保できる場合
- コストを最小限に抑えたい場合
3. AWS PrivateLink によるプライベート接続
概要
サービスをNLBの背後に配置して、消費者側がInterface VPC Endpointを作成して接続する方式です。
私が関わるプロジェクトでは複数の組織をまたがるクロスアカウントでのサービス提供や外部SaaSサービスへの接続といったパターンが多く、PrivateLinkが必要な場面が多いです。
ただ最初に概念を聞いたときは「エンドポイントサービス」と「VPCエンドポイント」がごっちゃになってしばらく混乱していました。「提供者側がEndpoint Serviceを作り、消費者側がInterface Endpointを作って接続しにいく」という構造だと整理してからようやくスッキリしました。
┌──────────────────────────────────┐ ┌──────────────────────────────────┐
│ Account A（サービス提供者） │ │ Account B（サービス消費者） │
│ │ │ │
│ ┌──────────┐ ┌─────────────┐ │ │ ┌─────────────────────────────┐ │
│ │ App/API │◄──│ NLB │ │ │ │ Interface VPC Endpoint │ │
│ └──────────┘ └───────┬─────┘ │ │ │ (ENI in VPC-B subnet) │ │
│ │ │ │ └──────────────┬──────────────┘ │
│ ┌─────────────────┐ │ │ │ │
│ │ Endpoint Service│◄─┼───────┼─────────────────┘ │
│ └─────────────────┘ │ │ │
└──────────────────────────────────┘ └──────────────────────────────────┘
設定手順
Step 1：NLBの作成（Account A側）
Step 2：Endpoint Serviceの作成（Account A側）
Step 3：Account Bへのアクセス許可（Account A側）
Step 4：Interface Endpointの作成（Account B側）
Step 5：接続リクエストの承認（Account A側）
DNS設定のポイント
Interface EndpointにはデフォルトでリージョナルなDNS名が割り当てられます。プライベートDNSを有効にすると、元のサービスのFQDNで名前解決できるようになります（Route 53 Private Hosted Zoneの活用を検討）。
このDNS設定まわりは「本当に解決されるのか？」と実際に動かすまで不安になりやすい部分です。後述のハマりポイントにも書きましたが、VPC側のDNS設定もセットで確認が必要なのでご注意を。
メリット・デメリット
✅ メリット
- CIDRの重複を気にしなくてよい
- 消費者からはENIのプライベートIPにしかアクセスできないため、セキュリティが高い
- 承認フローでアクセス制御が可能
- AWSマネージドサービス（S3, DynamoDBなど）への接続にも同じモデルを使える
❌ デメリット
- NLBのコストが発生する
- 通信は単方向（サービス提供者 → 消費者への通信は別途必要）
- セットアップが他の方式より手順が多い
向いているケース
- 共有APIや共有データベースを複数アカウントに提供したい場合
- SaaSプロバイダーとして顧客のVPCへサービスを提供する場合
- CIDRの管理が難しいレガシー環境
4. Transit Gateway + RAM によるクロスアカウント接続
概要
Transit Gateway（TGW）は複数のVPCを束ねるハブとして機能します。Resource Access Manager（RAM）でTGWを複数アカウントに共有することで、クロスアカウントのハブ＆スポーク構成も実現できます。
「VPCが増えてきたな」「オンプレとの接続も一緒に管理したい」となったときに頼もしい方式です。ただしアタッチメントごとにコストがかかるため、VPCが少ない構成でいきなりこれを使うと過剰になりがちです。最初からスケールアウトが見えている場合や、オンプレとの接続が絡む場合に選ぶのが自然かなと思っています。
┌─────────────────────────────┐
│ Account A（ネットワーク） │
│ │
│ ┌───────────────────────┐ │
│ │ Transit Gateway │ │
│ └───┬───────────┬───┬───┘ │
│ │ │ │ │
└──────┼───────────┼───┼───────┘
┌────────────────┘ │ └──────────────────┐
│ │ │
┌─────────▼──────────┐ ┌─────────────▼──────┐ ┌──────────▼─────────┐
│ Account B │ │ Account C │ │ Account D │
│ VPC-B │ │ VPC-C │ │ VPC-D │
│ 10.1.0.0/16 │ │ 10.2.0.0/16 │ │ 10.3.0.0/16 │
└─────────────────────┘ └────────────────────┘ └────────────────────┘
設定手順
Step 1：Transit Gatewayの作成（Account A側）
Step 2：RAMでTGWを共有（Account A側）
Step 3：RAM招待の承認（Account B/C/D側）
Step 4：TGWへのVPCアタッチメント（各アカウント側）
Step 5：VPCのルートテーブルにTGWを追加（各アカウント側）
メリット・デメリット
✅ メリット
- 推移的ルーティングが可能（A→TGW→B→TGW→C など）
- 接続数が増えてもルーティング管理がTGWに集約されてシンプル
- オンプレミス（Direct Connect / VPN）との統合も容易
❌ デメリット
- アタッチメントごとにコストがかかる（スモールスタートには不向き）
- TGWを所有するアカウントに依存関係が生まれる
- VPC Peeringと比べてレイテンシが若干高い
向いているケース
- VPCが多数あり、フルメッシュ接続が現実的でない場合
- オンプレミスとの接続も含めてネットワークを一元管理したい場合
- 将来的なスケールアップを見据えた設計
5. 方式選定のフローチャート
どれを選べばいいか最初は迷うと思いますが、整理すると判断軸はそれほど多くないです。
接続するVPCの数は？
│
├─ 少ない（〜5個）──────────────────────────────────────────────────────────────►
│ │
│ CIDRは重複していない？ │
│ ├─ YES ──► 推移的ルーティングは必要？ │
│ │ ├─ NO ──► ✅ VPC Peering（シンプル・低コスト） │
│ │ └─ YES ──► ✅ Transit Gateway │
│ └─ NO ──► ✅ AWS PrivateLink（サービス提供型の要件か？） │
│
└─ 多い（6個以上）──► ✅ Transit Gateway + RAM（スケーラブル）
（サービス提供モデルなら PrivateLink も併用）
6. よくあるハマりポイントと対処法
ハマりポイントをまとめます。
❶ VPC PeeringでCIDRが重複していた
原因：複数のVPCに同じCIDRレンジを割り当ててしまっている。
マルチアカウント化が後から進んだ組織では結構あるあるです。VPCを作る人がバラバラだとCIDRが被りやすい。「ピアリング作ろうとしたらエラーになった」という経験がある方も多いのではないでしょうか。
対処法：
- ピアリング前にすべてのVPCのCIDRを棚卸しする
- 潔く他の接続方式を採用する
❷ PrivateLinkでDNS解決されない
原因：Interface EndpointのプライベートDNSが有効になっていない、またはVPCのDNS設定（enableDnsHostnames / enableDnsSupport）が無効になっている。
エンドポイントは作れたのに疎通確認できない…というとき、まずここを疑ってみてください。VPC側のDNS設定はデフォルトで有効なことも多いですが、古い環境だと無効になっていることがあります。
対処法：
DNSを有効にしましょう
# VPCのDNS設定を確認・有効化
aws ec2 modify-vpc-attribute \
--vpc-id vpc-xxxxxxxx \
--enable-dns-hostnames
aws ec2 modify-vpc-attribute \
--vpc-id vpc-xxxxxxxx \
--enable-dns-support
❸ Transit Gatewayのルートが伝播されない
原因：TGWルートテーブルへのアタッチメントの「関連付け（Association）」と「伝播（Propagation）」の設定漏れ。
TGWはアタッチメントを作るだけでは終わりじゃなくて、ルートテーブルへの関連付けと伝播を別途設定する必要があります。「アタッチしたのになぜか通信できない」という場合はまずここを確認しましょう。
対処法：
- コンソールまたはCLIでルートテーブルの関連付け・伝播を明示的に設定する
- アタッチメントが
available状態になるまで待ってから確認する
❹ セキュリティグループで通信がブロックされる
原因：ルートテーブルは設定できていても、セキュリティグループのインバウンドルールに相手のCIDRが許可されていない。
ルーティングとセキュリティグループは別物です。「ルートは通っているはずなのに…」というときは、セキュリティグループも合わせて見てみてください。意外と見落としがちです。
対処法：
- セキュリティグループのソースにVPCのCIDRブロックを指定する
- PrivateLinkの場合はEndpointのセキュリティグループも確認する
まとめ
3つの方式を改めて整理するとこうなります。
| 方式 | 推奨シーン |
|---|---|
| VPC Peering | 少数VPC・シンプルな1対1接続・コスト優先 |
| AWS PrivateLink | サービス提供モデル・CIDR管理が困難・セキュリティ重視 |
| Transit Gateway + RAM | 多数VPC・推移的ルーティング必要・オンプレ統合 |
ドキュメントやAIと壁打ちして整理をしながら改めて感じたのは、SAPやANSなどの資格取得をして表面的にわかったつもりになっていても、実務レベルで複雑な構成を考えるシーンに出会うと、まだ理解が浅いと感じたことです。とはいえ、最低限の知識があったおかげで理解も早いので資格を先に取得しておくことは有効だと思います。
特に今回のプライベート接続要件は、企業内での大規模サービス構築時には必須の考え方になります。
NW周りに少し苦手意識があったので、このあたりは実務も通して解像度をより高めていけるように頑張りたいと思います！