はじめに
概要
本記事は、AWSのVPCピアリングについてやさしく解説します。VPCピアリングは、異なるVPC同士がプライベートIPで直接通信できる仕組みです。セキュリティを保ちながら高速な通信経路を確保できるため、クラウド上でのシステム分割や環境間連携によく使われます。
誰に向けた記事か
クラウドやネットワークの基礎知識を持ち、実務でAWSを使うエンジニアや運用担当者を主な対象としています。初心者の方でも理解できるように、専門用語は最小限にして具体例で補足します。
本記事で学べること
- VPCピアリングの基本概念と特徴
- 接続の仕組みとイメージ
- 実際の設定手順と注意点
- 他の接続手段との違いと代表的なユースケース
最後に、運用上のベストプラクティスも紹介します。
読み方のヒント
各章は独立して読めます。まずは第2章で全体像を把握すると、以降の設定や注意点が理解しやすくなります。
VPCピアリングとは何か
概要
VPCピアリングは、AWS内の二つのVPC（仮想ネットワーク）を直接つなぎ、プライベートIPで通信できる仕組みです。インターネットを経由せずにAWS内部だけで通信が完結するため、セキュリティと通信性能の面でメリットがあります。
どんな場面で使うか（具体例）
- 開発用VPCから本番用VPCのデータベースに安全に接続したい
- 別チームのVPCにあるログ収集サーバへアクセスしたい
- マイクロサービスを別VPCで分けて運用しつつ、内部通信だけは高速にしたい
大事な特徴（短く）
- プライベートIP同士で直接通信します。外部に公開しません。
- 点対点の接続です。AとB、BとCをつないでもAとCは自動ではつながりません（非トランジティブ）。
- セキュリティグループやルートテーブルの設定が必要です。接続しただけでは通信できません。
簡単なイメージ
想像すると、別々の部屋（VPC）にドアを作り、扉を通って直接行き来するようなものです。扉は鍵（ルール）で管理します。
VPCピアリングの主な特徴
1. 直接接続（ダイレクト）
VPC同士を中間のVPNやインターネット経由でなく、直接結びます。たとえば、開発用VPCと本番用VPCを中継なしでつなぎ、内部IPで通信できます。
2. プライベート通信
通信はAWSの内部ネットワークを通り、プライベートIPでやり取りします。外部に公開せず安全にデータを移動できます。
3. 低レイテンシ・高帯域幅
AWSのバックボーン上で通信するため遅延が小さく、転送速度も出やすいです。データベース同期や大量ログ転送などに向きます。
4. 柔軟な接続範囲
同一リージョン内だけでなく、異なるリージョンや別のAWSアカウント間でも接続できます。組織内でVPCを分けていても連携しやすいです。
5. セキュリティとアクセス制御
各VPCのセキュリティグループやネットワークACLはそのまま効きます。細かい通信許可や拒否を設定して、安全に通信範囲を限定できます。
6. 運用上の利便性
設定は比較的シンプルで、接続の承認やルート設定を行えば利用開始できます。管理負荷を抑えつつ安全な接続を作れます。
VPCピアリングの仕組みと接続イメージ
簡単な流れ
- リクエスト送信：片方のVPC（リクエスタ）からピアリング接続を作成します。
- 承認：相手側のVPC（アクセプタ）がリクエストを承認します。
- ルート追加：両VPCのルートテーブルに、相手のCIDR宛てルートをピア接続経由で追加します。
- 接続完了：インスタンス同士がプライベートIPで直接通信できます。
具体的な接続イメージ
例：VPC-A（10.0.0.0/16）とVPC-B（10.1.0.0/16）をピアリングする場合
– VPC-Aのルートテーブル：10.1.0.0/16 -> ピア接続
– VPC-Bのルートテーブル：10.0.0.0/16 -> ピア接続
図（テキスト）:
[VPC-A 10.0.0.0/16] <—ピア接続—> [VPC-B 10.1.0.0/16]
各VPC内のインスタンスは相手のプライベートIPで通信できます。
アクセス制御と動作のポイント
- セキュリティグループとネットワークACLは個別に設定します。ピア接続はルーティングを提供するだけです。
- トラフィックはクラウド内の専用経路を直接通ります。インターネットやVPNを経由しません。
- トランジティブ（中継）ルーティングはサポートされません。A-B、B-Cの組合せでA-Cが直接つながることはありません。したがって必要な接続は個別に作成します。
補足（DNSやアカウントをまたぐ接続）
- プライベートDNS名での名前解決を使う場合は、VPCのDNS設定やサービス側の設定が必要です。
- 同一アカウント内、または別アカウント間でもピアリングできます。承認や権限に注意してください。
設定手順とポイント
前提条件
- リクエスタ側とアクセプタ側のVPC IDとCIDRを確認します。CIDRが重複すると接続できません。
手順（基本）
- VPCピアリング接続を作成します。AWSコンソールやCLIで、リクエスタVPCとアクセプタVPCを指定します。異なるアカウントやリージョンも指定可能です。
- アクセプタ側でリクエストを承諾します。承諾操作を忘れると接続が確立しません。
- 各VPCのルートテーブルを編集します。相手VPCのCIDRへのルートをピアリング接続ID経由で追加します（例: 宛先10.1.0.0/16 → ターゲット pcx-0abc123）。両側で設定が必要です。
- セキュリティグループとネットワークACLを調整します。必要なポートと相手のCIDRを許可します。
設定のポイント
- DNS解決を利用する場合は、ピアリングでのDNS転送設定を確認します。\
- クロスアカウントではIAMや承諾時の権限に注意します。
動作確認
- 各VPCのインスタンスから相手のプライベートIPへpingやTCP接続を試します。
- うまくいかない場合は、ルートテーブル、セキュリティグループ、CIDR重複の順に確認します。
注意点（短く）
- CIDR重複とルート未設定が最も多いトラブル原因です。必ず両側を確認してください。
VPCピアリング利用時の注意点・制約
VPCピアリングを使う際は、設計と運用の注意点を押さえておくと安全で安定した接続ができます。以下に主な制約と対策をやさしく説明します。
トランジティブルーティング不可
A↔B と A↔C のピアリングがあっても、B↔C は直接通信できません。中継ルーターのようには使えないため、必要なVPC同士はそれぞれ個別にピアリングを作成してください。例：BとCが通信するならB↔Cのピアリングを別途作成します。
ルーティングテーブルのセキュリティ
ルートに「0.0.0.0/0」を入れると全トラフィックが流れてしまいます。必要最小限のCIDRだけを許可し、意図しない経路を防ぎます。特にパブリック向けや非公開ネットワークへの出口には注意してください。
ピアリング数の上限
アカウントごとに作成できるピアリング数に上限があります。多数のVPCを接続する場合は、設計段階で上限や将来の拡張を確認しておくと安心です。
DNS解決の扱い
デフォルトでは相手VPCの内部DNSは有効になりません。相互に名前解決を使いたい場合は、ピアリングのDNS設定を明示的に有効にしてください。設定漏れで接続はできてもサービス名でアクセスできないことがあります。
運用ではログや監視を整え、変更時にルートやDNS設定を必ず見直す習慣をつけるとよいです。
他のVPC接続手段との比較
概要
VPCピアリング、トランジットゲートウェイ、VPN/Direct Connectの違いを分かりやすく説明します。用途や規模に合わせて選べるよう、主要ポイントで比較します。
主な比較ポイント
- 接続モデル：
- VPCピアリングは1対1の直接接続。設定がシンプルです。例：開発用VPCと本番VPCの限定通信。
- トランジットゲートウェイは中央ハブで複数VPCを接続。大規模構成に向きます。
- VPN/Direct Connectはオンプレミスとクラウドをつなぎます。高帯域や専用線が必要な場合に適します。
- スケーラビリティと管理：
- 小規模はピアリングで十分。VPCが増えると管理が煩雑になります。
- 複数VPCや複雑なルーティングはトランジットゲートウェイが管理しやすいです。
- コストと運用：
- ピアリングは基本的に安価で単純。
- ゲートウェイは機能に応じてコスト増。運用工数は抑えられます。
- VPN/Direct Connectは回線費用が発生しますが、安定した接続を得られます。
用途別の目安
- 小規模・限定的な接続：VPCピアリングを推奨。設定が早く済みます。
- 企業全体や多数VPCを接続する場合：トランジットゲートウェイを検討してください。
- オンプレミスとクラウドをつなぐ：VPNやDirect Connectが適切です。
選ぶ際のチェックリスト
- 接続先の数と将来的な拡張性
- 運用負荷と予算
- 必要な帯域と遅延要件
- ルーティングの複雑さとセキュリティ要件
これらを基に、目的と規模に合った方式を選ぶとよいです。
VPCピアリングの代表的なユースケース
以下は実際によく見られる代表的な利用シーンです。具体例を交え、何を解決できるかをわかりやすく説明します。
開発環境と本番環境での限定共有
本番VPCは分離しつつ、開発やステージングから一部リソース（データベースのテストコピーや認証サービス）にだけ安全にアクセスしたい場合に使います。例：開発VPCからステージングDBへ接続して動作確認を行う、といった用途です。
異なるAWSアカウント間でのプライベート連携
組織内でアカウントを分けている場合や、パートナーのアカウントと安全に通信したいときに有効です。例：複数のアカウントから中央のログ収集VPCや認証VPCへプライベートに送信するケースです。
複数リージョン間での低レイテンシ・セキュア通信
リージョンをまたいで動作するアプリで、公開インターネットを経由せずに通信したいときに使います。例：リージョン間でのデータ同期、リードレプリカやフェイルオーバー用のレプリケーション通信です。
マイクロサービス分割と内部APIの利用
機能ごとにVPCを分けている場合、内部APIや決済サービスなどをプライベート経路で呼び出す用途に適します。サービス間の通信をインターネット公開しません。
データ処理・分析基盤との連携
ETL処理や解析クラスタを別VPCに置いている場合、プライベートにアクセスして効率よく大容量データをやり取りできます。例：処理VPCからデータレイクVPCへ直接データを送る、といった運用です。
中央管理・監視（ログ収集・セキュリティ）
ログ収集や監視ツールを集中させたVPCに、各アプリVPCからプライベートで送る構成に向きます。運用負荷を下げつつ通信を安全に保てます。
まとめとベストプラクティス
VPCピアリングは、AWS内でシンプルに安全なVPC間接続を実現できます。小規模な環境や直接通信が必要なケースに向きます。ここでは設計・運用で押さえるべきポイントと具体的な対策をまとめます。
- 基本設計の確認
- CIDRが重複しないか必ず確認してください。重複があると接続できません。
-
例：アプリVPC(10.0.0.0/16)とDB VPC(10.1.0.0/16)のように分けます。
-
ルーティングとセキュリティ
- ルートテーブルにピア接続先への経路を追加してください。
- セキュリティグループとネットワークACLで通信ポートを明確に許可します。
-
構築後は実際の通信（疎通確認）を必ず行ってください。
-
運用と監視
- 定期的に設定を見直し、不要なアクセスを閉じます。
-
接続数が増える場合はトランジットゲートウェイなどの導入を検討してください。より複雑な環境で管理が楽になります。
-
トラブル対策と手順
- 変更時は影響範囲を洗い出し、ステージングで確認してから反映します。
- ログやフローログを有効にして通信障害の原因を追いやすくしておきます。
最後に、VPCピアリングは構成がシンプルな場面で効果を発揮します。運用ではルーティングやセキュリティ設定のミスが主な原因になるため、構築後の確認と定期的な見直しを習慣にしてください。
