Amazon SAP-C02: Datenbanken & Analytics — 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.

Transaktionale Datenbanken, Skalierungsmuster und Caching

Die Wahl zwischen Amazon RDS (MySQL/PostgreSQL/Oracle/SQL Server), Amazon Aurora und Amazon DynamoDB beginnt mit dem Workload-Profil: Ein striktes relationales Schema und komplexe Transaktionen sprechen für RDS/Aurora; massive Skalierung, Lookups im einstelligen Millisekundenbereich und ein flexibles Schema sprechen für DynamoDB. Aurora bietet hohen Durchsatz mit verteiltem Speicher, Autoscaling für Replikate, schnelles Failover, Global Database für regionsübergreifende Lesezugriffe und Disaster Recovery mit geringerer Latenz. RDS Multi-AZ bietet synchrone Replikation für Verfügbarkeit, aber keine Leseskalierung; Read Replicas (RDS/Aurora) bewältigen leseintensive Workloads. Für Key-Value-Caching und Latenz im Mikrosekundenbereich reduziert ElastiCache (Redis oder Memcached) die Datenbanklast; MemoryDB for Redis fügt Dauerhaftigkeit und Redis-kompatible Persistenz hinzu, wo Daten hochverfügbar und wiederherstellbar sein müssen. Häufige Fallstricke sind die Unterschätzung von Verbindungslimits (maximale Verbindungen bei MySQL), die Nichtverwendung von Connection Pooling (Lambda/Container erzeugen viele Verbindungen), Hot Partitions in DynamoDB durch schlechtes Schlüsseldesign und die Vernachlässigung des Cache-Eviction/-Designs, was zu veralteten Daten führt. Entscheidungsabwägungen drehen sich oft um Kosten gegenüber Leistung und Ausfallsicherheit: provisionierte Aurora-Instanzen oder große RDS-Instanzen kosten mehr, reduzieren aber die Latenz und vereinfachen Transaktionen, während DynamoDB mit On-Demand oder Autoscaling den Betriebsaufwand senken kann, aber eine sorgfältige Schema- und Kapazitätsplanung erfordert. Verschlüsselung, automatisierte Backups, PITR und regionsübergreifende Replikationsmuster sollten gemäß RPO/RTO ausgewählt werden.

Data Lake, ETL und analytische Query-Engines

S3 ist der kanonische, langlebige Data Lake; das Design sollte sich um Partitionierung, spaltenorientierte Formate (Parquet/ORC), Komprimierung und Kompaktierung drehen, um kosteneffiziente Abfragen zu ermöglichen. AWS Glue und der AWS Glue Data Catalog bieten serverloses ETL, Schema-Erkennung und Katalogisierung; Lake Formation fügt zentralisierte Zugriffskontrolle, feingranulare Berechtigungen und kontoübergreifende Freigaben für verwaltete (governed) Lakes hinzu. Für interaktive Analysen fragt Amazon Athena S3-Daten direkt ab (serverlos, Bezahlung pro Abfrage), während Amazon Redshift (RA3/Iceberg-Unterstützung) performantes, verwaltetes MPP-Warehousing für komplexe BI-Anwendungen und Joins bereitstellt. Verwenden Sie Redshift Spectrum, um S3-Daten von Redshift aus abzufragen, ohne alles ingestieren zu müssen. Kinesis Data Firehose ist ein verwalteter Ingest-Pfad, um Streaming-Events in S3 oder Redshift zu speichern. Häufige Architektur-Fallstricke sind zu viele kleine Dateien, die einen hohen Overhead bei Athena/Redshift verursachen, schlecht gewählte Partitionsschlüssel, die zu Daten-Skews führen, und das Versäumnis, Daten zu kompaktieren oder in spaltenorientierte Formate zu konvertieren. Die Abwägungen liegen zwischen Latenz und Kosten: Athena hat geringe Betriebskosten für Ad-hoc-Abfragen; Redshift bietet eine höhere dauerhafte Leistung zu höheren provisionierten Kosten. Data Governance und Lineage über Glue/Lake Formation sind für Compliance und die Zuständigkeit mehrerer Teams unerlässlich.

Streaming, Echtzeitverarbeitung und Suche

Für Echtzeit-Ingestion und -Verarbeitung werden Kinesis Data Streams (Shard-basierter Durchsatz und Reihenfolgen-Garantien), Kinesis Data Firehose (verwaltete Lieferung an Sinks), Kinesis Data Analytics (Verarbeitung mit SQL/Apache Flink) oder Amazon MSK für Kafka-kompatible Anforderungen verwendet. Wählen Sie Kinesis für eine unkomplizierte, AWS-native serverlose Integration; wählen Sie MSK, wenn Clients auf Werkzeuge des Kafka-Ökosystems angewiesen sind. At-least-once-Zustellungssemantik, Shard-Limits, Consumer-Parallelität und die Bereitstellung einer ausreichenden Anzahl von Shards sind häufige betriebliche Fallstricke. Für nachgelagerte schnelle Suche und Observability bietet der Amazon OpenSearch Service Indizierung, Suche in Nahezu-Echtzeit und integrierte Kibana-Dashboards; Index-Lifecycle-Management und Warm/Cold Tiers reduzieren die Kosten für ältere Daten. Verwenden Sie Kinesis + Lambda oder Kinesis + KDA, um Ereignisse anzureichern oder zu transformieren, bevor sie in OpenSearch oder S3 persistiert werden. Architektieren Sie Idempotenz und Deduplizierung in die Consumer, da Wiederholungsversuche oder Replays Duplikate verursachen. Entscheidungskriterien wägen Durchsatz und Latenz ab: Kinesis mit vielen Shards unterstützt einen hohen Durchsatz, erhöht aber Kosten und Verwaltungsaufwand; Firehose entlastet den Consumer, bietet aber weniger flexible Transformationsmöglichkeiten.

Migration, Replikation, Governance und betriebliche Resilienz

Database Migration Service (AWS DMS) und das Schema Conversion Tool (SCT) sind die primären Migrationswerkzeuge für homogene und heterogene Umzüge und ermöglichen kontinuierliches Change Data Capture (CDC). Migrationsmuster umfassen Rehost (Lift-and-Shift), Replatform (z. B. Umzug zu Aurora) und Refactor zu DynamoDB oder Serverless, wo es sinnvoll ist. Verwenden Sie DMS mit Validierung vor und nach der Migration, parallelem Kopieren von Tabellen und sorgfältiger Handhabung von LOB/LOBLOB. Konto- und regionsübergreifende Replikation erfordert Zugriff auf KMS-Schlüssel, VPC-Peering oder Transit Gateway sowie eine Planung der Netzwerkbandbreite; Global Databases und Read Replicas sind Alternativen, wenn Lesevorgänge mit geringer Latenz über Regionen hinweg erforderlich sind. Governance und Sicherheit müssen Lake Formation für die gemeinsame Datennutzung, das IAM-Prinzip der geringsten Rechte (Least Privilege), Ressourcenrichtlinien für S3- und RDS-Snapshots sowie VPC-Endpunkte/PrivateLink zur Vermeidung von öffentlichem Egress umfassen. Betriebliche Fallstricke sind unzureichendes Monitoring (übersehener Replica Lag), das Nicht-Testen von Failover/Runbooks und versteckte Egress-Kosten bei Massenübertragungen. Backup, PITR-Strategie und automatisierte Wiederherstellung spielen bei den RTO/RPO-Abwägungen eine Rolle; kombinieren Sie Replikation für die Verfügbarkeit mit regelmäßigen Backups für eine längerfristige Aufbewahrung und Compliance.

Praktisches Problem: Anwendungsfallszenario

Szenario: Acme Retail betreibt eine E-Commerce-Plattform in einer AWS Organization mit mehreren Konten, mit Produktions-Workloads in us-east-1 und europe-west-1. Sie speichern Clickstreams und Transaktionsereignisse in S3 und betreiben eine On-Premises-OLTP-DB, die mit minimaler Ausfallzeit zu AWS migriert werden muss.

Herausforderung: Migrieren Sie die OLTP-Datenbank zu einem hochverfügbaren, regionsübergreifend leseskalierbaren Ziel und bauen Sie gleichzeitig einen verwalteten Analyse-See (Analytic Lake) auf S3 mit Echtzeit-Ingestion und Abfragefunktionen auf.

Empfohlener Ansatz:

Verwenden Sie AWS DMS mit SCT für die Schemakonvertierung und richten Sie kontinuierliches CDC von der On-Premises-DB zu Amazon Aurora (Global Database) in us-east-1 mit einer Aurora Read Replica in europe-west-1 ein.
Nehmen Sie Clickstream- und Transaktionsereignisse über Amazon Kinesis Data Streams und Firehose auf; puffern Sie die Rohereignisse und liefern Sie sie im Parquet-Format, partitioniert nach Datum und Region, an S3.
Katalogisieren Sie S3-Daten mit AWS Glue, setzen Sie die Zugriffskontrolle über Lake Formation durch und führen Sie ETL mit Glue-Jobs (oder Glue Studio) durch, um kuratierte Datensätze zu erstellen; stellen Sie diese Analysten über Amazon Athena und Redshift Spectrum zur Verfügung.
Fügen Sie ElastiCache (Redis) für das Caching von häufig gelesenen Produkt- und Sitzungsdaten hinzu; instrumentieren Sie das End-to-End-Monitoring mit CloudWatch, aktivieren Sie Enhanced Monitoring für Aurora und validieren Sie das Failover mit Runbooks.

Begründung: Dieser Ansatz minimiert die Ausfallzeit durch die Verwendung von DMS CDC, bietet globale Lesevorgänge mit geringer Latenz über Aurora Global Database, etabliert einen verwalteten S3 Data Lake für analytische Agilität und reduziert die Last auf OLTP-Systemen durch Caching und entkoppelte Streaming-Ingestion im Einklang mit den Best Practices für unternehmensweite Resilienz und Leistung.

← Speicher · Alle Domänen · Migration →

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