AWS RDS EU Alternative 2026: GDPR, CLOUD Act, and the Managed Relational Database Jurisdiction Problem

Post #680 in the sota.io EU Compliance Series

Amazon Relational Database Service (RDS) is the world's most widely deployed managed relational database platform. It supports PostgreSQL, MySQL, MariaDB, Oracle Database, Microsoft SQL Server, and Amazon Aurora — a proprietary MySQL/PostgreSQL-compatible engine. For developers who need a managed relational database without operating their own servers, RDS has long been the default choice.

AWS has a Frankfurt region (eu-central-1) and a Stockholm region (eu-north-1). It provides a GDPR Data Processing Addendum, Standard Contractual Clauses, and a long list of certifications including ISO 27001, SOC 2, and BSI C5 (a German cloud security standard).

The problem is structural: Amazon Web Services, Inc. is incorporated in Delaware and is a wholly-owned subsidiary of Amazon.com, Inc., a US entity headquartered in Seattle, Washington. The CLOUD Act (18 U.S.C. § 2713) binds every US-incorporated company, regardless of where their servers physically sit. A valid US government order — bypassing European courts entirely — can compel AWS to hand over data stored in Frankfurt: your RDS snapshots, Multi-AZ replicas, Performance Insights logs, and query execution plans.

The same legal analysis that applies to Neon, PlanetScale, MongoDB Atlas, and Firebase applies here. An EU region is a geographic fact about infrastructure. It is not a legal statement about who holds the keys to your data under US federal law.

This post analyses AWS RDS's GDPR and CLOUD Act exposure service by service, and maps the best EU-native managed relational database alternatives for teams that need genuine data sovereignty in 2026.

What AWS RDS Actually Is

AWS RDS is not a single product — it is a family of managed services that provision, replicate, back up, monitor, and connect to relational databases on your behalf.

Each of these components is a distinct CLOUD Act surface. A US government order directed at AWS does not need to specify "the primary RDS instance" — it can compel production of any or all of the above.

The CLOUD Act Problem with AWS RDS

The CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) amended the Stored Communications Act with a single sentence that has enormous jurisdictional reach (18 U.S.C. § 2713):

"A provider of electronic communication service or remote computing service shall comply with the obligations of this chapter to preserve, backup, or disclose the contents of a wire or electronic communication and any record or other information pertaining to a customer or subscriber within such provider's control, regardless of whether such communication, record, or other information is located within or outside of the United States."

Amazon Web Services, Inc. falls squarely within this definition:

• US-incorporated: Delaware, registered 2006
• US-controlled: Subsidiary of Amazon.com, Inc. (NASDAQ: AMZN), headquartered in Seattle, WA
• US investor structure: NYSE-listed, SEC-regulated parent company
• US executive leadership: AWS CEO, CTO, and General Counsel are all US-based employees of a US corporation

The BSI C5 attestation that AWS holds for eu-central-1 is a German government cloud security assessment. It attests to technical security controls (encryption, access management, logging) and is issued by the German Federal Office for Information Security. BSI C5 does not create a legal barrier to CLOUD Act compulsion. It is not designed to, and the BSI has never claimed otherwise. A C5 attestation certifies that AWS implements certain security measures; it says nothing about whether a US federal court can compel AWS to produce your data.

Similarly, AWS's Standard Contractual Clauses and GDPR DPA establish contractual obligations between you (data controller) and AWS (data processor). The CLOUD Act operates outside this contractual relationship — it is a statutory obligation on AWS as a US entity that AWS cannot disclaim by contract.

AWS RDS Service-by-Service GDPR Analysis

Performance Insights: The Hidden PII Risk

Performance Insights is an RDS feature that captures top SQL queries, digest plans, wait events, and execution latency. It is frequently enabled by default in AWS-managed environments and in AWS console defaults.

Performance Insights stores verbatim SQL text — including literal values in queries that have not been parameterised. If your application issues queries like:

SELECT * FROM users WHERE email = 'alice@example.com';
UPDATE orders SET status = 'shipped' WHERE customer_id = 12345;

Performance Insights stores those queries, with those literal values, in its own data store. Under GDPR Article 35, this represents a secondary processing activity — one that EU organisations may not have assessed separately in their Data Protection Impact Assessment when they evaluated RDS itself.

A CLOUD Act order directed at AWS can compel production of Performance Insights data alongside the primary RDS snapshot. For healthcare, financial, or legal applications where query text may contain personal data, this is a significant and frequently overlooked risk.

Aurora: Distributed Storage as a CLOUD Act Multiplier

Amazon Aurora uses a proprietary distributed storage engine: data is automatically replicated across six storage nodes distributed across three Availability Zones within a region. Aurora does not use traditional database replication — the storage layer itself is the replication unit.

From a CLOUD Act perspective, this architecture changes nothing legally (all six storage nodes are within AWS's CLOUD Act-obligated control) but it means that even a "small" Aurora cluster involves significantly more physical storage endpoints than a standard RDS PostgreSQL instance. All of those endpoints — and all Aurora Global Database secondaries (which may reside in US regions such as us-east-1) — are compellable.

EU organisations using Aurora Global Database with a US secondary read replica have explicitly routed EU personal data into a US AWS region. This is not an EU-region-only deployment even in the AWS console sense.

RDS Proxy: Connection Logs and Session Data

RDS Proxy is a serverless connection pool layer positioned between application clients (commonly AWS Lambda functions) and RDS instances. It is marketed as a reliability and cost-optimisation feature for high-connection serverless architectures.

RDS Proxy logs include:

• Client connection metadata (source IP, IAM principal, timestamp)
• Database target endpoints
• Session duration and connection state
• Error events (including authentication failures that may include username values)

These logs are stored in Amazon CloudWatch Logs under AWS control and are subject to the same CLOUD Act regime as the RDS data itself.

GDPR Risk Assessment: AWS RDS in the EU

Under GDPR Article 44, personal data may only be transferred to a third country if the Commission has adopted an adequacy decision, or if appropriate safeguards (SCCs, BCRs) are in place. The EU-US Data Privacy Framework (DPF, 2023) creates a transfer mechanism — but DPF certification is voluntary, and more critically, the DPF does not override CLOUD Act compulsion for data stored in the EU.

The core GDPR issue with AWS RDS in Frankfurt is not transfer risk (your data does not physically leave the EU). It is access risk: under the CLOUD Act, a US entity has a legal obligation to produce EU-stored data upon valid US government request, without notifying the data subject or the EU supervisory authority.

The EDPB's 2021 Recommendations (01/2020) on supplementary measures specify that technical measures (encryption, pseudonymisation) can only address CLOUD Act risk if the data is encrypted before leaving your control, with keys you exclusively hold. Standard AWS encryption (SSE with AWS-managed keys, or AWS KMS) does not satisfy this requirement — AWS holds the key material and can therefore produce plaintext under CLOUD Act compulsion.

If you use AWS KMS with customer-managed keys stored in AWS, AWS still controls the key management service and can produce key material under CLOUD Act order. Only client-side encryption with keys entirely outside AWS (on your own infrastructure or with a European KMS provider) would technically resolve the access risk — but this approach is incompatible with standard RDS query execution, which requires the database engine to access plaintext data.

In practical terms: there is no configuration of AWS RDS that removes CLOUD Act jurisdiction while remaining operationally functional as a relational database.

EU-Native Managed Relational Database Alternatives

The following providers are incorporated in EU member states (or EFTA members Switzerland and Norway), operate EU-based infrastructure, and are not subsidiaries of US parent companies.

1. Scaleway Managed Databases

Headquarters: Paris, France
Entity: Scaleway SAS (subsidiary of Iliad SA, a French telecommunications group — not US-controlled)
Engines: PostgreSQL (up to v16), MySQL (8.0)
Regions: Paris (fr-par), Amsterdam (nl-ams), Warsaw (pl-waw)

Scaleway Managed Databases offer automated backups, read replicas, and connection pooling via pgBouncer. The offering is more limited than RDS in raw features but covers the core managed PostgreSQL/MySQL use case for GDPR-sensitive workloads.

GDPR stance: Iliad SA is a French entity with no US corporate parent. Standard Contractual Clauses are available. Scaleway explicitly markets its EU data sovereignty credentials.

Migration from RDS: Standard PostgreSQL dump/restore (pg_dump / pg_restore), or aws_s3 extension for snapshot-based migrations. MySQL: mysqldump or AWS DMS equivalent.

2. OVHcloud Managed Databases

Headquarters: Roubaix, France
Entity: OVH SAS (OVHcloud group, privately held French company)
Engines: PostgreSQL (v14/15/16), MySQL (8.0), Redis, OpenSearch, Kafka, Cassandra, M3DB, Grafana
Regions: Multiple EU regions (GRA, SBG, DE1, UK1, WAW)

OVHcloud's managed database portfolio is broader than any other EU-native provider. For teams migrating from RDS PostgreSQL, MySQL, or Aurora-compatible MySQL, OVHcloud provides direct engine equivalents.

GDPR stance: OVH SAS is a French entity. No US corporate parent. French data protection law (loi Informatique et Libertés) applies at the domestic level in addition to GDPR.

Migration path: Standard pg_dump/mysqldump for smaller databases. OVHcloud provides migration documentation for cross-cloud moves. For large databases, physical replication (pg_basebackup to a standby that then promotes) is faster than logical backup/restore.

3. Exoscale Managed PostgreSQL

Headquarters: Vienna, Austria
Entity: Akenes SA (Exoscale parent, Swiss company)
Engines: PostgreSQL (v14/15/16), MySQL (8.0), Redis, Kafka, OpenSearch
Regions: Vienna (AT-VIE), Frankfurt (DE-FRA), Zurich (CH-GVA), Geneva (CH-GVA2), Sofia (BG-SOF), Munich (DE-MUC)

Exoscale is a Swiss cloud provider with strong EU coverage and a particular focus on enterprise GDPR compliance. It holds ISO 27001 certification and explicitly positions itself as a CLOUD Act-free alternative.

GDPR stance: Akenes SA is Swiss-incorporated. Switzerland has adequate protection status under GDPR (Commission adequacy decision, 2000, updated 2023). No US corporate parent.

Differentiator: Swiss legal jurisdiction provides an additional layer of protection beyond EU-member-state law. Swiss Federal Act on Data Protection (nFADP) aligns closely with GDPR.

4. UpCloud Managed Databases

Headquarters: Helsinki, Finland
Entity: UpCloud Ltd (Finnish company, no US parent)
Engines: PostgreSQL (v14/15/16), MySQL (8.0), Redis, OpenSearch
Regions: Frankfurt (DE-FRA), Amsterdam (NL-AMS), Helsinki (FI-HEL), Warsaw (PL-WAW), Madrid (ES-MAD), plus others

UpCloud offers managed databases built on the open-source Aiven platform (also Finnish-founded, though now US-incorporated — see note below). UpCloud's entity itself remains Finnish.

GDPR stance: UpCloud Ltd is a Finnish entity. EU-incorporated. No US parent.

Note on Aiven: Aiven Oy originated in Finland and is widely used for EU-compliant database hosting, but Aiven Inc. (its US entity) received significant US venture funding and incorporated in Delaware. Teams with strict US-entity exclusion requirements should confirm Aiven's current corporate structure with their DPO before selecting Aiven directly.

5. Clever Cloud Managed PostgreSQL / MySQL

Headquarters: Nantes, France
Entity: Clever Cloud SAS (French company, no US parent)
Engines: PostgreSQL, MySQL, MongoDB (TBD), Redis
Regions: Paris (PAR), Roubaix (RBX), Warsaw (WSW), Montreal (MTL — not EU)

Clever Cloud is a French PaaS that includes managed databases as first-class components of its deployment model. It is particularly suited to teams that deploy applications and databases together on a single European PaaS rather than combining separate cloud vendors.

GDPR stance: Clever Cloud SAS is French-incorporated. ISO 27001 certified. Member of the French Tech association.

6. Self-Hosted PostgreSQL on EU-Only IaaS

For teams that require maximum control over GDPR compliance posture and have operational capacity to manage database infrastructure, self-hosted PostgreSQL on EU-only infrastructure eliminates CLOUD Act risk entirely.

Recommended EU-only IaaS providers:

PostgreSQL deployment options on these providers:

• Patroni + etcd: Production-grade HA cluster with automatic failover
• Supabase self-hosted: Full Postgres + Auth + Storage stack on your own VMs
• CloudNativePG (CNPG): Kubernetes-native PostgreSQL operator, supports streaming replication, backup to S3-compatible storage (Hetzner Object Storage, Scaleway Object Storage)
• pgEdge Community: Multi-master distributed Postgres for low-latency reads across EU regions

Migration Guide: AWS RDS PostgreSQL → EU-Native Alternative

Step 1: Inventory your RDS dependencies

Before migrating, audit your RDS configuration for AWS-specific features that have no direct equivalent:

# Check for RDS-specific parameter groups
aws rds describe-db-parameter-groups --region eu-central-1

# Check for RDS Proxy usage
aws rds describe-db-proxies --region eu-central-1

# Check for Performance Insights retention
aws rds describe-db-instances \
  --query 'DBInstances[*].{ID:DBInstanceIdentifier,PI:PerformanceInsightsEnabled}' \
  --region eu-central-1

# Check for Aurora-specific features
aws rds describe-db-clusters \
  --query 'DBClusters[*].{ID:DBClusterIdentifier,Engine:Engine,Mode:EngineMode}' \
  --region eu-central-1

Common blockers to resolve before migration:

• aws_s3 extension (RDS-specific S3 integration) → replace with standard COPY + EU object storage
• aws_commons extension → remove, use standard PostgreSQL
• IAM DB Auth → replace with certificate-based auth or password auth on target
• RDS Proxy → replace with pgBouncer on EU infrastructure
• Performance Insights → replace with pg_stat_statements + Prometheus + Grafana on EU infrastructure

Step 2: Export data from RDS

For databases under 50 GB:

# Logical dump (works across major PostgreSQL versions)
pg_dump \
  --host=your-rds-endpoint.eu-central-1.rds.amazonaws.com \
  --username=postgres \
  --dbname=your_database \
  --format=directory \
  --jobs=4 \
  --file=/path/to/backup/dir

For databases over 50 GB, use physical replication: set up your EU target as a streaming replica of the RDS source, allow it to catch up to near-real-time, then promote it and switch application traffic.

# On EU target server: configure recovery.conf (pg <12) or postgresql.conf (pg >=12)
primary_conninfo = 'host=your-rds-endpoint port=5432 user=replicator password=...'
primary_slot_name = 'migration_slot'

# On RDS source: create replication slot
SELECT pg_create_physical_replication_slot('migration_slot');

Step 3: Restore on EU-native target

# Restore logical dump
pg_restore \
  --host=your-eu-managed-db-endpoint \
  --username=postgres \
  --dbname=your_database \
  --format=directory \
  --jobs=4 \
  /path/to/backup/dir

Step 4: Validate and cut over

# Verify row counts match
psql -h eu-target-host -c "SELECT schemaname, tablename, n_live_tup FROM pg_stat_user_tables ORDER BY n_live_tup DESC LIMIT 20;"

# Compare against RDS source
psql -h rds-source-host -c "SELECT schemaname, tablename, n_live_tup FROM pg_stat_user_tables ORDER BY n_live_tup DESC LIMIT 20;"

# After validation: update application connection strings
# Recommended: use a connection string environment variable so cutover is a config change
DATABASE_URL=postgresql://user:pass@eu-target-host:5432/your_database

Comparison Table: AWS RDS vs EU Alternatives

Legal Checklist: AWS RDS GDPR Compliance in the EU

Before continuing to use AWS RDS in the eu-central-1 region for personal data, your DPO should confirm the following:

• DPIA conducted — Data Protection Impact Assessment explicitly addresses CLOUD Act risk under Art. 35
• Supplementary measures assessed — EDPB Recommendations 01/2020 analysis: can technical measures (client-side encryption) effectively neutralise CLOUD Act risk? (Answer for standard RDS: No)
• Art. 49 derogations assessed — Is there a legitimate derogation for transfers to the US under Art. 49? (Typically: No, for routine processing)
• Supervisory authority notification — If high-risk processing, has your lead supervisory authority been notified?
• Data subject transparency — Do your privacy notices disclose that data is processed by a US-incorporated entity subject to CLOUD Act?
• DPA terms reviewed — AWS DPA reviewed by legal counsel; CLOUD Act carve-outs and government disclosure provisions identified
• Performance Insights audit — Does Performance Insights capture query text containing personal data? If yes, this is a secondary processing activity requiring separate assessment
• Aurora Global Database audit — If using Aurora Global with US secondaries, you have an explicit cross-border transfer of personal data to the US

Conclusion

AWS RDS Frankfurt is excellent infrastructure. It is operationally mature, deeply integrated with the AWS ecosystem, and backed by a large support organisation. The Frankfurt region is technically capable of hosting personal data.

It is not legally capable of providing CLOUD Act immunity — because no AWS region is. AWS is a US company. The CLOUD Act applies to US companies. That is the entire analysis.

For EU organisations processing personal data subject to GDPR, the question is not "is AWS RDS technically secure?" (it is) but "does our DPA require that we select processors who are not subject to foreign surveillance laws that can compel disclosure without EU judicial process?" (often: yes).

The alternatives — Scaleway, OVHcloud, Exoscale, UpCloud, Clever Cloud, or self-hosted PostgreSQL on Hetzner — are operationally mature enough for most production relational database workloads in 2026. The pricing is frequently lower. The CLOUD Act exposure is absent.

AWS RDS is the right choice for teams that have assessed the CLOUD Act risk, documented it in their DPIA, and concluded that it is acceptable for their specific processing activities. For teams where it is not acceptable, the migration path is well-established.

See also:

• Neon EU Alternative 2026 — Serverless PostgreSQL
• PlanetScale EU Alternative 2026 — Serverless MySQL / Vitess
• MongoDB Atlas EU Alternative 2026 — NoSQL / Document Store
• Firebase EU Alternative 2026 — BaaS / Firestore
• Supabase EU Alternative 2026 — Open-source Firebase Alternative