Amazon DOP-C02: Opslag, Databases en Databeheer — Studiegids

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

Onderdeel van de AWS DevOps Engineer Professional DOP-C02 — Studiegids. Oefen met geverifieerde antwoorden in het Amazon-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Opslag, databases en dataverplaatsing op AWS moeten worden ontworpen voor duurzaamheid, beschikbaarheid, kostenefficiëntie en automatisering. Het beheersen van S3-opslagklassen en -replicatie, DynamoDB-capaciteit en wereldwijde distributie, RDS/Aurora-configuratiecontroles en back-uppatronen, in-memory caching, gedeelde bestandssystemen en datamigratiediensten maakt betrouwbare systemen met lage latentie mogelijk, met voorspelbaar herstelgedrag en beheerste uitgaven.

Amazon S3: opslagklassen, lifecycle, intelligent tiering en replicatie

S3-opslagklassen stemmen de kosten af op toegangspatronen:

Standard: multi-AZ, lage latentie, geen ophaalkosten. Standaard voor ‘hot data’.
Intelligent-Tiering (S3 INT): multi-AZ met automatische tiering over Frequent en Infrequent Access tiers en optionele archief-tiers. Kosten voor monitoring en automatisering per object; objecten kleiner dan 128 KB worden niet automatisch getierd. Archive Access en Deep Archive Access tiers zijn opt-in met drempels voor laatste toegang; ophaalkosten zijn van toepassing vanuit niet-frequente tiers.
Standard-IA en One Zone-IA: lagere opslagkosten met ophaalkosten; minimale opslagkosten voor 30 dagen. One Zone-IA is single-AZ voor data die opnieuw kan worden aangemaakt.
Glacier Instant Retrieval: toegang in milliseconden tegen archiefkosten; minimaal 90 dagen.
Glacier Flexible Retrieval: ophalen in minuten tot uren, bulk/standaard/versnelde opties; minimaal 90 dagen.
Glacier Deep Archive: ophalen in uren tot 12 uur; minimaal 180 dagen. Kies de koudst mogelijke tier en houd rekening met de kosten voor minimale opslagduur, ophaalkosten en de vereiste toegangstijden.

Lifecycle-beleid automatiseert transities en vervalacties met behulp van filters (prefix, tags) voor fijngranulaire controle. Belangrijke acties zijn onder meer de transitie naar IA/Glacier-tiers na drempels voor inactiviteit, transitie/verval van niet-huidige versies in buckets met versiebeheer, het laten vervallen van delete markers en het afbreken van onvolledige multipart uploads. Lifecycle en object-tagging zijn cruciaal om dataretentie en verdedigbare verwijdering af te dwingen, naast S3 Object Lock (governance/compliance modes) wanneer onveranderlijkheid vereist is.

Intelligent-Tiering is ideaal wanneer toegangspatronen onbekend of variabel zijn. Het behoudt de prestaties (geen ophaalvertraging vanuit frequent/IA-tiers), elimineert de noodzaak voor herarchitecturering wanneer patronen veranderen, en kan optioneel automatisch archiveren naar diepe tiers op basis van laatste toegang. Dit biedt de beste mix van flexibiliteit en kostenbeheersing voor datasets met een lange levensduur en sporadische toegang.

S3-replicatie zorgt voor een duurzame, asynchrone kopie van objecten:

Vereisten: versiebeheer ingeschakeld op de bron- en bestemmingsbucket. De replicatieconfiguratie definieert de bestemmingsbucket/account/regio, filter op prefix/tags, replicatie van metadata (ACL’s, tags, S3 Object Lock), opslagklasse en of delete markers en bestaande objecten gerepliceerd moeten worden.
Same-Region Replication (SRR): compliance/datasoevereiniteit, log-aggregatie, atomaire verwerking over accounts heen.
Cross-Region Replication (CRR): DR, latentiereductie, wereldwijde distributie, compliance.
Met KMS versleutelde objecten: de replicatierol moet toestemming hebben om te ontsleutelen met de bron-KMS-sleutel en te versleutelen met de bestemmings-KMS-sleutel. Specificeer de replica-KMS-sleutel in de EncryptionConfiguration van de replicatieregel. Voor cross-account replicatie, update het bucket-beleid van de bestemming om de replicatierol schrijftoegang te geven.
Bestaande objecten: gebruik S3 Batch Replication om deze alsnog te repliceren.
Replication Time Control (RTC): voegt een SLA van 15 minuten toe voor de voltooiing van de replicatie, met replicatiemetrieken en notificaties om SLA’s te monitoren. Nuttig voor compliance en strikte RPO’s.
Eigendom en toegang: bij cross-account replicatie, schakel ‘bucket owner preferred’ of ‘Object Ownership bucket owner enforced’ in om de complexiteit van ACL’s te vermijden en ervoor te zorgen dat het bestemmingsaccount eigenaar is van de replica’s.

Databases op AWS: DynamoDB, RDS en Aurora

DynamoDB-capaciteitsmodi en schalen:

On-demand: geen capaciteitsplanning; betalen per aanvraag; ideaal voor onvoorspelbare of piekbelastingen en voor nieuwe tabellen zonder bekend verkeer.
Provisioned: stel RCU’s/WCU’s in met DynamoDB Application Auto Scaling op basis van doelgebruik; geschikt voor stabiel of voorspelbaar verkeer en kostenbeheersing.
Adaptive capacity: herverdeelt automatisch de doorvoer van partities naar ‘hot keys’, maar extreem ‘hotte’ partities vereisen nog steeds load-leveling (bijv. write sharding). GSI’s hebben aparte capaciteit; modelleer zorgvuldig om throttling te voorkomen.
Itemgrootte beïnvloedt capaciteit: 1 WCU per 1 KB schrijfoperatie; 1 RCU per 4 KB ‘strongly consistent’ leesoperatie of 8 KB ’eventually consistent’ leesoperatie.

DynamoDB streams en DAX:

Streams leggen mutaties op itemniveau vast met een retentie van 24 uur. Kies weergavetypes om NIEUWE/OUDE images op te nemen. Veelvoorkomende patronen: Lambda-triggers voor CQRS/event-driven schrijfacties, synchronisatie tussen tabellen en audittrails. De volgorde is per partitiesleutel en de levering is ‘at-least-once’.
DAX is een beheerde, API-compatibele, in-memory cache voor DynamoDB die de leeslatentie drastisch verlaagt. Het ondersteunt ’eventually consistent’ leesoperaties; ‘strongly consistent’ leesoperaties moeten DAX omzeilen. Het biedt ‘write-through’ voor itemmutaties en op TTL gebaseerde invalidatie. Gebruik multi-AZ-clusters voor hoge beschikbaarheid en plaats DAX-subnetten dicht bij clients.

DynamoDB global tables:

Multi-Region, multi-master replicatie via streams met ’last-writer-wins’ conflictresolutie op basis van een systeemtijdstempel. Ontwerp om gelijktijdige updates van dezelfde attributen in verschillende Regions te vermijden of implementeer reconciliatie aan de applicatiekant.
Het TTL-attribuut repliceert als normale itemdata; door TTL gestuurde verwijderingen worden per Region verwerkt en niet gerepliceerd als expliciete verwijderingen.
Back-ups en PITR zijn per Region ingesteld; herstel naar nieuwe tabellen per Region en maak (optioneel) opnieuw aan als een nieuwe global table.

Amazon RDS-configuratie en back-ups:

Parameter groups definiëren engine-parameters. Statische parameters vereisen een herstart; dynamische parameters worden onmiddellijk toegepast waar ondersteund. Gebruik DB parameter groups voor engines op instance-niveau en cluster parameter groups voor Aurora.
Option groups maken engine-native functies mogelijk (bijv. Oracle TDE/OEM, SQL Server native back-up/herstel, MySQL/MariaDB-plug-ins). Opties kunnen een herstart van de engine vereisen; beheer wijzigingsvensters zorgvuldig.
Geautomatiseerde back-ups maken PITR mogelijk binnen een retentieperiode (tot 35 dagen). Ze maken dagelijkse snapshots en transactielogboeken naar S3; hersteloperaties produceren nieuwe instances.
Handmatige snapshots worden bewaard totdat ze worden verwijderd, zijn kopieerbaar tussen Regions en deelbaar tussen accounts (met inachtneming van KMS-sleutelmachtigingen voor versleutelde snapshots). Gebruik het kopiëren van snapshots tussen Regions voor DR-seeds.

Amazon Aurora-specifieke kenmerken:

Endpoints: het cluster (writer) endpoint verwijst altijd naar de primary voor schrijfacties. Het reader endpoint verdeelt de belasting over replica’s. Custom endpoints kunnen een subset van readers selecteren voor gelaagde leespools of gespecialiseerde workloads. Richt schrijfacties altijd op het writer endpoint en leesacties op het reader/geschikte custom endpoint voor minimale onderbrekingen tijdens failovers.
Serverless v2: fijnmazige, onmiddellijke schaling van ACU’s zonder herstart. Het draait binnen een Aurora-cluster, ondersteunt een mix van serverless en provisioned instances, en is zeer geschikt voor piekbelastingen, dev/test, of multi-tenant apps met ongelijkmatige vraag. Het behoudt de verbindingsconsistentie beter dan v1 dankzij continue schaling.
Cloning: snelle, ‘copy-on-write’ klonen binnen een Region voor dev/test, data science, of validatie van blue/green-wijzigingen. Klonen zijn ruimte-efficiënt en wijken alleen af op gewijzigde pagina’s. Je kunt klonen aan elkaar koppelen; verwijder ze als je klaar bent om opslagruimte vrij te maken.

Caching en gedeelde bestandssystemen: ElastiCache en EFS

ElastiCache for Redis vs Memcached:

Redis: geavanceerde datastructuren, replicatie, Pub/Sub, Lua, streams, geospatial, gesorteerde sets en persistentie via snapshots; ondersteunt Multi-AZ automatische failover en Redis Global Datastore voor cross-Region leesreplica’s. Kies Redis wanneer je rijke datatypes, duurzaamheid (herstel van snapshots) of hoge beschikbaarheid met failover nodig hebt.
Memcached: eenvoudig, multithreaded, geen replicatie of persistentie; scale-out via client-side sharding; stateless en gemakkelijk horizontaal te schalen. Kies Memcached voor kortstondige, pure caching met zeer hoge doorvoer en wanneer je sharding aan de clientzijde wilt beheren. Redis cluster mode en replication groups:
Cluster mode uitgeschakeld: één shard met een primary en replica’s; verticale schaal of beperkte horizontale schaling via leesreplica’s.
Cluster mode ingeschakeld: hash-slot sharding over meerdere primary shards, elk met replica’s, wat een bijna-lineaire scale-out mogelijk maakt. Replication groups definiëren de primary/replica-topologie en Multi-AZ failover. Back-ups zijn per replication group; test de failover om de RTO te valideren.

Amazon EFS voor gedeelde POSIX-bestanden:

Mount targets: maak er één aan in elke AZ van de VPC om toegangspaden en beschikbaarheid binnen de AZ te garanderen. Security groups op mount targets beheren het NFS-verkeer; gebruik de EFS mount helper voor TLS-in-transit en IAM-autorisatie indien nodig.
Access points: dwing een rootdirectory en POSIX-identiteit (UID/GID) af voor applicaties, wat multi-tenant isolatie en eenvoudige ’least-privilege’ mounting door ECS/EKS/EC2 mogelijk maakt zonder het OS-gebruikersbeheer te hoeven coördineren.
Lifecycle management en storage classes: EFS Standard en Standard-IA (Regional, multi-AZ) en One Zone/One Zone-IA (single-AZ). Intelligent tiering verplaatst bestanden automatisch tussen de standard- en IA-klassen op basis van de laatste toegangstijd; je kunt ook expliciete overgangsbeleidsregels instellen. Kies One Zone-varianten voor hercreëerbare of niet-kritieke data om kosten te besparen. Combineer met AWS Backup voor gecentraliseerd beleid en back-ups tussen accounts/Regions.

Datamigratie: DMS, Snowball en DataSync

AWS Database Migration Service (DMS): online migratie met minimale downtime via een volledige laadcyclus plus change data capture (CDC). Ondersteunt homogene en heterogene migraties via ingebouwde schemaconversie (met de AWS Schema Conversion Tool voor complexe conversies). Gebruik voor lift-and-shift naar RDS/Aurora, naar DynamoDB (via JSON-mapping), of voor doorlopende replicatie voor read offloading of gefaseerde cutovers. Dimensionneer replicatie-instances voor piekveranderingssnelheden; zorg ervoor dat bronlogboeken (bijv. binlog/redo) voldoende historie bewaren.
AWS Snowball (Edge Storage/Compute Optimized): offline gegevensoverdracht op petabyteschaal wanneer netwerken beperkt/duur zijn of wanneer u snel enorme S3/EFS-datasets moet ‘seeden’. Koppel meerdere apparaten voor ladingen van meerdere petabytes. Gebruik voor initiële bulkladingen, verzameling op remote/edge-locaties, of migratie vanuit datacenters met beperkingen. Data wordt end-to-end versleuteld met KMS; apparaattracking en fraudebestendige verzegelingen ondersteunen de chain of custody.
AWS DataSync: online, versnelde overdracht voor NFS/SMB naar S3/EFS/FSx en tussen AWS-opslagservices/Regio’s. Het verzorgt incrementele wijzigingsdetectie, parallellisatie, compressie, bandbreedtebeheer, planning en integriteitscontroles. Gebruik om terugkerende delta’s en hybride workflows te verplaatsen, en om aangepaste rsync-scripts te vervangen door beheerde automatisering. Implementeer de DataSync-agent on-premise om toegang te krijgen tot lokale opslag.

Praktisch Probleemscenario

Shopify moet zijn wereldwijde pipeline voor productmedia en catalogusdata moderniseren, en tegelijkertijd de veerkracht en latency voor kopers wereldwijd verbeteren. Het bedrijf moet: productafbeeldingen repliceren over Regio’s en accounts met een strikte RPO, de leeslatentie van DynamoDB in Noord-Amerika en Europa verminderen, on-premise NFS-assets met doorlopende delta’s migreren, en RDS-operaties vereenvoudigen met betrouwbare back-ups.

Implementeer S3 CRR met Replication Time Control van de primaire mediabucket in us-east-1 (merchandising-account) naar een doelbucket in eu-west-1 (delivery-account).

Waarom: CRR voldoet aan de scheiding tussen Regio’s en accounts voor ’least privilege’ en datasoevereiniteit. RTC biedt een replicatie-SLA van 15 minuten en monitoring voor een RPO die aan compliance-eisen voldoet. Een cross-account bucket policy zorgt ervoor dat de bronreplicatierol kan schrijven, en het specificeren van een doel-KMS-sleutel handhaaft de encryptiedomeinen.

Definieer S3-replicatieregels gefilterd op prefix en tag om originelen, thumbnails en logs te scheiden, en schakel replicatie van ‘delete markers’ in. Gebruik S3 Batch Replication om legacy-objecten aan te vullen.

Waarom: Het afbakenen van regels voorkomt onnodige replicatiekosten, en de replicatie van ‘delete markers’ houdt Regio’s semantisch consistent. Batch Replication dicht historische hiaten zonder op maat gemaakte scripts.

Converteer de productcatalogus en voorraad naar een DynamoDB global table verspreid over us-east-1 en eu-west-1; schakel de tabellen over naar on-demand capaciteit en voeg DAX-clusters per Regio toe voor lees-intensieve API’s.

Waarom: Global tables bieden active-active writes met lokale lees/schrijfacties met lage latency en continue replicatie. On-demand elimineert het risico van capaciteitsplanning tijdens verkeerspieken. DAX verlaagt P99-latencies voor ‘hot reads’ en beschermt DynamoDB tegen piekbelasting.

Replatform de relationele workload voor bestellingen naar Amazon Aurora MySQL met writer- en reader-endpoints; voeg een kleine Aurora Serverless v2-reader toe voor piekbelastingen door analyses en schakel geautomatiseerde back-ups in met een bewaartermijn van 14 dagen.

Waarom: Cluster/reader-endpoints ontkoppelen lees- en schrijfacties en minimaliseren verstoring tijdens onderhoud of failover. Serverless v2 vangt onvoorspelbare analytische pieken kosteneffectief op. Geautomatiseerde back-ups leveren PITR en vereenvoudigde herstelprocessen.

Introduceer ElastiCache for Redis (cluster mode ingeschakeld) voor sessieopslag en caching van productbeschikbaarheid met Multi-AZ en snapshot-back-ups; stel TTL’s in die zijn afgestemd op de zakelijke SLA’s.

Waarom: Redis-datastructuren en Multi-AZ failover zorgen voor snelle, stateful sessies en near-real-time cache-invalidatie. De cluster mode schaalt horizontaal naarmate de catalogusgrootte en het verkeer toenemen.

Creëer een EFS Regional-bestandssysteem met mount targets in elke applicatie-AZ en Access Points voor workloads die gedeelde POSIX-opslag vereisen (bijv. mediaprocessors). Schakel EFS lifecycle-transities naar IA in na 30 dagen.

Waarom: EFS biedt elastische, multi-AZ gedeelde opslag; Access Points dwingen per-applicatie-isolatie en POSIX-identiteiten af. Lifecycle management verlaagt automatisch de kosten voor ‘koude’ assets die toegankelijk blijven.

Migreer on-premise NFS-mediabibliotheken met AWS DataSync via geplande taken voor nachtelijke incrementele synchronisaties naar S3 en EFS.

Waarom: DataSync beheert wijzigingsdetectie, parallellisme, integriteitsverificatie en bandbreedtecontrole beter dan ad-hoc rsync, en automatiseert doorlopende delta’s met minimale operationele inspanning.

Verplaats de legacy PostgreSQL-catalogus naar Aurora met AWS DMS (volledige laadcyclus plus CDC) en de AWS Schema Conversion Tool waar nodig; voer de cutover uit nadat de CDC-vertraging is weggewerkt.

Waarom: DMS maakt een migratie met nagenoeg geen downtime mogelijk, waarbij continue replicatie zorgt voor datapariteit op het moment van de cutover. SCT handelt engine-specifieke conversies af.

Seed historische media van meerdere petabytes naar S3 met Snowball Edge-apparaten, en schakel vervolgens over naar DataSync voor doorlopende incrementele updates.

Waarom: Snowball versnelt de initiële bulkoverdracht zonder WAN-verbindingen te overbelasten; DataSync onderhoudt continue updates na het ‘seeden’ met verificatie en planning.

Deze architectuur verlaagt de wereldwijde leeslatencies, biedt voorspelbare RPO’s voor replicatie, vereenvoudigt relationele operaties en back-ups, centraliseert gedeelde opslag met toegangscontrole, en biedt een pragmatisch pad van offline bulkmigratie naar geautomatiseerde, incrementele dataverplaatsing.

← Gebeurtenisgestuurde architecturen en Automatisering · Alle domeinen · Netwerken en Contentlevering →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →