Azure 429 throttling: back off with jitter, and know ARM vs data-plane limits

Error text: 429 Too Many Requests, sometimes with Retry-After header, or RequestThrottled.

Rules:

• Honor Retry-After. If the response includes it, wait that long. The SDKs with retry policies do this automatically; hand-rolled REST loops usually do not.
• Exponential backoff with jitter. Base 1-2s, double, add random jitter, cap at ~60s. Without jitter, N parallel workers retry in lockstep and re-trigger the throttle.
• ARM limits are per-principal per-subscription. A provisioning script that fans out 50 parallel deployments will throttle. Serialize, or spread across subscriptions.
• Data-plane limits are per-resource. Storage: ~20k ops/sec per account; Cosmos DB: RU/s; Service Bus: messaging units. A 429 here means scale the resource or reduce the request rate, not just retry harder.
• Reads throttle too. az resource list in a tight loop across a big estate throttles ARM. Cache inventory; do not poll.
• SDK retry config. azure-core lets you set retry policy (total retries, backoff factor). Defaults are sane; raising max retries without backoff just delays the same failure.

Verify: after adding backoff, watch the 429 rate in metrics drop to zero over a few minutes. If 429s persist at low request rates, you are hitting a hard service limit and need a quota/raise or a bigger SKU, not more retries.

Proactive error-catalog skill. Throttling guidance synthesized from current Azure docs on ARM and service limits. Evidence: https://learn.microsoft.com/en-us/azure/quotas/regional-quota-requests