sota.io
2026-05-02·14 min read·
# AWS Backup EU Alternative 2026: Backup Retention, Erasure Conflicts, and the CLOUD Act Problem AWS Backup centralises data protection across your entire AWS footprint — EC2 volumes, RDS databases, DynamoDB tables, S3 buckets, EFS filesystems, Aurora clusters, and more. When you enable AWS Backup, you are creating **recovery points** that are exact copies of all personal data your services process. Every customer record, every health record, every financial transaction — all of it lands in backup vaults that operate under different retention rules than your primary databases. This is where GDPR compliance breaks down. Your primary database may honour Article 17 erasure requests within hours. Your AWS Backup vault retains a point-in-time copy of that data for 30, 60, or 90 days — or longer if you have enabled **Vault Lock**. The recovery point does not delete automatically when the source record is erased. And if you replicate backups cross-region for disaster recovery, every copy sits on US-controlled infrastructure subject to CLOUD Act compelled disclosure. This article analyses six critical GDPR failure vectors in AWS Backup and maps the best EU-sovereign alternatives for 2026. --- ## What AWS Backup Does (and Why That Creates GDPR Exposure) AWS Backup is a managed service that automates backup scheduling, retention management, and cross-account or cross-region copying across AWS services. You define backup plans, assign resources, and AWS Backup creates recovery points stored in **backup vaults**. The service is deeply integrated: when you back up an RDS instance, the recovery point is a complete database snapshot. When you back up an EBS volume, it is a full block-level copy. DynamoDB backups capture the entire table including all item attributes. S3 backups can include every object version. **Why this matters for GDPR:** Unlike a database where you can target individual records for erasure, backup recovery points are typically **monolithic and immutable**. You cannot delete a single user's data from a recovery point. You must either delete the entire recovery point — which may destroy backup coverage for legitimate purposes — or keep it and accept that the deleted user's data persists in encrypted cold storage. --- ## GDPR Failure Vector 1: Article 17 Right to Erasure vs. Vault Lock AWS Backup **Vault Lock** implements WORM (Write Once Read Many) storage for recovery points. Once configured, Vault Lock prevents deletion of recovery points even by the account root user. AWS markets this as a compliance and ransomware-protection feature — and for many regulatory frameworks it is exactly that. For GDPR, it is a direct conflict. **Article 17(1)** requires that personal data be erased "without undue delay" when the data subject exercises their erasure right and no retention obligation under Article 17(3) applies. A Vault Lock configuration with a minimum retention of 90 days means that a user who requests erasure today will have their personal data kept in backup for at minimum another 90 days — not because of a legal obligation, but because of a backup architecture decision. The DPA enforcement consequence: if a user complains to their national DPA that their data was not erased, "we have it in a vault-locked backup" is not a defence recognised under GDPR. The backup copy is still personal data. The controller is still responsible for it. **Practical implication:** Any organisation using AWS Backup Vault Lock for ransomware protection is inadvertently creating a 30–90 day GDPR erasure gap for every user deletion request. These two compliance requirements are structurally incompatible within the standard AWS Backup architecture. --- ## GDPR Failure Vector 2: Article 5(1)(e) Storage Limitation — Backup Retention Drift **Article 5(1)(e)** requires that personal data be kept "no longer than is necessary for the purposes for which the personal data are processed." AWS Backup retention policies are set at the **backup plan level**, not the data-subject level. A single backup plan covers entire RDS instances, EFS filesystems, or DynamoDB tables. If your backup plan retains recovery points for 35 days, every personal data record in the backed-up resource is retained for 35 days beyond the last backup — regardless of whether individual records have passed their own retention limit. **The Retention Drift Problem:** Consider a user whose account was inactive for 18 months and whose data you delete in accordance with your data retention policy. If your last backup ran yesterday, AWS Backup retains a copy of that user's data for another 35 days. Now multiply by thousands of users. Your backup infrastructure becomes a systematic retention violation — an accumulation of personal data that exceeds the purposes for which it was collected. **Cross-service compounding:** AWS Backup supports DynamoDB, Aurora, DocumentDB, Neptune, and Timestream — services that often hold the richest personal data (user profiles, health records, financial transactions). Backup retention policies across these services create overlapping retention windows that GDPR's storage limitation principle cannot easily accommodate without purpose-specific retention justification documented in your Article 30 records. --- ## GDPR Failure Vector 3: CLOUD Act + Article 46 — Cross-Region Backup as International Transfer Disaster recovery best practice recommends copying backups to a second AWS region. For EU-based organisations, the canonical pattern is replicating from `eu-west-1` (Ireland) or `eu-central-1` (Frankfurt) to `us-east-1` or `us-west-2` for geographic redundancy. **This is a third-country transfer under GDPR Article 46.** The backup copy now sits on AWS infrastructure in the United States, where AWS is subject to the **CLOUD Act (Clarifying Lawful Overseas Use of Data Act)**. US federal law enforcement and intelligence agencies can compel AWS to disclose the contents of recovery points held on US infrastructure, including EU personal data, via a warrant or court order — **without notifying the EU data subjects or the EU controller**. **Schrems II amplification:** The CJEU's Schrems II ruling invalidated Privacy Shield precisely because US surveillance law (Section 702 FISA, EO 12333) allows bulk access to data held by US providers. The CLOUD Act extends this to specific targeted requests. Cross-region backup to US regions exposes every personal data category your organisation holds — not just operational data but complete point-in-time database snapshots — to this legal regime. **The EU Backup Vault illusion:** Keeping your primary backup vault in `eu-central-1` is insufficient if your backup plan includes cross-region copy rules targeting US regions. Many organisations implement cross-region copy without realising it constitutes a transfer under Article 46 requiring either SCCs or an adequacy decision — neither of which insulates data from CLOUD Act compelled disclosure as Schrems II made clear. --- ## GDPR Failure Vector 4: Article 28 — Backup Spans the Entire Processor Chain AWS is already a data processor under Article 28 for each AWS service you use. AWS Backup adds a meta-processor layer: it copies data **across services** and **across accounts**. **Cross-account backup** is AWS's recommended security architecture: production backups are copied to a separate "backup account" to prevent ransomware actors from deleting backups if they compromise the production account. From a GDPR perspective, this creates data flows between AWS accounts that may belong to different legal entities within a corporate group — each requiring Article 28 DPA assessment or intra-group data sharing agreements under Article 46. **Expanding Article 28 inventory:** When AWS Backup copies an RDS snapshot to the backup account, the backup account's AWS environment now processes personal data. If the backup account uses different IAM roles, different CloudTrail configurations, or different encryption keys (KMS cross-account key grants), each configuration element affects the security and access controls that Article 32 and Article 28(3)(c) require. The Article 30 records of processing activities must reflect these backup data flows — a requirement most organisations miss when implementing AWS Backup for the first time. **AWS's own sub-processors:** AWS Backup uses AWS KMS for encryption (separate service, separate FIPS compliance scope), AWS CloudWatch for monitoring, and AWS IAM for access control. Each is an additional AWS sub-processor that Article 28(2) requires you to authorise — the DPA with AWS lists these, but many controllers sign AWS's standard DPA without reviewing the sub-processor list against their Article 30 inventory. --- ## GDPR Failure Vector 5: Article 25 Data Minimisation — Whole-Resource Backup Has No Selectivity **Article 25(1)** requires that by design, only personal data necessary for each specific purpose is processed. Backup has a defined purpose: recovery from data loss. Backup should therefore cover only the data necessary for that purpose — and only for as long as is necessary. AWS Backup creates **whole-resource recovery points**. When you back up an RDS instance, you get a snapshot of every schema, every table, every column, every row. You cannot configure AWS Backup to exclude specific tables containing special category data under Article 9 (health records, biometric data, racial or ethnic origin) from backup while backing up the rest of the database. **Special category data accumulation:** A healthcare SaaS provider on AWS might store appointment records (Article 9 health data) in one RDS table and billing records in another. AWS Backup treats the entire RDS instance as one unit. The backup recovery point contains Article 9 data that may require enhanced security controls, explicit consent for the backup purpose, and DPIAs under Article 35 — none of which the standard AWS Backup setup prompts you to consider. **Article 35 DPIA trigger:** The combination of large-scale processing (AWS Backup covers your entire data estate), special category data (Article 9(1)), and systematic processing (automated backup schedules) is a textbook Article 35(3)(b) DPIA trigger. Most AWS Backup implementations are deployed without a DPIA. --- ## GDPR Failure Vector 6: Article 32 — KMS Key Location and Encryption Control AWS Backup encrypts recovery points using AWS KMS. The encryption provides strong protection against unauthorised access — but the encryption key is managed by AWS KMS, which is subject to US law. **The KMS jurisdiction problem:** AWS KMS keys stored in `eu-central-1` are managed by AWS infrastructure running AWS software. AWS, as a US entity, can be compelled under CLOUD Act or FISA to provide access to encrypted data or to expose key material to US government agencies. The encryption does not prevent compelled disclosure — it only means the compelled disclosure requires AWS's cooperation, which US law can mandate. **External Key Store (XKS) — partial mitigation:** AWS KMS External Key Store allows you to use your own Hardware Security Module (HSM) outside AWS for the key material. AWS Backup recovery points encrypted with XKS keys cannot be decrypted without access to your on-premises or EU-hosted HSM. This is a real mitigation — but it is complex to implement, has operational risks (if your HSM is unavailable, backups cannot be decrypted), and requires an HSM infrastructure investment that most AWS Backup users have not made. **Practical implication:** Without XKS, your AWS Backup recovery points are encrypted with keys whose jurisdiction is US law. For sectors subject to NIS2, DORA, or sector-specific data sovereignty requirements (banking, healthcare, critical infrastructure), this is a compliance gap that AWS Backup's standard encryption does not close. --- ## EU-Sovereign Backup Alternatives ### Restic — Open Source, Storage-Backend Agnostic [Restic](https://restic.net/) is a modern open-source backup tool that stores encrypted, deduplicated backup snapshots to any storage backend (local filesystem, SFTP, S3-compatible, Azure, GCS, Wasabi, Backblaze B2). You control the encryption keys entirely — no HSM required, keys never leave your infrastructure. - **GDPR advantage:** Full key control, EU storage backends (Hetzner, OVH, Scaleway), selective backup of specific directories, retention policies enforced client-side - **Erasure:** Restic's `forget --prune` removes specific snapshots. Granular enough for most erasure workflows - **Best for:** Application-level file and database dump backups in EU-native environments ### BorgBackup — Deduplication + Encryption at Rest [BorgBackup](https://www.borgbackup.org/) (Borg) provides encrypted, compressed, deduplicated backups with strong key management. Combined with [Borgmatic](https://torsion.org/borgmatic/) for automation, it covers most AWS Backup use cases for non-cloud-native environments. - **GDPR advantage:** Keys never leave your infrastructure, EU storage via BorgBase (EU-hosted), fine-grained retention policies, append-only mode as Vault Lock alternative without GDPR conflicts - **Best for:** VM and bare-metal backup, database dumps, file-level backup with GDPR-compliant erasure ### Velero — Kubernetes-Native Backup [Velero](https://velero.io/) backs up Kubernetes cluster resources and persistent volumes. If you run workloads on EU-native Kubernetes (Hetzner, OVH, Scaleway, IONOS), Velero stores backups on EU-controlled object storage. - **GDPR advantage:** EU storage backends, backup encryption with your own keys via restic integration, namespace-level backup granularity (closer to Article 25 data minimisation than whole-cluster AWS Backup) - **Best for:** Kubernetes workloads migrating away from EKS to EU-native managed Kubernetes ### Veeam Data Platform — Enterprise EU Deployment [Veeam](https://www.veeam.com/) (now part of Insight Partners, but deployable entirely within EU infrastructure) provides enterprise backup for virtual machines, databases, and cloud workloads. With a self-hosted Veeam infrastructure on EU servers, no backup data leaves EU jurisdiction. - **GDPR advantage:** Full deployment within EU infrastructure, no US cloud dependency, immutable backup with configurable retention compliant with Article 17, broad GDPR documentation toolkit - **Best for:** Enterprise environments requiring comprehensive backup with compliance reporting, currently running VMware/Hyper-V on-premises or in EU colocation ### Bacula Enterprise — Open Core, EU-Deployable [Bacula Enterprise](https://www.baculasystems.com/) (Swiss-based, EU-deployable) provides backup and recovery for physical, virtual, and cloud environments. The open-source Bacula Community edition is available for self-hosted deployments. - **GDPR advantage:** EU-based vendor, self-hosted deployment, granular backup policy configuration, no US cloud dependency - **Best for:** Organisations requiring an enterprise backup vendor with EU-based support and sales ### NAKIVO Backup & Replication — EU-Deployable [NAKIVO](https://www.nakivo.com/) provides backup and replication for VMware, Hyper-V, Nutanix, AWS, Azure, and physical machines. Deployable entirely on EU infrastructure. - **GDPR advantage:** Deployable on EU NAS or server, AWS-agnostic storage, granular retention per backup job, immutable backup mode that respects separate retention per data type - **Best for:** Hybrid environments (some AWS, some EU on-premises) requiring unified backup management --- ## Comparison: AWS Backup vs. EU-Sovereign Alternatives | Dimension | AWS Backup | Restic / Borg | Velero | Veeam Enterprise | |-----------|-----------|---------------|--------|-----------------| | Key jurisdiction | AWS (US) | You | You | You | | Cross-region DR | US regions | EU backends | EU backends | EU colocation | | Vault Lock GDPR conflict | Yes | No | No | Configurable | | Article 17 erasure | Snapshot-level only | Snapshot + file-level | Namespace-level | Granular | | DPIA requirement | Article 35 trigger | Lower risk | Lower risk | Depends on scale | | Article 25 selectivity | Whole-resource | Directory/file | Namespace | Granular | | NIS2 / DORA readiness | Partial | Yes (self-managed) | Yes (self-managed) | Yes (EU vendor) | --- ## Recommended Architecture for GDPR-Compliant Backup on EU Infrastructure **Tier 1 — Application-level exports (daily, short retention):** Export database dumps and application files to encrypted local or EU S3-compatible storage (Hetzner Object Storage, OVH Object Storage, Scaleway Object Storage). Use Restic or BorgBackup. Retain for 7 days. This tier covers your recovery from most operational failures without long retention of personal data. **Tier 2 — Monthly snapshots (medium retention):** Keep monthly snapshots for 90 days for DR purposes. Document the retention basis in your Article 30 records (legitimate interest in operational continuity, balanced against data subject rights). Implement a documented process for handling Article 17 requests against monthly snapshots — deletion of specific snapshots where the legal basis for retention no longer applies. **Tier 3 — Annual disaster recovery archive (long retention):** For regulatory requirements (financial records, healthcare retention obligations), use purpose-specific backup with documented Article 6 legal basis, DPIA under Article 35, and encryption with keys held on EU-territory HSM infrastructure. **Key architectural rule:** Never enable cross-region backup copies targeting US AWS regions for personal data. EU-to-EU replication (`eu-west-1` to `eu-central-1`) keeps backup data within EU jurisdiction. Document the replication paths in your Article 30 records. --- ## Migrating Off AWS Backup: Practical Steps 1. **Inventory your recovery points:** Use `aws backup list-recovery-points-by-backup-vault` to enumerate all recovery points and their associated resources. This is your GDPR exposure surface. 2. **Map personal data categories:** For each backed-up resource (RDS instance, DynamoDB table, EBS volume), identify the personal data categories it contains and their associated erasure obligations. 3. **Identify Vault Lock conflicts:** If Vault Lock is enabled, document the minimum retention period and assess it against your Article 17 obligations. Vault Lock cannot be removed once applied — plan migration away from locked vaults. 4. **Implement EU backup infrastructure:** Deploy Restic or BorgBackup pointing to EU-region object storage. Test recovery workflows before decommissioning AWS Backup. 5. **Update Article 30 records and DPAs:** Remove AWS Backup from your Article 30 sub-processor list. Add your new backup infrastructure. Update your DPA with storage providers. 6. **DPIA review:** If you had (or should have had) a DPIA for AWS Backup, review it against the new architecture. --- ## The Audit Question If your DPA asks: *"How do you ensure that personal data erased from your primary systems is also erased from backup copies?"* — what is your answer? For most AWS Backup deployments: *"We cannot erase individual data subject records from recovery points. We can delete entire recovery points, which may leave gaps in our backup coverage."* For EU-sovereign backup with Restic or Borg: *"We can prune specific snapshots where the data subject's data was the primary content, or we can document the residual retention with a defined purge schedule."* GDPR does not prohibit backup. It requires that backup retention be documented, justified, and bounded — and that the rights of data subjects be reconcilable with backup retention practices. AWS Backup's architecture makes that reconciliation structurally difficult. EU-sovereign alternatives, deployed correctly, make it straightforward. --- ## Conclusion AWS Backup solves an operational problem — centralised, managed, automated backup — while creating a GDPR problem: **recovery points containing all personal data your organisation holds, retained under rules that conflict with erasure obligations, encrypted with US-controlled keys, and replicable to CLOUD Act-subject infrastructure**. The six failure vectors — Vault Lock vs. Article 17, retention drift vs. Article 5(1)(e), cross-region transfer vs. Article 46/CLOUD Act, cross-account processing vs. Article 28, whole-resource backup vs. Article 25, and KMS jurisdiction vs. Article 32 — are not edge cases. They are the default behaviour of a standard AWS Backup implementation. EU-sovereign alternatives (Restic, BorgBackup, Velero, Veeam self-hosted, Bacula) do not have these problems structurally. They require more operational investment than AWS Backup's managed service model — but they give you the key control, jurisdiction certainty, and retention granularity that GDPR's core obligations require. For EU organisations subject to GDPR, NIS2, DORA, or sector-specific data protection requirements: backup sovereignty is not optional infrastructure. It is a data protection requirement.

EU-Native Hosting

Ready to move to EU-sovereign infrastructure?

sota.io is a German-hosted PaaS — no CLOUD Act exposure, no US jurisdiction, full GDPR compliance by design. Deploy your first app in minutes.

Start free — no credit cardView pricing