FirewallPolicyRuleCollectionGroups.createOrUpdate — ~25 polls and ~4 minutes

Question

FirewallPolicyRuleCollectionGroups.createOrUpdate — ~25 polls and ~4 minutes

Dvora Fridman 0

Hi,

We provision Azure Firewall Policy rules programmatically and see a consistent ~4 minute wall-clock cost to update a single rule collection group.

The PUT itself is accepted in about a second; the rest is the long-running operation.

I'd like to understand what that time represents.

## Setup

Java, using the Azure SDK for Java:

com.azure.resourcemanager:azure-resourcemanager-network : 2.50.0

com.azure:azure-core : 1.55.3

com.azure:azure-identity : 1.12.2

## Setup

Authentication is ClientSecretCredential against a service principal, with a

custom HttpPipeline (BearerTokenAuthenticationPolicy + RetryPolicy +

HttpLoggingPolicy), then:

NetworkManager.authenticate(pipeline, azureProfile)

  .serviceClient()

  .getFirewallPolicyRuleCollectionGroups()

The methods we call:

FirewallPolicyRuleCollectionGroupsClient.list(resourceGroupName, policyName)

FirewallPolicyRuleCollectionGroupsClient.get(resourceGroupName, policyName, groupName)

FirewallPolicyRuleCollectionGroupsClient.createOrUpdate(

  resourceGroupName, policyName, groupName, FirewallPolicyRuleCollectionGroupInner)

i.e. the underlying REST call is

PUT .../firewallPolicies/{policy}/ruleCollectionGroups/{group}

Since the SDK exposes no per-rule endpoint, adding or editing a single network rule

means a read-modify-write of the whole rule collection group.

## What we see

A single rule collection group update, adding one network rule:

GET ruleCollectionGroups (list) 0.5 s

GET ruleCollectionGroups/{group} 0.5 s

PUT ruleCollectionGroups/{group} -> accepted 1.1 s

~25 poll GETs at 10 s intervals 4 m 02 s

total 4 m 17 s

So the API calls account for ~2.6 s, and the remaining ~4 minutes is the SDK

polling provisioningState until the operation reports success.

## Questions

Is ~4 minutes the expected completion time for a rule collection group createOrUpdate, or does it suggest something misconfigured on our side?
Does the long-running operation complete only once the change has been rolled out to the firewall data plane, rather than when the control plane has accepted it?
Does the duration scale with the number of Azure Firewalls attached to the policy, or with the total number of rules already in the policy?
Is there a supported way to get control-plane acceptance without blocking for the full rollout — so a caller can return and verify completion later?

Thanks!

Jose Benjamin Solis Nolasco 12,281 Reputation points Volunteer Moderator

2026-08-26T12:37:47.36+00:00
Welcome to Microsoft Q&A.

@Dvora Fridman I hope you are doing well.

What you are observing is consistent with the createOrUpdate operation being treated as a long-running operation (LRO). The initial PUT can be accepted quickly, while the Azure Resource Manager operation continues until the rule collection group's provisioningState reaches Succeeded.

Microsoft's REST API documentation confirms that FirewallPolicyRuleCollectionGroups.createOrUpdate returns an Azure-AsyncOperation header for the asynchronous operation, and the resource exposes a provisioningState property. The documented states include Creating, Updating, Succeeded, Failed, and Canceled.

https://learn.microsoft.com/en-us/rest/api/firewall/firewall-policy-rule-collection-groups/create-or-update

I would therefore not interpret the ~4 minutes by itself as evidence of a misconfiguration.

........................................................................................................................................................................................................................................

Regarding your questions:

1. Is ~4 minutes expected?

There is no Microsoft-published fixed completion time that I can find for a rule collection group update. Therefore, I would not consider 4 minutes a documented SLA or guaranteed normal duration.

If the operation consistently completes successfully after approximately four minutes, the important distinction is that the PUT is succeeding and the service is completing the asynchronous provisioning operation.

2. Does completion mean that the change has reached the firewall data plane?

Microsoft does not publicly document the internal stages represented by the provisioningState, so I would avoid assuming that the polling period corresponds specifically to data-plane rollout.

The safe interpretation is that the Azure resource operation has not yet reached its final Succeeded state.

3. Does the duration depend on the number of firewalls or rules?

I am not aware of a documented formula that correlates createOrUpdate duration with either the number of attached Azure Firewalls or the number of rules in the policy.

Therefore, I would not assume that either factor is responsible without controlled testing or confirmation from the Azure Firewall service team.

4. Can the caller avoid waiting for the complete operation?

Yes. The Azure CLI supports --no-wait for the rule collection group update operation:

https://learn.microsoft.com/en-us/cli/azure/network/firewall/policy/rule-collection-group

For example:

az network firewall policy rule-collection-group update \

--resource-group "<resource-group>" \

--policy-name "<firewall-policy>" \

--name "<rule-collection-group>" \

--no-wait

This allows the client to submit the operation without waiting for the long-running operation to finish.

You can then check the rule collection group's provisioning state separately. The REST API exposes this state through the resource:

properties.provisioningState

with values such as Updating and Succeeded.

https://learn.microsoft.com/en-us/rest/api/firewall/firewall-policy-rule-collection-groups/list

For your Java implementation, the equivalent approach would be to use the asynchronous operation exposed by the Azure SDK rather than waiting synchronously for completion, depending on the specific SDK method available in version 2.50.0.

One additional consideration is your read-modify-write approach. Because createOrUpdate replaces the rule collection group resource, make sure your automation preserves the complete existing rule collection group when adding a single rule. This is particularly important when multiple automation processes can modify the same policy concurrently.

In summary, the ~4-minute polling period appears to be the ARM long-running operation completing the resource update. Microsoft does not currently document the exact internal reason for that duration or provide a guaranteed completion time. If you need a non-blocking workflow, --no-wait or asynchronous handling is the appropriate approach.

Microsoft documentation

Firewall Policy Rule Collection Groups – Create or Update https://learn.microsoft.com/en-us/rest/api/firewall/firewall-policy-rule-collection-groups/create-or-update

Azure CLI – Firewall Policy Rule Collection Group https://learn.microsoft.com/en-us/cli/azure/network/firewall/policy/rule-collection-group

Firewall Policy Rule Collection Groups – List https://learn.microsoft.com/en-us/rest/api/firewall/firewall-policy-rule-collection-groups/list

Azure Firewall Policy rule sets https://learn.microsoft.com/en-us/azure/firewall/policy-rule-sets

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.

1 answer

Your answer

Answer 1

Hello Dvora Fridman,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that the initial PUT is accepted in about one second, but the Java FirewallPolicyRuleCollectionGroupsClient.createOrUpdate(...) call continues polling for approximately four minutes.

This does not currently indicate a client-side misconfiguration. The create/update REST operation is asynchronous and returns Azure-AsyncOperation and Retry-After headers. The synchronous Java createOrUpdate(...) method waits for that operation to finish. Microsoft also documents that individual Azure Firewall Policy changes can take several minutes to deploy, so the observed four-minute duration is consistent with documented behavior, although Microsoft does not publish a fixed completion-time SLA for this operation.

For a nonblocking submission, use the Java SDK’s beginCreateOrUpdate(...) method:

SyncPoller<
    PollResult<FirewallPolicyRuleCollectionGroupInner>,
    FirewallPolicyRuleCollectionGroupInner
> poller =
    client.beginCreateOrUpdate(
        resourceGroupName,
        firewallPolicyName,
        ruleCollectionGroupName,
        parameters
    );

Ensure that you:

Replace createOrUpdate(...) with beginCreateOrUpdate(...).
Poll using the returned handle.
Persist the resource identifiers and query the RCG.
Confirm the returned RCG contains the intended rule, then run a controlled matching traffic test.
Batch frequent updates where suitable, if numerous incremental edits are being made, evaluate Draft + Deployment.

This returns a poller instead of waiting for completion. In the same process, call poller.poll() periodically and obtain the final result only after the status is SUCCESSFULLY_COMPLETED. The Java client documents both beginCreateOrUpdate(...) and beginCreateOrUpdateAsync(...) for this purpose.

If a different worker or a later process must verify completion, persist the policy and Rule Collection Group identifiers, call get(...), and inspect properties.provisioningState. A Succeeded state confirms completion of the resource-provider operation. If actual traffic enforcement is business-critical, verify it separately with a controlled flow matching the changed rule rather than assuming that provisioning state alone proves the observed data-plane result.

Microsoft does not publish a formula showing how this duration varies with total rule count or the number of firewalls using the policy, so no linear scaling relationship should be assumed. For frequent changes, consider Azure Firewall Draft + Deployment to batch multiple edits into one deployment, subject to its documented limitations.

You can Open a support request via your Azure Portal or contact priority customer support (PCS), if it becomes stuck or fails, or if Succeeded is followed by a reproducible failure to enforce the updated rule; this might depend on your support level.

I hope this is helpful. Please! Do not hesitate to let me know if you have any other questions, steps or clarifications.

Please do not close the thread by upvoting and accepting the answer if any part of it is helpful.