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

Question

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

Rina Frusman 40

Hi,

There is a list of Azure firewall limitations

The Azure Firewall limits page lists several limits for Azure Firewall and Firewall Policy. For example:

Rule limits 20,000 unique source/destinations in network rules....
Total size of rules within a single Rule Collection Group 1 MB for Firewall policies created before July 2022 2 MB for Firewall policies created after July 2022
IP addresses in IP Groups Maximum of 600 unique IP Groups per firewall policy....

I'd like to know what happens in practice when one of these limits is reached or exceeded:

Enforcement: Is the limit a hard block? Will Azure reject the deployment or update (portal, API) with a validation error, or can a policy go over the limit?
Impact if exceeded: If a policy can go over the limit, what is the effect? For example, slower rule processing or throughput, higher latency, failed or stuck provisioning, or rules that are silently ignored?
Monitoring: Is there a supported way to track how close a policy is to these limits, such as a metric, Azure Resource Graph query or API property?

Thanks in advance for any documentation references or real-world experience.

0 comments

2 answers

Your answer

Answer 1

@Rina Frusman I hope you are doing well today, Welcome to Microsoft Q&A

The key distinction is that not all Azure Firewall limits have the same enforcement behavior.

20,000 unique source/destination combinations in network rules is documented as a soft limit. Exceeding it can affect traffic processing and increase latency; it is not documented as an automatic configuration rejection. Microsoft recommends tracking the count through Firewall Policy Analytics > Insights and monitoring the Firewall Latency Probe metric.

2,000 rule collections is a documented Resource Manager limitation. Microsoft specifically states that creating more than 2,000 NAT, Application, or Network rule collections results in an error.

Other limits, such as 2 MB Rule Collection Group size, 600 IP Groups, and 250 public IP addresses, are documented service limits, but Microsoft does not specify the exact portal/API failure behavior for every individual limit. Therefore, I would not assume that all of them fail in the same way.

For monitoring, Policy Analytics is the supported way to track the network-rule count. For runtime impact, establish a baseline for Firewall Latency Probe and investigate sustained increases, particularly as the policy approaches the documented rule limits.

One important point: the 20,000 limit is not simply the number of rules. Microsoft calculates unique source/destination combinations using sources, destinations, IP Groups, protocols, and destination ports. Consequently, a relatively small number of rules can consume a significant portion of the limit.

Microsoft references:

https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits#azure-firewall-limits

https://learn.microsoft.com/en-us/azure/firewall/firewall-best-practices

https://learn.microsoft.com/en-us/azure/firewall/firewall-known-issues

If this answer helped clarify the platform capabilities and save you troubleshooting time, please consider marking it as Accepted. This helps others in the community find similar solutions.

Answer 2

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.

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.
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.
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.
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.
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: