Share via

Safe limits for Azure VNet modification via REST API / SDK (large configurations)

Eduardo Palou Hervias 0 Reputation points Microsoft Employee
2026-06-24T08:25:43.27+00:00

Hello.

We are working with Azure VNets that have a relatively high number of configurations (multiple peerings, subnets, and associated resources).

We are planning to update these VNets programmatically (via REST API / SDK) to add summarizedGatewayPrefixes.

However, when exporting the VNet configuration, some of these VNets result in very large JSON payloads (over ~50k lines).

We would like to understand if there are any known limitations or best practices related to modifying VNets of this size.

Specifically:

  1. Are there any documented limits (payload size, request size, or complexity) when performing PUT/PATCH operations on VNets through REST API or SDK?
  2. Can large VNet configurations lead to issues such as timeouts, partial updates, or inconsistencies during deployment?
  3. Is there any recommended approach to safely update properties like summarizedGatewayPrefixes without sending the full VNet definition (e.g., partial updates or alternative APIs)?
  4. Are there known best practices for handling large-scale VNets to avoid deployment or update failures?

Any guidance or insight from Microsoft engineering or documentation would be highly appreciated.

Thanks

Eduardo

Azure Virtual Network
Azure Virtual Network

An Azure networking service that is used to provision private networks and optionally to connect to on-premises datacenters.

0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Alex Burlachenko 22,925 Reputation points MVP Volunteer Moderator
    2026-06-24T14:51:12.1533333+00:00

    Eduardo Palou Hervias hi, thx for sharing urs issue here at Q&A portal,

    For VNets, I’d avoid doing full-resource PUT with a huge exported JSON unless u really have to.

    ARM PUT is normally a full replace-style update. So if ur payload is huge, stale, or missing server-managed fields, u can get weird failures or accidentally overwrite parts of the VNet config. Not fun, esp w/ peerings/subnets attached. Safer move is use the smallest scoped API that updates only what u need. If summarizedGatewayPrefixes is exposed on the virtual network resource in ur api-version, use PATCH if supported by that Network RP version, or use SDK/CLI cmd that sends a minimal model instead of replaying the full export. I’d also use If-Match / ETag handling so u don’t overwrite someone else’s change. Read VNet, keep the ETag, patch/update, then re-read and verify. https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources

    For large VNets, expect long-running Network RP ops. Don’t assume timeout means failure. Track the Azure-AsyncOperation / operation result and check provisioning state after. Network updates can take time even when the payload is valid.

    test on a cloned/non-prod VNet shape first, update one VNet at a time, take the current config backup, avoid parallel subnet/peering changes during the same window, and log correlation IDs for every request. I don’t know of a clean public doc that says ‘VNet PUT max is X lines of JSON’. The real limit is usually ARM/request payload size + Network RP validation/operation time, not line count. 50k lines is a smell tho. Means u should not round-trip the full export unless MS networking confirms that’s the intended path.

    https://learn.microsoft.com/en-us/rest/api/virtualnetwork/virtual-networks so, best ask to MS Networking would be what api-version supports partial update for summarizedGatewayPrefixes, and whether the Network RP team recommends PATCH/minimal update vs full VNet PUT for large VNet configs.

    rgds,

    Alex

    &

    If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.