Amazon SAP-C02: Veerkracht, Disaster Recovery & Hoge Beschikbaarheid — Studiegids
Onderdeel van de AWS Solutions Architect Professional SAP-C02 — Studiegids. Oefen met geverifieerde antwoorden in het Amazon-examencentrum, of doe getimede oefentests op ExamRoll.io.
RTO- en RPO-planning: tolerantie kwantificeren en architectuur in kaart brengen
RTO (Recovery Time Objective) en RPO (Recovery Point Objective) zijn de drijvende kracht achter elke keuze op het gebied van veerkracht, van de dimensionering van compute tot de replicatietopologie. Begin met het classificeren van workloads op basis van bedrijfsimpact en de kosten van downtime, en vertaal die prioriteiten vervolgens naar meetbare doelstellingen: RPO’s van milliseconden vereisen synchrone replicatie of speciaal gebouwde wereldwijde databases, terwijl RPO’s van minuten tot uren asynchrone replicatie, snapshot-schema’s of gebundelde log shipping toestaan. Gebruik AWS-services die aansluiten bij de doelstellingen: Amazon Aurora Multi‑AZ en Aurora Global Database voor lage RTO/RPO op grote schaal, RDS Multi‑AZ voor synchrone high availability binnen één regio, cross-region read replica’s voor herstel en rapportage, en AWS Elastic Disaster Recovery (DRS) voor bijna-realtime replicatie van on‑prem servers met minimale applicatiewijzigingen. Een veelvoorkomende valkuil is om alleen te ontwerpen voor de gemiddelde belasting in plaats van voor hersteloperaties in het ergste geval; een andere is de aanname dat snapshots alleen al voldoende zijn om de RPO voor transactionele systemen te halen, omdat snapshots minuten na elkaar kunnen worden gemaakt en mogelijk geen applicatieconsistentie hebben. De afwegingen zijn eenvoudig: synchrone replicatie verhoogt de kosten en de write-latency, maar verlaagt de RPO; asynchrone replicatie verlaagt de latency en de kosten, maar verhoogt het potentiële dataverlies. Test het plan met chaos testing, geplande failovers en hersteloefeningen om de daadwerkelijke RTO/RPO te valideren en verborgen afhankelijkheden zoals externe authenticatie, DNS of IP-whitelists te identificeren.
Multi‑AZ- en Multi‑Region-architecturen en failover-strategieën
Multi‑AZ-architecturen bieden bescherming tegen storingen in een AZ door redundante compute, netwerk en opslag over meerdere Availability Zones te verdelen; Multi‑Region breidt de tolerantie uit naar storingen op regioniveau, natuurrampen of grote netwerkpartities. Kies een architectuurpatroon — pilot light, warm standby, active-passive of active-active — op basis van kosten en herstelvereisten. Pilot light gebruikt minimale resources in een secundaire regio om de kosten te minimaliseren en schaalt op tijdens een failover; warm standby houdt verkleinde services draaiende voor sneller herstel; active-active verwerkt verkeer in meerdere regio’s voor de laagste RTO, maar vereist sterke datareplicatie en conflictoplossing. Gebruik Route 53 met health checks en failover routing, Amazon CloudFront of Global Accelerator voor wereldwijd verkeersbeheer, en dataservices zoals DynamoDB Global Tables of Aurora Global Database voor cross-region replicatie. Veelvoorkomende valkuilen zijn het vertrouwen op te lange DNS TTL’s, het niet valideren van de failover van stateful services (session stores, caches) en het negeren van de kosten voor cross-region dataoverdracht en compliance-beperkingen. Weeg de complexiteit en kosten van een multi-region implementatie af tegen acceptabele downtime en dataverlies; instrumenteer en modelleer bij twijfel de failover-tijden om de businesscase te onderbouwen.
Patronen voor applicatieveerkracht: statelessness, ontkoppeling en state management
Ontwerp met het oog op storingen door de state die aan individuele compute nodes is gekoppeld te minimaliseren en door componenten te ontkoppelen zodat gedeeltelijke storingen niet trapsgewijs escaleren. Stateless applicatie-nodes achter een Application Load Balancer of Network Load Balancer maken horizontale schaalbaarheid en snelle vervanging mogelijk. Geef voor session state de voorkeur aan externe opslag zoals Amazon DynamoDB of Amazon ElastiCache in plaats van sticky sessions; gebruik voor file shares Amazon S3, Amazon EFS of FSx, afhankelijk van het protocol en de prestatiebehoeften. Asynchrone patronen die gebruikmaken van Amazon SQS, SNS of Kinesis vangen pieken op, maken retries mogelijk, reguleren backpressure en verminderen synchrone afhankelijkheden tijdens een failover. Implementeer circuit breakers, bulkheads en exponential backoff in clients om falende subsystemen te isoleren. Een veelvoorkomende valkuil voor architecten is het onderschatten van cold-start- of opschaaltijden — Lambda concurrency-limieten, Auto Scaling cooldowns en warm-up-strategieën beïnvloeden de RTO. Een andere is het beschouwen van caching als duurzaamheid; caches moeten opnieuw opgebouwd kunnen worden. De afweging tussen kosten en veerkracht komt tot uiting in de dimensionering van buffers en replicatie: een hogere veerkracht vereist vaak meer gereserveerde capaciteit of cross-region replicatie, wat de kosten verhoogt; kies de minimaal levensvatbare redundantie die voldoet aan de RTO/RPO en zorg tegelijkertijd voor observability en automatisering om storingen te detecteren en te verhelpen.
← Migratie · Alle domeinen · Kostenoptimalisatie →
Oefen deze vragen → · Getimede oefening op ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Slaag voor je examen →