① 異なるリージョンのEC2は「別の国にある建物」と同じ。直接は通信できず、必ず「接続手段」の設定が必要。
② 接続手段は3パターン：VPCピアリング（直行便）、Transit Gateway（ハブ空港）、VPN/Direct Connect（専用回線）。
③ 通信障害の原因は「5つの関所」のどれか：ルートテーブル → セキュリティグループ → NACL → DNS → アプリ設定。
国際郵便システムでたとえると超わかりやすい！
AWSリージョン = 国。VPC = その国の中にある都市。EC2 = 都市の中の建物。 異なるリージョンのEC2に通信を送るとは、つまり「別の国にある建物に手紙を届ける」こと。 国内なら普通の郵便で届くけど、海外には国際郵便の仕組み（接続手段）がないと届きません！
| 📮 国際郵便の世界 | ☁️ AWSの世界 | 役割 |
|---|---|---|
| 国（日本・アメリカなど） | リージョン（ap-northeast-1, us-east-1） | 物理的に離れた拠点 |
| 都市（東京、大阪） | VPC | 隔離されたネットワーク空間 |
| 都市の中の建物 | EC2インスタンス | 実際の通信先マシン |
| 国際郵便の航空便 | VPCピアリング | 2拠点間の直接接続 |
| 国際ハブ空港（経由便） | Transit Gateway | 多拠点を集約する中継ハブ |
| 住所（郵便番号） | プライベートIPアドレス / CIDR | 送信先を特定する情報 |
| 税関・検問所 | セキュリティグループ / NACL | 通信の許可・拒否を判定 |
| 配達ルート表 | ルートテーブル | パケットの転送先を決める |
全体アーキテクチャ図
図1：VPCピアリングによるクロスリージョン接続の全体構成
3つの接続パターン
リージョン間のEC2を接続する方法は主に3つ。「国際郵便」に例えると、それぞれの特徴がクリアに見えてきます。
たとえ：直行便（成田→JFK）
2つのVPCを直接つなぐ1対1接続。経由地なし、シンプルで高速。ただし拠点が増えるとペアリングの数が爆発する。
低コスト 低レイテンシ
たとえ：ハブ空港（シンガポール経由）
1つのハブで複数VPC・リージョンを集約。拠点が3つ以上なら圧倒的に管理が楽。Inter-Region Peeringで他リージョンのTGWと接続。
中コスト 高拡張性
たとえ：外交行嚢（専用の安全ルート）
オンプレミスを経由してリージョン間を接続するパターン。既存VPN/DXがある場合に選択。暗号化＋専用線で最もセキュア。
高コスト 高セキュリティ
図2：3つの接続パターン比較 ─ ユースケースに応じて選択
VPCピアリング構築の5ステップ
両国（リージョン）が郵便協定を結ぶには、「申請 → 承認 → ルート設定 → 税関ルール設定」の手順が必要です。AWSも同じ流れです。
CIDR設計の最重要ルール
VPC-A: 10.0.0.0/16
VPC-B: 10.0.0.0/16
同じ住所の都市が2つ存在するのと同じ。ルーターがどちらに届ければいいかわからず、ピアリング接続そのものが作成できない！
VPC-A: 10.0.0.0/16
VPC-B: 10.1.0.0/16
それぞれ固有の住所を持つ都市。ルートテーブルが「10.1.x.x宛ならピアリング経由で送れ」と明確に判断できる。
トラブルシューティング：5つの関所チェック
手紙が届かない時は「配達ルートは正しいか → 税関で止まっていないか → 住所不明で返送されていないか」の順に調べます。 AWSでも同じ。パケットが通る「5つの関所」を順番にチェックすれば、必ず原因が見つかります。
図3：トラブルシューティングは「上流から下流へ」の原則で5つの関所を順番に確認
5つの関所チェックリスト詳細
関所 ① ルートテーブル ─ 「配達ルート表」
- 相手VPCのCIDR（例：10.1.0.0/16）に対するルートが存在するか？ターゲットが正しいピアリング接続ID（pcx-xxx）を指しているか？
- 両方のVPCのルートテーブルに追加済みか？（片方だけでは片道切符の手紙になる）
- より具体的なルート（Longest Prefix Match）が別のターゲットを指していないか？
関所 ② セキュリティグループ ─ 「建物のガードマン」
- 受信側EC2のSGで、送信元CIDRまたは送信元SGからのInboundルールが許可されているか？
- プロトコル（TCP/UDP）とポート番号は正しいか？（例：HTTP=80, HTTPS=443, SSH=22）
- SGはステートフル：Inboundを許可すれば、戻りの通信は自動的に許可される（Outboundの明示設定は不要）
関所 ③ NACL ─ 「都市の入国管理局」
- NACLはステートレス！ Inbound/Outbound両方のルールが必要
- エフェメラルポート（1024-65535）の戻り通信が許可されているか？（最頻出の見落とし原因）
- ルール番号の評価順は小さい番号が優先。先にDenyルールがないか確認
関所 ④ DNS解決 ─ 「住所録サービス」
- VPCの enableDnsSupport と enableDnsHostnames が両方 true になっているか？
- プライベートホスト名を使う場合、DNS解決がピアリング接続を介して動作するか確認
関所 ⑤ アプリケーション ─ 「宛先の部屋番号」
- アプリが正しいIPアドレス/ポートでリッスンしているか？（0.0.0.0 でバインドしているか）
- OS内のファイアウォール（iptables, Windows Firewall）がブロックしていないか？
実践トラブルシューティングコマンド
ping 10.1.1.20 ─ ICMP疎通確認（SGでICMP許可が必要）
telnet 10.1.1.20 443 ─ 特定ポートの接続確認
traceroute 10.1.1.20 ─ 経路確認（どこで止まるか特定）
aws ec2 describe-flow-logs ─ Flow Logsの有効化状態を確認
CloudWatch LogsでREJECTのログを検索 ─ 拒否されたパケットを特定
送信元IP・宛先IP・ポート・アクションを確認
aws ec2 describe-route-tables ─ 全ルートの一覧表示
相手CIDR → pcx-xxx のルートが存在するかチェック
ステータスがactiveであること
aws ec2 describe-security-groups ─ SGルールの確認
aws ec2 describe-network-acls ─ NACLルールの確認
Reachability Analyzer で経路全体を自動検証
AWS公式トラブルシューティングツール
送信元と宛先を指定するだけで、経路上のすべてのコンポーネント（ルートテーブル、SG、NACL、ピアリング接続）を自動分析。どこでブロックされているかを一発で特定。
最も推奨
ENI（ネットワークインターフェース）レベルでパケットのACCEPT/REJECTを記録。CloudWatch LogsまたはS3に出力。長期的な監視と過去のトラブル調査に不可欠。
必須設定
よくある質問（FAQ）
まとめ：覚えておくべきポイント
2拠点 → VPCピアリング。3拠点以上 → Transit Gateway。既存DX/VPNあり → 経由接続。CIDRの重複は絶対NG。
ルートテーブル → SG → NACL → DNS → アプリの順に確認。VPC Reachability Analyzerを最初に使うのが最速。Flow Logsは常時ONで。