AWS S3 EU Alternative 2026: GDPR, CLOUD Act, and the Object Storage Jurisdiction Problem

Post #683 in the sota.io EU Compliance Series

AWS S3 is the foundation of cloud storage. Every image upload, database backup, log archive, and static asset in a typical AWS architecture passes through S3. It is also — from a GDPR perspective — one of the most underestimated compliance risks in the AWS stack.

The common assumption is straightforward: "We store our S3 buckets in eu-central-1 (Frankfurt). European data stays in Europe." This assumption misses the point entirely. Jurisdiction is determined by the corporate structure of the service provider, not by the physical location of the hardware. AWS is a US company. S3 Frankfurt runs on US-owned infrastructure, under US corporate governance, subject to US law — including the CLOUD Act.

This post covers the complete jurisdictional analysis of AWS S3, the specific S3 features that expand your legal exposure beyond the obvious, and the EU-native object storage alternatives that eliminate the CLOUD Act problem.

Why Frankfurt Buckets Are Still Under US Jurisdiction

The Clarifying Lawful Overseas Use of Data Act (CLOUD Act, 18 U.S.C. § 2713) requires US companies to disclose data stored anywhere in the world when served with a valid US government order. The law contains no geographic exception. Amazon Web Services LLC, a Delaware corporation, operates S3 globally — including Frankfurt and Stockholm. A US court order served on AWS in Seattle can compel the production of objects stored in eu-central-1.

The GDPR, meanwhile, prohibits transferring EU personal data to third countries without adequate safeguards (Art.44 GDPR). The EU-US Data Privacy Framework (DPF) provides a partial transfer mechanism, but it applies only to data voluntarily transferred to the US. A CLOUD Act disclosure is a compelled transfer under US law — the DPF does not apply, and no Standard Contractual Clauses cover government-compelled access. This is the core compliance gap.

AWS's response to this tension is its "AWS European Sovereign Cloud" initiative, but that product is specifically designed for regulated industries and government customers, not available to standard commercial accounts. Your eu-central-1 S3 bucket is not covered.

The S3 Features That Expand Your GDPR Exposure

Most developers understand that the objects they upload to S3 are under AWS's jurisdiction. What they often miss is the full scope of secondary data that S3 generates and retains — data that is equally accessible under a CLOUD Act order.

S3 Versioning: The Data You Thought You Deleted

S3 versioning, when enabled, retains every version of every object indefinitely unless you configure lifecycle rules to expire noncurrent versions. When a user exercises their GDPR right to erasure (Art.17 GDPR) and you delete the object, S3 does not delete the data — it creates a delete marker. The previous versions remain as "noncurrent" objects, accessible through the API, visible in S3 Inventory, and reachable under a CLOUD Act order.

Developers who implement GDPR deletion workflows by calling DeleteObject without disabling versioning first are not actually deleting data. The noncurrent versions persist until explicitly expired via lifecycle policy or deleted individually.

# Audit which buckets have versioning enabled
aws s3api list-buckets --query 'Buckets[].Name' --output text | \
  tr '\t' '\n' | xargs -I{} aws s3api get-bucket-versioning --bucket {}

To actually delete all versions of an object for GDPR compliance, you must list and delete every version explicitly:

# List all versions including delete markers
aws s3api list-object-versions --bucket your-bucket --prefix user-data/user-123/ \
  --query '{Versions:Versions[].{Key:Key,VersionId:VersionId},Deletes:DeleteMarkers[].{Key:Key,VersionId:VersionId}}'

This complexity is itself a compliance risk: engineering teams under time pressure frequently implement incomplete deletion that satisfies the API call but not the legal requirement.

S3 Object Lock (WORM): Compliance Features That Block GDPR Compliance

S3 Object Lock allows objects to be written once and retained for a fixed period — the WORM (Write Once Read Many) model required by financial regulations like SEC Rule 17a-4 and FINRA. Object Lock has two modes: Governance (protected but overridable by admin) and Compliance (no override possible, not even by AWS).

Here is the tension: Object Lock is designed to make data undeletable. GDPR Art.17 requires data to be deleteable. For organizations storing financial transaction records that include personal data — payment amounts, counterparty identifiers, IP addresses — Object Lock and GDPR are structurally in conflict.

More critically for CLOUD Act exposure: Compliance-mode Object Lock ensures that objects cannot be deleted even during the retention period, which means that personal data locked for a 7-year financial compliance period is guaranteed to exist and be accessible to US government requests for the entire duration.

S3 Replication: The Art.44 Transfer You Configured Yourself

S3 Cross-Region Replication (CRR) automatically copies objects from a source bucket to a destination bucket in a different region. If you have a disaster recovery configuration that replicates from eu-central-1 to us-east-1, you have configured an explicit cross-border data transfer under Art.44 GDPR — one that requires adequate safeguards that S3 CRR does not provide by itself.

More subtly: S3 Same-Region Replication (SRR) between two buckets in eu-central-1 does not create an Art.44 issue, but it does double the scope of data accessible under a CLOUD Act order. Both source and destination buckets are accessible.

# Identify all replication configurations across your buckets
aws s3api list-buckets --query 'Buckets[].Name' --output text | \
  tr '\t' '\n' | while read bucket; do
    result=$(aws s3api get-bucket-replication --bucket "$bucket" 2>/dev/null)
    if [ -n "$result" ]; then
      echo "REPLICATION: $bucket"
      echo "$result" | python3 -c "import json,sys; r=json.load(sys.stdin); [print(f'  → {d[\"Destination\"][\"Bucket\"]} Region:{d[\"Destination\"].get(\"StorageClass\",\"STANDARD\")}') for d in r['ReplicationConfiguration']['Rules']]"
    fi
  done

S3 Transfer Acceleration: EU Data Through US Infrastructure

S3 Transfer Acceleration routes uploads through CloudFront edge locations to the S3 bucket. The purpose is to improve upload speed for geographically distributed users. The consequence is that data transits through AWS's global edge network — including US-based points of presence — before reaching the bucket.

This transit does not create an Art.44 transfer in the traditional sense (data lands in your EU bucket), but it does mean that data passed through infrastructure under direct US jurisdiction during transmission. For organizations subject to strict data minimization requirements or that have made specific representations about data routing to their DPO, Transfer Acceleration is worth auditing.

S3 Intelligent-Tiering and Glacier: The Archives Your DPA Forgets

S3 Intelligent-Tiering automatically moves objects between access tiers based on access frequency. Objects that are not accessed for 30 days move to the Infrequent Access tier; after 90 days to Archive Instant Access. Developers often enable Intelligent-Tiering for cost optimization without considering that the archived tier objects are still personal data subject to GDPR rights — but the retrieval process (Glacier Instant Retrieval, Expedited Retrieval) is now more complex.

The practical compliance risk: when a user requests their data (Art.15 GDPR subject access request), the S3 Glacier Flexible Retrieval tier has restore times of 3-12 hours for Standard retrieval. Meeting the 30-day GDPR response deadline becomes operationally harder when the data is in deep archive. And the data remains fully accessible to CLOUD Act orders regardless of its Glacier tier.

S3 Event Notifications: The Processing Chain Under US Jurisdiction

S3 can publish event notifications to Lambda, SQS, SNS, and EventBridge when objects are created, deleted, or modified. These notifications include the object key, size, and ETag — potentially including PII embedded in filenames or paths. The notification itself is a data processing operation. Lambda, SQS, SNS, and EventBridge are all AWS services under the same US jurisdiction as S3.

If you use S3 events to trigger a processing pipeline — image resizing, virus scanning, ETL jobs — the entire pipeline operates under US law. A CLOUD Act order that reaches S3 also reaches the triggered Lambda function, the SQS queue containing the event, and the downstream services.

S3 Inventory: AWS-Generated Metadata Under US Jurisdiction

S3 Inventory generates CSV, ORC, or Parquet files listing all objects in a bucket, including object metadata: key name, size, last modified date, ETag, replication status, and encryption status. This inventory is itself a data asset — one that AWS generates and stores in another S3 bucket.

For buckets containing user-generated content, the object keys often embed personal information: uploads/user-456/profile-photo-2024-03.jpg, invoices/customer-789/invoice-2025-12.pdf. S3 Inventory creates a queryable catalog of this PII-embedding metadata that is stored separately from the objects themselves. A CLOUD Act order served on AWS can compel production of the inventory files as well as the objects they describe.

AWS KMS with S3: Why Encryption Alone Does Not Help

S3 Server-Side Encryption with AWS KMS (SSE-KMS) is frequently cited as a GDPR compliance control. The reasoning is: "Our data is encrypted with our own KMS key (CMK), so AWS cannot read it." This reasoning is incorrect in two ways.

First, AWS KMS is an AWS service. The customer-managed key (CMK) stored in KMS is protected by AWS's HSMs, which are under US jurisdiction. A CLOUD Act order can compel AWS to use the CMK to decrypt data, even if the order is served without the customer's knowledge. The customer's ability to "disable" or "delete" the CMK provides a technical control, but only if exercised before the CLOUD Act order is served — not after.

Second, SSE-KMS does not prevent AWS from accessing object metadata, access patterns, or the fact of the objects' existence. Even fully encrypted, the S3 bucket's existence, object count, size distribution, and access logs are observable by AWS and accessible under US law.

For data at rest to be outside CLOUD Act reach, the encryption must be performed client-side before the data reaches AWS — using keys that AWS never possesses. S3 Client-Side Encryption (CSE) achieves this, but it means AWS cannot serve the data directly (presigned URLs without the encryption key are useless), and it significantly complicates application architecture.

EU-Native S3 Alternatives

The following object storage services are operated by European-headquartered companies with no US parent, eliminating the CLOUD Act jurisdiction problem.

MinIO

MinIO is an Apache 2.0-licensed, S3-compatible object storage server that you deploy on your own infrastructure. It is the most widely used S3-compatible alternative, with full API compatibility including multipart uploads, presigned URLs, versioning, and object locking.

Deployed on EU infrastructure (Hetzner, OVHcloud, or your own servers), MinIO eliminates third-party cloud jurisdiction entirely. The data is on your hardware, governed by EU law.

MinIO is appropriate for organizations with sufficient operational capacity. The trade-off is operational responsibility: you manage replication, availability, storage expansion, and software updates. MinIO supports active-active replication across multiple sites, which is needed for production durability.

For teams deploying on sota.io (EU-native PaaS), MinIO can be run as a containerized service with persistent storage — no US-parent cloud provider in the stack.

Scaleway Object Storage

Scaleway is a French cloud provider (Iliad Group) offering S3-compatible object storage in Paris and Amsterdam data centers. Scaleway is subject to French law and EU jurisdiction, with no US parent company.

Scaleway Object Storage is production-ready, supports multipart uploads, presigned URLs, and bucket policies. Pricing is competitive with AWS S3. The service lacks some AWS-specific features (Intelligent-Tiering, Object Lock), which may be a constraint for specific compliance use cases — but eliminates those same features as GDPR risks.

Hetzner Object Storage

Hetzner Online GmbH is a German company operating data centers in Nuremberg, Falkenstein, and Helsinki. Hetzner Object Storage is S3-compatible and designed as a direct S3 replacement for EU customers.

Hetzner has a strong reputation for price-performance and GDPR compliance. German data protection law (BDSG) applies alongside GDPR. For EU customers storing non-sensitive data, Hetzner Object Storage is one of the lowest-cost options available from an EU-headquartered provider.

Exoscale Object Storage (Simple Object Storage)

Exoscale is a Swiss cloud provider (A1 Digital International) operating in Switzerland, Austria, Germany, and Bulgaria. Switzerland is not an EU member but has been granted adequacy status by the EU Commission (since 2021 via the Swiss nFADP framework equivalent), making data transfers to Swiss providers permissible under Art.45 GDPR without additional safeguards.

Exoscale SOS is S3-compatible and designed for compliance-sensitive workloads. Swiss data protection law (nFADP) is one of the strictest in the world, aligned with GDPR. For organizations that want the strongest possible data protection posture, Swiss jurisdiction adds a layer beyond EU member state requirements.

OVHcloud Object Storage

OVHcloud is a French cloud provider (OVH SAS) with data centers throughout the EU. OVHcloud Object Storage (Swift API and S3-compatible API) is designed for EU enterprise customers with explicit GDPR compliance commitments.

OVHcloud publishes detailed data processing agreements and has obtained ENISA Cloud Security Alliance (CSA STAR) certification. The company's EU governance structure and no-US-parent setup make it a natural S3 alternative for organizations already using OVHcloud for compute.

Migration Guide: From S3 to EU-Native Object Storage

Migrating from S3 to an EU-native alternative requires auditing your current state before moving data.

Step 1: Inventory your buckets and features in use

# List all buckets with their regions
aws s3api list-buckets

# For each bucket, check which features are enabled:
# Versioning
aws s3api get-bucket-versioning --bucket YOUR_BUCKET

# Replication
aws s3api get-bucket-replication --bucket YOUR_BUCKET 2>/dev/null

# Object Lock
aws s3api get-object-lock-configuration --bucket YOUR_BUCKET 2>/dev/null

# Lifecycle rules (to understand data flows)
aws s3api get-bucket-lifecycle-configuration --bucket YOUR_BUCKET 2>/dev/null

# Event notifications (to map the processing pipeline)
aws s3api get-bucket-notification-configuration --bucket YOUR_BUCKET

Step 2: Migrate data with rclone

rclone supports both S3 (source) and S3-compatible destinations (Scaleway, Hetzner, MinIO) natively:

# Configure rclone with both AWS and destination credentials
rclone config

# Sync a bucket to EU-native storage
rclone sync s3:your-bucket scaleway:your-new-bucket \
  --progress \
  --transfers 32 \
  --checkers 16 \
  --s3-chunk-size 100M

# Verify transfer completeness
rclone check s3:your-bucket scaleway:your-new-bucket

Step 3: Update application code

The AWS SDK s3Client can be pointed at any S3-compatible endpoint. The API calls remain identical:

import { S3Client } from "@aws-sdk/client-s3";

// Before: AWS S3
const s3 = new S3Client({ region: "eu-central-1" });

// After: Scaleway (or any S3-compatible endpoint)
const s3 = new S3Client({
  region: "fr-par",
  endpoint: "https://s3.fr-par.scw.cloud",
  credentials: {
    accessKeyId: process.env.SCW_ACCESS_KEY!,
    secretAccessKey: process.env.SCW_SECRET_KEY!,
  },
});

The S3Client configuration change is the only code modification required for most S3 operations. Bucket operations, object operations, presigned URLs, and multipart uploads all work identically against S3-compatible endpoints.

Step 4: Audit for S3-specific features that have no direct equivalent

S3-specific features that may require workarounds:

• S3 Transfer Acceleration: Eliminate it — it was routing through US infrastructure anyway
• S3 Intelligent-Tiering: Replace with explicit lifecycle rules or accept flat storage pricing
• S3 Object Lock (Compliance mode): MinIO supports object locking; Scaleway/Hetzner support is partial
• S3 Inventory: Replace with scheduled rclone lsjson outputs stored in your own infrastructure
• S3 Event Notifications: Replace with MinIO event notifications (Kafka/NATS/Webhook) or polling

Step 5: Update your DPIA

After migration, update your Data Protection Impact Assessment to reflect:

• New controller-processor relationship with EU-native provider
• Elimination of Art.44 transfer risk
• Updated third-country transfer register (S3 should be removed)
• New data processing agreement with the EU provider

The Regulatory Timeline

The CLOUD Act has been in force since 2018. The EU-US Data Privacy Framework was adopted in 2023 but faces ongoing legal challenges at the Court of Justice of the EU — the same challenge pattern that invalidated Privacy Shield (2020) and Safe Harbor (2015) before it. Organizations relying on the DPF as their sole CLOUD Act mitigation are building on a legally fragile foundation.

EU data protection authorities have issued increasing enforcement activity on cloud jurisdiction since 2021. The Austrian DSB ruling on Google Analytics (2022), the French CNIL's Meta Pixel guidance, and the European Data Protection Board's guidelines on international transfers have all pointed in the same direction: using US-owned cloud services to process EU personal data requires robust legal justification that survives scrutiny.

S3 is the foundational storage layer for most cloud architectures. Getting the jurisdiction right at the storage layer eliminates a compliance risk that propagates through every service that reads from and writes to that storage.

Summary

S3 is not the only AWS service with jurisdiction problems — but it is the most fundamental. Every database backup, every user upload, every log archive that passes through S3 passes through US jurisdiction. Migrating S3 first removes the largest surface area of CLOUD Act exposure in a typical AWS architecture.

For teams building new applications or migrating existing ones to EU-compliant infrastructure, sota.io provides EU-native managed hosting (Frankfurt, Helsinki) where object storage runs on European infrastructure from the ground up — no US-parent cloud provider in the stack.

See Also

• AWS RDS EU Alternative 2026 — Relational DB: migrate your PostgreSQL backups away from S3 at the same time
• AWS ElastiCache EU Alternative 2026 — Redis/Memcached: RDB snapshot exports use S3 as the migration path
• AWS DynamoDB EU Alternative 2026 — NoSQL: PITR backups and exports land in S3, jurisdiction chain extends here
• Vercel EU Alternative 2026 — Compute/CDN layer: Vercel Blob storage has the same US-parent jurisdiction problem
• Hetzner Price Increase: EU PaaS Alternative 2026 — EU-native object storage pricing context