Grote cloudstoringen halen steeds vaker het nieuws. Een hele regio van een cloudprovider valt uit, een belangrijke dienst gaat onderuit en plots hebben banken, webshops en overheidsportalen tegelijk problemen. Het is verleidelijk om daaruit te besluiten dat de cloud de nieuwe zwakke schakel is. In dit artikel kijken we voorbij de headlines: hoe vaak gaat het echt mis, waarom doet één storing vandaag zoveel pijn, en vooral, wat betekent dat voor de keuzes die je als CIO of IT-manager nu moet maken?

Wie vooral afgaat op de headlines, krijgt al snel de indruk dat de cloud voortdurend platligt. In de praktijk ligt het genuanceerder. Overzichten van recente incidenten tonen telkens opnieuw een handvol stevige storingen bij grote cloudplatformen en bekende online diensten. Soms valt een hele regio van een provider urenlang weg, met haperende websites, betalingen en inlogs als gevolg. De oorzaak is zelden één spectaculair lek, maar meestal een combinatie van configuratiewijzigingen, updates en complexe onderlinge afhankelijkheden die anders uitpakken dan gepland.

Een recent voorbeeld is de grote storing bij Cloudflare in 2025. Door een probleem in hun infrastructuur waren onder andere ChatGPT, X en verschillende gaming- en bedrijfsdiensten tijdelijk niet bereikbaar voor miljoenen gebruikers. Niet omdat al die organisaties zelf iets verkeerd deden, maar omdat één gedeelde schakel in de keten uitviel.

Het gaat niet alleen om de bekende cloudproviders zelf. Er is ook een laag van dienstverleners die verkeer sturen, beveiliging leveren of de prestaties van websites optimaliseren. Wanneer zo’n schakel uitvalt, neemt die vaak een hele reeks andere diensten mee. Eén storing bij zo’n partij kan daardoor tegelijk verschillende sectoren raken, ook als organisaties op verschillende cloudproviders werken.

Of er vandaag objectief meer storingen zijn dan tien jaar geleden, is minder belangrijk dan de vraag hoeveel schade één incident kan veroorzaken. Die schade is groter dan vroeger, omdat:

• veel organisaties een groot deel van hun kernprocessen in de cloud hebben staan;
• dezelfde onderliggende diensten door duizenden klanten tegelijk worden gebruikt;
• digitale kanalen voor klanten en burgers vaak het belangrijkste kanaal zijn geworden.

Een storing die vroeger vooral binnen de IT-afdeling bleef, is nu meteen zichtbaar voor klanten, media en toezichthouders. Denk bijvoorbeeld aan de grote AWS-storing in 2025, waarbij één regio-incident leidde tot problemen bij webshops, SaaS-diensten en allerlei bedrijfsapplicaties, goed voor meer dan 17 miljoen storingsmeldingen wereldwijd. Voor eindgebruikers zag het eruit alsof het internet traag was of niet werkte, terwijl de oorzaak terug te voeren was op één onderdeel in de keten. Uitval raakt dus niet alleen je systemen, maar ook omzet, reputatie en vertrouwen.

De stelling dat cloudstoringen de nieuwe norm zijn, klinkt serieus, maar beschrijft vooral een gevoel. De onderliggende technologie is niet plots onbetrouwbaar geworden. Wat wel duidelijk is:

• storingen zullen altijd blijven voorkomen;
• de impact van één storing ligt hoger dan vroeger;
• organisaties die geen rekening houden met uitval, nemen bewust extra bedrijfsrisico.

Daarom leggen analisten de nadruk op veerkracht in plaats van op paniekreacties of het terughalen van alles naar on-premise. Het is niet de bedoeling om de cloud af te schrijven, maar om je omgeving zo te ontwerpen dat uitval beheersbaar blijft. Dat betekent concreet: nadenken over hersteltijden en dataverlies (RTO en RPO), fallbackscenario’s en de vraag wat een halve of hele dag uitval betekent voor jouw belangrijkste processen.

Drie vragen helpen om van een abstract risico naar concrete keuzes te komen:

• Wat gebeurt er als één cloudregio een halve dag wegvalt?
  Breng in kaart welke applicaties en datastromen afhankelijk zijn van welke regio, provider of kern-SaaS-dienst. Doorloop het scenario: welke processen vallen stil, welke kunnen doorlopen en welke interne en externe communicatie heb je klaarstaan als dit gebeurt?
• Haal je alles uit één provider wat vandaag al mogelijk is?
  Multi-cloud is niet automatisch de beste eerste stap. Binnen één platform valt vaak al veel te winnen door:
  – over meerdere availability zones en eventueel meerdere regio’s te ontwerpen;
  – back-ups én restores regelmatig te testen;
  – duidelijke runbooks te hebben en incidentprocedures ook echt te oefenen.
• Heb je een onderbouwde visie op multi-cloud en een tweede thuisbasis?
  Voor je meest kritieke workloads kan een tweede platform, regio of dienst zinvol zijn. Dat is geen reflex, maar een bewuste ontwerpbeslissing. Welke functies wil je echt dubbel uitvoeren, welke data moet kunnen verhuizen en wie beheert de extra complexiteit die daarbij hoort?