Amazon DOP-C02: Speicher, Datenbanken und Datenmanagement — Lernleitfaden

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

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

Überblick

Speicher, Datenbanken und Datenverschiebung auf AWS müssen auf Langlebigkeit, Verfügbarkeit, Kosteneffizienz und Automatisierung ausgelegt sein. Die Beherrschung von S3-Speicherklassen und -Replikation, DynamoDB-Kapazität und globaler Verteilung, RDS/Aurora-Konfigurationssteuerungen und Backup-Mustern, In-Memory-Caching, gemeinsam genutzten Dateisystemen und Datenmigrationsdiensten ermöglicht zuverlässige Systeme mit niedriger Latenz, vorhersagbarem Wiederherstellungsverhalten und kontrollierten Ausgaben.

Amazon S3: Speicherklassen, Lifecycle, Intelligent-Tiering und Replikation

S3-Speicherklassen richten die Kosten an den Zugriffsmustern aus:

Standard: Multi-AZ, niedrige Latenz, keine Abrufgebühren. Standard für „heiße“ Daten.
Intelligent-Tiering (S3 INT): Multi-AZ mit automatischem Tiering über die Ebenen „Frequent Access“ und „Infrequent Access“ sowie optionale Archiv-Ebenen. Überwachungs- und Automatisierungsgebühr pro Objekt; Objekte kleiner als 128 KB werden nicht automatisch verschoben. Die Ebenen „Archive Access“ und „Deep Archive Access“ sind optional (Opt-in) mit Schwellenwerten für den letzten Zugriff; Abrufgebühren fallen für Ebenen an, die nicht „Frequent“ sind.
Standard-IA und One Zone-IA: Geringere Speicherkosten mit Abrufgebühren; 30-tägige Mindestspeichergebühr. One Zone-IA ist Single-AZ für wiederherstellbare Daten.
Glacier Instant Retrieval: Zugriff im Millisekundenbereich zu Archiv-Kosten; 90 Tage Mindestspeicherdauer.
Glacier Flexible Retrieval: Abruf in Minuten bis Stunden, Optionen für Bulk/Standard/Expedited; 90 Tage Mindestspeicherdauer.
Glacier Deep Archive: Abruf in Stunden bis zu 12 Stunden; 180 Tage Mindestspeicherdauer. Wählen Sie die kälteste praktikable Speicherklasse unter Berücksichtigung der Mindestspeicherdauer, der Abrufgebühren und der erforderlichen Zugriffszeiten.

Lifecycle-Richtlinien automatisieren Übergänge und das Ablaufen von Objekten mithilfe von Filtern (Präfix, Tags) für eine granulare Steuerung. Wichtige Aktionen umfassen den Übergang zu IA/Glacier-Speicherklassen nach Schwellenwerten für Inaktivität, den Übergang/das Ablaufen von nicht aktuellen Versionen in versionierten Buckets, das Ablaufen von Löschmarkierungen und das Abbrechen unvollständiger mehrteiliger Uploads. Lifecycle und Objekt-Tagging sind entscheidend, um die Datenaufbewahrung und eine nachweisbare Löschung durchzusetzen, zusammen mit S3 Object Lock (Governance-/Compliance-Modi), wenn Unveränderlichkeit erforderlich ist.

Intelligent-Tiering ist ideal, wenn Zugriffsmuster unbekannt oder variabel sind. Es erhält die Leistung (keine Abrufverzögerung aus den Frequent/IA-Ebenen), eliminiert die Notwendigkeit einer Neuarchitektur bei sich ändernden Mustern und kann optional auf Basis des letzten Zugriffs automatisch in tiefe Archiv-Ebenen verschieben. Dies bietet die beste Mischung aus Agilität und Kostenkontrolle für langlebige Datensätze mit sporadischem Zugriff.

S3-Replikation bietet eine langlebige, asynchrone Kopie von Objekten:

Anforderungen: Versionierung muss für Quelle und Ziel aktiviert sein. Die Replikationskonfiguration definiert den Ziel-Bucket/das Ziel-Konto/die Ziel-Region, Filter nach Präfix/Tags, Metadaten-Replikation (ACLs, Tags, S3 Object Lock), Speicherklasse und ob Löschmarkierungen und vorhandene Objekte repliziert werden sollen.
Same-Region Replication (SRR): Compliance/Datenhoheit, Log-Aggregation, atomare Verarbeitung über Konten hinweg.
Cross-Region Replication (CRR): DR, Latenzreduzierung, globale Verteilung, Compliance.
KMS-verschlüsselte Objekte: Die Replikationsrolle muss berechtigt sein, mit dem Quell-KMS-Schlüssel zu entschlüsseln und mit dem Ziel-KMS-Schlüssel zu verschlüsseln. Geben Sie den Replikat-KMS-Schlüssel in der EncryptionConfiguration der Replikationsregel an. Bei kontoübergreifender Replikation muss die Bucket-Richtlinie des Ziels aktualisiert werden, um der Replikationsrolle Schreibzugriff zu gewähren.
Bestehende Objekte: Verwenden Sie S3 Batch Replication zum nachträglichen Auffüllen.
Replication Time Control (RTC): Fügt ein 15-Minuten-SLA für den Abschluss der Replikation hinzu, mit Replikationsmetriken und Benachrichtigungen zur Überwachung der SLAs. Nützlich für Compliance und strenge RPOs.
Eigentümerschaft und Zugriff: Bei kontoübergreifender Replikation aktivieren Sie „Bucket owner preferred“ oder „Object Ownership bucket owner enforced“, um die Komplexität von ACLs zu vermeiden und sicherzustellen, dass das Zielkonto Eigentümer der Replikate ist.

Datenbanken auf AWS: DynamoDB, RDS und Aurora

DynamoDB-Kapazitätsmodi und -Skalierung:

On-Demand: keine Kapazitätsplanung; Preis pro Anfrage; ideal für unvorhersehbare oder stark schwankende Workloads und für neue Tabellen ohne bekanntes Verkehrsaufkommen.
Provisioned (Bereitgestellt): RCUs/WCUs mit DynamoDB Application Auto Scaling auf eine Zielauslastung festlegen; geeignet für gleichmäßigen oder vorhersagbaren Datenverkehr und zur Kostenkontrolle.
Adaptive Capacity: verteilt den Partitionsdurchsatz automatisch auf „Hot Keys“ um, aber extrem heiße Partitionen erfordern weiterhin einen Lastausgleich (z. B. Write Sharding). GSIs haben eine separate Kapazität; sorgfältige Modellierung ist erforderlich, um Drosselung (Throttling) zu vermeiden.
Elementgröße beeinflusst die Kapazität: 1 WCU pro 1 KB Schreibvorgang; 1 RCU pro 4 KB stark konsistentem Lesevorgang oder 8 KB eventuell konsistentem Lesevorgang.

DynamoDB Streams und DAX:

Streams erfassen Änderungen auf Elementebene mit einer Aufbewahrungsfrist von 24 Stunden. Wählen Sie Ansichtstypen, um NEW/OLD-Images einzuschließen. Gängige Muster: Lambda-Trigger für CQRS/ereignisgesteuerte Schreibvorgänge, tabellenübergreifende Synchronisierung und Audit-Protokolle. Die Reihenfolge gilt pro Partitionsschlüssel, und die Zustellung erfolgt mindestens einmal (at-least-once).
DAX ist ein verwalteter, API-kompatibler In-Memory-Cache für DynamoDB, der die Lese-Latenz drastisch reduziert. Er unterstützt eventuell konsistente Lesevorgänge; stark konsistente Lesevorgänge müssen DAX umgehen. Er bietet Write-Through für Elementänderungen und TTL-basierte Invalidierung. Verwenden Sie Multi-AZ-Cluster für Hochverfügbarkeit und platzieren Sie DAX-Subnetze in der Nähe der Clients.

DynamoDB Global Tables:

Multi-Region-, Multi-Master-Replikation mittels Streams mit „Last-Writer-Wins“-Konfliktauflösung basierend auf einem Systemzeitstempel. Das Design sollte darauf ausgelegt sein, gleichzeitige Aktualisierungen derselben Attribute über Regionen hinweg zu vermeiden, oder eine anwendungsseitige Abstimmung (Reconciliation) implementieren.
Das TTL-Attribut wird wie normale Elementdaten repliziert; TTL-gesteuerte Löschungen werden pro Region verarbeitet und nicht als explizite Löschvorgänge repliziert.
Backups und PITR sind auf eine Region beschränkt (Region-scoped); Wiederherstellung erfolgt in neuen Tabellen pro Region und (optional) Neuerstellung als neue Global Table.

Konfiguration und Backups von Amazon RDS:

Parametergruppen definieren Engine-Parameter. Statische Parameter erfordern einen Neustart; dynamische Parameter werden, wo unterstützt, sofort angewendet. Verwenden Sie DB-Parametergruppen für Engines auf Instanzebene und Cluster-Parametergruppen für Aurora.
Optionsgruppen aktivieren Engine-native Funktionen (z. B. Oracle TDE/OEM, native Sicherung/Wiederherstellung von SQL Server, MySQL/MariaDB-Plugins). Optionen können einen Neustart der Engine erfordern; verwalten Sie Änderungsfenster sorgfältig.
Automatisierte Backups ermöglichen PITR innerhalb eines Aufbewahrungszeitraums (bis zu 35 Tage). Sie erfassen tägliche Snapshots und Transaktionsprotokolle in S3; Wiederherstellungen erzeugen neue Instanzen.
Manuelle Snapshots bleiben bis zur Löschung erhalten, sind über Regionen hinweg kopierbar und können kontenübergreifend geteilt werden (unter Beachtung der KMS-Schlüsselberechtigungen für verschlüsselte Snapshots). Verwenden Sie das Kopieren von Snapshots über Regionen hinweg als Grundlage für DR (Disaster Recovery).

Besonderheiten von Amazon Aurora:

Endpunkte: Der Cluster-(Writer-)Endpunkt verweist für Schreibvorgänge immer auf die primäre Instanz. Der Reader-Endpunkt verteilt die Last auf die Replicas. Benutzerdefinierte (Custom) Endpunkte können eine Teilmenge von Readern für gestaffelte Lesepools oder spezialisierte Workloads auswählen. Leiten Sie Schreibvorgänge immer an den Writer-Endpunkt und Lesevorgänge an den Reader- oder den entsprechenden Custom-Endpunkt, um Unterbrechungen bei Failovern zu minimieren.
Serverless v2: feingranulare, sofortige Skalierung von ACUs ohne Neustart. Es läuft innerhalb eines Aurora-Clusters, unterstützt gemischte Serverless- und Provisioned-Instanzen und eignet sich gut für stark schwankende Workloads, Dev/Test oder mandantenfähige Anwendungen mit ungleichmäßiger Nachfrage. Es bewahrt die Verbindungskonsistenz aufgrund der kontinuierlichen Skalierung besser als v1.
Klonen: schnelle Copy-on-Write-Klone innerhalb einer Region für Dev/Test, Data Science oder die Validierung von Blue/Green-Änderungen. Klone sind speichereffizient und weichen nur bei geänderten Pages voneinander ab. Sie können Klone verketten; löschen Sie sie nach Gebrauch, um Speicherplatz freizugeben.

Caching und gemeinsam genutzte Dateisysteme: ElastiCache und EFS

ElastiCache for Redis vs. Memcached:

Redis: erweiterte Datenstrukturen, Replikation, Pub/Sub, Lua, Streams, Geospatial, sortierte Mengen (Sorted Sets) und Persistenz über Snapshots; unterstützt automatisches Multi-AZ-Failover und Redis Global Datastore für regionsübergreifende Read Replicas. Wählen Sie Redis, wenn Sie komplexe Datentypen, Langlebigkeit (Wiederherstellung aus Snapshots) oder Hochverfügbarkeit mit Failover benötigen.
Memcached: einfach, multithreaded, keine Replikation oder Persistenz; Scale-Out über clientseitiges Sharding; zustandslos und einfach horizontal zu skalieren. Wählen Sie Memcached für flüchtiges, reines Caching mit sehr hohem Durchsatz und wenn Sie das Sharding auf Client-Seite steuern möchten. Redis Cluster-Modus und Replikationsgruppen:
Cluster-Modus deaktiviert: ein Shard mit einer primären Instanz und Replicas; vertikale Skalierung oder begrenzte horizontale Skalierung über Read Replicas.
Cluster-Modus aktiviert: Hash-Slot-Sharding über mehrere primäre Shards, jeder mit Replicas, was ein nahezu lineares Scale-Out ermöglicht. Replikationsgruppen definieren die Primär-/Replica-Topologie und das Multi-AZ-Failover. Backups erfolgen pro Replikationsgruppe; testen Sie das Failover, um die RTO zu validieren.

Amazon EFS für gemeinsam genutzte POSIX-Dateien:

Mount-Ziele (Mount Targets): Erstellen Sie eines in jeder AZ der VPC, um Zugriffspfade innerhalb der AZ und Verfügbarkeit sicherzustellen. Sicherheitsgruppen an den Mount-Zielen steuern den NFS-Verkehr; verwenden Sie bei Bedarf den EFS Mount Helper für TLS-in-transit und IAM-Autorisierung.
Zugriffspunkte (Access Points): Erzwingen Sie ein Stammverzeichnis und eine POSIX-Identität (UID/GID) für Anwendungen, was mandantenfähige Isolierung und einfaches Mounting mit minimalen Rechten (Least Privilege) durch ECS/EKS/EC2 ermöglicht, ohne die OS-Benutzerverwaltung koordinieren zu müssen.
Lifecycle Management und Speicherklassen: EFS Standard und Standard-IA (Regional, Multi-AZ) sowie One Zone/One Zone-IA (Single-AZ). Intelligent-Tiering verschiebt Dateien basierend auf der letzten Zugriffszeit automatisch zwischen den Standard- und IA-Klassen; Sie können auch explizite Übergangsrichtlinien festlegen. Wählen Sie One-Zone-Varianten für wiederherstellbare oder unkritische Daten, um Kosten zu sparen. Kombinieren Sie dies mit AWS Backup für zentralisierte Richtlinien und konten-/regionsübergreifende Backups.

Datenmigration: DMS, Snowball und DataSync

AWS Database Migration Service (DMS): Online-Migration mit minimaler Ausfallzeit durch vollständiges Laden plus Change Data Capture (CDC). Unterstützt homogene und heterogene Migrationen durch integrierte Schemakonvertierung (mit dem AWS Schema Conversion Tool für komplexe Konvertierungen). Einsatz für Lift-and-Shift zu RDS/Aurora, zu DynamoDB (über JSON-Mapping) oder für laufende Replikation zur Lese-Entlastung oder für schrittweise Umstellungen. Dimensionieren Sie Replikationsinstanzen für Spitzenänderungsraten; stellen Sie sicher, dass Quell-Logs (z. B. binlog/redo) eine ausreichende Historie behalten.
AWS Snowball (Edge Storage/Compute Optimized): Offline-Datentransfer im Petabyte-Maßstab, wenn Netzwerke begrenzt/teuer sind oder wenn Sie schnell riesige S3/EFS-Datensätze bereitstellen müssen. Verketten Sie mehrere Geräte für Multi-Petabyte-Lasten. Einsatz für anfängliche Massen-Uploads, Datenerfassung an Remote-/Edge-Standorten oder die Migration aus eingeschränkten Rechenzentren. Die Daten werden durchgängig mit KMS verschlüsselt; Geräte-Tracking und manipulationssichere Siegel unterstützen die Nachweiskette (Chain of Custody).
AWS DataSync: Online, beschleunigter Transfer für NFS/SMB zu S3/EFS/FSx und zwischen AWS-Speicherdiensten/Regionen. Der Dienst übernimmt die inkrementelle Änderungserkennung, Parallelisierung, Komprimierung, Bandbreitensteuerung, Zeitplanung und Integritätsprüfungen. Einsatz zum Verschieben wiederkehrender Deltas, für hybride Workflows und zum Ersetzen benutzerdefinierter rsync-Skripte durch verwaltete Automatisierung. Stellen Sie den DataSync-Agenten On-Premises bereit, um auf lokalen Speicher zuzugreifen.

Praktisches Problemszenario

Shopify muss seine globale Produktmedien-Pipeline und Katalogdaten modernisieren und gleichzeitig die Ausfallsicherheit und Latenz für Käufer weltweit verbessern. Das Unternehmen muss: Produktbilder über Regionen und Konten hinweg mit einem strengen RPO replizieren, die Lese-Latenz von DynamoDB in Nordamerika und Europa reduzieren, On-Premises-NFS-Assets mit laufenden Deltas migrieren und den RDS-Betrieb mit zuverlässigen Backups vereinfachen.

Implementieren Sie S3 CRR mit Replication Time Control vom primären Medien-Bucket in us-east-1 (Merchandising-Konto) zu einem Ziel-Bucket in eu-west-1 (Auslieferungskonto).

Warum: CRR erfüllt die Trennung über Regionen und Konten hinweg für das Prinzip der geringsten Rechte (Least Privilege) und die Datenhoheit. RTC bietet ein 15-minütiges Replikations-SLA und Überwachung für ein RPO auf Compliance-Niveau. Eine kontoübergreifende Bucket-Richtlinie stellt sicher, dass die Quell-Replikationsrolle schreiben kann, und die Angabe eines Ziel-KMS-Schlüssels erhält die Verschlüsselungsdomänen aufrecht.

Definieren Sie S3-Replikationsregeln, die nach Präfix und Tag gefiltert sind, um Originale, Thumbnails und Protokolle zu trennen, und aktivieren Sie die Replikation von Löschmarkierungen. Verwenden Sie S3 Batch Replication, um ältere Objekte nachzufüllen.

Warum: Die Eingrenzung durch Regeln vermeidet unnötige Replikationskosten, und die Replikation von Löschmarkierungen hält die Regionen semantisch konsistent. Batch Replication schließt historische Lücken ohne maßgeschneiderte Skripte.

Konvertieren Sie den Produktkatalog und das Inventar in eine globale DynamoDB-Tabelle über us-east-1 und eu-west-1; stellen Sie die Tabellen auf On-Demand-Kapazität um und fügen Sie DAX-Cluster pro Region für leselastige APIs hinzu.

Warum: Globale Tabellen bieten Aktiv-Aktiv-Schreibvorgänge mit lokalen Lese-/Schreibvorgängen mit geringer Latenz und kontinuierlicher Replikation. On-Demand eliminiert das Risiko der Kapazitätsplanung bei Verkehrsspitzen. DAX reduziert die P99-Latenzen für häufig gelesene Daten (Hot Reads) und schirmt DynamoDB vor sprunghaften Zugriffen ab.

Migrieren Sie den relationalen Workload für Bestellungen auf Amazon Aurora MySQL mit Writer- und Reader-Endpunkten; fügen Sie einen kleinen Aurora Serverless v2 Reader für sprunghafte Analysen hinzu und aktivieren Sie automatisierte Backups mit einer Aufbewahrungsfrist von 14 Tagen.

Warum: Cluster/Reader-Endpunkte entkoppeln Lese-/Schreibvorgänge und minimieren Störungen bei Wartungsarbeiten oder Failover. Serverless v2 fängt unvorhersehbare Analyse-Spitzen kosteneffektiv ab. Automatisierte Backups ermöglichen PITR und vereinfachte Wiederherstellungsprozesse.

Führen Sie ElastiCache for Redis (Cluster-Modus aktiviert) für die Sitzungsspeicherung und das Caching der Produktverfügbarkeit mit Multi-AZ und Snapshot-Backups ein; setzen Sie TTLs, die auf die Geschäfts-SLAs abgestimmt sind.

Warum: Redis-Datenstrukturen und Multi-AZ-Failover gewährleisten schnelle, zustandsbehaftete Sitzungen und eine Cache-Invalidierung nahezu in Echtzeit. Der Cluster-Modus skaliert horizontal mit wachsender Kataloggröße und zunehmendem Datenverkehr.

Erstellen Sie ein regionales EFS-Dateisystem mit Mount-Zielen in jeder Anwendungs-AZ und Access Points für Workloads, die gemeinsam genutzten POSIX-Speicher benötigen (z. B. Medienprozessoren). Aktivieren Sie EFS-Lebenszyklusübergänge zu IA nach 30 Tagen.

Warum: EFS bietet elastischen, Multi-AZ-fähigen, gemeinsam genutzten Speicher; Access Points erzwingen eine anwendungsspezifische Isolierung und POSIX-Identitäten. Das Lebenszyklusmanagement senkt automatisch die Kosten für selten genutzte (kalte) Assets, die zugänglich bleiben.

Migrieren Sie On-Premises-NFS-Medienbibliotheken mit AWS DataSync und geplanten Aufgaben für nächtliche inkrementelle Synchronisierungen nach S3 und EFS.

Warum: DataSync handhabt Änderungserkennung, Parallelität, Integritätsprüfung und Bandbreitenkontrolle besser als Ad-hoc-rsync und automatisiert laufende Deltas mit minimalem Betriebsaufwand.

Verschieben Sie den alten PostgreSQL-Katalog mit AWS DMS (vollständiges Laden plus CDC) und bei Bedarf mit dem AWS Schema Conversion Tool nach Aurora; führen Sie die Umstellung durch, nachdem der CDC-Lag abgebaut ist.

Warum: DMS ermöglicht eine Migration mit nahezu null Ausfallzeit, wobei die kontinuierliche Replikation die Datenparität bei der Umstellung sicherstellt. SCT übernimmt Engine-spezifische Konvertierungen.

Laden Sie historische Medien im Multi-Petabyte-Bereich mit Snowball Edge-Geräten als Startpunkt in S3 und wechseln Sie dann zu DataSync für laufende Inkremente.

Warum: Snowball beschleunigt den anfänglichen Massentransfer, ohne die WAN-Verbindungen zu überlasten; DataSync sorgt nach dem initialen Laden für kontinuierliche Updates mit Verifizierung und Zeitplanung.

Diese Architektur reduziert die globalen Lese-Latenzen, bietet vorhersagbare Replikations-RPOs, vereinfacht relationale Operationen und Backups, zentralisiert gemeinsam genutzten Speicher mit Zugriffskontrollen und bietet einen pragmatischen Weg von der Offline-Massenmigration zu einer automatisierten, inkrementellen Datenbewegung.

← Ereignisgesteuerte Architekturen und Automatisierung · Alle Domänen · Netzwerk und Content Delivery →

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