Häufig gestellte Fragen

Die folgenden FAQs geben Antworten auf einige häufig gestellte Fragen.

Welche AWS OpsWorks Stacks Versionen kann ich migrieren?

Sie können nur Chef 11.10- und Chef 12-, Amazon Linux-, Amazon Linux 2-, Ubuntu- und Red Hat Enterprise Linux 7-Stacks migrieren.

Welche Chef-Versionen können meine migrierten Instances verwenden?

Migrierte Instanzen können die Chef-Versionen 11 bis 14 verwenden.

Anmerkung

Die Windows-Stack-Migration wird nicht unterstützt.

Welche Repository-Typen kann ich migrieren?

Sie können die Repository-Typen S3, Git und HTTP migrieren.

Kann ich weiterhin ein privates Git-Repository verwenden?

Ja, du kannst weiterhin ein privates Git-Repository verwenden.

Wenn du ein privates GitHub Repository verwendest, musst du einen neuen Ed25519 Hostschlüssel für SSH erstellen. Dies liegt daran, dass GitHub geändert wurde, welche Schlüssel in SSH unterstützt werden, und das unverschlüsselte Git-Protokoll entfernt wurde. Weitere Informationen zum Ed25519 Hostschlüssel findest du im GitHub Blogbeitrag Improving Git protocol security on GitHub. Nachdem Sie einen neuen Ed25519 Hostschlüssel generiert haben, erstellen Sie einen Systems Manager SecureString Manager-Parameter für diesen SSH-Schlüssel und verwenden Sie den Parameternamen als Wert für den --repo-private-key Parameter. Weitere Informationen zum Erstellen eines Systems Manager SecureString Manager-Parameters finden Sie unter Create a SecureString parameter (AWS CLI) im AWS Systems Manager Benutzerhandbuch.

Erstellen Sie für jeden anderen Git-Repository-Typ einen Systems Manager SecureString Manager-Parameter für diesen SSH-Schlüssel und verwenden Sie den Parameternamen als Wert für den --repo-private-key Parameter des Skripts.

Mit welchen SSH-Schlüsseln kann ich auf meine Instanzen zugreifen?

Wenn Sie das Skript ausführen, migriert das Skript die im Stack konfigurierten SSH-Schlüssel und -Instanzen. Sie können die SSH-Schlüssel verwenden, um auf Ihre Instanz zuzugreifen. Wenn SSH-Schlüssel für den Stack und die Instanz bereitgestellt werden, verwendet das Skript die Schlüssel aus dem Stack. Wenn Sie sich nicht sicher sind, welche SSH-Schlüssel Sie verwenden sollen, sehen Sie sich die Instances in der EC2-Konsole an (https://console.aws.amazon.com/ec2/). Auf der Detailseite in der EC2-Konsole werden die SSH-Schlüssel für Ihre Instance angezeigt.

Warum werden meine Instances automatisch ein- und ausskaliert?

Auto Scaling skaliert Instances auf der Grundlage der Skalierungsregeln für die Auto Scaling Scaling-Gruppe. Sie können die Kapazitätswerte Min., Max und Desired für Ihre Gruppe festlegen. Die Auto Scaling Scaling-Gruppe skaliert Ihre Kapazität automatisch entsprechend, wenn Sie diese Werte aktualisieren.

Kann ich Auto Scaling ausschalten?

Sie können Auto Scaling deaktivieren, indem Sie die Werte Min., Max und Gewünschte Kapazität der Auto Scaling Scaling-Gruppe auf dieselbe Zahl setzen. Wenn Sie beispielsweise immer über zehn Instances verfügen möchten, legen Sie die Werte für Min., Max und Gewünschte Kapazität auf zehn fest.

Kann ich Kernel- und Paket-Updates auf gestarteten EC2-Instances durchführen?

Standardmäßig erfolgen Kernel- und Paket-Updates, wenn die EC2-Instance gestartet wird. Gehen Sie wie folgt vor, um Kernel- oder Paket-Updates auf einer gestarteten EC2-Instance durchzuführen. Beispielsweise möchten Sie möglicherweise Updates anwenden, nachdem Sie die Rezepte „deploy“ oder „configure“ ausgeführt haben.

1. Stellen Sie eine Verbindung zu Ihrer EC2- Instance her.

2. Erstellen Sie die folgende perform_upgrade Funktion und führen Sie sie auf Ihrer Instanz aus.

   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

3. Nach den Kernel- und Paket-Updates müssen Sie möglicherweise Ihre EC2-Instance neu starten. Um zu überprüfen, ob ein Neustart erforderlich ist, erstellen Sie die folgende reboot_if_required Funktion und führen Sie sie auf Ihrer EC2-Instance aus.

   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            

4. Wenn die reboot_if_required Ergebnisse in einer reboot is required Meldung ausgeführt werden, starten Sie die EC2-Instance neu. Wenn Sie eine reboot is not required Nachricht erhalten, müssen Sie die EC2-Instance nicht neu starten.

Warum enthalten die EBS-Volumes in meinen Instances keine Daten?

Wenn Sie das Skript ausführen, migriert das Skript die Konfiguration der EBS-Volumes und erstellt so eine Ersatzarchitektur für Ihren OpsWorks Stack und Ihre Ebene. Das Skript migriert weder die tatsächlichen Instanzen noch die in den Instanzen enthaltenen Daten. Das Skript migriert nur die Konfiguration von EBS-Volumes auf Layer-Ebene und hängt die leeren EBS-Volumes an gestartete EC2-Instances an.

Gehen Sie wie folgt vor, um Daten aus den EBS-Volumes Ihrer vorherigen Instances abzurufen.

1. Erstellen Sie einen Snapshot der EBS-Volumes Ihrer vorherigen Instances. Weitere Informationen zum Erstellen eines Snapshots finden Sie unter Amazon EBS-Snapshot erstellen im Amazon EC2 EC2-Benutzerhandbuch.

2. Erstellen Sie ein Volume aus Ihrem Snapshot. Weitere Informationen zum Erstellen eines Volumes aus einem Snapshot finden Sie unter Create a Volume from a Snapshot im Amazon EC2 EC2-Benutzerhandbuch.

3. Hängen Sie das von Ihnen erstellte Volume an die Instances an. Weitere Informationen zum Anhängen von Volumes finden Sie unter Anhängen eines Amazon EBS-Volumes an eine Instance im Amazon EC2 EC2-Benutzerhandbuch.

Warum wurden die in meiner Startvorlage beschriebenen EBS-Volumes nicht bereitgestellt?

Wenn Sie eine Startvorlagen-ID für den --launch-template Parameter mit EBS-Volumes angeben, hängt das Skript die EBS-Volumes an, mountet die Volumes jedoch nicht. Sie können die angehängten EBS-Volumes mounten, indem Sie das MountEBSVolumes RunCommand Dokument ausführen, das das Skript für die gestartete EC2-Instance erstellt hat.

Wenn Sie keinen --launch-template Parameter festlegen, erstellt das Skript eine Vorlage. Wenn die Auto Scaling Scaling-Gruppe eine neue EC2-Instance startet, hängt die Auto Scaling Scaling-Gruppe automatisch die EBS-Volumes an und führt dann den SetupAutomation Befehl aus, um die angehängten Volumes an den in den Layer-Einstellungen konfigurierten Mountpunkten zu mounten.

Wo finde ich die Volume Logs von Chef Recipe und Mount EBS?

OpsWorks übermittelt die Protokolle an einen S3-Bucket, den Sie angeben können, indem Sie einen Wert für den --command-logs-bucket Parameter angeben. Der Standardname des S3-Buckets hat das Format:aws-opsworks-stacks-application-manager-logs-account-id. Chef-Rezeptprotokolle werden im ApplyChefRecipes Präfix gespeichert. Mount EBS-Volumenprotokolle werden im MountEBSVolumes Präfix gespeichert. Alle Ebenen, die aus einem Stack migriert werden, liefern Protokolle an denselben S3-Bucket.

Anmerkung

• Die Lifecycle-Konfiguration des S3-Buckets umfasst eine Regel zum Löschen der Protokolle nach 30 Tagen. Wenn Sie die Protokolle länger als 30 Tage aufbewahren möchten, müssen Sie die Regel in der Lifecycle-Konfiguration des S3-Buckets aktualisieren.

• Derzeit werden OpsWorks nur Chef setup und terminate Rezepte protokolliert.

Wo finde ich das Debug-Protokoll für das Migrationsskript?

Das Skript platziert Debug-Logs in einem Bucket mit dem Namen. aws-opsworks-stacks-transition-logs-account-id Sie finden die Debug-Protokolle im migration_script Ordner des S3-Buckets unter Ordnern, die dem Namen der Ebene entsprechen, die Sie migriert haben.

Unterstützt das Migrationsskript die Versionierung von CloudFormation Vorlagen?

Das Skript generiert Systems Manager Manager-Dokumente des Typs CloudFormation , die einen Ersatz für die Ebene oder den Stapel bilden, den Sie migrieren möchten. Wenn Sie das Skript erneut ausführen, selbst mit denselben Parametern, wird eine neue Version der zuvor exportierten Layer-Vorlage exportiert. Die Vorlagenversionen werden im selben S3-Bucket wie die Skriptprotokolle gespeichert.

Kann ich mehrere Ebenen migrieren?

Der --layer-id Parameter des Skripts wird in einer einzigen Ebene übergeben. Um mehrere Ebenen zu migrieren, führen Sie das Skript erneut aus und übergeben Sie eine andere--layer-id.

Ebenen, die Teil desselben OpsWorks Stacks sind, werden in Application Manager unter derselben Anwendung aufgeführt.

1. Öffnen Sie die Systems Manager Manager-Konsole unter https://console.aws.amazon.com/systems-manager/.

2. Wählen Sie im Navigationsbereich Application Manager aus.

3. Wählen Sie im Abschnitt Anwendungen die Option Benutzerdefinierte Anwendungen aus.

4. Wählen Sie Ihre Anwendung. Der Name der Anwendung beginnt mitapp-stack-name-first-six-characters-stack-id.

5. Das Element der obersten Ebene, das mit App beginnt, zeigt alle Komponenten, die Ihrem OpsWorks Stack entsprechen. Dazu gehören Komponenten, die Ihrer OpsWorks Ebene entsprechen.

6. Wählen Sie die Komponente aus, die der Ebene entspricht, um die Ressourcen für die Ebene anzuzeigen. Die Komponenten, die OpsWorks Ebenen darstellen, sind auch im Bereich Benutzerdefinierte Anwendungen als einzelne Anwendungen sichtbar.

Wie erstelle ich einen SecureString Parameter?

Sie können Systems Manager verwenden, um einen SecureString Parameter zu erstellen. Weitere Informationen zum Erstellen eines Systems Manager SecureString Manager-Parameters finden Sie unter Erstellen eines SecureString Parameters (AWS CLI) oder Erstellen eines Systems Manager Manager-Parameters (Konsole) im AWS Systems Manager Benutzerhandbuch.

Sie müssen einen SecureString Parameter als Wert für die --repo-private-key Parameter --http-username--http-password, oder angeben.

Wie kann ich Instances in der neuen Auto Scaling Scaling-Gruppe vor Terminierungsereignissen schützen?

Sie können Instances schützen, indem Sie den --enable-instance-protection Parameter auf festlegen TRUE und jeder EC2-Instance, die Sie vor Kündigungsereignissen schützen möchten, einen protected_instance Tag-Schlüssel hinzufügen. Wenn Sie den --enable-instance-protection Parameter auf setzen TRUE und einen protected_instance Tag-Schlüssel hinzufügen, fügt das Skript Ihrer neuen Auto Scaling Scaling-Gruppe eine benutzerdefinierte Kündigungsrichtlinie hinzu und unterbricht den ReplaceUnhealthy Prozess. Instances mit dem protected_instance Tag-Schlüssel sind vor den folgenden Terminierungsereignissen geschützt:

• Skalierung von Ereignissen

• Instance-Aktualisierung

• Neuausgleich

• Maximale Lebensdauer der Instanz

• Kündigung der Listing-Instance zulassen

• Kündigung und Ersatz fehlerhafter Instances

Anmerkung

Sie müssen den protected_instance Tag-Schlüssel für Instances festlegen, die Sie schützen möchten. Beim Tag-Schlüssel wird zwischen Groß- und Kleinschreibung unterschieden. Jede Instanz mit diesem Tag-Schlüssel ist unabhängig vom Tag-Wert geschützt.

Um die Laufzeit der benutzerdefinierten Kündigungsrichtlinie zu reduzieren, können Sie die Standardanzahl von Instanzen erhöhen, die die Lambda-Funktion verwendet, um nach geschützten Instanzen zu filtern, indem Sie den Wert für die default_sample_size Funktionscodevariable aktualisieren. Der Standardwert ist 15. Wenn Sie den erhöhendefault_sample_size, müssen Sie möglicherweise den der Lambda-Funktion zugewiesenen Speicher erhöhen, was die Kosten Ihrer Lambda-Funktion erhöhen würde. Informationen zu AWS Lambda -Preisen erhalten Sie unter AWS Lambda Pricing (Preise für WAF).

Welche Load Balancer sind mit dem Migrationsskript verfügbar?

Das Skript bietet drei Load Balancer-Optionen.

• (Empfohlen) Erstellen Sie einen neuen Application Load Balancer. Standardmäßig erstellt das Skript einen neuen Application Load Balancer. Sie können den --lb-type Parameter auch auf setzen. ALB Weitere Informationen zu Application Load Balancers finden Sie unter Was ist ein Application Load Balancer? im Elastic Load Balancing User Guide.

• Wenn ein Application Load Balancer keine Option ist, erstellen Sie einen Classic Load Balancer, indem Sie den --lb-type Parameter auf setzen. Classic Wenn Sie diese Option auswählen, wird Ihr vorhandener Classic Load Balancer, der mit Ihrem OpsWorks Layer verbunden ist, von Ihrer Anwendung getrennt. Weitere Informationen zu Application Load Balancers finden Sie unter Was ist ein Classic Load Balancer? im Elastic Load Balancing: Classic Load Balancers Benutzerhandbuch.

• Sie können einen vorhandenen Load Balancer anhängen, indem Sie den --lb-type Parameter auf setzen. None

  Wichtig

  Wir empfehlen, neue Elastic Load Balancing Load Balancer für Ihre AWS OpsWorks Stacks-Ebenen zu erstellen. Wenn Sie sich dafür entscheiden, einen vorhandenen Elastic Load Balancing Load Balancer zu verwenden, sollten Sie zunächst sicherstellen, dass er nicht für andere Zwecke verwendet wird und keine angehängten Instances hat. Nachdem der Load Balancer an die Ebene angehängt wurde, werden alle vorhandenen Instances OpsWorks entfernt und der Load Balancer so konfiguriert, dass er nur die Instances der Ebene verarbeitet. Es ist zwar technisch möglich, die Elastic Load Balancing Balancing-Konsole oder API zu verwenden, um die Konfiguration eines Load Balancers zu ändern, nachdem er an eine Ebene angehängt wurde, aber Sie sollten dies nicht tun, da die Änderungen nicht dauerhaft sind.

So fügen Sie Ihren vorhandenen OpsWorks Layer-Load Balancer Ihrer Auto Scaling Scaling-Gruppe hinzu

1. Führen Sie das Migrationsskript aus, wobei der --lb-type Parameter auf None gesetzt ist. Wenn der Wert auf gesetzt istNone, klont oder erstellt das Skript keinen Load Balancer.

2. Nachdem das Skript den CloudFormation Stack bereitgestellt hat, aktualisieren Sie die Auto Scaling Scaling-Gruppen Min Max und Desired capacity -Werte und testen Sie dann Ihre Anwendung.

3. Wählen Sie die in Link to the template der Skriptausgabe angezeigte Option aus. Wenn Sie Ihr Terminal geschlossen haben, gehen Sie wie folgt vor, um auf die Vorlage zuzugreifen.

   1. Öffnen Sie die Systems Manager Manager-Konsole unter https://console.aws.amazon.com/systems-manager/.

   2. Wählen Sie im Navigationsbereich Application Manager aus.

   3. Wählen Sie CloudFormation Stacks und dann Template-Bibliothek aus.

   4. Wählen Sie Owned by me und suchen Sie nach Ihrer Vorlage.

4. Wählen Sie in der CloudFormation Vorlage im Menü Aktionen die Option Bearbeiten aus.

5. Aktualisieren Sie die LabelBalancerNames Eigenschaft im ApplicationAsg Ressourcenbereich der CloudFormation Vorlage.

   ApplicationAsg:
      DependsOn: CustomTerminationLambdaPermission
      Properties:
      #(other properties in ApplicationAsg to remain unchanged)
         LoadBalancerNames:
           - load-balancer-name 
         HealthCheckType: ELB
                       

6. Wenn Sie möchten, dass die Zustandsprüfung Ihrer Auto Scaling Scaling-Gruppeninstanzen auch die Integritätsprüfung des Load Balancers verwendet, entfernen Sie den folgenden Abschnitt HealthCheckType und geben Sie einELB. Wenn Sie nur EC2-Integritätsprüfungen benötigen, müssen Sie die Vorlage nicht ändern.

7. Speichern Sie Ihre Änderungen. Beim Speichern wird eine neue Standardversion der Vorlage erstellt. Wenn Sie das Skript für den Layer zum ersten Mal ausführen und Änderungen zum ersten Mal in der Konsole gespeichert haben, ist die neuere Version 2.

8. Wählen Sie unter Aktionen die Option Bereitstellungsstapel aus.

9. Bestätigen Sie, dass Sie die Standardversion der Vorlage verwenden möchten. Vergewissern Sie sich, dass Select a existing stack ausgewählt ist und wählen Sie den CloudFormation Stack aus, der aktualisiert werden soll.

10. Wählen Sie für jede der nachfolgenden Seiten Weiter aus, bis Sie die Seite „Überprüfen und Bereitstellen“ sehen. Wählen Sie auf der Seite Überprüfen und Bereitstellen sowohl Ich bestätige, dass AWS CloudFormation möglicherweise IAM-Ressourcen mit benutzerdefinierten Namen erstellt werden, als auch die Option Ich verstehe, dass Änderungen an der ausgewählten Vorlage AWS CloudFormation dazu führen können, dass vorhandene AWS Ressourcen aktualisiert oder entfernt werden.

11. Wählen Sie Stack bereitstellen.

Wenn Sie Ihre Aktualisierungen rückgängig machen müssen, gehen Sie wie folgt vor.

1. Wählen Sie Aktionen und dann Bereitstellungsstapel aus.

2. Wählen Sie Wählen Sie eine der vorhandenen Versionen aus und wählen Sie dann die vorherige Vorlagenversion aus.

3. Wählen Sie „Einen vorhandenen Stapel auswählen“ und dann den zu CloudFormation aktualisierenden Stapel aus.

Werden Rezepte zur Konfiguration benutzerdefinierter Kochbücher migriert?

Die Ausführung benutzerdefinierter Kochbücher während eines Setup-Ereignisses wird nicht unterstützt. Das Skript migriert benutzerdefinierte Kochbuch-Konfigurationsrezepte und erstellt ein Systems Manager Automation-Runbook für Sie. Sie müssen die Rezepte jedoch manuell ausführen.

Führen Sie die folgenden Schritte aus, um Ihre Konfigurationsrezepte auszuführen.

1. Öffnen Sie die Systems Manager Manager-Konsole unter https://console.aws.amazon.com/systems-manager/.

2. Wählen Sie im Navigationsbereich Application Manager aus.

3. Wählen Sie im Abschnitt Anwendungen die Option Benutzerdefinierte Anwendungen aus.

4. Wählen Sie Ihre Anwendung. Der Name der Anwendung beginnt mitapp-stack-name.

5. Wählen Sie Resources und dann das Configure Runbook aus.

6. Wählen Sie „Automatisierung ausführen“.

7. Wählen Sie die Instanz-IDs aus, für die Sie die Konfigurationsrezepte ausführen möchten, und wählen Sie dann Execute.

Kann ich Rezepte zum Bereitstellen und Aufheben der Bereitstellung auf meinen neu erstellten Instances ausführen?

Das Skript kann je nach Konfiguration Ihres Layers drei mögliche Automation-Runbooks erstellen.

• Aufstellen

• Konfiguration

• Beenden

Das Skript kann auch die folgenden Systems Manager Manager-Parameter erstellen, die Eingabewerte für das AWS-ApplyChefRecipes Run Command Dokument enthalten.

• Aufstellen

• Bereitstellen

• Konfiguration

• Bereitstellung aufheben

• Beenden

Wenn ein Scale-Out-Ereignis eintritt, wird das Runbook für die Setup-Automatisierung automatisch ausgeführt. Dazu gehören die Einrichtung und Bereitstellung von benutzerdefinierten Kochbuchrezepten aus Ihrer ursprünglichen Ebene. OpsWorks Wenn ein Scale-In-Ereignis eintritt, wird das Terminate Automation-Runbook automatisch ausgeführt. Das Terminate Automation-Runbook enthält die Shutdown-Rezepte aus Ihrem ursprünglichen Layer. OpsWorks

Wenn Sie Rezepte manuell ausführen, bereitstellen oder konfigurieren möchten, gehen Sie wie folgt vor.

1. Öffnen Sie die Systems Manager Manager-Konsole unter https://console.aws.amazon.com/systems-manager/.

2. Wählen Sie im Navigationsbereich Application Manager aus.

3. Wählen Sie im Abschnitt Anwendungen die Option Benutzerdefinierte Anwendungen aus.

4. Wählen Sie Ihre Anwendung. Der Name der Anwendung beginnt mitapp-stack-name-first-six-characters-stack-id. Der Anwendungsmanager öffnet die Registerkarte Übersicht.

5. Wählen Sie Ressourcen und dann das Runbook zur Konfiguration von Automation aus.

6. Wählen Sie „Automatisierung ausführen“.

7. Verweisen Sie für den Eingabeparameter des applyChefRecipesPropertiesParameter Automatisierungs-Runbooks auf den richtigen Systems Manager Manager-Parameter. Der Name des Systems Manager Manager-Parameters folgt dem Format/ApplyChefRecipes-Preset/OpsWorks-stack-name-OpsWorks-layer-name-first-six-characters-stack-id/event, in dem der Wert für das Ereignis lautet ConfigureDeploy, oder Undeploy hängt von den Rezepten ab, die Sie ausführen möchten.

8. Wählen Sie die Instanz-IDs aus, auf denen Sie die Rezepte ausführen möchten, und klicken Sie auf Ausführen.

Kann ich ändern, über welche Subnetze sich meine Auto Scaling Scaling-Gruppe erstreckt?

Standardmäßig umfasst die Auto Scaling Scaling-Gruppe alle Subnetze in Ihrer OpsWorks Stack-VPC. Gehen Sie wie folgt vor, um zu aktualisieren, welche Subnetze sich erstrecken sollen.

1. Wählen Sie aus, wie es in der Ausgabe des Skripts Link to the template angezeigt wird. Wenn Sie Ihr Terminal geschlossen haben, gehen Sie wie folgt vor, um auf die Vorlage zuzugreifen.

   1. Öffnen Sie die Systems Manager Manager-Konsole unter https://console.aws.amazon.com/systems-manager/.

   2. Wählen Sie im Navigationsbereich Application Manager aus.

   3. Wählen Sie CloudFormation Stacks und dann Template-Bibliothek aus.

   4. Wählen Sie Owned by me und suchen Sie nach Ihrer Vorlage.

2. Wählen Sie unter Aktionen die Option Bereitstellungsstapel aus.

3. Bestätigen Sie, dass Sie die Standardvorlage verwenden möchten. Wählen Sie Bestehenden Stack auswählen und wählen Sie dann den CloudFormation Stack aus, der aktualisiert werden soll.

   Anmerkung

   Wenn Sie das Skript mit dem auf gesetzten --provision-application Parameter ausgeführt habenFALSE, müssen Sie einen neuen CloudFormation Stack erstellen.

4. Geben Sie für den SubnetIDs Parameter eine durch Kommas getrennte Liste der Subnetz-IDs an, über die sich Ihre Auto Scaling Scaling-Gruppe erstrecken soll.

5. Wählen Sie Weiter, bis die Seite „Überprüfen und Bereitstellen“ angezeigt wird.

6. Wählen Sie auf der Seite Überprüfen und Bereitstellen die Option Ich bestätige, dass AWS CloudFormation möglicherweise IAM-Ressourcen mit benutzerdefinierten Namen erstellt werden, und ich verstehe, dass Änderungen an der ausgewählten Vorlage AWS CloudFormation dazu führen können, dass vorhandene AWS Ressourcen aktualisiert oder entfernt werden.

7. Wählen Sie Stack bereitstellen.