問題点
VPC ピアリング接続をセットアップしたばかりだとします。AWS コンソールのステータスは緑色の Active（アクティブ）と表示され、準備は万端に見えます。しかし、ピアリング先の VPC 内にあるデータベースへの ping や、インスタンスへの SSH 接続を試みた瞬間、次のような壁にぶつかります：
Request timeout for icmp_seq — no route to host
通常、これは「橋」は存在しているものの、インスタンスがそれを見つけるための地図を持っていないことを意味します。ネットワークパケットはローカルゲートウェイまで到達しますが、リモートの CIDR 範囲に到達するための明示的な指示がないため、そこで止まってしまいます。
60秒でできる解決策
VPC ピアリングでは、手動でのルーティング設定が必要です。トラフィックが双方向に流れるように、両方の VPC のサブネットに関連付けられたルートテーブルを更新する必要があります：
- VPC ダッシュボードを開き、ルートテーブルを選択します。
- ソースインスタンスのルートテーブル（例:
10.0.0.0/16）を見つけます。 - ルートを追加します：送信先（Destination）にリモート VPC の CIDR（例:
172.31.0.0/16）を、ターゲット（Target）にpcx-xxxxxxID を設定します。 - 重要： 送信先 VPC のルートテーブルに切り替え、ソース CIDR を指し示す戻りのルートを追加します。
なぜこれが発生するのか
AWS は VPC をピアリングする際にネットワークインフラを構築しますが、セキュリティ上の理由からルーティングロジックには手を加えません。VPC ピアリングは、2つのオフィスビルの間に新しく作られたプライベートなトンネルのようなものだと考えてください。トンネルが開通していても、新しい出口に向かう案内標識を設置しない限り、従業員がそれを利用することはありません。
ルーティングの失敗は、通常、次の3つのギャップに起因します：
- リクエスタ（申請側）のギャップ： ソース VPC が、宛先 IP への有効なゲートウェイとしてピアリング接続を認識していない。
- アクセプタ（承認側）のギャップ： 宛先 VPC はパケットを受信するが、応答（ACK）を返す方法がわからない。
- 非対称ルーティング： トラフィックが一方向にしか流れず、プロトコルのハンドシェイク時に接続が失敗する。
ステップバイステップ・ガイド
1. ネットワーク詳細の確認
コンソールを操作する前に、次の3つの値を手元に用意してください：
- VPC A (リクエスタ):
10.0.0.0/16 - VPC B (アクセプタ):
172.31.0.0/16 - ピアリング ID:
pcx-0a1b2c3d4e5f6g7h8
2. ソースルートの設定 (VPC A)
- VPC コンソールで、ルートテーブルをクリックします。
- インスタンスのサブネットに関連付けられているテーブルを選択します。複数のサブネット（パブリック/プライベート）がある場合は、インスタンスが実際に使用しているものを更新してください。
- アクション > ルートの編集を選択します。
- ルートの追加をクリックします。送信先に
172.31.0.0/16を入力します。 - ターゲットで Peering Connection を選択し、該当する
pcx-...ID を選びます。 - 変更を保存します。
3. 戻りルートの設定 (VPC B)
このステップをスキップすることが、「no route to host」エラーの最も一般的な原因です。通信は双方向である必要があります。
- VPC B の宛先サブネットのルートテーブルを見つけます。
- ルートの編集をクリックし、新しいエントリを追加します。
- 送信先に
10.0.0.0/16（VPC A の範囲）を入力します。 - ターゲットとして同じピアリング接続 IDを選択します。
- 変更を保存します。
4. AWS CLI によるクイック修正
ターミナルを好む場合は、次のコマンドを実行して即座にギャップを解消できます：
# VPC A から VPC B へのルート
aws ec2 create-route \
--route-table-id rtb-11111111 \
--destination-cidr-block 172.31.0.0/16 \
--vpc-peering-connection-id pcx-0a1b2c3d4e5f6g7h8
# VPC B から VPC A へのルート
aws ec2 create-route \
--route-table-id rtb-22222222 \
--destination-cidr-block 10.0.0.0/16 \
--vpc-peering-connection-id pcx-0a1b2c3d4e5f6g7h8
接続のテスト
テーブルを更新したら、パスを確認します。まずは VPC A のインスタンスから簡単な ICMP チェックを行ってください：
# リモートインスタンスのプライベート IP に ping を送信
ping 172.31.20.5
# 特定のサービスポートに到達可能か確認
nc -zv 172.31.20.5 80
ping が依然として失敗する場合は、VPC Reachability Analyzer を使用してください。2つのインスタンス間のパスを作成すると、視覚的なマップが生成され、どのセキュリティグループルールや NACL がトラフィックをドロップしているかを正確に教えてくれます。
ネットワーク安定性のためのプロのヒント
- セキュリティグループの範囲： 宛先インスタンスがソース CIDR からのインバウンドトラフィックを許可していることを確認してください。注意：ピアリング接続では、リージョンをまたいでセキュリティグループ ID を参照することはできません。
- NACL： セキュリティグループとは異なり、ネットワーク ACL（NACL）はステートレスです。両端でインバウンドとアウトバウンドの両方のトラフィックを許可する必要があります。
- CIDR の重複： 両方の VPC が
10.0.0.0/16を使用している場合、ピアリングは機能しません。AWS は、両側が同じアドレス空間を主張している場合、トラフィックをルーティングできません。
VPC を構築する前にアドレスの競合を避けるために、ToolCraft Subnet Calculator を使用することをお勧めします。これは、Dev、Staging、Production 環境の CIDR ブロックを計画し、将来のピアリングで重複しないようにするための優れた方法です。