Amazon DVA-C02: Datenbanken und Caching (RDS, Aurora, ElastiCache, Timestream, Proxy) — Lernleitfaden

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

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

RDS und Aurora: Design, Skalierung und Verschlüsselung

Das Design relationaler Datenbanken auf RDS oder Aurora beginnt mit den Abwägungen je nach Workload zwischen einem provisionierten RDS mit einem einzelnen Knoten und dem verteilten Speicher von Aurora. Wählen Sie Aurora, wenn Sie eine hohe Leseskalierbarkeit und ein schnelles Failover benötigen: Aurora-Replicas teilen sich das Cluster-Volume, sodass die Heraufstufung (Promotion) schnell erfolgt, während RDS MySQL/Postgres Read Replicas eine asynchrone, auf Binlogs basierende Replikation verwenden und hinterherhinken können. Um Lesevorgänge zu skalieren, fügen Sie Read Replicas hinzu und leiten Sie den Lese-Traffic der Anwendung auf diese um. Verwenden Sie Reader-Endpunkte in Aurora, um die Last automatisch auf die Replicas zu verteilen. Für Schreibvorgänge sind die vertikale Skalierung (Instanzklasse) und ein sorgfältiges Schema-/Indexdesign entscheidend. Aktivieren Sie die Verschlüsselung im Ruhezustand (Encryption at Rest) immer bei der Erstellung mit einem KMS CMK – eine spätere Aktivierung erfordert einen Snapshot/Restore in eine neue verschlüsselte Instanz; das ist eine häufige Falle. Für den Schutz bei der Übertragung (In-Transit Protection) erzwingen Sie TLS/SSL-Verbindungen (RDS stellt CA-Bundles bereit). Bevorzugen Sie für Anmeldeinformationen AWS Secrets Manager mit automatischer Rotation unter Verwendung der integrierten Lambda-Vorlage für die RDS-Rotation; rufen Sie Secrets programmgesteuert mit SecretsManager.getSecretValue() in SDKs ab. Erwägen Sie die IAM-Datenbankauthentifizierung, um statische Passwörter zu vermeiden: Generieren Sie ein Token über RDS.Signer (SDK) oder rds.generate-db-auth-token und verbinden Sie sich dann mit einem kurzlebigen Token. Instrumentieren Sie mittels Performance Insights, Enhanced Monitoring und CloudWatch; verwenden Sie Slow-Query-Logs und EXPLAIN für Hotspots.

Verbindungspooling, RDS Proxy und Serverless-Muster

Serverless-Funktionen und verbindungsintensive Anwendungen schöpfen häufig die Verbindungslimits der Datenbank aus. Das einfachste Muster in Node.js besteht darin, einen mysql2/promise-Pool im globalen Geltungsbereich (Scope) von Lambda zu platzieren und ihn über Aufrufe hinweg wiederzuverwenden, aber das löst nicht das Problem massiver gleichzeitiger Skalierung. RDS Proxy ist die verwaltete Lösung: Erstellen Sie den Proxy mit create_db_proxy, verknüpfen Sie ihn mit Secrets aus dem Secrets Manager und den Ziel-RDS/Aurora-Instanzen und verwenden Sie den Proxy-Endpunkt in Ihrer Anwendung. RDS Proxy übernimmt das Verbindungs-Multiplexing, die Integration der IAM-Authentifizierung und das Failover. Für serverloses Aurora Serverless oder wenn Sie Aufrufe im HTTP-Stil bevorzugen, verwenden Sie die RDS Data API: rdsdataservice.executeStatement({resourceArn, secretArn, sql, database}) ermöglicht es Lambdas, SQL ohne persistente TCP-Verbindungen auszuführen. Ein häufiger Fallstrick ist die Vermischung der Data API mit provisionierten Clustern – die Data API ist für serverlose Cluster gedacht und hat eine andere Latenz- und Transaktionssemantik. Beachten Sie auch, dass RDS Proxy ein Timeout für den Verbindungspool und max_connections einführt; passen Sie das Timeout für inaktive Clients und das Ausleihen von Verbindungen (Connection Borrowing) für Lambda-Bursts an. Verwenden Sie SecretsManager.getSecretValue() für Anmeldeinformationen und rotieren Sie diese mit rotateSecret oder aktivieren Sie die automatische Rotation in der Konsole/im SDK.

Caching-Strategien: ElastiCache, DAX und Cache-Design

Die Wahl der Caching-Strategie hängt vom Datenspeicher und den Zugriffsmustern ab. Für DynamoDB bietet DAX eine Leselatenz im Mikrosekundenbereich und eine transparente SDK-Integration über den AmazonDaxClient, der den DynamoDB.DocumentClient umschließt; es ist ideal für leseintensive, Eventually-Consistent-Workloads. Für relationales oder beliebiges Key-Value-Caching verwenden Sie ElastiCache Redis für erweiterte Datenstrukturen, Persistenz (AOF/RDB-Snapshots), Replikation und Sharding im Cluster-Modus, oder Memcached für einfaches, horizontal skalierbares Caching. Implementieren Sie Cache-Aside für Lesevorgänge und Write-Through/Write-Behind nur dann, wenn dies hinsichtlich Konsistenz und Komplexität akzeptabel ist. Das Schlüsseldesign ist entscheidend: Versehen Sie Schlüssel mit Anwendungs- und Versionspräfixen, verwenden Sie sinnvolle TTLs und vermeiden Sie unbegrenzte Kardinalität. Behandeln Sie Cache Stampedes mit Lock-and-Refresh-Mustern (SETNX oder Redlock) oder einer probabilistischen vorzeitigen TTL-Aktualisierung. Konfigurieren Sie Redis mit Multi-AZ und automatischem Failover; erstellen Sie Replikationsgruppen mit automatischem Failover und Snapshots über CreateReplicationGroup. Häufige Fallen sind veraltete Caches nach Schreibvorgängen, die fehlende Invalidierung bei Schemaänderungen und die Erwartung absoluter Konsistenz. Überwachen Sie die Cache-Hit-Ratio und Eviction-Metriken in CloudWatch und skalieren Sie Knotentypen oder Cluster-Shards, wenn der Arbeitsspeicher oder die CPU zum Engpass wird.

Zeitreihen mit Timestream und Read-Replica-Mustern

Amazon Timestream ist speziell für Zeitreihen konzipiert: Die Datenerfassung erfolgt über die WriteRecords-API aus dem SDK mit gebündelten WriteRecords-Aufrufen, und Abfragen werden mit TimestreamQuery.query(sql) durchgeführt. Entwerfen Sie Ihr Datensatzschema mit Dimensionen von geringer Kardinalität und verwenden Sie Multi-Measure-Records, um die Schreibverstärkung (Write Amplification) zu reduzieren. Konfigurieren Sie Aufbewahrungsregeln für den Arbeitsspeicher (Memory Tier) und den magnetischen Speicher (Magnetic Tier) pro Tabelle, um aktuelle Daten „heiß“ zu halten und ältere Daten kostengünstig zu speichern. Die Anpassung der Aufbewahrungsdauer ist entscheidend, da die Größe des Memory Tiers die Kosten und die Abfrageleistung beeinflusst. Verwenden Sie für Analysen zeitreihenspezifische Abfragen (time_bin oder bin) und wenden Sie Filter auf Dimensionen an (Push-Down), um die Menge der gescannten Daten zu minimieren. Bei der Integration von Zeitreihen mit relationalen Speichern lagern Sie historische, unveränderliche Daten in Timestream aus und stellen Sie „heiße“ Metadaten aus RDS/Aurora mit ElastiCache bereit. Für die Skalierung von Lesezugriffen auf relationale Datenbanken fügen Sie Read Replicas hinzu und leiten Sie schreibgeschützten Verkehr dorthin. Verwenden Sie bei Aurora Reader-Endpunkte und überprüfen Sie den Replikationsverzug (CloudWatch ReplicaLag), bevor Sie kritische Lesezugriffe weiterleiten. Eine häufige Falle für Entwickler ist eine hohe Kardinalität in Timestream oder die Erzeugung von Caching-Schlüsseln pro Anfrage, was den Speicherbedarf in die Höhe treibt und die Leistung beeinträchtigt. Nutzen Sie Batch-Verarbeitung für Schreibvorgänge und asynchrone Erfassungspipelines (Kinesis, Firehose), um Lastspitzen abzufedern und Drosselung (Throttling) zu vermeiden.

Praktisches Problem: Anwendungsfallszenario

Szenario: NovaShop betreibt eine Multi-Region-E-Commerce-Plattform in AWS und verwendet Aurora MySQL für Bestellungen in us-east-1, Lambda-basierte APIs und einen globalen Kundenkatalog in DynamoDB. Entwickler nutzen CI/CD in einem einzigen AWS-Konto und speichern DB-Anmeldeinformationen im Secrets Manager.

Herausforderung: Bei Verkaufsspitzen erschöpfen Lambda-Funktionen die DB-Verbindungen, und der Katalog erfordert Lesezugriffe im Mikrosekundenbereich. Entwickler müssen die Sicherheit durch rotierte Anmeldeinformationen und minimale Latenz bei Produktlesevorgängen gewährleisten.

Empfohlener Ansatz:

1. Erstellen Sie einen RDS Proxy für den Aurora-Cluster mit CreateDBProxy, verknüpfen Sie den ARN des Secrets-Manager-Secrets und konfigurieren Sie die IAM-Authentifizierung. Aktualisieren Sie Lambda, um den Proxy-Endpunkt zu verwenden und die Anmeldeinformationen mit SecretsManager.getSecretValue() abzurufen.
2. Stellen Sie für den Katalog einen Amazon DAX-Cluster bereit und wechseln Sie vom DynamoDB-Client zum AmazonDaxClient({endpoints}), der den DynamoDB DocumentClient für Lesezugriffe im Mikrosekundenbereich umschließt (wraps).
3. Aktivieren Sie die automatische Rotation des Secrets Manager für das Aurora-Secret mithilfe der RDS-Rotations-Lambda-Vorlage (rotate-secret oder Konfiguration über die Konsole) und stellen Sie sicher, dass die IAM-Rolle von Lambda secretsmanager:GetSecretValue aufrufen kann.
4. Fügen Sie einen ElastiCache for Redis-Cluster (Cluster-Modus) für das Session-Caching hinzu und implementieren Sie das Cache-Aside-Muster mit TTLs und einer SETNX-Sperre zur Aktualisierung, um Cache Stampedes zu verhindern.

Begründung: Die Verwendung von RDS Proxy verhindert Verbindungsstürme (Connection Storms) durch die Skalierung von Lambda, während IAM/Secrets Manager die Anmeldeinformationen durch automatische Rotation schützt. DAX ermöglicht DynamoDB-Lesezugriffe im Mikrosekundenbereich, und ElastiCache übernimmt das Caching von transienten Sitzungs- und Lesedaten. Dies steht im Einklang mit den Best Practices für serverlose Skalierung und Sicherheit.

← Speicher · Alle Domänen · Messaging →

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

Amazon durchsuchen →