Limitation des requêtes d'API Amazon Route 53

Important

Amazon Route 53 a mis à jour son comportement de limitation des API. La mise à jour inclut l'augmentation de la limite de demandes par seconde et l'introduction d'une limitation basée sur les modifications. Cette page décrit en détail les limites mises à jour.

Amazon Route 53 limite les demandes d'API par compte afin de maintenir la stabilité du service et de garantir une utilisation équitable pour tous les clients. La Route 53 applique deux limites indépendantes :

• Taux de demandes : le nombre de requêtes d'API par seconde.

• Modifier le débit : le nombre de modifications d'enregistrements DNS individuels par seconde, agrégé entre les actions d'API qui modifient les données DNS.

Une demande peut être limitée par l'une ou l'autre limite. Lorsqu'une demande est limitée, Amazon Route 53 renvoie une erreur HTTP 400 ()Bad request. L'en-tête de réponse inclut également un élément Code avec une valeur Throttling et un élément Message avec une valeur Rate exceeded.

Comment l'étranglement est appliqué

Amazon Route 53 utilise un algorithme de bucket de jetons. Chaque limite comporte un compartiment contenant un nombre maximum de jetons. Chaque demande (pour la limite de débit de demandes) ou chaque modification (pour la limite de débit de modification) supprime des jetons du compartiment applicable. Le seau se recharge à un rythme fixe toutes les secondes, jusqu'à sa capacité maximale. Si les jetons de recharge arrivent alors que le seau est déjà plein, Route 53 les jette.

Deux valeurs décrivent chaque compartiment :

• La capacité maximale du compartiment est votre rafale : le nombre de demandes ou de modifications que Route 53 peut absorber en une seule fois lorsque le compartiment est plein.

• Le taux de remplissage du bucket est votre taux soutenu : le nombre de demandes ou de modifications par seconde que vous pouvez maintenir indéfiniment.

Vous pouvez utiliser les jetons de recharge au fur et à mesure de leur ajout ; vous n'avez pas besoin d'attendre que le seau soit complètement rempli.

Taux de demande, tailles des seaux de jetons et taux de recharge

Route 53 applique une limitation du débit de demandes à deux niveaux :

• Niveau du compte : toutes les demandes d'API Amazon Route 53 provenant de votre compte proviennent d'un seul compartiment.

• Niveau de compte et de fonctionnement : chaque action d'API possède également son propre compartiment.

Une demande consomme un jeton provenant des deux compartiments et est limitée si l'un des compartiments est vide. Les actions suivantes ont des limites de débit de demandes par défaut différentes.

Limites de taux de demandes par action d'API

Action d’API	Capacité maximale du compartiment	Taux de remplissage du seau
Toutes les actions de l'API Amazon Route 53 combinées (au niveau du compte)	50	10
Toute action d'API non répertoriée ci-dessous (par défaut par action)	50	10
AssociateVPCWithHostedZone	20	5
ChangeCidrCollection	40	5
CreateCidrCollection	40	5
CreateHealthCheck	50	0.5
CreateHostedZone	40	2
CreateReusableDelegationSet	40	2
CreateTrafficPolicyInstance	1	1
DeleteCidrCollection	40	5
DeleteHealthCheck	15	3
DeleteHostedZone	40	5
DeleteReusableDelegationSet	40	5
DeleteTrafficPolicyInstance	1	1
DisassociateVPCFromHostedZone	10	5
GetHealthCheckLastFailureReason	4	1
GetHealthCheckStatus	4	1
UpdateHealthCheck	50	5
UpdateTrafficPolicyInstance	1	1

Pour obtenir la liste complète des actions de l'API Amazon Route 53, consultez la section Actions du manuel de référence de l'API Amazon Route 53.

CreateHealthCheck requêtes

Vous pouvez envoyer une requête CreateHealthCheck toutes les 2 secondes par Compte AWS. Cela correspond au taux de recharge de 0,5 demande par seconde indiqué dans le tableau précédent.

Modifier la limite de débit

Outre la limite de débit de requêtes, les actions d'API qui modifient les données DNS sont soumises à une limite de débit de modification. Cette limite utilise un compartiment de jetons distinct qui s'efface en fonction du nombre de modifications d'enregistrement DNS effectuées par une demande, et non du nombre de demandes. Le débit de modification est limité par action Compte AWS d'API et non par action. Toutes les actions suivantes sont effectuées à partir d'un seau, qui a une capacité maximale de 1 500 changements (rafale) et se recharge à 100 changements par seconde (en continu).

Les modifications sont comptabilisées comme suit :

Jetons consommés par opération

Opération	Jetons consommés
ChangeResourceRecordSets	1 pourCREATE, 1 pourDELETE, 2 pour UPSERT
AssociateVPCWithHostedZone	2
DisassociateVPCFromHostedZone	2
CreateHostedZone	2
DeleteHostedZone	2

Toutes les autres actions de l'API Amazon Route 53 ne consomment aucun jeton de débit et sont limitées uniquement par le taux de demandes.

Exemple : vous pouvez soumettre une seule demande contenant 1 000 modifications (une rafale), ce qui consomme 1 000 jetons. Après la rafale, le seau se recharge à 100 jetons par seconde. Si vous continuez à soumettre 100 modifications par seconde, vous pouvez maintenir ce taux indéfiniment. Si vous tentez de maintenir 500 modifications par seconde, le compartiment s'épuise et les demandes suivantes sont limitées jusqu'à ce qu'il soit rechargé.

Surveiller la limitation des API

Vous pouvez surveiller votre utilisation de l'API Amazon Route 53 en surveillant les réponses HTTP 400 dans les journaux de vos applications ou en suivant l'utilisation de l'API grâce à CloudWatch des statistiques. Lorsque vous recevez des erreurs de limitation, vos demandes dépassent l'une des limites décrites dans les sections précédentes.

Réessais et retard exponentiel

Lorsque vous interrogez ou réessayez une demande d'API, nous vous recommandons d'utiliser un algorithme d'attente exponentiel pour calculer l'intervalle de veille entre les demandes. Le backoff exponentiel utilise des temps d'attente de plus en plus longs entre les nouvelles tentatives pour obtenir des réponses d'erreur consécutives. Implémentez un intervalle de retard maximal et un nombre maximum de tentatives, et envisagez d'ajouter du jitter (délai aléatoire) pour éviter les collisions successives. Pour plus d'informations, consultez la section Délais d'attente, nouvelles tentatives et repli en cas de gigue dans la bibliothèque des constructeurs. AWS

Chaque AWS SDK met en œuvre une logique de nouvelle tentative automatique, y compris un mode de nouvelle tentative adaptatif qui ajuste le taux de demandes côté client en réponse à la limitation. Pour les charges de travail qui approchent régulièrement ces limites, envisagez d'activer les nouvelles tentatives adaptatives. Pour plus d'informations, consultez la section Comportement des nouvelles tentatives dans le Guide de référence AWS des kits de développement logiciel et des outils.

Demande d'une augmentation de limite

Vous pouvez demander une augmentation du taux de demandes d'API ou de la limite de débit de modification via AWS Support. Pour demander une augmentation :

• Ouvrez le centre AWS de support.

• Créez un dossier et choisissez Augmentation de la limite de service.

• Pour Type de limite, choisissez Route 53.

• Indiquez votre consommation actuelle et la limite dont vous avez besoin.

Meilleures pratiques en matière de limitation des API

• Équilibrez le taux de demandes par rapport à la taille du lot : si vous êtes limité par la limite du taux de demandes, envoyez davantage de modifications par demande. Si vous êtes limité par la limite de débit de modification, réduisez votre taux de modification total. Ni les très petits ni les très grands lots ne sont optimaux en eux-mêmes.

• Utilisez le traitement par lots pour l'atomicité : toutes les modifications d'une seule ChangeResourceRecordSets demande sont appliquées de manière atomique, de sorte qu'elles aboutissent ou échouent ensemble.

• Répartissez les modifications dans le temps : répartissez les modifications de manière uniforme sur quelques secondes au lieu de soumettre de gros lots simultanément.

• Comptez sur les rafales pour les pics occasionnels, et non sur le débit soutenu : la capacité de rafale permet de faire face à des pics de trafic légitimes ; il ne s'agit pas d'un plafond de fonctionnement durable.

• Réessayez avec un délai exponentiel : lorsque vous recevez des réponses HTTP 400, réessayez après un délai qui augmente à chaque tentative (voir). Réessais et retard exponentiel

• La limite de demandes augmente de manière proactive : si vous prévoyez une augmentation de la charge de travail, demandez une augmentation avant d'atteindre la limite (voirDemande d'une augmentation de limite).

Pour obtenir des conseils plus complets sur Amazon Route 53, consultezBonnes pratiques relatives à Amazon Route 53.