Amazon SOA-C02: Rechenleistung und Auto Scaling — Lernleitfaden

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Teil des AWS SysOps Administrator Associate SOA-C02 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Dieser Bereich behandelt die Verwaltung von EC2-Instanzen und Auto Scaling, um zuverlässige und kosteneffiziente Rechenkapazität bereitzustellen. Der Fokus liegt auf den Lebenszyklus-Operationen von Instanzen, Skalierungsstrategien, der Integration von Load Balancern, der Platzierung für Performance und Resilienz sowie dem Wartungs- und Terminierungsverhalten, das die Verfügbarkeit und den Zustand beeinflusst. Operative Beherrschung bedeutet, die richtigen Instanztypen, Muster für Startkonfigurationen, Skalierungsrichtlinien und die Integration von Health-Checks auszuwählen, um SLAs zu erfüllen und gleichzeitig die Kosten zu kontrollieren.

EC2-Instanzlebenszyklus und -verwaltung

Das Lebenszyklusmanagement von EC2 beginnt bei der Startkonfiguration: Verwenden Sie Launch Templates (aws ec2 create-launch-template / Konsole), um AMI, Instanztyp, IAM-Instanzprofil, User-Data, Netzwerkschnittstellen, EBS-Mapping und Metadaten-Optionen zu erfassen; Templates unterstützen Versionierung, was Immutable Deploys vereinfacht. Immutable Deploys verwenden eine neue Version des Launch Templates (oder ein neues Launch Template) und erstellen entweder eine neue Auto Scaling Group oder nutzen den ASG Instance Refresh, um Instanzen zu ersetzen; vermeiden Sie In-Place-Upgrades laufender Instanzen, wenn Änderungen das Startverhalten oder Patches auf AMI-Ebene betreffen.

Operative Muster für CLI/Konsole umfassen

undefined

für einmalige Starts und

undefined

für ASG-gesteuerte Starts. Entscheiden Sie zwischen dem „Backen“ von AMIs (Packer/CodeBuild) und User-Data-Startskripten basierend auf der Startzeit: „Backen“ Sie aufwendige Abhängigkeiten in AMIs, um die Startdauer zu verkürzen; verwenden Sie User-Data für umgebungsspezifische Konfigurationen. Bei ephemerem Speicher denken Sie daran, dass Instance-Store-Volumes bei der Terminierung verloren gehen; konfigurieren Sie Root- und Daten-Volumes mit DeleteOnTermination=false, wenn Sie die Persistenz von EBS nach der Instanz-Terminierung benötigen.

Auto Scaling Groups, Richtlinien und Lifecycle Hooks

Auto Scaling Groups (ASGs) werden mit einem Launch Template oder einer Launch Configuration konfiguriert und steuern die gewünschte/minimale/maximale Kapazität über Availability Zones hinweg. Wählen Sie Launch Template + MixedInstancesPolicy für kostenoptimierte Flotten, die On-Demand und Spot mit einer Liste von Instanztypen mischen; verwenden Sie Instance Weighting und kapazitätsoptimierte Zuweisungsstrategien für vorhersagbare Kapazität. Für Deployments bevorzugen Sie Immutable Patterns: Erstellen Sie eine neue Version des Launch Templates und führen Sie einen ASG Instance Refresh oder einen Blue/Green-Swap durch, anstatt bestehende Instanzen neu zu konfigurieren.

Skalierungsrichtlinien werden ausgedrückt als:

Target Tracking (PolicyType=TargetTrackingScaling): Legen Sie eine vordefinierte Metrik wie ALB RequestCountPerTarget oder die durchschnittliche CPU-Auslastung der ASG und einen Zielwert fest; die ASG übernimmt die Anpassungen automatisch.
Step Scaling (PolicyType=StepScaling): Definieren Sie CloudWatch-Alarme, die basierend auf der Schwere der Überschreitung spezifische Anpassungsschritte (z. B. +2, +4) auslösen; nützlich für Workloads mit Lastspitzen.
Simple Scaling (Legacy): einstufige Anpassungen mit Cooldown; im Allgemeinen durch Target Tracking oder Step Scaling abgelöst.

Verwenden Sie Lifecycle Hooks (

undefined

), um die Terminierung/den Start von Instanzen zu pausieren. Lifecycle Hooks ermöglichen es Ihnen, Verbindungen zu „drainen“ (zu leeren), den Zustand zu replizieren (nach S3/RDS) oder Orchestrierungssysteme über SNS/SQS/Lambda vor dem Abschluss zu benachrichtigen; setzen Sie immer einen HeartbeatTimeout und eine Standardaktion, um blockierte Zustände zu vermeiden.

Elastic Load Balancing-Typen und Health Checks

Wählen Sie den Load-Balancer-Typ basierend auf dem Traffic-Muster: Application Load Balancer (ALB) für HTTP/HTTPS mit inhaltsbasiertem Routing und Host-/Pfad-Regeln; Network Load Balancer (NLB) für extreme Performance und statische IPs für TCP/UDP; Classic Load Balancer (CLB) nur für Legacy-Stacks. Erstellen Sie ALBs und Target Groups mit

undefined

und

undefined

; registrieren Sie ASG-Ziele, indem Sie die Target-Group-Zuordnung der ASG für eine automatische Integration des Lebenszyklus-Zustands verwenden.

Die Integration von Health-Checks erfordert die Abstimmung der Health-Checks von ASG und ELB: Setzen Sie den HealthCheckType der ASG auf ELB (

undefined

), sodass eine Instanz erst dann als fehlerfrei gilt, wenn der Load Balancer ihr Ziel als fehlerfrei markiert hat. Arten von Health-Checks und ihre Auswirkungen:

ALB/NLB Target Group Health Check: unterstützt HTTP/HTTPS/TCP und misst die Bereitschaft auf Anwendungsebene; empfohlen für Webanwendungen.
Nur ASG Health Checks: für einfache Überprüfungen auf Host-Ebene (z. B. EC2-Statusprüfungen) verwenden.
HealthCheckGracePeriod: Geben Sie neuen Instanzen Zeit zum Starten, Ausführen von User-Data und Bestehen der anwendungsspezifischen Prüfungen.

Auswirkungen von Stickiness: Die Stickiness von ALB Target Groups verwendet eine auf Anwendungs-Cookies basierende Affinität (dauerbasiert), was die Sitzungsaffinität verbessern kann, aber eine gleichmäßige Verteilung reduziert und Rolling Updates erschwert. NLB unterstützt Client-IP-Affinität; verwenden Sie Stickiness nur, wenn der Sitzungszustand nicht externalisiert werden kann.

Platzierung von Instances, Kapazitätsplanung und Skalierungsmetriken

Platzierungsentscheidungen beeinflussen Latenz und Fehlerdomänen: Platzierungsgruppen (Placement Groups) bieten die Strategien Cluster (Netzwerk mit geringer Latenz), Spread (eine Instance pro Rack für kritische Instances) und Partition (fehlerisolierte Partitionen). ASGs verteilen Instances standardmäßig über AZs hinweg; bevorzugen Sie eine AZ-bewusste Kapazitätsplanung, um Hotspots in einzelnen AZs zu vermeiden. Für die CLI:

undefined

Die Kapazitätsplanung berücksichtigt Instance-Typen, Kaufoptionen und Metriken:

Instance-Typen: Wählen Sie CPU-/speicher-/netzwerkoptimierte Familien (M/C/R/T/D/I) basierend auf der Workload; messen Sie dies mit repräsentativen Lasttests.
Kaufoptionen: On-Demand für Vorhersehbarkeit, Reserved oder Savings Plans für Kostensenkungen bei stabiler Auslastung, Spot für Kosteneffizienz bei transienten Workloads; verwenden Sie eine MixedInstancesPolicy, um Typen und Kaufoptionen zu kombinieren.
Skalierungsmetriken: Standard-ASG-Metriken verwenden die durchschnittliche CPU-Auslastung der Gruppe; bevorzugen Sie Metriken auf Anwendungsebene wie ALB RequestCountPerTarget oder benutzerdefinierte CloudWatch-Metriken (z. B. Warteschlangentiefe) für das Target Tracking. Gängige Muster:
Verwenden Sie Target Tracking mit ALB/request-count-per-target, wenn Sie eine stabile Anzahl von Anfragen pro Instance benötigen.
Verwenden Sie Step Scaling für plötzliche, große Lastspitzen mit definierten Wiederherstellungsschritten.
Ziehen Sie Predictive Scaling für täglich zyklische Workloads in Betracht.

Wiederherstellung von Instances, Beendigungsverhalten und Wartung

Planen Sie für Instance-Ausfälle und Wartungsarbeiten, indem Sie die automatische Wiederherstellung bei Hardwareproblemen aktivieren (CloudWatch-Alarm mit EC2 Recover-Aktion) und geplante Ereignisse behandeln (describe-instance-status). Konfigurieren Sie die Flags instance-initiated-shutdown-behavior und EBS DeleteOnTermination, um den Lebenszyklus von Volumes zu steuern; verwenden Sie

undefined

zur Anpassung.

Beendigungsverhalten in ASGs: ASG-Beendigungsrichtlinien (Termination Policies) entscheiden, welche Instance zuerst beendet wird (Standard: älteste Startkonfiguration oder Heuristiken für Instance-Zustand und AZ-Verteilung). Wichtige operative Details:

Lokaler Zustand ist flüchtig: Instance-Store-Volumes und In-Memory-Caches gehen bei der Beendigung verloren. Gehen Sie nicht davon aus, dass der lokale Zustand bei einem Austausch erhalten bleibt; persistieren Sie kritische Daten auf EBS (mit entsprechenden Snapshots/Backups), S3 oder einem externen Cache (ElastiCache).
Verwenden Sie Lifecycle Hooks, um den Datenverkehr abzuleiten (Drain) und den Zustand vor der Beendigung auszulagern.
Verwenden Sie Instance Refresh oder Blue/Green für Wartungsarbeiten, um Instances sicher zu ersetzen;

undefined

Häufige Fallstricke und Entscheidungskriterien

Verlassen auf Standard-Cooldowns und reine CPU-Metriken: Wählen Sie Metriken, die auf das Anwendungsverhalten abgestimmt sind (ALB RequestCountPerTarget, Warteschlangentiefe); legen Sie Cooldowns fest, um die Startzeit zu berücksichtigen, und eine HealthCheckGracePeriod, um Oszillationen zu vermeiden.
Keine Verwendung von Lifecycle Hooks für eine ordnungsgemäße Beendigung (Graceful Termination): Ohne Hooks gehen In-Flight-Anfragen und lokale Caches verloren; implementieren Sie Hooks mit SNS/SQS/Lambda, um den Zustand abzuleiten und zu persistieren.
Annahme, dass der lokale Zustand beim Austausch von Instances erhalten bleibt: Lokale Instance-Stores und In-Memory-Caches sind flüchtig; entwerfen Sie für zustandslose Instances oder replizieren Sie den Zustand in dauerhafte Speicher.
Übermäßige Verwendung von Stickiness: Stickiness erhöht die ungleichmäßige Lastverteilung und erschwert die Skalierung und Updates; bevorzugen Sie externe Session-Speicher (ElastiCache, DynamoDB) für das Scale-out.
Ignorieren der AZ-Verteilung und von Platzierungsgruppen: Die Platzierung zu vieler Instances in einer AZ oder Cluster-Gruppe kann Single Points of Failure erzeugen; nutzen Sie die Multi-AZ-Verteilung von ASGs und geeignete Strategien für Platzierungsgruppen.
Fehlkonfiguration der Health-Check-Integration: Der ASG health-check-type muss mit den ELB/Target-Group-Health-Checks übereinstimmen und die HealthCheckGracePeriod muss lang genug für die Anwendungsinitialisierung sein, andernfalls werden fehlerfreie Instances beendet.

Praktisches Problem: Anwendungsfallszenario

StreamingCo betreibt eine Video-Thumbnail-API, die tägliche Lastspitzen erfährt und lokale Festplatten-Caches auf EC2-Instances verwendet. In letzter Zeit war das Hochskalieren (Scale-up) langsam, und beendete Instances verlieren ihren Cache, was zu schlechten Antwortzeiten führt.

Migrieren Sie die Launch Configuration in ein Launch Template und erstellen Sie ein schlankes AMI (Bake) mit Laufzeitabhängigkeiten; verwenden Sie

undefined

und Versionierung für unveränderliche (immutable) Deployments. 2. Konfigurieren Sie eine ASG mit einer MixedInstancesPolicy, die mehrere Instance-Typen und eine Zuweisung von Spot + On-Demand auflistet, um Kosten und Kapazität auszugleichen. 3. Hängen Sie einen ALB an und verwenden Sie TargetTrackingScaling für die Metrik ALB RequestCountPerTarget mit einer HealthCheckGracePeriod, die auf die Bootstrap-Zeit der Anwendung eingestellt ist. 4. Implementieren Sie Lifecycle Hooks für ASG-Beendigungen, um Verbindungen abzuleiten (Drain) und einen Lambda/SNS-Flow auszuführen, um notwendige Cache-Schlüssel vor der Beendigung in ElastiCache oder S3 zu persistieren. 5. Lagern Sie den Session- und Cache-Zustand nach ElastiCache oder S3 aus und verwenden Sie Platzierungsgruppen/AZ-Verteilung, um die Anforderungen an Latenz und Fehlerdomänen zu erfüllen.

Begründung: Die Verwendung von Launch Templates und unveränderlichen Deployments reduziert die Variabilität beim Starten; das auf den ALB ausgerichtete Target Tracking koppelt die Skalierung an die Anfragelast statt an die CPU; Lifecycle Hooks verhindern Datenverlust bei der Beendigung; die Auslagerung des Caches beseitigt die Abhängigkeit vom flüchtigen lokalen Zustand und ermöglicht eine schnelle, sichere Skalierung sowie niedrigere Kosten durch gemischte Instance-/Kaufstrategien.

← Speicher und Datenverwaltung · Alle Domänen · Datenbanken und Caching →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →