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.
# Lancer des instances de manière synchrone
Amazon EC2 Auto Scaling propose deux méthodes pour lancer des instances dans votre groupe Auto Scaling : le comportement de dimensionnement asynchrone et le provisionnement synchrone à l'aide de l'API. LaunchInstances
Avec le provisionnement synchrone, vous utilisez l' LaunchInstances API pour demander un nombre spécifique d'instances dans une zone de disponibilité donnée. Le provisionnement synchrone offre les avantages suivants :
+ Feedback immédiat sur la disponibilité des capacités dans des zones de disponibilité spécifiques
+ Contrôle précis des instances de zone de disponibilité lancées dans
+ Instance déterministe IDs pour une utilisation immédiate dans les systèmes d'orchestration
+ Décisions de dimensionnement en temps réel basées sur les contraintes de capacité réelles
+ Mise à l'échelle plus rapide en éliminant les temps d'attente pour les lancements asynchrones d'Auto Scaling
Avec Auto Scaling asynchrone, lorsque vous modifiez la capacité souhaitée ou lorsqu'une politique de dimensionnement se déclenche, Amazon EC2 Auto Scaling traite la demande de dimensionnement et lance les instances en arrière-plan. Vous devez surveiller les activités de dimensionnement ou décrire votre groupe Auto Scaling pour déterminer à quel moment les instances sont lancées avec succès.
**Note**
L' LaunchInstances API fonctionne uniquement avec les groupes Auto Scaling qui utilisent des modèles de lancement. Les groupes Auto Scaling qui utilisent des configurations de lancement ne sont pas pris en charge. Si votre groupe Auto Scaling utilise une configuration de lancement, vous devez migrer vers un modèle de lancement avant d'utiliser le provisionnement synchrone.
L' LaunchInstances API prend en charge les politiques relatives aux instances mixtes avec des options d'achat entièrement à la demande ou entièrement ponctuelles uniquement. Les politiques mixtes combinant à la fois des instances à la demande et des instances ponctuelles ne sont pas prises en charge.
Pour les groupes Auto Scaling couvrant plusieurs zones de disponibilité, vous devez spécifier la zone de disponibilité ou le sous-réseau cible. Pour les groupes mono-AZ, ce paramètre est facultatif.
## Provisionnement synchrone et dimensionnement asynchrone
### Provisionnement synchrone
Lorsque vous utilisez l' LaunchInstances API, Amazon EC2 Auto Scaling :
+ Tente immédiatement de lancer les instances demandées en utilisant CreateFleet
+ Attend de renvoyer CreateFleet l'instance IDs avant de répondre
+ Renvoie les informations relatives à IDs l'instance, aux types d'instances et à la zone de disponibilité en cas de réussite
+ Renvoie des codes d'erreur spécifiques et des informations sur les défaillances
+ Fournit un feedback immédiat, permettant de prendre des décisions de dimensionnement en temps réel
### Mise à l'échelle asynchrone
Lorsque vous utilisez des méthodes Auto Scaling asynchrones, telles que la modification de la capacité souhaitée ou l'utilisation de politiques de dimensionnement, Amazon EC2 Auto Scaling :
+ Met à jour la capacité souhaitée dans l'API mais ne renvoie pas les instances immédiatement
+ Planifie automatiquement les lancements d'instances dans les zones de disponibilité
+ Lance des instances via des flux de travail en arrière-plan
+ Répartit automatiquement la capacité entre plusieurs zones de disponibilité à des fins d'équilibre
+ Gère les échecs de lancement grâce à une logique de nouvelle tentative intégrée
Vous devez interroger les activités de dimensionnement ou décrire votre groupe Auto Scaling pour vérifier l'état des opérations de lancement.
## Limites et considérations
Lorsque vous utilisez le provisionnement synchrone, gardez à l'esprit les remarques et limites suivantes :
+ **État de l'instance après le lancement** : les instances renvoyées par l'API sont en attente. Ils peuvent toujours échouer lors des processus de flux de travail ou des accrochages du cycle de vie ultérieurs. Une réponse d'API réussie signifie qu'EC2 a accepté la demande de lancement et renvoyé les ID d'instance. Les instances ne sont pas automatiquement considérées comme entièrement prêtes pour les charges de travail et doivent suivre les processus de cycle de vie standard EC2 et Auto Scaling.
+ **Limitation des pools de chaleur** — Les groupes Auto Scaling avec des pools de chaleur ne sont actuellement pas pris en charge. Si vous tentez d'appeler l' LaunchInstances API sur un groupe Auto Scaling sur lequel un pool de chaleur est configuré, l'API effectue un démarrage à froid au lieu d'utiliser des instances de pool de chauffage et renvoie une UnsupportedOperation erreur. Pour plus d'informations sur les démarrages à froid, consultez [la section Limitations relatives aux piscines chaudes](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-warm-pools.html#warm-pools-limitations).
+ **Expiration de l'API et nouvelles tentatives** : si l' CreateFleet opération sous-jacente prend plus de temps que prévu, l'API peut expirer et renvoyer un jeton d'idempuissance. Vous pouvez réessayer de l'utiliser ClientToken pour suivre l'opération de lancement initiale ou utiliser describe-instances avec le jeton client pour vérifier les instances lancées.
+ **Contraintes liées aux zones de disponibilité** : si votre groupe Auto Scaling couvre plusieurs zones de disponibilité et que le rééquilibrage des zones de disponibilité est activé, le lancement synchrone des instances peut provoquer des conflits opérationnels :
+ Limitation d'une seule zone de disponibilité par appel : chaque appel d' LaunchInstances API ne peut cibler qu'une seule zone de disponibilité, même si votre groupe Auto Scaling couvre plusieurs zones.
+ Conflits de rééquilibrage AZ - Si le rééquilibrage AZ est activé dans votre groupe Auto Scaling, les appels séquentiels entre différents groupes AZs peuvent déclencher des lancements asynchrones supplémentaires, ce qui se traduit par un nombre d'instances supérieur à celui prévu. Envisagez de suspendre le rééquilibrage AZ pour un contrôle précis de la capacité. Pour de plus amples informations, veuillez consulter [Suspendre et reprendre les processus Amazon EC2 Auto Scaling](as-suspend-resume-processes.md).
+ **Scénarios de réussite partielle** — L'`LaunchInstances`API peut renvoyer un succès partiel si seule une partie de la capacité demandée est disponible, ce qui correspond au comportement normal d'EC2. L'API renvoie les instances lancées avec succès ainsi que les détails des erreurs en cas d'échec des lancements. Pour les cas d'utilisation nécessitant le lancement simultané de toutes les instances (comme les applications nécessitant toutes les instances dans la même zone de disponibilité pour une faible latence), vous devez mettre fin aux instances partiellement lancées et réessayer dans une autre zone de disponibilité. Tenez compte de ce comportement lors de la conception d'une logique de nouvelle tentative pour les charges de travail sensibles à la capacité.
+ **Pondérations d'instance** : si votre groupe Auto Scaling utilise des poids d'instance, le RequestedCapacity paramètre représente les unités de capacité pondérées, et non le nombre d'instances. Le nombre réel d'instances lancées dépend des types d'instances sélectionnés et de leurs poids configurés. EC2 Auto Scaling limite les lancements à 100 instances par appel d'API, quelle que soit la capacité pondérée demandée.
+ **Types d'instances mixtes** : l' LaunchInstances API utilise la politique d'instances mixtes existante de votre groupe Auto Scaling pour déterminer les types d'instances à lancer. L'API lance les instances en fonction de la stratégie d'allocation de votre groupe et des priorités relatives aux types d'instances.
# Lancement d'instances avec provisionnement synchrone
Vous pouvez utiliser l' LaunchInstances API pour lancer de manière synchrone un nombre spécifique d'instances dans votre groupe Auto Scaling. L'API lance des instances dans la zone de disponibilité ou le sous-réseau que vous spécifiez et renvoie immédiatement les informations relatives à l'instance IDs ou à l'erreur.
## Conditions préalables
Avant de pouvoir utiliser l' LaunchInstances API, vous devez disposer des éléments suivants :
+ Un groupe Auto Scaling qui utilise un modèle de lancement (les configurations de lancement ne sont pas prises en charge)
+ Vous devez disposer d'autorisations pour les actions IAM suivantes :
+ `autoscaling:LaunchInstances`
+ `ec2:CreateFleet`
+ `ec2:DescribeLaunchTemplateVersions`
## Lancer des instances avec un provisionnement synchrone
Vous pouvez lancer des instances avec un provisionnement synchrone via le. AWS CLI
### AWS CLI
Pour lancer des instances avec un provisionnement synchrone :
```
aws autoscaling launch-instances \
--auto-scaling-group-name group-name \
--requested-capacity number \
[--availability-zones zone-name] \
[--subnet-ids subnet-id] \
[--availability-zone-ids zone-id] \
[--retry-strategy none|retry-with-group-configuration] \
[--client-token token]
```
#### Exemples
**Lancement d'instances dans une zone de disponibilité spécifique**
```
aws autoscaling launch-instances \
--auto-scaling-group-name my-asg \
--requested-capacity 3 \
--availability-zones us-east-1a \
--retry-strategy retry-with-group-configuration
```
**Lancement d'instances dans un sous-réseau spécifique**
```
aws autoscaling launch-instances \
--auto-scaling-group-name my-asg \
--requested-capacity 2 \
--subnet-ids subnet-12345678 \
--retry-strategy none \
--client-token my-unique-token-123
```
#### Gestion des réponses
**Exemple de réponse réussie :**
```
{
"AutoScalingGroupName": "my-asg",
"ClientToken": "my-unique-token-123",
"Instances": [
{
"InstanceType": "m5.xlarge",
"AvailabilityZone": "us-east-1a",
"AvailabilityZoneId": "use1-az1",
"SubnetId": "subnet-12345678",
"MarketType": "OnDemand",
"InstanceIds": ["i-0123456789abcdef0", "i-0fedcba9876543210"]
}
],
"Errors": []
}
```
**Exemple de réponse comportant des erreurs**
```
{
"AutoScalingGroupName": "my-asg",
"ClientToken": "my-unique-token-123",
"Instances": [],
"Errors": [
{
"InstanceType": "m5.large",
"AvailabilityZone": "us-east-1a",
"AvailabilityZoneId": "use1-az1",
"SubnetId": "subnet-12345678",
"MarketType": "OnDemand",
"ErrorCode": "InsufficientInstanceCapacity",
"ErrorMessage": "There is not enough capacity to fulfill your request for instance type 'm5.large' in 'us-east-1a'"
}
]
}
```
## Gérer les échecs de lancement et les nouvelles tentatives
Lorsque l' LaunchInstances API rencontre des échecs, vous pouvez mettre en œuvre des stratégies de nouvelle tentative à l'aide de jetons d'idempotencie et de politiques de nouvelle tentative appropriées.
Vous pouvez utiliser le paramètre client-token pour réessayer les demandes. Vous pouvez également utiliser les stratégies de nouvelle tentative suivantes :
+ `RetryStrategy: none`(par défaut) - Si l'appel d'API échoue, la capacité souhaitée du groupe Auto Scaling reste inchangée et aucune nouvelle tentative automatique n'est effectuée.
+ `RetryStrategy: retry-with-group-configuration`- Si l'appel d'API échoue, la capacité souhaitée du groupe Auto Scaling est augmentée du montant demandé, et Auto Scaling réessaiera automatiquement de lancer des instances en utilisant la configuration et les processus standard du groupe.
Le comportement des nouvelles tentatives `RetryStrategy: retry-with-group-configuration` dépend du type d'échec :
+ **Erreurs de validation** : la capacité souhaitée n'est pas augmentée car l'opération ne peut pas se poursuivre. Par exemple, des paramètres non valides ou des configurations non prises en charge.
+ **Erreurs de capacité** : la capacité souhaitée est augmentée et Auto Scaling réessaiera de lancer des instances de manière asynchrone en utilisant les processus de dimensionnement habituels du groupe.
### Utilisation de jetons clients pour l'idempuissance
Le `client-token` paramètre garantit des opérations idempotentes et permet de réessayer en toute sécurité les demandes de lancement.
Comportements clés :
+ Les jetons clients ont une durée de vie de 8 heures à compter de la demande initiale
+ Une nouvelle tentative avec le même jeton client dans les 8 heures renvoie la réponse mise en cache au lieu de lancer de nouvelles instances
+ Après 8 heures, le même jeton client lancera une nouvelle opération de lancement