Azure Networking Limits / Quotasを理解するための前提
network limitは「Azure全体の固定値」ではなく、subscription・region・resource typeごとにscopeや引き上げ可否が異なる。 2026-09-11時点のARM network limitsではVNet 1,000、VNetあたりsubnet 3,000、VNet peering 500、NSG 5,000、NSG rules 2,000、UDR table 600、route/table 1,000が掲載されている。
現在値はPortalのUsage + quotasだけでなく、az network list-usages / Get-AzNetworkUsageで対象regionを明示して採取する。 quota requestで増やせる値と、service design上のhard limitは別物。上限近傍での運用を前提にせずheadroomとmigration pathを持つ。
quota exhaustionはdeployment failureだけでなくscale-out失敗・DR failover失敗・緊急時のpublic IP/NIC追加不能として顕在化する。
Control plane と Data plane
仕組みと設計上の意味
Azure networkingの上限は、resource inventoryと同じくらい設計の前提条件です。特にsubscriptionを長期間使い回す環境では、VNet/NIC/NSG/public IPなどのリージョン単位使用量が静かに積み上がります。新規deploymentが失敗して初めて発覚すると、障害対応中のscale-outやDR切替と衝突します。
「Limit」は同じ表に並んでいても性質が異なります。support requestやquota APIで調整できるsoft quota、SKU/architectureに紐づくservice limit、1 resource内の構成上限を分けて扱います。設計時にはscope / current usage / limit / adjustable / ownerの5列で台帳化すると、数字だけを転記するより安全です。
| 代表項目（2026-09-11確認） | 上限 | 運用上の意味 |
|---|---|---|
| Virtual networks | 1,000 | subscription / regionのestate分割、landing zone増加時に監視。 |
| Subnets per VNet | 3,000 | 大量delegation/PE用subnetでも、IP設計が先に制約になることが多い。 |
| VNet peerings per VNet | 500 | full-meshではなくhub/Virtual WAN/AVNM等の構造を検討。 |
| Network Security Groups | 5,000 | resource sprawlとpolicy ownershipを同時に管理。 |
| NSG rules per NSG | 2,000 | rule explosionはlimit以前にreviewabilityを損なう。 |
| User-defined route tables | 600 | route table複製設計の増殖に注意。 |
| UDRs per route table | 1,000 | BGP/Firewall/Virtual WANとの責務分担を検討。 |
Operational / decision path
対象scopeと時刻を固定し、read-only evidence → 判断 → change → same testで再検証の順を崩さない。
- 対象subscriptionとregionを固定し、resourceの現在使用量を取得する。
- Microsoft Learnの最新limits表で、その値がどのscopeに適用されるか確認する。
- 計画済み増分・autoscale・blue/green・DR時の同時存在分を加算する。
- soft quotaなら変更申請のlead timeを見積もる。hard limitならarchitectureを分割する。
- 変更後にcurrent usageとremaining headroomを再取得し、監視台帳へ反映する。
設計判断
| 判断点 | 推奨 | 理由 |
|---|---|---|
| Capacity headroom | 通常運用とDR/rollback用の余力を別枠で予約 | 移行中はold/newが同時存在し、steady stateより消費するため |
| Scope | subscription + region + resource typeを必ず記録 | 同じ名称のquotaでもscopeが異なるため |
| Alerting | 使用率だけでなくremaining absolute countを監視 | 小さいquotaでは80%より「残り2」の方が重要 |
| Architecture | hard limit近傍ならquota申請より分割を優先 | 運用複雑性とblast radiusを同時に改善できる場合がある |
確認手順
Azure Portal
- Subscriptions → Usage + quotasで対象provider/regionの現在値を確認。
- 対象service固有のQuota bladeがある場合は同じsubscription/regionで照合。
- Resource Graphで実resource countも取り、quotaカウンタとのsemantic差を確認。
Evidence contract
Read-only first: 以下のCLI/PowerShellは原則として参照系から開始します。コメントでMUTATINGと示した操作は、必要性・scope・rollbackを確認した後にのみ実行します。
# read-only: regionを明示
az network list-usages --location japaneast -o table
# inventory側の実数も比較
az graph query -q "Resources | where type startswith 'microsoft.network/' | summarize count() by type | order by count_ desc" -o tableGet-AzNetworkUsage -Location japaneast |
Select-Object ResourceType, CurrentValue, Limit
Search-AzGraph -Query "Resources | where type startswith 'microsoft.network/' | summarize count() by type | order by count_ desc"障害切り分け
| 症状 | 疑う点 | 証拠 | 次の確認 |
|---|---|---|---|
| DeploymentがQuotaExceeded | 対象regionのcurrent/limit、resource provider error detail | az network list-usages + Activity Log | どのresource counterを消費する操作か特定 |
| Portalとinventory countが一致しない | quota counterの定義とARG反映遅延 | Usage blade + Resource Graph + resource list | 削除中/soft-deleted/別typeを切り分け |
| DR時だけ不足 | secondary regionの事前quota未確認 | 両regionのusage snapshot | failover時同時存在数で再計算 |
| 申請しても増えない | hard limit/unsupported offer | Learn limits表 + support response | architecture分割またはSKU変更 |
変更・rollback
- quota increase自体を「容量設計の代替」にしない。増枠後もtarget operating rangeを決める。
- 大規模deleteで使用量を下げる場合はresource dependencyとrollback windowを確認し、quotaだけを理由に即削除しない。
- subscription splitを行う場合はRBAC、Policy、DNS、peering、logging、billing ownershipまで同時に移行設計する。
- 変更前後のUsage snapshotを保存し、rollback時にold/new双方が収まるか確認する。