Comprendre comment Azure Resource Manager limite les demandes

2025-06-10

Cet article explique comment Azure Resource Manager limite les requêtes. Il vous montre comment suivre le nombre de demandes qui restent avant d’atteindre la limite et comment réagir quand vous avez atteint la limite.

Limitation régionale et algorithme de compartiment de jetons

Microsoft a migré des abonnements Azure vers une architecture de limitation mise à jour depuis 2024. Les limites de limitation sont désormais appliquées par région plutôt que par instance d’Azure Resource Manager. Cette nouvelle architecture utilise un algorithme du seau à jetons pour gérer le débit des API.

Le compartiment de jetons représente le nombre maximal de demandes que vous pouvez envoyer par seconde. Quand vous atteignez le nombre maximal de demandes, le taux de remplissage détermine la vitesse de disponibilité des jetons dans le compartiment.

Ces limites mises à jour facilitent l’actualisation et la gestion de votre quota.

Les limites mises à jour sont les suivantes :

Étendue	Opérations	Taille du compartiment	Taux de remplissage par seconde
Abonnement	lectures	250	25
Abonnement	suppressions	200	10
Abonnement	écritures	200	10
Locataire	lectures	250	25
Locataire	suppressions	200	10
Locataire	écritures	200	10

Les limites d’abonnement s’appliquent par abonnement, par principal de service et par type d’opération. Il existe également des limites d’abonnement générales équivalentes à 15 fois les limites d’un principal de service individuel pour chaque type d’opération. Les limites générales s’appliquent à tous les principaux de service. Les requêtes sont limitées si les limites générales ou celles propres au principal de service ou au locataire sont dépassées.

Les limites peuvent être plus basses pour les clients de versions gratuites ou d’essai.

Par exemple, supposons que vous avez une taille de compartiment de 250 jetons pour les demandes de lecture et que le taux de remplissage est de 25 jetons par seconde. Si vous envoyez 250 demandes de lecture en une seconde, le compartiment est vide et vos demandes sont limitées. Chaque seconde, 25 jetons deviennent disponibles jusqu’à ce que le compartiment atteigne sa capacité maximale de 250 jetons. Vous pouvez utiliser des jetons dès qu’ils sont disponibles.

La lecture de métriques en utilisant l’API */providers/microsoft.insights/metrics contribue considérablement au trafic global d’Azure Resource Manager et elle est la cause courante des événements de limitation des abonnements. Si vous utilisez fortement cette API, nous vous recommandons de basculer vers l’API getBatch. Vous pouvez interroger plusieurs ressources dans une seule requête REST, ce qui permet d’améliorer les performances et de réduire la limitation. Pour découvrir plus d’informations sur la conversion de vos opérations, consultez Migrer de l’API de métriques vers l’API getBatch.

Comment puis-je afficher mes requêtes limitées ?

Pour consulter vos requêtes limitées et les autres métriques du gestionnaire de ressources, voir Accès aux métriques Azure Resource Manager.

Pourquoi la limitation de requêtes est-elle par région et non par instance ?

Parce que différentes régions ont un nombre différent d’instances Resource Manager, la limitation par instance entraîne des performances de limitation incohérentes. La limitation par région rend la limitation cohérente et prévisible.

Comment l’expérience de limitation mise à jour affecte-t-elle mes limites ?

Vous pouvez envoyer plus de demandes. Les demandes d’écriture sont 30 fois supérieures. Les demandes de suppression sont 2,4 fois supérieures. Les demandes de lecture sont 7,5 fois supérieures.

Régulation des tâches en arrière-plan

Les travaux en arrière-plan dans Azure Resource Manager (ARM) sont des tâches automatisées qui s’exécutent en arrière-plan pour prendre en charge les opérations telles que les déploiements de ressources, les diagnostics et la maintenance du système. Ces travaux sont essentiels pour traiter les demandes des utilisateurs et garantir la fonctionnalité de service. Pour maintenir la stabilité et la fiabilité de la plateforme, ARM utilise la limitation des travaux en arrière-plan pour gérer la charge de ces tâches.

Vous pouvez savoir quand la limitation des travaux en arrière-plan se produit si vous recevez le message d’erreur suivant :

The request for subscription '{0}' could not be processed due to an excessive volume of traffic. Please try again later.

Les clients peuvent rencontrer une limitation en raison de travaux en arrière-plan excessifs, qui peuvent être déclenchés par des opérations à haute fréquence ou des activités à l’échelle du système. Bien que les clients n’aient pas de contrôle direct sur la création ou l’exécution de ces travaux, il est important d'être conscient de la limitation potentielle du débit.

Limitation pour les clouds non publics

La limitation se produit à deux niveaux. Azure Resource Manager limite les demandes pour l’abonnement et le locataire. Si la demande se trouve sous les limites de limitation pour l’abonnement et le locataire, le Gestionnaire des ressources achemine la requête vers le fournisseur de ressources. Le fournisseur de ressources applique des limites de limitation adaptées à ses opérations.

Les requêtes sont initialement limitées par ID de principal et par instance Azure Resource Manager dans la région de l’utilisateur qui envoie la requête. Les demandes adressées à l’instance Azure Resource Manager dans la région sont également limitées par ID d’utilisateur principal et par heure. Lorsque la demande est transférée au fournisseur de ressources, les requêtes sont limitées par région de la ressource plutôt que par instance Azure Resource Manager dans la région de l’utilisateur.

Remarque

Les limites d’un fournisseur de ressources peuvent différer des limites de l’instance Azure Resource Manager dans la région de l’utilisateur.

L’illustration suivante montre la façon dont la limitation est appliquée lorsqu’une demande passe de l’utilisateur à Azure Resource Manager et au fournisseur de ressources.

Diagramme montrant la façon dont la limitation est appliquée quand une requête passe de l’utilisateur à Azure Resource Manager et au fournisseur de ressources.

Limites de locataire et d’abonnement

Chaque opération au niveau de l’abonnement et du client est soumise à des limites de limitation. Les requêtes appliquées à l’abonnement sont celles qui impliquent la transmission de votre ID d’abonnement, par exemple pour récupérer les groupes de ressources dans votre abonnement. Par exemple, l’envoi d’une demande à https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups?api-version=2022-01-01 est une opération au niveau de l’abonnement. Les requêtes appliquées au locataire n’incluent pas votre ID d’abonnement, notamment pour la récupération des emplacements Azure valides. Par exemple, l’envoi d’une demande à https://management.azure.com/tenants?api-version=2022-01-01 est une opération au niveau du locataire.

Les limites de limitation par heure par défaut sont indiquées dans le tableau suivant.

Étendue	Opérations	Limite
Abonnement	lectures	12,000
Abonnement	suppressions	15,000
Abonnement	écritures	1,200
Locataire	lectures	12,000
Locataire	écritures	1,200

Ces limites sont définies d’après le principal de sécurité (utilisateur ou application) qui effectue les requêtes et l’ID d’abonnement ou l’ID du locataire. Si vos requêtes proviennent de plusieurs principaux de sécurité, votre limite dans l’abonnement ou le locataire est supérieure à 12 000 et 1200 par heure.

Ces limites s’appliquent à chaque instance Azure Resource Manager. Chaque région Azure comporte plusieurs instances, et Azure Resource Manager est déployé dans toutes les régions Azure. Par conséquent, dans la pratique, les limites sont supérieures à ces limites. Différentes instances d’Azure Resource Manager gèrent généralement les requêtes de l’utilisateur.

Les demandes restantes sont renvoyées dans les valeurs d’en-tête de réponse.

Limites de fournisseur de ressources

Les fournisseurs de ressources appliquent leurs propres limites de limitation. Dans chaque abonnement, le fournisseur de ressources limite par région de la ressource dans la requête. Étant donné que Resource Manager limite par instance de Resource Manager et qu’il existe plusieurs instances de Resource Manager dans chaque région, le fournisseur de ressources peut recevoir plus de demandes que les limites par défaut de la section précédente.

Cette section décrit les limites de limitation de certains fournisseurs de ressources couramment utilisés.

Limitation du stockage

Les limites suivantes s’appliquent seulement si vous effectuez des opérations de gestion en utilisant Azure Resource Manager avec le Stockage Azure et le Fournisseur de ressources de stockage. Les limites s’appliquent par abonnement et par région de la ressource dans la requête.

Ressource	Limite
Opérations de gestion du compte de stockage (lecture)	800 toutes les 5 minutes
Opérations de gestion du compte de stockage (écriture)	10 par seconde/1 200 par heure
Opérations de gestion du compte de stockage (liste)	100 toutes les 5 minutes

Limitation du réseau

Le fournisseur de ressources Microsoft. Network applique les limites de limitation suivantes :

Opération	Limite
écriture / suppression (PUT)	1 000 par 5 minutes
lecture (GET)	10 000 par 5 minutes

En plus de ces limites générales, consultez les limites d’utilisation pour Azure DNS.

Calculer la limitation

Microsoft Compute implémente la limitation pour offrir une expérience optimale aux utilisateurs de machines virtuelles et de groupes de machines virtuelles identiques. Limites de la limitation du calcul fournit des informations complètes sur les stratégies de limitation et les limites des machines virtuelles, les groupes de machines virtuelles identiques et les machines virtuelles d’un groupe identique.

Limitation Azure Resource Graph

Azure Resource Graph limite le nombre de demandes à ses opérations. Les étapes décrites dans cet article pour déterminer les requêtes restantes et comment réagir si la limite est atteinte s’appliquent également à Resource Graph. Toutefois, Resource Graph définit ses propres limites et son propre taux de réinitialisation. Pour plus d’informations, voir En-têtes de limitation de Resource Graph.

Azure Resource Graph dispose également d’une solution qui permet d’obtenir des données de ressources supplémentaires lorsque vous avez atteint des limites de limitation du fournisseur de ressources en s’intégrant en toute transparence avec les API GET et LIST existantes du plan de contrôle Azure Resource Manager, offrant une solution puissante et évolutive pour l’accès aux données de ressources. Pour plus d’informations, consultez l’API ARG GET/LIST.

Autres fournisseurs de ressources

Pour plus d’informations sur la limitation dans d’autres fournisseurs de ressources, consultez :

Code d'erreur

Lorsque vous atteignez la limite, vous recevez le code d’état HTTP 429 Trop de requêtes. La réponse inclut la valeur Retry-After qui spécifie le nombre de secondes pendant lesquelles votre application doit attendre avant d’envoyer la requête suivante. Si vous envoyez une demande avant l’écoulement de la valeur de nouvelles tentatives, votre demande n’est pas traitée et une autre valeur de nouvelles tentatives est renvoyée.

Si vous utilisez un Kit de développement logiciel (SDK) Azure, celui-ci peut inclure une configuration de nouvelle tentative automatique. Pour plus d’informations, consultez Guide du mécanisme de nouvelle tentative relatif aux services Azure.

Certains fournisseurs de ressources retournent l’erreur 429 pour signaler un problème temporaire. Le problème peut être une condition de surcharge qui n’est pas due à votre requête. Il peut également s’agir d’une erreur temporaire concernant l’état de la ressource cible ou de la ressource dépendante. Par exemple, le fournisseur de ressources réseau retourne le message 429 avec le code d’erreur RetryableErrorDueToAnotherOperation lorsqu’une autre opération verrouille la ressource cible. Pour déterminer si l’erreur provient d’une limitation ou d’une condition temporaire, affichez les détails de l’erreur dans la réponse.

Requêtes restantes

Vous pouvez déterminer le nombre de requêtes restantes en examinant les en-têtes de réponse. Les requêtes de lecture retournent une valeur dans l’en-tête pour le nombre de requêtes de lecture restantes. Les requêtes d’écriture incluent une valeur pour le nombre de requêtes d’écriture restantes. Le tableau suivant décrit les en-têtes de réponse que vous pouvez examiner pour ces valeurs :

En-tête de réponse	Descriptif
x-ms-ratelimit-remaining-subscription-deletes	Requêtes de suppression restantes étendues à l’abonnement. Cette valeur est renvoyée pour les opérations de suppression.
x-ms-ratelimit-remaining-subscription-reads	Requêtes de lecture restantes étendues à l’abonnement. Cette valeur est renvoyée pour les opérations de lecture.
x-ms-ratelimit-remaining-subscription-writes	Requêtes d’écriture restantes étendues à l’abonnement. Cette valeur est renvoyée pour les opérations d’écriture.
x-ms-ratelimit-remaining-tenant-reads	Lectures délimitées du locataire restantes.
x-ms-ratelimit-remaining-tenant-writes	Écritures délimitées du locataire restantes.
x-ms-ratelimit-remaining-subscription-resource-requests	Requêtes de type de ressource délimitées à l’abonnement restantes. Cette valeur d’en-tête est retournée uniquement si un service remplace la limite par défaut. Resource Manager ajoute cette valeur au lieu des requêtes de lecture ou d’écriture de l’abonnement.
x-ms-ratelimit-remaining-subscription-resource-entities-read	Requêtes de collecte de type de ressource délimitées à l’abonnement restantes. Cette valeur d’en-tête est retournée uniquement si un service remplace la limite par défaut. Cette valeur fournit le nombre de requêtes de collecte restantes (répertorier les ressources).
x-ms-ratelimit-remaining-tenant-resource-requests	Requêtes de type de ressource délimitées au locataire restantes. Cet en-tête est ajouté pour les requêtes au niveau du locataire, et ce uniquement si un service écrase la limite par défaut. Resource Manager ajoute cette valeur au lieu des requêtes de lecture ou d’écriture du locataire.
x-ms-ratelimit-remaining-tenant-resource-entities-read	Requêtes de collecte de type de ressource restantes étendues au locataire. Cet en-tête est ajouté uniquement pour les demandes au niveau du locataire, et ce uniquement si un service remplace la limite par défaut.

Le fournisseur de ressources peut également retourner des en-têtes de réponse avec des informations sur les demandes restantes. Pour plus d’informations sur les en-têtes de réponse retournés par le fournisseur de ressources de calcul, consultez En-têtes de réponse d’information de débit d’appels.

Récupération des valeurs d’en-tête

La récupération de ces valeurs d’en-tête dans votre code ou script est similaire à la récupération de n’importe quelle valeur d’en-tête.

Par exemple, en C#, vous récupérez la valeur d’en-tête d’un objet HttpWebResponse nommé response avec le code suivant :

response.Headers.GetValues("x-ms-ratelimit-remaining-subscription-reads").GetValue(0)

Dans PowerShell, récupérez la valeur d’en-tête d’une opération Invoke-WebRequest.

$r = Invoke-WebRequest -Uri https://management.azure.com/subscriptions/{guid}/resourcegroups?api-version=2016-09-01 -Method GET -Headers $authHeaders
$r.Headers["x-ms-ratelimit-remaining-subscription-reads"]

Pour obtenir un exemple PowerShell complet, consultez Vérifier les limites ARM pour un abonnement donné.

Pour voir les requêtes restantes pour le débogage, fournissez le paramètre -Debug sur votre applet de commande PowerShell.

Get-AzResourceGroup -Debug

La réponse inclut de nombreuses valeurs, notamment la valeur de réponse suivante :

DEBUG: ============================ HTTP RESPONSE ============================

Status Code:
OK

Headers:
Pragma                        : no-cache
x-ms-ratelimit-remaining-subscription-reads: 11999

Pour obtenir des limites d’écriture, utilisez une opération d’écriture :

New-AzResourceGroup -Name myresourcegroup -Location westus -Debug

La réponse inclut de nombreuses valeurs, notamment les suivantes :

DEBUG: ============================ HTTP RESPONSE ============================

Status Code:
Created

Headers:
Pragma                        : no-cache
x-ms-ratelimit-remaining-subscription-writes: 1199

Dans Azure CLI, vous utilisez l’option plus détaillée pour récupérer la valeur d’en-tête :

az group list --verbose --debug

La commande retourne de nombreuses valeurs, notamment les suivantes :

msrest.http_logger : Response status: 200
msrest.http_logger : Response headers:
msrest.http_logger :     'Cache-Control': 'no-cache'
msrest.http_logger :     'Pragma': 'no-cache'
msrest.http_logger :     'Content-Type': 'application/json; charset=utf-8'
msrest.http_logger :     'Content-Encoding': 'gzip'
msrest.http_logger :     'Expires': '-1'
msrest.http_logger :     'Vary': 'Accept-Encoding'
msrest.http_logger :     'x-ms-ratelimit-remaining-subscription-reads': '11998'