📌 結論ファースト：3つの核心ポイント
Direct Connectのルート制限とサマライゼーションについて、まずこれだけ押さえましょう。
100ルート制限
Private VIF / Transit VIF それぞれ IPv4最大100件・IPv6最大100件のBGPルートアドバタイズ制限がある。超過するとBGPセッションがDOWNする
ルート集約で解決
複数の細かいルート（/24など）を1つの大きなルート（/22など）にまとめることで、アドバタイズ数を劇的に削減できる
クォータ引き上げも可能
ルート集約だけでは対応できない場合、AWSサポートへのクォータ引き上げリクエストで上限を変更することも可能
📮 たとえ話で理解する「ルート制限とサマライゼーション」
「郵便配達ルート」に置き換えて考えると、一気に分かりやすくなります
📮 郵便配達員のルート表 ＝ BGPルートテーブル
あなたの会社は、AWSという「巨大な郵便局」と専用の配達ルート（Direct Connect）で結ばれています。この専用ルートを通じて、あなたの会社の各部署の住所（IPルート）を郵便局に伝えて、荷物が届くようにしています。
しかし、この郵便局には「配達先リストに載せられるのは最大100件まで」というルールがあります。101件目の住所を登録しようとした瞬間、配達員はパニックを起こして全ての配達を停止してしまいます（BGPセッションがDOWN）。
そこで使うのが「住所の束ね」（ルート集約）です。「東京都新宿区西新宿1-1」「東京都新宿区西新宿1-2」「東京都新宿区西新宿1-3」「東京都新宿区西新宿1-4」と4件書く代わりに、「東京都新宿区西新宿1丁目」と1件にまとめるイメージです。
📊 「郵便配達ルート表」のたとえ ― Before / After
❌ 束ねる前（4件で登録）
→ 4件分のルート枠を消費
（サマライゼーション）
✅ 束ねた後（1件で登録）
→ たった1件のルート枠でOK！
🚧 BGPルートアドバタイズメントの制限
AWS Direct Connectには、VIFタイプごとに明確なルート数の上限があります
📊 VIFタイプ別 BGPルートアドバタイズ制限
🏢 オンプレミス側
BGPで経路をアドバタイズ
☁️ AWS（Direct Connect）
Private VIF / Transit VIF
を通じて受信
※ Public VIF は別制限
（1,000 prefixes）
⚠️ 100ルートを超えるとどうなる？
制限を超えた瞬間、段階的にではなく即座にBGPセッション全体が停止します。
アドバタイズ
Idle状態に遷移
DOWN
削減して復旧
🔑 ポイント：101件目を追加した瞬間に、既存の100件も含めて「全て」のルートが通信不能になります。部分的な影響ではなく全面的な障害です。
📮 たとえ：配達員のリスト上限
郵便配達員は「配達先リスト」を持っています。このリストに書ける住所は最大100件です。配達先が100件以内なら問題なく荷物を届けられますが、101件目の住所を追加しようとすると配達員はリストをかかえたまま「もうムリです！」とパニックになり、全ての配達を投げ出してしまいます。101件目だけ届かないのではなく、既に登録済みの100件への配達も含めて全て停止してしまうのです。
📦 ルート集約（サマライゼーション）の仕組み
複数の詳細なルートを、より少ない一般的なルートにまとめる技術です
📊 ルート集約 ― Before / After の具体例
❌ 集約前（4ルート）
4ルート分の枠を消費
✅ 集約後（1ルート）
たった1ルートの枠でOK！
🧮 なぜ /24 × 4 → /22 になる？ サブネット計算の裏側
| ルート | 3オクテット目（バイナリ） | 含まれるホスト数 |
|---|---|---|
| 192.168.1.0/24 | 00000001 | 256アドレス |
| 192.168.2.0/24 | 00000010 | 256アドレス |
| 192.168.3.0/24 | 00000011 | 256アドレス |
| 192.168.4.0/24 | 00000100 | 256アドレス |
| 192.168.0.0/22 | 先頭22ビットが共通 → /22に集約 | 1,024アドレス |
💡 /24は256アドレス、/22は1,024アドレス（256×4）をカバー。上位ビットが共通する連続したサブネットを1つのプレフィックスにまとめます。
※ 192.168.4.0 は厳密には 192.168.0.0/22 の範囲を超えるため、実際には 192.168.0.0/22 + 192.168.4.0/24 か、192.168.0.0/21 への集約が必要です。
✨ ルート集約の5大メリット
ルート数の削減
100ルート制限内に収めやすくなり、BGPセッションDOWNのリスクを大幅に低減
ルーティングテーブル縮小
ルーターが保持するテーブルが小さくなり、メモリ使用量とCPU負荷が軽減
ネットワーク安定性向上
個々のサブネット変更がBGPアップデートを引き起こさないため、フラッピングを抑制
帯域幅の節約
BGP Updateメッセージの数が減り、制御プレーンのトラフィックが削減される
収束時間の短縮
ルート変更時にネットワーク全体が安定するまでの時間（収束時間）が短くなる
管理のシンプル化
ルートの数が少ないほど、トラブルシューティングや監査が容易になる
🏢 実践シナリオ：企業ネットワークでのルート集約
大規模企業がDirect Connectでどのようにルート集約を活用するかを見てみましょう
🏢 シナリオ：従業員5,000人の製造業企業
東京本社、大阪支社、名古屋工場の3拠点があり、各拠点に複数のサブネットがあるとします。集約前は合計48ルートをアドバタイズしており、制限の半分近くを消費しています。
| 拠点 | 集約前のルート | ルート数 | 集約後 | 集約後ルート数 |
|---|---|---|---|---|
| 東京本社 | 10.1.1.0/24 ～ 10.1.20.0/24 | 20 | 10.1.0.0/19 | 1 |
| 大阪支社 | 10.2.1.0/24 ～ 10.2.16.0/24 | 16 | 10.2.0.0/20 | 1 |
| 名古屋工場 | 10.3.1.0/24 ～ 10.3.12.0/24 | 12 | 10.3.0.0/20 | 1 |
| 合計 | ― | 48ルート | ― | 3ルート |
✅ 結果：48ルート → 3ルートに削減（93.75%削減）。100ルート制限に対して余裕が生まれ、将来の拡張にも安心です。
⚙️ クォータ引き上げリクエスト
ルート集約だけでは対応できない場合の最終手段
📋 クォータ引き上げの流れ
Service Quotas
コンソール
AWS Service Quotasから Direct Connectの クォータを検索
引き上げ
リクエスト送信
必要なルート数と ビジネス理由を 記載して申請
AWSによる
審査
AWS側でリクエスト を審査（数営業日 かかる場合あり）
承認・適用
承認後、新しい 上限が自動的に 適用される
📮 たとえ：郵便局への特別リクエスト
通常の配達先リストは100件までですが、どうしても足りない場合は郵便局長（AWS）に「特別に枠を増やしてください」と申請書を出すことができます。ただし、まずは住所の束ね（ルート集約）をやった上で、それでも足りない正当な理由が必要です。申請が通れば配達先リストの枠が拡張されますが、審査には時間がかかるので、ギリギリになってからではなく余裕を持って申請しましょう。
💻 ルート集約の設定例
オンプレミスのルーター側でルート集約を設定する方法（Cisco IOSの例）
⌨️ Cisco IOS ルート集約設定例
# --- オンプレミスルーターでのBGPルート集約設定 --- # BGPプロセスに入る（AS番号65000の例） router bgp 65000 # AWSのDirect Connect側ピアを設定 neighbor 169.254.100.1 remote-as 7224 # アドレスファミリ IPv4 ユニキャストの設定 address-family ipv4 unicast # ルート集約：192.168.0.0/22 にまとめる # summary-only を付けると詳細ルートのアドバタイズを抑制 aggregate-address 192.168.0.0 255.255.252.0 summary-only # 10.1.0.0/19 に東京本社の20サブネットを集約 aggregate-address 10.1.0.0 255.255.224.0 summary-only # 10.2.0.0/20 に大阪支社の16サブネットを集約 aggregate-address 10.2.0.0 255.255.240.0 summary-only # 10.3.0.0/20 に名古屋工場の12サブネットを集約 aggregate-address 10.3.0.0 255.255.240.0 summary-only exit-address-family
⌨️ AWS CLI でBGP経路を確認
# Direct ConnectのVIF一覧を確認 aws directconnect describe-virtual-interfaces # 特定のVIFのBGPピア情報を確認 aws directconnect describe-virtual-interfaces \ --virtual-interface-id dxvif-abc12345 \ --query "virtualInterfaces[].bgpPeers" # BGPステータスがdownの場合、ルート数超過の可能性あり # bgpStatus: "down" → ルート数を確認！ # Service Quotasでルート数の現在の上限を確認 aws service-quotas get-service-quota \ --service-code directconnect \ --quota-code L-XXX
📊 VIFタイプ別ルート制限の比較
VIFの種類によってルート制限のルールが異なります
| VIFタイプ | IPv4ルート上限 | IPv6ルート上限 | 制限超過時の動作 | クォータ引き上げ |
|---|---|---|---|---|
| Private VIF | 100 | 100 | BGPセッションDOWN | リクエスト可能 |
| Transit VIF | 100 | 100 | BGPセッションDOWN | リクエスト可能 |
| Public VIF | 1,000 | 1,000 | BGPセッションDOWN | 要確認 |
※ AWS→オンプレミス方向にアドバタイズされるルート数にも制限があります。VGW接続の場合は最大100ルート、Transit Gateway接続の場合も制限があるため要注意。
✅ ベストプラクティス
ルート制限のトラブルを未然に防ぐための実践的なガイドライン
🏆 運用で守るべき6つのルール
IPアドレス設計時にサマライゼーションを考慮
最初のIPアドレス割り当て時に、将来のサマライゼーションを見越した連続的なアドレス空間を確保しましょう。後からの再割り当ては非常に困難です。
ルート数を定期的に監視
CloudWatchやオンプレミスの監視ツールで、アドバタイズしているルート数を常にモニタリング。80ルートを超えたらアラートを設定しましょう。
変更前にテスト環境で検証
BGPルートの変更は影響範囲が大きいため、必ずテスト環境で集約後のルーティングを検証してから本番に適用しましょう。
summary-only オプションを活用
ルート集約時にsummary-onlyを付けることで、詳細ルートのアドバタイズを確実に抑制し、ルート数削減の効果を最大化します。
ルート変更の変更管理プロセス
BGPルートの追加・変更は必ずチケット管理し、現在のルート数と上限を確認してから実施しましょう。
冗長化とフェイルオーバーの確認
ルート集約の設定はプライマリとバックアップの両方のDirect Connect接続で一貫性を保つようにしましょう。
❓ よくある質問（FAQ）
ルート制限とサマライゼーションに関するよくある質問
clear ip bgp <peer-ip> を実行します。
📝 試験対策ポイント（SAP / ANS）
AWS認定試験で狙われやすいポイントをまとめました
🎯 試験で問われるキーポイント
📌 頻出パターン1：BGPセッションDOWNの原因
「Direct ConnectのBGPセッションが突然DOWNした」→ まずルートアドバタイズ数の超過を疑う。100ルート制限はほぼ確実に出題されます。
📌 頻出パターン2：ルート数削減の方法
「ルート数が多すぎて制限に近い」→ 答えはルート集約（Route Summarization）。設問でsummary-onlyやaggregate-addressが選択肢に出たら要注目。
📌 頻出パターン3：VIFタイプの違い
Private VIFとTransit VIFの制限は同じ100ルート。Public VIFは1,000ルート。この数値の違いを問う設問があります。
📌 頻出パターン4：クォータ引き上げ
「ルート集約後もルート数が足りない」→ Service Quotasからクォータ引き上げリクエストが正解。自動で上限が上がることはないことを覚えておきましょう。