Limitation des demandes pour Amazon EC2 API - Amazon Elastic Compute Cloud
Comment l'étranglement est appliquéLimites d'étranglementRégulation du API moniteurRéessais et recul exponentielDemander une augmentation de limite

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Limitation des demandes pour Amazon EC2 API

Amazon EC2 limite les EC2 API demandes pour chaque AWS compte par région. Nous faisons cela pour améliorer les performances du service et garantir une utilisation équitable pour tous les EC2 clients Amazon. La régulation garantit que les demandes adressées à Amazon ne dépassent EC2 API pas les limites de API demandes maximales autorisées. APIles demandes sont soumises aux limites de demandes, qu'elles proviennent de :

  • Une application tierce

  • Un outil de ligne de commande

  • La EC2 console Amazon

Si vous dépassez une limite d'APIétranglement, le code RequestLimitExceeded d'erreur s'affiche.

Comment l'étranglement est appliqué

Amazon EC2 utilise l'algorithme Token Bucket pour implémenter le API throttling. Avec cet algorithme, votre compte dispose d'un compartiment contenant un nombre spécifique de jetons. Le nombre de jetons dans le compartiment représente votre limite de limitation à chaque seconde.

Amazon EC2 implémente deux types de API régulation :

Limitation du débit de demande

Avec la limitation du taux de demandes, chacune API est évaluée individuellement et le nombre de demandes que vous faites est limité par rapport à chaque demande. API Chaque demande que vous effectuez supprime un jeton API du compartiment. Par exemple, la taille du compartiment de jetons pour DescribeHosts une API action non mutante est de 100 jetons. Vous pouvez effectuer jusqu'à 100 DescribeHosts demandes en une seconde. Si vous dépassez 100 demandes par seconde, vous êtes limité API et les demandes restantes échouent, mais les demandes pour les autres ne API sont pas affectées.

Les seaux se rechargent automatiquement à un débit défini. Si le compartiment est inférieur à sa capacité maximale, un nombre défini de jetons y est ajouté chaque seconde jusqu'à ce qu'il atteigne sa capacité maximale. Si le seau est plein à l'arrivée des jetons de recharge, ils sont jetés. Le bucket ne peut pas contenir plus de jetons que son maximum. Par exemple, la taille du compartiment pour DescribeHosts une API action non mutante est de 100 jetons et le taux de recharge est de 20 jetons par seconde. Si vous faites 100 DescribeHosts demandes en une seconde, le bucket est réduit à zéro (0) jeton. Le seau est ensuite rempli de 20 jetons par seconde, jusqu'à ce qu'il atteigne sa capacité maximale de 100 jetons. Cela signifie qu'un compartiment vide atteint sa capacité maximale au bout de 5 secondes si aucune demande n'est faite pendant cette période.

Il n'est pas nécessaire d'attendre que le compartiment soit complètement plein pour pouvoir faire des API demandes. Vous pouvez utiliser des jetons de recharge au fur et à mesure qu'ils sont ajoutés au compartiment. Si vous utilisez immédiatement les jetons de recharge, le seau n'atteint pas sa capacité maximale. Par exemple, la taille du compartiment pour DescribeHosts une API action non mutante est de 100 jetons et le taux de recharge est de 20 jetons par seconde. Si vous épuisez le compartiment en effectuant 100 API demandes par seconde, vous pouvez continuer à en faire 20 API par seconde en utilisant les jetons de recharge au fur et à mesure qu'ils sont ajoutés au compartiment. Le compartiment ne peut être rempli à sa capacité maximale que si vous effectuez moins de 20 API demandes par seconde.

Limitation du débit des ressources

Certaines API actions, telles que RunInstances etTerminateInstances, comme décrit dans le tableau ci-dessous, utilisent la limitation du débit des ressources en plus de la limitation du débit des demandes. Ces API actions sont associées à un compartiment de jetons de ressources distinct qui s'épuise en fonction du nombre de ressources affectées par la demande. À l'instar des compartiments de jetons de demande, les compartiments de jetons de ressources ont un nombre maximal de compartiments qui vous permet de les déborder, et un taux de recharge qui vous permet de maintenir un taux constant de demandes aussi longtemps que nécessaire. Si vous dépassez une limite de compartiment spécifique pour unAPI, y compris lorsqu'un compartiment n'est pas encore rempli pour répondre à la API demande suivante, l'action du API est limitée même si vous n'avez pas atteint la limite d'APIaccélération totale.

Par exemple, la taille du compartiment de jetons de ressources pour RunInstances est de 1 000 jetons et le taux de recharge est de deux jetons par seconde. Par conséquent, vous pouvez lancer immédiatement 1 000 instances en utilisant n'importe quel nombre de API demandes, par exemple une demande pour 1 000 instances ou quatre demandes pour 250 instances. Une fois que le bucket de jetons de ressources est vide, vous pouvez lancer jusqu'à deux instances par seconde, en utilisant soit une demande pour deux instances, soit deux demandes pour une instance.

Pour de plus amples informations, veuillez consulter Tailles des seaux de jetons de ressources et taux de recharge.

Limites d'étranglement

Les sections suivantes décrivent les tailles des compartiments de jetons de demande et de jetons de ressources ainsi que les taux de recharge.

Demandez la taille des seaux de jetons et les taux de recharge

Pour limiter le taux de demandes, API les actions sont regroupées dans les catégories suivantes :

  • Actions non mutantes : API actions qui récupèrent des données sur les ressources. Cette catégorie inclut généralement tous les Describe*List*,Search*, et Get* API les actions, telles que DescribeRouteTablesSearchTransitGatewayRoutes, etGetIpamPoolCidrs. Ces API actions ont généralement les limites d'APIétranglement les plus élevées.

  • Actions non mutantes non filtrées et non paginées : sous-ensemble spécifique d'actions non API mutantes qui, lorsqu'elles sont demandées sans spécifier de pagination ni de filtre, utilisent des jetons provenant d'un compartiment de jetons plus petit. Il est recommandé d'utiliser la pagination et le filtrage afin que les jetons soient déduits du compartiment de jetons standard (plus grand).

  • Actions de mutation : API actions qui créent, modifient ou suppriment des ressources. Cette catégorie inclut généralement toutes les API actions qui ne sont pas classées comme des actions non mutantes, telles que AllocateHostsModifyHosts, et. CreateCapacityReservation Ces actions ont une limite d'étranglement inférieure à celle des actions non API mutantes.

  • Actions gourmandes en ressources : actions mutantes API qui prennent le plus de temps et consomment le plus de ressources pour être réalisées. Ces actions ont une limite d'étranglement encore plus faible que les actions mutantes. Elles sont régulées séparément des autres actions mutantes.

  • Actions non mutantes sur la console : actions non mutantes API demandées depuis la console Amazon. EC2 Ces API actions sont limitées séparément des autres actions non API mutantes.

  • Actions non classées : il s'agit d'APIactions qui reçoivent leur propre taille de seau de jetons et leur propre taux de recharge, même si, par définition, elles entrent dans l'une des autres catégories.

Le tableau suivant indique la taille des seaux de jetons demandés et les taux de recharge pour toutes les AWS régions.

APIcatégorie d'action Actions Capacité maximale du compartiment Taux de recharge du seau
Actions non mutantes

Toutes Describe* les List* Get* API actions qui ne sont pas des actions non mutantes non filtrées et non paginées ou des actions non classées. Search*

 100 20
Actions non mutantes non filtrées et non paginées

  • DescribeInstances

  • DescribeInstanceStatus

  • DescribeNetworkInterfaces

  • DescribeSecurityGroups

  • DescribeSnapshots

  • DescribeSpotInstanceRequests

  • DescribeVolumes

 50 10
Actions mutantes

Toutes les API actions mutantes qui ne sont pas des actions gourmandes en ressources ou des actions non classées.

 50 5
Actions gourmandes en ressources

  • AcceptVpcPeeringConnection

  • AuthorizeSecurityGroupIngress

  • CancelSpotInstanceRequests

  • CreateKeyPair

  • CreateVpcPeeringConnection

  • DeleteVpcPeeringConnection

  • RejectVpcPeeringConnection

  • RevokeSecurityGroupIngress

  • RequestSpotInstances

 50 5
Actions non mutantes de la console

  • Describe*

  • Get*

 100 10
Actions non classées AcceptVpcEndpointConnections 10 1
AdvertiseByoipCidr 1 0.1
AssignIpv6Addresses 100 5
AssignPrivateIpAddresses 100 5
AssignPrivateNatGatewayAddress 10  1
AssociateEnclaveCertificateIamRole 10 1
AssociateIamInstanceProfile 100 5
AssociateNatGatewayAddress 10  1
AttachVerifiedAccessTrustProvider 10 2
CreateDefaultSubnet 1 1
CreateDefaultVpc 1 1
CopyImage 100 1
CreateLaunchTemplateVersion 100 5
CreateNatGateway 10  1
CreateNetworkInterface 100 5
CreateRestoreImageTask 50 0.1
CreateSnapshot 100 5
CreateSnapshots 100 5
CreateStoreImageTask 50 0.1
CreateTags 100 10
CreateVerifiedAccessEndpoint 20 4
CreateVerifiedAccessGroup 10 2
CreateVerifiedAccessInstance 10 2
CreateVerifiedAccessTrustProvider 10 2
CreateVolume 100 5
CreateVpcEndpoint 4 0.3
CreateVpcEndpointServiceConfiguration 10 1
DeleteNatGateway 10 1
DeleteNetworkInterface 100 5
DeleteSnapshot 100 5
DeleteTags 100 10
DeleteQueuedReservedInstances 5 5 
DeleteVerifiedAccessEndpoint 20 4
DeleteVerifiedAccessGroup 10 2
DeleteVerifiedAccessInstance 10 2
DeleteVerifiedAccessTrustProvider 10 2
DeleteVolume 100 5
DeleteVpcEndpoints 4 0.3
DeleteVpcEndpointServiceConfigurations 10 1
DeprovisionByoipCidr 1 0.1
DeregisterImage 100 5
DetachVerifiedAccessTrustProvider 10  2
DescribeByoipCidrs 1 0.5
DescribeCapacityBlockOfferings 10 0,15
DescribeInstanceTopology 1 1
DescribeMovingAddresses 1 1
DescribeReservedInstancesOfferings 10 10
DescribeSpotFleetRequestHistory 100 5
DescribeSpotFleetInstances 100 5
DescribeSpotFleetRequests 50 3
DescribeStoreImageTasks 50 0.5
DescribeVerifiedAccessInstanceLoggingConfigurations 10 2
DisableFastLaunch 5 2
DisableImageBlockPublicAccess 1 0.1
DisableSnapshotBlockPublicAccess 1 0.1
DisassociateEnclaveCertificateIamRole 10 1
DisassociateIamInstanceProfile 100 5
DisassociateNatGatewayAddress 10  1
EnableFastLaunch 5 2
EnableImageBlockPublicAccess 1 0.1
EnableSnapshotBlockPublicAccess 1 0.1
GetAssociatedEnclaveCertificateIamRoles 10 1
ModifyImageAttribute 100 5
ModifyInstanceMetadataOptions 100 5
ModifyLaunchTemplate 100 5
ModifyNetworkInterfaceAttribute 100 5
ModifySnapshotAttribute 100 5
ModifyVerifiedAccessEndpoint 20 4
ModifyVerifiedAccessEndpointPolicy 20 4
ModifyVerifiedAccessGroup 10 2
ModifyVerifiedAccessGroupPolicy 20 4
ModifyVerifiedAccessInstance 10 2
ModifyVerifiedAccessInstanceLoggingConfiguration 10 2
ModifyVerifiedAccessTrustProvider 10 2
ModifyVpcEndpoint 4 0.3
ModifyVpcEndpointServiceConfiguration 10 1
MoveAddressToVpc 1 1
ProvisionByoipCidr 1 0.1
PurchaseCapacityBlock 10 0,15
PurchaseReservedInstancesOffering 5 5 
RejectVpcEndpointConnections 10  1
RestoreAddressToClassic 1 1
RunInstances 5 2
StartInstances 5 2
TerminateInstances 100 5
UnassignPrivateIpAddresses 100 5
UnassignPrivateNatGatewayAddress 10  1
WithdrawByoipCidr 1 0.1

Tailles des seaux de jetons de ressources et taux de recharge

Le tableau suivant répertorie les tailles des compartiments de jetons de ressources et les taux de recharge pour les API actions utilisant la limitation du débit des ressources.

APIaction Capacité maximale du compartiment Taux de recharge du seau
RunInstances 1 000 2
TerminateInstances 1 000 20
StartInstances 1 000 2
StopInstances 1 000 20

Régulation du API moniteur

Vous pouvez utiliser Amazon CloudWatch pour surveiller vos EC2 API demandes Amazon et pour collecter et suivre les indicateurs relatifs à la API régulation. Vous pouvez également créer une alarme pour vous avertir lorsque vous êtes sur le point d'atteindre les limites d'APIétranglement. Pour de plus amples informations, veuillez consulter Surveillez les EC2 API demandes Amazon à l'aide d'Amazon CloudWatch.

Réessais et recul exponentiel

Il se peut que votre application doive réessayer une API demande. Par exemple :

  • Pour vérifier l'existence d'une mise à jour du statut d'une ressource

  • Pour énumérer un grand nombre de ressources (par exemple, tous vos volumes)

  • Pour réessayer une demande après qu'elle ait échoué en raison d'une erreur de serveur (5xx) ou d'une erreur de limitation

Toutefois, en cas d'erreur client (4xx), vous devez réviser la demande pour corriger le problème avant de réessayer la demande.

Changements de statut des ressources

Avant de commencer à interroger pour vérifier les mises à jour de statut, donnez à la demande le temps de se terminer éventuellement. Par exemple, attendez quelques minutes avant de vérifier si votre instance est active. Lorsque vous commencez à interroger, utilisez un intervalle de sommeil approprié entre les demandes successives afin de réduire le taux de API demandes. Pour obtenir de meilleurs résultats, utilisez un intervalle de veille croissant ou variable.

Vous pouvez également utiliser Amazon EventBridge pour vous informer de l'état de certaines ressources. Par exemple, vous pouvez utiliser l'événement de notification de changement d'état de l'EC2instance pour vous informer d'un changement d'état d'une instance. Pour plus d'informations, consultez Automatiser EC2 l'utilisation d'Amazon EventBridge.

Nouvelle tentative

Lorsque vous devez interroger ou réessayer une API demande, nous vous recommandons d'utiliser un algorithme de temporisation exponentielle pour calculer l'intervalle de sommeil entre les demandes. API L’idée sous-jacente consiste à utiliser des temps d’attente progressivement plus longs entre les tentatives en cas de réponses d’erreur consécutives. Vous devez implémenter un intervalle maximal, ainsi qu'un nombre maximal de nouvelles tentatives. Vous pouvez également utiliser la gigue (délai aléatoire) pour éviter les collisions successives. Pour plus d'informations, consultez les sections Expiration, nouvelles tentatives et interruption avec gigue.

Chacun AWS SDK implémente une logique de nouvelle tentative automatique. Pour plus d'informations, consultez la section Comportement des tentatives dans le guide de référence AWS SDKs et Tools.

Demander une augmentation de limite

Vous pouvez demander une augmentation des limites de API limitation pour votre. Compte AWS

Pour demander l'accès à cette fonctionnalité

  1. AWS Support Centre ouvert.

  2. Choisissez Create case (Créer une demande).

  3. Choisissez Compte et facturation.

  4. Pour le service, sélectionnez Informations générales et Mise en route.

  5. Dans Catégorie, choisissez Utilisation AWS et services.

  6. Choisissez Next step: Additional information (Étape suivante : informations supplémentaires).

  7. Pour Subject (Objet), saisissez Request an increase in my Amazon EC2 API throttling limits.

  8. Pour Description, saisissez Please increase the API throttling limits for my account. Related page: https://docs.aws.amazon.com/AWSEC2/latest/APIReference/throttling.html. Incluez également les informations suivantes :

    • Description de votre cas d’utilisation.

    • Les régions où vous avez besoin d'une augmentation.

    • La fenêtre d'une heureUTC, au cours de laquelle le pic d'étranglement ou d'utilisation s'est produit (pour calculer la nouvelle limite d'étranglement).

  9. Choisissez Next step: Solve now or contact us (Étape suivante : résolvez maintenant ou contactez-nous).

  10. Dans l'onglet Contactez-nous, choisissez la langue de contact et le mode de contact que vous préférez.

  11. Sélectionnez Envoyer.