複数VPCの接続方式

1. まず「VPC間を接続する」とは何か

別々のVPCを作成すると、

VPC-A
10.10.0.0/16

VPC-B
10.20.0.0/16

VPCは論理的に分離されたネットワークなので、そのままではVPC-AとVPC-BのプライベートIPアドレス間で自由に通信できるわけではありません。そこでVPC間の通信経路を用意します。

VPCピアリング

AWS Transit Gateway

2. VPCピアリング

VPCピアリングは、2つのVPCを1対1で接続する仕組みです。

VPC-A
10.10.0.0/16
    │
    │ VPCピアリング
    │
VPC-B
10.20.0.0/16

接続後、双方のVPCのルートテーブルへ相手側CIDRをVPCピアリング接続へ向けるルートを設定することで、プライベートIPアドレスを使用した通信が可能になります。

VPC-A
宛先     ターゲット
10.10.0.0/16    local
10.20.0.0/16    pcx-xxxx

VPC-B
宛先     ターゲット
10.20.0.0/16    local
10.10.0.0/16    pcx-xxxx

3. ピアリング接続しただけでは通信は完成しない

VPCピアリングを作成しただけで、A ↔ Bの通信が自動的にすべて有効になるわけではありません。

• VPCピアリング接続
• 双方向の適切なルート
• セキュリティ制御

が必要になります。通信を成立させるには、ルートに加えてセキュリティグループやネットワークACLなどのセキュリティ制御も整合している必要があります。

4. 別AWSアカウントでもVPCピアリングできる

VPCピアリングは異なるAWSアカウント間でも利用できます。

アカウント A
   VPC-A
      │
      │ ピアリング
      │
アカウント B
   VPC-B

接続を要求する側をリクエスタ、要求を受ける側をアクセプタとして、アクセプタ側がリクエストを承認します。SAP-C02ではマルチアカウント環境が多いため、別AWSアカウントだからVPCピアリング不可とは考えません。

5. 別リージョンでもVPCピアリングできる

VPCピアリングは同一リージョン内だけでなく、異なるAWSリージョン間でも使用できます。

東京リージョン
VPC-A
   │
   │ リージョン間VPCピアリング
   │
大阪リージョン
VPC-B

ただしリージョン間通信ではリージョン間データ転送料金などを考慮します。

6. VPCピアリング最大の特徴：1対1

VPCピアリングはポイントツーポイント接続です。3個のVPCすべてを直接通信させるなら、

A ↔ B
A ↔ C
B ↔ C

と3本の接続が必要になります。

7. VPCピアリングは推移的ではない

次の構成を考えます。

VPC-B
   │
   │ ピアリング
   │
VPC-A
   │
   │ ピアリング
   │
VPC-C

A-B間、A-C間にピアリングがあっても、B → A → Cとは通信できません。VPCピアリングは推移的ルーティングをサポートしません。 BとCを通信させたいなら、B-C間の直接的なピアリング接続も必要です。

8. 「中央VPCへ全部ピアリングすればハブになる」は誤り

       VPC-B
         │
         │ ピアリング
         │
VPC-C ─ VPC-A ─ VPC-D
         ピアリング

見た目はVPC-Aがハブ、B/C/Dがスポークに見えます。しかしVPCピアリングは推移的ではないので、B → A → Cというルーティングはできません。見た目がハブ＆スポークでも、VPCピアリングだけではスポーク間の中継ルーターにはなりません。

9. フルメッシュ

複数VPCすべてをVPCピアリングで相互接続する構成を考えます。

A────B
|\  /|
| \/ |
| /\ |
|/  \|
C────D

各VPCを直接接続する形をフルメッシュとして考えます。VPC数を n とすると必要な接続数は、

n(n - 1)
────────
   2

です。

10. フルメッシュの接続数

例えば10 VPCなら、

10 × 9
──────
  2

= 45

となります。

11. 問題は「接続できるか」だけではない

VPC数が増えると、VPCを1個追加するたびに既存の各VPCとの接続を追加する必要があります。9 VPCがフルメッシュのときに10個目を追加すると、

新しいピアリング接続 × 9

が必要です。さらに各接続について、ピアリング作成、承認、ルート追加、セキュリティ設定、トラブルシューティングなどを考える必要があります。つまりフルメッシュの問題は、通信できないことではなく、規模が大きくなるほど構成・運用が複雑になることです。

12. 少数VPCならVPCピアリングが悪いわけではない

だからといって、VPCピアリング = 古い / 悪い、Transit Gateway = 常に正解、ではありません。

VPC-A
     ↕
VPC-B

だけを通信させ、VPC数は増えない、推移的ルーティング不要、中央ネットワーク管理不要なら、Transit Gatewayという中央ルーターを追加するよりVPCピアリングの方が単純です。

13. AWS Transit Gateway

AWS Transit Gatewayは、複数のVPCやオンプレミスネットワークを接続するマネージドの中央ルーターとして利用できます。

           VPC-A
             │
             │
VPC-B ─── Transit Gateway ─── VPC-C
             │
             │
           VPC-D

各VPCをTransit Gatewayへ接続します。これをハブ＆スポークとして考えます。

ハブ
→ Transit Gateway

スポーク
→ 各VPC

14. ハブ＆スポーク

フルメッシュでは各VPC間に直接接続が必要ですが、Transit Gatewayでは中央へ集約します。

A ─┐
B ─┼─ Transit Gateway
C ─┤
D ─┘

新しいVPC-Eを追加するときも、VPC-EからTransit Gatewayへの中央接続を追加する形で拡張できます。

15. Transit Gatewayでは推移的ルーティングが可能

Transit Gatewayが中央ルーターになるため、

VPC-A
   │
   ▼
Transit Gateway
   │
   ▼
VPC-B

のような通信経路を構成できます。VPC-AとVPC-Bの間に直接VPCピアリングを作成する必要はありません。これはVPCピアリングではできなかった推移的ルーティングを可能にする重要な違いです。

16. ただし「接続したVPCは全部通信可能」とは限らない

Transit Gatewayには独自のルートテーブルがあります。

VPC-A
  │
  │ アタッチメント
  ▼
Transit Gateway
  │
Transit Gatewayルートテーブル
  │
  ▼
VPC-B

Transit Gatewayへ接続されたネットワーク間の通信は、Transit Gatewayのルーティング設定で制御できます。したがって、Transit Gatewayへアタッチしただけで全VPCが無条件に相互通信、ではありません。どのVPCからどこへ通信できるようにするかはTransit Gatewayのルーティングポリシーで制御します。

17. Transit Gatewayのアタッチメント

Transit Gatewayへネットワークを接続するときにはアタッチメントを使用します。

VPC-A ─ VPC アタッチメント ─┐
                        │
VPC-B ─ VPC アタッチメント ─┼─ Transit Gateway
                        │
VPN ─── VPN アタッチメント ─┘

現行AWSではVPC、VPN、Direct Connectゲートウェイ、Transit Gatewayピアリング、Transit Gateway Connectなど複数の接続方式をTransit Gatewayへ統合できます。アタッチメント種別によって必要な設定やサブネット選択が異なります。

18. オンプレミス接続も中央へ集約しやすい

VPCピアリングには推移性がないため、VPC-BがVPC-AのVPNを経由してオンプレミスへ通信する、という使い方はできません。一方Transit Gatewayなら、

          VPC-A
            │
          VPC-B
            │
オンプレミス ── TGW ── VPC-C
            │
          VPC-D

のように、VPC接続とハイブリッド接続を中央へ集約できます。ハイブリッド接続を中央化する場合は、VPN / Direct Connectの要件も別途比較します。

19. 高可用性のためにTransit Gatewayを2台作る必要はない

Transit GatewayはAWSが管理するマネージドサービスであり、高可用性を備えるよう設計されています。そのため、1リージョン内でTransit Gateway障害に備えるためだけに、全く同じTGWを2台用意することを基本形とはしません。複数TGWを使う設計自体は存在しますが、管理境界、設定ミスの影響範囲、大規模ネットワークの分離など別の設計理由で検討します。

20. VPCピアリングとTransit Gatewayの構造比較

21. 性能だけでTransit Gatewayを選ばない

Transit Gatewayは管理性に優れますが、通信経路にTransit Gatewayという追加ホップが入ります。一方VPCピアリングは2つのVPCを直接接続します。

2 VPCしかない
+
直接通信だけ
+
中央管理不要

なのに「SAP-C02だからTransit Gateway」と選ぶのは誤りです。必要のない複雑性を追加することになります。

22. コストも構造によって変わる

VPCピアリングとTransit Gatewayでは料金構造が異なります。Transit Gatewayでは通常、アタッチメントやデータ処理などに料金が発生します。一方VPCピアリングではTransit Gatewayという中央サービス自体を配置しません。ただし通信するAZやリージョンによってデータ転送料金を考える必要があります。

したがって、TGW = 常に安い、ピアリング = 常に安い、でもありません。少数の単純なVPC接続では、Transit Gatewayの中央管理能力が不要ならVPCピアリングがコスト・構成の両面で適する場合があります。

23. CIDR重複はTransit Gatewayでも魔法のようには解決しない

CIDR重複はVPC間接続の大きな制約です。VPCピアリングでは重複CIDRを持つVPC間にピアリング接続を作成できません。ではTransit Gatewayを使えばよいかというと、そうではありません。Transit Gatewayでも重複CIDRを持つVPCを通常のルーティングで自由に相互通信させられるわけではありません。

CIDR設計を失敗してもTGWで直せる、とは考えません。 必要ならCIDR再設計やアドレス変換を含む別アーキテクチャを検討します。

24. VPCピアリングとTransit Gatewayの選択条件

ここまでの知識を、VPC数だけではなく通信関係・将来増加・推移性・中央管理・ハイブリッド接続・運用負荷でまとめます。

例えば5 VPCでも中央管理・オンプレミス接続共有・将来の急増があるならTransit Gatewayが有力です。逆にVPC数が多少多くても、通信相手が固定され中央ルーティングが不要なら、必要な接続だけをVPCピアリングで構成する余地があります。

25. フルメッシュとハブ＆スポーク

フルメッシュ
A────B
|\  /|
| \/ |
| /\ |
|/  \|
C────D

ハブ＆スポーク
A ─┐
B ─┤
C ─┼─ Transit Gateway
D ─┤
E ─┘

フルメッシュでは接続数が n(n-1)/2 で増えるため、規模が大きくなるほど接続作成・ルート管理・障害切り分けの負荷が増えます。

26. SAP-C02での判断フロー

複数VPCを接続したい
        │
        ▼
CIDRは重複していないか？
        │
        ▼
通信相手は少数・固定の1対1か？
        │
   ┌────┴────┐
  はい        いいえ
   │          │
   ▼          ▼
VPCピアリング   推移的通信 / 中央管理が必要？
              │
         ┌────┴────┐
        いいえ         はい
         │          │
         ▼          ▼
個別接続も検討   Transit Gateway
                    │
                    ▼
          将来VPCが増える？
          ハイブリッド接続も集約する？
                    │
                    ▼
          TGWがさらに有力

最初にサービス名を選ぶのではなく、必要な通信関係と将来の運用モデルを決めてから接続方式を選びます。

27. 混同ポイント

• VPC ピアリングは非推移：A-BとA-Cがあっても、B→A→Cの中継はできません。
• 見た目がハブでもピアリングはハブルーターにならない：中央VPCが別ピアリング間を自動中継するわけではありません。
• Transit Gatewayへアタッチメントしただけでは全通信が許可されない：TGW側のルーティングポリシーで通信範囲を制御します。
• Transit Gatewayが常に正解ではない：少数・固定接続ならVPC ピアリングの方が単純な場合があります。
• 重複CIDRはTGWで自動解決しない：アドレス設計や変換方式を別途検討します。
• VPC ピアリングはクロスアカウント / リージョン間でも利用可能です。

28. まとめ

VPCピアリング
→ 1対1の直接接続
→ 非推移
→ 少数・固定された通信に向く

フルメッシュ
→ 各VPCを直接相互接続
→ n(n-1)/2
→ 規模拡大で運用負荷が増える

AWS Transit Gateway
→ 中央ルーター
→ ハブ＆スポーク
→ 推移的ルーティング
→ 多数VPC / 中央管理 / ハイブリッド接続の集約に向く

接続方式の選択
→ VPC数だけでは決めない
→ 通信関係
→ 将来増加
→ 推移性
→ 中央管理
→ ハイブリッド接続
→ コスト / 運用負荷

最重要ポイント：「今つながるか」ではなく、VPCが増えた後も意図した通信関係を管理できるアーキテクチャかまで判断します。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional（SAP-C02）試験ガイド
• Amazon VPC — VPCピアリング接続の仕組み
• Amazon VPC — VPCピアリングのルーティング
• AWS — マルチVPCネットワーク / VPCピアリング
• AWS — Transit Gateway
• AWS Transit Gateway — ルートテーブル
• AWS — マルチVPC接続パターン