Amazon SAP-C02: Compute & Auto Scaling — Lernleitfaden

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

Teil des AWS Solutions Architect Professional SAP-C02 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

EC2-Instanzdesign, Speicher und Netzwerk

Das Design von EC2-Instanzen beginnt mit der Abstimmung der Workload-Eigenschaften auf die Instanzfamilien, wobei vCPU, Arbeitsspeicher, Netzwerk und lokaler Speicher ausbalanciert werden. Wählen Sie je nach Profiling rechenoptimierte (C), speicheroptimierte (R/X), speicheroptimierte (I/D) oder GPU-Typen (P/G). Nutzen Sie Nitro-basierte Instanzen und ENA/SR-IOV für hohen Netzwerkdurchsatz und geringe Latenz. Für latenzempfindliche oder temporäre Daten mit hohen IOPS sollten Sie Instance Store (ephemeral) auf I3/I4- oder Nitro-SSDs in Betracht ziehen; für persistenten Blockspeicher verwenden Sie EBS mit Provisioned IOPS (io2/io2 Block Express) und aktivieren Sie die EBS-Verschlüsselung mit KMS für die Schlüsselverwaltung. Wenn sich Instanzen in VPCs hinter Application Load Balancern befinden, stellen Sie sicher, dass internetseitige ALBs in öffentlichen Subnetzen und die Ziele in privaten Subnetzen platziert werden; eine falsche Platzierung von ALBs oder eine Fehlkonfiguration von Sicherheitsgruppen ist eine häufige Fehlerquelle. Verwenden Sie Placement Groups (Cluster für HPC mit geringer Latenz, Partition für große verteilte zustandsbehaftete Systeme, Spread für Fehlerisolierung), um die Platzierung zu beeinflussen, aber akzeptieren Sie die Kompromisse: Cluster bietet die beste Leistung, reduziert aber die Fehlertoleranz auf AZ-Ebene. Für die Verschlüsselung von Daten während der Übertragung (in transit) verwenden Sie TLS-Terminierung am ALB oder End-to-End-TLS mit NLB-Passthrough. Die Entscheidungskriterien wägen Kosten gegen Leistung ab: dichter gepackte Instanztypen senken die Kosten, können aber den „Blast Radius“ und die Lizenzkosten erhöhen; bevorzugen Sie ein Right-Sizing, das auf CloudWatch, AWS Compute Optimizer und Lasttests basiert, anstatt auf Faustregeln.

Auto Scaling Groups, Richtlinien und Lifecycle-Management

Auto Scaling Groups (ASGs) sollten auf Elastizität, Resilienz und Kosteneffizienz ausgelegt sein, indem eine Kombination aus Launch Templates, Mixed-Instances-Policies, Lifecycle Hooks und Skalierungsrichtlinien verwendet wird. Verwenden Sie Launch Templates zur Versionierung von AMI, Überschreibungen des Instanztyps, EBS-Konfigurationen und User-Data; Mixed-Instances mit kapazitätsoptimierter Spot-Zuweisung oder einer diversifizierten Strategie reduzieren das Unterbrechungsrisiko und senken die Kosten. Für das Skalierungsverhalten bevorzugen Sie Target-Tracking-Policies für vorhersagbare Metriken (CPU, Anzahl der Anfragen pro Ziel) und Step-Scaling, wenn schwellenwertgesteuerte, mehrstufige Aktionen erforderlich sind; Predictive Scaling kann Kapazitäten für bekannte tageszeitliche Muster vorab bereitstellen. Implementieren Sie Lifecycle Hooks, um benutzerdefinierte Initialisierungs- oder Draining-Aufgaben vor der Terminierung auszuführen; kombinieren Sie Warm Pools, um die Time-to-Serve zu verkürzen, und Scheduled Scaling für Basislasten während der Geschäftszeiten. Health Checks sollten ELB- und EC2-Health-Checks integrieren, um einen vorzeitigen Austausch zu vermeiden. Achten Sie auf Fehlerquellen wie Scale-in-Churn durch zu aggressive Cooldowns, falsche Gewichtung von Instanzen in gemischten ASGs und die Nichtberücksichtigung der Aufwärmphase von Anwendungen. Vermeiden Sie bei zustandsbehafteten Diensten ein schnelles Scale-in, das In-Memory-Caches verliert; im Spannungsfeld Kosten vs. Resilienz bietet Spot-gestützte Kapazität mit On-Demand-Fallbacks Einsparungen, erfordert aber die Behandlung von Unterbrechungen, während 100 % On-Demand die Vorhersagbarkeit bei höheren Kosten maximiert.

Container und Orchestrierung: Entscheidungen zwischen ECS, EKS und Fargate

Die Wahl zwischen Amazon ECS, EKS und Fargate hängt vom Betriebsmodell, dem Kontrollbedarf und den Workload-Mustern ab. Fargate eliminiert die Node-Verwaltung und ist ideal für Teams, die operative Einfachheit priorisieren, hat aber höhere Preise pro vCPU und Begrenzungen beim ephemeren Speicher; es unterstützt Fargate Spot für Kosteneinsparungen. ECS bietet eine enge AWS-Integration und Einfachheit für Kunden, die eine Container-Orchestrierung ohne die Komplexität von Kubernetes wünschen. EKS ist geeignet, wenn das Kubernetes-Ökosystem, Portabilität oder erweitertes Scheduling erforderlich sind; ziehen Sie Managed Node Groups oder Self-Managed + Karpenter für dynamisches Right-Sizing in Betracht. Netzwerkgrenzen (ENI/Pod-Dichte) und das CNI-Verhalten beeinflussen die Pod-Dichte und die Node-Größe; bei EKS reduzieren IAM Roles for Service Accounts und der EBS CSI für persistente Volumes die unkontrollierte Verbreitung von Anmeldeinformationen (Credential Sprawl) und ermöglichen Speicher pro Pod. Für gemeinsam genutzte Dateisysteme verwenden Sie je nach Durchsatz- und Latenzanforderungen EFS (NFS) oder FSx (Lustre); vermeiden Sie NFS-gestützte Container für hohe Metadaten-Operationen – bevorzugen Sie EFS mit auf den Workload abgestimmten Durchsatzmodi. Implementieren Sie den Cluster Autoscaler oder Karpenter für die Node-Skalierung und Service Auto Scaling mit ALB/ECS-Servicemetriken. Häufige Fehlerquellen sind das Ignorieren von Pod Disruption Budgets, das Unterschätzen der Kubernetes Control Plane Quotas und die Überprovisionierung von Nodes anstelle der Verwendung von Bin-Packing-Strategien – die Auswahl sollte durch Abwägungen zwischen Kontrolle, Kosten und Betriebsaufwand bestimmt werden.

Serverless-Rechenmuster, Lambda-Einschränkungen und ereignisgesteuertes Design

Serverless reduziert den Betriebsaufwand, erfordert aber Architekturmuster, die Nebenläufigkeit, Zustand und die Grenzen nachgelagerter Systeme berücksichtigen. Lambda eignet sich hervorragend für kurzlebige, ereignisgesteuerte Aufgaben, API-Backends über API Gateway oder ALB und die asynchrone Verarbeitung mit SQS oder SNS. Verwenden Sie Step Functions zur Orchestrierung langlebiger Workflows und DynamoDB oder RDS Proxy für den Datenbankzugriff, um Verbindungsstürme (Connection Storms) zu vermeiden. Beachten Sie den durch die Erstellung von ENIs verursachten Cold-Start-Overhead von Lambda in einer VPC; mildern Sie diesen durch Provisioned Concurrency für latenzempfindliche Endpunkte oder verwenden Sie VPC-Endpunkte und RDS Proxy, um die Anzahl der Verbindungen zu begrenzen. Implementieren Sie Fan-Out/Fan-In über SNS + SQS oder Kinesis/MKS für die geordnete Stream-Verarbeitung; verwenden Sie SQS Dead-Letter-Queues und idempotente Handler, um Wiederholungsversuche und Duplikate zu verwalten. Nebenläufigkeitsgrenzen, Reserved Concurrency und Throttling sollten geplant werden, um kaskadierende Ausfälle zu vermeiden; entwerfen Sie für Gegendruck (Backpressure) unter Verwendung von Drosselungen (Throttles), Wiederholungsversuchen mit Jitter und Circuit Breakers (API Gateway oder benutzerdefiniert). Die Kompromisse zwischen Kosten und Leistung sind klar: Lambda ist kosteneffektiv für spitzenlastige, kurzzeitige Aufgaben, während Fargate oder EC2 besser für dauerhaft hohe CPU-Auslastung oder langlebige Aufgaben geeignet sind. Häufige Fehler sind das Verlassen auf synchrone Wiederholungsversuche, die nachgelagerte Systeme überlasten, das Speichern von Zustand im lokalen /tmp in der Erwartung von Persistenz und das Nicht-Vorsehen von Ressourcen für Kaltstarts bei latenzkritischen Abläufen.

Praktisches Problem: Migration des Kontaktcenters von NovaTel Enterprise

Szenario: NovaTel Enterprise betreibt ein hybrides Kontaktcenter mit lokaler Anrufweiterleitung und einer Direct Connect zu AWS. Sie betreiben Session Broker auf EC2 in zwei Availability Zones und möchten auf ein von AWS verwaltetes Kontaktcenter mit hoher Verfügbarkeit und vorhersagbarer Latenz zwischen der lokalen PBX und den Cloud-Diensten migrieren.

Herausforderung: Sie benötigen eine Konnektivität mit geringer Latenz für den SIP-Verkehr, eine skalierbare Rechenschicht für die Sprachverarbeitung, die Spot-Unterbrechungen toleriert, und eine DR-Strategie über Regionen hinweg, ohne die betriebliche Komplexität zu erhöhen.

Empfohlener Ansatz:

1. Bereitstellung von Amazon Connect für die Kontaktcenter-Funktionalität und Nutzung eines Site-to-Site VPN oder Direct Connect mit einem AWS Transit Gateway für SIP-Trunking mit geringer Latenz, das an einem NLB mit TLS-Passthrough vor den Session Brokern terminiert wird.
2. Betreiben der Sitzungsverarbeitungskomponenten als gemischte Auto Scaling Group mit Launch Templates, die kapazitätsoptimierte Spot-Instanzen plus On-Demand als Fallback verwenden, und Nutzung von Placement Groups (Spread) zur Fehlerisolierung kritischer Broker.
3. Für zustandsbehaftete Anrufmedien, die einen ephemeren Speicher mit geringer Latenz erfordern, verwenden Sie Instance-Store-gestützte Instanzen (Nitro) für die Medienpufferung und replizieren Sie Sitzungsmetadaten nach DynamoDB oder ElastiCache mit Multi-AZ-Replikation; setzen Sie RDS (Multi-AZ) oder Aurora Global DB für persistente Daten mit regionsübergreifenden Lesereplikas für DR ein.
4. Implementieren Sie Lifecycle Hooks und Warm Pools, um den Kaltstart von Brokern zu minimieren, Route 53 Weighted Failover für regionsübergreifendes DR und CloudWatch + SNS/SQS für Alarmierung und automatisierte Failover-Runbooks.

Begründung: Die Verwendung von verwalteten Kontaktcenter-Diensten reduziert den Betriebsaufwand, während gemischte ASGs mit Spot die Kosten optimieren; die Isolierung ephemerer Medien auf Instance Stores erhält die Leistung, und die dauerhafte Zustandsreplikation nach DynamoDB/ElastiCache plus Multi-AZ RDS/Aurora bietet Ausfallsicherheit und schnelles Failover im Einklang mit den Best Practices professioneller Architektur.

← Sicherheit · Alle Domänen · Speicher →

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

Amazon durchsuchen →