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.
# FAQ
Vous trouverez ci-dessous FAQs des réponses aux questions les plus fréquemment posées.
**Topics**
+ [Quelles AWS OpsWorks Stacks versions puis-je migrer ?](#w2ab1c14c43c19b7)
+ [Quelles versions de Chef peuvent utiliser mes instances migrées ?](#w2ab1c14c43c19b9)
+ [Quels types de référentiels puis-je migrer ?](#w2ab1c14c43c19c11)
+ [Puis-je continuer à utiliser un dépôt Git privé ?](#w2ab1c14c43c19c13)
+ [Quelles clés SSH puis-je utiliser pour accéder à mes instances ?](#w2ab1c14c43c19c15)
+ [Pourquoi mes instances évoluent-elles automatiquement vers l'avant et vers l'extérieur ?](#w2ab1c14c43c19c17)
+ [Puis-je désactiver Auto Scaling ?](#w2ab1c14c43c19c19)
+ [Puis-je effectuer des mises à jour du noyau et des packages sur les EC2 instances lancées ?](#w2ab1c14c43c19c21)
+ [Pourquoi les volumes EBS de mes instances ne contiennent-ils aucune donnée ?](#w2ab1c14c43c19c23)
+ [Pourquoi les volumes EBS décrits dans mon modèle de lancement ne sont-ils pas montés ?](#w2ab1c14c43c19c25)
+ [Où puis-je trouver les journaux de volume des recettes Chef et Mount EBS ?](#w2ab1c14c43c19c27)
+ [Où puis-je trouver le journal de débogage du script de migration ?](#w2ab1c14c43c19c29)
+ [Le script de migration prend-il en charge la gestion des versions des CloudFormation modèles ?](#w2ab1c14c43c19c31)
+ [Puis-je migrer plusieurs couches ?](#w2ab1c14c43c19c33)
+ [Comment créer un `SecureString` paramètre ?](#w2ab1c14c43c19c35)
+ [Comment protéger les instances du nouveau groupe Auto Scaling contre les événements de résiliation ?](#w2ab1c14c43c19c37)
+ [Quels équilibreurs de charge sont disponibles avec le script de migration ?](#w2ab1c14c43c19c39)
+ [Les recettes de configuration de livres de recettes personnalisées sont-elles migrées ?](#w2ab1c14c43c19c41)
+ [Puis-je exécuter des recettes de déploiement et de dédéploiement sur mes instances nouvellement créées ?](#w2ab1c14c43c19c43)
+ [Puis-je modifier les sous-réseaux couverts par mon groupe Auto Scaling ?](#w2ab1c14c43c19c45)
## Quelles AWS OpsWorks Stacks versions puis-je migrer ?
Vous ne pouvez migrer que les stacks Chef 11.10 et Chef 12, Amazon Linux, Amazon Linux 2, Ubuntu et Red Hat Enterprise Linux 7.
## Quelles versions de Chef peuvent utiliser mes instances migrées ?
Les instances migrées peuvent utiliser les versions 11 à 14 de Chef.
**Note**
La migration vers Windows Stack n'est pas prise en charge.
## Quels types de référentiels puis-je migrer ?
Vous pouvez migrer les types de référentiels S3, Git et HTTP.
## Puis-je continuer à utiliser un dépôt Git privé ?
Oui, vous pouvez continuer à utiliser un dépôt Git privé.
Si vous utilisez un GitHub dépôt privé, vous devez créer une nouvelle clé d'`Ed25519`hôte pour SSH. Cela est dû au fait que les clés prises en charge par SSH ont été GitHub modifiées et le protocole Git non chiffré a été supprimé. Pour plus d'informations sur la clé `Ed25519` d'hôte, consultez le billet de GitHub blog [Améliorer la sécurité du protocole Git sur GitHub](https://github.blog/2021-09-01-improving-git-protocol-security-github/). Après avoir généré une nouvelle clé `Ed25519` d'hôte, créez un `SecureString` paramètre Systems Manager pour cette clé SSH et utilisez le nom du paramètre comme valeur du `--repo-private-key` paramètre. Pour plus d'informations sur la création d'un `SecureString` paramètre Systems Manager, voir [Create a SecureString parameter (AWS CLI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/param-create-cli.html#param-create-cli-securestring) dans le *Guide de AWS Systems Manager l'utilisateur*.
Pour tout autre type de dépôt Git, créez un `SecureString` paramètre Systems Manager pour cette clé SSH et utilisez le nom du paramètre comme valeur du `--repo-private-key` paramètre du script.
## Quelles clés SSH puis-je utiliser pour accéder à mes instances ?
Lorsque vous exécutez le script, celui-ci migre les clés SSH et les instances configurées dans la pile. Vous pouvez utiliser les clés SSH pour accéder à votre instance. Si des clés SSH sont fournies pour la pile et l'instance, le script utilise les clés de la pile. Si vous ne savez pas quelles clés SSH utiliser, consultez les instances dans la EC2 console ([https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)). La page **Détails** de la EC2 console affiche les clés SSH de votre instance.
## Pourquoi mes instances évoluent-elles automatiquement vers l'avant et vers l'extérieur ?
Auto Scaling redimensionne les instances en fonction des règles de dimensionnement du groupe Auto Scaling. Vous pouvez définir les valeurs de **capacité **minimale**, **maximale** et souhaitée** pour votre groupe. Le groupe Auto Scaling adapte automatiquement votre capacité en conséquence lorsque vous mettez à jour ces valeurs.
## Puis-je désactiver Auto Scaling ?
Vous pouvez désactiver Auto Scaling en définissant les valeurs de **capacité **minimale**, **maximale** et souhaitée** du groupe Auto Scaling sur le même nombre. Par exemple, si vous souhaitez toujours avoir dix instances, définissez les valeurs de **capacité **minimale**, **maximale** et souhaitée** sur dix.
## Puis-je effectuer des mises à jour du noyau et des packages sur les EC2 instances lancées ?
Par défaut, les mises à jour du noyau et des packages ont lieu au démarrage de l' EC2 instance. Procédez comme suit pour effectuer des mises à jour du noyau ou du package sur une EC2 instance lancée. Par exemple, vous souhaiterez peut-être appliquer des mises à jour après avoir exécuté des recettes de déploiement ou de configuration.
1. Connectez-vous à votre EC2 instance.
1. Créez la `perform_upgrade` fonction suivante et exécutez-la sur votre instance.
```
perform_upgrade() {
#!/bin/bash
if [ -e '/etc/system-release' ] || [ -e '/etc/redhat-release' ]; then
sudo yum -y update
elif [ -e '/etc/debian_version' ]; then
sudo apt-get update
sudo apt-get dist-upgrade -y
fi
}
perform_upgrade
```
1. Après les mises à jour du noyau et du package, vous devrez peut-être redémarrer votre EC2 instance. Pour vérifier si un redémarrage est nécessaire, créez la `reboot_if_required` fonction suivante et exécutez-la sur votre EC2 instance.
```
reboot_if_required () {
#!/bin/bash
if [ -e '/etc/debian_version' ]; then
if [ -f /var/run/reboot-required ]; then
echo "reboot is required"
else
echo "reboot is not required"
fi
elif [ -e '/etc/system-release' ] || [ -e '/etc/redhat-release' ]; then
export LC_CTYPE=en_US.UTF-8
export LC_ALL=en_US.UTF-8
LATEST_INSTALLED_KERNEL=`rpm -q --last kernel | perl -X -pe 's/^kernel-(\S+).*/$1/' | head -1`
CURRENTLY_USED_KERNEL=`uname -r`
if [ "${LATEST_INSTALLED_KERNEL}" != "${CURRENTLY_USED_KERNEL}" ];then
echo "reboot is required"
else
echo "reboot is not required"
fi
fi
}
reboot_if_required
```
1. Si les `reboot_if_required` résultats sont affichés dans un `reboot is required` message, redémarrez l' EC2 instance. Si vous recevez un `reboot is not required` message, il n'est pas nécessaire de redémarrer l' EC2 instance.
## Pourquoi les volumes EBS de mes instances ne contiennent-ils aucune donnée ?
Lorsque vous exécutez le script, celui-ci migre la configuration des volumes EBS, créant ainsi une architecture de remplacement pour votre OpsWorks pile et votre couche. Le script ne migre pas les instances réelles ni les données qu'elles contiennent. Le script migre uniquement la configuration des volumes EBS au niveau de la couche et attache les volumes EBS vides aux instances lancées. EC2
Procédez comme suit pour extraire les données des volumes EBS de vos instances précédentes.
1. Prenez un instantané des volumes EBS de vos instances précédentes. Pour plus d'informations sur la création d'un instantané, consultez la section [Créer un instantané Amazon EBS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html) dans le *guide de l' EC2 utilisateur Amazon*.
1. Créez un volume à partir de votre instantané. Pour plus d'informations sur la création d'un volume à partir d'un instantané, consultez la section [Créer un volume à partir d'un instantané](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-volume.html#ebs-create-volume-from-snapshot) dans le *guide de EC2 l'utilisateur Amazon*.
1. Attachez le volume que vous avez créé aux instances. Pour plus d'informations sur l'attachement de volumes, consultez la section [Attacher un volume Amazon EBS à une instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-attaching-volume.html) dans le *guide de l' EC2 utilisateur Amazon*.
## Pourquoi les volumes EBS décrits dans mon modèle de lancement ne sont-ils pas montés ?
Si vous fournissez un ID de modèle de lancement pour le `--launch-template` paramètre avec les volumes EBS, le script attache les volumes EBS, mais ne les monte pas. Vous pouvez monter les volumes EBS attachés en exécutant le `MountEBSVolumes` RunCommand document créé par le script pour l' EC2 instance lancée.
Si vous ne définissez aucun `--launch-template` paramètre, le script crée un modèle, et lorsque le groupe Auto Scaling lance une nouvelle EC2 instance, le groupe Auto Scaling attache automatiquement les volumes EBS, puis exécute la `SetupAutomation` commande pour monter les volumes attachés aux points de montage configurés dans les paramètres de couche.
## Où puis-je trouver les journaux de volume des recettes Chef et Mount EBS ?
OpsWorks fournit les journaux dans un compartiment S3 que vous pouvez spécifier en fournissant une valeur pour le `--command-logs-bucket` paramètre. Le nom du compartiment S3 par défaut est au format :`aws-opsworks-stacks-application-manager-logs-account-id`. Les journaux de recettes du chef sont stockés dans le `ApplyChefRecipes` préfixe. Les journaux du volume Mount EBS sont stockés dans le `MountEBSVolumes` préfixe. Toutes les couches migrées à partir d'une pile fournissent des journaux vers le même compartiment S3.
**Note**
La configuration du cycle de vie du compartiment S3 inclut une règle permettant de supprimer les journaux après 30 jours. Si vous souhaitez conserver les journaux pendant plus de 30 jours, vous devez mettre à jour la règle dans la configuration du cycle de vie du compartiment S3.
Actuellement, il enregistre OpsWorks uniquement le chef `setup` et les `terminate` recettes.
## Où puis-je trouver le journal de débogage du script de migration ?
Le script place les journaux de débogage dans un compartiment nommé`aws-opsworks-stacks-transition-logs-account-id`. Les journaux de débogage se trouvent dans le `migration_script` dossier du compartiment S3, sous les dossiers qui correspondent au nom de la couche que vous avez migrée.
## Le script de migration prend-il en charge la gestion des versions des CloudFormation modèles ?
Le script génère des documents Systems Manager de type CloudFormation qui remplacent la couche ou la pile que vous souhaitez migrer. La réexécution du script, même avec les mêmes paramètres, permet d'exporter une nouvelle version du modèle de couche précédemment exporté. Les versions du modèle sont stockées dans le même compartiment S3 que les journaux de script.
## Puis-je migrer plusieurs couches ?
Le `--layer-id` paramètre du script est transmis dans une seule couche. Pour migrer plusieurs couches, réexécutez le script et transmettez-en un autre`--layer-id`.
Les couches faisant partie d'une même OpsWorks pile sont répertoriées sous la même application dans Application Manager.
1. Ouvrez la console Systems Manager à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le volet de navigation, choisissez **Application Manager**.
1. Dans la section **Applications**, sélectionnez **Applications personnalisées**.
1. Choisissez votre application. Le nom de l'application commence par`app-stack-name-first-six-characters-stack-id`.
1. L'élément de niveau supérieur, commençant par app, montre tous les composants qui correspondent à votre OpsWorks pile. Cela inclut les composants correspondant à votre OpsWorks couche.
1. Choisissez le composant correspondant à la couche pour afficher les ressources de la couche. Les composants représentant les OpsWorks couches sont également visibles dans la section **Applications personnalisées** en tant qu'applications individuelles.
## Comment créer un `SecureString` paramètre ?
Vous pouvez utiliser Systems Manager pour créer un `SecureString` paramètre. Pour plus d'informations sur la création d'un `SecureString` paramètre Systems Manager, voir [Create a SecureString parameter (AWS CLI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/param-create-cli.html#param-create-cli-securestring) ou [Create a Systems Manager parameter (console)](https://docs.aws.amazon.com/systems-manager/latest/userguide/parameter-create-console.html) dans le *Guide de AWS Systems Manager l'utilisateur*.
Vous devez fournir un `SecureString` paramètre comme valeur pour les `--repo-private-key` paramètres `--http-username``--http-password`, ou.
## Comment protéger les instances du nouveau groupe Auto Scaling contre les événements de résiliation ?
Vous pouvez protéger les instances en définissant le `--enable-instance-protection` paramètre sur `TRUE` et en ajoutant une clé de `protected_instance` balise à chaque EC2 instance que vous souhaitez protéger contre les événements de résiliation. Lorsque vous définissez le `--enable-instance-protection` paramètre sur `TRUE` et ajoutez une clé de `protected_instance` balise, le script ajoute une politique de résiliation personnalisée à votre nouveau groupe Auto Scaling et suspend le `ReplaceUnhealthy` processus. Les instances dotées de la clé de `protected_instance` balise sont protégées contre les événements de terminaison suivants :
+ Échelle des événements
+ Actualisation d'instance
+ Rééquilibrage
+ Durée de vie maximale de l'instance
+ Autoriser la résiliation de l'instance de référencement
+ Résiliation et remplacement d'instances défectueuses
**Note**
Vous devez définir la clé de `protected_instance` balise sur les instances que vous souhaitez protéger. La clé du tag distingue les majuscules et minuscules. Toute instance dotée de cette clé de balise est protégée quelle que soit la valeur de la balise.
Pour réduire la durée d'exécution de la politique de résiliation personnalisée, vous pouvez augmenter le nombre d'instances par défaut utilisées par la fonction Lambda pour filtrer les instances protégées en mettant à jour la valeur de la variable de code de `default_sample_size` fonction. La valeur par défaut est 15. Si vous augmentez le`default_sample_size`, vous devrez peut-être augmenter la mémoire allouée à la fonction Lambda, ce qui augmentera le coût de votre fonction Lambda. Pour plus d'informations sur la tarification AWS Lambda , consultez [Tarification AWS Lambda](https://aws.amazon.com/).
## Quels équilibreurs de charge sont disponibles avec le script de migration ?
Le script propose trois options d'équilibreur de charge.
+ (Recommandé) Créez un nouvel Application Load Balancer. Par défaut, le script crée un nouvel Application Load Balancer. Vous pouvez également définir le `--lb-type` paramètre sur`ALB`. Pour plus d'informations sur les équilibreurs de charge d'application, voir [Qu'est-ce qu'un équilibreur de charge d'application](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) ? dans le *guide de l'utilisateur d'Elastic Load Balancing*.
+ Si un Application Load Balancer n'est pas une option, créez un Classic Load Balancer en définissant le paramètre `--lb-type` sur. `Classic` Si vous sélectionnez cette option, votre Classic Load Balancer existant attaché à votre OpsWorks couche est séparé de votre application. Pour plus d'informations sur les équilibreurs de charge d'application, voir [Qu'est-ce qu'un Classic Load](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/introduction.html) Balancer ? dans le *guide de l'utilisateur d'Elastic Load Balancing : Classic Load Balancers*.
+ Vous pouvez associer un équilibreur de charge existant en définissant le `--lb-type` paramètre sur`None`.
**Important**
Nous vous recommandons de créer de nouveaux équilibreurs de charge Elastic Load Balancing pour vos couches AWS OpsWorks Stacks. Si vous choisissez d'utiliser un équilibreur de charge Elastic Load Balancing existant, vous devez d'abord vérifier qu'il n'est pas utilisé à d'autres fins et qu'aucune instance n'est attachée. Une fois que l'équilibreur de charge est attaché à la couche, il OpsWorks supprime toutes les instances existantes et configure l'équilibreur de charge pour qu'il gère uniquement les instances de la couche. Bien qu'il soit techniquement possible d'utiliser la console ou l'API Elastic Load Balancing pour modifier la configuration d'un équilibreur de charge après l'avoir attaché à une couche, vous ne devez pas le faire ; les modifications ne seront pas permanentes.
**Pour associer votre équilibreur de charge de OpsWorks couche existant à votre groupe Auto Scaling**
1. Exécutez le script de migration avec le `--lb-type` paramètre défini sur`None`. Lorsque la valeur est définie sur`None`, le script ne clone ni ne crée d'équilibreur de charge.
1. Une fois que le script a déployé la CloudFormation pile, mettez à jour les groupes `Min` `Max` et les `Desired capacity` valeurs d'Auto Scaling, puis testez votre application.
1. Choisissez `Link to the template` affiché dans la sortie du script. Si vous avez fermé votre terminal, procédez comme suit pour accéder au modèle.
1. Ouvrez la console Systems Manager à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le volet de navigation, choisissez **Application Manager**.
1. Choisissez des **CloudFormation piles**, puis choisissez **Bibliothèque de modèles**.
1. Choisissez **Owned by me** et localisez votre modèle.
1. Dans le CloudFormation modèle, choisissez **Modifier** dans le menu **Actions**.
1. Mettez à jour la `LabelBalancerNames` propriété dans la section des `ApplicationAsg` ressources du CloudFormation modèle.
```
ApplicationAsg:
DependsOn: CustomTerminationLambdaPermission
Properties:
#(other properties in ApplicationAsg to remain unchanged)
LoadBalancerNames:
- load-balancer-name
HealthCheckType: ELB
```
1. Si vous souhaitez que la vérification de l'état de vos instances de groupe Auto Scaling utilise également celle de l'équilibreur de charge, supprimez la section ci-dessous `HealthCheckType` et entrez`ELB`. Si vous n'avez besoin que EC2 de bilans de santé, il n'est pas nécessaire de modifier le modèle.
1. Enregistrez vos modifications. L'enregistrement crée une nouvelle version par défaut du modèle. Si c'est la première fois que vous exécutez le script pour la couche et que vous enregistrez des modifications dans la console, la version la plus récente est 2.
1. Dans **Actions**, sélectionnez **Provision stack**.
1. Confirmez que vous souhaitez utiliser la version par défaut du modèle. Assurez-vous que l'**option Sélectionner une pile existante** est sélectionnée et choisissez la CloudFormation pile à mettre à jour.
1. Choisissez **Next** pour chacune des pages suivantes jusqu'à ce que la page **Révision et mise à disposition** apparaisse. Sur la page **Révision et mise à disposition**, sélectionnez à la fois **Je reconnais que cela AWS CloudFormation peut créer des ressources IAM avec des noms personnalisés** et **je comprends que les modifications apportées au modèle sélectionné peuvent entraîner la mise AWS CloudFormation à jour ou la suppression de AWS ressources existantes**.
1. Sélectionnez **Approvisionner une pile**.
Si vous devez annuler vos mises à jour, procédez comme suit.
1. Choisissez **Actions**, puis **Provision stack**.
1. **Choisissez l'une des versions existantes**, puis choisissez la version précédente du modèle.
1. Choisissez **Sélectionner une pile existante**, puis choisissez la CloudFormation pile à mettre à jour.
## Les recettes de configuration de livres de recettes personnalisées sont-elles migrées ?
L'exécution de livres de recettes personnalisés n'est pas prise en charge lors d'un événement d'installation. Le script migre les recettes de configuration personnalisées des livres de recettes et crée un runbook Systems Manager Automation pour vous. Cependant, vous devez exécuter les recettes manuellement.
Procédez comme suit pour exécuter vos recettes de configuration.
1. Ouvrez la console Systems Manager à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le volet de navigation, choisissez **Application Manager**.
1. Dans la section **Applications**, sélectionnez **Applications personnalisées**.
1. Choisissez votre application. Le nom de l'application commence par`app-stack-name`.
1. Choisissez **Resources**, puis choisissez le runbook de configuration. ****
1. Choisissez **Execute Automation**.
1. Choisissez l'instance IDs pour laquelle vous souhaitez exécuter les recettes de configuration, puis choisissez **Execute**.
## Puis-je exécuter des recettes de déploiement et de dédéploiement sur mes instances nouvellement créées ?
Le script peut créer trois runbooks d'automatisation possibles en fonction de la configuration de votre couche.
+ Configuration
+ Configurer
+ Terminer
Le script peut également créer les paramètres Systems Manager suivants qui contiennent des valeurs d'entrée pour le `AWS-ApplyChefRecipes Run Command` document.
+ Configuration
+ Déploiement
+ Configurer
+ Annulation du déploiement
+ Terminer
Lorsqu'un événement de scale-out se produit, le runbook de configuration Automation s'exécute automatiquement. Cela inclut la configuration et le déploiement de recettes de livres de recettes personnalisées à partir de votre OpsWorks couche d'origine. Lorsqu'un événement de scale-in se produit, le runbook Terminate Automation s'exécute automatiquement. Le runbook Terminate Automation contient les recettes d'arrêt de votre OpsWorks couche d'origine.
Si vous souhaitez exécuter des recettes d'annulation ou de configuration manuellement, procédez comme suit.
1. Ouvrez la console Systems Manager à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le volet de navigation, choisissez **Application Manager**.
1. Dans la section **Applications**, sélectionnez **Applications personnalisées**.
1. Choisissez votre application. Le nom de l'application commence par`app-stack-name-first-six-characters-stack-id`. Le gestionnaire d'applications ouvre l'onglet **Vue d'ensemble**.
1. Choisissez **Resources**, puis choisissez le runbook de configuration de l'automatisation.
1. Choisissez **Execute Automation**.
1. Pour le paramètre d'entrée `applyChefRecipesPropertiesParameter` Automation Runbook, référencez le paramètre Systems Manager correct. Le nom du paramètre Systems Manager suit le format`/ApplyChefRecipes-Preset/OpsWorks-stack-name-OpsWorks-layer-name-first-six-characters-stack-id/event`, dans lequel la valeur *event* est `Configure``Deploy`, ou `Undeploy` en fonction des recettes que vous souhaitez exécuter.
1. Choisissez l'instance IDs dans laquelle vous souhaitez exécuter les recettes, puis choisissez **Execute**.
## Puis-je modifier les sous-réseaux couverts par mon groupe Auto Scaling ?
Par défaut, le groupe Auto Scaling couvre tous les sous-réseaux de votre stack OpsWorks VPC. Pour mettre à jour les sous-réseaux à couvrir, procédez comme suit.
1. Choisissez `Link to the template` affiché dans la sortie du script. Si vous avez fermé votre terminal, procédez comme suit pour accéder au modèle.
1. Ouvrez la console Systems Manager à l'adresse [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. Dans le volet de navigation, choisissez **Application Manager**.
1. Choisissez des **CloudFormation piles**, puis choisissez **Bibliothèque de modèles**.
1. Choisissez **Owned by me** et localisez votre modèle.
1. Dans **Actions**, sélectionnez **Provision stack**.
1. Confirmez que vous souhaitez utiliser le modèle par défaut. Choisissez **Sélectionner une pile existante**, puis choisissez la CloudFormation pile à mettre à jour.
**Note**
Si vous avez exécuté le script avec le `--provision-application` paramètre défini sur`FALSE`, vous devez créer une nouvelle CloudFormation pile.
1. Pour le `SubnetIDs` paramètre, fournissez une liste séparée par des virgules des sous-réseaux IDs que vous souhaitez étendre à votre groupe Auto Scaling.
1. Choisissez **Next** jusqu'à ce que la page **Révision et approvisionnement** apparaisse.
1. Sur la page **Révision et mise à disposition**, choisissez **Je reconnais que des ressources IAM CloudFormation peuvent être créées avec des noms personnalisés**. **Je comprends que les modifications apportées au modèle sélectionné peuvent entraîner la mise CloudFormation à jour ou la suppression de AWS ressources existantes**.
1. Sélectionnez **Approvisionner une pile**.