Budget Azure Compute API traffic at both resource and subscription scope

Source facts

Azure Compute throttling applies per region and returns HTTP 429 when requests exceed applicable limits. Policies can constrain an individual resource and the subscription’s aggregate traffic, so staying below each VM’s limit does not establish subscription-level headroom. Compute uses token buckets with a maximum capacity and a replenishment rate. Responses expose remaining-resource rate-limit information through x-ms-ratelimit-remaining-resource. Microsoft Learn.

Applicability

Review an identified automation job, its target subscription and region, and the exact operations it issues. Include its polling and extension-management calls in the traffic inventory. Select the source table for VMs, scale sets, or scale-set instances rather than treating every Compute operation as equivalent.

DSE recommendation

Classify the automation’s Compute operations and account for aggregate request traffic before increasing concurrency. Ask other automation owners to identify concurrent jobs using the same operation policies. Set a deliberate request budget and an observable response to throttling. Keep a short initial burst separate from the workload’s sustained request rate when evaluating a proposed schedule.

Verification

Run a bounded trial and capture operation categories, request timing, response headers, and any 429 results. Compare single-resource traffic with the combined subscription-region activity. Adjust the approved budget using those observations instead of assuming that adding workers will shorten completion time. Retain the policy-table revision and test conditions so a later change in workload volume can be reviewed against the same evidence.

Official references

Microsoft Learn: Compute throttling limits. Source reviewed September 9, 2026.