Eine Website läuft auf vier EC2-Instances hinter einem ALB. Wenn der ALB eine Instance als fehlerhaft markiert, wechselt ein CloudWatch-Alarm in den ALARM-Zustand, und ein Operator fügt manuell eine Ersatz-Instance hinzu. Das Unternehmen wünscht sich eine hochverfügbare Lösung, die ausgefallene EC2-Instances automatisch ersetzt und gleichzeitig die Ausfallzeiten während der Migration zum neuen Design minimiert. Welche Abfolge von Schritten sollte der Lösungsarchitekt verwenden?

Die korrekte Option minimiert Ausfallzeiten, indem sie die vorhandene Infrastruktur (ALB und EC2-Instanzen) nutzt. Zuerst wird eine Auto Scaling-Gruppe (ASG) mit einer Startvorlage erstellt, die die gewünschte Konfiguration für neue Instanzen definiert. Diese ASG wird dann an den bestehenden ALB angehängt. Schließlich werden die vorhandenen EC2-Instanzen der ASG hinzugefügt. Dies ermöglicht es der ASG, die Kontrolle über die Skalierung und den Ersatz von Instanzen zu übernehmen, ohne den Dienst zu unterbrechen. Die anderen Optionen sind weniger geeignet: Das Löschen des vorhandenen ALB oder der EC2-Instanzen würde zu Ausfallzeiten führen. Das Warten darauf, dass der ALB Instanzen bei der ASG registriert, ist nicht der korrekte Mechanismus; die Instanzen müssen der ASG hinzugefügt werden.