Amazon SAA-C03: Hoge beschikbaarheid, Fouttolerantie & Disaster Recovery — 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.

Multi-AZ-implementaties en replicatie

Multi-AZ-architecturen zijn bedoeld voor het opvangen van een storing in één datacenter of Availability Zone — niets meer. Dit onderscheid is het meest onbegrepen punt in high-availability-ontwerp. Een Multi-AZ-implementatie tolereert het verlies van een AZ binnen één Regio; het tolereert niet een storing in een hele Regio, een regionale service-onderbreking, of het per ongeluk verwijderen van een resource, waarbij de verwijdering onmiddellijk wordt gerepliceerd naar de standby. Replicatie propageert trouw foute data — logische corruptie, schemafouten, ransomware-writes — en daarom zijn replicatie en back-up complementair, geen vervanging voor elkaar.

Voor Amazon RDS provisioneert Multi-AZ een synchrone stand-by replica in een andere AZ. Writes worden op beide instances doorgevoerd (commit) voordat ze worden bevestigd (acknowledgment), wat een RPO van effectief nul oplevert en een RTO van doorgaans 60-120 seconden tijdens een automatische failover. In de klassieke Multi-AZ instance-implementatie is de stand-by niet leesbaar — deze bestaat puur voor duurzaamheid en failover. Multi-AZ cluster-implementaties (twee leesbare stand-by’s) verkorten de failover-tijd verder en bieden enige leesschaling, maar blijven beperkt tot één Regio.

Voeg voor leesschaling read replica’s toe. Read replica’s gebruiken asynchrone replicatie en zijn bedoeld om rapportage-, analyse- en dashboard-query’s te offloaden. Een read replica beschouwen als een HA-failovermechanisme is om drie redenen onjuist: de replicatie is asynchroon (dataverlies bij promotie), de promotie is handmatig of gescript (niet automatisch), en het primaire endpoint wordt niet behouden. Wanneer een groeiende workload meer leescapaciteit nodig heeft zonder nieuwe complexiteit, voeg dan een read replica toe; wanneer de eis automatische failover met nul dataverlies is, gebruik dan Multi-AZ. Wanneer RPO/RTO een Regio-storing moet overleven voor een relationele engine, biedt Aurora Global Database een cross-region replicatievertraging van minder dan een seconde en een beheerde failover-RTO van minder dan een minuut.

Amazon ElastiCache volgt hetzelfde patroon met replicatiegroepen. Een Redis-replicatiegroep met Multi-AZ ingeschakeld onderhoudt een primaire en een of meer replica’s verspreid over AZ’s; als de primaire uitvalt, promoveert ElastiCache een replica en werkt het primaire endpoint bij. Voor horizontale schaalvergroting partitioneert Redis (met cluster mode ingeschakeld) data over shards, waarbij elke shard zijn eigen replicatiegroep is. Memcached daarentegen repliceert niet — verlies van een node betekent dataverlies voor die partitie.

Amazon FSx biedt Multi-AZ-implementatietypes voor FSx for Windows File Server en FSx for ONTAP, waarbij synchrone replicatie wordt gebruikt tussen een ‘preferred’ en een ‘standby’ file server. FSx for Lustre is over het algemeen single-AZ (scratch of persistent); duurzaamheid voor Lustre komt van S3 data repository-koppelingen, niet van AZ-replicatie.

# RDS Multi-AZ with cross-Region read replica for DR
DBInstance:
  Type: AWS::RDS::DBInstance
  Properties:
    Engine: sqlserver-ee
    MultiAZ: true              # AZ-level HA (synchronous)
    BackupRetentionPeriod: 35
    CopyTagsToSnapshot: true
    DeletionProtection: true

Geautomatiseerde RDS-back-ups en Point-in-Time Recovery

Geautomatiseerde RDS-back-ups combineren een dagelijkse snapshot met continue uploads van transactielogboeken naar S3 (elke 5 minuten), wat point-in-time recovery (PITR) mogelijk maakt naar elke seconde binnen de bewaarperiode van 1-35 dagen. Als je RPO 2 uur is, dekken de native back-ups van RDS dit al — er is geen extra snapshot-planning nodig, en het toevoegen van een laag AWS Backup is overbodig, tenzij je cross-region kopieën, cross-account isolatie of Vault Lock-semantiek nodig hebt die verder gaan dan wat de RDS snapshot-kopieerfunctie biedt. De standaard geautomatiseerde back-up is vaak het goedkoopste juiste antwoord op bescheiden RPO-vereisten.

AWS Backup als het gecentraliseerde controlepaneel

AWS Backup is het beleidsgestuurde controlepaneel voor back-ups van onder andere EBS, EC2 (als AMI’s), RDS, Aurora, DynamoDB, EFS, FSx, Storage Gateway en S3. In plaats van service-specifieke snapshot-logica te scripten, definieer je back-upplannen die regels groeperen die frequentie, back-upvenster, start-/voltooiingsvensters, lifecycle-transities naar cold storage, retentie en doel-vaults beschrijven. Resources worden toegevoegd via resource-toewijzingen op basis van tag of ARN, zodat een tagging-conventie zoals Backup=Daily het operationele contract wordt dat de dekking regelt. Voor vloten van honderden EC2-instances is selectie op basis van tags de aanpak die de minste inspanning vergt — pas de tag toe en laat AWS Backup de opsomming doen, in plaats van schema’s per instance te moeten schrijven.

Een back-upvault is de met KMS versleutelde container waar herstelpunten worden bewaard. Toegang wordt beheerd door resource-beleidsregels op de vault.

BackupPlan:
  BackupPlanName: tier1-daily
  Rules:
    - RuleName: daily-35day
      TargetBackupVault: vault-locked-compliance
      ScheduleExpression: cron(0 5 ? * * *)
      StartWindowMinutes: 60
      CompletionWindowMinutes: 180
      Lifecycle:
        MoveToColdStorageAfterDays: 30
        DeleteAfterDays: 365
      CopyActions:
        - DestinationBackupVaultArn: arn:aws:backup:us-west-2:111122223333:backup-vault:dr-vault
          Lifecycle: { DeleteAfterDays: 365 }

Cross-region en cross-account kopieën

Het CopyActions-blok is het mechanisme voor cross-region DR-kopieën. AWS Backup handelt de snapshot-kopie af, herversleutelt met een KMS-sleutel in de doelregio (de doel-vault moet verwijzen naar een sleutel in die Regio), en past een onafhankelijke lifecycle toe. EBS- en RDS-snapshots staan standaard in de bronregio — als de hele Regio is aangetast, geldt dat ook voor de snapshots. Elke regelgevende of zakelijke eis die regionale veerkracht vermeldt, moet een expliciete stap voor cross-region kopiëren bevatten, of dat nu via AWS Backup copy actions, de geautomatiseerde cross-region kopieerfunctie van RDS-snapshots, of DLM-beleid met cross-region bestemmingen is.

Voor cross-account kopieën delegeert AWS Organizations een beheerdersaccount voor AWS Backup; het beleid van de bron-vault staat het doelaccount toe, en de doel-vault staat kopieën van de bron toe. Dit is de kosteneffectieve manier om DR te centraliseren: één beheeraccount bewaart herstelpunten van vele workload-accounts en kan in beide Regio’s herstellen. Voor EC2 stelt een AMI-kopie naar een tweede Regio plus het delen van snapshots je in staat om daar instances te starten zonder warme infrastructuur. Versleutelde snapshots vereisen het delen van de CMK — het doelaccount of de doelregio heeft kms:CreateGrant en toegang tot de sleutel nodig. Het ontbreken hiervan is de reden waarom cross-account restores stilzwijgend mislukken.

Een RPO van 24 uur wordt goedkoop gerealiseerd door een dagelijkse geautomatiseerde snapshot die cross-region wordt gekopieerd — veel minder kostbaar dan een cross-region read replica of een warm standby-cluster. Stap alleen over op continue replicatie als de RPO lager moet zijn dan wat de snapshot-cadans kan leveren.

AMI-levenscyclus en EC2-back-ups

Twee mechanismen automatiseren EC2-back-ups: Data Lifecycle Manager (DLM) en AWS Backup. DLM is ouder dan AWS Backup en creëert op beleid gebaseerde EBS-snapshots of AMI’s volgens een schema, met kopieeracties over Regio’s en accounts heen. AWS Backup omvat dit en voegt centraal beleid, Vault Lock en een multi-service scope toe. Geef de voorkeur aan AWS Backup als je het al gebruikt voor andere services; gebruik DLM voor pure EBS/AMI-scenario’s waar je geen vault-functies nodig hebt.

Voor stateless web-lagen achter een Auto Scaling group zonder persistente lokale data, is het back-uppen van draaiende EC2-instances verspilling. De juiste aanpak is om een ‘hardened’ AMI te ‘bakken’ (via EC2 Image Builder of een CI-pipeline), hiernaar te verwijzen in de launch template, en de ASG de vervanging van instances te laten afhandelen. De back-upinspanningen concentreren zich op de stateful lagen waarvan de native geautomatiseerde back-ups voldoen aan de RPO.

Onveranderlijkheid: Vault Lock en Object Lock

Een gewone snapshot in je account kan worden verwijderd door iedereen met de juiste IAM-permissie — snapshots alleen voldoen niet aan de eisen voor onveranderlijkheid. Regelgevende kaders (SEC 17a-4, FINRA, HIPAA, GDPR) vereisen vaak een write-once-read-many (WORM) retentie die zelfs beheerders niet kunnen omzeilen. Twee AWS-mechanismen bieden dit.

AWS Backup Vault Lock dwingt WORM af op een back-up vault:

In de compliance-modus kan geen enkele gebruiker — inclusief het root-account — de retentieperiode verkorten, herstelpunten vóór de vervaldatum verwijderen of de lock zelf verwijderen zodra de afkoelperiode is verstreken. Dit voorkomt zowel verwijdering door insiders als door een ransomware-operator die het account volledig heeft gecompromitteerd.

aws backup put-backup-vault-lock-configuration \
  --backup-vault-name ComplianceVault \
  --changeable-for-days 3 \
  --min-retention-days 2555 \
  --max-retention-days 2920

S3 Object Lock biedt WORM op objectniveau in Governance-modus (geprivilegieerde gebruikers met s3:BypassGovernanceRetention kunnen dit negeren) of Compliance-modus (niemand, inclusief root, kan de retentie verwijderen of verkorten). Legal Hold staat los van retentieperioden. Object Lock vereist versioning en moet bij het aanmaken van de bucket worden ingeschakeld voor volledige bescherming.

Capaciteitsreserveringen voor de Failover-regio

Een DR-plan dat ervan uitgaat dat de failover-regio EC2-capaciteit beschikbaar heeft op de dag van een grootschalig incident, is geen plan. Wanneer een regio uitvalt, voert iedereen tegelijk een failover uit, en kunnen instance types — vooral grote, GPU- of gespecialiseerde varianten — uitgeput raken. On-Demand Capacity Reservations (ODCRs) in de doelregio garanderen capaciteit voor een specifiek instance type, platform en AZ, en worden gefactureerd ongeacht of ze worden gebruikt. Combineer dit met een Savings Plan om de kosten te compenseren. Voor lange-termijn GPU/ML-verplichtingen zijn Capacity Blocks van toepassing; voor flexibiliteit binnen families dekt een Capacity Reservation Fleet meerdere instance families. Het principe is: als de business gegarandeerde compute vereist in de DR-regio, reserveer het dan — vertrouw niet op de ‘best-effort’ beschikbaarheid van On-Demand.

Selectie van DR-strategie

AWS onderscheidt vier canonieke DR-niveaus, elk met een eigen afweging tussen kosten en hersteltijd:

Het juiste niveau wordt bepaald door de RPO en RTO van de business — niet door architecturale voorkeur. Een RPO van 24 uur tolereert dagelijkse cross-region snapshot-kopieën (Backup & Restore). Een RPO van seconden vereist continue replicatie — cross-region read replica’s, Aurora Global Database, DynamoDB Global Tables of S3 Cross-Region Replication. Een RPO van 5 minuten proberen te bereiken met nachtelijke snapshots is architectonisch onmogelijk, ongeacht het budget. Omgekeerd is het standaard kiezen voor active-active voor elke workload een kosten-antipattern: het vereist wereldwijd consistente data (DynamoDB Global Tables of Aurora Global met write-forwarding), dubbele compute op volledige schaal, en complexe verkeerssturing via Route 53 of Global Accelerator. Kies het goedkoopste patroon dat voldoet aan de gestelde RPO/RTO — voor een RPO van 2 uur volstaan backup-and-restore of pilot light meestal, en is warm standby over-engineering.

Bescherming tegen verwijdering en gelaagde beveiliging

Veerkracht is niet alleen “hebben we back-ups” — het is “kan één enkele actor, fout of aanval ze uitwissen”. Gelaagde controles voorkomen de ‘één-verkeerde-klik’-catastrofe:

• RDS: schakel DeletionProtection in en vereis een definitieve snapshot bij verwijdering.
• EC2: schakel DisableApiTermination en DisableApiStop in op kritieke instances.
• DynamoDB: schakel ‘deletion protection’ en ‘point-in-time recovery’ in.
• S3: Versioning + MFA Delete + Object Lock voor onveranderlijkheid.
• CloudFormation: DeletionPolicy: Retain op stateful resources en ‘stack termination protection’.
• IAM SCP’s: weiger backup:DeleteRecoveryPoint, backup:DeleteBackupVault, rds:DeleteDBInstance en ec2:DeleteSnapshot buiten ‘break-glass’-rollen.

aws rds modify-db-instance \
  --db-instance-identifier prod-pg \
  --deletion-protection \
  --backup-retention-period 35 \
  --apply-immediately

Gecombineerd met Vault Lock in compliance-modus, creëren deze een ‘defense in depth’: zelfs een gecompromitteerd beheerdersaccount kan de ’last-line-of-defense’ herstelpunten niet vernietigen.

Veelvoorkomende Valkuilen

Multi-AZ als DR beschouwen. RDS Multi-AZ, ElastiCache Multi-AZ en FSx Multi-AZ bevinden zich allemaal binnen één Region. Een storing van de regionale API, een per ongeluk verwijderde tabel of een verkeerd toegepaste schemamigratie treft beide nodes. Elke vereiste die “een andere Region”, “regionale storing” of “cross-Region RPO” vermeldt, vereist cross-Region replicatie of kopie — Multi-AZ alleen voldoet niet aan de vereiste.

Read replicas verwarren met HA. Read replicas zijn asynchroon, moeten handmatig worden gepromoveerd en hebben een ander endpoint. Ze lossen read scaling op, niet automatische failover.

Ervan uitgaan dat snapshots gelijkstaan aan compliance. Snapshots zonder Vault Lock (compliance mode) of Object Lock kunnen worden verwijderd door elke principal met de juiste IAM-permissie en door het root-account. WORM-retentie voor regelgeving vereist een expliciete onveranderbaarheidsconfiguratie (immutability) waarbij een vergrendelde afkoelperiode is verstreken.

Alleen lokale snapshots voor een regionale RPO. EBS- en RDS-snapshots worden standaard in de bron-Region opgeslagen. Regionale veerkracht (resilience) vereist een expliciete cross-Region kopieeractie.

Back-ups zonder geteste restores of gereserveerde capaciteit. Een snapshot die je nog nooit hebt hersteld, is een hypothese, geen back-up. Restore-oefeningen (drills) onthullen ontbrekende IAM-rollen, problemen met toegang tot KMS-sleutels in de doel-Region en het doelaccount, en niet-beschikbare instance types. Zonder Capacity Reservations voor kritieke workloads heeft de DR-Region mogelijk niet de ‘shape’ die je nodig hebt wanneer iedereen tegelijkertijd een failover uitvoert — en wordt de RTO onbegrensd.

Over-engineering naar active-active. Dubbele globale compute, wereldwijd consistente datareplicatie en complexe traffic steering zijn duur. Als de RPO/RTO dit niet rechtvaardigt, is een pilot light of warm standby de juiste architectuur.

Back-ups maken van stateless tiers. Het maken van snapshots van tijdelijke (ephemeral) webservers achter een ASG is geldverspilling en bemoeilijkt het herstel. ‘Bake’ AMI’s, verwijs ernaar in launch templates en concentreer de back-upinvesteringen op stateful data.

← Beheer · Alle domeinen

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

Blader door Amazon →