sota.io
2026-05-05·12 min read·
AWS Elastic Block Store is the foundational persistence layer for most AWS-hosted applications. Every EC2 instance that needs durable storage beyond the local instance store uses EBS. It is reliable, fast, and deeply integrated with the AWS ecosystem. It is also the layer where most European teams unknowingly create their most serious GDPR exposure. The problem is not that EBS stores your data in the EU. It does. The problem is that EBS encryption is managed by AWS Key Management Service, which is operated by a US corporation subject to the CLOUD Act. Your data is encrypted at rest. The encryption keys are under US jurisdiction. Under a valid CLOUD Act order, Amazon can be compelled to produce those keys and the data they protect — regardless of which AWS region your volumes sit in. This guide covers exactly where EBS creates GDPR liability, what the AWS encryption architecture means in practice, and which EU-native block storage alternatives eliminate the structural exposure. ## What AWS EBS Actually Does EBS provides persistent block-level storage volumes for use with Amazon EC2. A volume behaves like a raw unformatted block device that you can attach to an EC2 instance. You format it, mount it, and it holds your data across instance restarts and stop/start cycles. EBS volumes have three properties that matter for GDPR analysis: **Persistence:** Data written to an EBS volume survives beyond the lifetime of the EC2 instance that wrote it. A volume can be detached from one instance and attached to another. This is essential for stateful applications but it also means personal data outlives the compute context in which it was created. **Snapshots:** EBS supports point-in-time snapshots stored in Amazon S3. Snapshots are incremental — each snapshot stores only the blocks that changed since the last snapshot. Most teams create automated snapshot schedules for backup and disaster recovery. Those snapshots accumulate, each containing personal data, often without a matching deletion schedule. **Encryption:** EBS volumes can be encrypted at rest using AES-256. Encryption uses keys from AWS Key Management Service. Without explicit configuration, EBS uses an AWS-managed key. With configuration, you can use a Customer Managed Key. With significant additional effort, you can use an External Key Store that keeps key material outside AWS entirely. ## The Four GDPR Exposure Points ### 1. Art.28 — Data Processor Under CLOUD Act Jurisdiction When you use EBS, AWS is your data processor under Art.28 GDPR. You are required to have a Data Processing Agreement. AWS provides one, and it includes appropriate safeguards on paper. The structural problem that no DPA can solve: AWS is incorporated in the United States. CLOUD Act Section 2713 (18 U.S.C. § 2713) compels US-incorporated cloud providers to produce data stored on their infrastructure regardless of physical location. A valid CLOUD Act order issued to Amazon does not require a subpoena to each individual server in eu-central-1. It requires Amazon — the corporation — to produce data from your EBS volumes. The AWS Data Processing Agreement explicitly states that AWS will comply with applicable law, including lawful government orders. CLOUD Act orders are lawful government orders. The DPA protects you from AWS voluntarily sharing your data. It does not protect you from AWS being legally compelled to produce it. Your Art.28 DPA is necessary. It is not sufficient for CLOUD Act risk. ### 2. Art.32 — Encryption That Does Not Provide the Protection You Think It Does Art.32 GDPR requires technical measures appropriate to the risk, including encryption. EBS encryption satisfies the technical measure requirement. It does not satisfy the underlying risk requirement when the threat model includes US government compelled access. Encryption protects against unauthorized access by third parties — a leaked hard drive, a misconfigured S3 bucket, a rogue employee at the data center. Encryption does not protect against the key holder being compelled to decrypt. When you use EBS encryption with an AWS-managed key, the key material is generated by AWS and never leaves AWS KMS. You cannot export it. AWS holds it. Under a CLOUD Act order, Amazon can use that key to decrypt your volumes and produce plaintext data. When you use a Customer Managed Key — one you create and control — the situation is marginally better. You can delete the CMK, which makes the data permanently inaccessible. But while the CMK exists and EBS volumes are operational, AWS KMS must have access to the key material to perform encryption and decryption operations. That access is what a CLOUD Act order targets. Encryption is essential for GDPR compliance. It does not eliminate CLOUD Act risk for data stored in AWS infrastructure. ### 3. Art.17 — The Right to Erasure and Snapshot Accumulation Art.17 GDPR gives data subjects the right to erasure. When a user requests deletion of their personal data, you must be able to comply completely and verifiably. EBS snapshot lifecycle is where Art.17 compliance breaks down in practice. When you delete an EBS volume, the data is gone from that volume. When you delete an EC2 instance, attached volumes may or may not be deleted depending on your configuration — a common misconfiguration leaves orphaned volumes with personal data attached to no running instance. More critically: snapshots are not deleted when volumes are deleted unless you explicitly configure snapshot deletion policies. A typical production environment running for two years might have hundreds of snapshots, each containing the state of a database at a point in time. Every user's personal data that existed in that database at snapshot time exists in every subsequent snapshot until that snapshot is explicitly deleted. When a user exercises Art.17 right to erasure, you delete their record from the live database. If you do not also delete or overwrite the snapshots that contained that record, the deletion is incomplete. The personal data continues to exist in backup storage. A GDPR supervisory authority auditing your erasure capability will examine backup policies. Compliant snapshot lifecycle management requires a documented retention period for snapshots, automated deletion of snapshots beyond that period, a process for handling Art.17 requests against snapshots (typically: immediate deletion of affected snapshots or documented justification for retention under Art.17(3) exceptions), and verification that snapshot deletion is permanent. ### 4. Art.5(1)(e) — Storage Limitation and Snapshot Sprawl Art.5(1)(e) requires that personal data is not kept longer than necessary for the purpose for which it was collected. Snapshot sprawl is the most common Art.5(1)(e) violation in AWS environments, and it is almost always unintentional. The pattern: a team sets up daily snapshots for disaster recovery. No retention policy is configured. After one year, there are 365 snapshots of every volume. Each snapshot contains the full state of the data at that point, including personal data that may have been deleted from the live system weeks or months ago. The data subject who exercised their Art.17 right and whose record was deleted from the live database in January may still have their personal data in every snapshot taken between when they signed up and when their data was deleted. Those snapshots may live in AWS S3 — accessible to Amazon under CLOUD Act — for years after the data was supposed to be gone. A compliant configuration requires snapshot retention policies aligned with your data retention schedule, automated lifecycle rules that delete snapshots older than the retention period, and documentation mapping snapshot retention to the legal basis under which data is retained. ## The AWS KMS Architecture and Why It Matters AWS KMS stores cryptographic key material inside Hardware Security Modules (HSMs) that AWS owns and operates. When you create a key in KMS — even a Customer Managed Key — the key material is generated in AWS HSMs and stays there. The key hierarchy: AWS KMS generates a Customer Master Key (CMK). When EBS encrypts a volume, it calls KMS to generate a Data Encryption Key (DEK) protected by your CMK. EBS uses the DEK to encrypt your data. To decrypt, EBS calls KMS to decrypt the DEK using your CMK. KMS performs this in its HSMs and returns the plaintext DEK to EBS. At no point does your application hold the CMK. AWS KMS holds it in HSMs that AWS controls. You can use it, rotate it, restrict access to it, and delete it — but you cannot extract it from AWS infrastructure. Under a CLOUD Act order, Amazon does not need to extract the CMK. Amazon needs to perform a decryption operation using KMS. It already has that capability. ## Customer Managed Keys: Necessary But Not Sufficient Using Customer Managed Keys gives you significant control improvements: audit trails via CloudTrail, access restrictions per IAM principal, the ability to disable the key immediately, and permanent deletion to make data cryptographically unrecoverable. The capability to delete the CMK is sometimes cited as sufficient CLOUD Act protection. It is not, for two reasons. First, you cannot operate your application without the CMK. Deleting it means shutting down your application — not a realistic response to a 3am CLOUD Act order on a production database. Second, key deletion has a mandatory waiting period of 7 to 30 days. A CLOUD Act order received during this window can compel Amazon to cancel the deletion and use the key. CMKs are the correct choice for EBS volumes. They are not a substitute for key sovereignty. ## External Key Store: The Only True Key Sovereignty Option AWS KMS External Key Store (XKS) allows key material that never enters AWS infrastructure. The key lives in an external HSM you control. When EBS needs a cryptographic operation, KMS proxies the request to your external key manager. Only the result — never the key material — returns to AWS. With XKS correctly implemented, AWS never holds your key material. A CLOUD Act order cannot compel Amazon to produce keys that Amazon does not have. This is real key sovereignty. It is also operationally demanding: high-availability external key management, low-latency key operations (every EBS read/write triggers a KMS call to your external manager), and compliance with AWS XKS specification. For most European SaaS companies, the right answer is not XKS complexity within AWS — it is moving block storage to an EU-native provider where the jurisdictional problem does not exist. ## EU-Native Block Storage Alternatives ### Hetzner Cloud Volumes Hetzner Online GmbH is a German company with no US parent. Cloud Volumes are CEPH-based block storage available in Falkenstein, Nuremberg, and Helsinki. The CLOUD Act does not apply to Hetzner — US courts cannot compel production of data Hetzner holds. Data requests must go through EU legal channels under EU law. Hetzner Cloud Volumes: SSD-backed, up to 10TB per volume, €0.056/GB/month. Snapshots and automatic backups supported. ### OVHcloud Block Storage OVHcloud SAS is a French company headquartered in Roubaix with no US parent. Block Storage available in Gravelines, Strasbourg, Warsaw, and Frankfurt. OVHcloud offers SecNumCloud qualification (French ANSSI certification) on selected products — the highest EU public cloud security certification available. From €0.04/GB/month on NVMe SSD-backed volumes. ### Scaleway Block Storage Scaleway SAS (Iliad Group) is a French company with data centers in Paris, Amsterdam, and Warsaw. No US parent. Block Storage from €0.04/GB/month with configurable snapshot retention. ### Exoscale Block Storage A1 Telekom Austria Group, headquartered in Vienna. Data centers in Austria, Germany, Switzerland, and Bulgaria. ISO 27001 certified. GDPR DPA available. ### sota.io — EU-Native PaaS Without Block Storage Complexity Running your application on sota.io means persistent storage sits on EU-jurisdiction infrastructure by default, without configuring EBS, managing CMKs, or implementing XKS. sota.io uses Hetzner backend infrastructure in Germany — incorporated under German law, no US parent. For database persistence, file storage, and cache persistence, sota.io provides managed options where the storage infrastructure is explicitly outside US jurisdiction. You do not manage HSMs, snapshot retention policies, or key hierarchies. The sovereignty is architectural. ## Migrating from EBS to EU-Native Block Storage **Step 1: Inventory your volumes.** List all EBS volumes by region. Identify volumes that hold GDPR-covered personal data. Note encryption keys and snapshot schedules. **Step 2: Export your data.** Create a final snapshot of each volume. For databases, use logical dumps (pg_dump, mysqldump) rather than block-level copies. For file storage, use rsync or AWS DataSync to your new EU provider. **Step 3: Implement equivalent controls on the EU provider.** Configure encryption at rest. Set snapshot retention policies aligned with your GDPR data retention schedule. Document the legal basis for any data retained in snapshots. Review the new provider's DPA for Art.28 compliance. **Step 4: Delete AWS resources cleanly.** Delete EBS volumes after verifying data transfer. Delete all EBS snapshots. Delete your CMKs after the waiting period. Verify with AWS Config that no EBS resources remain. The migration eliminates ongoing CLOUD Act exposure and typically reduces costs — Hetzner at €0.056/GB/month versus EBS gp3 at approximately $0.08/GB/month in eu-central-1. ## The Practical Question Most European engineering teams using EBS in eu-central-1 or eu-west-1 are not thinking about CLOUD Act risk. They know their data is in Europe. They have encryption enabled. They have an AWS DPA. On the surface, it looks compliant. The structural exposure is architectural: a US-incorporated company holds your encryption keys under US law. Your Art.32 encryption does not protect against US-compelled access. Your Art.28 DPA protects against AWS's discretionary decisions, not legal compulsion. Your snapshot schedule has almost certainly created Art.5(1)(e) violations you are not aware of. The teams who discover this during a supervisory authority audit or an Art.35 DPIA are in a worse position than the teams who address it proactively. The cleanest solution is not configuring XKS inside AWS — it is using infrastructure where the jurisdictional problem does not exist. EU-native block storage from Hetzner, OVHcloud, or Scaleway, or a managed EU-native platform like sota.io, eliminates the CLOUD Act exposure at the architectural level.

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