What happens when Azure Firewall Policy limits are exceeded? Enforcement, performance and failure behavior

What is documented today is mixed: some Azure Firewall limits are clearly hard limits, while the 20,000 unique source/destination network-rule limit is documented as a performance-related soft limit.

1. Enforcement
   • 20,000 unique source/destination combinations in network rules: this is treated as a soft limit. Documentation states that exceeding it can affect traffic processing and latency rather than stating that deployment is blocked. Microsoft Q&A also states this limit is related to latency/performance and that inherited parent-policy rules count toward the same total.
   • 2,000 rule collections: this is documented as a current limitation. Creating more than 2,000 NAT/Application/Network rule collections results in an error.
   • DNAT maximum external destinations (250): documented as a maximum. If more than 250 are needed, the documented guidance is to add another firewall in a separate virtual network.
   • Rule Collection Group size limit (1 MB before July 2022, 2 MB after July 2022), 600 unique IP Groups per firewall policy, 250 public IPs, and similar entries are documented as service limits, but the provided material does not describe the exact failure mode for each one at portal/API level.
   • There is also a documented case where removing RuleCollectionGroups using ARM templates isn't supported and results in failure.
2. Impact if exceeded
   • For the 20,000 unique source/destination network-rule limit, the documented effect is performance degradation:
     • traffic processing can be affected
     • latency can increase
     • firewall performance can degrade
   • Best-practices guidance recommends keeping within this limit and monitoring latency. A proxy recommendation is to keep Firewall Latency Probe under 20 ms during peak hours.
   • For high throughput, high connection count, and IDPS Alert + Deny mode, the documented impact is also performance-related, including latency increase and possible SNAT port exhaustion.
   • For hard/current limitations such as more than 2,000 rule collections, the documented behavior is failure rather than silent ignore.
   • The provided material does not document a general rule that excess rules are silently ignored.
3. Monitoring how close a policy is to limits Supported options in the provided material are:
   • Policy Analytics: explicitly recommended to identify policy-limit issues, improper rules, and IP group usage. The limits page also says the Firewall Policy network rule count can be tracked in policy analytics under the Insights tab. Microsoft Q&A further notes that the Policy Limits counter in Policy Analytics reflects the count relevant to the 20K limit, including inherited parent-policy rules.
   • Azure Firewall metrics: use Firewall Latency Probe to watch for latency impact. Guidance says to establish a baseline, expect occasional spikes, and investigate if latency exceeds 3x baseline or persists. It also explicitly says to check whether network rules are within the 20K rule limit.
   • Resource Health: useful for operational state after impact occurs. States include Available, Degraded, Unavailable, and Unknown. Degraded means reduced capacity or resiliency and intermittent problems might occur.
4. Practical interpretation by limit type
   • Soft/performance limit: the 20K unique source/destination network-rule limit. Policy can exceed it, but performance and latency can suffer.
   • Documented hard/current limitation: examples include 2,000 rule collections and unsupported ARM-template removal of RuleCollectionGroups. These fail rather than degrade gracefully.
   • Other listed maxima: documented as limits, but the provided material does not specify for each whether enforcement is pre-validation, provisioning failure, or runtime rejection.
5. Design options when approaching limits
   • Use IP Groups to reduce unique source/destination expansion.
   • Place frequently used rules early to reduce processing latency for large rule sets.
   • Consider Application Rules where appropriate to reduce outbound Network Rules.
   • Deploy additional firewalls when more rule capacity is needed. However, if using parent-child policies, inherited parent rules still count toward the child firewall’s 20K unique source/destination total.

References:

• Azure subscription and service limits, quotas, and constraints
• Best practices for Azure Firewall performance
• Architecture best practices for Azure Firewall
• Azure Firewall known issues and limitations
• Azure Firewall monitoring data reference
• Azure Firewall rule limits - Microsoft Q&A