Does AWS back up your data? The shared responsibility model explained

What does AWS protect, and what is your responsibility?

AWS protects the infrastructure your workloads run on. You protect everything you put on it: data, identities, configuration and backups.

The AWS shared responsibility model splits this into "security of the cloud", which AWS handles, and "security in the cloud", which you handle. For services such as S3 and DynamoDB, AWS runs the infrastructure while customers manage data encryption, asset classification and IAM permissions. For EC2, you also manage the guest operating system, patches and security groups.

In short, AWS protects the building, and what's inside is yours to look after. That's the gap backup as a service fills. Google Cloud and Microsoft use the same model; see Google Cloud shared responsibility.

What can go wrong with your data in AWS?

The platform rarely loses your data. People, attackers and configuration do: a deleted bucket, a compromised access key, a policy that exposes or overwrites data.

• Human error: an admin deletes the wrong bucket, a script overwrites objects or a cleanup job removes snapshots that were still needed.
• Missing protection: according to the Amazon S3 documentation, S3 Versioning "is disabled on buckets" by default, so a delete or overwrite can be final unless you enabled it.
• Compromised credentials: an attacker with admin keys can delete production data and any backups those keys can reach.
• Misconfiguration: an overly permissive IAM role or bucket policy lets the wrong process change data.

The worst case has happened before. In June 2014, The Register reported that an attacker gained access to Code Spaces' AWS control panel and "removed all EBS snapshots, S3 buckets, all AMI's, some EBS instances and several machine instances". Its backups were reachable from that same control panel. The company announced it could not continue operating.

Isn't AWS Backup enough?

AWS Backup is a good service, and with the right settings it can be hard for an attacker to delete. But it protects only what you configure, stays inside AWS's control plane, and remains under the same provider and jurisdiction as your production data.

To be fair to AWS, the options have improved. AWS Backup Vault Lock in compliance mode makes a vault immutable once a grace period of at least three days has passed; after that, AWS says it can't be changed or deleted by any user or by AWS. Governance mode, by contrast, can be removed by users with enough IAM permissions. A logically air-gapped vault always uses compliance mode and can be shared with other accounts for recovery if the owning account is compromised.

Staying inside one provider also means sharing its outages. On 19-20 October 2025, AWS's post-event summary describes a DynamoDB DNS failure in US-EAST-1 that also affected EC2, Lambda, IAM authentication and STS for most of a day. A copy outside AWS doesn't depend on AWS being healthy to reach.

Does the CLOUD Act apply to data in AWS EU regions?

It can. The CLOUD Act follows the provider, not the server, so data held by a US company in Frankfurt or Ireland is still in scope.

The text of 18 U.S.C. 2713, added by the CLOUD Act in 2018, requires providers to disclose data in their "possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States". Data residency, where data sits, is not the same as data sovereignty, who can be compelled to hand it over. Our guide to data sovereignty covers the difference.

AWS launched its European Sovereign Cloud in Brandenburg, Germany, in January 2026, run by a German company with EU leadership and separate IAM, billing and DNS. According to InfoQ, practitioners still question whether that removes US legal reach, because it remains wholly owned by Amazon.com Inc. Whether that matters for you depends on your data and your regulators; it's a question for your DPO and legal adviser.

How do you build an AWS backup strategy that survives the worst day?

Use AWS's native controls for fast, everyday restores, and add an independent copy outside AWS for the day the account itself is the problem.

1. Turn on versioning for critical S3 buckets and set lifecycle rules for old versions.
2. Use AWS Backup with Vault Lock in compliance mode for critical resources, in a separate backup account.
3. Restrict deletion rights: few people, MFA on every privileged action, no long-lived admin keys.
4. Keep an independent copy outside AWS, with its own credentials and immutable storage, following the 3-2-1-1-0 rule.
5. Set RPO and RTO per workload: how much work you can lose and how long it can be down.
6. Test restores on a schedule. The AWS Well-Architected reliability pillar (REL09-BP04) calls "restoring without validation" and assuming your recovery time is met without measuring it anti-patterns.

For step 4, we back up AWS workloads to our own Tier III data centres in the Netherlands and Germany, under EU law and independent of US hyperscalers. Backups are immutable with Object Lock, an air-gapped copy is kept, data is AES-256 encrypted in transit, admin actions require MFA, and every backup job is checked automatically. See AWS backup and how to verify your backup works.

Who needs an independent AWS backup most?

Any organisation that couldn't survive losing its AWS account, and especially those with regulators, sensitive data or clients who depend on them.

• Entities under NIS2: Article 21(2) requires "business continuity, such as backup management and disaster recovery" in point (c) and supply chain security in point (d). Relying on one provider for both production and backup is a supply chain question auditors may ask. See what Article 21 asks for.
• Healthcare and other special-category data: GDPR Article 32(1)(c) requires the ability to restore availability and access to personal data in a timely manner. We're ISO 27001 and NEN 7510 audited and sign a GDPR Data Processing Agreement with every contract.
• MSPs hosting client workloads in AWS: one compromised management account can affect many clients. Our multi-tenant console and pay-as-you-grow billing are built for that; see our partner programme.

What to do next

Storing data in AWS is a sensible choice. Assuming that storing it is the same as backing it up is not. AWS secures the platform; your data, IAM and backups are your responsibility, and the safest copy is one that sits outside the account an attacker would target.

Ask three questions this week: is versioning on for your critical buckets, are your backup vaults locked in compliance mode, and does any copy exist outside AWS? Our backup as a service overview shows how an independent EU copy fits alongside AWS.

Want to see an AWS restore from an EU data centre? Book a free 15-minute demo in Dutch, German or English.

This article is information, not legal advice.