Maakt AWS een back-up van je data? Het model van gedeelde verantwoordelijkheid uitgelegd

Wat beschermt AWS, en waar ben jij verantwoordelijk voor?

AWS beschermt de infrastructuur waarop je workloads draaien. Jij beschermt alles wat je erop zet: data, identiteiten, configuratie en back-ups.

Het model van gedeelde verantwoordelijkheid van AWS verdeelt dit in "security of the cloud", dat AWS regelt, en "security in the cloud", dat jijzelf regelt. Bij diensten als S3 en DynamoDB beheert AWS de infrastructuur. Klanten beheren de versleuteling van data, de classificatie van assets en de IAM-rechten. Bij EC2 beheer je ook het gastbesturingssysteem, de patches en de security groups.

Kort gezegd beschermt AWS het gebouw, en wat erin staat moet je zelf bewaken. Dat gat vult Backup as a Service. Google Cloud en Microsoft gebruiken hetzelfde model, zie gedeelde verantwoordelijkheid bij Google Cloud.

Wat kan er misgaan met je data in AWS?

Het platform verliest je data zelden. Mensen, aanvallers en configuratie doen dat wel: een verwijderde bucket, een gecompromitteerde toegangssleutel, een beleidsregel die data blootstelt of overschrijft.

• Menselijke fouten: een beheerder verwijdert de verkeerde bucket, een script overschrijft objecten of een opschoontaak haalt snapshots weg die nog nodig waren.
• Ontbrekende bescherming: volgens de Amazon S3-documentatie is S3 Versioning standaard "uitgeschakeld op buckets". Een verwijdering of overschrijving kan dus definitief zijn, tenzij je versiebeheer hebt ingeschakeld.
• Gecompromitteerde inloggegevens: een aanvaller met beheerderssleutels kan productiedata verwijderen, en ook alle back-ups die met die sleutels te bereiken zijn.
• Verkeerde configuratie: een te ruime IAM-rol of een te ruim bucketbeleid laat het verkeerde proces data wijzigen.

Het slechtste scenario is al eens gebeurd. In juni 2014 meldde The Register dat een aanvaller toegang kreeg tot het AWS-beheerpaneel van Code Spaces en "alle EBS-snapshots, S3-buckets, alle AMI's, enkele EBS-instances en meerdere machine-instances" verwijderde. De back-ups waren bereikbaar vanuit datzelfde beheerpaneel. Het bedrijf maakte bekend niet verder te kunnen.

Is AWS Backup niet genoeg?

AWS Backup is een goede dienst en met de juiste instellingen is hij moeilijk te verwijderen voor een aanvaller. Maar hij beschermt alleen wat je configureert, blijft binnen de control plane van AWS en valt onder dezelfde aanbieder en hetzelfde rechtsgebied als je productiedata.

Eerlijk is eerlijk: de opties zijn beter geworden. AWS Backup Vault Lock in compliance mode maakt een vault onveranderbaar zodra een bedenktijd van minimaal drie dagen voorbij is. Daarna kan volgens AWS geen enkele gebruiker en ook AWS zelf de vault niet meer wijzigen of verwijderen. Governance mode kan daarentegen worden verwijderd door gebruikers met genoeg IAM-rechten. Een logisch air-gapped vault gebruikt altijd compliance mode. Je kunt hem delen met andere accounts voor herstel als het account van de eigenaar is gecompromitteerd.

Binnen één aanbieder blijven betekent ook: zijn storingen delen. De post-event summary van AWS beschrijft een DNS-storing van DynamoDB in US-EAST-1 op 19–20 oktober 2025, die het grootste deel van een dag ook EC2, Lambda, IAM-authenticatie en STS raakte. Een kopie buiten AWS blijft bereikbaar, ook als AWS niet in orde is.

Geldt de CLOUD Act voor data in AWS-regio's in de EU?

Dat kan. De CLOUD Act volgt de aanbieder, niet de server. Data die een Amerikaans bedrijf in Frankfurt of Ierland bewaart, valt er dus ook onder.

De tekst van 18 U.S.C. 2713, in 2018 toegevoegd door de CLOUD Act, verplicht aanbieders om data openbaar te maken die zij in hun "bezit, bewaring of controle" hebben, "ongeacht of die communicatie, dat record of die andere informatie zich binnen of buiten de Verenigde Staten bevindt". Data residency (waar je data staat) is niet hetzelfde als datasoevereiniteit (wie kan worden gedwongen om data af te geven). In onze gids over datasoevereiniteit lees je het verschil.

AWS lanceerde in januari 2026 de European Sovereign Cloud in Brandenburg, Duitsland. Die wordt beheerd door een Duits bedrijf met Europese leiding en heeft aparte IAM, facturering en DNS. Volgens InfoQ betwijfelen mensen uit de praktijk nog steeds of daarmee de Amerikaanse juridische toegang verdwijnt, omdat het bedrijf volledig eigendom blijft van Amazon.com Inc. Of dat voor jou uitmaakt, hangt af van je data en je toezichthouders. Leg die vraag voor aan je functionaris voor gegevensbescherming (FG) en je juridisch adviseur.

Hoe bouw je een AWS-back-upstrategie die de slechtste dag overleeft?

Gebruik de ingebouwde functies van AWS voor snelle, dagelijkse herstelacties en voeg een onafhankelijke kopie buiten AWS toe voor de dag dat het account zelf het probleem is.

1. Zet versiebeheer aan voor kritieke S3-buckets en stel lifecycle-regels in voor oude versies.
2. Gebruik AWS Backup met Vault Lock in compliance mode voor kritieke resources, in een apart back-upaccount.
3. Beperk verwijderrechten: weinig mensen, MFA bij elke bevoegde actie en geen beheerderssleutels met een lange looptijd.
4. Bewaar een onafhankelijke kopie buiten AWS, met eigen inloggegevens en onveranderbare opslag, volgens de 3-2-1-1-0-regel.
5. Stel RPO en RTO vast per workload: hoeveel werk je kunt verliezen (RPO) en hoelang het stil mag liggen (RTO).
6. Test herstel volgens een vast schema. De AWS Well-Architected reliability pillar (REL09-BP04) noemt "herstellen zonder validatie" en aannemen dat je hersteltijd wordt gehaald zonder dat te meten anti-patterns (veelgemaakte fouten).

Voor stap 4 maken we een back-up van AWS-workloads naar onze eigen Tier III-datacenters in Nederland en Duitsland, onder EU-recht en onafhankelijk van Amerikaanse hyperscalers (grote cloudaanbieders). De back-ups zijn onveranderbaar met Object Lock, we bewaren een air-gapped kopie (een kopie zonder verbinding met je netwerk), data is tijdens transport met AES-256 versleuteld, beheeracties vragen MFA en we controleren elke back-uptaak automatisch. Zie AWS-back-up en hoe je test of je back-up werkt.

Wie heeft een onafhankelijke AWS-back-up het hardst nodig?

Elke organisatie die het verlies van haar AWS-account niet zou overleven, en zeker organisaties met toezichthouders, gevoelige data of klanten die van hen afhankelijk zijn.

• Entiteiten onder NIS2: NIS2-artikel 21(2) vraagt in punt (c) om bedrijfscontinuïteit, waaronder back-upbeheer en disaster recovery (je systemen weer draaiend krijgen na een calamiteit), en in punt (d) om ketenbeveiliging. Als je voor productie en back-up van één aanbieder afhankelijk bent, is dat een ketenvraag waar auditors naar kunnen vragen. Zie wat artikel 21 vraagt.
• Zorg en andere bijzondere persoonsgegevens: AVG-artikel 32(1)(c) vraagt om het vermogen om de beschikbaarheid van en de toegang tot persoonsgegevens tijdig te herstellen. We zijn ISO 27001- en NEN 7510-gecertificeerd en sluiten bij elk contract een AVG-verwerkersovereenkomst.
• MSP's die workloads van klanten in AWS hosten: één gecompromitteerd beheeraccount kan veel klanten raken. Onze multi-tenant console en het betalen naar gebruik (pay-as-you-grow) zijn daarvoor gebouwd, zie ons partnerprogramma.

Wat je nu kunt doen

Data in AWS opslaan is een verstandige keuze. Ervan uitgaan dat opslaan hetzelfde is als back-uppen is dat niet. AWS beveiligt het platform. Je data, je IAM en je back-ups blijven je eigen verantwoordelijkheid, en de veiligste kopie staat buiten het account waarop een aanvaller zich richt.

Stel deze week drie vragen: staat versiebeheer aan voor je kritieke buckets, zijn je back-upvaults vergrendeld in compliance mode, en bestaat er ergens een kopie buiten AWS? In ons overzicht van Backup as a Service zie je hoe een onafhankelijke EU-kopie naast AWS past.

Wil je een AWS-herstel zien vanuit een EU-datacenter? Plan een gratis demo van 15 minuten in het Nederlands, Duits of Engels.

Dit artikel is algemene informatie, geen juridisch advies.