Amazon CLF-C02: Kern-Datenbankservices — Lernleitfaden

By Laurynas Brazys · 29 July 2026 · #amazon #clf-c02 #certification #exam-prep #study-guide

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

Verwaltete relationale Datenbanken: Amazon RDS und Amazon Aurora

Amazon RDS bietet vollständig verwaltete relationale Engines (MySQL, PostgreSQL, MariaDB, SQL Server, Oracle) mit automatisierten Backups, Multi-AZ für Hochverfügbarkeit, Read Replicas zur Skalierung und Snapshot-basierter Wiederherstellung. Aurora ist eine speziell entwickelte, MySQL- und PostgreSQL-kompatible Engine, die die Rechenleistung von einer verteilten, fehlertoleranten Speicherschicht trennt, um einen höheren Durchsatz, eine schnelle Wiederherstellung nach Abstürzen und Funktionen wie Backtrack und Global Database für die regionsübergreifende Replikation zu bieten. Die Preismodelle umfassen On-Demand-Instances für flexible Kapazität, Reserved Instances oder Savings Plans für planbare Einsparungen sowie Serverless- oder Autoscaling-Kapazitätsmodelle für Aurora Serverless, um die Kosten an variable Workloads anzupassen. Wichtige Architekturentscheidungen hängen vom Lese-/Schreibprofil, den Latenzanforderungen und der Betriebstoleranz ab: Wählen Sie RDS, wenn Kompatibilitäts- und Lizenzanforderungen im Vordergrund stehen, und Aurora, wenn Sie eine höhere Leistung, Autoscaling des Speichers oder globale Lesevorgänge benötigen. Häufige Fehler in der Praxis sind die Unterprovisionierung von IOPS für schreibintensive Workloads, das Vergessen der Aktivierung von Multi-AZ für die Produktion, die Beibehaltung der Standard-Master-Anmeldeinformationen und das Versäumnis, die Point-in-Time-Wiederherstellung zu testen. Für die Compliance aktivieren Sie die Verschlüsselung im Ruhezustand (Encryption at Rest) mit AWS KMS, erzwingen Sie TLS für die Verschlüsselung während der Übertragung (In-Transit Encryption) und stellen Sie sicher, dass automatisierte Backups und Snapshots die Aufbewahrungs- und regionsübergreifenden DR-Ziele erfüllen.

NoSQL-, Caching- und Graph-Datenbanken: DynamoDB, ElastiCache, Amazon Neptune

Für Key-Value- und Dokumenten-Workloads in großem Maßstab bietet Amazon DynamoDB Latenzzeiten im einstelligen Millisekundenbereich, automatische Partitionierung und zwei Kapazitätsmodi: provisioniert (mit Autoscaling) und On-Demand für unvorhersehbaren Datenverkehr. Funktionen wie DynamoDB Streams, globale Tabellen und Point-in-Time Recovery (PITR) unterstützen Replikation, Change Data Capture und Backups. Ein häufiger Fehler ist ein schlechtes Design des Partitionsschlüssels, das zu Hot Partitions und Throttling führt; modellieren Sie zuerst die Datenzugriffsmuster. Für In-Memory-Workloads mit geringer Latenz verwenden Sie ElastiCache: Redis bietet Persistenz, Clustering und Pub/Sub, während Memcached ein einfaches, multithreaded Caching ist. Verwenden Sie DAX für leselastige DynamoDB-Workloads, die Caching im Mikrosekundenbereich erfordern. Für beziehungsorientierte Graph-Abfragen ist Amazon Neptune eine vollständig verwaltete Graph-Datenbank, die Gremlin und SPARQL unterstützt. Preisentscheidungen: DynamoDB On-Demand ist einfach, aber bei konstant hohem Datenverkehr teurer; provisioniert mit Autoscaling und Reserved Capacity kann deutlich günstiger sein. Die Cache-Größe, Eviction Policies und Persistenzoptionen in ElastiCache beeinflussen Kosten und Wiederherstellung. Bewerten Sie Haltbarkeit (Durability), Konsistenzmodelle und die betriebliche Komplexität bei der Wahl zwischen verwalteten NoSQL-, In-Memory-Caches und Graph-Datenbanken.

DynamoDB vs. RDS/Aurora: DynamoDB für massive Skalierung, schemaflexibles Single-Table-Design; RDS/Aurora für komplexe SQL-Abfragen, Transaktionen und relationale Integrität.
ElastiCache (Redis) vs. DAX: Redis für allgemeine In-Memory-Workloads und Persistenz; DAX ist ein DynamoDB-spezifischer Lese-Cache mit clientseitiger Integration.
Neptune: Verwenden, wenn Traversierungen und Graph-Analysen den Kern der Anwendung bilden.

Analyse- und Data-Lake-Muster: Amazon Redshift, Athena und S3-Speicheroptionen

Amazon Redshift ist ein spaltenbasiertes Data Warehouse im Petabyte-Maßstab, das für komplexe analytische Abfragen und hohe Gleichzeitigkeit (Concurrency) optimiert ist. Modernes Redshift (RA3-Knoten) entkoppelt Rechenleistung und verwalteten Speicher, sodass Sie die Rechenleistung unabhängig skalieren und Kosten senken können, indem Sie S3 als verwalteten Speicher nutzen; Redshift Spectrum fragt Daten direkt in S3 für die Data-Lake-Integration ab. Für Ad-hoc-SQL-Abfragen über Dateien bietet Amazon Athena serverlose Pay-per-Query-Analysen (abgerechnet pro gescanntem TB) und ist ideal für CSV/Parquet/JSON auf S3; die Optimierung von Formaten und Komprimierung reduziert die Kosten drastisch. S3 bietet mehrere Speicherklassen: Bei unbekannten Zugriffsmustern verschiebt S3 Intelligent-Tiering Objekte automatisch zwischen Zugriffsebenen, um die Kosten ohne Abrufgebühren zu minimieren; für Langzeitarchive sollten S3 Glacier oder Glacier Deep Archive in Betracht gezogen werden, bei denen Abruflatenzen und -gebühren anfallen. Kostenabwägungen umfassen Speicher vs. Rechenleistung: Komprimieren, partitionieren und verwenden Sie spaltenbasierte Formate, um das Scan-Volumen zu reduzieren; ziehen Sie Redshift Concurrency Scaling und Workload Management für eine vorhersagbare Leistung in Betracht. Für Machine-Learning-Workloads, die mit Analysen verknüpft sind, kann intensives Training GPU-EC2-Familien (P- oder G-Serien) erfordern, aber die meisten analytischen DB-Workloads basieren eher auf optimierter CPU- und spaltenbasierter Ausführung als auf GPUs.

Migration, Backup, Sicherheit und bewährte Betriebspraktiken

Die Migration und der Schutz von Datenbanken erfordern die richtige Mischung aus Services und Richtlinien. AWS Database Migration Service (DMS) bewältigt homogene und heterogene Migrationen mit minimaler Ausfallzeit; das Schema Conversion Tool hilft bei der Konvertierung von Datenbankschemata beim Wechsel zwischen Engine-Typen. Für Backups und richtlinienbasierten Schutz verwenden Sie native Engine-Funktionen (automatisierte RDS-Backups und Snapshots, DynamoDB PITR) zusammen mit AWS Backup für zentralisierte, serviceübergreifende Backup-Richtlinien und konto- oder regionsübergreifende Kopien. Die Sicherheit muss IAM-Richtlinien mit den geringsten Rechten (Least Privilege), Verschlüsselung während der Übertragung (TLS) und im Ruhezustand (KMS) sowie Netzwerksteuerungen umfassen: Sicherheitsgruppen sind zustandsbehaftete (stateful) Firewalls auf Host-Ebene, die Sie an Instanzen anhängen, während Netzwerk-ACLs zustandslose (stateless) Filter auf Subnetz-Ebene sind – beide ergänzen sich, unterscheiden sich aber im Verhalten. Im Rahmen der geteilten Verantwortung (Shared Responsibility) verwaltet AWS die Cloud-Infrastruktur, während Kunden die Daten, IAM, Patches auf Betriebssystemebene bei selbstverwalteten Instanzen und die Schlüsselrotation für Secrets und Zugangsdaten verwalten. Die Betriebsautomatisierung mit CloudFormation, dem AWS CLI oder SDKs ermöglicht eine wiederholbare Bereitstellung von Umgebungen; häufige Fallstricke sind die Verwendung des Root-Kontos, das Belassen weitreichender IAM-Richtlinien, die Vernachlässigung der Schlüsselrotation und das Versäumnis, die Überwachung mit CloudWatch, VPC Flow Logs oder AWS Config durchzuführen. Für große Datenübertragungen sollten Sie AWS Snowball oder DataSync in Betracht ziehen, um Terabytes/Petabytes sicher mit Verschlüsselung während der Übertragung und Integritätsprüfung zu verschieben.

Praktisches Problem: Anwendungsfallszenario

Szenario: AcmeRetail betreibt eine saisonale E-Commerce-Plattform mit einer On-Premises-MySQL-OLTP-Datenbank und großen historischen CSV-Verkaufsdatendateien auf einem On-Prem-NFS-Share. Ihr AWS-Konto verfügt über eine VPC mit privaten Subnetzen und einem Transit Gateway zu ihrem Rechenzentrum. Sie müssen die transaktionale Datenbank mit minimaler Ausfallzeit migrieren und die historischen Daten für BI-Zwecke abfragbar machen.

Herausforderung: Verschieben der Produktionsdatenbank mit nahezu null Ausfallzeit, Ermöglichen skalierbarer Analysen der historischen CSVs und Sicherstellen von Backups, Verschlüsselung und Zugriff nach dem Prinzip der geringsten Rechte (Least Privilege).

Empfohlener Ansatz:

Verwenden Sie AWS Database Migration Service (DMS) mit dem Schema Conversion Tool, falls erforderlich, um MySQL zu Amazon Aurora (MySQL-kompatibel) zu migrieren. Konfigurieren Sie dabei die kontinuierliche Replikation, um die Ausfallzeit zu minimieren.
Übertragen Sie historische CSVs mit AWS DataSync oder Snowball (für sehr große Volumen) nach Amazon S3, speichern Sie sie in S3 mit Intelligent-Tiering und konvertieren Sie sie mit AWS Glue ETL in Parquet, um die Abfrageeffizienz zu steigern.
Stellen Sie Amazon Redshift (RA3) bereit oder verwenden Sie Amazon Athena über den S3-Daten (Parquet) für BI-Abfragen; nutzen Sie Redshift Spectrum, wenn Sie Warehouse- und Lake-Abfragen kombinieren.
Implementieren Sie automatisierte Backups (automatisierte RDS-Backups und Snapshots), aktivieren Sie die Verschlüsselung mit KMS-Schlüsseln, beschränken Sie den Zugriff mit IAM-Rollen und Sicherheitsgruppen nach dem Prinzip der geringsten Rechte und zentralisieren Sie Backup-Richtlinien mit AWS Backup.

Begründung: Die kontinuierliche Replikation mit DMS ermöglicht eine Migration von Transaktionssystemen mit nahezu null Ausfallzeit; S3 + Parquet + Athena/Redshift minimiert die Analysekosten und die Größe der Scans; KMS, Backups und IAM nach dem Prinzip der geringsten Rechte stehen im Einklang mit der geteilten Verantwortung (Shared Responsibility) und bewährten Betriebspraktiken für Verfügbarkeit, Sicherheit und Kostenkontrolle.

← Kern-Speicherservices · Alle Domänen · Netzwerk und Content Delivery →

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