Auto Scaling Group Health Checks: Warum deine Instanzen beendet werden, obwohl sie laufen
Eine ASG beendet laufende Instanzen — das ist einer der frustrierendsten Zustände in der AWS-Produktion, weil der EC2-Status grün ist, die Anwendung aber trotzdem aus der Rotation fliegt. Der Reflex, einfach von 'EC2' auf 'ELB' umzustellen, ist verständlich, aber ohne Verständnis des zugrundeliegenden Mechanismus kann diese Änderung das Problem verschlimmern statt lösen.
TL;DR — Auto Scaling Group Health Check Entscheidung
| Szenario | Empfohlener Health-Check-Typ | Wichtigster Fallstrick |
|---|---|---|
| Instanz läuft, App antwortet nicht | ELB | Grace Period muss lang genug für App-Start sein |
| Instanz wird direkt nach Launch beendet | EC2 (prüfe zuerst Grace Period) | Grace Period zu kurz — ELB-Check schlägt während Boot fehl |
| Kein Load Balancer vorhanden | EC2 | ELB-Typ ohne Target Group hat keine Wirkung |
| Instanz hängt im 'Impaired'-Status | EC2 reicht | Status-Check-Fehler lösen EC2-Typ-Terminierung aus |
Wie ASG Health Checks funktionieren
Bevor du irgendetwas änderst, musst du verstehen, was die ASG tatsächlich prüft — und wann. Es gibt zwei unabhängige Schichten, die kombiniert werden können.
EC2 Health Check (Standard)
Die ASG fragt den EC2-Systemstatus ab: 'System Status Check' und 'Instance Status Check'. Wenn eine Instanz den Status impaired hat oder nicht mehr im Zustand running ist, markiert die ASG sie als ungesund und leitet die Terminierung ein. Das ist rein infrastrukturell — ob deine Anwendung auf Port 8080 antwortet, interessiert diesen Check nicht.
ELB Health Check
Wenn du den Health-Check-Typ auf 'ELB' setzt, zieht die ASG zusätzlich den Gesundheitsstatus aus der Target Group des zugehörigen Load Balancers heran. Eine Instanz gilt als ungesund, sobald der Target-Group-Status auf unhealthy wechselt. Das bedeutet: Der Load Balancer sendet HTTP-Requests an den konfigurierten Health-Check-Pfad, und wenn die Antwort nicht dem erwarteten Status-Code entspricht, wird die Instanz aus Sicht der ASG ungesund.
Der ELB-Health-Check-Typ macht die ASG nicht schlauer — er delegiert die Entscheidung an den Load Balancer. Wenn der Load Balancer falsch konfiguriert ist, terminiert die ASG korrekt auf Basis falscher Informationen.
Die Health Check Grace Period — der am häufigsten übersehene Parameter
Hier liegt die Wurzel der meisten 'Instanz wird sofort beendet'-Probleme. Die Grace Period definiert, wie viele Sekunden nach dem Launch einer Instanz die ASG Health-Check-Ergebnisse ignoriert. Der Standardwert ist 300 Sekunden — aber wenn deine Anwendung 4 Minuten zum Starten braucht und der ELB-Health-Check nach 60 Sekunden fehlschlägt, wird die Instanz beendet, bevor sie jemals produktiv war.
(Health Checks ignoriert)"] B --> C{"Grace Period abgelaufen?"} C -- Nein --> B C -- Ja --> D{"Health Check Typ?"} D -- EC2 --> E["EC2 Statuscheck abfragen"] D -- ELB --> F["Target Group Status abfragen"] E --> G{"Status OK?"} F --> G G -- Ja --> H["Instanz: Healthy In Rotation"] G -- Nein --> I["Instanz: Unhealthy Terminierung eingeleitet"] I --> J["Neue Instanz gestartet Zyklus beginnt neu"]
- Launch: EC2-Instanz startet, ASG-Timer beginnt.
- Grace Period aktiv: Health-Check-Ergebnisse werden ignoriert — egal ob EC2 oder ELB.
- Grace Period abgelaufen: Ab jetzt wertet die ASG Health-Check-Ergebnisse aus.
- Unhealthy erkannt: ASG markiert Instanz, wartet kurz, leitet Terminierung ein.
- Replacement: Neue Instanz wird gestartet — der Zyklus beginnt von vorn, wenn die Ursache nicht behoben ist.
Diagnose: Warum werden meine Instanzen beendet?
Bevor du den Health-Check-Typ änderst, musst du wissen, welche Schicht das Problem auslöst. Die folgenden Schritte gehen von der äußersten Schicht nach innen.
Schritt 1: ASG-Aktivitätshistorie prüfen
Die Aktivitätshistorie zeigt den genauen Grund für jede Terminierung. Das ist der erste Anlaufpunkt — ohne diesen Schritt tappst du im Dunkeln.
aws autoscaling describe-scaling-activities \
--auto-scaling-group-name DEINE-ASG-NAME \
--max-items 20 \
--region us-east-1Achte auf das Feld StatusMessage. Typische Einträge:
Instance failed EC2 health checks— EC2-Statuscheck fehlgeschlagenInstance failed ELB health checks in us-east-1a— Target Group meldet unhealthyTerminating EC2 instance: i-0abc... Termination policy: OldestInstance— Scale-in, kein Health-Check-Problem
Schritt 2: Aktuellen Health-Check-Status der Instanzen in der ASG abrufen
Dieser Befehl zeigt, welche Instanzen die ASG aktuell als gesund oder ungesund bewertet — und nach welchem Typ.
aws autoscaling describe-auto-scaling-instances \
--region us-east-1 \
--query 'AutoScalingInstances[?AutoScalingGroupName==`DEINE-ASG-NAME`].{Instance:InstanceId,Health:HealthStatus,LifecycleState:LifecycleState}'Eine Instanz im Zustand Terminating mit HealthStatus: Unhealthy bestätigt, dass ein Health Check ausgelöst hat — nicht eine Scaling-Policy.
Schritt 3: Grace Period und Health-Check-Typ der ASG prüfen
Viele Teams ändern die Grace Period einmalig beim Setup und vergessen sie danach. Wenn sich die Startzeit der Anwendung durch neue Dependencies verlängert hat, ist dieser Wert möglicherweise längst veraltet.
aws autoscaling describe-auto-scaling-groups \
--auto-scaling-group-names DEINE-ASG-NAME \
--region us-east-1 \
--query 'AutoScalingGroups[0].{HealthCheckType:HealthCheckType,GracePeriod:HealthCheckGracePeriod,MinSize:MinSize,MaxSize:MaxSize}'Schritt 4: Target-Group-Health-Status prüfen (nur bei ELB-Typ)
Wenn der Health-Check-Typ bereits 'ELB' ist oder du dahin wechseln willst, musst du den tatsächlichen Status in der Target Group kennen. Die ASG übernimmt diesen Wert direkt — sie hat keine eigene Logik darüber hinaus.
aws elbv2 describe-target-health \
--target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/DEIN-TG-NAME/abc123 \
--region us-east-1Wenn der Zustand unhealthy ist, prüfe das Feld Reason. Häufige Ursachen: falscher Health-Check-Pfad, falscher Port, Security Group blockiert den Load-Balancer-Traffic zur Instanz.
Schritt 5: EC2-Statusprüfungen direkt abfragen
Wenn Schritt 1 auf EC2-Health-Check-Fehler hinweist, prüfe die Statusprüfungen auf Instanzebene. Ein impaired-Status hier ist das direkte Signal für den EC2-Health-Check-Typ.
aws ec2 describe-instance-status \
--instance-ids i-0abc1234def567890 \
--region us-east-1 \
--query 'InstanceStatuses[0].{SystemStatus:SystemStatus.Status,InstanceStatus:InstanceStatus.Status}'- Aktivitätshistorie zeigt den Terminierungsgrund — immer hier starten.
- EC2-Statusfehler → Schritt 5, Instanz-Hardware oder Netzwerk-Problem.
- ELB-Statusfehler → Schritt 4, Target-Group-Konfiguration prüfen.
- Grace-Period-Verdacht → Schritt 3, Wert gegen tatsächliche Boot-Zeit messen.
Health-Check-Typ ändern: EC2 vs. ELB
Wann ELB der richtige Typ ist
Wenn deine Instanzen laufen, der EC2-Statuscheck grün ist, aber die Anwendung nicht antwortet — zum Beispiel weil ein Prozess abgestürzt ist oder die App in einem Fehlerzustand hängt — dann erkennt der EC2-Typ dieses Problem nicht. Hier ist ELB die richtige Wahl, weil der Load Balancer aktiv HTTP-Requests sendet und eine fehlerhafte Anwendung sichtbar macht.
Wann ELB das Problem verschlimmert
Wenn die Grace Period zu kurz ist und die Anwendung länger zum Starten braucht als dieser Wert, wird jede neue Instanz terminiert, bevor sie den Health Check bestehen kann. Das Ergebnis ist eine Terminierungsschleife. Mit EC2-Typ wäre die Instanz nach dem Boot als gesund markiert worden — mit ELB-Typ schlägt sie fehl, weil der App-Prozess noch nicht bereit ist.
Health-Check-Typ und Grace Period anpassen
Passe beide Parameter gleichzeitig an. Eine Grace Period von mindestens der maximalen beobachteten Startzeit plus einem Puffer ist der Ausgangspunkt.
aws autoscaling update-auto-scaling-group \
--auto-scaling-group-name DEINE-ASG-NAME \
--health-check-type ELB \
--health-check-grace-period 600 \
--region us-east-1Instanz manuell als gesund markieren (temporär)
Wenn du eine Instanz aus einer laufenden Terminierungsschleife retten willst, um die Ursache zu untersuchen, kannst du den Health-Status manuell überschreiben. Das ist eine Diagnosemaßnahme, kein dauerhafter Fix.
aws autoscaling set-instance-health \
--instance-id i-0abc1234def567890 \
--health-status Healthy \
--should-respect-grace-period false \
--region us-east-1Das Muster, das immer wieder auftaucht
Ein Team meldet: 'Unsere ASG terminiert Instanzen im 2-Minuten-Takt.' Erster Verdacht: fehlerhafte Anwendung. Die Logs zeigen aber eine sauber startende App. Der EC2-Statuscheck ist grün. Der Health-Check-Typ ist bereits 'ELB'.
Der tatsächliche Befund: Die Anwendung braucht 8 Minuten zum vollständigen Start — Datenbankverbindungen, Cache-Warmup, Konfigurationsdownload aus S3. Die Grace Period steht auf 300 Sekunden. Der Load Balancer sendet nach 5 Minuten den ersten Health-Check-Request, die App antwortet noch nicht, Target Group meldet unhealthy, ASG terminiert.
Die Lösung war nicht der Health-Check-Typ — der war korrekt. Die Grace Period war schlicht zu kurz für die tatsächliche Startzeit der Anwendung. Nach der Anpassung auf 600 Sekunden verschwand das Problem sofort.
Die Grace Period ist kein Sicherheitspuffer — sie ist eine Behauptung über die maximale Startzeit deiner Anwendung. Wenn sich die Startzeit ändert, muss dieser Wert mitgeändert werden.
IAM-Berechtigungen für die Diagnose
Für die oben gezeigten Diagnosebefehle benötigt der ausführende Principal mindestens folgende Berechtigungen:
🔽 IAM Policy für ASG-Health-Check-Diagnose (klicken zum Aufklappen)
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"autoscaling:DescribeAutoScalingGroups",
"autoscaling:DescribeAutoScalingInstances",
"autoscaling:DescribeScalingActivities",
"autoscaling:SetInstanceHealth",
"autoscaling:UpdateAutoScalingGroup"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstanceStatus",
"elasticloadbalancing:DescribeTargetHealth"
],
"Resource": "*"
}
]
}Hinweis: DescribeAutoScalingGroups, DescribeScalingActivities und DescribeInstanceStatus unterstützen keine ressourcenbasierte Einschränkung auf ARN-Ebene — "Resource": "*" ist für diese Aktionen erforderlich. Prüfe die aktuelle Service Authorization Reference, bevor du die Policy produktiv einsetzt.
Auto Scaling Group Health Checks — Zusammenfassung und nächste Schritte
Der Wechsel von EC2 auf ELB als Health-Check-Typ ist oft die richtige Entscheidung — aber nur dann, wenn du weißt, dass das Problem auf Anwendungsebene liegt und nicht in einer zu kurzen Grace Period. Die Diagnoseschritte oben geben dir in unter 5 Minuten Klarheit darüber, welche Schicht das Problem auslöst.
Nächste Schritte:
- Messe die tatsächliche Startzeit deiner Anwendung unter Last und setze die Grace Period auf diesen Wert plus einen Puffer.
- Prüfe den Health-Check-Pfad in der Target Group — ein falscher Pfad ist eine häufige stille Fehlerquelle.
- Stelle sicher, dass die Security Group der Instanz eingehenden Traffic vom Load Balancer auf dem Health-Check-Port erlaubt.
- Offizielle Dokumentation: AWS Auto Scaling Health Checks Overview
Glossar
| Begriff | Bedeutung |
|---|---|
| Health Check Grace Period | Zeitraum nach dem Instanz-Launch, in dem die ASG Health-Check-Ergebnisse ignoriert. Verhindert vorzeitige Terminierung während des Anwendungsstarts. |
| EC2 Health Check Typ | ASG bewertet Instanzgesundheit anhand der EC2-Systemstatuschecks (Hardware- und Netzwerkebene). |
| ELB Health Check Typ | ASG übernimmt den Gesundheitsstatus direkt aus der Target Group des zugehörigen Load Balancers. |
| Target Group | Logische Gruppe von Zielen (z.B. EC2-Instanzen) für einen Application Load Balancer, inklusive eigenem Health-Check-Konfiguration. |
| Impaired | EC2-Statusbezeichnung für eine Instanz, deren System- oder Instanzstatuscheck fehlgeschlagen ist. |
Kommentare
Kommentar veröffentlichen