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.
# Accès programmatique à Amazon EC2
Vous pouvez créer et gérer vos EC2 ressources Amazon à l'aide de l'interface de programmation AWS Management Console ou d'une interface de programmation. Pour plus d'informations sur l'utilisation de la EC2 console Amazon, consultez le [guide de EC2 l'utilisateur Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/).
**Comment ça marche**
+ [Points de EC2 terminaison Amazon](ec2-endpoints.md)
+ [Cohérence éventuelle](eventual-consistency.md)
+ [Idempotenciité](ec2-api-idempotency.md)
+ [Limitation des demandes](ec2-api-throttling.md)
+ [Pagination](ec2-api-pagination.md)
**Interfaces de programmation**
+ [AWS Command Line Interface (AWS CLI)](ec2-aws-cli.md)
+ [AWS CloudFormation](ec2-cloudformation.md)
+ [AWS SDKs](sdk-general-information-section.md)
+ [API de bas niveau](ec2-low-level-api.md)
**Premiers pas**
+ [Exemples de code](service_code_examples.md)
+ [Console-to-Code](console-to-code.md)
**Surveillance**
+ [AWS CloudTrail](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitor-with-cloudtrail.html)
+ [Surveiller les demandes](monitor.md)
# Points de terminaison du service Amazon EC2
Un point de terminaison est une URL qui sert de point d'entrée à un service AWS Web. Amazon EC2 prend en charge les types de terminaux suivants :
+ [IPv4 points de terminaison](#ipv4)
+ [Points de terminaison à double pile](#ipv6) (compatibles avec et IPv4 ) IPv6
+ [points de terminaison FIPS](https://docs.aws.amazon.com/general/latest/gr/rande.html#FIPS-endpoints).
Lorsque vous soumettez une demande, vous pouvez spécifier le point de terminaison et la région à utiliser. Si vous ne spécifiez aucun point de terminaison, le IPv4 point de terminaison est utilisé par défaut. Pour utiliser un autre type de point de terminaison, vous devez le spécifier dans votre demande. Pour obtenir un exemple de la façon de procéder, consultez [Spécification des points de terminaison](#examples). Pour un tableau des points de terminaison disponibles, voir[Points de terminaison de service par région](#service-endpoints).
## IPv4 points de terminaison
IPv4 les terminaux ne prennent en charge que IPv4 le trafic. IPv4 les points de terminaison sont disponibles pour toutes les régions.
Si vous spécifiez le point de terminaison général, `ec2.amazonaws.com`, nous utilisons le point de terminaison pour `us-east-1`. Pour utiliser une autre région, spécifiez son point de terminaison associé. Par exemple, si vous le spécifiez `ec2.us-east-2.amazonaws.com` comme point de terminaison, nous dirigeons votre demande vers le point de terminaison `us-east-2`.
IPv4 les noms des points de terminaison utilisent la convention de dénomination suivante :
+ `service.region.amazonaws.com`
Par exemple, le nom du IPv4 point de terminaison de la `eu-west-1` région est`ec2.eu-west-1.amazonaws.com`.
## Points de terminaison à double pile (IPv4 et IPv6)
Les terminaux à double pile prennent en charge à la fois le trafic IPv4 et IPv6 le trafic. Lorsque vous envoyez une demande à un point de terminaison à double pile, l'URL du point de terminaison correspond à une IPv4 adresse IPv6 ou à une adresse, selon le protocole utilisé par votre réseau et votre client.
Amazon EC2 ne prend en charge que les points de terminaison régionaux à double pile, ce qui signifie que vous devez spécifier la région dans le nom du point de terminaison. Les noms des points de terminaison à double pile utilisent la convention d’affectation de noms suivante :
+ `ec2.region.api.aws`
Par exemple, le nom du point de terminaison à double pile de la région `eu-west-1` est `ec2.eu-west-1.api.aws`.
## Points de terminaison de service par région
Les points de terminaison de service pour Amazon EC2 sont les suivants. Pour plus d'informations sur les régions, consultez [Régions et zones de disponibilité](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) dans le guide de l'*utilisateur Amazon EC2*.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/ec2/latest/devguide/ec2-endpoints.html)
## Spécification des points de terminaison
Cette section fournit quelques exemples sur la manière de spécifier un point de terminaison lors de l’envoi d’une demande.
------
#### [ AWS CLI ]
Les exemples suivants montrent comment spécifier un point de terminaison pour la `us-east-2` région à l'aide du AWS CLI.
+ **Double pile**
```
aws ec2 describe-regions --region us-east-2 --endpoint-url https://ec2.us-east-2.api.aws
```
+ **IPv4**
```
aws ec2 describe-regions --region us-east-2 --endpoint-url https://ec2.us-east-2.amazonaws.com
```
------
#### [ AWS SDK for Java 2.x ]
Les exemples suivants montrent comment spécifier un point de terminaison pour la `us-east-2` région à l'aide du AWS SDK for Java 2.x.
+ **Double pile**
```
Ec2Client client = Ec2Client.builder()
.region(Region.US_EAST_2)
.endpointOverride(URI.create("https://ec2.us-east-2.api.aws"))
.build();
```
+ **IPv4**
```
Ec2Client client = Ec2Client.builder()
.region(Region.US_EAST_2)
.endpointOverride(URI.create("https://ec2.us-east-2.amazonaws.com"))
.build();
```
------
#### [ AWS SDK pour Java 1.x ]
Les exemples suivants montrent comment spécifier un point de terminaison pour la `eu-west-1` région à l'aide de la version AWS SDK pour Java 1.x.
+ **Double pile**
```
AmazonEC2 s3 = AmazonEC2ClientBuilder.standard()
.withEndpointConfiguration(new EndpointConfiguration(
"https://ec2.eu-west-1.api.aws",
"eu-west-1"))
.build();
```
+ **IPv4**
```
AmazonEC2 s3 = AmazonEC2ClientBuilder.standard()
.withEndpointConfiguration(new EndpointConfiguration(
"https://ec2.eu-west-1.amazonaws.com",
"eu-west-1"))
.build();
```
------
#### [ AWS SDK for Go ]
Les exemples suivants montrent comment spécifier un point de terminaison pour la `us-east-1` région à l'aide du AWS SDK pour Go.
+ **Double pile**
```
sess := session.Must(session.NewSession())
svc := ec2.New(sess, &aws.Config{
Region: aws.String(endpoints.UsEast1RegionID),
Endpoint: aws.String("https://ec2.us-east-1.api.aws")
})
```
+ **IPv4**
```
sess := session.Must(session.NewSession())
svc := ec2.New(sess, &aws.Config{
Region: aws.String(endpoints.UsEast1RegionID),
Endpoint: aws.String("https://ec2.us-east-1.amazonaws.com")
})
```
------
# Cohérence éventuelle dans l' EC2 API Amazon
L' EC2 API Amazon suit un modèle de cohérence éventuel, en raison de la nature distribuée du système supportant l'API. Cela signifie que le résultat d'une commande d'API que vous exécutez et qui affecte vos EC2 ressources Amazon peut ne pas être immédiatement visible pour toutes les commandes suivantes que vous exécuterez. Vous devez garder cela à l’esprit lorsque vous exécutez une commande API qui suit immédiatement une commande API précédente.
La cohérence éventuelle peut affecter la façon dont vous gérez vos ressources. Par exemple, si vous exécutez une commande pour créer une ressource, elle sera éventuellement visible par les autres commandes. Cela signifie que si vous exécutez une commande pour modifier ou décrire la ressource que vous venez de créer, son identifiant ne s'est peut-être pas propagé dans tout le système et vous recevrez un message d'erreur indiquant que la ressource n'existe pas.
Pour gérer la cohérence à terme, vous pouvez procéder comme suit :
+ Vérifiez l'état de la ressource avant d'exécuter une commande pour la modifier. Exécutez la commande `Describe` appropriée à l’aide d’un algorithme de backoff exponentiel afin de laisser suffisamment de temps à la commande précédente pour se propager dans le système. Pour ce faire, exécutez la `Describe` commande à plusieurs reprises, en commençant par quelques secondes d'attente, puis en augmentant progressivement jusqu'à quelques minutes.
+ Ajoutez un temps d’attente entre les commandes suivantes, même si une commande `Describe` renvoie une réponse précise. Appliquez un algorithme de réduction exponentielle en commençant par un temps d'attente de quelques secondes, puis augmentez-le progressivement jusqu'à quelques minutes.
**Exemples d'erreurs de cohérence éventuelles**
Vous trouverez ci-dessous des exemples de codes d'erreur que vous pourriez rencontrer en raison d'une éventuelle cohérence.
+ `InvalidInstanceID.NotFound`
Si vous exécutez correctement la `RunInstances` commande, puis que vous exécutez immédiatement une autre commande en utilisant l'ID d'instance fourni dans la réponse de`RunInstances`, une `InvalidInstanceID.NotFound` erreur peut être renvoyée. Cela ne signifie pas que l'instance n'existe pas.
Certaines commandes spécifiques susceptibles d'être affectées sont les suivantes :
+ `DescribeInstances`: pour confirmer l'état réel de l'instance, exécutez cette commande à l'aide d'un algorithme de ralentissement exponentiel.
+ `TerminateInstances`: Pour confirmer l'état de l'instance, exécutez d'abord la `DescribeInstances` commande à l'aide d'un algorithme de rétrogradation exponentielle.
**Important**
Si vous recevez une `InvalidInstanceID.NotFound` erreur après l'exécution`TerminateInstances`, cela ne signifie pas que l'instance est ou sera interrompue. Votre instance est peut-être toujours en cours d'exécution. C'est pourquoi il est important de confirmer d'abord l'état de l'instance à l'aide de`DescribeInstances`.
+ `InvalidGroup.NotFound`
Si vous exécutez correctement la `CreateSecurityGroup` commande, puis que vous exécutez immédiatement une autre commande en utilisant l'ID de groupe de sécurité fourni dans la réponse de`CreateSecurityGroup`, une `InvalidGroup.NotFound` erreur peut être renvoyée. Pour confirmer l'état du groupe de sécurité, exécutez la `DescribeSecurityGroups` commande à l'aide d'un algorithme de réduction exponentielle.
+ `InstanceLimitExceeded`
Vous avez demandé un nombre d'instances supérieur à ce que votre limite d'instances actuelle autorise pour le type d'instance spécifié. Vous pourriez atteindre cette limite de façon inattendue si vous lancez et mettez fin à des instances rapidement, car les instances résiliées sont prises en compte dans votre limite d'instances pendant un certain temps après leur résiliation.
# Garantir l'idempuissance des requêtes d'API Amazon EC2
Lorsque vous effectuez une demande d’API de mutation, la demande renvoie généralement un résultat avant la fin des flux de travail asynchrones de l’opération. Les opérations peuvent également expirer ou rencontrer d’autres problèmes de serveur avant d’être terminées, même si la demande a déjà renvoyé un résultat. Par conséquent, il peut être difficile de déterminer si la demande a abouti ou non et de multiples tentatives peuvent être déclenchées pour s’assurer que l’opération se termine correctement. Toutefois, si la demande initiale et les tentatives suivantes aboutissent, l’opération est terminée plusieurs fois. Cela signifie que vous pourriez créer plus de ressources que vous ne le souhaitiez.
L’*idempotence* garantit qu’une demande d’API se termine correctement. Avec une demande idempotente, si la demande d’origine se termine avec succès, toutes les tentatives suivantes se terminent avec succès, sans aucune action supplémentaire. Toutefois, le résultat peut contenir des informations mises à jour, telles que le statut de création actuel.
**Topics**
+ [Idempotencia sur Amazon EC2](#client-tokens)
+ [RunInstances idempuissance](#run-instances-idempotency)
+ [Exemples](#Run_Instance_Idempotency_CLI)
+ [Recommandations de nouvelle tentative pour les demandes idempotentes](#recommended-actions)
## Idempotencia sur Amazon EC2
Les actions d'API suivantes sont idempotentes par défaut et ne nécessitent aucune configuration supplémentaire. Les AWS CLI commandes correspondantes prennent également en charge l'idempotencie par défaut.
**Idempotent par défaut**
+ AssociateAddress
+ CreateVpnConnection
+ DisassociateAddress
+ ReplaceNetworkAclAssociation
+ TerminateInstances
Les actions d'API suivantes prennent éventuellement en charge l'idempotencie à l'aide d'un jeton *client*. Les AWS CLI commandes correspondantes prennent également en charge l'idempotencie à l'aide d'un jeton client. Un jeton client est une chaîne unique, distinguant majuscules et minuscules, comportant jusqu'à 64 caractères ASCII. Pour effectuer une demande d'API idempotente à l'aide de l'une de ces actions, spécifiez un jeton client dans la demande. Vous ne devez pas réutiliser le même jeton client pour d'autres demandes d'API. Si vous réessayez une demande qui s'est terminée avec succès en utilisant le même jeton client et les mêmes paramètres, la nouvelle tentative aboutit sans effectuer d'autre action. Si vous réessayez une demande réussie en utilisant le même jeton client, mais qu'un ou plusieurs paramètres sont différents, autres que la région ou la zone de disponibilité, la nouvelle tentative échoue avec une `IdempotentParameterMismatch` erreur.
**Idempotent à l'aide d'un jeton client**
+ AllocateHosts
+ AllocateIpamPoolCidr
+ AssociateClientVpnTargetNetwork
+ AssociateIpamResourceDiscovery
+ AttachVerifiedAccessTrustProvider
+ AuthorizeClientVpnIngress
+ CopyFpgaImage
+ CopyImage
+ CreateCapacityReservation
+ CreateCapacityReservationFleet
+ CreateClientVpnEndpoint
+ CreateClientVpnRoute
+ CreateEgressOnlyInternetGateway
+ CreateFleet
+ CreateFlowLogs
+ CreateFpgaImage
+ CreateInstanceConnectEndpoint
+ CreateIpam
+ CreateIpamPool
+ CreateIpamResourceDiscovery
+ CreateIpamScope
+ CreateLaunchTemplate
+ CreateLaunchTemplateVersion
+ CreateManagedPrefixList
+ CreateNatGateway
+ CreateNetworkAcl
+ CreateNetworkInsightsAccessScope
+ CreateNetworkInsightsPath
+ CreateNetworkInterface
+ CreateReplaceRootVolumeTask
+ CreateReservedInstancesListing
+ CreateRouteTable
+ CreateTrafficMirrorFilter
+ CreateTrafficMirrorFilterRule
+ CreateTrafficMirrorSession
+ CreateTrafficMirrorTarget
+ CreateVerifiedAccessEndpoint
+ CreateVerifiedAccessGroup
+ CreateVerifiedAccessInstance
+ CreateVerifiedAccessTrustProvider
+ CreateVolume
+ CreateVpcEndpoint
+ CreateVpcEndpointConnectionNotification
+ CreateVpcEndpointServiceConfiguration
+ DeleteVerifiedAccessEndpoint
+ DeleteVerifiedAccessGroup
+ DeleteVerifiedAccessInstance
+ DeleteVerifiedAccessTrustProvider
+ DetachVerifiedAccessTrustProvider
+ ExportImage
+ ImportImage
+ ImportSnapshot
+ ModifyInstanceCreditSpecification
+ ModifyLaunchTemplate
+ ModifyReservedInstances
+ ModifyVerifiedAccessEndpoint
+ ModifyVerifiedAccessEndpointPolicy
+ ModifyVerifiedAccessGroup
+ ModifyVerifiedAccessGroupPolicy
+ ModifyVerifiedAccessInstance
+ ModifyVerifiedAccessInstanceLoggingConfiguration
+ ModifyVerifiedAccessTrustProvider
+ ProvisionIpamPoolCidr
+ PurchaseHostReservation
+ RequestSpotFleet
+ RequestSpotInstances
+ RunInstances
+ StartNetworkInsightsAccessScopeAnalysis
+ StartNetworkInsightsAnalysis
**Types d'idempuissance**
+ Régional — Les demandes sont idempotentes dans chaque région. Cependant, vous pouvez utiliser la même demande, y compris le même jeton client, dans une région différente.
+ Zonal — Les demandes sont idempotentes dans chaque zone de disponibilité d'une région. Par exemple, si vous spécifiez le même jeton client lors de deux appels vers **AllocateHosts** la même région, les appels aboutissent s'ils spécifient des valeurs différentes pour le **AvailabilityZone** paramètre.
## RunInstances idempuissance
L'action de [RunInstances](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html)l'API utilise à la fois l'idempuissance régionale et zonale.
Le type d'idempuissance utilisé dépend de la manière dont vous spécifiez la zone de disponibilité dans votre demande d' RunInstances API. La demande utilise l'**idempotencie zonale** dans les cas suivants :
+ Si vous spécifiez explicitement une zone de disponibilité à l'aide du **AvailabilityZone**paramètre du type de données de **placement**
+ Si vous spécifiez implicitement une zone de disponibilité à l'aide du paramètre **SubnetId**
Si vous ne spécifiez pas explicitement ou implicitement de zone de disponibilité, la demande utilise l'**idempotencie régionale**.
### Idempotencie zonale
L'idempotencie zonale garantit qu'une demande d' RunInstances API est idempotente dans chaque zone de disponibilité d'une région. Cela garantit qu'une demande avec le même jeton client ne peut être traitée qu'une seule fois dans chaque zone de disponibilité d'une région. Toutefois, le même jeton client peut être utilisé pour lancer des instances dans d'autres zones de disponibilité de la région.
Par exemple, si vous envoyez une demande idempotente pour lancer une instance dans la zone de `us-east-1a` disponibilité, puis que vous utilisez le même jeton client dans une demande dans la zone de `us-east-1b` disponibilité, nous lançons des instances dans chacune de ces zones de disponibilité. Si un ou plusieurs paramètres sont différents, les tentatives suivantes avec le même jeton client dans ces zones de disponibilité sont soit renvoyées avec succès sans effectuer aucune autre action, soit échouer avec une `IdempotentParameterMismatch` erreur.
### Idempuissance régionale
L'idempuissance régionale garantit qu'une demande d' RunInstances API est idempotente dans une région. Cela garantit qu'une demande avec le même jeton client ne peut être traitée qu'une seule fois dans une région. Cependant, la même demande, avec le même jeton client, peut être utilisée pour lancer des instances dans une autre région.
Par exemple, si vous envoyez une demande idempotente pour lancer une instance dans la `us-east-1` région, puis que vous utilisez le même jeton client dans une demande dans la `eu-west-1` région, nous lançons des instances dans chacune de ces régions. Si un ou plusieurs paramètres sont différents, les tentatives suivantes avec le même jeton client dans ces régions sont soit renvoyées avec succès sans effectuer aucune autre action, soit échouer avec une `IdempotentParameterMismatch` erreur.
**Astuce**
Si l'une des zones de disponibilité de la région demandée n'est pas disponible, les RunInstances demandes utilisant l'idempuissance régionale peuvent échouer. Pour tirer parti des fonctionnalités de zone de disponibilité proposées par l' AWS infrastructure, nous vous recommandons d'utiliser l'idempotencie zonale lors du lancement des instances. RunInstances les demandes qui utilisent l'idempotencie zonale et ciblent une zone de disponibilité disponible aboutissent même si aucune autre zone de disponibilité dans la région demandée n'est disponible.
## Exemples
### AWS CLI exemples de commandes
Pour rendre une AWS CLI commande idempotente, ajoutez l'`--client-token`option.
**Exemple 1 : Idempotencie**
La commande [allocate-hosts](https://docs.aws.amazon.com/cli/latest/reference/ec2/allocate-hosts.html) suivante utilise l'idempotencie car elle inclut un jeton client.
```
aws ec2 allocate-hosts --instance-type m5.large --availability-zone eu-west-1a --auto-placement on --quantity 1 --client-token 550e8400-e29b-41d4-a716-446655440000
```
**Exemple 2 : idempotence régionale des instances d'exécution**
La commande [run-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html) suivante utilise l'idempotencie régionale car elle inclut un jeton client mais ne spécifie pas explicitement ou implicitement de zone de disponibilité.
```
aws ec2 run-instances --image-id ami-b232d0db --count 1 --key-name my-key-pair --client-token 550e8400-e29b-41d4-a716-446655440000
```
**Exemple 3 : idempotencie zonale des instances d'exécution**
La commande [run-instances](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html) suivante utilise l'idempotencie zonale car elle inclut un jeton client et une zone de disponibilité explicitement spécifiée.
```
aws ec2 run-instances --placement "AvailabilityZone=us-east-1a" --image-id ami-b232d0db --count 1 --key-name my-key-pair --client-token 550e8400-e29b-41d4-a716-446655440000
```
### Exemples de demandes d'API
Pour rendre une demande d'API idempotente, ajoutez le `ClientToken` paramètre.
**Exemple 1 : Idempotencie**
La demande [AllocateHosts](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AllocateHosts.html)d'API suivante utilise l'idempotencie car elle inclut un jeton client.
```
https://ec2.amazonaws.com/?Action=AllocateHosts
&AvailabilityZone=us-east-1b
&InstanceType=m5.large
&Quantity=1
&AutoPlacement=off
&ClientToken=550e8400-e29b-41d4-a716-446655440000
&AUTHPARAMS
```
**Exemple 2 : RunInstances idempuissance régionale**
La demande [RunInstances](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html)d'API suivante utilise l'idempotencie régionale car elle inclut un jeton client mais ne spécifie pas explicitement ou implicitement de zone de disponibilité.
```
https://ec2.amazonaws.com/?Action=RunInstances
&ImageId=ami-3ac33653
&MaxCount=1
&MinCount=1
&KeyName=my-key-pair
&ClientToken=550e8400-e29b-41d4-a716-446655440000
&AUTHPARAMS
```
**Exemple 3 : idempotence RunInstances zonale**
La demande [RunInstances](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html)d'API suivante utilise l'idempotencie zonale car elle inclut un jeton client et une zone de disponibilité explicitement spécifiée.
```
https://ec2.amazonaws.com/?Action=RunInstances
&Placement.AvailabilityZone=us-east-1d
&ImageId=ami-3ac33653
&MaxCount=1
&MinCount=1
&KeyName=my-key-pair
&ClientToken=550e8400-e29b-41d4-a716-446655440000
&AUTHPARAMS
```
## Recommandations de nouvelle tentative pour les demandes idempotentes
La table suivante présente certaines réponses courantes que vous pouvez obtenir pour les demandes d’API idempotentes et fournit des recommandations pour réessayer.
| Réponse | Recommandation | Commentaires |
| --- | --- | --- |
| 200 (OK) | Ne pas réessayer | La demande d’origine s’est terminée avec succès. Toutes les tentatives suivantes sont renvoyées avec succès. |
| Codes de réponse de la série 400 (erreurs [du client](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html#CommonErrors)) | Ne pas réessayer | La demande présente un problème, parmi les suivants : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/ec2/latest/devguide/ec2-api-idempotency.html) Si la demande concerne une ressource en train de changer d’état, il est possible que la nouvelle tentative aboutisse. |
| Codes de réponse de la série 500 ([erreurs du serveur](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/errors-overview.html#api-error-codes-table-server)) | Réessayer | L'erreur est due à un problème AWS côté serveur et est généralement transitoire. Répétez la demande avec une stratégie de backoff appropriée. |
# Limitation des demandes pour l'API Amazon EC2
Amazon EC2 limite les demandes EC2 d'API 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 à l' EC2 API Amazon ne dépassent pas les limites de demandes d'API maximales autorisées. Les demandes d'API 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 de limitation de l'API, le code `RequestLimitExceeded` d'erreur s'affiche.
**Topics**
+ [Comment l'étranglement est appliqué](#throttling-how)
+ [Limites de jetons de demande](#throttling-limits-rate-based)
+ [Limites des jetons de ressources](#throttling-limits-cost-based)
+ [Surveiller la régulation des API](#throttling-monitor)
+ [Réessais et recul exponentiel](#api-backoff)
+ [Demander une augmentation de limite](#throttling-increase)
## Comment l'étranglement est appliqué
Amazon EC2 utilise l'[algorithme Token Bucket](https://en.wikipedia.org/wiki/Token_bucket) pour implémenter la régulation des API. 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 d'étranglement à chaque seconde.
Amazon EC2 met en œuvre deux types de régulation des API :
**Topics**
+ [Limitation du débit de demande](#throttling-rate-based)
+ [Limitation du débit des ressources](#throttling-cost-based)
### Limitation du débit de demande
Avec la limitation du taux de demandes, chaque API est évaluée individuellement, et le nombre de demandes que vous faites par API est limité. Chaque demande que vous effectuez supprime un jeton du compartiment de l'API. Par exemple, la taille du compartiment de jetons pour `DescribeHosts` une action d'API *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é sur cette API et les demandes restantes échouent. Toutefois, les demandes pour d'autres API ne 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 nombre maximum de jetons. Par exemple, la taille du compartiment pour `DescribeHosts` une action d'API *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 effectuer des demandes d'API. 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 action d'API *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 demandes d'API par seconde, vous pouvez continuer à effectuer 20 demandes d'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 demandes d'API par seconde.
Pour de plus amples informations, veuillez consulter [Demandez la taille des seaux de jetons et les taux de recharge](#throttling-limits-rate-based).
### Limitation du débit des ressources
Certaines actions d'API, telles que `RunInstances` et`TerminateInstances`, 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 actions d'API disposent d'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 une API, y compris lorsqu'un compartiment n'est pas encore rempli pour prendre en charge la prochaine demande d'API, l'action de l'API est limitée même si vous n'avez pas atteint la limite totale de l'API.
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 autant de demandes d'API que vous le souhaitez, par exemple une demande pour 1 000 instances ou quatre demandes pour 250 instances. Une fois le compartiment de jetons de ressources 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](#throttling-limits-cost-based).
## Demandez la taille des seaux de jetons et les taux de recharge
Pour limiter le taux de demandes, les actions d'API sont regroupées dans les catégories suivantes :
+ Actions **non mutantes : actions d'**API qui récupèrent des données sur les ressources. Cette catégorie inclut généralement toutes les actions `Describe*` `List*``Search*`,, et d'`Get*`API, telles que `DescribeRouteTables``SearchTransitGatewayRoutes`, et`GetIpamPoolCidrs`. Ces actions d'API présentent généralement les limites de limitation d'API les plus élevées.
+ Actions **non mutantes non filtrées et non paginées : sous-ensemble spécifique d'actions** d'API non mutantes qui, lorsqu'elles sont demandées sans spécifier de [pagination](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-pagination.html) ni de [filtre](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/Using_Filtering.html#Filtering_Resources_CLI), 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 : actions** d'API qui créent, modifient ou suppriment des ressources. Cette catégorie inclut généralement toutes les actions d'API qui ne sont pas classées comme *des actions non mutantes*, telles que `AllocateHosts``ModifyHosts`, et. `CreateCapacityReservation` La limite de régulation de ces actions est inférieure à celle des actions d'API non mutantes.
+ **Actions gourmandes en ressources : actions** d'API mutantes qui prennent le plus de temps et consomment le plus de ressources. 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 de console : actions** d'API non mutantes demandées depuis la console Amazon. EC2 Ces actions d'API sont limitées séparément des autres actions d'API non mutantes.
+ **Actions non classées** : il s'agit d'actions d'API qui reçoivent leur propre taille de bucket de jetons et leurs propres taux de recharge, même si, par définition, elles entrent dans l'une des autres catégories.
| Catégorie d'action de l'API | Actions | Capacité maximale du compartiment | Taux de recharge du seau |
| --- | --- | --- | --- |
| Actions non mutantes | Les actions `Describe*``List*`,`Search*`, et `Get*` d'API qui ne sont pas incluses dans une autre catégorie. | 100 | 20 |
| Actions non mutantes non filtrées et non paginées | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/ec2/latest/devguide/ec2-api-throttling.html) | 50 | 10 |
| Actions mutantes | *Toutes les actions d'API mutantes qui ne sont pas des actions *gourmandes en ressources ou des actions* non classées.* | 50 | 5 |
| Actions gourmandes en ressources | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/ec2/latest/devguide/ec2-api-throttling.html) | 50 | 5 |
| Actions non mutantes de la console | Les actions`Describe*`, `List*``Search*`, et d'`Get*`API, qui sont appelées par la EC2 console Amazon, mais qui ne sont pas incluses dans une autre catégorie. | 100 | 10 |
| Actions non classées | Capacité maximale du compartiment | Taux de recharge du seau |
| --- | --- | --- |
| AcceptVpcEndpointConnections | 10 | 1 |
| AdvertiseByoipCidr | 1 | 0.1 |
| AssignIpv6Addresses | 100 | 5 |
| AssignPrivateIpAddresses | 100 | 5 |
| AssignPrivateNatGatewayAddress | 10 | 1 |
| AssociateCapacityReservationBillingOwner | 1 | 0.5 |
| AssociateEnclaveCertificateIamRole | 10 | 1 |
| AssociateIamInstanceProfile | 100 | 5 |
| AssociateNatGatewayAddress | 10 | 1 |
| AttachVerifiedAccessTrustProvider | 10 | 2 |
| AuthorizeClientVpnIngress | 5 | 2 |
| CancelDeclarativePoliciesReport | 1 | 1 |
| CopyImage | 100 | 1 |
| CreateClientVpnRoute | 5 | 2 |
| CreateCoipCidr | 5 | 1 |
| CreateCoipPool | 5 | 1 |
| CreateDefaultSubnet | 1 | 1 |
| CreateDefaultVpc | 1 | 1 |
| CreateLaunchTemplateVersion | 100 | 5 |
| CreateNatGateway | 10 | 1 |
| CreateNetworkInterface | 100 | 5 |
| CreateRestoreImageTask | 50 | 0.1 |
| CreateSnapshot | 100 | 5 |
| CreateSnapshots | 100 | 5 |
| CreateSpotDatafeedSubscription | 50 | 3 |
| CreateStoreImageTask | 50 | 0.1 |
| CreateSubnetCidrReservation | 5 | 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 |
| DeleteClientVpnRoute | 5 | 2 |
| DeleteCoipCidr | 5 | 1 |
| DeleteCoipPool | 5 | 1 |
| DeleteCoipPoolPermission | 5 | 1 |
| DeleteNatGateway | 10 | 1 |
| DeleteNetworkInterface | 100 | 5 |
| DeleteSnapshot | 100 | 5 |
| DeleteSpotDatafeedSubscription | 50 | 3 |
| DeleteSubnetCidrReservation | 5 | 1 |
| DeleteQueuedReservedInstances | 5 | 5 |
| DeleteTags | 100 | 10 |
| 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 |
| DescribeAggregateIdFormat | 10 | 10 |
| DescribeByoipCidrs | 1 | 0.5 |
| DescribeCapacityBlockExtensionOfferings | 10 | 0,15 |
| DescribeCapacityBlockOfferings | 10 | 0,15 |
| DescribeDeclarativePoliciesReports | 5 | 5 |
| DescribeHostReservations | 5 | 2 |
| DescribeHostReservationOfferings | 5 | 2 |
| DescribeIdentityIdFormat | 10 | 10 |
| DescribeIdFormat | 10 | 10 |
| DescribeInstanceTopology | 1 | 1 |
| DescribeMovingAddresses | 1 | 1 |
| DescribePrincipalIdFormat | 10 | 10 |
| DescribeReservedInstancesOfferings | 10 | 10 |
| DescribeSecurityGroupReferences | 20 | 5 |
| DescribeSpotDatafeedSubscription | 100 | 13 |
| DescribeSpotFleetInstances | 100 | 5 |
| DescribeSpotFleetRequestHistory | 100 | 5 |
| DescribeSpotFleetRequests | 50 | 3 |
| DescribeStaleSecurityGroups | 20 | 5 |
| DescribeStoreImageTasks | 50 | 0.5 |
| DescribeVerifiedAccessInstanceLoggingConfigurations | 10 | 2 |
| DetachVerifiedAccessTrustProvider | 10 | 2 |
| DisableFastLaunch | 5 | 2 |
| DisableImageBlockPublicAccess | 1 | 0.1 |
| DisableSnapshotBlockPublicAccess | 1 | 0.1 |
| DisassociateCapacityReservationBillingOwner | 1 | 0.5 |
| DisassociateEnclaveCertificateIamRole | 10 | 1 |
| DisassociateIamInstanceProfile | 100 | 5 |
| DisassociateNatGatewayAddress | 10 | 1 |
| EnableFastLaunch | 5 | 2 |
| EnableImageBlockPublicAccess | 1 | 0.1 |
| EnableSnapshotBlockPublicAccess | 1 | 0.1 |
| GetAssociatedEnclaveCertificateIamRoles | 10 | 1 |
| GetDeclarativePoliciesReportSummary | 5 | 5 |
| GetHostReservationPurchasePreview | 5 | 2 |
| ModifyImageAttribute | 100 | 5 |
| ModifyInstanceMetadataDefaults | 2 | 2 |
| 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 |
| PurchaseCapacityBlockExtension | 10 | 0,15 |
| PurchaseHostReservation | 5 | 2 |
| PurchaseReservedInstancesOffering | 5 | 5 |
| RejectVpcEndpointConnections | 10 | 1 |
| RestoreAddressToClassic | 1 | 1 |
| RevokeClientVpnIngress | 5 | 2 |
| RunInstances | 5 | 2 |
| StartDeclarativePoliciesReport | 1 | 1 |
| 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 actions d'API qui utilisent la limitation du débit des ressources.
| Action d’API | 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 |
## Surveiller la régulation des API
Vous pouvez utiliser Amazon CloudWatch pour surveiller vos demandes d' EC2 API Amazon et pour collecter et suivre les indicateurs relatifs à la limitation des API. Vous pouvez également créer une alarme pour vous avertir lorsque vous êtes sur le point d'atteindre les limites de limitation de l'API. Pour de plus amples informations, veuillez consulter [Surveillez les demandes EC2 d'API Amazon à l'aide d'Amazon CloudWatchSurveillez les demandes d'API à l'aide CloudWatch](monitor.md).
## Réessais et recul exponentiel
Il se peut que votre application doive réessayer une demande d'API. 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.
**Modifications de l'état 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 demandes d'API. 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'EC2 instance** pour vous informer d'un changement d'état d'une instance. Pour plus d'informations, consultez [Automatiser EC2 l'utilisation d'Amazon EventBridge](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/automating_with_eventbridge.html).
**Nouvelles tentatives**
Lorsque vous devez interroger ou réessayer une demande d'API, nous vous recommandons d'utiliser un algorithme de ralentissement exponentiel pour calculer l'intervalle de sommeil entre les demandes d'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 de plus amples informations, consultez la section [Délais d’attente, nouvelles tentatives et backoff avec instabilité](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/).
Chaque AWS SDK implémente une logique de nouvelle tentative automatique. Pour plus d'informations, consultez la section [Comportement](https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html) 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 limitation des API pour votre. Compte AWS
**Recommandations**
+ Demandez au maximum trois fois votre limite existante en une seule demande.
+ Priorisez l'augmentation du taux de remplissage des seaux avant d'augmenter la capacité maximale des seaux.
+ Si le taux de remplissage du seau demandé dépasse la capacité maximale du seau, augmentez simultanément la capacité maximale du seau.
+ Fournissez toutes les actions d'API qui nécessitent une augmentation. Les limites sont appliquées à des actions d'API individuelles, et non à des catégories d'actions d'API.
+ Il existe des limites de taux de demande et de débit de ressources pour les actions d'API suivantes : `RunInstances``StartInstances`,`StopInstances`, et`TerminateInstances`. Assurez-vous d'indiquer quelle limite doit être augmentée
**Pour demander l'accès à cette fonctionnalité**
1. [AWS Support Centre](https://console.aws.amazon.com/support/home#/) ouvert.
1. Choisissez **Create case** (Créer une demande).
1. Choisissez **Compte et facturation**.
1. Pour le **service**, sélectionnez **Informations générales et Mise en route**.
1. Dans **Catégorie**, choisissez **Utilisation AWS et services**.
1. Choisissez **Étape suivante : informations supplémentaires**.
1. Pour **Subject (Objet)**, saisissez **Request an increase in my Amazon EC2 API throttling limits**.
1. Pour **Description**, copiez le modèle suivant et fournissez les informations requises.
```
Please increase the API throttling limits for my account.
Related page: https://docs.aws.amazon.com/ec2/latest/devguide/ec2-api-throttling.html
Description: Brief notes about your use case. If available, include the IDs
of a few Amazon EC2 requests that were throttled.
Time window: One-hour window when peak throttling or usage occurred.
region_1 request rate increases:
action: new_bucket_maximum_capacity
action: new_bucket_refill_rate
action: new_bucket_maximum_capacity|new_bucket_refill_rate
region_1 resource rate increases:
action: new_bucket_maximum_capacity
action: new_bucket_refill_rate
action: new_bucket_maximum_capacity|new_bucket_refill_rate
region_2 request rate increases:
action: new_bucket_maximum_capacity
action: new_bucket_refill_rate
action: new_bucket_maximum_capacity|new_bucket_refill_rate
region_2 resource rate increases:
action: new_bucket_maximum_capacity
action: new_bucket_refill_rate
action: new_bucket_maximum_capacity|new_bucket_refill_rate
```
1. Cliquez sur **Étape suivante : résoudre maintenant ou nous contacter**.
1. Dans l'onglet **Contactez-nous**, choisissez la langue de contact et le mode de contact que vous préférez.
1. Cliquez sur **Envoyer**.
# Pagination dans l'API Amazon EC2
Nous vous recommandons d'utiliser la pagination lorsque vous appelez des actions de description susceptibles de renvoyer un grand nombre de résultats, telles que`DescribeInstances`. L'utilisation de la pagination limite le nombre d'éléments renvoyés par un appel de description et le temps nécessaire au retour de l'appel. Si vous disposez d'un grand nombre de ressources, les appels non paginés risquent d'être limités et d'expirer. Par conséquent, la latence globale est meilleure avec les appels paginés qu'avec les appels non paginés, car les appels paginés sont toujours réussis.
Pour plus d'informations, consultez la section [Pagination](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/Query-Requests.html#api-pagination) dans le manuel *Amazon EC2 API Reference*.
## Bonnes pratiques
Dans la mesure du possible, spécifiez une liste de ressources IDs dans vos appels de description. C'est le moyen le plus rapide de décrire un grand nombre de ressources. Notez que vous ne devez pas IDs en spécifier plus de 1 000 par appel. Voici un exemple.
```
private List describeMyInstances(List ids){
if (ids == null || ids.isEmpty()) {
return ImmutableList.of();
}
final DescribeInstancesRequest request = new DescribeInstancesRequest()
.withInstanceIds(ids);
return ec2.describeInstances(request).getReservations();
}
```
Si vous ne pouvez pas spécifier de ressource IDs dans vos appels de description, nous vous recommandons vivement d'utiliser la pagination. Voici un exemple.
```
private List describeMyInstances(final Collection filters){
final DescribeInstancesRequest request = new DescribeInstancesRequest()
.withFilters(filters)
.withMaxResults(1000);
List reservations = new ArrayList<>();
String nextToken = null;
do {
request.setNextToken(nextToken);
final DescribeInstancesResult response = ec2.describeInstances(request);
reservations.addAll(response.getReservations());
nextToken = response.getNextToken();
} while (nextToken != null);
return reservations;
}
```
Si vous devez réessayer un appel paginé, utilisez le [back-off exponentiel](ec2-api-throttling.md#api-backoff) avec gigue.
## Problèmes courants
Voici des exemples de code qui effectue par inadvertance des appels non paginés.
**Example Exemple de problème : transmission d'une liste de ressources vide IDs**
Le code suivant utilise une liste de IDs. Toutefois, si la liste est vide, le résultat est un appel non paginé.
```
private List describeMyInstances(List ids){
final DescribeInstancesRequest request = new DescribeInstancesRequest()
.withInstanceIds(ids);
return ec2.describeInstances(request).getReservations();
}
```
Pour corriger ce problème, assurez-vous que la liste n'est pas vide avant de lancer l'appel de description.
```
private List describeMyInstances(List ids){
if (ids == null || ids.isEmpty()) {
return ImmutableList.of();
// OR
return Lists.newArrayList();
// OR
return new ArrayList<>();
}
final DescribeInstancesRequest request = new DescribeInstancesRequest()
.withInstanceIds(ids);
return ec2.describeInstances(request).getReservations();
}
```
**Example Exemple de problème : ne pas régler MaxResults**
Le code suivant vérifie et utilise`nextToken`, mais ne définit pas`MaxResults`.
```
private List describeMyInstances(final Collection filters){
final DescribeInstancesRequest request = new DescribeInstancesRequest()
.withFilters(filters);
List reservations = new ArrayList<>();
String nextToken = null;
do {
request.setNextToken(nextToken);
final DescribeInstancesResult response = ec2.describeInstances(request);
reservations.addAll(response.getReservations());
nextToken = response.getNextToken();
} while (nextToken != null);
return reservations;
}
```
Pour corriger ce problème, ajoutez ce qui `withMaxResults` suit.
```
private List describeMyInstances(final Collection filters){
final DescribeInstancesRequest request = new DescribeInstancesRequest()
.withFilters(filters)
.withMaxResults(1000);
List reservations = new ArrayList<>();
String nextToken = null;
do {
request.setNextToken(nextToken);
final DescribeInstancesResult response = ec2.describeInstances(request);
reservations.addAll(response.getReservations());
nextToken = response.getNextToken();
} while (nextToken != null);
return reservations;
}
```