De AWS-storing van 20 oktober herinnerde ons opnieuw aan een simpele waarheid: resilience improviseer je niet. Hoge beschikbaarheid (HA) binnen één regio helpt, maar vervangt geen plan B dat de dienst overeind houdt wanneer het gemeenschappelijke knooppunt uitvalt waar te veel componenten van afhankelijk zijn (regio, control plane, DNS, queues, identity, enz.).
In deze gids schetsen we een praktische route van “HA” naar bedrijfscontinuïteit, met patronen die we in productie zien werken—en die we bij Stackscale implementeren met twee active-active datacenters. Waar nodig combineren deze architecturen moeiteloos met andere providers. Het begint bij de basis: RTO/RPO definiëren en failovers oefenen.
David Carrero (mede-oprichter van Stackscale): “HA is onmisbaar, maar als alles afhangt van één gemeenschappelijk punt, dan faalt HA. Het verschil tussen een schrikmoment en een crisis wordt gemaakt door een geoefend plan B.”
1) Business en technologie op één lijn: RTO/RPO en een afhankelijkheidskaart
- RTO (Recovery Time Objective): hoe lang een dienst mag uitvallen.
- RPO (Recovery Point Objective): hoeveel gegevensverlies (in tijd) je accepteert bij herstel.
Met die doelen geaccordeerd door de business, teken je de afhankelijkheidskaart: wat breekt wat? Waar “ankeren” identity, DNS, queues, catalogi of global tables in werkelijkheid? De uitkomst is je lijst met diensten die niet mogen uitvallen—én waarop ze leunen.
2) Continuïteitspatronen die écht werken
Active-active over twee datacenters (RTO=0 / RPO=0)
Voor betalingen, identity of kerntransacties:
- Synchrone opslagreplicatie tussen beide DC’s → RTO=0 / RPO=0.
- Gedistribueerde / quorum-databases, met conflictbeheersing (CRDT’s / saga’s).
- DNS/GTM met health checks op serviceniveau (geen pings).
- Gedefinieerde degradatiemodi (read-only, feature flags).
Bij Stackscale bieden we active-active over twee Europese datacenters met synchrone replicatie als fundament voor mission-critical workloads. Dat fundament kan je aanvullen met derden (hyperscalers of andere DC’s) als je een derde continuïteitsroute of soevereiniteits-/lokalisatie-eisen hebt.
Multi-site warm standby (hot passive)
Voor de meeste belangrijke workloads:
- Asynchrone datakopie naar een tweede site.
- Vooraf geprovisionde infrastructuur (templates / IaC) om site B in minuten te promoveren.
- Automatische failover via DNS/GTM en geoefende runbooks.
Minimale voetafdruk bij een alternatieve provider (voorheen “pilot-light”)
Wil je risicoconcentratie verlagen met beheersbare kosten:
- Houd het minimaal noodzakelijke aan buiten de primaire provider (bijv. DNS, observability, immutabele back-ups, nood-identity, statuspagina).
- Promoveer alleen het echt kritieke naar active-passive of active-active, conform je RTO/RPO.
Carrero: “Het gaat niet om hyperscalers verlaten, maar om balanceren. Het Europese ecosysteem—ook in Spanje en de Benelux—is volwassen en een sterke aanvulling voor resilience en soevereiniteit.”
3) Drie lagen die het verschil maken (en hoe je ze aanpakt)
Data
- Transactioneel: quorum-distributie + conflictcontrole.
- Objecten: versioning + inter-site replicatie, immutabiliteit (WORM-vergrendeling) en waar nodig air-gap.
- Catalogi/queues: vermijd “global” services verankerd in één externe regio als je RTO/RPO dat niet toestaat.
Netwerk / DNS / CDN
- Twee DNS-providers en GTM met business-probes (een echte “gezondheidstransactie”, geen ping).
- Multi-CDN en alternatieve origins (A/A of A/P) met origin shielding.
- Redundante private connectiviteit (overlay SD-WAN) tussen cloud en DC.
Identity & access
- IdP met JWKS-keycaching en contextuele her-authenticatie.
- Break-glass-accounts buiten het faaldomein, met sterke MFA (hardware sleutels).
- App governance om consent phishing en OAuth-misbruik te stoppen.
4) Observability, back-ups en drills: zonder dit geen plan B
- Observability buiten hetzelfde faaldomein: minstens één mirror van metrics/logs en een statuspagina die niet van de primaire provider afhangt.
- Immutabele back-ups en getimede hersteltests (met recent bewezen succes).
- Kwartaal-gamedays: uitval van regio/IdP/DNS/queue/DB. Meet echte RTO, dwell time (verblijftijd) en MTTR.
5) Twee referentie-architecturen (en hoe ze met Stackscale klikken)
“Alles Stackscale” continuïteit
- DC A + DC B (Stackscale) in active-active met synchrone replicatie (RTO=0/RPO=0).
- Immutabele back-ups in een derde domein (ander DC of geïsoleerde object storage).
- Multi-provider DNS/DNSSEC + GTM met business-healthchecks.
- Observability gespiegeld buiten (dedicated provider of tweede Stackscale-site).
- Runbooks en regelmatige gamedays met nabij 24/7-support.
Hybride continuïteit (Stackscale + andere locatie/provider)
- DC A + DC B (Stackscale) active-active voor de kern.
- Minimale voetafdruk bij een andere provider voor DNS, status, logs/SIEM en immutabele objectopslag (of omgekeerd).
- Niet-kritieke workloads bij de andere partij, met DR terug naar Stackscale bij soevereiniteits- of kostendwingende redenen.
- Private connectiviteit en portabele policies (identity, logging, back-up).
Wat Stackscale toevoegt (zonder verkooppraat):
- Twee Europese datacenters met lage latency, redundante netwerken en stroom, en lokale 24/7-support.
- Synchrone replicatie voor mission-critical apps (RTO=0/RPO=0).
- High-performance storage (block/object) met versioning en WORM-lock (Object Lock) voor immutabele back-ups.
- Bare-metal en private cloud om workloads te consolideren, plus dedicated connectiviteit met carriers en public clouds via partners.
- Eenvoudige integratie met externe providers (DNS, CDN, observability, hyperscalers) voor hybride of selectieve multicloud strategieën.
6) Realistische 30-60-90-dagen roadmap
Dag 1–30
- RTO/RPO per dienst formaliseren.
- Afhankelijkheids- & global-anchor kaart opstellen.
- Immutabele back-ups en eerste getimede restore.
Dag 31–60
- DNS/GTM multi-provider, multi-CDN en observability buiten hetzelfde faaldomein.
- Minimale voetafdruk (nood-identity, status, SIEM).
- Eerste gameday (DNS + DB/queues).
Dag 61–90
- Active-active of warm standby tussen de twee Stackscale-DC’s.
- Integraties met derden (indien nodig).
- Volledige regio-uitval gameday en metriekreview.
7) Bestuurlijke KPI’s die wél iets zeggen
- % diensten met ondertekende RTO/RPO en gehaald in drills.
- Restore OK (laatste 30 dagen) en gemiddelde hersteltijd.
- Failovertijd (gamedays) en dwell time per scenario.
- Observability-dekking “buiten” het faaldomein (ja/nee per domein).
- “Global” afhankelijkheden met alternatief (ja/nee).
Slot: nuchtere resilience (zonder jezelf vast te ketenen)
De les is niet “vlucht uit de cloud”, maar ontwerp voor falen en de-concentreer single points of failure. HA is nodig, maar onvoldoende: je hebt een volwaardige alternatieve route naar hetzelfde resultaat nodig. Met twee active-active DC’s (RTO=0/RPO=0) als basis en continuïteitslagen—DNS, immutabele kopieën, observability en nood-identity—buiten hetzelfde faaldomein, blijft je platform overeind wanneer een provider of regio struikelt.
Bij Stackscale begeleiden we die transitie elke dag. En wanneer je continuïteitsdoelen of regelgeving daarom vragen, combineren we onze twee-datacenter-infrastructuur met andere providers. Zo is plan B geen PDF in een la, maar een route die je al gelopen hebt.