--- title: "AWS Direct Connectの100ルート問題｜既定100経路の上限と最大1,000への引き上げ手順" url: "https://www.issoh.co.jp/tech/details/4648/" published: 2024-12-25 updated: 2026-10-17 categories: ["AWS"] publisher: "株式会社一創" --- # AWS Direct Connectの100ルート問題｜既定100経路の上限と最大1,000への引き上げ手順 AWS Direct Connectの「100ルート問題」は、1本のBGPセッションでオンプレミスからAWSへ広告できる経路数の上限に当たる事象です。上限を超えると通信が遅くなるのではなく、BGPセッションが落ちて経路がまとめて消えます。この上限は長く動かせないものとして扱われてきましたが、2026年8月20日にAWSがinbound prefix controlsを発表し、仮想インターフェイス（VIF）ごとに最大1,000経路まで割り当てられるようになりました。ただし既定値は今も100で、何もしなければ挙動は変わりません。この記事では上限と超過時の挙動、1,000へ引き上げる手順、引き上げても効かない構成、監視の設計を公式ドキュメントに沿って整理します。 ## まとめ - 既定の上限はBGPセッション単位で**IPv4・IPv6が「それぞれ」100経路**です。対象はprivate VIFとtransit VIFで、public VIFは別枠の1,000です。 - 超えると**BGPセッションがidle状態になりDOWN**します。冗長化した両系に同じ経路を広告していれば、両系が同時に落ちます。 - 2026年8月20日以降は、inbound prefix controlsで**VIFごとに最大1,000（IPv4・IPv6それぞれ）**まで割り当てられます。追加料金はありません。既定の割り当ては100のままなので、明示的に変更が必要です。 - 専用接続上のVIFをDirect Connectゲートウェイに接続する場合、割り当ては接続のプール（1・10GbpsではIPv4・IPv6各5,000）とゲートウェイのプール（IPv4・IPv6合計10,000）の両方から差し引かれます。デュアルスタックで1,000ずつ割り当てると、1つのゲートウェイに付けられるVIFは5本で埋まります。 - 仮想プライベートゲートウェイ経由でVPCへ経路を伝播する構成では、**VPCルートテーブルの伝播経路100（引き上げ不可）**が先に効きます。VIFを1,000にしてもVPCに入る経路は増えません。 - オンプレミスからAWSへの広告が1,000経路以内で、必要な枠をVIFに確保できる場合は、Transit Gateway Connectの追加より割り当て変更を優先します。ネイティブのtransit VIFで同じ1,000に届き、GREトンネルの5Gbpsという帯域の天井も付きません。 ## 100ルート問題の正体｜BGPセッションあたりIPv4・IPv6が各100経路 [Direct Connectのクォータ表](https://docs.aws.amazon.com/directconnect/latest/UserGuide/limits.html)は、private VIFまたはtransit VIFでオンプレミスからAWSへ広告する経路数を「Default of 100 each for IPv4 and IPv6」と定義しています。IPv4とIPv6を合わせて100ではなく、アドレスファミリごとに100ずつです。同じ項目の注記には「Can be increased using prefix controls up to 1,000 each for IPv4 and IPv6」と追記されています。 ### 上限が効く方向と仮想インターフェイスの種類 100という数字は、オンプレミスからAWSへ広告する方向にだけかかります。AWSからオンプレミスへ流れる経路は別の枠です。 | 対象 | 方向 | 既定 | 引き上げ | | ------------------------------ | ------------ | --------------- | ------------------------ | | private VIF / transit VIF | オンプレミス → AWS | IPv4・IPv6 各100 | prefix controlsで各1,000まで | | public VIF | オンプレミス → AWS | 1,000 | 不可 | | Transit Gateway（transit VIF経由） | AWS → オンプレミス | IPv4+IPv6 合計200 | SA/TAMに相談 | | Cloud WANコアネットワーク | AWS → オンプレミス | 5,000 | SA/TAMに相談 | | SiteLink | プレフィックス数 | VIFの割り当てに従う | prefix controlsで各1,000まで | ### 超過時の挙動｜セッションのidle化と冗長構成の同時断 クォータ表は、割り当てを超える経路を広告するとBGPセッションがidle状態に入り、ステータスがDOWNとして報告されると書いています。超えた分だけ無視される動作ではありません。セッションが落ちるので、そのVIFが運んでいた経路がまとめて消えます。 ルーター側からは、AWSから届くBGP NOTIFICATIONで原因が分かります。[野村総合研究所のエンジニアが公開した検証記事](https://qiita.com/KazukiFujiwara/items/46f5e4b39bf2e8178110)のCiscoルーターのログには「6/1 (Maximum Number of Prefixes Reached)」の受信と、数秒おきの再接続と切断が記録されています。6/1はCease（コード6）のサブコード1で、[RFC 4486](https://www.rfc-editor.org/rfc/rfc4486)が定める「Maximum Number of Prefixes Reached」です。 危ないのは、冗長化した2本のDirect Connectに同じ経路を広告している構成です。経路が101本に増えた原因はオンプレミス側にあるため、両系のセッションが同じ条件で同時に上限を超えます。別拠点や別クラウド向けのルーティング変更でも、BGPで伝播して静かに上限へ届きます。 ## inbound prefix controls｜VIFごとに最大1,000経路を割り当てる仕組み [2026年8月20日の発表](https://aws.amazon.com/about-aws/whats-new/2026/08/aws-direct-connect-new-prefix-controls/)で、専用接続とホスト接続のVIFにIPv4・IPv6それぞれ最大1,000経路を割り当てられるようになりました。発表文は、それまでのprivate VIFとtransit VIFが受け付ける経路は最大100で、経路集約や複数VIFへの分割で回避するしかなかったと説明しています。全商用リージョンとGovCloud（US-East・US-West）、中国の北京・寧夏リージョンで、追加料金なしで使えます。 ### 接続・ゲートウェイ・VIFの3段のプール [prefix controlsのユーザーガイド](https://docs.aws.amazon.com/directconnect/latest/UserGuide/prefix-controls.html)によると、割り当ては次の3段で制限されます。VIFに割り当てた値は、接続のプールとDirect Connectゲートウェイ（DXGW）のプールの両方から差し引かれます。 | 単位 | 上限 | 数え方 | | ------------- | ------------ | ------------- | | VIF | 1,000（既定100） | IPv4・IPv6それぞれ | | 専用接続 1・10Gbps | 5,000 | IPv4・IPv6それぞれ | | 専用接続 100Gbps | 30,000 | IPv4・IPv6それぞれ | | 専用接続 400Gbps | 50,000 | IPv4・IPv6それぞれ | | DXGW | 10,000 | IPv4とIPv6の合計 | 設計で詰まりやすいのはDXGWの側です。接続のプールはアドレスファミリごとに数えますが、DXGWの10,000はIPv4とIPv6の割り当て値を合計して判定します。デュアルスタックで各1,000を割り当てると1本で2,000を消費し、5本でDXGWが埋まります。DXGWに付けられるVIFは30本までという従来の上限も残っており、どちらかを超えるアタッチ要求は拒否されます。AWS InterconnectをDXGWに接続していると、それだけで2,000を消費します。 LAGのプールはメンバー接続数の倍数です。10Gbpsを4本束ねたLAGはIPv4・IPv6それぞれ20,000で、メンバーを外すとプールが縮みます。縮んだ後のプールが割り当て合計を下回る場合、メンバーの取り外し自体が拒否されます。 ### 割り当て値の確認と変更｜AWS CLIの手順 コンソールでは接続の詳細画面にある「Inbound prefixes」カードでプールの残量を、VIFの編集画面で割り当て値を変更できます。CLIでは、[割り当て管理の手順](https://docs.aws.amazon.com/directconnect/latest/UserGuide/prefix-allocations.html)どおり次のように操作します。パラメータはAWS CLI 2.36.28で追加されたもので、それより古いCLIでは認識されません。 ``` # 接続のプールの大きさと未割り当て数を確認する aws directconnect describe-connections --connection-id dxcon-abc12345 \ --query 'connections[0].[prefixPoolSizeIpv4,prefixPoolUnallocatedCountIpv4,prefixPoolSizeIpv6,prefixPoolUnallocatedCountIpv6]' # 既存VIFの割り当てをIPv4 500・IPv6 100に変更する（即時反映） aws directconnect update-virtual-interface-attributes \ --virtual-interface-id dxvif-abc12345 \ --prefix-pool-allocated-count-ipv4 500 \ --prefix-pool-allocated-count-ipv6 100 # DXGWに付いたVIFの割り当て合計（上限10,000）を確認する aws directconnect describe-direct-connect-gateways \ --direct-connect-gateway-id d2113d06-a0d8-476b-91a7-8555d9973d12 \ --query 'directConnectGateways[0].totalPrefixPoolAllocations' ``` 新規作成時は `create-private-virtual-interface` または `create-transit-virtual-interface` に渡すJSONへ `prefixPoolAllocatedCountIpv4` と `prefixPoolAllocatedCountIpv6` を入れます。変更は即時に反映され、広告中の経路数が新しい割り当て以下ならセッションは維持されます。逆に、使用中の経路数より小さい値への減算はAPIが拒否します。減らしたいときは、先にオンプレミス側の広告を減らしてください。 なお、SDKのサービス定義（botocore 1.43.114で確認）ではこの値は下限0の整数として定義され、上限の1,000はモデルに書かれていません。1,000を超える値や、プールの残量を超える値を弾くのはAPI側です。Terraformなどで値を変数化するときは、手元のバリデーションで1,000以下を保証しておくと、適用時のエラーで気付くより早く止められます。 ### ホスト接続とホストVIFの割り当て変更権限 パートナー経由の契約では、自社で割り当てを変えられるかどうかが契約の形で分かれます。ホスト接続（hosted connection）は1接続にVIF 1本で、接続単位のプールはありません。VIFの割り当ては利用者自身がAPIで最大1,000まで引き上げられ、コンソールにはプールの情報が表示されません。 ホストVIF（パートナーの接続上に作られ、利用者のアカウントに共有されるVIF）は事情が違います。割り当ては親接続のオーナーが管理し、新しいホストVIFは必ず既定の100で作られます。受け入れた後に割り当てを変えられるのは接続オーナーの側です。ホストVIFで100を超える必要があるなら、自分のコンソールではなく契約しているパートナーに変更を依頼することになります。 ### 1,000に上げても効かない構成｜VGW経由のVPCルートテーブルは伝播100 prefix controlsのページ自身が注記している落とし穴です。private VIFを仮想プライベートゲートウェイ（VGW）に付け、経路をVPCのルートテーブルへ伝播している構成では、伝播された経路にVPC側のクォータがかかります。[Amazon VPCのクォータ表](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html)で「Propagated routes per route table」は100で、引き上げ不可です。表の備考は「If you require additional prefixes, advertise a default route」と、デフォルトルートの広告を案内しています。 つまりVGW構成では、VIFの割り当てを1,000にしてBGPセッションが落ちなくなっても、VPCのルートテーブルに入る経路は増えません。100を超える経路をVPCまで届けたいなら、オンプレミスからデフォルトルートか集約経路を広告するか、Transit GatewayをDXGWに関連付けるtransit VIF構成へ移るかのどちらかです。Transit Gatewayには、1つのゲートウェイの全ルートテーブルを合計して動的・静的経路10,000の既定上限があり、こちらはSA/TAMへの相談で引き上げを検討できます。 ### 障害切り分けページの旧上限表記と読み替え 2026年10月17日時点で、Direct Connectの[レイヤー3/4の障害切り分けページ](https://docs.aws.amazon.com/directconnect/latest/UserGuide/ts-layer-3.html)は「private VIFで100、public VIFで1,000を超えて広告していないか」を確認項目に挙げ、「These are hard limits and cannot be exceeded」と書いたままです。クォータ表と発表文はprefix controlsでの引き上げを明記しているので、private VIFの100については割り当て値に読み替えてください。切り分けで確かめるべきなのは、広告している経路数がそのVIFの割り当て値を超えていないかです。 ## 引き上げより先に検討する打ち手｜経路集約とVIFの分け方 1,000まで割り当てられるようになっても、集約は第一の選択肢のままです。上の伝播100の制約や、DXGWの合計10,000を食い合う問題は、経路が少なければ起きません。連続したアドレス帯を割り当てていれば、拠点ごとの/24を64本、/18の1本に畳めます。 | 広告内容 | 経路数 | | ---------------------------------- | --- | | 10.10.0.0/24 〜 10.10.63.0/24（拠点ごと） | 64 | | 10.10.0.0/18（同じ範囲を集約） | 1 | 集約の副作用は、存在しないアドレス帯まで到達可能と宣言することです。拠点側の経路が切れてもAWS側からは見えません。アドレス設計が飛び飛びで、集約範囲に他組織のレンジが混ざる場合は、無理にまとめず割り当ての引き上げを選んだほうが安全です。 VIFの分割は、prefix controls以前の主な回避策でした。専用接続ではtransit VIFが4本まで、private VIFとpublic VIFは合わせて50本、全体で51本まで作れます。今後は経路数のためだけに分ける理由は薄く、部門やセキュリティ境界など、もともと分ける理由がある場所でだけ分けるのが素直です。分けた場合も、各VIFの割り当ては同じ接続のプールから差し引かれます。 ## AWSからオンプレミスへの経路は別枠｜allowed prefixesの挙動差 AWS側の経路をオンプレミスへ広告する量は、DXGWのallowed prefixesで制御します。関連付け先がTransit Gatewayか仮想プライベートゲートウェイかで、同じ設定値の意味が変わります。VPCのCIDRが10.0.0.0/16の場合、公式ドキュメントの例は次のとおりです。 | allowed prefixes | Transit Gateway関連付け | VGW関連付け | | ------------------ | ------------------- | --------------- | | 22.0.0.0/24 | 22.0.0.0/24 を受信 | 受信なし | | 10.0.0.0/24 | 10.0.0.0/24 を受信 | 受信なし | | 10.0.0.0/15（VGWの例） | 公式例なし | 10.0.0.0/16 を受信 | Transit Gateway関連付けでは、書いたプレフィックスがそのまま広告されます。VPCが何十個あっても、10.0.0.0/8と1行書けばオンプレミスが受け取る経路は1本です。transit VIF経由でTransit Gatewayから流れる経路の上限はIPv4とIPv6の合計200なので、ここは集約で収めるのが基本です。VGW関連付けではallowed prefixesはフィルタとして働き、VPCのCIDRと同じかそれより広い範囲を書く必要があります。1つのDXGWに複数のTransit Gatewayを関連付ける場合、allowed prefixesの重複は許されません。 ## Transit Gateway Connectの採用判断｜広告方向ごとの経路枠と帯域制約 [Transit Gateway](/tech/details/4263/)のConnectアタッチメントは、GREトンネルの上でBGPを動かし、SD-WAN機器などの仮想アプライアンスと経路を交換する仕組みです。Direct Connectのアタッチメントを土台にでき、[Transit Gatewayのクォータ](https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-quotas.html)ではアプライアンスからConnect peerへ広告できる経路が1,000です。prefix controls以前は、これがtransit VIFの100を回避する手段として紹介されていました。 今はネイティブのtransit VIFでも同じ1,000に届きます。一方でConnect peer（GREトンネル）1本は帯域5Gbps・30万ppsが上限で引き上げられず、1つのアタッチメントにつき4本まで、合計20Gbpsです。BFDとBGPのgraceful restartも使えません。**オンプレミスからAWSへの広告が1,000経路以内で、VIFに必要な枠を割り当てられるなら、経路数だけを理由にConnectを追加せず、transit VIFの割り当て変更を優先します。**SD-WAN連携に加え、AWSからアプライアンスへ多数の経路を動的広告したい場合なども、Connectの比較対象です。AWSからの広告枠は5,000経路で、関連付けたTransit Gatewayルートテーブルの経路が広告されます。transit VIF経由でTransit Gatewayからオンプレミスへ流せる経路はIPv4とIPv6の合計200なので、AWS側の経路を集約せずに数百本受け取りたい構成では、今もConnectが候補に残ります。すでに経路数のためにConnectを使っている環境は、次の更改でtransit VIFの割り当て引き上げへ戻せるかを検討する価値があります。 ## CloudWatchとBGP route visibilityで上限前に気付く監視 上限超過は予兆なく全断につながるので、経路数そのものを監視します。Direct Connectは[namespace AWS/DX](https://docs.aws.amazon.com/directconnect/latest/UserGuide/monitoring-cloudwatch.html)へ次のメトリクスを送ります。3つとも `IpAddressFamily` ディメンション（ipv4／ipv6）を持ちます。 | メトリクス | 意味 | | ------------------------------------- | ------------------- | | VirtualInterfaceBgpPrefixesAccepted | BGPピアから受け入れた数（監視対象） | | VirtualInterfaceBgpPrefixesAdvertised | BGPピアへ広告した数 | | VirtualInterfaceBgpStatus | 1=up、0=down | 上限に当たるのは自社ルーターがAWSへ広告した数で、AWS側から見て「受け入れた」数です。監視すべきはAcceptedで、Advertisedを見ても100ルート問題は検知できません。閾値は100固定ではなく、例えばそのVIFの割り当て値の80%に置きます。割り当てを500にしたなら400です。通常の増加幅と対応時間に合わせて調整し、一度の変更で上限を超える急増は事前検知できない場合があるため、広告経路の変更前確認も併用します。 ``` aws cloudwatch put-metric-alarm \ --alarm-name dx-vif-prefixes-ipv4-near-allocation \ --namespace AWS/DX \ --metric-name VirtualInterfaceBgpPrefixesAccepted \ --dimensions Name=VirtualInterfaceId,Value=dxvif-abc12345 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 # 割り当てを引き上げたら --threshold も割り当て値の80%に直す # IPv6を広告している場合は Value=ipv6 で同じアラームを作る ``` `--treat-missing-data notBreaching` は、欠測を閾値違反なしとして扱う設定です。このアラームでは欠測による障害を通知できないため、BGP状態と監視データの欠測は別途監視します。断そのものは `VirtualInterfaceBgpStatus` のアラームで捉えます。 アラームが鳴った後に「どの経路が増えたか」を調べる手段も増えました。[BGP route visibility](https://docs.aws.amazon.com/directconnect/latest/UserGuide/bgp-route-visibility.html)で、AWSが受け入れた経路をAS\_PATHとコミュニティ付きで一覧できます。AWS CLI 2.36.15以降で使えます。 ``` aws directconnect list-virtual-interface-routes \ --virtual-interface-id dxvif-abc12345 \ --filters '{"routeDirection": "accepted"}' ``` 受け入れ経路の一覧を前回分と突き合わせれば、別クラウド向けの変更が伝播してきた経路をAS\_PATHから特定できます。ルーターにログインせずに切り分けられるのが利点です。 ## 経路数を増やさない経路制御｜SiteLinkとlocal preference public VIFでは接続間の推移的ルーティングがサポートされません。拠点同士をAWS経由でつなぐ目的でpublic VIFにプレフィックスを足しても通らず、経路だけが増えます。Direct Connectのロケーション同士を接続する機能はSiteLinkで、そのプレフィックス上限もprefix controlsで設定したVIFの割り当てに従い、最大1,000です。 冗長構成の優先度は、プレフィックスを細かく切って追加広告するのではなく、BGPコミュニティで表します。private VIFとtransit VIFでは、AWSは最長一致の次にlocal preferenceを評価します。 | コミュニティ | 優先度 | 用途 | | --------- | --- | --------------------- | | 7224:7300 | 高 | Active/Passiveの主系 | | 7224:7200 | 中 | 同一タグで負荷分散（経路属性の一致が必要） | | 7224:7100 | 低 | Active/Passiveの待機系 | より長いマスクを別途広告して主系を作る方法は、割り当ての枠を消費します。コミュニティで優先度を付ければ、経路数を増やさずに同じ制御ができます。BGP route visibilityの一覧にも、受け入れたlocal preferenceコミュニティが表示されるので、意図どおりにタグが付いているかをAWS側から確認できます。 VIFの割り当てやDXGWの構成を含めた設計の見直しを外部に任せたい場合は、[AWS・Google Cloud・Azureのインフラ構築支援](/service/system/aws/)で相談を受け付けています。 ## よくある質問 ### 100ルート問題はDirect Connectのどの構成で起きますか？ private VIFとtransit VIFで、オンプレミスからAWSへBGPで経路を広告する構成です。public VIFの上限は1,000経路で、prefix controlsの対象外です。2026年8月20日以降も、割り当てを変更していないVIFの上限は100のままです。 ### IPv4とIPv6を合わせて100ですか、それぞれ100ですか？ それぞれ100です。prefix controlsで引き上げる場合も、IPv4とIPv6を別々に最大1,000まで割り当てます。ただしDirect ConnectゲートウェイのプールはIPv4とIPv6の合計10,000で数えます。 ### 上限を超えるとどんな症状になりますか？ BGPセッションがidle状態になりDOWNし、そのVIF経由の経路がすべて消えます。ルーターにはBGP NOTIFICATIONの6/1（Maximum Number of Prefixes Reached）が記録され、再接続と切断を繰り返します。両系に同じ経路を広告している冗長構成では、両系が同時に落ちます。 ### 100の上限は引き上げられますか？ 引き上げられます。2026年8月20日に提供が始まったinbound prefix controlsで、VIFごとにIPv4・IPv6それぞれ最大1,000まで、追加料金なしで割り当てられます。1,000を超える値はSA/TAMに相談し、個別審査になります。ホストVIFの割り当ては親接続のオーナー（パートナー）が変更します。 ### VIFの割り当てを1,000にすればVPCに1,000経路入りますか？ 仮想プライベートゲートウェイ経由で伝播する構成では入りません。VPCのルートテーブルに伝播できる経路は100が上限で、引き上げられません。100を超える経路をVPCで扱うなら、デフォルトルートや集約経路を広告するか、Transit Gatewayを使うtransit VIF構成に移ります。 ## 関連記事 - [AWS Direct Connectとは？専用線接続の仕組み・VPNとの違い・料金と導入判断【2026年版】](/tech/details/15476/) - [Transit GatewayとVPC Peeringの違い｜東京リージョン料金とCLI構築手順](/tech/details/4263/) - [AWSのネットワーク接続方式まとめ｜VPC内・VPC間・オンプレ・インターネットの選び分け](/column/details/2805/) - [VPCエンドポイントとは｜2種類の違いとNATゲートウェイとの料金比較・損益分岐点](/tech/details/2326/) --- 出典: [AWS Direct Connectの100ルート問題｜既定100経路の上限と最大1,000への引き上げ手順]()（株式会社一創）