Understanding ARM throttling limits applicable for Usages/Quotas List API

Question

Understanding ARM throttling limits applicable for Usages/Quotas List API

Pawan Rawal 5

Hi,

I am using the following ARM APIs to retrieve usage and quota information for resources under the Microsoft.Compute provider across multiple subscriptions.

While using them I am getting throttling 429 errors.

--------------------------------------------------------------------------------
RESPONSE 429: 429 Too Many Requests
ERROR CODE: RequestThrottled
--------------------------------------------------------------------------------
{
  "error": {
    "code": "RequestThrottled",
    "message": "The request was throttled, please retry after 300 seconds."
  }
}

I tried printing the response headers from the response and I see that I am not exceeding the subscription or global limits based on these values. Sample values shown below.

headers.X-Ms-Ratelimit-Remaining-Subscription-Global-Reads[0]: 3749 
headers.X-Ms-Ratelimit-Remaining-Subscription-Reads[0]: 249

I also reviewed this article on throttling: Azure Throttling and Request Limits. Based on this, my understanding is that throttling limits apply per subscription, service principal, and operation type. The response headers indicate that these limits are not being exceeded. Are there any additional limits at the provider or tenant level that might be reached?

Anusree Nashetty 6,715 Reputation points Microsoft External Staff Moderator

2025-03-19T06:39:04.31+00:00

Hi Pawan Rawal,

Your understanding is correct that throttling limits in Azure apply at the subscription, service principal, and operation type levels. There are other factors that might apply at the provider or tenant level.

Azure enforces rate limits at the resource provider level, which are not reflected in the X-Ms-Ratelimit-Remaining-Subscription-Reads headers. To check if provider-level throttling is occurring, check the headers if it shows low or zero remaining reads, then your API calls are being throttled at the provider level.

Azure tenant-level limits that apply across all subscriptions within a tenant. These limits are typically higher but can be reached if you are making a large number of requests across multiple subscriptions. Check the following headers, if these values are low, your entire tenant is being throttled X-Ms-Ratelimit-Remaining-Tenant-Reads, X-Ms-Ratelimit-Remaining-Tenant-Global-Reads

Azure has migrated to a regional throttling model, where limits are applied per region. If your requests are targeting resources in a specific region, you might hit regional throttling limits. Distribute your requests across multiple regions to avoid hitting regional limits.
Regional throttling documentation

If you have any further queries, let me know. If the information is helpful, please click on Upvote.
Pawan Rawal 5 Reputation points

2025-03-19T07:06:38.06+00:00

Hey thanks for your reply. A few follow up questions.

To check if provider-level throttling is occurring, check the headers if it shows low or zero remaining reads, then your API calls are being throttled at the provider level.

What headers are you referring to? Are you referring to the X-Ms-Ratelimit-Remaining-Subscription-Reads header here?

Azure tenant-level limits that apply across all subscriptions within a tenant. These limits are typically higher but can be reached if you are making a large number of requests across multiple subscriptions. Check the following headers, if these values are low, your entire tenant is being throttled X-Ms-Ratelimit-Remaining-Tenant-Reads, X-Ms-Ratelimit-Remaining-Tenant-Global-Reads

What are these limits, and are they documented anywhere? The tenant-level read headers you mentioned were not returned when I called the Usages List and Quotas List APIs. Are you certain these headers are always provided for the APIs I linked above?

Azure has migrated to a regional throttling model, where limits are applied per region. If your requests are targeting resources in a specific region, you might hit regional throttling limits. Distribute your requests across multiple regions to avoid hitting regional limits.

Yes, I am aware of this and have been limiting requests to one per subscription per second, yet we are still experiencing throttling. We are making these requests concurrently on behalf of a customer with over 300 subscriptions. However, the rate remains at only one request per second for any given subscription. I need to understand the tenant-level limits to design a system that operates within those constraints.
Anusree Nashetty 6,715 Reputation points Microsoft External Staff Moderator

2025-03-19T12:06:41.96+00:00
Hi Pawan Rawal,

As for your follow-up questions,

To determine if provider-level throttling is occurring, you should inspect the following response headers. These headers indicate the remaining read quotas at the provider level. If these values are low or zero, it suggests that your API calls are being throttled by the resource provider.

X-Ms-Ratelimit-Remaining-Provider-Reads X-Ms-Ratelimit-Remaining-Provider-Global-Reads

The following headers indicate tenant-level throttling:

X-Ms-Ratelimit-Remaining-Tenant-Reads X-Ms-Ratelimit-Remaining-Tenant-Global-Reads

Please check this for limits: https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/request-limits-and-throttling#subscription-and-tenant-limits

These headers are not always returned in API responses. Their presence depends on the specific API being called, the throttling tier being enforced (e.g., subscription, provider, tenant, or region).

Use the Retry-After header to determine how long to wait before retrying a request. This will distribute requests across regions and implement exponential backoff.

Even if you’re limiting requests to one per subscription per second, the cumulative request rate across 300+ subscriptions can still be significant: 1 request per second per subscription × 300 subscriptions = 300 requests per second across the tenant. This cumulative rate might exceed tenant-level limits, even if individual subscription-level headers show remaining capacity.

If you have any further queries, let me know. If the information is helpful, please click on Upvote.
Anusree Nashetty 6,715 Reputation points Microsoft External Staff Moderator

2025-03-20T06:48:26.8066667+00:00

Hi Pawan Rawal,

I have provided information to your question. Please tell us if it was helpful and feel free to reach out to us if you have any further queries. If this is helpful to you, please click on Upvote.
Anonymous

2025-03-24T09:48:39.7833333+00:00

Hi Pawan Rawal,

As per the MS doc son throttling, it applies to subscriptions and tenants. If you are using service principals, they are part of the tenant, and throttling will apply to them as well.

**

Reference**: https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/request-limits-and-throttling#subscription-and-tenant-limits
Arko 4,180 Reputation points Moderator

2025-03-25T08:21:01.9+00:00
Hello Pawan Rawal, your understanding of ARM throttling is mostly correct, but there are some important nuances that might be causing the 429 errors you're seeing — even when the X-Ms-Ratelimit-Remaining-* headers look fine.

In your case, since you're calling the usages list and quotas list APIs for the Microsoft.Compute provider across multiple subscriptions, you might be running into throttling that's not reflected in the standard subscription-level headers.

Even though the headers like X-Ms-Ratelimit-Remaining-Subscription-Reads and Global-Reads are still showing available quota, azure also applies hidden throttling at the API or resource provider level (in this case, Microsoft.Compute and Microsoft.Quota)

So, it’s possible you're hitting a per-API limit specifically for these usage/quota endpoints, especially if you're calling them in a tight loop or concurrently across many subscriptions.

These limits aren’t publicly documented and don’t show up in the standard rate limit headers — which is why the 429 response can be confusing. If you’re using a single service principal to access multiple subscriptions, azure may also throttle based on the overall request volume across the tenant or identity. That means you're potentially hitting a tenant-level ceiling, even though each individual subscription looks okay. Look out for headers like X-Ms-Ratelimit-Remaining-Tenant-Reads or X-Ms-Ratelimit-Remaining-Tenant-Global-Reads. If they’re present and low, that could explain it. But again, in many cases, these limits are enforced even if the headers don’t give you a clear signal.

Please note, Azure has been shifting toward a regional throttling model, which means even if your subscription and global limits are fine, repeated calls to quota APIs in a single region (e.g. East US) could still hit backend throttling.

So, if your requests are region-targeted (or defaulting to a specific region), consider spreading them out or adding delays between calls.

Additonally answering your follow up questions-

“Are you referring to X-Ms-Ratelimit-Remaining-Subscription-Reads when you talk about provider-level throttling?”

Ans- Not exactly. The headers you're seeing:

X-Ms-Ratelimit-Remaining-Subscription-Reads

X-Ms-Ratelimit-Remaining-Subscription-Global-Reads

are subscription-wide rate limit indicators — they don’t tell you anything about resource provider-level or API-specific throttling.

Unfortunately, Azure doesn’t expose separate headers for provider-level or operation-specific throttling, even though those limits are enforced behind the scenes. So yes, you're not missing any headers. This is one of the key challenges as you can be throttled at the provider/API level without visible signals in the headers.

“Are those tenant-level headers (X-Ms-Ratelimit-Remaining-Tenant-Reads, etc.) returned for Usages/Quotas APIs?”

Ans- In practice, no, not always and not for the Usages/Quotas List APIs, based on what we’ve observed too. These headers are:

Inconsistently returned across different ARM APIs

Sometimes only present in responses from high-volume or management-plane APIs (like deployments, policy, or RBAC)

So you're correct for the Usages List and Quotas List APIs, those tenant-level headers are typically not included.

They’re mentioned in some Microsoft docs and GitHub discussions but not universally implemented and there’s no official public documentation that defines tenant-level rate limits in detail.

“What are the actual tenant-level limits? Are they documented?”

Ans- No tenant-level limits are not publicly documented by Microsoft.

“We’re making one request per subscription per second (300+ subscriptions), but still throttled — how can we stay within tenant-level limits?”

Ans- Even though 1 request/sec/subscription sounds modest, at 300 subscriptions, that's still 300 requests/sec hitting ARM, possibly from the same Service principal / Region / Resource provider (Microsoft.Compute) / Tenant

This aggregate rate may exceed the internal per-tenant or per-identity thresholds, especially if the APIs have lower backend limits (e.g., 100-200 calls/sec across a tenant for certain provider APIs).

There’s evidence that some ARM APIs (including /usages and /quotas) have backend thresholds of around 50–100 requests/sec across a tenant or SPN, even if per-subscription headers look fine.
Arko 4,180 Reputation points Moderator

2025-03-25T08:28:34.6466667+00:00

I can see in the document shared by Venkat V that throttles apply at both the subscription and tenant levels, with distinct limits for read, write, and delete operations. If you're using a service principal, it falls under tenant-level limits, so your total read request rate across all subscriptions (even if 1/sec/sub) can still exceed the tenant-wide 25/sec limit and cause throttling (429s). You mentioned you're calling the APIs at 1 request/sec per subscription, across 300+ subscriptions — that’s 300+ read requests/sec from a single tenant/service principal. That exceeds the tenant-level read limit of 25/sec (with a burst capacity of 250), which now confirms the root cause of your throttling.

What can you try?

Throttle globally to stay under 25 reads/sec across all subscriptions for that tenant or service principal. Consider spreading requests over time, batching, or using multiple service principals (with appropriate identity separation). Implement exponential backoff and respect the Retry-After header to prevent cascading retries.
Arko 4,180 Reputation points Moderator

2025-03-26T07:54:29.02+00:00

Following up on this. Is your issue resolved?
Arko 4,180 Reputation points Moderator

2025-03-27T06:41:54.9533333+00:00

Kindly confirm if your issue is resolved?
Pawan Rawal 5 Reputation points

2025-03-27T07:22:39.1933333+00:00

Hey Arko and Venkat,

Thank you for your effort in trying to help. However, I don’t understand how my use of the API qualifies as a tenant-level operation when I am making calls per subscription. As I understand it, APIs can be called either at the subscription level or the tenant level, and based on how I am calling the Usage and Quotas API, it should be considered a subscription-level operation, not a tenant-level one. How does using a service principal change this to a tenant-level operation? Is there any documentation on this? Infact, the ARM throttling docs clearly call out

These limits are scoped to the security principal (user or application) making the requests and the subscription ID or tenant ID.
Arko 4,180 Reputation points Moderator

2025-03-28T07:31:13.08+00:00

Hello Pawan Rawal, hope I was able to resolve your query above.

1 answer

Your answer

Anusree Nashetty 6,715 Reputation points Microsoft External Staff Moderator

2025-03-19T06:39:04.31+00:00

Hi Pawan Rawal,

Your understanding is correct that throttling limits in Azure apply at the subscription, service principal, and operation type levels. There are other factors that might apply at the provider or tenant level.

Azure enforces rate limits at the resource provider level, which are not reflected in the X-Ms-Ratelimit-Remaining-Subscription-Reads headers. To check if provider-level throttling is occurring, check the headers if it shows low or zero remaining reads, then your API calls are being throttled at the provider level.

Azure tenant-level limits that apply across all subscriptions within a tenant. These limits are typically higher but can be reached if you are making a large number of requests across multiple subscriptions. Check the following headers, if these values are low, your entire tenant is being throttled X-Ms-Ratelimit-Remaining-Tenant-Reads, X-Ms-Ratelimit-Remaining-Tenant-Global-Reads

Azure has migrated to a regional throttling model, where limits are applied per region. If your requests are targeting resources in a specific region, you might hit regional throttling limits. Distribute your requests across multiple regions to avoid hitting regional limits.
Regional throttling documentation

If you have any further queries, let me know. If the information is helpful, please click on Upvote.
Pawan Rawal 5 Reputation points

2025-03-19T07:06:38.06+00:00

Hey thanks for your reply. A few follow up questions.

To check if provider-level throttling is occurring, check the headers if it shows low or zero remaining reads, then your API calls are being throttled at the provider level.

What headers are you referring to? Are you referring to the X-Ms-Ratelimit-Remaining-Subscription-Reads header here?

Azure tenant-level limits that apply across all subscriptions within a tenant. These limits are typically higher but can be reached if you are making a large number of requests across multiple subscriptions. Check the following headers, if these values are low, your entire tenant is being throttled X-Ms-Ratelimit-Remaining-Tenant-Reads, X-Ms-Ratelimit-Remaining-Tenant-Global-Reads

What are these limits, and are they documented anywhere? The tenant-level read headers you mentioned were not returned when I called the Usages List and Quotas List APIs. Are you certain these headers are always provided for the APIs I linked above?

Azure has migrated to a regional throttling model, where limits are applied per region. If your requests are targeting resources in a specific region, you might hit regional throttling limits. Distribute your requests across multiple regions to avoid hitting regional limits.

Yes, I am aware of this and have been limiting requests to one per subscription per second, yet we are still experiencing throttling. We are making these requests concurrently on behalf of a customer with over 300 subscriptions. However, the rate remains at only one request per second for any given subscription. I need to understand the tenant-level limits to design a system that operates within those constraints.
Anusree Nashetty 6,715 Reputation points Microsoft External Staff Moderator

2025-03-19T12:06:41.96+00:00

Hi Pawan Rawal,

As for your follow-up questions,

To determine if provider-level throttling is occurring, you should inspect the following response headers. These headers indicate the remaining read quotas at the provider level. If these values are low or zero, it suggests that your API calls are being throttled by the resource provider.

X-Ms-Ratelimit-Remaining-Provider-Reads X-Ms-Ratelimit-Remaining-Provider-Global-Reads

The following headers indicate tenant-level throttling:

X-Ms-Ratelimit-Remaining-Tenant-Reads X-Ms-Ratelimit-Remaining-Tenant-Global-Reads

Please check this for limits: https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/request-limits-and-throttling#subscription-and-tenant-limits

These headers are not always returned in API responses. Their presence depends on the specific API being called, the throttling tier being enforced (e.g., subscription, provider, tenant, or region).

Use the Retry-After header to determine how long to wait before retrying a request. This will distribute requests across regions and implement exponential backoff.

Even if you’re limiting requests to one per subscription per second, the cumulative request rate across 300+ subscriptions can still be significant: 1 request per second per subscription × 300 subscriptions = 300 requests per second across the tenant. This cumulative rate might exceed tenant-level limits, even if individual subscription-level headers show remaining capacity.

If you have any further queries, let me know. If the information is helpful, please click on Upvote.
Anusree Nashetty 6,715 Reputation points Microsoft External Staff Moderator

2025-03-20T06:48:26.8066667+00:00

Hi Pawan Rawal,

I have provided information to your question. Please tell us if it was helpful and feel free to reach out to us if you have any further queries. If this is helpful to you, please click on Upvote.
Anonymous

2025-03-24T09:48:39.7833333+00:00

Hi Pawan Rawal,

As per the MS doc son throttling, it applies to subscriptions and tenants. If you are using service principals, they are part of the tenant, and throttling will apply to them as well.

**

Reference**: https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/request-limits-and-throttling#subscription-and-tenant-limits
Arko 4,180 Reputation points Moderator

2025-03-25T08:28:34.6466667+00:00

I can see in the document shared by Venkat V that throttles apply at both the subscription and tenant levels, with distinct limits for read, write, and delete operations. If you're using a service principal, it falls under tenant-level limits, so your total read request rate across all subscriptions (even if 1/sec/sub) can still exceed the tenant-wide 25/sec limit and cause throttling (429s). You mentioned you're calling the APIs at 1 request/sec per subscription, across 300+ subscriptions — that’s 300+ read requests/sec from a single tenant/service principal. That exceeds the tenant-level read limit of 25/sec (with a burst capacity of 250), which now confirms the root cause of your throttling.

What can you try?

Throttle globally to stay under 25 reads/sec across all subscriptions for that tenant or service principal. Consider spreading requests over time, batching, or using multiple service principals (with appropriate identity separation). Implement exponential backoff and respect the Retry-After header to prevent cascading retries.
Arko 4,180 Reputation points Moderator

2025-03-26T07:54:29.02+00:00

Following up on this. Is your issue resolved?
Arko 4,180 Reputation points Moderator

2025-03-27T06:41:54.9533333+00:00

Kindly confirm if your issue is resolved?
Pawan Rawal 5 Reputation points

2025-03-27T07:22:39.1933333+00:00

Hey Arko and Venkat,

Thank you for your effort in trying to help. However, I don’t understand how my use of the API qualifies as a tenant-level operation when I am making calls per subscription. As I understand it, APIs can be called either at the subscription level or the tenant level, and based on how I am calling the Usage and Quotas API, it should be considered a subscription-level operation, not a tenant-level one. How does using a service principal change this to a tenant-level operation? Is there any documentation on this? Infact, the ARM throttling docs clearly call out

These limits are scoped to the security principal (user or application) making the requests and the subscription ID or tenant ID.
Arko 4,180 Reputation points Moderator

2025-03-28T07:31:13.08+00:00

Hello Pawan Rawal, hope I was able to resolve your query above.

Answer 1

Hello Pawan Rawal, you're right that the API endpoints you're calling (/usages and /quotas) are scoped at the subscription level — meaning they require a subscription ID in the URL, and they return usage/quota data per subscription.

However Azure throttling is enforced not just based on the API's URI scope but also based on the identity and rate of total requests coming from that identity.

According to the official ARM throttling documentation:

"These limits are scoped to the security principal (user or application) making the requests and the subscription ID or tenant ID."

This means both subscription- and tenant-level limits can apply simultaneously.

So Why Is a Tenant-Level Limit Being Hit?

Ans- You're using a single service principal to make many calls (300+ calls/sec), even if each is to a different subscription.

Please note, azure applies tenant-level throttling to avoid overload when a single identity floods ARM, even across subscriptions. So even though each call is technically scoped to a subscription, the rate at which they’re being made by a single security principal (your service principal) across the tenant exceeds the tenant-level limits.

enter image description here

That means - you can be throttled per subscription or per tenant and the limits apply per identity (SPN, user, etc.)

So, based on your usage pattern, lots of concurrent subscription-level calls made by one SPN and hence can hit tenant-level limits, especially now that Azure enforces regional and identity-based token bucket throttling (25 req/sec at tenant scope, as per 2024 changes).