Is there an API to read the Azure Firewall Policy “Unique source/destination” count shown in Policy analytics?

Microsoft does not publicly document a REST API, SDK method, Resource Graph field, or ARM property that returns the Policy Analytics “Unique source/destination” counter directly; automation must currently read the rule collection groups and calculate an estimate.

What is publicly documented

The documented limit is 20,000 unique source-destination combinations in network rules, calculated as:

IP protocols
× source IP addresses
× destination IP addresses
× ceil(effective destination ports / 14)

The limits documentation also identifies Policy analytics → Insights as the place to view the resulting count.^1^

Therefore:

• Only network rules are part of this documented formula; application and NAT/DNAT rules are not.
• Rules inherited from a parent policy contribute to the child policy’s 20,000 limit.^2^
• An IP Group is treated as one address when used in a network rule.^3^
• The public documentation does not specify the portal’s normalization or deduplication algorithm. Your observation that identical rules are counted once may describe current portal behavior, but it should not be treated as a stable, documented contract.

Reading the inputs programmatically

The ARM schema exposes rule collection groups and the inputs required for network rules: ipProtocols, sourceAddresses, sourceIpGroups, destinationAddresses, destinationIpGroups, and destinationPorts. It does not expose the computed Policy Analytics count.^4^

This Azure Resource Graph query returns all rule collection groups under one Firewall Policy:

POLICY_ID="/subscriptions/[Subscription ID] ID]/resourceGroups/[Resource Group] Group]/providers/Microsoft.Network/firewallPolicies/<policy>"

az graph query -q "
resources
| where type =~ 'microsoft.network/firewallpolicies/rulecollectiongroups'
| where id startswith '${POLICY_ID}/ruleCollectionGroups/'
| project id, name, properties
" --first 1000 -o json > rule-groups.json

Flatten the returned rules and retain network rules:

jq '[
  .data[].properties.ruleCollections[]?.rules[]?
  | select(.ruleType == "NetworkRule")
  | {
      protocols: (.ipProtocols // []),
      sources: ((.sourceAddresses // []) + (.sourceIpGroups // [])),
      destinations: ((.destinationAddresses // []) +
                     (.destinationIpGroups // [])),
      ports: (.destinationPorts // [])
    }
]' rule-groups.json

Repeat that query for every parent policy in the inheritance chain and combine the network rules before calculating the total. The public material supplied here does not identify the exact parent-reference property, so inspect the policy resource JSON rather than hard-coding an assumed property name:

az resource show --ids "$POLICY_ID" -o json

Calculation caveats

A basic arithmetic function is straightforward once the inputs have been normalized:

static long RuleCost(
    int protocolCount,
    int sourceCount,
    int destinationCount,
    int effectivePortCount)
{
    var portGroups = (effectivePortCount + 13L) / 14L;
    return protocolCount * (long)sourceCount
         * destinationCount * portGroups;
}

effectivePortCount is the number of destination ports represented by the rule—not necessarily the number of strings in destinationPorts. Public documentation does not fully define how the Policy Analytics backend expands:

• port ranges or *;
• protocol Any;
• CIDRs, address ranges, service tags, or destination FQDNs;
• overlapping addresses or IP Groups;
• semantically identical rules.

For an estimator, either normalize those forms under explicitly documented assumptions or reject them and report that exact portal parity cannot be guaranteed. Do not silently count each range, wildcard, or CIDR as one effective port/address unless that is the policy you intentionally selected.

Roadmap

There is no publicly documented roadmap commitment or ETA for an API exposing this counter. The Policy Analytics documentation describes the portal feature and its analytics capabilities but does not announce such an API.^5^

For a supported requirement for exact parity, submit an Azure support request or feature request and ask specifically for a stable, documented Policy Analytics metric/API rather than relying on an undocumented portal backend.

References

1. Azure subscription and service limits, quotas, and constraints
2. Azure Firewall rule limits
3. Architecture best practices for Azure Firewall
4. Microsoft.Network firewallPolicies/ruleCollectionGroups 2024-07-01 (deployment-language-arm-template)
5. Azure Firewall Policy Analytics | Microsoft Learn