navlogo_blue

English

Dutch

Data in AWS? That is not a backup yet.

Why cloud storage and cloud backup are not the same thing — and why it matters

KEY TAKEAWAYS

01

AWS protects their infrastructure. They do not protect your data.

02

45% of all data loss incidents now occur in cloud or SaaS environments — human error, ransomware and misconfigurations are the leading causes.

03

Even if AWS offers its own backup service, that backup sits inside the same system — and under the same US legal jurisdiction — as your production data.

Many businesses have moved to AWS. The infrastructure is reliable, the services are mature, and data is stored safely in a European region. What could still go wrong?

More than most IT managers expect. Because AWS protects the platform — not what you put on it. The responsibility for your data lies with you, not with Amazon. This is called the Shared Responsibility Model, and it is the most underestimated agreement in cloud computing.

What does AWS actually protect?

Amazon guarantees that the AWS platform will be available. Its SLA commits to high uptime for most services. That means the infrastructure — the servers, the network, the storage layer — stays up and running.

What Amazon does not guarantee is that your data will survive what happens on top of that infrastructure. AWS's own Shared Responsibility Model states explicitly that security in the cloud — your data, your configurations, your access management — is the customer's responsibility.

The distinction is simple: AWS protects the building. What is inside it is your responsibility.

What can go wrong in AWS?

According to research by Datastackhub, 45% of all data loss incidents now occur in cloud or SaaS environments. These are the main causes:

1

Human error

Files get deleted. S3 buckets get overwritten. An administrator accidentally removes the wrong IAM role or resource group. Human error accounts for 32% of all data loss incidents globally — and once data is deleted past AWS's retention window, it is permanently gone.

2

Ransomware

Ransomware increasingly targets cloud environments directly. Cloud ransomware incidents rose 28% year-over-year in 2025, with attackers specifically targeting backup repositories to prevent recovery. An AWS environment without an independent, immutable backup copy has no fallback once encryption takes hold.

3

Misconfiguration

Misconfiguration is responsible for 68% of all cloud data exposures, according to SentinelOne's 2026 cloud security report. A misconfigured S3 bucket policy, an overly permissive IAM role, a deleted VPC — these are operational risks that no uptime guarantee protects against.

4

CLOUD Act: The US Government Can Claim Your Data

Amazon is a US company. Under the US CLOUD Act, passed in 2018, US authorities can compel Amazon to hand over data stored anywhere in the world — including servers in eu-west-1 (Ireland) or eu-central-1 (Frankfurt) — without notifying the data subjects or European supervisory authorities. Under the CLOUD Act, jurisdiction follows the company — not the server.

But AWS offers its own backup service — isn't that enough?

AWS does offer a backup service: AWS Backup, for EC2, EBS, RDS, S3, DynamoDB and more. For operational scenarios — restoring a snapshot, recovering a database — this works well.

The problem is structural: AWS Backup sits inside the same AWS account, under the same IAM credentials, as your production data. A compromised IAM role, a malicious administrator or an attacker with access to your account can delete both production data and AWS Backup vaults in a single action. Recovery and production share the same perimeter.

And critically: AWS Backup is still operated by a US company. A backup stored inside AWS is subject to exactly the same CLOUD Act jurisdiction as the data it protects.

An independent sovereign backup — operated by a European entity, outside the AWS perimeter, with its own credentials — remains accessible and legally protected even when your AWS environment is not.

Want to see a detailed comparison of what AWS Backup covers versus what sovereign backup adds? View the full comparison on our AWS Cloud Backup page.

What is data sovereignty — and why does it matter for AWS?

Data sovereignty, as defined by ENISA, is the ability of an organisation or jurisdiction to control how its data is stored, processed and accessed — including protection from foreign legal frameworks.

It is different from data residency. Data residency tells you where the data is stored. Data sovereignty tells you who controls access to it — and who can legally demand it.

A company whose AWS data sits in Frankfurt but is managed by a US company has data residency in the EU, but it does not have data sovereignty. The CLOUD Act can reach across the Atlantic regardless of where the servers are physically located.

For organisations subject to DORA, NIS2 or sector regulators such as AFM or BaFin, data sovereignty is increasingly an audit requirement.

Mindtime's sovereign backup for AWS is designed to meet this standard: EU legal entity, EU-operated data centres, customer-held encryption keys and an identity plane fully independent of AWS IAM.

For Whom Is This Most Urgent?

1

Financial services

Under DORA, which requires demonstrable operational resilience and independent recovery capabilities outside a single provider's control plane.

2

Organisations processing special categories of personal data

Such as health, financial or legal data — where a US government data request directly conflicts with European privacy legislation.

3

Public sector and critical infrastructure

Subject to NIS2, which requires supply chain risk management. A cloud backup held by a US-parented provider is a supply chain dependency that auditors flag.

4

Any organisation whose CISO or DPO has been asked:

"If our AWS environment is compromised, or if a foreign government requests our data, what is our recovery plan?"

Want to know if sovereign backup is right for your organisation? Contact us

Conclusion

Storing data in AWS is a smart decision. Assuming that storing data is the same as having a backup is not.

AWS protects infrastructure. It does not protect you against human error, ransomware, misconfiguration or legal access requests from a foreign government. Sovereign backup is about completing your recovery strategy with a copy that is genuinely independent: a different operator, a different legal jurisdiction, a different identity plane.

Sovereign backup is not about distrusting Amazon. It is about completing your recovery strategy with a copy that is genuinely independent: a different operator, a different legal jurisdiction, a different identity plane.

Want to know if sovereign backup is right for your organisation? Contact us.

FAQ
Is my data safe if it is stored in AWS?
AWS protects their infrastructure — uptime, hardware, network availability. They do not protect your data against deletion, misconfiguration, ransomware or legal access requests. Storing your data in AWS is not the same as backing it up.
What is the difference between storing data in AWS and an AWS backup?
Storing data in AWS is where your data lives. A backup is an independent copy, held separately, used to restore operations if the primary copy is lost or inaccessible. A backup held inside the same AWS account is not truly independent.
Does sovereign backup mean I have to leave AWS?
No. Sovereign backup is designed to complement your existing AWS environment, not replace it. You continue using AWS for your workloads while the sovereign backup adds an independent copy under European law.

Recommended Content

  • All
  • Compliance
  • Cyber Security
  • Data Resilience
  • Managed IT Services
Scroll to Top