Amazon SAA-C03: Datenbanken & Caching — 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.

Amazon RDS: Verwaltete relationale Engines

Amazon RDS bietet sechs verwaltete Engines – MySQL, PostgreSQL, MariaDB, Oracle, SQL Server und Amazon Aurora (MySQL- und PostgreSQL-kompatibel) – und abstrahiert dabei Patching, Backups, Replikationstopologie und Failover. Die Wahl der Engine bestimmt die Lizenzierung, die Backup-Semantik und die Verfügbarkeit von Funktionen: Bei Oracle und SQL Server gibt es die Unterscheidung zwischen BYOL (Bring Your Own License) und „Lizenz inklusive“, SQL Server unterstützt bis zu fünf Read Replicas über native Replikation, und Oracle Read Replicas erfordern die Enterprise Edition mit Active Data Guard.

Die beiden RDS-Funktionen, die am häufigsten für Verfügbarkeit und Skalierung genutzt – und am häufigsten verwechselt – werden, sind Multi-AZ-Bereitstellungen und Read Replicas. Sie sind orthogonal, komplementär und nicht austauschbar.

Multi-AZ stellt eine synchrone Standby-Replik in einer zweiten Availability Zone bereit. Jeder Schreibvorgang wird sowohl auf der primären als auch auf der Standby-Instanz committet, bevor er bestätigt wird. Dies ergibt einen RPO von praktisch null und einen RTO von 60–120 Sekunden bei einem automatischen Failover. Die Standby-Instanz akzeptiert keinen Datenverkehr – sie existiert ausschließlich für den Failover. Wenn die primäre Instanz ausfällt, eine AZ beeinträchtigt ist oder Wartungsarbeiten einen Neustart erfordern, schwenkt RDS den DNS-CNAME auf die Standby-Instanz um, und Anwendungen verbinden sich transparent über denselben Endpunkt neu. Multi-AZ ist die einfachste Lösung für einen Single Point of Failure in einer einzelnen AZ: Es ist eine reine Konfigurationsoption, erfordert keine Schema- oder Anwendungsänderungen und behält den Endpunkt bei. Die neuere Multi-AZ-Cluster-Bereitstellung ist eine Drei-Knoten-Topologie (ein Writer, zwei lesbare Standbys), die eine semi-synchrone Replikation mit einer Commit-Latenz von etwa einer Sekunde verwendet und so HA plus begrenzten Lese-Offload bietet.

Read Replicas verwenden die native asynchrone Replikation der Engine (MySQL binlog, PostgreSQL WAL-Streaming). Sie sind das richtige Werkzeug für die Leseskalierung – analytische Abfragen, Reporting-Dashboards, Ad-hoc-SELECTs –, die andernfalls die OLTP-Leistung auf der primären Instanz beeinträchtigen würden. Das klassische Szenario: Eine Datenbank für die Auftragsabwicklung erleidet Timeouts, weil Mitarbeiter lange Monatsabschlussberichte ausführen. Das Hinzufügen einer Read Replica und das Verweisen des Reporting-Tools auf deren Endpunkt isoliert die analytische Last, ohne die primäre Instanz hochskalieren zu müssen. Read Replicas können regionenübergreifend sein und manuell zu eigenständigen Datenbanken hochgestuft werden, aber die Hochstufung erfolgt niemals automatisch, und alle Transaktionen, die zum Zeitpunkt des Ausfalls noch nicht repliziert wurden, gehen verloren.

In diesem Bereich gibt es zwei wiederkehrende Fallen. Erstens ist es aus mehreren Gründen falsch, Read Replicas als HA-Lösung zu behandeln: Replikate sind asynchron (potenzieller Datenverlust), haben keine automatische Hochstufung, der Endpunkt ändert sich bei der Hochstufung, und laufende Transaktionen gehen verloren. Wenn ein Design „keinen Datenverlust“ verspricht und auf eine Read Replica als Failover-Ziel verweist, ist dieses Versprechen falsch. Zweitens ist die Bereitstellung von Multi-AZ zur Bedienung von Leseverkehr Geldverschwendung, da die Standby-Instanz in der Standardtopologie nicht lesbar ist. Multi-AZ löst das Verfügbarkeitsproblem; Read Replicas lösen das Problem der Leseskalierung; oft will man beides.

Read Replicas tragen auch nichts zur Schreibskalierung bei – jeder Schreibvorgang trifft weiterhin die primäre Instanz, und die Replikate müssen ihn wiederholen. Für die Schreibskalierung nutzt man Sharding, wechselt zu Aurora (entkoppelter Speicher) oder gestaltet das System in Richtung DynamoDB um.

Richtige Dimensionierung von Read Replicas

Eine Replik muss nicht dieselbe Instanzklasse wie die primäre Instanz haben. Die primäre Instanz bewältigt die volle Schreiblast plus Lesezugriffe; eine Replik bewältigt nur die Lesezugriffe, die sie erreichen. Eine primäre

TargetTrackingScalingPolicyConfiguration:
  TargetValue: 70.0
  PredefinedMetricSpecification:
    PredefinedMetricType: DynamoDBReadCapacityUtilization
  ScaleInCooldown: 60
  ScaleOutCooldown: 60

-Instanz in Kombination mit einer

TTLSpecification:
  AttributeName: expireAt
  Enabled: true

-Replik für einen nächtlichen Reporting-Job ist durchaus sinnvoll – vorausgesetzt, die Replik kann mit der Replikations-I/O Schritt halten. Die Methodik lautet: Messen Sie die tatsächliche CPU- und Speicherauslastung sowie den Replica Lag der Replik und dimensionieren Sie sie dann entsprechend dieser Arbeitslast. Die einzige Einschränkung: Wenn Sie beabsichtigen, eine Replik während eines DR-Szenarios zur primären Instanz hochzustufen, muss sie so dimensioniert sein, dass sie die Schreiblast bewältigen kann. Unterdimensionierte Replikate sind keine geeigneten Ziele für eine Hochstufung.

Blue/Green-Deployments und Speicher

RDS Blue/Green-Deployments erstellen eine vollständige Staging-Kopie der Produktionsumgebung (Green), die über logische Replikation synchron gehalten wird. Sie können die Engine-Version aktualisieren, Parametergruppen ändern oder Schemata in der Green-Umgebung anpassen, diese testen und die Umschaltung in weniger als einer Minute mit automatischer Umbenennung des Endpunkts durchführen. Dies eliminiert das klassische Risiko eines In-Place-Upgrades, bei dem ein fehlgeschlagenes Major-Version-Upgrade ein Snapshot-Rollback erzwingt.

Die Speicherauswahl ist für schreibintensive OLTP-Workloads genauso wichtig wie die Instanzklasse. Die gp3/io2-Taxonomie:

Die Verbesserung von gp3 gegenüber gp2 ist die Entkopplung der IOPS von der Größe – Sie müssen nicht mehr Kapazität überprovisionieren, um die Leistung zu steigern. Wählen Sie io2, wenn die dauerhaften IOPS die Obergrenze von gp3 überschreiten oder wenn eine Beständigkeit von 99,999 % erforderlich ist. Multi-Attach ermöglicht es, ein einzelnes io2-Volume an bis zu 16 Nitro-Instanzen anzuhängen, aber das Dateisystem oder die Anwendung muss clusterfähig sein; es ist kein Ersatz für Replikation. Eine latente Ausfallfalle: die Bereitstellung von festem Speicher ohne aktiviertes Speicher-Autoscaling oder einen CloudWatch-Alarm für

import amazondax
dax = amazondax.AmazonDaxClient(
    endpoint_url='dax://cluster.abc.dax-clusters.us-east-1.amazonaws.com')
table = dax.Table('Products')
resp = table.get_item(Key={'sku': '1234'})  # microsecond hit path

. Wenn der freie Speicherplatz auf null sinkt, geht RDS in den Zustand

import redis, json
r = redis.Redis(host='sessions.abc123.ng.0001.use1.cache.amazonaws.com',
                port=6379, ssl=True)

def save_session(sid, data, ttl=1800):
    r.setex(f"sess:{sid}", ttl, json.dumps(data))

und lehnt Schreibvorgänge ab.

Amazon Aurora: Architektur und Endpunkte

Aurora implementiert die Speicherschicht unter MySQL und PostgreSQL als verteiltes, log-strukturiertes, sechsfach repliziertes Volume neu, das sich über drei AZs erstreckt. Rechenknoten sind in Bezug auf den Speicher zustandslos, sodass eine Aurora Replica vom selben zugrunde liegenden Volume liest wie der Writer, anstatt ein Protokoll wiederzugeben. Die Replikationsverzögerung beträgt typischerweise 10–20 ms, im Vergleich zu Sekunden bei Standard-RDS-Replicas, und ein Cluster unterstützt bis zu 15 Replicas, die in etwa 30 Sekunden zum Writer hochgestuft werden können.

Aurora stellt vier Endpunkttypen bereit:

Benutzerdefinierte Endpunkte sind wichtig, wenn Replicas heterogen sind. Wenn drei von sechs Replicas vom Typ db.r6g.8xlarge für analytisches Reporting sind, während der Rest OLTP-Lesezugriffe bedient, leitet der allgemeine Reader-Endpunkt gelegentlich Reporting-Anfragen an kleinere Knoten weiter, was die Vorhersagbarkeit beeinträchtigt. Ein benutzerdefinierter Endpunkt, der nur auf die großen Replicas beschränkt ist, bietet eine deterministische Workload-Isolierung:

aws rds create-db-cluster-endpoint \
  --db-cluster-identifier prod-aurora \
  --db-cluster-endpoint-identifier reporting \
  --endpoint-type READER \
  --static-members reporting-node-1 reporting-node-2 reporting-node-3

Beachten Sie, dass die DNS-TTLs von Aurora-Endpunkten 5 Sekunden betragen; ein längeres Caching von Verbindungszeichenfolgen hebt das Failover-Verhalten aus.

Aurora Auto Scaling fügt Reader basierend auf Ziel-CPU- oder Verbindungsmetriken hinzu und entfernt sie. Dies ist die Standardantwort für unvorhersehbare, leselastige Workloads, die hochverfügbar bleiben müssen:

TargetTrackingScalingPolicyConfiguration:
  PredefinedMetricSpecification:
    PredefinedMetricType: RDSReaderAverageCPUUtilization
  TargetValue: 60.0
  ScaleInCooldown: 300
  ScaleOutCooldown: 60

Wenn RDS MySQL Read Replicas die Replikationsverzögerung zu Spitzenzeiten nicht unter einer Sekunde halten können, ist die Low-Code-Antwort die Migration zu Aurora MySQL – die Verbindungszeichenfolgen ändern sich kaum, und die Replikation auf Speicherebene eliminiert die Verzögerung.

Aurora Serverless v2 und Klonen

Aurora Serverless v2 skaliert die Rechenleistung vertikal in feingranularen Aurora Capacity Units (ACUs, je 2 GiB Arbeitsspeicher) in etwa einer halben Sekunde, ohne Sitzungen zu trennen. Es eignet sich für variable Workloads mit einem bekannten Grundbedarf an Arbeitsspeicher – zum Beispiel eine On-Premises-MySQL-Migration, die immer mindestens 2 GiB verbraucht. Setzen Sie das Minimum auf 1 ACU und das Maximum auf 32 ACUs, und der Cluster passt sich ohne Administration an. Provisioned Aurora bleibt vorzuziehen, wenn die Last konstant und vorhersagbar ist, da Serverless v2 einen Aufschlag pro ACU mit sich bringt.

Das Klonen von Aurora erstellt einen neuen Cluster, der die Speicherseiten der Quelle mittels Copy-on-Write teilt. Klone erscheinen in Sekunden und kosten nichts, bis die Daten divergieren, was sie ideal für Staging-Umgebungen, riskante Migrationen oder um Analysten eine Produktionskopie intensiv nutzen zu lassen, macht. Eine Snapshot-Wiederherstellung stellt die Daten physisch wieder her und kann Stunden dauern; Klonen ist die bessere Wahl, wenn es auf Geschwindigkeit ankommt.

Aurora Global Database

Aurora Global Database erweitert einen Cluster auf bis zu fünf sekundäre Regionen über eine dedizierte Replikationsinfrastruktur auf Speicherebene – nicht durch Binlog-Shipping. Die typische Replikationsverzögerung liegt unter einer Sekunde, der RPO liegt unter einer Sekunde, und ein verwaltetes Failover stuft eine sekundäre Region in weniger als einer Minute hoch.

Zwei wichtige semantische Aspekte: sekundäre Regionen sind im Normalbetrieb schreibgeschützt, und Global Database ist für DR mit niedrigem RPO und Lesezugriffe mit geringer Latenz aus der Ferne konzipiert, nicht für Aktiv-Aktiv-Multi-Master. Die Annahme, eine Global Database würde „Schreibvorgänge in der sekundären Region automatisch handhaben“, ist falsch – Schreibvorgänge dort erfordern ein explizites verwaltetes Failover oder ein „Detach-and-Promote“ (Trennen und Hochstufen). Für eine angegebene Anforderung von 5 Minuten RPO / 20 Minuten RTO über Regionen hinweg mit minimalem Betriebsaufwand ist Global Database die Standardantwort.

RDS Proxy und Verbindungsmanagement

Serverless- und hochgradig nebenläufige Workloads verschärfen ein klassisches Problem: Verbindungsstürme (Connection Storms). Eine Lambda-Funktion, die auf 3.000 gleichzeitige Ausführungen skaliert, öffnet 3.000 Sockets, sprengt max_connections und verursacht kaskadierende Ausfälle – genau dann, wenn das System unter Last steht. Pools innerhalb der Funktion helfen nicht, da jede nebenläufige Ausführungsumgebung isoliert ist.

RDS Proxy befindet sich zwischen den Clients und der Datenbank, unterhält einen warmen Pool von Verbindungen und multiplext Client-Sitzungen auf diese. Er löst zwei Probleme:

1. Verbindungsstürme. Tausende von Client-Sitzungen werden auf einen kleinen Backend-Pool gemultiplext.
2. Failover-Zeit. Der Proxy hält die Client-Verbindungen offen, während er die Backend-Verbindung wiederherstellt. Dies reduziert die wahrgenommene Failover-Zeit um bis zu 66 % und eliminiert die clientseitige Wiederherstellung von TCP/TLS und die erneute DNS-Auflösung.

Er lässt sich für die Handhabung von Anmeldeinformationen in IAM und Secrets Manager integrieren, wodurch hartcodierte Secrets aus dem Anwendungscode entfernt werden.

DBProxy:
  Type: AWS::RDS::DBProxy
  Properties:
    EngineFamily: POSTGRESQL
    RequireTLS: true
    IdleClientTimeout: 1800
    Auth:
      - AuthScheme: SECRETS
        SecretArn: !Ref DBSecret
        IAMAuth: REQUIRED

Anwendungen verbinden sich mit dem Proxy-Endpunkt, nicht mit dem Cluster-Endpunkt. Jede Lambda-zu-RDS- oder High-Fan-Out-Architektur sollte RDS Proxy verwenden, es sei denn, es gibt einen bestimmten Grund, dies nicht zu tun. Den Betrieb eines eigenen Poolers (PgBouncer, ProxySQL) auf EC2 ist möglich, bringt aber den zusätzlichen Betriebsaufwand mit sich, zu dessen Beseitigung der Proxy dient.

DynamoDB: Kapazitätsmodi

DynamoDB ist ein verwalteter Schlüssel-Wert-/Dokumentenspeicher mit einer Latenz im einstelligen Millisekundenbereich bei jeder Skalierungsstufe, der horizontal nach einem Hash-Schlüssel partitioniert wird. Es bietet zwei Kapazitätsmodi:

On-Demand ist wesentlich einfacher, kostet aber pro Anfrage etwa 6- bis 7-mal mehr als gut ausgelastete bereitgestellte Kapazität. Für einen nächtlichen 4-Stunden-Batch mit 500 WCU ist On-Demand deutlich zu teuer – bereitgestellte Kapazität mit geplanter Skalierung oder reservierte Kapazität ist weitaus günstiger. Umgekehrt führt die Verwendung von bereitgestellter Kapazität für einen unvorhersehbaren Workload bei einem öffentlichen Launch zu Throttling. Für gleichmäßige Workloads mit moderater Varianz ist bereitgestellte Kapazität mit Auto-Scaling mit Zielverfolgung bei etwa 70 % Auslastung erheblich günstiger als On-Demand – oft um 50–70 %:

TargetTrackingScalingPolicyConfiguration:
  TargetValue: 70.0
  PredefinedMetricSpecification:
    PredefinedMetricType: DynamoDBReadCapacityUtilization
  ScaleInCooldown: 60
  ScaleOutCooldown: 60

Sie können den Modus einmal alle 24 Stunden wechseln. Die Annahme, dass On-Demand generell günstiger ist, ist ein kostspieliger Fehler; ebenso die Annahme, dass bereitgestellte Kapazität für unregelmäßigen Datenverkehr immer die richtige Wahl ist.

DynamoDB: Konsistenz, Streams, Globale Tabellen

Lesezugriffe sind standardmäßig eventuell konsistent (können innerhalb von ca. 1 Sekunde veraltete Daten zurückgeben, kostet 0,5 RCU). Das Setzen von ConsistentRead=true gibt den neuesten committeten Wert zu doppelten Kosten zurück. Stark konsistente Lesezugriffe werden nicht über globale sekundäre Indizes oder über DAX unterstützt – diese Pfade geben immer eventuell konsistente Daten zurück.

DynamoDB Streams erfassen Änderungen auf Elementebene als geordnetes Protokoll, das 24 Stunden lang aufbewahrt wird. Sie lösen Lambda für nachgelagerte Verarbeitungen aus (Suchindizierung, Benachrichtigungen, tabellenübergreifende Denormalisierung), ohne dass ein Polling erforderlich ist.

Globale Tabellen bauen auf Streams auf, um eine Multi-Aktiv-, Multi-Region-Replikation mit Last-Writer-Wins-Konfliktlösung bereitzustellen. Sie sind die richtige Antwort, wenn Lese- und Schreibvorgänge in mehreren Regionen lokal erfolgen müssen. Sie verdoppeln jedoch ungefähr die Speicher- und Schreibkosten – jeder Schreibvorgang ist eine WCU in jeder Replikatregion – und schwächen die Konsistenz zwischen den Regionen. Die Falle besteht darin, Globale Tabellen zu aktivieren, wenn eine einzelne Region die Verfügbarkeitsanforderungen erfüllt: DynamoDB in einer einzelnen Region wird bereits über drei AZs mit einer Verfügbarkeit von 99,99 % repliziert. Kosteneffektive Hochverfügbarkeit in einer einzelnen Region wird durch eine Tabelle in einer einzelnen Region mit aktiviertem PITR und, falls gewünscht, bereitgestellter Kapazität mit Auto-Scaling erreicht.

Point-in-Time Recovery (PITR) bietet kontinuierliche Backups mit einer Wiederherstellungsgranularität im Sekundenbereich für die letzten 35 Tage bei vernachlässigbarem Overhead. Aktivieren Sie es für jede Produktionstabelle – es erfüllt typische RPO-Anforderungen von Minuten statt Stunden. Für eine längere Aufbewahrung (regulatorische Anforderungen) integrieren Sie AWS Backup für geplante, über den Lebenszyklus verwaltete und regionsübergreifend kopierbare Backups.

TTL ermöglicht die Angabe eines Attributs, das einen Unix-Epochen-Ablaufzeitpunkt enthält; DynamoDB löscht abgelaufene Elemente asynchron und kostenlos, was ideal für Session-Speicher, kurzlebige Token oder Event-Caches ist. TTL-Löschungen fließen zur nachgelagerten Archivierung durch Streams:

TTLSpecification:
  AttributeName: expireAt
  Enabled: true

Für Analysen erzeugt der Export nach S3 einen Point-in-Time-Snapshot, der von Athena, Redshift Spectrum oder EMR gelesen werden kann, ohne die Tabellenkapazität zu verbrauchen – ein weitaus besseres Muster als das Scannen der Tabelle.

DAX: DynamoDB Accelerator

DAX ist ein vollständig verwalteter In-Memory-Cache mit Write-Through speziell für DynamoDB, der eine Leselatenz im Mikrosekundenbereich im Vergleich zum Basiswert von DynamoDB im einstelligen Millisekundenbereich liefert. Sein Unterscheidungsmerkmal ist die API-Kompatibilität: Der DAX-Client ist ein direkter Ersatz für den DynamoDB-SDK-Client, sodass Anwendungen ihn durch Ändern der Endpunktkonfiguration anstelle des Umschreibens der Abfragelogik übernehmen:

import amazondax
dax = amazondax.AmazonDaxClient(
    endpoint_url='dax://cluster.abc.dax-clusters.us-east-1.amazonaws.com')
table = dax.Table('Products')
resp = table.get_item(Key={'sku': '1234'})  # microsecond hit path

DAX unterhält zwei Caches: einen Item-Cache für GetItem/BatchGetItem-Ergebnisse und einen Query-Cache für Query/Scan-Ergebnisse. Schreibvorgänge erfolgen per Write-Through – DAX leitet sie an DynamoDB weiter und aktualisiert bei Erfolg seinen Item-Cache – aber der Query-Cache basiert auf TTL, sodass Abfrageergebnisse selbst bei frisch geschriebenen Elementen veraltet sein können.

Zwei Einschränkungen sind wichtig. Erstens beschleunigt DAX nur eventuell konsistente Lesezugriffe; stark konsistente Lesezugriffe umgehen den Cache. Zweitens verursachen andere Schreibvorgänge, die DAX umgehen, veraltete Daten. Für eine Produktdetailseite, die täglich millionenfach aufgerufen wird, ist DAX der Beschleuniger mit dem geringsten Betriebsaufwand – kein Code zur Cache-Invalidierung, keine separate Cluster-Verwaltung. ElastiCache vor DynamoDB würde funktionieren, erfordert aber eine Cache-Aside-Logik, die DAX überflüssig macht.

ElastiCache: Redis und Memcached

ElastiCache bietet als Managed Service, der Redis oder Memcached ausführt, In-Memory-Datenzugriff im Sub-Millisekundenbereich. Die Wahl der Engine hängt von den benötigten Funktionen ab:

• Memcached – reiner multithreaded Key-Value-Cache mit horizontalem Sharding, ohne Persistenz, ohne Replikation, ohne Pub/Sub. Nur für ephemeres Caching verwenden, bei dem der Verlust des gesamten Caches akzeptabel ist.
• Redis – unterstützt Replikation, Multi-AZ mit automatischem Failover, Cluster-Modus für Sharding, Persistenz, Pub/Sub, sortierte Sets, Transaktionen sowie Verschlüsselung während der Übertragung und im Ruhezustand. Erforderlich für alles, was langlebig sein muss oder komplexe Datentypen benötigt.

Zwei kanonische Muster dominieren.

Zentralisierter Session-Speicher. Wenn ein ALB den Datenverkehr auf zustandslose EC2- oder ECS-Instanzen verteilt, erzwingt die lokale Speicherung von Sessions Sticky Sessions, was zu unausgeglichener Lastverteilung führt und bei Scale-In, Deployments und AZ-Ausfällen Probleme verursacht. Die Auslagerung von Sessions in Redis ermöglicht es jeder Instanz, jede Anfrage zu bedienen, und die Sessions überleben einen Host-Ausfall:

import redis, json
r = redis.Redis(host='sessions.abc123.ng.0001.use1.cache.amazonaws.com',
                port=6379, ssl=True)

def save_session(sid, data, ttl=1800):
    r.setex(f"sess:{sid}", ttl, json.dumps(data))

Entlastung von Lesezugriffen für aufwendige Abfragen – Ranglisten (Redis Sorted Sets über ZADD/ZREVRANGE), Katalogabfragen, Aggregationen. Caching-Strategien müssen den Konsistenzanforderungen entsprechen:

• Lazy Loading (Cache-Aside): Die Anwendung liest aus dem Cache; bei einem Miss liest sie aus der DB und füllt den Cache mit einer TTL. Einfach, aber Cold Misses sind performancetechnisch schmerzhaft und die Daten können veraltet sein.
• Write-Through: Die Anwendung schreibt in den Cache und die DB in derselben Operation. Der Cache bleibt aktuell, aber Schreibvorgänge sind langsamer und ungenutzte Daten belegen weiterhin Speicher.
• Write-Back (Write-Behind): Schreibvorgänge gehen zuerst in den Cache und werden asynchron in die DB geschrieben. Schnellste Schreibvorgänge, aber bei einem Cache-Ausfall gehen Daten verloren.

data = r.get(f"product:{sku}")
if data is None:
    data = db.query("SELECT * FROM products WHERE sku=%s", sku)
    r.setex(f"product:{sku}", 300, serialize(data))

Sich auf eine Caching-Schicht ohne Invalidierungsstrategie zu verlassen – TTL, explizites DEL bei Updates oder Write-Through – führt zu veralteten Lesezugriffen (Stale Reads). Der Fehlermodus ist schleichend: Die Anwendung scheint korrekt zu funktionieren, bis Benutzer Abweichungen bemerken. Caching ist oft auch die kostengünstigste Methode, um Lesezugriffe über das hinaus zu skalieren, was Read Replicas problemlos bewältigen können, und schützt die primäre Instanz bei Lastspitzen.

Im Gegensatz zu DAX ist ElastiCache Engine-agnostisch – Sie sind für die Invalidierungslogik verantwortlich –, weshalb DAX in puncto betrieblicher Einfachheit gewinnt, wenn der Backing Store DynamoDB ist.

Migration: DMS und SCT

Der AWS Database Migration Service (DMS) repliziert Daten zwischen homogenen Engines (Oracle→Oracle, MySQL→Aurora MySQL) oder heterogenen Engines (Oracle→Aurora PostgreSQL, SQL Server→RDS MySQL, On-Prem→DynamoDB). Eine DMS-Task hat drei Phasen:

1. Full Load – Massenkopie vorhandener Zeilen.
2. CDC (Change Data Capture) – Verfolgt das Transaktionsprotokoll der Quelle und wendet laufende Änderungen an.
3. Full Load + CDC – das gängige Muster für minimale Ausfallzeiten: Die Quelle bleibt online, DMS hält das Ziel synchron, die Umstellung (Cutover) ist ein kurzer DNS-Wechsel.

aws dms create-replication-task \
  --replication-task-identifier ora-to-aurora \
  --source-endpoint-arn $SRC --target-endpoint-arn $TGT \
  --migration-type full-load-and-cdc \
  --table-mappings file://mappings.json \
  --replication-instance-arn $RI

DMS Serverless macht die Dimensionierung und Verwaltung von Replikationsinstanzen überflüssig – die Kapazität wird automatisch an die Arbeitslast angepasst, was sich für variable oder langlaufende CDC eignet. Quell-Engines müssen Supplemental Logging (Oracle) oder binäres Logging im ROW-Format (MySQL) aktiviert haben. Für sehr große Startdatenmengen (Seeds) integriert DMS mit Snowball Edge für Offline-Ladevorgänge.

DMS verschiebt Daten, nicht das Schema. Für heterogene Migrationen kombinieren Sie es mit dem AWS Schema Conversion Tool (SCT), das Stored Procedures, Views, Trigger, Sequenzen und dialektspezifische Typen konvertiert – zum Beispiel Oracle PL/SQL zu PostgreSQL PL/pgSQL oder T-SQL zu Aurora MySQL. SCT erstellt einen Bewertungsbericht, der Objekte kennzeichnet, die eine manuelle Nachbearbeitung erfordern (typischerweise 5–20 % bei komplexen Codebasen). DMS allein für eine engine-übergreifende Migration zu verwenden, ist ein häufiger Fehler: DMS kann zwar rudimentäre Zieltabellen erstellen, übersetzt aber Prozeduren oder proprietäre Typen nicht korrekt. Bei homogenen Migrationen ist SCT nicht erforderlich – native Tools (mysqldump, pg_dump, RMAN) plus DMS CDC sind ausreichend.

Das vollständige engine-übergreifende Muster:

1. SCT: convert schema, apply to target RDS/Aurora
2. DMS full-load task: bulk copy existing data
3. DMS CDC task: capture ongoing changes from source
4. Cutover: stop writes at source, wait for CDC lag = 0, redirect app

Backups und Point-in-Time Recovery

Automatisierte RDS-Backups kombinieren tägliche Snapshots mit 5-minütigen Transaktionsprotokoll-Backups und ermöglichen so eine PITR (Point-in-Time Recovery) auf die Sekunde genau innerhalb des Aufbewahrungszeitraums (1–35 Tage, Standard 7). Die Wiederherstellung erstellt eine neue Instanz – Sie können nicht direkt auf der bestehenden Instanz wiederherstellen (in-place) –, daher müssen Anwendungs-Endpunkte oder CNAMEs aktualisiert werden. Manuelle Snapshots bleiben über den Aufbewahrungszeitraum hinaus bestehen und überleben das Löschen der Instanz (abhängig von der Einstellung für den finalen Snapshot), können für DR über Regionen hinweg kopiert und über Konten hinweg geteilt werden.

Fast Snapshot Restore (FSR) für EBS-gestützte Snapshots eliminiert die Latenz durch Lazy Loading und verleiht wiederhergestellten Volumes sofort die volle Leistung – nützlich, wenn unter Zeitdruck mehrere Umgebungen aus einem Snapshot erstellt werden. Das Klonen von Aurora umgeht Snapshots für Kopien innerhalb derselben Region vollständig. DynamoDB PITR ist eine parallele Funktion, die pro Tabelle aktiviert werden muss und bei der Wiederherstellung eine neue Tabelle erzeugt.

Zweckgebundene Datenbanken

Die Auswahl einer zweckgebundenen Engine, wenn die Zugriffsmuster es erfordern, verhindert eine teure Neuarchitektur. Amazon Neptune ist eine verwaltete Graph-Datenbank, die Gremlin, openCypher und SPARQL unterstützt – geeignet, wenn Abfragen Beziehungen durchlaufen (Betrugsnetzwerke, soziale Graphen, Wissensgraphen), bei denen rekursive Joins in einer relationalen Engine unerschwinglich teuer wären. Amazon QLDB ist ein unveränderliches, kryptographisch verifizierbares Ledger mit einem reinen Anhänge-Journal (Append-only), geeignet für Aufzeichnungssysteme (Systems of Record), die eine manipulationssichere Auditierung erfordern – Lieferketten-Herkunft, Finanztransaktionen, Kfz-Zulassungsdaten. DynamoDB ist der Standard für Key-Value- oder Dokumentenzugriff im einstelligen Millisekundenbereich bei jeder Skalierung, unter Verwendung von Mustern wie Single-Table-Design, zusammengesetzten Sortierschlüsseln für hierarchischen Zugriff und GSIs für alternative Zugriffspfade. Das Erzwingen dieser Workloads in RDS führt zu Lock Contention (Ledger-Schreibvorgänge), Abfragekomplexität (Graph-Traversal) oder Skalierungsgrenzen (Key-Value mit hohem Durchsatz) – jeder dieser Punkte ist in der späteren Behebung weitaus kostspieliger als die richtige Wahl zum Zeitpunkt des Designs.

Zusammenfassung der Fallstricke

• Read Replicas als Hochverfügbarkeit (HA). Asynchron, keine automatische Heraufstufung (Promotion), Endpunkt ändert sich bei der Heraufstufung, laufende Transaktionen gehen verloren. Multi-AZ ist die Lösung für HA.
• Multi-AZ zur Leseskalierung. Die Standby-Instanz ist bei standardmäßigem RDS Multi-AZ nicht lesbar. Verwenden Sie Read Replicas oder Aurora Replicas.
• Single-AZ in der Produktion. Kein Failover-Ziel; Verfügbarkeitsverlust bei jedem AZ-Ereignis oder Instanz-Neustart. Multi-AZ kostet etwa das Doppelte, bietet aber einen qualitativen Sprung in der Verfügbarkeit.
• Replica standardmäßig gleich groß wie die primäre Instanz. Replicas benötigen oft viel weniger; dimensionieren Sie sie entsprechend der gemessenen Last, es sei denn, die Replica ist ein Heraufstufungsziel (Promotion Target).
• DynamoDB On-Demand ist immer günstiger. Die Kosten pro Anfrage sind etwa 6-7x höher; Provisioned + Auto-Scaling ist bei stabilen Workloads vorteilhafter.
• Global Tables für Anforderungen in einer einzigen Region. Verdoppelt die Kosten und schwächt die Konsistenz ohne Nutzen, es sei denn, es wird eine regionenübergreifende Benutzernähe oder Disaster Recovery (DR) benötigt.
• Sekundäre Instanzen einer Aurora Global Database verarbeiten Schreibvorgänge. Sie sind schreibgeschützt (read-only), bis ein verwaltetes Failover sie heraufstuft.
• Lambda → RDS ohne RDS Proxy. Eine Verbindungflut (Connection Storm) schöpft max_connections aus; in der Funktion implementierte Pools helfen nicht über nebenläufige Ausführungsumgebungen hinweg.
• DMS allein für heterogene Migrationen. Verschiebt Daten, aber nicht das Schema. Kombinieren Sie es mit SCT.
• Fester RDS-Speicher ohne Autoscaling oder FreeStorageSpace-Alarme. Latenter Ausfall – der storage-full-Zustand weist Schreibvorgänge ab.
• Caching ohne Invalidierungsstrategie. Stillschweigend veraltete Daten (Silent Staleness). TTLs, Write-Through oder explizite Invalidierung sind nicht verhandelbar.
• Stark konsistente Lesezugriffe über DAX oder GSIs. Beide Wege liefern nur eventuell konsistente (eventually consistent) Daten.

← Inhaltsbereitstellung · Alle Domänen · Analytik →

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

Amazon durchsuchen →