Launch Templates und ASG-Konfiguration

Ein Launch Template ist ein versionierter Bauplan, der Auto Scaling Groups (und EC2 direkt) darüber informiert, wie Instances gestartet werden sollen. Es fasst die AMI-ID, den Instance-Typ, das Schlüsselpaar, die Sicherheitsgruppen und optionale Benutzerdaten in einem einzigen wiederverwendbaren Dokument zusammen. Im Gegensatz zur älteren Launch Configuration unterstützt ein Launch Template mehrere Versionen und kann aktualisiert werden, ohne die ASG zu ersetzen.

Sie können ein Launch Template mit der AWS CLI über create-launch-template erstellen. Der Parameter --launch-template-data akzeptiert ein JSON-Objekt, das alle Instance-Einstellungen definiert. Dank der Versionierung können Sie das Template weiterentwickeln, ohne laufende Instances zu beeinflussen, bis Sie zur Bereitstellung bereit sind.

Jedes Launch Template beginnt mit der Version 1. Beim Erstellen einer neuen Version müssen Sie nur die geänderten Felder überschreiben; alle anderen Einstellungen werden von der Quellversion übernommen. Sie können die ASG so konfigurieren, dass sie die Version $Latest (immer die neueste) oder die Version $Default (explizit festgelegt) verwendet. Mit $Default erhalten Sie kontrollierte Rollouts, während $Latest in Entwicklungsumgebungen praktisch ist.

Eine Auto Scaling Group (ASG) verwaltet eine Gruppe von EC2-Instances innerhalb festgelegter Grenzen: Minimum (Untergrenze), Maximum (Obergrenze) und gewünschte Kapazität (die zu jedem Zeitpunkt angestrebte Anzahl). Wenn Instances die Zustandsprüfungen nicht bestehen oder die Scaling-Richtlinie ausgelöst wird, startet oder beendet die ASG automatisch Instances, um die gewünschte Anzahl zwischen Minimum und Maximum beizubehalten.

Beim Erstellen einer ASG verweisen Sie auf ein Launch Template (nicht direkt auf eine bestimmte AMI). Außerdem geben Sie die VPC-Subnetze an, in denen Instances gestartet werden. Die Verteilung auf mehrere Subnetze (je eines pro AZ) bietet integrierte Multi-AZ-Redundanz: Wenn eine AZ ausfällt, startet die ASG automatisch Ersatz-Instances in den verbleibenden AZs.

Standardmäßig verwendet eine ASG EC2-Zustandsprüfungen. Dabei wird eine Instance nur dann als fehlerhaft eingestuft, wenn sie gestoppt oder beendet wurde oder der Hypervisor einen Fehler meldet. Wenn Sie einen Load Balancer anbinden, sollten Sie zu ELB-Zustandsprüfungen wechseln, damit die ASG Instances ersetzt, die zwar ausgeführt werden, aber HTTP-5xx-Fehler zurückgeben. Dies ist eine häufige Prüfungsfrage: Wenn die Architektur einen Load Balancer enthält, wählen Sie immer ELB-Zustandsprüfungen.

Die korrekte Festlegung der Kapazitätsgrenzen ist entscheidend. Das Minimum stellt sicher, dass Ihre Anwendung immer Datenverkehr bedienen kann (es wird nie unterschritten). Das Maximum verhindert eine unkontrollierte Skalierung, durch die Service-Limits oder Ihr Budget ausgeschöpft werden könnten. Die gewünschte Kapazität ist das anfängliche Ziel; Scaling-Richtlinien passen sie dynamisch an. Wenn Sie min=max=desired setzen, verhält sich die ASG wie eine Gruppe mit fester Größe. Das ist für Bereitstellungen mit Launch Templates oder eine festgelegte Kapazität nützlich.

Bei Anwendungen der Webschicht binden Sie die ASG an eine Target-Gruppe eines Application Load Balancers an. Jede von der ASG gestartete neue Instance wird automatisch in der Target-Gruppe registriert, und beendete Instances werden automatisch deregistriert. Dadurch wird sichergestellt, dass Datenverkehr nur an fehlerfreie, ausgeführte Instances weitergeleitet wird. Außerdem müssen Sie den Typ der Zustandsprüfung auf ELB setzen, damit die ASG über Fehler auf Load-Balancer-Ebene informiert ist.

Benutzerdaten sind ein Shell-Skript (Base64-codiert), das beim ersten Start einer Instance einmalig ausgeführt wird. In einem Launch Template sind sie der richtige Ort, um Pakete zu installieren, Agents (CloudWatch, SSM) zu konfigurieren und Anwendungscode abzurufen. Sorgen Sie dafür, dass Benutzerdaten idempotent sind: Skripte, die problemlos mehr als einmal ausgeführt werden können, verhindern Probleme bei der Instance-Aktualisierung. Bei komplexen Setups sollten Sie stattdessen AWS Systems Manager oder ein Konfigurationsverwaltungstool aufrufen, anstatt umfangreiche Skripte einzubetten.

Ein Warm Pool initialisiert eine Gruppe gestoppter (oder ausgeführter) EC2-Instances außerhalb der ASG vor und hält sie in einem bereiten Zustand. Wenn die ASG aufskaliert werden muss, verwendet sie Instances aus dem Warm Pool, statt neue Instances vollständig neu zu starten. Dadurch wird die Zeit zum Hinzufügen von Kapazität deutlich verkürzt. Für Instances im Warm Pool fallen Kosten für den gestoppten Zustand an (nur für EBS, keine CPU-Kosten), wodurch diese Lösung deutlich günstiger ist, als vollständig ausgeführte Reserve-Instances bereitzuhalten.

Wenn die ASG herunterskaliert, muss sie entscheiden, welche Instances beendet werden. Die standardmäßige Beendigungsrichtlinie wählt zuerst die AZ mit den meisten Instances aus (um einen Ausgleich herzustellen), anschließend das älteste Launch Template und danach die Instance, die ihrer Abrechnungsstunde am nächsten ist. Sie können diese Reihenfolge anpassen – beispielsweise OldestLaunchTemplate wählen, um zuerst Instances mit veralteten Konfigurationen zu entfernen. Die ASG führt außerdem automatisch einen AZ-Ausgleich durch, nachdem ein Subnetz verfügbar wird oder manuelle Änderungen vorgenommen wurden.

Testen Sie Ihr Verständnis der AWS-Solutions-Architect-Konzepte (SAA-C03) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: Launch Templates bieten eine versionierte, wiederverwendbare Vorlage für Instances und unterstützen mehrere Versionen sowie die Versionszeiger $Latest/$Default; die ASG-Kapazitätsgrenzen (Minimum/Maximum/gewünschte Kapazität) steuern die Größe der Gruppe mit automatischer Multi-AZ-Verteilung über Subnetze; und ELB-Zustandsprüfungen müssen aktiviert werden, wenn sich eine ASG hinter einem Load Balancer befindet, damit Fehler auf Anwendungsebene eine Ersetzung auslösen. Als Nächstes sehen wir uns Scaling-Richtlinien an, darunter Target Tracking und Step Scaling.