VPCピアリングで同一CIDRが使えない理由
VPCピアリングで同一CIDRが使えない理由と回避策
こんにちは
今回は、VPCピアリングを実装する際の「同一CIDRブロック」の問題について詳しく解説します。
私自身、IaC(Infrastructure as Code)でVPCピアリングを実装していた際に、デプロイの瞬間までこの問題に気づかず、貴重な時間を失ってしまいました。コンソールからだとすぐにわかるこの制約が、なぜ存在するのか、そしてどうやって回避できるのかをまとめていきます。
目次
問題の概要
VPCピアリングを設定する際、以下のようなエラーに遭遇したことはありませんか?
Error: VPC peering connection cannot be created.
The VPCs have overlapping CIDR blocks.
このエラーは、ピアリングしようとする2つのVPCが同じCIDRブロックを使用している場合に発生します。
具体例
# VPC A: 10.0.0.0/16
# VPC B: 10.0.0.0/16 ← 同じCIDRブロック
重要なポイント: 通常のVPC作成では、異なるアカウントやリージョンであれば同じCIDRブロックを使っても問題ありません。しかし、VPCピアリングを設定する場合のみ、この制約が発生します。
なぜ同一CIDRが使えないのか
1. ルーティングの競合
VPCピアリングは、2つのVPC間でプライベートIPアドレスを使って直接通信を可能にする機能です。しかし、同じCIDRブロックを持つVPC同士をピアリングすると、以下の問題が発生します:
- ルーティングテーブルの競合: どちらのVPCにパケットを送信すべきか判断できない
- IPアドレスの重複: 同じIPアドレスが2つのVPCに存在するため、宛先が曖昧になる
2. AWSの制約
AWSは、VPCピアリングにおいて以下の制約を設けています:
- 重複するCIDRブロック: 完全に同じCIDRブロックは使用不可
- 重複するサブネット: 部分的に重複するサブネットも使用不可
技術的な背景
ルーティングの仕組み
VPCピアリングの仕組みを、宅配便の配達に例えて説明してみましょう。
VPC A (10.0.0.0/16) ←→ VPC B (10.1.0.0/16)
この場合、VPC AからVPC Bへの通信は:
- VPC Aのルーティングテーブル(配達ルート)で「10.1.0.0/16」宛の荷物をピアリング接続(専用道路)に向ける
- VPC Bのルーティングテーブルで「10.0.0.0/16」宛の荷物をピアリング接続に向ける
問題が起きるのは、同じ住所(CIDR)を持つ2つの家がある場合です:
VPC A (10.0.0.0/16) ←→ VPC B (10.0.0.0/16)
宅配便の配達員が「10.0.0.0/16」という住所に荷物を届けようとしても、どちらの家に届ければいいのか分からない状態になってしまいます。
VPCピアリングのメリット
VPCピアリングを使うことで、以下のようなメリットが得られます:
1. プライベート通信の実現
- パブリックインターネットを経由せずに、VPC間で直接通信
- セキュリティが向上し、通信コストも削減
2. シンプルな構成
- VPNやTransit Gatewayと比べて設定が簡単
- 管理コストが低い
3. 低レイテンシー
- 直接接続により高速な通信が可能
- ゲートウェイを経由しないため、レイテンシーが低い
4. 柔軟なネットワーク設計
- 複数のVPCを相互接続可能
- アカウント間、リージョン間の接続も可能
回避策
1. CIDRブロックの設計変更
推奨アプローチ
簡単に言うと、2つの家に違う住所を付けるということです:
# 修正前(同じ住所)
VPC A: 10.0.0.0/16
VPC B: 10.0.0.0/16
# 修正後(違う住所)
VPC A: 10.0.0.0/16
VPC B: 10.1.0.0/16
これで宅配便の配達員も迷わずに正しい家に荷物を届けられます。
2. サブネットの再設計
既存のVPCを変更できない場合は、同じマンション内でも部屋番号を分けるような発想で、サブネットレベルで重複を避ける方法もあります:
# VPC A(1階〜2階)
- 10.0.0.0/16
- Subnet A1: 10.0.1.0/24 # 1階
- Subnet A2: 10.0.2.0/24 # 2階
# VPC B(3階〜4階)
- 10.0.0.0/16
- Subnet B1: 10.0.3.0/24 # 3階
- Subnet B2: 10.0.4.0/24 # 4階
3. Transit Gatewayの使用
大規模な環境では、中央の交通ハブのような役割を果たすTransit Gatewayを使うことで、より柔軟なネットワーク設計が可能です。これなら同じ住所でも問題ありません。
4. その他の代替案
VPN接続
- インターネット経由での接続
- セキュリティは高いが、レイテンシーが高くなる
PrivateLink
- 特定のサービス間での接続に特化
- VPCピアリングよりも制限的だが、セキュリティが高い
実装例
基本的なTerraform実装例
宅配便の配達ルートを設定するような感覚で、以下のように実装します:
# VPC A(住所:10.0.0.0/16)
resource "aws_vpc" "vpc_a" {
cidr_block = "10.0.0.0/16"
tags = { Name = "VPC-A" }
}
# VPC B(住所:10.1.0.0/16)
resource "aws_vpc" "vpc_b" {
cidr_block = "10.1.0.0/16" # 違う住所
tags = { Name = "VPC-B" }
}
# 専用道路(ピアリング接続)
resource "aws_vpc_peering_connection" "main" {
vpc_id = aws_vpc.vpc_a.id
peer_vpc_id = aws_vpc.vpc_b.id
auto_accept = true
tags = { Name = "VPC-A-to-VPC-B" }
}
まとめ
VPCピアリングにおける同一CIDRブロックの問題は、宅配便の配達員が迷子になるような状況です。同じ住所を持つ2つの家があると、どちらに荷物を届ければいいのか分からなくなってしまいます。
重要なポイント
- 事前設計の重要性: VPCピアリングを予定している場合は、設計段階で「住所の重複」を避ける
- IaCでの早期発見: コンソールでの確認を習慣化する(宅配便の配達ルートを事前に確認するようなもの)
- 代替案の検討: Transit Gatewayなど、より柔軟なソリューションの検討
- VPCピアリングのメリット理解: 制約はあるものの、シンプルで効率的な接続方法
今後の改善点
- 設計レビュー: VPCピアリングを予定している場合の「住所チェック」を必須化
- 自動化: CI/CDパイプラインで住所重複チェックを実装
- ドキュメント化: ネットワーク設計ガイドラインの整備
- メリット・デメリットの理解: VPCピアリングの制約とメリットを適切に評価
この記事が、VPCピアリング実装時のトラブルシューティングに役立てば幸いです。**同じ住所の家を建てないように気をつけましょう!**何かご質問があれば、お気軽にお聞かせください!
Discussion