🌐 VPC Networking

CIDRブロックの重複と
VPC接続完全ガイド

VPC間をつなぐとき、住所（IPアドレス）がかぶると通信できない ── その仕組みと解決策を図解します

まず結論：覚えておくべき3つのポイント
⚠️ 制約 1
VPCピアリングはCIDR重複があると使えない
⚠️ 制約 2
Transit GatewayもCIDR重複があると使えない
✅ 解決策
AWS PrivateLinkならCIDR重複でも接続可能

📮 たとえ話で理解する

「住所が同じ家が2軒あったら、郵便は届かない」
🏘️ 郵便配達のたとえ話
VPCは「住宅街」、CIDRブロックは「その住宅街の番地の範囲」です。

A町（VPC-A）の番地が「100番〜200番」、B町（VPC-B）の番地が「150番〜180番」だとします。
B町の番地はA町の範囲にすっぽり含まれており、番地が重複しています。

この状態でA町とB町を「直通道路」（VPCピアリング）でつなぐと、「160番地のXさん宛て」の郵便がA町のXさんなのかB町のXさんなのか、郵便屋さん（ルーター）が判別できません。

一方、AWS PrivateLinkは「特定のお店への専用出前サービス」のようなもの。番地ではなく「B町のピザ屋さん」と指定するので、住所が重複していても確実に届きます。
📐 番地の重複が引き起こす問題（図解）
VPC-A（A町）
🏠 番地 100〜200
192.168.128.0/17
🏠 🏠 🏠 🏠 🏠 🏠
160番地宛の
郵便はどっち？
😵
ルーターが
迷子に！
VPC-B（B町）
🏡 番地 150〜180
192.168.224.0/19
🏡 🏡 🏡

🔗 CIDR重複NGの接続方法

この2つの方法は、VPC間のIP範囲が被っていると使えません
🤝
VPC ピアリング
2つのVPC間で直接的なプライベート接続を確立する、最もシンプルな方法です。
VPC-A
⟵ 直通 ⟶
VPC-B
❌ CIDR重複時は使用不可
▸ 低レイテンシーで高スループットの直接接続
▸ 追加のゲートウェイやVPNは不要
▸ 推移的なルーティングは非対応（A↔B↔CでもA↔Cは不可）
🌐
Transit Gateway
中央のハブを経由して、多数のVPCとオンプレミスネットワークをまとめて接続できます。
VPC-A
→
TGW
→
VPC-B
❌ CIDR重複時は使用不可
▸ ハブ&スポーク型で多数のVPCを一元管理
▸ オンプレミスVPN/Direct Connectとも統合可能
▸ ルートテーブルによる細かいルーティング制御

📊 CIDR重複の判定方法

具体的な数値で「重複」を見える化します
IPアドレス範囲の可視化
192.168.0.0 〜 192.168.255.255 のアドレス空間における各CIDRの範囲を図示
192.168.0.0 .64.0 .128.0 .192.0 .255.255
192.168.128.0/17
→ 192.168.128.0 ～ 192.168.255.255（32,768個）
A町の範囲
192.168.224.0/19
→ 192.168.224.0 ～ 192.168.255.255（8,192個）
B町の範囲
⚠️ B町（/19）はA町（/17）の中にすっぽり収まっている → 完全に重複！
192.168.128.0/17 192.168.224.0/19 完全に包含 = CIDR重複
🔍 バイナリ（2進数）で確認する
192.168.128.0/17
11000000.10101000.10000000.00000000
32,768 アドレス
192.168.224.0/19
11000000.10101000.11100000.00000000
8,192 アドレス
赤字 = ネットワーク部（固定）/ 灰色 = ホスト部（変動可能）
/19のネットワーク部「11000000.10101000.111」は、/17のネットワーク部「11000000.10101000.1」で始まっているため、/19は/17の範囲に含まれます。

🧭 判断フロー

CIDRが重複しているか否かで、使える接続方法が変わります
VPC間を接続するときの判断チャート
判定
CIDRブロックは
重複している？
Yes
重複あり
ピアリング ✕
TGW ✕
→
解決策
AWS PrivateLink
を使用 ✓
No
重複なし
ピアリング / TGW
いずれも利用可能
CIDRブロックが重複していても、サービスをプライベートに共有できる仕組み
AWS PrivateLink = 「特定のサービスへの専用通路」
VPC全体を接続するのではなく、必要なサービスだけをピンポイントで公開します。
住所（CIDR）ではなく「お店の名前（サービスのエンドポイント）」で通信先を指定するため、IPアドレスの重複は問題になりません。 すべてのトラフィックはAWSプライベートネットワーク内を通り、パブリックインターネットを経由しません。
🔄
CIDR重複OK
IPアドレス範囲の重複に関係なく機能する。これが最大の強み。
🔒
最小権限の公開
VPC全体ではなく、特定のサービスのみをピンポイントで公開。
🌐
AWSネットワーク内で完結
トラフィックはパブリックインターネットを通らず安全。
⚡
変更が最小限
既存のVPC設計をほぼ変更せずに導入可能。
🏗️ PrivateLink アーキテクチャ図
🖥️ 消費者 VPC（本番環境）
192.168.128.0/17
アプリケーション
サービスを利用する側
↕
VPCエンドポイント
Interface型（ENI）
🔗 AWS PrivateLink
（プライベート通信）
☁️ AWSバックボーン
ネットワーク内で完結
📦 プロバイダー VPC
192.168.224.0/19
VPCエンドポイントサービス
サービスを公開する側
↕
NLB / GWLB
Network Load Balancer
↕
バックエンドサービス
EC2 / ECS / Lambda
なぜ NLB / GWLB が必要なのか？
PrivateLinkは「消費者VPCからプロバイダーVPCのサービスへの専用通路」を作る仕組みですが、
その通路の出口には必ず「受付窓口」＝ロードバランサーが必要です。
🏠
注文者
消費者VPC
ピザを注文したい人
（サービスを利用する側）
📞
受付カウンター
NLB / GWLB
注文を受け付けて
厨房に振り分ける窓口
🍕
厨房（複数台）
バックエンドサービス
EC2やECSで動く
実際のアプリケーション
消費者VPC                              プロバイダーVPC
┌──────────┐    PrivateLink    ┌──────────────────────────┐
│          │ ─────────────→  │ NLB（受付窓口）           │
│  アプリ  │   専用通路       │   ├→ EC2-A（厨房1）      │
│          │                  │   ├→ EC2-B（厨房2）      │
└──────────┘                  │   └→ EC2-C（厨房3）      │
                                 └──────────────────────────┘

厨房（バックエンド）が複数台あるため、
「どのサーバーに届けるか」を振り分ける受付窓口（NLB）が必須
⚡
NLB大半のケース
TCP/UDPレベルでトラフィックを振り分ける、高速・高スループットなロードバランサー。PrivateLinkでは最も一般的に使用されます。
ユースケース：一般的なAPI公開、マイクロサービス間通信、データベースプロキシなど
🛡️
GWLB特殊なケース
セキュリティアプライアンス（ファイアウォール、IDS/IPSなど）を透過的に経由させるための特殊なロードバランサー。
ユースケース：サードパーティ製セキュリティ機器の集中配置、トラフィック検査の一元化
💡
ALBは直接使えないが、間接的には利用可能
ALB（Application Load Balancer）はPrivateLinkに直接紐づけられません。ただし「NLBのターゲットとしてALBを指定する」構成が可能です。既にALBでサービスを運用している場合は、前段にNLBを追加する形で対応できます。

🔧 実装ステップ

3ステップでPrivateLinkを構築
1
VPCエンドポイントサービスを作成（プロバイダー側）
プロバイダーVPCで、既存のNLBまたはGWLBに関連付けたエンドポイントサービスを作成します。
# エンドポイントサービスを作成
aws ec2 create-vpc-endpoint-service-configuration \
  --network-load-balancer-arns arn:aws:elasticloadbalancing:ap-northeast-1:123456789:loadbalancer/net/my-nlb/abc123 \
  --acceptance-required

# 出力例: ServiceId = vpce-svc-0123456789abcdef0
2
インターフェイスVPCエンドポイントを作成（消費者側）
消費者VPC（本番環境）で、Step 1のサービスに接続するエンドポイントを作成します。
# インターフェイスエンドポイントを作成
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-consumer-123 \
  --service-name com.amazonaws.vpce.ap-northeast-1.vpce-svc-0123456789abcdef0 \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-aaa111 subnet-bbb222 \
  --security-group-ids sg-consumer-456
3
セキュリティグループを設定
エンドポイントとバックエンドサービスの双方で、必要なポートのみを許可するセキュリティグループを設定します。
# 消費者側: エンドポイントのSGでアウトバウンドを許可
aws ec2 authorize-security-group-egress \
  --group-id sg-consumer-456 \
  --protocol tcp --port 443 \
  --cidr 0.0.0.0/0

# プロバイダー側: NLBターゲットのSGでインバウンドを許可
aws ec2 authorize-security-group-ingress \
  --group-id sg-provider-789 \
  --protocol tcp --port 443 \
  --cidr 0.0.0.0/0

📋 接続方法の比較

3つの方式を一覧で比較します
項目 VPC ピアリング Transit Gateway PrivateLink
CIDR重複 ✕ 不可 ✕ 不可 ✓ 問題なし
接続範囲 VPC全体（双方向） VPC全体（双方向） 特定サービスのみ（一方向）
トポロジ 1対1 ハブ＆スポーク（多対多） プロバイダー → コンシューマー
構成の複雑さ 低い 中程度 中程度（NLB必要）
代表的なユースケース 少数VPC間の全面通信 大規模マルチVPC環境 CIDR重複時のサービス共有
たとえ話 🛤️ 2つの町を結ぶ直通道路 🏙️ 中央駅を経由する鉄道網 🍕 特定のお店への専用出前

❓ よくある質問

初心者がつまずきやすいポイントをQ&A形式で解説
Q
CIDRブロックが「重複」しているかどうか、簡単に判定する方法は？
▼
2つのCIDRのうち、プレフィックス長が短い方（/17など）のIP範囲を確認し、もう一方（/19など）の開始・終了アドレスがその範囲に含まれているかを確認します。含まれていれば重複です。オンラインの「CIDR Overlap Checker」ツールを使えばワンクリックで判定できます。
Q
PrivateLinkはNLB（Network Load Balancer）なしで使えますか？
▼
いいえ。VPCエンドポイントサービスを作成するには、NLBまたはGWLB（Gateway Load Balancer）が必要です。ALB（Application Load Balancer）は直接使えませんが、NLBのターゲットとしてALBを指定することは可能です。
Q
VPCピアリングとPrivateLink、コスト的にはどちらが安いですか？
▼
VPCピアリングはピアリング自体に料金はかかりませんが、データ転送量に応じた課金があります。PrivateLinkはエンドポイント1つあたりの時間課金＋データ処理料金がかかります。少量の通信であればピアリングが安く、サービス公開のセキュリティ要件が厳しい場合はPrivateLinkのコストが正当化されます。
Q
既にCIDRが重複している状態を解消する方法はありますか？
▼
根本的には、一方のVPCでCIDR範囲を変更する方法があります（VPCにセカンダリCIDRを追加してリソースを移行）。ただし既存リソースの再配置が必要なため大規模な作業になります。短期的にはPrivateLinkで必要なサービスだけ接続するのが現実的な解決策です。
AWS SAP 学習リソース — CIDRブロックの重複とVPC接続
VPC CIDR PrivateLink Networking

Created by SSuzuki1063

AWS SAP Learning Resources