Amazon SAA-C03: Databases & Caching — Studiegids

By Laurynas Brazys · 18 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Onderdeel van de AWS SAA-C03 — Complete studiegids. Oefen met geverifieerde antwoorden in het Amazon-examencentrum, of doe getimede oefentests op ExamRoll.io.

Amazon RDS: Beheerde Relationele Engines

Amazon RDS biedt zes beheerde engines — MySQL, PostgreSQL, MariaDB, Oracle, SQL Server en Amazon Aurora (compatibel met MySQL en PostgreSQL) — waarbij patching, back-ups, replicatietopologie en failover worden geabstraheerd. De keuze van de engine bepaalt de licenties, de semantiek van back-ups en de beschikbaarheid van functies: Oracle en SQL Server kennen het onderscheid tussen BYOL en License Included, SQL Server ondersteunt tot vijf read replica’s via native replication, en voor Oracle read replica’s is Enterprise Edition met Active Data Guard vereist.

De twee RDS-functies die het meest worden ingezet voor beschikbaarheid en schaalbaarheid — en die ook het vaakst door elkaar worden gehaald — zijn Multi-AZ deployments en read replica’s. Ze zijn orthogonaal, complementair en niet onderling uitwisselbaar.

Multi-AZ richt een synchrone standby replica in een tweede Availability Zone in. Elke schrijfactie wordt zowel naar de primary als naar de standby gecommit voordat deze wordt bevestigd, wat een RPO van effectief nul en een RTO van 60–120 seconden oplevert tijdens een automatische failover. De standby accepteert geen verkeer — deze bestaat uitsluitend voor failover. Wanneer de primary uitvalt, een AZ is aangetast, of onderhoud een herstart vereist, schakelt RDS de DNS CNAME om naar de standby en maken applicaties transparant opnieuw verbinding via hetzelfde endpoint. Multi-AZ is de oplossing die de minste inspanning kost voor een single point of failure in één AZ: het is een configuratie-instelling, vereist geen wijzigingen in het schema of de applicatie, en behoudt het endpoint. De nieuwere Multi-AZ cluster deployment is een topologie met drie nodes (één writer, twee leesbare standbys) die gebruikmaakt van semi-synchrone replicatie met een commit-latentie van ongeveer één seconde, wat HA plus beperkte read offload biedt.

Read replica’s gebruiken de native asynchrone replicatie van de engine (MySQL binlog, PostgreSQL WAL streaming). Ze zijn het juiste instrument voor het schalen van leesoperaties — analytische query’s, rapportagedashboards, ad-hoc SELECTs — die anders de OLTP op de primary zouden uitputten. Het klassieke scenario: een database voor orderverwerking die time-outs geeft omdat medewerkers langdurige maandeindrapporten draaien. Door een read replica toe te voegen en de rapportagetool naar diens endpoint te laten wijzen, wordt de analytische belasting geïsoleerd zonder de primary te hoeven opschalen. Read replica’s kunnen cross-region zijn en handmatig worden gepromoveerd tot zelfstandige databases, maar deze promotie is nooit automatisch en alle transacties die op het moment van de storing nog niet gerepliceerd waren, gaan verloren.

Twee valkuilen komen in dit domein vaak voor. Ten eerste is het behandelen van read replica’s als een HA-oplossing om meerdere redenen onjuist: replica’s zijn asynchroon (potentieel dataverlies), hebben geen automatische promotie, het endpoint verandert bij promotie, en in-flight transacties verdwijnen. Als een ontwerp “geen dataverlies” belooft en naar een read replica wijst als failover-doel, is die belofte onjuist. Ten tweede is het inrichten van Multi-AZ om leesverkeer te bedienen geldverspilling, omdat de standby in de standaardtopologie niet leesbaar is. Multi-AZ lost beschikbaarheid op; read replica’s lossen schaalbaarheid van leesoperaties op; vaak wil je beide.

Read replica’s doen ook niets voor het schalen van schrijfacties — elke schrijfactie raakt nog steeds de primary en de replica’s moeten deze herhalen. Voor het schalen van schrijfacties moet je sharden, overstappen op Aurora (ontkoppelde storage), of herontwerpen richting DynamoDB.

De Juiste Grootte Kiezen voor Read Replica’s

Een replica hoeft niet dezelfde instance class te hebben als de primary. De primary verwerkt de volledige schrijfbelasting plus leesoperaties; een replica verwerkt alleen de leesoperaties die naar hem worden gestuurd. Een db.r6i.4xlarge primary gekoppeld aan een db.r6i.large replica voor een nachtelijke rapportagetaak is volkomen redelijk — mits de replica de replicatie-I/O kan bijhouden. De methodologie is: meet de daadwerkelijke CPU, het geheugen en de replica lag van de replica, en bepaal vervolgens de grootte op basis van die workload. De enige kanttekening: als je van plan bent een replica te promoveren tot de nieuwe primary tijdens DR, moet deze groot genoeg zijn om de schrijfbelasting aan te kunnen. Ondermaatse replica’s zijn geen geschikte kandidaten voor promotie.

Blue/Green Deployments en Storage

RDS Blue/Green Deployments creëren een volledige staging-kopie van de productieomgeving (green) die synchroon blijft via logische replicatie. Je kunt de engine-versie upgraden, parametergroepen wijzigen of schema’s aanpassen op de green-omgeving, deze testen en in minder dan een minuut overschakelen met automatische hernoeming van het endpoint. Dit elimineert het klassieke risico van een in-place upgrade, waarbij een mislukte upgrade van een hoofdversie een rollback naar een snapshot forceert.

De keuze van storage is net zo belangrijk als de instance class voor schrijf-intensieve OLTP. De gp3/io2-taxonomie:

De verbetering van gp3 ten opzichte van gp2 is de ontkoppeling van IOPS en grootte — je hoeft niet langer capaciteit te overprovisioneren voor prestaties. Kies io2 wanneer de aanhoudende IOPS het plafond van gp3 overschrijden of wanneer 99,999% duurzaamheid vereist is. Met Multi-Attach kan één io2-volume aan maximaal 16 Nitro-instances worden gekoppeld, maar het bestandssysteem of de applicatie moet cluster-aware zijn; het is geen vervanging voor replicatie. Een latente valkuil voor uitval: het provisioneren van vaste opslag zonder dat storage autoscaling is ingeschakeld of zonder een CloudWatch-alarm op FreeStorageSpace. Wanneer de vrije ruimte nul bereikt, gaat RDS naar de status storage-full en weigert schrijfacties.

Amazon Aurora: Architectuur en Endpoints

Aurora herimplementeert de opslaglaag onder MySQL en PostgreSQL als een gedistribueerd, log-structured, zesvoudig gerepliceerd volume dat drie AZ’s omspant. Compute-nodes zijn stateless ten opzichte van de opslag, dus een Aurora Replica leest van hetzelfde onderliggende volume als de writer, in plaats van een log opnieuw af te spelen. Replicatielag is doorgaans 10–20 ms, vergeleken met seconden voor standaard RDS-replica’s, en een cluster ondersteunt tot 15 replica’s die in ongeveer 30 seconden tot writer gepromoveerd kunnen worden.

Aurora biedt vier soorten endpoints:

Custom endpoints zijn belangrijk wanneer replica’s heterogeen zijn. Als drie van de zes replica’s db.r6g.8xlarge zijn voor analytische rapportages, terwijl de rest OLTP-reads afhandelt, zal het algemene reader endpoint af en toe rapportages naar de kleinere nodes sturen, wat de voorspelbaarheid schaadt. Een custom endpoint dat alleen de grote replica’s omvat, biedt deterministische workload-isolatie:

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

Let op: de DNS TTL’s van Aurora-endpoints zijn 5 seconden; het langer cachen van connection strings ondermijnt het failover-gedrag.

Aurora Auto Scaling voegt readers toe en verwijdert ze op basis van doel-CPU- of verbindingsstatistieken, wat het standaardantwoord is voor onvoorspelbare, read-heavy workloads die hoog beschikbaar moeten blijven:

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

Wanneer RDS MySQL read replica’s de replicatielag tijdens piekuren niet onder één seconde kunnen houden, is het low-code antwoord om te migreren naar Aurora MySQL — de connection strings veranderen nauwelijks, en replicatie op opslagniveau elimineert de lag.

Aurora Serverless v2 en Klonen

Aurora Serverless v2 schaalt compute verticaal in fijnmazige Aurora Capacity Units (ACU’s, elk 2 GiB geheugen) in ongeveer een halve seconde, zonder sessies te verbreken. Het is geschikt voor variabele workloads met een bekende baseline geheugenvoetafdruk — bijvoorbeeld een on-prem MySQL-migratie die altijd minstens 2 GiB verbruikt. Stel min in op 1 ACU en max op 32 ACU’s, en het cluster schaalt flexibel zonder beheer. Provisioned Aurora blijft de voorkeur hebben wanneer de belasting stabiel en voorspelbaar is, aangezien Serverless v2 een meerprijs per ACU heeft.

Aurora cloning creëert een nieuw cluster dat de storage pages van de bron deelt via copy-on-write. Klonen verschijnen binnen enkele seconden en kosten niets totdat de data uiteenloopt, wat ze ideaal maakt voor staging-omgevingen, risicovolle migraties, of om analisten een productie-kopie zwaar te laten belasten. Een snapshot restore herstelt de data fysiek en kan uren duren; klonen is de beste keuze als snelheid belangrijk is.

Aurora Global Database

Aurora Global Database breidt een cluster uit naar maximaal vijf secundaire Regions met behulp van een toegewijde replicatie-infrastructuur op opslagniveau — geen binlog shipping. De typische replicatielag is minder dan één seconde, de RPO is minder dan één seconde, en een managed failover promoveert een secundaire region in minder dan een minuut.

Twee cruciale semantische punten: secundaire regions zijn read-only tijdens normaal bedrijf, en Global Database is ontworpen voor low-RPO DR en low-latency remote reads, niet voor active-active multi-master. Aannemen dat een global DB ‘automatisch writes in de secundaire region afhandelt’ is onjuist — writes daar vereisen een expliciete managed failover of een detach-and-promote. Voor een gestelde eis van 5 minuten RPO / 20 minuten RTO over regions heen met minimale operationele overhead, is Global Database het standaardantwoord.

RDS Proxy en Connection Management

Serverless en zeer concurrente workloads verergeren een klassiek probleem: connection storms. Een Lambda-functie die schaalt naar 3.000 concurrente uitvoeringen opent 3.000 sockets, waardoor de max_connections-limiet wordt overschreden en kettingreacties van storingen ontstaan — precies op het moment dat het systeem onder zware belasting staat. Pools binnen de functie helpen niet, omdat elke concurrente uitvoeringsomgeving geïsoleerd is.

RDS Proxy bevindt zich tussen clients en de database, onderhoudt een ‘warme’ pool van verbindingen en multiplexeert clientsessies hierop. Het lost twee problemen op:

1. Connection storms. Duizenden clientsessies worden gemultiplexeerd op een kleine backend-pool.
2. Failover-tijd. De proxy houdt clientverbindingen open terwijl de backend-link wordt hersteld, wat de waargenomen failover-tijd met tot wel 66% verkort en de noodzaak voor client-side TCP/TLS-herverbinding en DNS-herresolutie elimineert.

Het integreert met IAM en Secrets Manager voor het beheer van credentials, waardoor hardgecodeerde secrets uit de applicatiecode worden verwijderd.

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

Applicaties maken verbinding met het proxy-endpoint, niet met het cluster-endpoint. Elke Lambda-naar-RDS of high-fan-out architectuur zou RDS Proxy moeten gebruiken, tenzij er een specifieke reden is om dit niet te doen. Het draaien van je eigen pooler (PgBouncer, ProxySQL) op EC2 is mogelijk, maar voegt de operationele overhead toe die de proxy juist beoogt te elimineren.

DynamoDB: Capaciteitsmodi

DynamoDB is een beheerde key-value/document store met een latentie van enkele milliseconden op elke schaal, horizontaal gepartitioneerd op basis van een hash key. Het biedt twee capaciteitsmodi:

On-demand is aanzienlijk eenvoudiger, maar kost ongeveer 6-7× meer per request dan goed benutte provisioned capaciteit. Voor een nachtelijke batch van 4 uur met 500 WCU betaal je met on-demand aanzienlijk te veel — provisioned met scheduled scaling of reserved capacity is veel goedkoper. Omgekeerd leidt het gebruik van provisioned voor een onvoorspelbare workload bij een publieke lancering tot throttling. Voor stabiele workloads met gematigde variatie is provisioned met target-tracking auto-scaling rond 70% gebruik aanzienlijk goedkoper dan on-demand — vaak met 50-70%:

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

Je kunt één keer per 24 uur van modus wisselen. Aannemen dat on-demand universeel goedkoper is, is een dure fout; net als aannemen dat provisioned altijd de juiste keuze is voor piekverkeer.

DynamoDB: Consistentie, Streams, Global Tables

Reads zijn standaard eventually consistent (kunnen binnen ~1 seconde verouderde data retourneren, kost 0.5 RCU). Het instellen van ConsistentRead=true retourneert de laatst gecommitte waarde tegen dubbele kosten. Strongly consistent reads worden niet ondersteund via global secondary indexes of via DAX — die paden retourneren altijd eventually consistent data.

DynamoDB Streams leggen wijzigingen op itemniveau vast als een geordende log die 24 uur wordt bewaard. Dit triggert Lambda voor downstream verwerking (zoekindexering, notificaties, denormalisatie tussen tabellen) zonder te hoeven pollen.

Global Tables bouwen voort op Streams om multi-actieve, multi-Region replicatie te bieden met ’last-writer-wins’ conflictoplossing. Ze zijn de juiste oplossing wanneer reads en writes in meerdere Regions lokaal moeten zijn. Maar ze verdubbelen ongeveer de opslag- en schijfkosten — elke write is een WCU in elke replica-Region — en verzwakken de consistentie tussen de Regions. De valkuil is het inschakelen van Global Tables wanneer één enkele Region voldoet aan de beschikbaarheidseisen: DynamoDB in één Region wordt al gerepliceerd over drie AZs met 99,99% beschikbaarheid. Kosteneffectieve single-Region HA is een single-Region tabel met PITR ingeschakeld en, indien gewenst, provisioned capaciteit met auto-scaling.

Point-in-Time Recovery (PITR) biedt continue back-ups met een herstelgranulariteit per seconde voor de laatste 35 dagen tegen verwaarloosbare overhead. Schakel dit in op elke productietabel — het voldoet aan typische RPO-eisen van minuten in plaats van uren. Voor langere retentie (wettelijke bewaarplicht), integreer AWS Backup voor geplande, lifecycle-beheerde back-ups die naar andere regions gekopieerd kunnen worden.

TTL laat je een attribuut specificeren dat een Unix epoch vervaldatum bevat; DynamoDB verwijdert verlopen items asynchroon zonder kosten, ideaal voor sessie-opslag, tijdelijke tokens of event caches. TTL-verwijderingen gaan via Streams voor downstream archivering:

TTLSpecification:
  AttributeName: expireAt
  Enabled: true

Voor analytics produceert export to S3 een point-in-time snapshot die leesbaar is door Athena, Redshift Spectrum of EMR zonder tabelcapaciteit te verbruiken — een veel beter patroon dan het scannen van de tabel.

DAX: DynamoDB Accelerator

DAX is een volledig beheerde, in-memory, write-through cache specifiek voor DynamoDB, die een read-latentie van microseconden levert vergeleken met de basislijn van enkele milliseconden van DynamoDB. Het onderscheidende kenmerk is API-compatibiliteit: de DAX-client is een drop-in vervanging voor de DynamoDB SDK-client, waardoor applicaties het kunnen adopteren door de endpoint-configuratie te wijzigen in plaats van de query-logica te herschrijven:

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 onderhoudt twee caches: een item cache voor GetItem/BatchGetItem-resultaten en een query cache voor Query/Scan-resultaten. Writes zijn write-through — DAX fungeert als proxy naar DynamoDB en werkt zijn item cache bij na een succesvolle schrijfactie — maar de query cache is afhankelijk van TTL, waardoor query-resultaten verouderd kunnen raken, zelfs voor recent geschreven items.

Twee beperkingen zijn van belang. Ten eerste versnelt DAX alleen eventually consistent reads; strongly consistent reads omzeilen de cache. Ten tweede, andere schrijvers die DAX omzeilen, veroorzaken verouderde data (staleness). Voor een productdetailpagina die miljoenen keren per dag wordt bezocht, is DAX de accelerator met de minste operationele overhead — geen code voor cache-invalidatie, geen apart clusterbeheer. ElastiCache voor DynamoDB zou werken, maar vereist cache-aside logica die DAX overbodig maakt.

ElastiCache: Redis en Memcached

ElastiCache levert in-memory datatoegang met een latentie van minder dan een milliseconde als een beheerde service die Redis of Memcached draait. De keuze van de engine is afhankelijk van de features:

• Memcached — pure multi-threaded key/value-cache met horizontale sharding, geen persistentie, geen replicatie, geen pub/sub. Alleen te gebruiken voor kortstondige caching waarbij het verlies van de volledige cache acceptabel is.
• Redis — ondersteunt replicatie, Multi-AZ met automatische failover, clustermodus voor sharding, persistentie, pub/sub, gesorteerde sets, transacties en versleuteling ‘in transit’ en ‘at rest’. Vereist voor alles wat duurzaam moet zijn of complexe datatypen nodig heeft.

Twee canonieke patronen domineren.

Gecentraliseerde sessieopslag. Wanneer een ALB verkeer verdeelt over stateless EC2- of ECS-instances, dwingt lokale sessieopslag ‘sticky sessions’ af, wat de load ongelijk verdeelt en problemen veroorzaakt bij scale-in, deployments en AZ-storingen. Door sessies naar Redis te externaliseren, kan elke instance elk verzoek afhandelen en overleven sessies een hoststoring:

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))

Lees-offload voor kostbare query’s — leaderboards (Redis sorted sets via ZADD/ZREVRANGE), catalogus-lookups, aggregaties. Cachingstrategieën moeten aansluiten bij de consistentievereisten:

• Lazy loading (cache-aside): de applicatie leest de cache; bij een ‘miss’ leest het de DB en vult de cache met een TTL. Eenvoudig, maar ‘cold misses’ zijn pijnlijk en data kan verouderd zijn.
• Write-through: de applicatie schrijft naar de cache en de DB in dezelfde operatie. De cache blijft actueel, maar schrijfacties zijn trager en ongebruikte data neemt nog steeds geheugen in beslag.
• Write-back (write-behind): schrijfacties gaan eerst naar de cache en worden asynchroon naar de DB weggeschreven. Snelste schrijfacties, maar bij een cachestoring gaat data 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))

Vertrouwen op een cachinglaag zonder een invalidatiestrategie — TTL, expliciete DEL bij een update, of write-through — leidt tot het lezen van verouderde data (‘stale reads’). De storingsmodus is stil: de applicatie lijkt correct te werken totdat gebruikers afwijkingen opmerken. Caching is ook vaak de goedkoopste manier om leesoperaties op te schalen voorbij wat read replica’s comfortabel kunnen ondersteunen en beschermt de primaire database tijdens verkeerspieken.

In tegenstelling tot DAX is ElastiCache engine-agnostisch — je bent zelf verantwoordelijk voor de invalidatielogica — wat de reden is dat DAX wint op het gebied van operationele eenvoud wanneer de onderliggende opslag DynamoDB is.

Migratie: DMS en SCT

AWS Database Migration Service (DMS) repliceert data tussen homogene engines (Oracle→Oracle, MySQL→Aurora MySQL) of heterogene engines (Oracle→Aurora PostgreSQL, SQL Server→RDS MySQL, on-prem→DynamoDB). Een DMS-taak heeft drie fasen:

1. Full load — bulksgewijs kopiëren van bestaande rijen.
2. CDC (change data capture) — het transactielogboek van de bron volgen en doorlopende wijzigingen toepassen.
3. Full load + CDC — het gebruikelijke patroon voor minimale downtime: de bron blijft online, DMS houdt het doel synchroon, en de overstap is een korte DNS-switch.

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 elimineert de noodzaak om replicatie-instances te dimensioneren en te beheren — capaciteit wordt automatisch aan de workload aangepast, wat geschikt is voor variabele of langlopende CDC. Bron-engines moeten ‘supplemental logging’ (Oracle) of ‘ROW-format binary logging’ (MySQL) hebben ingeschakeld. Voor zeer grote initiële datasets integreert DMS met Snowball Edge voor offline-overdrachten.

DMS verplaatst data, niet het schema. Voor heterogene migraties combineer je het met de AWS Schema Conversion Tool (SCT), die stored procedures, views, triggers, sequences en dialect-specifieke typen converteert — bijvoorbeeld Oracle PL/SQL naar PostgreSQL PL/pgSQL, of T-SQL naar Aurora MySQL. SCT produceert een beoordelingsrapport dat objecten markeert die handmatige aanpassingen vereisen (doorgaans 5–20% voor complexe codebases). Alleen DMS gebruiken voor een cross-engine migratie is een veelgemaakte fout: hoewel DMS rudimentaire doeltabellen kan aanmaken, vertaalt het procedures of propriëtaire typen niet correct. Voor homogene migraties is SCT onnodig — native tools (mysqldump, pg_dump, RMAN) plus DMS CDC volstaan.

Het volledige cross-engine patroon:

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

Back-ups en Point-in-Time Recovery

Geautomatiseerde RDS-back-ups combineren dagelijkse snapshots met back-ups van transactielogboeken om de 5 minuten, wat PITR mogelijk maakt tot op de seconde nauwkeurig binnen de retentieperiode (1–35 dagen, standaard 7). Een hersteloperatie creëert een nieuwe instance — je kunt niet ‘in place’ herstellen — dus applicatie-endpoints of CNAMEs moeten worden bijgewerkt. Handmatige snapshots blijven bestaan na de retentieperiode en overleven het verwijderen van een instance (afhankelijk van de instelling voor de laatste snapshot), kunnen voor DR naar een andere regio worden gekopieerd en kunnen met andere accounts worden gedeeld.

Fast Snapshot Restore (FSR) voor op EBS gebaseerde snapshots elimineert de ’lazy-load’-vertraging, waardoor herstelde volumes onmiddellijk volledige prestaties leveren — handig wanneer onder tijdsdruk meerdere omgevingen vanuit één snapshot worden opgestart. Aurora cloning omzeilt snapshots volledig voor kopieën binnen dezelfde regio. DynamoDB PITR is een parallelle feature die per tabel moet worden ingeschakeld en bij herstel een nieuwe tabel produceert.

Purpose-Built Databases

Het selecteren van een ‘purpose-built’ engine wanneer toegangspatronen dit vereisen, voorkomt dure herarchitectuur. Amazon Neptune is een beheerde graafdatabase die Gremlin, openCypher en SPARQL ondersteunt — geschikt wanneer query’s relaties doorkruisen (frauderingen, sociale grafieken, kennisgrafieken) waar recursieve joins in een relationele engine onbetaalbaar duur zouden zijn. Amazon QLDB is een onveranderlijk, cryptografisch verifieerbaar ledger met een ‘append-only’ journaal, geschikt voor ‘systems of record’ die een fraudebestendige audit vereisen — herkomst van de toeleveringsketen, financiële transacties, voertuigregistraties. DynamoDB is de standaard voor key-value- of documenttoegang op elke schaal met een latentie van enkele milliseconden, met gebruik van patronen zoals ‘single-table design’, samengestelde sorteersleutels voor hiërarchische toegang en GSI’s voor alternatieve toegangspaden. Het forceren van deze workloads in RDS creëert ’lock contention’ (ledger-schrijfacties), querycomplexiteit (graaf-traversal) of schaalbaarheidsplafonds (high-throughput key-value) — elk veel kostbaarder om later te verhelpen dan de juiste keuze te maken tijdens het ontwerp.

Samenvatting van valkuilen

• Read replica’s als HA. Asynchroon, geen automatische promotie, endpoint verandert bij promotie, transacties ‘in-flight’ gaan verloren. Multi-AZ is het antwoord voor HA.
• Multi-AZ voor leesschaling. De standby is niet leesbaar in standaard RDS Multi-AZ. Gebruik read replica’s of Aurora replica’s.
• Single-AZ in productie. Geen failover-doel; verliest beschikbaarheid bij elk AZ-incident of herstart van de instance. Multi-AZ kost ongeveer 2x zoveel voor een kwalitatieve sprong in beschikbaarheid.
• Replica standaard even groot als de primary. Replica’s hebben vaak veel minder nodig; dimensioneer op basis van de gemeten workload, tenzij de replica een promotie-doel is.
• On-demand DynamoDB is altijd goedkoper. De kosten per request zijn ongeveer 6-7x hoger; provisioned + auto-scaling is voordeliger voor stabiele workloads.
• Global Tables voor single-region behoeften. Verdubbelt de kosten en verzwakt de consistentie zonder voordeel, tenzij nabijheid van gebruikers in meerdere regio’s of DR vereist is.
• Aurora Global Database secondaries verwerken schrijfacties. Ze zijn read-only totdat een beheerde failover ze promoveert.
• Lambda → RDS zonder RDS Proxy. Een ‘connection storm’ put max_connections uit; pools binnen de functie helpen niet over verschillende ‘concurrent execution environments’ heen.
• DMS alleen voor heterogene migratie. Verplaatst data, niet het schema. Combineer met SCT.
• Vaste RDS-opslag zonder autoscaling of FreeStorageSpace-alarmen. Latente storing — de storage-full-status weigert schrijfacties.
• Caching zonder invalidatiestrategie. Stilzwijgende veroudering van data. TTLs, write-through of expliciete invalidatie zijn niet-onderhandelbaar.
• Strongly consistent reads via DAX of GSI’s. Beide paden leveren alleen ’eventually consistent’ data.

← Contentlevering · Alle domeinen · Analytics →

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

Blader door Amazon →