Amazon DOP-C02: Hoge beschikbaarheid, Veerkracht en Noodherstel — 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

Hoge beschikbaarheid en disaster recovery op AWS richten zich op het verminderen van downtime (RTO) en dataverlies (RPO) bij storingen van componenten, Availability Zones (AZ’s) of regio’s. Multi-AZ-ontwerpen vangen storingen van een AZ op zonder dataverlies en met minimale impact op de service; multi-regio-ontwerpen zijn gericht op regionale verstoringen en grootschalige gebeurtenissen. De keuze tussen active/active, active/passive (warm standby) en pilot-light-strategieën wordt bepaald door de RTO/RPO-doelstellingen van de business, consistentievereisten en kosten. Het bereiken van deze doelstellingen vereist een samenhangend ontwerp voor DNS-routing, elasticiteit van compute, load balancing, databasereplicatie/failover, duurzame object storage met replicatie/versiebeheer, gecentraliseerde back-up en continue verificatie van de veerkracht via fault injection.

Architecturen voor RTO/RPO en intelligente routing

Multi-AZ en multi-regio:

Multi-AZ: Plaats redundante instances in ten minste twee subnets in verschillende AZ’s achter een load balancer. Gebruik beheerde databases met synchrone replicatie (RDS Multi-AZ, Aurora Multi-AZ/cluster). De RPO is doorgaans nul voor synchrone opslag; RTO-doelstellingen variëren van minder dan een minuut (Aurora) tot enkele minuten (RDS Single-Instance Multi-AZ failover).
Multi-regio: Kies voor active/active voor de laagste RTO met regionale isolatie en lage latency, of voor warm standby/pilot light voor een kostengeoptimaliseerde DR. Datareplicatie moet voldoen aan de RPO: asynchrone DB-replica’s, Aurora Global Database (<1 s typische RPO), DynamoDB global tables (multi-regio, multi-actief) en S3 Cross-Region Replication (CRR) met optionele Replication Time Control (RTC) voor replicatie met SLA-garantie.

Route 53 routing policies en health checks:

Failover routing: Maak twee records aan voor dezelfde naam: Primary en Secondary. Koppel een health check aan de Primary (of gebruik “Evaluate Target Health” voor een alias naar een ALB/NLB). Bij een storing wordt het verkeer omgeleid naar de Secondary. Houd de TTL laag (bijv. 60 s) om vertraging door DNS-caching te verminderen, en monitor de status van de health check met CloudWatch Alarms.
Latency-based routing: Stuur gebruikers naar de regio met de laagst gemeten latency. Koppel health checks aan elk record om ervoor te zorgen dat alleen gezonde endpoints verkeer ontvangen. Combineer dit met multi-regio-stacks en regionale datastores die, indien nodig, eventual of strong consistency ondersteunen.
Weighted routing: Verdeel het verkeer procentueel ter ondersteuning van canary releases, A/B-testen of “trickle” DR-gereedheid (bijvoorbeeld continu 1% naar de secundaire omgeving). Combineer dit met health checks zodat ongezonde gewichten worden uitgesloten. Gebruik geleidelijk verschuivende gewichten om verkeer te migreren tijdens een regionale evacuatie.
Health checks: Controleer HTTP(S)/TCP-endpoints of CloudWatch Alarms. Voor ALB/NLB-aliassen, schakel “Evaluate Target Health” in om de status van de target group over te nemen. Ontwerp health-endpoints die de werkelijke gereedheid weerspiegelen (afhankelijkheden bereikbaar, migraties toegepast). Voor stateful applicaties, voeg controles van afhankelijkheden toe (database, cache) om te voorkomen dat verkeer naar gedeeltelijk gezonde instances wordt gestuurd.

Veerkrachtige patronen per doelstelling:

Lage RPO, RTO van minder dan een minuut wereldwijd: Active/active met Route 53 latency-based routing en health checks, regio-lokale stateless compute, DynamoDB global tables of Aurora Global Database, S3 CRR met RTC voor kritieke objecten.
Gemiddelde RPO (≤15 min), RTO ≤4 uur: Warm standby met een verkleinde secundaire omgeving, asynchrone DB-replica (RDS cross-region read replica of Aurora Global), Route 53 failover routing, runbooks of automatisering om op te schalen en te promoveren bij een failover.
Kostengeoptimaliseerde DR: Pilot light alleen voor kerndataservices, infrastructure-as-code om de applicatielaag op te schalen bij activering, RPO bepaald door de replicatiefrequentie, RTO door de provisioningtijd en het inhalen van data.

Elastic Load Balancing en Auto Scaling

Elastic Load Balancing:

Application Load Balancer (ALB): Laag 7, host/path-routing, WebSocket/HTTP/2, geïntegreerde WAF, stickiness via target group-cookies en request-gebaseerde health checks. Gebruik cross-zone load balancing en deregistration delay (connection draining) om targets geleidelijk (gracefully) te drainen tijdens scale-in of deployments. Configureer slow start en outlier detection voor een ongelijkmatige opwarming van de backend.
Network Load Balancer (NLB): Laag 4, extreem lage latency, statische IP’s/Elastic IP’s, TLS pass-through/termination, behoudt het bron-IP-adres en ondersteunt langdurige verbindingen. Gebruik voor TCP/UDP-protocollen, workloads met hoge doorvoersnelheid of waar zichtbaarheid van het client-IP verplicht is. Health checks zijn TCP/HTTP/HTTPS op Laag 4/7 zoals geconfigureerd.
Connection draining (deregistration delay): Stel een geschikte vertraging in (bijvoorbeeld 60–300 s) om ‘in-flight’ requests te laten voltooien. Zorg ervoor dat deployment- en Auto Scaling-terminatie-events deze vertraging respecteren om onderbreking voor de gebruiker te voorkomen.

Auto Scaling groups:

Schalingsbeleid (scaling policies):
- Target tracking scaling: Houd een metric (CPUUtilization, ALB RequestCountPerTarget) op een doelwaarde. Dit is het eenvoudigste en meest adaptieve beleid voor web/API-vloten.
- Step scaling: Schaal op basis van gedefinieerde stappen wanneer metrics drempelwaarden overschrijden. Nuttig voor piekverkeer (bursty traffic) met voorspelbare patronen.
- Scheduled scaling: Schaal vooraf op voor bekende gebeurtenissen (sales, launches) om ‘koude’ capaciteit te vermijden.
- Predictive scaling: Voorspel optioneel de vraag met behulp van ML voor dagelijkse/wekelijkse patronen.
Lifecycle hooks: Launching:Wait en Terminating:Wait maken het mogelijk om de gereedheid (readiness) en afbouw van instances te beheren. Gebruik hooks om:
- Instances te bootstrappen (SSM Automation, voltooiing van user data, AMI-hydratatie) voordat ze in service gaan.
- Logs en artefacten te verzamelen voorafgaand aan de terminatie voor root cause analysis.
- Blue/green- of in-place-deployments te coördineren die gereedheidssignalen (readiness signals) moeten bevestigen (bijv. cfn-signal).
Warm pools: Houd instances voorgeïnitialiseerd in de status Stopped of Running, gekoppeld aan de ASG, om de scale-out-latency drastisch te verlagen. Warm pools combineren goed met lange bootstrap-stappen (installatie van grote pakketten, downloaden van modellen). Configureer een minimale opgewarmde capaciteit en hergebruikbeleid. Combineer met de lifecycle hook Launching:Wait om de hook pas te voltooien wanneer de app readiness checks slagen, wat zorgt voor consistente overschakeltijden.
Instellingen voor veerkracht (resilience): Schakel Capacity Rebalance in voor Spot, meerdere instance types/allocaties, health checks gekoppeld aan de status van de target group, en instance refresh voor veilige rolling updates met ‘health guardrails’.

Veerkracht, replicatie en back-ups van de datalaag

Relationele databases:

RDS Multi-AZ: Synchrone replicatie naar een standby in een andere AZ; een geautomatiseerde failover werkt het DNS-eindpunt bij naar de standby. Dit beschermt tegen het uitvallen van een AZ of instance met een RPO ≈ 0 en een RTO van doorgaans enkele minuten voor Single-AZ DB instances met een Multi-AZ standby. Het nieuwere Multi-AZ DB cluster voor MySQL/PostgreSQL biedt snellere failover met meerdere leesbare standbys.
Read replicas: Asynchrone replicatie voor leesschaling (read scaling) en DR. Gebruik cross-Region read replicas voor DR; promotie is handmatig (of geautomatiseerd met runbooks/Serverless-functies) en leidt tot een RPO > 0. Zorg ervoor dat binlog of logische replicatie correct is geconfigureerd en dat de replicatievertraging (replication lag) wordt gemonitord.
Aurora: Aurora Multi-AZ (cluster) gebruikt gedeelde opslag (shared storage) met replica’s in meerdere AZ’s; failover duurt over het algemeen minder dan een minuut. Aurora Global Database biedt opslaggebaseerde fysieke replicatie naar secundaire Regions met een typische RPO < 1 s en RTO < 1 min. Gebruik ‘managed planned failover’ voor migraties zonder dataverlies, of ongeplande failover voor noodgevallen (disaster events). Writer/reader-eindpunten abstraheren de topologie; applicaties moeten een ‘retry with backoff’-mechanisme implementeren.

Object storage en DR:

S3 Versioning: Schakel versioning in om te beschermen tegen overschrijvingen/verwijderingen en om CRR te ondersteunen. Configureer lifecycle-beleid om oudere versies over te zetten naar goedkopere opslag en stel een geschikte retentieperiode in.
S3 Cross-Region Replication (CRR): Vereist versioning op de bron- en doelbucket. Gebruik een IAM-rol voor replicatie; als de buckets zich in verschillende accounts bevinden, voeg een bucket policy toe aan de doelbucket die de bronrol de permissies

undefined

en ‘put’ geeft. Voor met KMS versleutelde objecten, geef de rol

undefined

op de bronsleutel en

undefined

op de doelsleutel. Overweeg:

Replication Time Control (RTC) waarbij 99,9% van de objecten binnen 15 minuten wordt gerepliceerd, met metrics/alerts.
Replicatie van ‘delete markers’ en ‘ownership controls’ indien nodig.
S3 Batch Replication voor bestaande objecten.
Replicatiemetrics en -notificaties voor SLA’s.
DynamoDB: Gebruik global tables voor multi-Region/multi-writer, lage latency en HA. Schakel als alternatief PITR en on-demand back-ups in voor herstel.

Gecentraliseerde back-ups met AWS Backup:

Backup plans: Definieer schema’s (CRON), back-upvensters, lifecycle (transitie naar cold storage, retentie) en kopieeracties naar andere Regions/accounts. Wijs resources toe via tag of ARN voor beleidsgestuurde dekking.
Backup vaults: Logische containers met onafhankelijke KMS-encryptiesleutels en toegangsbeleid. Schakel AWS Backup Vault Lock in voor WORM-onveranderlijkheid (immutability) en een ransomware-bestendige houding. Gebruik cross-account vault-kopieën voor het verkleinen van de ‘blast radius’.
Cross-account backup: Pas in Organizations back-upbeleid toe op member-accounts voor consistente governance. Configureer het toegangsbeleid van de vault om kopiëren/herstellen vanuit een centraal back-upaccount toe te staan. Voer regelmatig geautomatiseerde hersteloefeningen (restore drills) uit om de RTO te meten en runbooks te valideren.
Integraties: Bescherm EBS, EC2, RDS/Aurora, DynamoDB, EFS, FSx en meer. Stem het schema en de retentie af op de wettelijke RPO/RTO, en coördineer met ‘application-consistent quiescing’ waar nodig (SSM pre/post-scripts).

Chaos engineering en AWS Fault Injection Simulator (FIS)

Chaos-experimenten valideren dat HA- en DR-mechanismen zich gedragen zoals ontworpen. AWS FIS orkestreert gecontroleerde fouten met vangrails (guardrails):

Experimentsjablonen (templates) definiëren acties (bijvoorbeeld het stoppen of herstarten van een percentage EC2-instances in een ASG, het injecteren van CPU- of geheugenstress via SSM, het toevoegen van netwerklatentie/pakketverlies op instances, het beëindigen van EKS-pods, het stoppen van ECS-taken, het triggeren van een RDS/Aurora-failover) en doelen (targets) (resource-tags, ARN’s).
Veiligheidscontroles: Specificeer stopcondities via CloudWatch-alarmen, tijdslimieten, beperkingen van de ‘blast radius’ via tags/filters, en pre-checks. Voer eerst uit in non-prod, daarna in productie met strikte vangrails en goedkeuring van de business.
Observeerbaarheid: Instrumenteer KPI’s (foutenpercentage, tail latency, wachtrijleeftijd, replica lag) en verifieer geautomatiseerde reacties, inclusief Auto Scaling-reacties, convergentie van de load balancer health, Route 53-failover, databasepromotie en het gedrag van circuit breakers.
Continue veerkracht: Integreer experimenten in pipelines/gamedays om te voorkomen dat configuratiedrift de veerkracht ondermijnt. Gebruik Parameter Store of AppConfig voor toggles en om veilige rollouts te coördineren.

Praktijkscenario

Expedia Group beheert een wereldwijde API voor het zoeken van reizen die een RTO van minder dan 60 seconden en een RPO van bijna nul moet bieden voor kritieke boekingsgegevens, terwijl de lage latentie voor gebruikers in Noord-Amerika en Europa behouden moet blijven. Het team ervaart af en toe regionale ‘brownouts’ en door implementaties veroorzaakte instabiliteit, en auditors vereisen onveranderlijke (immutable) cross-account back-ups en gedocumenteerde DR-oefeningen.

Stapsgewijze aanpak:

Opzetten van multi-Region, active/active stacks

Implementeer stateless API-stacks in us-east-1 en eu-west-1 over meerdere AZ’s achter ALB’s. Gebruik Route 53 latency-based routing met health checks en Evaluate Target Health op alias records. Dit levert low-latency routing en automatische regionale uitwijking (evasion) als een endpoint ongezond is.

Globale datastore met lage RPO

Migreer boekings- en sessiegegevens naar Amazon Aurora Global Database (MySQL-compatibel) met us-east-1 als primaire en eu-west-1 als secundaire regio. Een typische RPO <1 s en RTO <1 min voldoet aan de doelstelling voor storingen. Gebruik de cluster- en reader-endpoints in de applicatieconfiguratie met retry/backoff om failovers te tolereren.

Veerkrachtige schaling en soepele overgangen

Configureer Auto Scaling target tracking op ALB RequestCountPerTarget met een minimumcapaciteit in beide regio’s. Voeg warm pools toe die groot genoeg zijn om de 10x verkeerstoename tijdens grote evenementen op te vangen en lifecycle Launching:Wait hooks om registratie uit te stellen totdat de app readiness checks slagen. Schakel ALB deregistration delay van 120 seconden in om in-flight requests te behouden tijdens scale-in en implementaties.

Duurzame object-DR

Schakel S3 Versioning en CRR met RTC in voor reisdocumenten van us-east-1 naar eu-west-1. Gebruik een toegewijde replicatie IAM-rol en KMS-sleutels in beide regio’s, waarbij kms:Decrypt wordt verleend op de bron en kms:Encrypt op de bestemming. RTC-metrics en -alerts bieden vertrouwen in de replicatie-SLA’s.

DNS-controles voor canary en failover

Voeg gewogen (weighted) Route 53-records toe (1% constante stroom naar eu-west-1) om het secundaire pad continu te testen. In combinatie met health checks zorgt dit ervoor dat de standby-omgeving productieklaar is en drift wordt opgemerkt voordat een crisis zich voordoet.

Gecentraliseerde, onveranderlijke back-ups

Maak in een back-upaccount dat eigendom is van het security-team AWS Backup vaults aan met Vault Lock en KMS CMK’s. Definieer back-upbeleid op organisatieniveau om dagelijkse back-ups en cross-account kopieën voor RDS, DynamoDB, EFS en EBS in te plannen. Wijs resources toe op basis van de Backup_Frequency-tag. Dit zorgt voor weerstand tegen ransomware en scheiding van taken (separation of duties).

Geautomatiseerde failover-orkestratie

Implementeer een EventBridge-regel die signalen van een falende Aurora-primary detecteert en een Lambda-functie aanroept die de secundaire regio promoot en een applicatie-endpoint bijwerkt dat is opgeslagen in Parameter Store. Applicaties laden het endpoint bij het opstarten en verversen het bij verbindingsfouten, waardoor handmatige stappen worden geminimaliseerd.

Chaosvalidatie met AWS FIS

Maak FIS-experimentsjablonen om: 10% van de ASG-instances te beëindigen, 150 ms latentie en 1% pakketverlies te injecteren op EC2 via SSM, en een Aurora-failover te triggeren. Beveilig dit met stopcondities via CloudWatch-alarmen op p95-latentie en het foutenpercentage. Voer maandelijks gamedays uit om de snelheid van de Route 53-failover, het herstel van de ASG, de convergentie van de ALB-health en de RTO van de Aurora-promotie te valideren.

Waarom deze services:

Route 53 latency-based en weighted routing bieden zowel optimale gebruikerslatentie als gecontroleerde traffic shaping voor DR-gereedheid.
ALB plus ASG met warm pools en lifecycle hooks zorgen voor snelle, soepele schaling zonder cold-start-penalty’s of verstoring voor de gebruiker.
Aurora Global Database is uniek in het voldoen aan een RPO van bijna nul en een RTO van minder dan een minuut over regio’s heen, met minimale wijzigingen in de applicatie.
S3 Versioning en CRR met RTC leveren auditeerbare, door SLA ondersteunde replicatie voor kritieke artefacten.
AWS Backup met cross-account vaults en Vault Lock creëert onveranderlijke, centraal beheerde back-ups die voldoen aan compliance-eisen.
AWS FIS levert veilige, geautomatiseerde foutinjectie om continu de veerkracht te bewijzen en te voorkomen dat configuratiedrift het DR-plan ondermijnt.

← Containers en Serverless-operaties · Alle domeinen · Gebeurtenisgestuurde architecturen en Automatisering →

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