Throttling and service limits to consider for testing
As a developer, you want to test your application before releasing it to production. When testing applications protected by the Microsoft identity platform, you should set up an Azure Active Directory (Azure AD) environment and tenant to be used for testing.
Applications that integrate with Microsoft identity platform require directory objects (such as app registrations, service principals, groups, and users) to be created and managed in an Azure AD tenant. Any production tenant settings that affect your app's behavior should be replicated in the test tenant. Populate your test tenant with the needed conditional access, permission grant, claims mapping, token lifetime, and token issuance policies. Your application may also use Azure resources such as compute or storage, which need to be added to the test environment. Your test environment may require a lot of resources, depending on the app to be tested.
In order to ensure reliable usage of services by all customers, Azure AD and other services limit the number of resources that can be created per customer and per tenant. When setting up a test environment and deploying directory objects and Azure resources, you may hit some of these service limits and quotas.
Azure AD, Microsoft Graph, and other Azure services also limit the number of concurrent calls to a service or limit the amount of compute load per customer in order to prevent overuse of resources. This is a practice known as throttling and ensures that Azure services can handle usage and incoming requests without service outages. Throttling can occur at the application, tenant, or entire service level. Throttling commonly occurs when an application has a large number of requests within or across tenants. At runtime, your application can read or update Azure AD directory objects through Microsoft Graph as part of it's business logic. For example, read or set user attributes, update a user’s calendar, or send emails on behalf of the user. While running, your application could also deploy, access, update, and delete Azure resources as well. During testing, your application could hit these runtime throttling limits and the previously mentioned service limits while deploying resources or directory objects.
Azure AD service limits relevant to testing
The following table lists Azure AD service limits to consider when setting up a test environment or running tests.
|Tenants||A single user can create a maximum of 200 directories.|
|Application manifest||A maximum of 1200 entries can be added in the Application Manifest.|
|Azure AD roles and permissions||
Throttling limits relevant to testing
The following global Microsoft Graph throttling limits apply:
|Request type||Per app across all tenants|
|Request type||Per app across all tenants|
|Any||2000 requests per second|
The following table lists Azure AD throttling limits to consider when running tests. Throttling is based on a token bucket algorithm, which works by adding individual costs of requests. The sum of request costs is then compared against pre-determined limits. Only the requests exceeding the limits will be throttled. For more detailed information on request costs, see Identity and access service limits. Other service-specific limits on Microsoft Graph can be found here.
|Limit type||Resource unit quota||Write quota|
|application+tenant pair||S: 3500, M:5000, L:8000 per 10 seconds||3000 per 2 minutes and 30 seconds|
|application||150,000 per 20 seconds||70,000 per 5 minutes|
|tenant||Not Applicable||18,000 per 5 minutes|
The application + tenant pair limit varies based on the number of users in the tenant requests are run against. The tenant sizes are defined as follows: S - under 50 users, M - between 50 and 500 users, and L - above 500 users.
What happens when a throttling limit is exceeded?
Throttling behavior can depend on the type and number of requests. For example, if you have a high volume of requests, all requests types are throttled. Threshold limits vary based on the request type. Therefore, you could encounter a scenario where writes are throttled but reads are still permitted.
When you exceed a throttling limit, you receive the HTTP status code
429 Too many requests and your request fails. The response includes a
Retry-After header value, which specifies the number of seconds your application should wait (or sleep) before sending the next request. Retry the request. If you send a request before the retry value has elapsed, your request isn't processed and a new retry value is returned. If the request fails again with a 429 error code, you are still being throttled. Continue to use the recommended
Retry-After delay and retry the request until it succeeds.
Learn how to setup a test environment.