AWS VPCピアリング完全ガイド：仕組みから適用シーンまで

目次

1. はじめに
2. 仕組みと特徴
3. 制約事項
4. 設定手順
5. VPCピアリングの方向性制御
6. コスト面
7. 適用シーンと代替アプローチ
   1. VPCピアリングの制限
   2. VPCピアリングを適用するシーン
      1. CIDRブロックの重複を避けて設計可能な単一プロジェクト
      2. 小規模な異なる組織間で、事前にCIDRの重複を調整してVPCピアリングで接続可能な場合
   3. VPCピアリング適用していないシーン
8. まとめ
9. 参考資料

1. はじめに

AWSでの複数VPC間の接続は、多くの組織にとって重要な課題です。本記事では、VPCピアリングに焦点を当て、その仕組みや特徴、適用シーンについて詳しく解説します。

VPCピアリングは、2014年3月リリースされ、AWSが提供する複数のVPC接続ソリューションの中で最も基本的かつ直接的な方法です。2つのVPC間に直接的なネットワーク接続を確立することで、安全で効率的な通信を実現します。

なお、AWSには他にもAWS PrivateLinkやTransit Gatewayといった複数VPC間の接続技術が存在します。これらの技術についての詳細な比較や適用シーン、コスト面での検討については、別途まとめの記事で解説する予定です。

本記事を通じて、VPCピアリングの基本概念から実装方法、ベストプラクティスまでを学び、AWSネットワーク設計の理解を深めることができます。

2. 仕組みと特徴

VPCピアリングは、2つのVPC間に直接的なネットワーク接続を確立する技術です。主な特徴は以下の通りです：

1. 直接接続：

   • 2つのVPC間で直接的なルーティングを実現
   • 中間のゲートウェイやVPNが不要

2. プライベート通信：

   • VPC間の通信にプライベートIPアドレスを使用
   • AWS内部ネットワークで完結し、インターネットを経由しない

3. 高性能：

   • 直接接続による低レイテンシー
   • AWS内部ネットワークを利用した高帯域幅

4. 柔軟な接続オプション：

   • リージョン内およびリージョン間のVPC接続をサポート
   • 異なるAWSアカウント間のVPC接続も可能

5. セキュリティ：

   • 既存のセキュリティグループをVPC内のインスタンスに適用
   • 既存のネットワークACLをVPCのサブネットに適用

これらの特徴により、VPCピアリングは安全で効率的なVPC間接続を実現します。

3. 制約事項

1. CIDRの制限：

   1. 単一CIDRの場合：CIDRが重複していない場合のみピアリングするVPC使用可能

      • 利用できる例：

        • VPC-A: 10.0.0.0/16
        • VPC-B: 172.16.0.0/16
          この場合、CIDRが重複していないため、VPC-AとVPC-Bはピアリング接続できます。
          

      • 完全重複の例：

        • VPC-C: 10.0.0.0/16
        • VPC-D: 10.0.0.0/16
          この場合、CIDRが完全に重複しているため、VPC-CとVPC-Dはピアリング接続できません。
          

      • 部分重複の例：

        • VPC-E: 10.0.0.0/16
        • VPC-F: 10.0.0.0/24
          この場合、VPC-FのCIDRがVPC-EのCIDRに含まれる（部分的に重複している）ため、VPC-EとVPC-Fはピアリング接続できません。
          

   2. 複数CIDRの場合：

      • VPCは複数のCIDRを持つことができますが、ピアリング接続時には以下の制限があります：
        • ピアリングするVPC間で、すべてのCIDRが重複していない場合のみ接続が可能です。
        • 一部のCIDRが重複している場合でも、ピアリング接続は確立できません。
      • 部分的な重複も許可されていません。例：
        • VPC-C: 10.0.0.0/16, 172.16.0.0/16
        • VPC-D: 10.0.0.0/24, 192.168.0.0/16
          この場合も、10.0.0.0/24が10.0.0.0/16と部分的に重複しているため、VPC-CとVPC-Dはピアリング接続できません。
          

   この制限は、ルーティングの競合を防ぎ、ネットワークの一意性を確保するために設けられています。
   重要：単一CIDRの場合も複数CIDRの場合も、すべてのCIDRが重複していない場合のみ、ピアリング接続が可能です。

2. 1対1の接続：

   • 各ピアリング接続は2つのVPC間のみを結びます。例えば：

     • VPC-A と VPC-B を接続する場合：1つのピアリング接続
     • VPC-A、VPC-B、VPC-C の3つを相互に接続する場合：
       • VPC-A ⇔ VPC-B
       • VPC-B ⇔ VPC-C
       • VPC-C ⇔ VPC-A
         の3つの個別ピアリング接続が必要です。
         

   • 複数VPCを接続する場合、個別のピアリング接続が必要です。例：

     • 5つのVPCを完全に相互接続する場合、10個のピアリング接続が必要になります。
       (n * (n-1) / 2 の公式で計算: 5 * 4 / 2 = 10

3. 直接接続のみ：

   • ピアリング接続は、直接つながっているVPC間でのみ通信が可能です。
   • 例：A-B間、B-C間にピアリングがあっても、A-C間の直接通信はできません。
     つまり、BをVPCを経由してAとCが通信することはできません。
     

4. 暗号化：VPC間のトラフィックは、AWSのプライベートネットワーク内で自動的に暗号化されます。追加の暗号化設定は不要です。

5. DNS解決：ピアリング接続では、オプションでVPC間のDNS解決を有効にすることができます。これにより、一方のVPCのプライベートIPアドレスを他方のVPCから名前解決できるようになります。

これらの特徴により、VPCピアリングは簡単かつ効率的なVPC間接続方法として、同一アカウント内だけでなく異なるアカウント間でも広く利用されています。

4. 設定手順

VPCピアリングの設定手順は以下の通りです。なお、エンドポイントの作成は不要です。VPCピアリングはAWSが自動的に管理するため、ユーザーが明示的にエンドポイントを作成する必要はありません。

1. ピアリング接続の作成：

   • VPCダッシュボードに移動し、「ピアリング接続」を選択
   • 「ピアリング接続の作成」ボタンをクリック
   • 要求元VPCと要求先VPCの情報を入力します。以下の４つのケース対応できる
     • 同一アカウント内の同一リージョンのVPC間
     • 同一アカウント内の異なるリージョンのVPC間
     • 異なるアカウントの同一リージョンのVPC間
     • 異なるアカウントの異なるリージョンのVPC間
   • 「ピアリング接続の作成」ボタンをクリックして要求を送信

   CIDR重複の場合は、そもそも「ピアリング接続」が作成できません。
   
   :

2. 承認プロセス：

   • VPCダッシュボードのピアリング接続セクションで、保留中の要求を確認
   • 該当する要求を選択し、「アクション」メニューから「承認」を選択
   • 確認ダイアログで「はい、承認」をクリック

3. ルートテーブルの更新：

   • 以下のようにそれぞれのVPCのルートテーブルにルートを追加

     • 送信先：相手のピアVPCのCIDR範囲
     • ターゲット：作成したピアリング接続のID

   • 変更後のルートテーブル：

     ルートテーブル	送信先	ターゲット
     VPC A	VPC A CIDR	ローカル
     	VPC B CIDR	pcx-11112222(作成したピアリング接続のID)
     VPC B	VPC B CIDR	ローカル
     	VPC A CIDR	pcx-11112222(作成したピアリング接続のID)

4. セキュリティグループの設定：
   セキュリティグループの設定は、VPCピアリングの接続先によって異なります：

   1. 同じリージョン内のVPCピアリングの場合：

      • 送信元/送信先にセキュリティグループを直接指定できます。
      • 例：VPC AのセキュリティグループでVPC Bのセキュリティグループを参照可能

   2. 異なるリージョン間のVPCピアリングの場合：

      • セキュリティグループを直接参照することはできません。代わりに、ピアVPCのCIDRブロックを使用して設定します。
      • 異なるリージョンの場合の設定例：VPC AのセキュリティグループでVPC BのCIDRを指定; VPC BのセキュリティグループでVPC AのCIDRを指定
        • VPC A（リージョン1）のセキュリティグループ(インバウンドルール)：

          タイプ	プロトコル	ポート範囲	送信元
          すべてのトラフィック	すべて	すべて	VPC BのCIDR

        • VPC B（リージョン2）のセキュリティグループ(インバウンドルール)：

          タイプ	プロトコル	ポート範囲	送信元
          すべてのトラフィック	すべて	すべて	VPC AのCIDR

      注意：セキュリティ要件に応じて、より具体的なプロトコルとポート範囲を指定することをお勧めします。

5. 接続のテスト：

   • 各VPC内のEC2インスタンスにSSH接続
   • pingコマンドやその他のネットワークツールを使用して、VPC間の接続を確認

5. VPCピアリングの方向性制御

VPCピアリング自体は双方向の接続を提供しますが、トラフィックの流れを細かく制御するには以下の方法があります：

1. ルートテーブルの設定：

   • 単方向の通信を実現するには、一方のVPCのルートテーブルにのみルートを追加します。
   • 例：VPC AからVPC Bへの通信のみを許可する場合
     • VPC Aのルートテーブル：VPC BのCIDRへのルートを追加
     • VPC Bのルートテーブル：VPC AのCIDRへのルートを追加しない

2. セキュリティグループの設定：

   • インバウンドルールとアウトバウンドルールを適切に設定
   • 例：VPC AのインスタンスからVPC Bのインスタンスへの接続のみを許可する場合
     • VPC Aのセキュリティグループ：アウトバウンドルールでVPC BのCIDRを許可
     • VPC Bのセキュリティグループ：インバウンドルールでVPC AのCIDRを許可

3. ネットワークACL（NACL）の利用：

   • より細かい制御が必要な場合、NACLを使用してサブネットレベルでトラフィックを制御
   • 例：特定のポートやプロトコルのみを許可/拒否する

4. IAMポリシーとリソースポリシー：

   • AWS APIやサービスへのアクセスを制御するために使用
   • 例：特定のIAMロールにのみ、ピアVPCのリソースへのアクセスを許可する

これらの方法を組み合わせることで、VPCピアリングの双方向性を維持しつつ、実質的に単方向や制限付きの通信を実現できます。

注意：完全な単方向通信の実装は、ネットワークプロトコルの性質上、困難な場合があります。多くの場合、最小限の双方向通信（例：TCP ACK）が必要となります。

6. コスト面

VPCピアリングのコスト構造は以下の通りです：

1. ピアリング接続の確立：
   VPCピアリング接続の確立自体に料金はかかりません。

2. データ転送料金：

   • 同一リージョン内のVPC間：
     • 同一アベイラビリティーゾーン（AZ）内：データ転送は無料
     • 異なるAZ間：小額の料金が発生（例：$0.01/GB）
   • 異なるリージョン間のVPC：
     • 送信側のリージョンの料金に基づいて課金されます。
     • 料金は転送されるデータ量に応じて変動（例：$0.02/GB、ほとんどのリージョンでは、同一リージョン内の異なるAZ間のデータ転送に対して0.01 USD/GBの料金が適用）

3. リージョン間ピアリングの追加コスト：
   リージョン間のデータ転送には、通常のデータ転送料金に加えて、リージョン間ピアリング固有の料金が適用

注意：具体的な料金は、AWSの価格表を参照し、使用状況に応じて見積もりを行うことをお勧めします。また、コストを最適化するために、データ転送量の監視と、必要に応じたVPCピアリング接続の見直しが重要です。

7. 適用シーンと代替アプローチ

7.1 VPCピアリングの制限

1. VPCピアリングの適用シーンは、CIDRブロックの重複がない環境に限定されます。
   異なる組織間でCIDR範囲を事前に調整することは、実務上非常に困難です。特に、デフォルトVPC設定（10.0.0.0/16）を使用する傾向があるため、重複の可能性が高くなります。各部門が独立してVPCを作成する場合、CIDRの重複は非常に起こりやすい問題となります。パートナー企業との接続では、CIDRの重複はさらに大きな課題となります。

2. 一部の状況では、AWSマネージドサービスを利用することで、VPCピアリングを回避できます。

これらの制限により、実際の複雑な環境でVPCピアリングを確実に適用できるシーンは限られています。

7.2 VPCピアリングを適用するシーン

7.2.1 CIDRブロックの重複を避けて設計可能な単一プロジェクト

1. 大規模なマイクロサービスアーキテクチャ：

   • 例：セキュリティ要件により、各マイクロサービスを独立したVPCに配置する必要がある単一プロジェクト。CIDRの重複を避けるよう事前に設計可能。このような場合、VPCピアリングによってサービス間の直接通信が実現できる。

2. 既存のネットワーク構成を変更せずに特定のサービスを共有：

   • 例：本番環境は通常他の環境から分離するのがベストプラクティスだが、一部のコンポーネントを共有せざるを得ないケースがある。具体的な例：

   1. ライセンス管理サーバー

      • 理由：ソフトウェアライセンスのコスト最適化のため、複数環境で同一のライセンスプールを共有する必要がある場合
      • 例：高額なデータベースライセンスや特殊なソフトウェアライセンスを、開発・検証・本番環境で共有利用

   2. 監視・ログ集約システム

      • 理由：全環境を統合的に監視し、問題の早期発見や相関分析を行うため
      • 例：Splunk、ELK Stack、Prometheusなどの監視ツールを中央集権的に配置し、全環境のログやメトリクスを収集

   3. セキュリティスキャンサービス

      • 理由：全環境の脆弱性を一元的に管理し、セキュリティ対策を統一的に実施するため
      • 例：Qualys、Nessusなどの脆弱性スキャンツールを共有利用
        これらのサービスは独立したVPCに配置し、VPCピアリングを使用して各環境に接続できる。

3. データ分析環境の分離：

   • 主要なアプリケーションVPCとは別に、データ分析用VPCを作成
   • VPCピアリングを使用して、必要なデータのみを安全に転送

7.2.2 小規模な異なる組織間で、事前にCIDRの重複を調整してVPCピアリングで接続可能な場合

1. 部門間または小規模な子会社間のリソース共有と接続：

   • 異なる部門や子会社が別々のAWSアカウントやVPCを持つ場合、特定のリソース（例：中央データベース）への直接アクセスが必要
   • 中央のIT部門がCIDR計画を管理し、VPCピアリングで接続

2. 特定のパートナー企業との限定的な接続：

   • 単一のパートナー企業とのみ接続が必要な場合、両社で協力してCIDRを調整
   • VPCピアリングを使用して、セキュアかつ直接的な接続を確立

7.3 VPCピアリング適用していないシーン

1. 一つのプロジェクトにおける開発環境、検証環境と本番環境のデータ共有：

   • 前提：
     • 環境ごとに別々のVPCに分離すべき、さらに可能であれば、別々のAWSアカウントに分離すべき
     • 環境間のデータ共有、つまり本番環境のデータをマスキングして開発環境や検証環境で使用することができる
   • データ共有方法：
     • RDS: 本番環境のスナップショットを開発環境や検証環境のAWSアカウントに共有すれば、開発環境や検証環境でもデータを使用できる。VPCピアリングは不要
     • S3: S3バケット間のレプリケーション機能を使用して、Account AのS3バケットの内容をAccount Bのバケットに自動的にコピーできる。VPCピアリングは不要で、S3の機能だけで実現可能
   • 結論：
     • この考え方は、環境分離とデータ共有の両立を図りつつ、不必要なVPCピアリングを避けることで、セキュリティとコスト効率を向上させることができます。

2. ディザスタリカバリ（DR）構成におけるクロスリージョンのデータ同期：

   • 前提：
     • DR構成では、メインシステムとは別のリージョンにDRサイトを構築するのが一般的です。
   • データ同期方法：VPCピアリングなしでクロスリージョンのデータ同期を実現できます。
     1. Amazon RDSのクロスリージョンリードレプリカ：
        • RDSは内部的にAWSのネットワークを使用してデータを同期
     2. AWS Database Migration Service (DMS)：
        • DMSはマネージドサービスとして、ソースとターゲットの間でデータを安全に転送
        • 異なるリージョン間でも、VPCピアリングなしで動作
     3. Amazon Auroraのグローバルデータベース：
        • Auroraグローバルデータベースは、専用の高速ネットワークを使用してリージョン間でデータを複製
     4. Amazon S3のクロスリージョンレプリケーション：
        • S3バケット間でデータを自動的に複製します
   • 結論：
     • DR構築において、VPCピアリングは必須ではありません
     • 多くのAWSマネージドサービス（RDS、S3など）は、VPCピアリングなしでクロスリージョンレプリケーションを実現できます。これにより、ネットワーク構成を簡素化し、管理オーバーヘッドを削減できます。さらに、AWSのマネージドサービスを活用することで、セキュリティと信頼性が向上し、運用負荷も軽減されます。

3. 複雑な部門や子会社間の接続は、VPCピアリングでは実現が難しい。そのため、より現実的なアプローチ：

   1. Transit Gateway

      • 複数のVPCを中央のハブに接続し、CIDRの重複があっても通信が可能
      • ルーティングテーブルで細かい制御が可能

   2. AWS PrivateLink

      • 特定のサービスやエンドポイントへのアクセスを提供
      • CIDRの重複に影響されない

   3. アプリケーションレベルの統合

      • API GatewayやALBを使用し、ネットワークレベルではなくアプリケーションレベルで統合

8. まとめ

1. VPCピアリングの特徴：

   • 2つのVPC間の直接的なネットワーク接続
   • プライベートIPアドレスを使用した安全な通信
   • 低レイテンシーと高帯域幅の実現
   • リージョン内外、異なるAWSアカウント間での接続が可能

2. 主な制約事項：

   • CIDRブロックの重複不可
   • 1対1の接続のみ
   • 直接接続のみ（中継不可）

3. 適用シーン：

   • 大規模なマイクロサービスアーキテクチャ
   • 特定サービスの共有（ライセンス管理、監視システムなど）
   • データ分析環境の分離
   • 小規模な組織間の限定的な接続

4. 代替アプローチ：

   • Transit Gateway：複雑な接続要件や多数のVPC接続に適する
   • AWS PrivateLink：CIDRの重複がある環境や特定サービスへのアクセスに適する

5. コスト面：

   • 接続確立自体は無料
   • データ転送量に応じた課金
     • 同一AZ内のデータ転送は無料
     • 異なるAZ間のデータ転送は料金が発生
     • リージョン間のデータ転送は、通常のAWS間データ転送料金が適用

VPCピアリングは、シンプルで直接的なVPC間接続を提供する強力なツールです。しかし、複雑なネットワーク要件や大規模な環境では、他のAWSネットワーキングソリューションとの組み合わせや代替手段の検討が必要です。適切な使用シーンを見極め、セキュリティとコスト効率を考慮しながら、最適なネットワークアーキテクチャを設計することが重要です。

9. 参考資料