AWS Direct Connectの100ルート問題｜BGP経路数の上限とセッション断の回避策

AWS Direct Connectで「100ルート問題」と呼ばれるのは、1本のBGPセッションでオンプレミスからAWSへ広告できる経路数の上限に当たる事象です。厄介なのは、上限を超えたときに通信が遅くなるのではなく、BGPセッションそのものが落ちて経路がまとめて消える点にあります。拠点の追加やVPCの分割で経路は静かに増えていき、101本目を広告した瞬間に専用線が沈黙します。冗長構成でも、両系に同じ経路を流していれば道連れです。この記事では上限値と超過時の挙動を公式のクォータ定義から確定させ、経路集約・仮想インターフェイス分割・allowed prefixesという打ち手と、100に届く前に気付くための監視設計を整理します。

まとめ

先に結論を置きます。

• 上限はBGPセッション単位でIPv4・IPv6が「それぞれ」100経路です。合計200ではなく、アドレスファミリごとに別々に100まで。対象はプライベート仮想インターフェイス（private VIF）とトランジット仮想インターフェイス（transit VIF）の両方です。
• 超えたときの挙動は性能劣化ではありません。公式クォータの注記どおりBGPセッションがidle状態に入りDOWNするため、その仮想インターフェイスの経路がまとめて消えます。
• この100を動かせるかどうかは、AWSのドキュメント内で記述が割れています。クォータ表の備考欄はSA/TAMへの相談を案内する一方、障害切り分けのページは「hard limits and cannot be exceeded」と明記しています。緩和を前提にした設計は避けてください。
• 現実的な打ち手は経路集約が第一で、次が仮想インターフェイスの分割です。ただし分割の余地は接続形態によって変わり、パートナー経由のホスト接続では成立しません。
• AWSからオンプレミスへ流れる経路は別枠です。Direct ConnectゲートウェイにTransit Gatewayを関連付けた構成では、allowed prefixesに書いたプレフィックスだけが広告され、transit VIF経由でTransit Gatewayから流れる数はIPv4とIPv6の合計で200です。
• Transit Gateway Connectは経路数の天井を1,000へ引き上げますが、代わりにGREトンネル1本あたり5Gbpsという帯域の天井が付きます。経路数だけを見て選ぶ機能ではありません。

以下、それぞれの根拠と設計上の判断基準を見ていきます。

100ルート問題の正体｜BGPセッションあたりIPv4・IPv6が各100経路

Direct Connectのクォータ表には「Routes per Border Gateway Protocol (BGP) session on a private virtual interface or transit virtual interface from on-premises to AWS」という項目があり、値は「100 each for IPv4 and IPv6」と定義されています。ここを「IPv4とIPv6を合わせて100」と読むと、デュアルスタック環境で見積もりを誤ります。IPv4で100本、IPv6で100本まで、という数え方です。

上限が効く方向と仮想インターフェイスの種類

もう1つ取り違えやすいのが方向です。100という数字はオンプレミスからAWSへ広告する側にかかるもので、AWSからオンプレミスへ流れる経路には別の枠が適用されます。仮想インターフェイスの種類によっても値が変わります。

この表の範囲では、public VIFの1,000だけが「この上限は引き上げられません」と明記された固定値です。クォータ表全体には他にも変更不可と明記された項目が多数あるため、備考欄の文言は項目ごとに確認してください。

超過時の挙動｜セッションのidle化と冗長構成の同時断

クォータ表の注記は挙動まで書いています。IPv4・IPv6それぞれについて100を超える経路を広告すると、BGPセッションはidle状態に入りDOWNします。閾値を超えた分の経路だけが無視される、という穏当な動作ではありません。セッションが落ちるので、その仮想インターフェイスが運んでいた経路がまとめて消えます。

設計上いちばん危ないのは、冗長化した2本のDirect Connectに同じ経路を広告している構成です。経路が101本に増えた原因はオンプレミス側の広告内容なので、両系のBGPセッションが同じ条件で同時に上限を超えます。冗長構成が冗長として機能しません。

切り分けの目安も単純です。物理リンクは正常なのにBGPだけがDOWNのまま戻らない、あるいは復旧してもすぐ落ちるなら、直前に増やした経路を疑ってください。ネットワーク機器の故障や光レベルの劣化であれば、ConnectionLightLevelRx や ConnectionErrorCount といった物理側のメトリクスにも異常が出ます。

オンプレミスからAWSへの広告経路を減らす打ち手｜経路集約と仮想インターフェイス分割

先に押さえておきたいのは、経路が増える作業はDirect Connectの設定変更とは限らない点です。オンプレミス側でのサブネット追加や別拠点のルーティング変更がBGPで伝播し、Direct Connectには一切触れていないのに上限へ届くことがあります。だからこそ、経路数は構成変更のたびに数えるのではなく、常時監視する対象になります。

経路集約｜/24を64本から/18を1本へ畳む効果と副作用

最初に検討するのは集約です。拠点ごとに切った小さなプレフィックスを、上位のCIDRブロック1本に束ねて広告します。連続したアドレス帯を割り当てていれば、64本の/24を1本の/18に畳めます。

ただし集約には副作用があります。集約後のプレフィックスは、実際には存在しないアドレス帯まで「到達できる」と宣言することになるため、拠点間の経路が切れていてもAWS側からは検知できません。アドレス設計が飛び飛びで集約範囲に他組織のレンジが混ざる場合は、無理にまとめず次の手を選んだほうが安全です。

仮想インターフェイスの分割｜専用接続とホスト接続で異なる分割余地

上限は「BGPセッションあたり」なので、仮想インターフェイスを分ければ枠も増えます。ただしこれは専用接続（dedicated connection）を契約している場合の話です。パートナー経由のホスト接続（hosted connection）は1接続あたり仮想インターフェイス1本で、しかも引き上げ不可と明記されているため、枠を増やすには接続そのものを追加するしかありません。

専用接続でも、分割の余地には別のクォータがかかります。専用接続1本あたりのtransit VIFは4本まで（この項目の備考はSA/TAMへの相談です）、private VIFとpublic VIFは合わせて50本、transit VIFを含めた合計は51本で、後者2つは引き上げ不可と明記されています。Direct Connectゲートウェイ1つに紐付けられるprivate VIFとtransit VIFは30本までです。

実務では、経路数のためだけにVIFを分けると経路制御が複雑になります。部門やセキュリティ境界など、もともと分ける理由があるところで分割するのが素直です。

上限緩和の可否｜クォータ表と障害切り分けページで記述が食い違う

ここは正直に書きます。AWSのドキュメントは、100経路を動かせるかどうかについて2通りのことを言っています。

後者は「private VIFで100、public VIFで1,000を超えるプレフィックスを広告していないか確認せよ」という文脈で書かれており、この2つをまとめてhard limitと呼んでいます。したがって、緩和が通る前提で設計するのは危険です。広告経路が100に迫っている構成では、まず集約とVIF構成の見直しで収める前提を置き、そのうえでAWSの担当窓口に可否を確認するという順番が安全です。

AWSからオンプレミスへの経路は別枠｜allowed prefixesのTGW関連付けとVGW関連付けの挙動差

AWS側の経路をオンプレミスへ広告する量は、Direct Connectゲートウェイのallowed prefixesで制御します。ここで混乱しやすいのは、関連付け先がTransit Gatewayか仮想プライベートゲートウェイかで、同じ設定値の意味が変わることです。公式ドキュメントは、VPC CIDRが10.0.0.0/16の構成で次のように挙動を説明しています。

Transit Gateway関連付けでは、書いたプレフィックスがそのまま広告されます。VPCのCIDRとは無関係にプロビジョニングされ、Direct ConnectゲートウェイのASNを起点とした経路として届きます。したがってVPCを何十個ぶら下げていても、allowed prefixesに10.0.0.0/8と1行書けばオンプレミス側が受け取る経路は1本です。

仮想プライベートゲートウェイ関連付けでは逆に、allowed prefixesはフィルタとして働きます。VPCのCIDRと同じか、それより広い範囲を書く必要があり、実際に広告されるのは関連付けたVPCのCIDRです。10.0.0.0/16のVPCに対して10.0.0.0/24と書くと、狭すぎて何も受け取れません。

なお、1つのDirect Connectゲートウェイに複数のTransit Gatewayを関連付ける場合、allowed prefixesの重複は許されません。0.0.0.0/0はすべてのIPv4ネットワークを含むため、複数関連付けの構成では設定できず、重複を示すエラーが返ります。

Transit Gateway Connectの正味の効果｜経路の天井は1,000、帯域の天井は5Gbps

この機能を「100ルート問題の解決策」として紹介する記事を見かけます。方向としては間違っていません。ただし効き方と代償を数字で押さえないと、選択を誤ります。

Transit Gateway Connectは、複数のVPCとオンプレミス網を中継するTransit Gatewayと、サードパーティ製の仮想アプライアンス（SD-WAN機器など）をGREトンネルで接続し、その上でBGPを動かす仕組みです。アプライアンスの設置場所はAWS公式ブログで「located inside AWS, or in your on-premises network」と説明されており、VPC内に限りません。土台となるtransport attachmentにはVPCアタッチメントに加えてDirect Connectアタッチメントも使えます。

AWSはこの統合の適用場面を「多数のプレフィックスをTransit Gatewayとの間で広告する必要がある」ケースと説明していますが、「transit VIFの100経路制限を回避できる」とは明文化していません。技術的には、経路がtransit VIFのBGPセッションではなくGREトンネル上のBGPで運ばれるため、クォータの適用先が「仮想ルーターアプライアンスからConnect peerへ広告できる動的経路」に移ります。この枠は1,000（備考はSA/TAM相談）で、逆にConnect peerからアプライアンスへ広告される経路は5,000、こちらは引き上げ不可です。

代償は帯域です。Connect peer（GREトンネル）1本あたりの帯域は最大5Gbps、パケットレートは最大30万ppsが上限で、いずれも引き上げられません。Connect attachment 1つにつきConnect peerは4本までなので、束ねても合計20Gbpsです。一方でDirect Connectゲートウェイのアタッチメント側は、リージョン内の利用可能なアベイラビリティゾーンあたり各方向100Gbpsまで許容されます（実効値は物理接続のポート速度に従うため、10Gbps回線であれば20Gbpsという上限は制約になりません）。100Gbps級の接続を引いている構成では、経路数の天井を上げる代わりに帯域の天井を大きく下げる取引になります。

運用面の制約も見落とせません。Connect attachmentではBidirectional Forwarding Detection（BFD）が使えず、BGPのgraceful restartもサポートされません。BGPピアリング自体はIPv4のみで、IPv6のプレフィックスはMP-BGPを使ってIPv4ピアリング上で交換します。静的経路も使えません。課金面では、Connect attachmentはTransit Gatewayのオーナーに対して時間課金され、データ処理料金はConnect attachment自体には追加されず、土台となるVPCまたはDirect Connectアタッチメントに準じます。

ここは判断を言い切ります。「100経路では足りない」という理由だけでTransit Gateway Connectを選ぶべきではありません。SD-WANアプライアンスをすでに運用していて、その制御プレーンをAWS側へ延伸したいという動機が先にあり、なおかつ広告経路が数百規模で集約も通らない、この条件が揃って初めて釣り合います。単一フローで5Gbpsを超える転送が必要な構成や、障害検知をBFDの秒未満オーダーに依存している構成では採用しないでください。

あわせて、「GREトンネルを使うことで帯域が向上し低遅延になる」という説明も見かけますが、これは限定付きで読む必要があります。AWSはGREを「for high performance」と表現しており、Site-to-Site VPNのトンネル（1本あたり1.25Gbps）と比べれば確かに高性能側です。ただし帯域が青天井になるわけではなく、Connect peer 1本は5Gbps・30万ppsで頭打ちになります。外部インターフェイスのMTUからGREヘッダ4バイトと外側IPヘッダ20バイトを引いた値をトンネルMTUに設定する（1500バイトなら1476バイト）という調整も必要で、怠るとフラグメントが発生します。

CloudWatchで100に届く前に気付く監視設計

上限超過は予兆なく全断につながるため、経路数そのものを監視対象にします。Direct Connectのメトリクスはnamespace AWS/DX へ送信され、仮想インターフェイス単位で次の3つが使えます。

名前が紛らわしいので方向を押さえてください。100の枠に当たるのは自社ルーターがAWSへ広告した数、すなわちAWS側から見て「受け入れた」数なので、監視すべきはAcceptedのほうです。Advertisedを見ていても100ルート問題は検知できません。

これら3つのBGPメトリクスには IpAddressFamily ディメンションがあり、値は ipv4 と ipv6 です。上限が「各100」で数えられる以上、アラームもアドレスファミリごとに分けます。メトリクスの既定の粒度は5分間隔で、各区間は最低2サンプルの集約値です。

aws cloudwatch put-metric-alarm \
  --alarm-name dx-vif-prefixes-ipv4-near-limit \
  --namespace AWS/DX \
  --metric-name VirtualInterfaceBgpPrefixesAccepted \
  --dimensions Name=VirtualInterfaceId,Value=dxvif-xxxxxxxx Name=IpAddressFamily,Value=ipv4 \
  --statistic Maximum \
  --period 300 \
  --evaluation-periods 1 \
  --threshold 80 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --treat-missing-data notBreaching \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:dx-alert

# IPv6を広告している場合は Value=ipv6 に替えて同じコマンドをもう一度実行する

閾値を80に置いているのは、100に達してからでは遅いためです。残り20本という猶予があれば、集約するか仮想インターフェイス構成を見直すかを落ち着いて選べます。--treat-missing-data notBreaching を付けているのは、BGPが落ちてメトリクスが欠測したときにアラームがINSUFFICIENT_DATAへ入り、かえって気付けなくなる事態を避けるためです。断そのものは VirtualInterfaceBgpStatus のアラームで検知します。マネジメントコンソールから作る場合は、メトリクスの選択画面で DX を選びます。

経路数を増やさない経路制御｜推移的ルーティングとlocal preference

拠点間接続｜public VIFの推移的ルーティング非対応とSiteLink

経路が増える原因の一部は、経路制御を経路数で解こうとすることにあります。まず、public VIFでは接続間の推移的ルーティングがサポートされません（このVIFの経路上限は1,000です）。拠点同士をAWS経由で相互接続する目的でプレフィックスを追加しても通らないため、経路だけが増えます。

Direct Connectのロケーション同士を接続するための機能はSiteLinkで、こちらのプレフィックス上限は100です。拠点間接続が目的なら、public VIFに経路を足すのではなくSiteLinkの採否を検討してください。

経路選択の優先順位｜local preferenceコミュニティによる冗長化

private VIFとtransit VIFでは、AWSは最長プレフィックス一致を最初に評価し、プレフィックス長が同じ場合はlocal preferenceを見ます。次にAS_PATH長、最後にMED（Multi-Exit Discriminator）ですが、MEDは評価順が低いためAWSは推奨していません。local preferenceはBGPコミュニティタグで指定します。

タグを付けない場合、Direct Connectロケーションと同じ関連リージョンには7224:7200相当の中優先度が設定され、関連リージョンが異なる場合はより低い値になります。相互排他のタグなので併用はできず、評価は低優先度から高優先度へ進む点に注意してください。複数のDirect Connectで負荷分散したいなら全プレフィックスに同じタグを付け、主系と待機系を分けたいなら高低を割り当てます。ECMPは、AS_PATH長とBGP属性が同じプレフィックスであれば複数のtransit VIF／private VIFにまたがって機能し、AS_PATH内のASNが一致している必要はありません。

言い換えると、冗長性や優先度をプレフィックスの細分化（より長いマスクを別途広告する手法）で表現するのは、100本の枠を消費する方法です。コミュニティタグで優先度を表現すれば、経路数を増やさずに同じ制御ができます。経路が90本を超えてきた環境では、まずここを見直してください。

よくある質問

100ルート問題はDirect Connectのどの構成で起きますか？

プライベート仮想インターフェイスとトランジット仮想インターフェイスで、オンプレミスからAWSへBGPで経路を広告する構成です。パブリック仮想インターフェイスの上限は1,000経路なので、この問題の対象外です。仮想インターフェイスの種類ごとの整理は本文の表を参照してください。

IPv4とIPv6を合わせて100ですか、それぞれ100ですか？

それぞれ100です。公式クォータの表記は「100 each for IPv4 and IPv6」で、CloudWatchのBGPメトリクスにも ipv4／ipv6 を切り替える IpAddressFamily ディメンションが用意されています。デュアルスタック環境では、両方を別々にカウントして監視してください。

上限を超えるとどんな症状になりますか？

通信が遅くなるのではなく、BGPセッションがidle状態になりDOWNします。その仮想インターフェイス経由の経路が消えるため通信断です。冗長構成であっても、両系に同じ経路を広告していれば同時に上限を超えて同時に落ちます。物理リンクは正常なのにBGPだけがDOWNのまま戻らない場合は、直前の経路追加を疑ってください。

AWSからオンプレミスへ流れる経路にも100の制限がありますか？

別の枠が適用されます。トランジット仮想インターフェイス経由でTransit Gatewayから広告されるプレフィックスはIPv4とIPv6の合計で200、Cloud WANのコアネットワークをDirect Connectゲートウェイにアタッチした構成では5,000です。この方向の経路数はDirect Connectゲートウェイのallowed prefixesで制御でき、Transit Gateway関連付けなら書いたプレフィックスだけが広告されます。

100の上限は引き上げられますか？

AWSのドキュメント内で記述が割れているため、引き上げられる前提で設計しないでください。クォータ表ではこの項目の備考にソリューションアーキテクトまたはテクニカルアカウントマネージャーへの相談が案内されている一方、レイヤー3／4の障害切り分けページは「private VIFで100、public VIFで1,000を超えるプレフィックスを広告していないか確認せよ。These are hard limits and cannot be exceeded」と明記しています。実際の可否は契約しているサポート体制によって変わるため、AWSの担当窓口で確認したうえで、確認が取れるまでは集約と構成見直しで100本以内に収める設計を採ってください。

関連記事

• AWS Direct Connectとは？専用線接続の仕組み・VPNとの違い・料金と導入判断【2026年版】
• AWS Transit Gatewayとは｜仕組み・VPC Peeringとの違い・料金を解説
• AWSのネットワーク接続方式まとめ｜VPC内・VPC間・オンプレ・インターネットの選び分け
• VPCエンドポイントとは｜2種類の違いとNATゲートウェイとの料金比較・損益分岐点