Amazon SAA-C03: Compute, Auto Scaling & Instanzverwaltung — Lernleitfaden

By Laurynas Brazys · 17 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Teil des AWS SAA-C03 — Vollständiger Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

EC2-Instance-Typen und AMIs

Die Auswahl der richtigen EC2-Instance-Familie ist die Grundlage einer gut konzipierten Compute-Ebene, da Familie, Generation und Größe zusammen die CPU-Architektur, das Verhältnis von Arbeitsspeicher zu vCPU, die Netzwerkbandbreite und die verfügbaren Beschleuniger bestimmen. Allzweck (M6i, M7g, T-Serie) eignet sich für ausgewogene Web-Tiers und gemischte Workloads. Rechenoptimiert (C7i, C7gn) passt zu CPU-gebundenen Simulationen, Encoding, Batch-Verarbeitung und Web-Frontends. Speicheroptimiert (R7i, X2idn) zielt auf In-Memory-Datenbanken und Caches ab. Speicherplatzoptimiert (I4i, D3) zielt auf NoSQL, HDFS und Data Warehousing ab. Beschleunigt (P5, G5, Trn1, Inf) bietet GPUs oder ML-Chips. Graviton-Instances (g-Suffix) liefern typischerweise ein um 20–40 % besseres Preis-Leistungs-Verhältnis für horizontal skalierbare Workloads, die sich sauber für ARM64 kompilieren lassen.

Die T-Familie ist burstable und verwendet standardmäßig den Standard-Modus, bei dem sich CPU-Guthaben im Leerlauf ansammeln und bei Lastspitzen verbraucht werden; wenn das Guthaben aufgebraucht ist, wird die Leistung auf die Basisleistung gedrosselt. Für Workloads mit unvorhersehbaren Lastspitzen – kleine Web-Tiers, Dev/Test-Umgebungen oder Elastic Beanstalk-Umgebungen für ein Frontend mit schwankender Last – ermöglichen T-Instances im unbegrenzten Modus, dass die Instance Guthaben leiht und ein kleiner Aufschlag pro vCPU-Stunde der Überschreitung berechnet wird, wodurch eine für den Benutzer sichtbare Drosselung vermieden wird. Aus diesem Grund werden Beanstalk-Umgebungen mit kurzer CPU-Sättigung in der Regel durch die Aktivierung des unbegrenzten Modus behoben, anstatt auf eine teurere rechenoptimierte Familie aufzurüsten. Es ist wichtig, die T-Serie für wirklich unregelmäßige Workloads mit geringer durchschnittlicher Auslastung zu reservieren: Eine dauerhafte CPU-Last im Standard-Modus verbraucht das Guthaben innerhalb von Minuten.

Die vertikale Skalierung (Wechsel zu einer größeren Größe innerhalb der Familie) ist durch die größte verfügbare Instance begrenzt, erzwingt eine Ausfallzeit für die Änderung, führt einen Single Point of Failure ein und kann die Last nicht auf mehrere Availability Zones verteilen. Immer wenn die Last stark schwankt, ist die horizontale Skalierung mit einer Auto Scaling Group die richtige Antwort.

Golden AMIs backen Anwendungscode, Laufzeitumgebung und Abhängigkeiten in den Root-Snapshot ein und ermöglichen so schnelle, deterministische Starts – entscheidend, wenn Auto Scaling auf eine Lastspitze reagiert. Bootstrapping über User-Data bei jedem Start fügt Latenz von mehreren Minuten hinzu, und das genau im falschen Moment.

Speicheroptionen: Instance-Speicher vs. EBS, Snapshots und Fast Snapshot Restore

Instances bieten zwei Speichersubstrate: Instance-Speicher (flüchtiger NVMe-Speicher, der an den physischen Host angeschlossen ist) und Amazon EBS (netzwerkgebundener Blockspeicher). Der Instance-Speicher liefert die geringstmögliche Latenz, aber seine Daten werden beim Anhalten, Ruhezustand, Beenden oder bei einem Hardwarefehler zerstört. Ihn als dauerhaften Speicher zu behandeln, ist ein häufiger und gefährlicher Fehler – er eignet sich nur für temporären Speicherplatz (Scratch Space), Puffer, Caches oder replizierte Daten wie bei einem HDFS-Datenknoten, dessen Replikate auf anderen Knoten existieren. Dauerhafte Daten gehören auf EBS, gesichert durch Snapshots, die in S3 gespeichert sind.

Snapshots sind nach ihrer Erstellung inkrementell und unabhängig, sodass die Wiederherstellung eines Snapshots auf einem neuen Volume die Quelle niemals beeinflusst. Der kanonische Weg, einen großen Produktionsdatensatz in eine Testumgebung zu duplizieren, besteht darin, einen Snapshot des Quell-Volumes zu erstellen und aus diesem Snapshot neue Volumes zu erzeugen. Allerdings laden Volumes, die aus Snapshots wiederhergestellt werden, Blöcke beim ersten Lesezugriff per Lazy-Loading aus S3, was zu erheblicher I/O-Latenz führt, bis jeder Block vollständig geladen ist. Dasselbe Lazy-Loading betrifft neue Instances, die von AMIs mit großen Root-Snapshots gestartet werden – sie wirken in den ersten Minuten nach dem Start träge.

EBS Fast Snapshot Restore (FSR) eliminiert diesen Nachteil. Aktivieren Sie FSR für den Snapshot in den AZs, in denen die ASG Instances startet, und daraus erstellte Volumes liefern sofort die volle bereitgestellte Leistung:

aws ec2 enable-fast-snapshot-restores \
  --availability-zones us-east-1a us-east-1b \
  --source-snapshot-ids snap-0123456789abcdef0

Dies ist unerlässlich, wenn Scale-Out-Ereignisse Kapazität in Sekunden statt in Minuten hinzufügen müssen.

Erweitertes Networking mit ENA und EFA

Der beworbene Netzwerkdurchsatz skaliert mit der Instance-Größe, ist aber nur erreichbar, wenn der Treiber für den Elastic Network Adapter (ENA) vorhanden ist. ENA bietet SR-IOV-basiertes erweitertes Networking und unterstützt bis zu 200 Gbit/s auf neueren Instances. Moderne AMIs (Amazon Linux 2, aktuelle Ubuntu-, Windows-Versionen) werden mit aktiviertem ENA ausgeliefert; überprüfen Sie dies mit:

aws ec2 describe-instances --instance-ids i-0abc \
  --query 'Reservations[].Instances[].EnaSupport'

modinfo ena | grep version
ethtool -i eth0

Ohne ENA fallen Instances unbemerkt auf einen geringeren Durchsatz und höheren Jitter zurück, was jedes auf niedrige Latenz ausgelegte Design untergräbt, unabhängig von der Wahl der Placement-Group.

Für kollektive Operationen im Mikrosekundenbereich – CFD, Wettermodellierung, Molekulardynamik, Training großer Modelle – fügen Sie einen Elastic Fabric Adapter (EFA) hinzu. EFA stellt MPI und NCCL einen OS-Bypass-Transport (Libfabric) zur Verfügung, der den Kernel-Netzwerk-Stack vollständig umgeht. EFA entfaltet seinen Vorteil nur innerhalb einer Cluster-Placement-Group auf unterstützten Instance-Typen (c7gn, hpc7a, p5) und erfordert den EFA-Treiber sowie einen kompatiblen MPI- (Open MPI, Intel MPI) oder NCCL-Build.

aws ec2 create-placement-group --group-name hpc-cg --strategy cluster
aws ec2 run-instances --instance-type hpc7a.96xlarge \
  --placement GroupName=hpc-cg \
  --network-interfaces InterfaceType=efa,DeviceIndex=0,SubnetId=subnet-abc

Placement Groups

Platzierungsgruppen (Placement Groups) steuern die physische Topologie von Instanzen:

Eine falsche Wahl verschwendet die Funktion. Eine Cluster-Gruppe kann sich nicht über AZs erstrecken – sie ist per Design intra-AZ. Spread kann aufgrund der Obergrenze von sieben pro AZ keine hundert Webserver hosten. Partition Placement, nicht Spread, ist das richtige Werkzeug für einen 40-Knoten-Kafka-Cluster, da es die Replikatplatzierung an den Fehlerdomänen ausrichtet. Für allgemeine Hochverfügbarkeit beschränken Sie eine ASG nicht auf eine Platzierungsgruppe in einer AZ – verteilen Sie die ASG über mehrere AZs.

Für Streaming-Analysen oder MPI-Workloads, die eine minimale Latenz von Knoten zu Knoten erfordern, ist die richtige Kombination eine Cluster-Platzierungsgruppe plus ENA-fähige Instanzen; Cluster reduziert die Anzahl der Hops und ENA liefert die Kapazität an Paketen pro Sekunde, die erforderlich ist, um diesen Latenzvorteil zu realisieren.

Auto Scaling Groups und Launch Templates

Eine Auto Scaling Group (ASG) ist die Laufzeiteinheit, die eine gewünschte Anzahl von EC2-Instanzen über eine oder mehrere AZs aufrechterhält, definiert durch drei Ganzzahlen – MinSize, DesiredCapacity, MaxSize – und eine Liste von Subnetzen. Die ASG selbst beschreibt nicht, was gestartet werden soll; das ist die Aufgabe eines Launch Template, dem modernen Ersatz für Launch Configurations. Launch Templates unterstützen Versionierung, Richtlinien für gemischte Instanzen, die Mischung von Spot- und On-Demand-Instanzen, die Erzwingung von IMDSv2, Kapazitätsreservierungen und T-Instanzen im unbegrenzten Modus. Ein Launch Template referenziert ein AMI, Instanztyp(en), Sicherheitsgruppen, ein IAM-Instanzprofil, Benutzerdaten und Block-Device-Mappings.

Das kanonische Muster für zustandslose Webanwendungen ist AMI + Launch Template + ASG + ALB. Das AMI sorgt für einen schnellen Start; der ALB (oder NLB für TCP/UDP) verteilt den Datenverkehr und führt Zustandsprüfungen durch; die ASG registriert neue Instanzen automatisch in der Zielgruppe und beendet fehlerhafte. Ein Multi-AZ-Deployment (mindestens zwei AZs, drei für Quorum-Systeme) ist zwingend erforderlich – eine an ein einzelnes Subnetz gebundene ASG kann einen AZ-Ausfall nicht überstehen, da die ASG selbst keine Ersatzinstanzen starten kann, während die AZ beeinträchtigt ist.

MyASG:
  Type: AWS::AutoScaling::AutoScalingGroup
  Properties:
    MinSize: 2
    MaxSize: 20
    DesiredCapacity: 4
    VPCZoneIdentifier: [subnet-a, subnet-b]
    TargetGroupARNs: [!Ref AppTargetGroup]
    LaunchTemplate:
      LaunchTemplateId: !Ref AppLT
      Version: !GetAtt AppLT.LatestVersionNumber
    HealthCheckType: ELB
    HealthCheckGracePeriod: 120

Skalierungsrichtlinien: Target Tracking, Step, Scheduled, Predictive

Die ASG-Skalierung hat vier Modi, von denen jeder ein anderes Problem löst:

• Target Tracking wählt eine Metrik und hält sie nahe an einem Sollwert (z. B. ASGAverageCPUUtilization = 50%, ALBRequestCountPerTarget = 1000). Es ist selbstoptimierend – AWS verwaltet die Alarme und passt die Geschwindigkeit an, wenn die Metrik abweicht. Dies sollte die Standardwahl sein.
• Step Scaling fügt Kapazität in abgestuften Stufen hinzu oder entfernt sie, je nachdem, wie weit eine Metrik außerhalb des Bereichs liegt. Dies ist nützlich, wenn die Reaktionsgröße mit dem Schweregrad des Alarms skalieren muss.
• Simple Scaling ist veraltet: eine einzige Anpassung pro Alarm, blockiert während des Cooldowns und sollte für neue Designs nicht gewählt werden.
• Scheduled Scaling ändert MinSize/DesiredCapacity/MaxSize zu Cron-Zeiten.
• Predictive Scaling nutzt maschinelles Lernen auf Basis von bis zu 14 Tagen an Verlaufsdaten, um die nächsten 48 Stunden vorherzusagen und Kapazität vor dem Anstieg bereitzustellen.

Dynamische Skalierung ist von Natur aus verzögert – sie reagiert erst, nachdem eine Metrik einen Schwellenwert überschreitet, und neue Instanzen benötigen dann Minuten zum Starten, Registrieren und Aufwärmen. Für eine Mitarbeiteranwendung, bei der alle Benutzer um 09:00 Uhr ankommen und 2–3 Stunden Verlangsamung erleben, während die ASG aufholt, ist die dynamische Skalierung allein die falsche Antwort. Fügen Sie zeitgesteuerte Aktionen vor der Spitze hinzu, um MinSize und DesiredCapacity zu erhöhen, bevor die Nachfrage eintrifft:

ScheduledAction:
  AutoScalingGroupName: web-asg
  ScheduledActionName: pre-sale-warmup
  Recurrence: "0 8 * * *"
  MinSize: 20
  DesiredCapacity: 30
  MaxSize: 200

Lassen Sie dann Target Tracking die restliche Variabilität absorbieren. Predictive Scaling ist die richtige Wahl, wenn die Form der Spitze stabil ist, aber ihr genauer Zeitpunkt von Tag zu Tag schwankt. Für vorhersehbare Abschaltungen außerhalb der Produktion (Entwicklungsumgebungen nachts und am Wochenende), ist eine zeitgesteuerte Aktion, die am Freitagabend auf desired=0, min=0 setzt und am Montagmorgen wieder hochfährt, die Lösung mit dem geringsten Aufwand – die ASG selbst ist die Zeitplan-Engine, es ist kein Lambda- oder EventBridge-Glue-Code erforderlich.

Die Wahl der Metrik ist genauso wichtig wie die Wahl der Richtlinie. CPU funktioniert für CPU-gebundene Web-Workloads, aber für Backlog-gesteuerte Worker, die aus SQS abrufen, müssen Sie nach der Warteschlangentiefe skalieren, nicht nach der CPU: Ein durch I/O blockierter Worker kann 10 % CPU-Auslastung anzeigen, während sich Millionen von Nachrichten ansammeln. Verwenden Sie ApproximateNumberOfMessagesVisible pro Instanz, bereitgestellt als benutzerdefinierte Metrik oder über das integrierte SQSQueueBacklogPerInstance-Ziel:

backlog_per_instance = messages_visible / running_instances
target = acceptable_latency_seconds / avg_processing_seconds_per_msg

TargetTrackingConfiguration:
  CustomizedMetricSpecification:
    MetricName: BacklogPerInstance
    Namespace: MyApp/Scaling
    Statistic: Average
  TargetValue: 100

Ebenso sollten latenzempfindliche HTTP-Tiers TargetResponseTime oder RequestCountPerTarget verfolgen; speicher-, festplatten- oder durch nachgelagerte Latenz gebundene Anwendungen sollten eine benutzerdefinierte Metrik veröffentlichen, die den tatsächlichen Engpass widerspiegelt. Das Skalieren nach CPU, wenn die CPU nicht der Engpass ist, führt genau zu dem Fehlermodus, bei dem Instanzen niemals aufskalieren, Warteschlangen unbegrenzt wachsen und der ALB 5xx-Fehler zurückgibt.

Zustandsprüfungen und Lebenszyklus-Hooks

ASGs verwenden standardmäßig EC2-Statusprüfungen, welche Hypervisor-Ausfälle, aber keine Anwendungsfehler erkennen. Die Aktivierung von ELB-Zustandsprüfungen für die ASG delegiert die Entscheidung über den Austausch an die anwendungsspezifische Prüfung des Load Balancers, was unerlässlich ist, wenn das Betriebssystem in Ordnung ist, aber der Prozess hängt. Setzen Sie HealthCheckGracePeriod lang genug, damit die Benutzerdaten-Skripte abgeschlossen werden können; andernfalls werden neue Instanzen mitten im Bootstrap-Prozess in einer Schleife beendet.

Die Wahl des Load Balancers beeinflusst die Bedeutung von „fehlerfrei“:

Eine HTTP-Anwendung hinter einem NLB, der nur TCP-Zustandsprüfungen durchführt, wird weiterhin Traffic von einer Instanz bedienen, die Verbindungen akzeptiert, aber 500er-Fehler zurückgibt. Wechseln Sie zu einem ALB – oder konfigurieren Sie HTTP-Zustandsprüfungen auf dem NLB –, um eine aussagekräftige Signalisierung wiederherzustellen.

Lebenszyklus-Hooks pausieren Instanzen im Zustand Pending:Wait oder Terminating:Wait, damit externe Automatisierungen agieren können. Beim Start ermöglicht ein Hook die Registrierung bei einem Konfigurationsmanagementsystem, das Aufwärmen von Caches oder das Abrufen von Secrets, bevor der ALB Traffic sendet. Beim Beenden ermöglicht ein Hook das Leeren von Sitzungen (Session Draining), das Schreiben von Protokollen (Log Flushing) und die Abmeldung von einem Service Mesh. Hooks geben EventBridge-Ereignisse aus; die Handler müssen CompleteLifecycleAction aufrufen, sonst läuft der Hook in einen Timeout und führt seine Standardaktion aus (CONTINUE oder ABANDON).

Warm-Pools und Ruhezustand

Die Kaltstartzeit ist ein echtes Problem für Anwendungen, die große Modelle laden, Caches aufwärmen oder vor der Bereitstellung JIT-kompilieren. Ein Warm-Pool ist eine vorinitialisierte Reserve, die an die ASG angehängt ist: Instanzen starten, führen Bootstrap-Skripte aus, werden dann gestoppt, weiter ausgeführt oder in den Ruhezustand versetzt und im Pool gehalten, bis die ASG aufskaliert. Das Abrufen aus dem Pool überspringt minutenlange Startvorgänge.

Der Ruhezustand (Hibernation) friert das Betriebssystem auf dem verschlüsselten EBS-Root-Volume ein, sodass der JVM-Heap, ML-Gewichte und der OS-Page-Cache bei der Wiederaufnahme wiederhergestellt werden. Anforderungen: ein verschlüsseltes Root-Volume, das groß genug ist, um den RAM zu speichern, ein Instanz-RAM von ≤ 150 GB auf einer unterstützten Familie und HibernationOptions.Configured = true beim Start. Ein Warm-Pool mit PoolState: Hibernated kombiniert beides – Instanzen kosten im gestoppten Zustand keine Rechenleistung und werden in Sekunden mit gefülltem Speicher wieder aufgenommen. Dies ist das richtige Muster, wenn eine Anwendung „lange braucht, um den Speicher zu laden, bevor sie produktiv ist“.

Automatische Wiederherstellung für nicht skalierbare Workloads

Nicht jeder Workload skaliert horizontal. Legacy-Anwendungen mit MAC-gebundenen Lizenzen, dateibasierten Sperren oder In-Memory-Sitzungszuständen ohne gemeinsamen Speicher können nicht auf mehr als einer Instanz ausgeführt werden – das Hochfahren zusätzlicher Knoten führt zu Datenkorruption oder Lizenzverstößen. Für diese wird Resilienz durch automatische Wiederherstellung erreicht, nicht durch Aufskalieren.

Zwei Muster funktionieren hier. Ein CloudWatch-Alarm für StatusCheckFailed_System, gekoppelt mit der EC2-Wiederherstellungsaktion, erhält die Instanz-ID, die private IP, die Elastic IP und die EBS-Anhänge über den Ausfall des zugrunde liegenden Hosts hinweg. Noch einfacher: eine ASG mit MinSize=MaxSize=1, die sich über mehrere AZs erstreckt, ersetzt eine ausgefallene Instanz und kann im Gegensatz zur Wiederherstellungsaktion einen AZ-Ausfall überstehen – vorausgesetzt, der Zustand wird außerhalb des Root-Volumes externalisiert oder das AMI ist wiederherstellbar.

Load Balancer und Subnetz-Platzierung

ALB arbeitet auf L7, terminiert HTTP/HTTPS und bietet Routing nach Host/Pfad/Header, HTTP/2, WebSockets sowie Integration mit WAF/Cognito/OIDC. NLB arbeitet auf L4, erhält die Client-IP, unterstützt statische IPs und TLS-Passthrough, PrivateLink und bewältigt Millionen von Verbindungen pro Sekunde. Gateway Load Balancer fügt Appliances von Drittanbietern (Firewalls, IDS) in den Datenverkehrspfad ein.

Die Platzierung in Subnetzen ist der Punkt, an dem Architekturen am häufigsten scheitern. Ein ins Internet gerichteter ALB muss an öffentliche Subnetze angebunden sein – also Subnetze mit einer 0.0.0.0/0-Route zu einem Internet Gateway – eines pro AZ, in der sich die Ziele befinden. Die Ziele selbst verbleiben in privaten Subnetzen. Wenn der ALB in privaten Subnetzen platziert wird oder den „öffentlichen“ Subnetzen eine IGW-Standardroute fehlt, erhalten Clients Verbindungs-Timeouts. Die Erreichbarkeit der Ziele erfordert, dass die Sicherheitsgruppe der Ziele eingehenden Verkehr von der Sicherheitsgruppe des ALB auf dem Zielport zulässt; zwischen ALB und Zielen in derselben VPC ist kein NAT erforderlich.

Client → IGW → ALB (public subnets, SG: allow 443 from 0.0.0.0/0)
              → Targets (private subnets, SG: allow 8080 from ALB-SG)

Aktivieren Sie ELB-Zustandsprüfungen für die ASG, damit fehlerhafte Ziele ersetzt und nicht nur abgemeldet werden. Zonenübergreifender Lastausgleich (standardmäßig bei ALB, optional bei NLB) sorgt für eine gleichmäßige Verteilung der Anfragen, unabhängig von der Anzahl der Instanzen pro AZ. Route 53 muss über einen Alias-Record (oder eine gewichtete/latenzbasierte Richtlinie über mehrere ALBs hinweg) auf den ALB verweisen – richten Sie Route 53 niemals auf einzelne EC2-IPs, da eine ausgefallene Instanz bis zum Ablauf der TTL weiterhin Traffic erhält und der ASG-Ersatz eine andere IP-Adresse hat.

Kaufmodelle und gemischte Instanz-Flotten

Die Wahl des Kaufmodells ist der größte Hebel zur Reduzierung der EC2-Ausgaben, unabhängig vom Architekturmuster.

Die rationale Strategie: Grundlast auf Reserved Instances oder einem Savings Plan, Lastspitzen auf On-Demand, fehlertolerante Aufgaben auf Spot. In einer ASG wird dies als Mixed-Instances-Policy ausgedrückt:

MixedInstancesPolicy:
  LaunchTemplate:
    LaunchTemplateSpecification:
      LaunchTemplateId: lt-0abc123
      Version: $Latest
    Overrides:
      - InstanceType: m5.large
      - InstanceType: m5a.large
      - InstanceType: m6i.large
      - InstanceType: m6a.large
  InstancesDistribution:
    OnDemandBaseCapacity: 4          # covered by Savings Plan
    OnDemandPercentageAboveBaseCapacity: 20
    SpotAllocationStrategy: price-capacity-optimized

Die Diversifizierung von Instanztypen vertieft den Spot-Pool und reduziert korrelierte Unterbrechungen. price-capacity-optimized (oder capacity-optimized) gleicht den Preis mit der Pool-Tiefe ab, sodass Instanzen seltener zurückgefordert werden.

Spot eignet sich für zustandslose, checkpoint-fähige, wiederholbare oder horizontal redundante Workloads: Web-Worker hinter einem ALB, Batch-Jobs mit automatischer Wiederholung, Spark-Executors, CI-Runner. Es ist nicht als alleinige Kapazität für kritische, ständig aktive Dienste, zustandsbehaftete primäre Datenbanken oder Leader-Knoten ohne Wiederherstellungspfad geeignet – die Zwei-Minuten-Benachrichtigung kann kein sicheres Herunterfahren garantieren, und die korrelierte, flottenweite Rückforderung eines bestimmten Instanztyps ist ein realer Fehlermodus. Wenn die Anforderung lautet „darf nicht unterbrochen werden“, ist Spot disqualifiziert.

Die umgekehrte Falle ist die Anwendung von RIs oder Savings Plans auf wirklich variable Workloads: Sie zahlen die stündliche Verpflichtung, ob genutzt oder nicht. Ein Workload, der 40 Stunden pro Woche läuft, bei einer Verpflichtung für 168 Stunden, verschwendet also 76 % der Reservierung. Wenn die Kapazität selbst – nicht der Preis – das Anliegen ist (ereignisgesteuerte Lastspitzen, Disaster Recovery), verwenden Sie eine On-Demand Capacity Reservation: eine reine, auf eine AZ beschränkte Garantie zu On-Demand-Raten, die für den Rabatt mit einem Savings Plan kombiniert werden kann.

Serverless Compute: Lambda und Fargate

Serverless verlagert das Kapazitätsmanagement auf die Plattform. Lambda eignet sich für ereignisgesteuerte, kurzlebige Aufgaben: S3 ObjectCreated-Trigger, DynamoDB Streams, SQS-Consumer mit geringem Volumen, API Gateway-Backends, Glue-Logik. Der Speicher (128 MB – 10.240 MB) stellt die CPU proportional bereit, sodass eine Erhöhung des Speichers oft die Kosten senkt, indem die Ausführungsdauer verkürzt wird. Harte Limits definieren den Anwendungsbereich: 15 Minuten maximale Ausführung, 10 GB Speicher, 10 GB /tmp, 250 MB entpacktes Deployment (oder 10 GB über ein Container-Image), 6 MB synchrone Nutzlast. Lambda für eine 30-minütige Videotranskodierung, einen mehrstündigen ETL-Prozess oder GPU-Training zu verwenden, ist architektonisch falsch – die Funktion erleidet mitten in der Arbeit einen Timeout, und die Wiederholungslogik vervielfacht nur die Verschwendung. Für latenzempfindliche Pfade sollten Kaltstarts und die Initialisierungszeit von an VPCs angebundenen ENIs mit Provisioned Concurrency gemindert werden.

Fargate führt Container aus, ohne EC2-Hosts verwalten zu müssen. Es ist die richtige Wahl, wenn Aufgaben 15 Minuten überschreiten, benutzerdefinierte Runtimes benötigen oder zur ECS/EKS-Orchestrierung passen, das Team aber keine Kapazität verwalten möchte. Fargate ist pro vCPU-Stunde teurer als EC2 Spot. Wenn also die Auslastung im stabilen Zustand hoch und vorhersagbar ist, ist eine ASG mit gemischten Instanzen und Spot auf ECS kostengünstiger. Bei stoßartigem oder unvorhersehbarem Datenverkehr gewinnt die sekundengenaue Abrechnung von Fargate.

Für die Orchestrierung vieler Lambdas sind Step Functions der Verkettung über SNS/SQS vorzuziehen, da sie einen visuellen Ausführungsverlauf, Wiederholungssemantik, eine zentralisierte Fehlerbehandlung und einen dauerhaften Zustand bieten. Standard-Workflows werden pro Zustandsübergang abgerechnet und können bis zu einem Jahr laufen; Express-Workflows sind für die Verarbeitung von ereignisgesteuerten Prozessen mit hohem Volumen und kurzer Dauer optimiert.

Für den Fan-Out von Tausenden von parametrisierten, containerisierten Jobs – Genomik, Monte-Carlo-Simulationen, ETL – übernimmt AWS Batch das Queuing, die Auflösung von Abhängigkeiten, Wiederholungsversuche und die Bereitstellung auf verwaltetem EC2, Spot oder Fargate. Jobs verweisen auf eine Job-Definition (Container + vCPU/Speicher + IAM-Rolle), und Batch packt sie per Bin-Packing auf passend dimensionierte Instanzen. Step Functions orchestriert häufig Batch, Lambda und ECS innerhalb einer einzigen State Machine.

Elastic Beanstalk

Beanstalk ist ein verwaltetes PaaS, das den ALB, die ASG, EC2-Instanzen und optional RDS aus einem Anwendungs-Bundle bereitstellt. Es unterstützt Rolling-, Rolling-with-additional-batch-, Immutable- und Blue/Green-Deployments mit CloudWatch-Integration. Skalierungsrichtlinien werden als Umgebungsoptionen (Metrik, Schwellenwerte, Min/Max) bereitgestellt. Da Beanstalk standardmäßig Burstable-Instanztypen verwendet, ist die Aktivierung des T-Unlimited-Modus die einfachste Lösung für kurzzeitige CPU-Sättigung. Geplante Skalierungsaktionen werden wie bei jeder anderen ASG an die von Beanstalk verwaltete ASG angehängt. Wählen Sie Beanstalk, wenn das Team eine Standard-Web-App-Topologie ohne selbst erstelltes CloudFormation wünscht und wenn Rolling Updates und versionierte Bundles zum Release-Rhythmus passen.

Flottenmanagement mit Systems Manager

SSH- und Bastion-Muster sind fragil und teuer in der Absicherung. AWS Systems Manager ersetzt diese. Der SSM Agent (vorinstalliert auf Amazon Linux 2, Ubuntu, Windows) sowie ein Instanzprofil, das AmazonSSMManagedInstanceCore gewährt, ist alles, was benötigt wird.

• Run Command führt Shell/PowerShell auf getaggten Flotten aus und konsolidiert die Ausgabe.
• Session Manager öffnet interaktive Shells über die AWS-API – kein eingehender Port 22, kein Bastion-Host, vollständige IAM-Authentifizierung, Sitzungen werden in S3 oder CloudWatch Logs protokolliert.
• Patch Manager wendet Betriebssystem-Patches nach Zeitplänen unter Verwendung von Wartungsfenstern an.

aws ssm send-command \
  --targets Key=tag:Env,Values=prod \
  --document-name AWS-RunShellScript \
  --parameters 'commands=["yum -y update"]'

Geplante Start/Stopp-Automatisierung

Für Nicht-Produktions-EC2 und -RDS, die außerhalb der Geschäftszeiten abgeschaltet sein müssen, ist das wartungsarme Muster EventBridge Scheduler → Lambda. Eine Cron-Regel (cron(0 19 ? * MON-FRI *)) ruft eine Lambda-Funktion auf, die getaggte Ressourcen stoppt; eine zweite Regel um 07:00 Uhr startet sie wieder.

import boto3
ec2 = boto3.client('ec2'); rds = boto3.client('rds')

def handler(event, _):
    action = event['action']  # 'start' or 'stop'
    ids = [i['InstanceId'] for r in ec2.describe_instances(
        Filters=[{'Name':'tag:AutoStop','Values':['true']}]
    )['Reservations'] for i in r['Instances']]
    getattr(ec2, f'{action}_instances')(InstanceIds=ids)
    for db in rds.describe_db_instances()['DBInstances']:
        if any(t['Key']=='AutoStop' and t['Value']=='true' for t in db['TagList']):
            getattr(rds, f'{action}_db_instance')(DBInstanceIdentifier=db['DBInstanceIdentifier'])

Dies ist serverless, hat keine Flotte, die gepatcht werden muss, und skaliert über Tags. Die AWS Instance Scheduler-Lösung funktioniert äquivalent. Eine Feinheit: Eine gestoppte RDS-Instanz startet nach sieben Tagen automatisch neu, daher muss der Stopp-Zeitplan wiederholt werden, um sie erneut zu stoppen. In Kombination mit ASGs, deren geplante Aktionen die Kapazität an Wochenenden auf null setzen, nähern sich die Kosten für Leerlaufzeiten dem Nullpunkt.

Netzwerk-Fallstricke bei skalierter Rechenleistung

Platzierung von NAT Gateways. Ein NAT Gateway befindet sich in einer einzigen AZ. Eine Flotte, die sich über drei AZs erstreckt und ihren gesamten ausgehenden Verkehr (Egress) durch ein einziges NAT in us-east-1a leitet, zahlt für jedes Paket aus us-east-1b/us-east-1c Gebühren für den Inter-AZ-Transfer und verliert den Egress-Zugang vollständig, wenn die Leistung von us-east-1a nachlässt. Das korrekte Muster ist ein NAT Gateway pro AZ, wobei die Routing-Tabelle jedes privaten Subnetzes auf das NAT in der eigenen AZ verweist. Dies lokalisiert den Datenverkehr und beseitigt den Single-AZ-Ausfallmodus.

NAT-Instanzen. Eine einzelne EC2-basierte NAT-Instanz wird mit wachsender Flotte zu einem Engpass bei Bandbreite und Paketen pro Sekunde (PPS) und stellt einen SPOF (Single Point of Failure) dar. Verwaltete NAT Gateways skalieren auf bis zu 100 Gbit/s pro Gateway. Für den Datenverkehr zu AWS-Services umgehen VPC-Endpunkte (Gateway für S3/DynamoDB, Interface für andere) das NAT vollständig, was Kosten senkt und das Risiko einer Sättigung bei Skalierungsereignissen eliminiert.

Wiederkehrende Design-Fallen

• Single-AZ ASGs können einen AZ-Ausfall nicht überstehen – binden Sie immer Subnetze aus mindestens zwei AZs an (drei für Quorum-Systeme) und halten Sie MinSize ≥ 2.
• Annahme, dass jede Workload horizontal skaliert. Zustandsbehaftete, Single-Writer- oder nicht clusterfähige lizenzierte Anwendungen verschlechtern sich unter einer ASG. Verwenden Sie zuerst Auto-Recovery oder führen Sie ein Refactoring durch.
• Reaktive Skalierung für vorhersehbare Spitzen verursacht das Symptom „träge für die ersten 2–3 Stunden“. Verwenden Sie geplante oder vorausschauende Skalierung zum Vorwärmen (Pre-Warming).
• Skalierung nach CPU, wenn die CPU nicht der Engpass ist. Veröffentlichen Sie eine Metrik, die den tatsächlichen Engpass widerspiegelt – Warteschlangentiefe, Antwortzeit, Anzahl der Verbindungen.
• Simple Scaling und Launch Configurations sind veraltet – bevorzugen Sie Target Tracking und Launch Templates.
• Reine TCP-Health-Checks bei HTTP-Anwendungen belassen fehlerhafte Instanzen in der Rotation. Verwenden Sie HTTP-Prüfungen (über ALB oder NLB-Prüfungen im HTTP-Modus).
• Spot für zustandsbehaftete oder unterbrechungskritische Workloads – Spot erfordert checkpoint-fähige, austauschbare Worker.
• Reserved Instances oder Savings Plans für wirklich variable Workloads – die ungenutzte Verpflichtung ist reine Verschwendung; senken Sie stattdessen die Kosten durch Right-Sizing und Spot.
• Route 53 auf einzelne EC2-IPs verweisen lassen – leiten Sie den Verkehr an den ALB-Alias weiter, damit das DNS die Flottenänderungen (Churn) widerspiegelt.
• Instance Store als langlebig behandeln – Daten gehen beim Stoppen, Beenden oder bei einem Host-Ausfall verloren.
• Die Latenz durch Lazy Loading nach einer Snapshot-Wiederherstellung oder einem AMI-Start ignorieren – aktivieren Sie Fast Snapshot Restore in den Ziel-AZs.

Alle Domänen · Container →

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

Amazon durchsuchen →