AWS Route 53 EU Alternative 2026: DNS, Query Logs, and the CLOUD Act Problem

Post #701 in the sota.io EU Compliance Series

AWS Route 53 is the DNS service most AWS-hosted applications use by default. It resolves domain names to IP addresses, routes traffic across regions, monitors endpoint health, and provides global load balancing — all integrated into the AWS ecosystem. Route 53 handles DNS for hundreds of thousands of domains, including many European applications that process personal data under GDPR.

Amazon operates Route 53 as a globally distributed service. DNS queries are answered from AWS edge locations worldwide, including locations in Frankfurt, Paris, Stockholm, and other EU cities. Many development teams interpret this as "our DNS runs in Europe."

It does not. Amazon Web Services, Inc. is a Delaware corporation headquartered in Seattle, Washington. The CLOUD Act (18 U.S.C. § 2713) compels US companies to produce data stored anywhere in the world when ordered by US authorities. Route 53's control plane — where zone configurations are stored, where query logs are collected, where health check results accumulate — is operated by Amazon Web Services, Inc. A valid government order can reach your Route 53 zone data regardless of which AWS edge location answered the DNS query.

This matters more than it might seem. DNS is the phone book of the internet, and the query log is a record of every call your users make. If Route 53 Resolver query logging is enabled, Amazon holds a timestamped log of every domain lookup your EU users performed — personal data under GDPR Art.4(1) when associated with IP addresses.

This analysis covers: what Route 53 stores under US jurisdiction, the GDPR implications of DNS query logs, health check data, and zone configurations, and the EU-native DNS alternatives that eliminate CLOUD Act exposure for European applications.

What AWS Route 53 Stores Under US Jurisdiction

DNS zone files and resource record sets. The foundation of Route 53 is the hosted zone — a container for DNS records (A, AAAA, CNAME, MX, TXT, NS, SOA records) that define how your domain resolves. Every hosted zone configuration, every resource record set, every routing policy is stored under US jurisdiction.

For most applications, zone file exposure is low-risk. DNS zone data is generally public by design — anyone can query your A records by asking a DNS resolver. However, Route 53 hosted zones can contain sensitive operational information: internal subdomain structures that reveal application architecture (api.internal.company.com, db-primary.internal.company.com, staging.company.com), SPF/DKIM/DMARC TXT records that document email authentication configuration, CAA records that specify authorized certificate authorities, and CNAME chains that reveal CDN and third-party service dependencies.

For EU organizations with data minimization obligations under GDPR Art.5(1)(c), the zone configuration held by Route 53 constitutes operational infrastructure data held by a US entity — a consideration for GDPR Article 30 Records of Processing Activities that document data processors.

Route 53 Resolver query logs. This is the highest-risk data category. When Route 53 Resolver query logging is enabled on a VPC, Amazon captures a log record for every DNS query that EC2 instances, Lambda functions, containers, or other resources in that VPC make. Each log record contains: the queried domain name, the query type (A, AAAA, MX, etc.), the response code (NOERROR, NXDOMAIN, SERVFAIL), the response IP addresses returned, a timestamp with millisecond precision, and the source IP address of the resource that made the query.

In a VPC serving EU user traffic, the source IP of a DNS query maps to a specific EC2 instance or container — which maps to a specific user session, transaction, or API request. The queried domain name reveals which external services your application accessed on behalf of that user: payment processor API domains, analytics services, authentication providers, external data sources. Correlated with application logs, Route 53 Resolver query logs constitute a detailed record of EU user activity patterns.

Route 53 Resolver query logs are typically stored in Amazon CloudWatch Logs or Amazon S3 — both services under US jurisdiction. If enabled, Amazon holds a complete record of your application's external service access patterns, timestamped to the millisecond, stored under CLOUD Act jurisdiction.

Query logs are not enabled by default, but the option exists and is commonly enabled for debugging, security monitoring, and compliance auditing purposes. Many organizations enable them temporarily for troubleshooting and forget to disable them.

Health check monitoring results and configuration. Route 53 health checks monitor the availability of endpoints — web servers, load balancers, application APIs — and use the results to route traffic away from unhealthy endpoints. Health check configuration includes: the endpoint URL or IP address being monitored, the protocol and port, request headers (including Host headers that may contain customer-specific subdomain information), expected response strings, monitoring intervals, failure thresholds, and notification configurations.

Health check results — pass/fail status for each check interval, response time measurements, the reason strings Amazon generates for failures — are stored under US jurisdiction. For applications with SLA obligations under EU contracts, the health check failure history stored in Route 53 constitutes a record of service availability that may be relevant to contractual disputes or NIS2 Article 23 incident reporting obligations.

For Route 53 health checks configured to monitor endpoints that serve personal data, the health check request logs — including response bodies if string matching is configured — may contain personal data excerpts stored under US jurisdiction.

Traffic Flow policies and routing configuration. Route 53 Traffic Flow provides visual policy management for complex routing scenarios: geolocation routing (directing EU users to EU endpoints), weighted routing (canary deployments, A/B tests), latency-based routing (directing users to the fastest region), and failover routing (active-passive configurations). Traffic Flow policies are stored as JSON policy documents under US jurisdiction.

For EU organizations using geolocation routing to ensure EU user data stays in EU regions, the routing policy configuration held by Route 53 is itself sensitive: it documents which IP address ranges are classified as EU, which endpoints serve EU users, and how traffic is partitioned — information that, in context, reveals the data residency architecture of the application.

DNSSEC signing keys. Route 53 supports DNSSEC for hosted zones — cryptographic signing of DNS responses to prevent DNS spoofing attacks. When DNSSEC is enabled, Route 53 generates and manages the Zone Signing Key (ZSK) and Key Signing Key (KSK) for the hosted zone using AWS Key Management Service (KMS). The DNSSEC key material is held under US jurisdiction via KMS.

For EU organizations in regulated sectors (financial services, healthcare, critical infrastructure), DNSSEC key management under a US entity raises questions under NIS2 Article 21(2)(h) (supply chain security) and applicable sector-specific regulations. The key signing keys that provide cryptographic guarantees for your domain's DNS responses are controlled by a US corporation.

Route 53 Domains registration data. For domains registered through Route 53 (rather than transferred in), Amazon acts as the domain registrar. Registrant data — organization name, technical and administrative contacts, billing information — is stored under US jurisdiction and shared with ICANN's WHOIS system subject to applicable domain registration policies. For EU registrants, this creates a data transfer to a US entity for personal contact data (GDPR Art.44).

CloudWatch alarms and SNS notifications for Route 53. Route 53 health checks can trigger CloudWatch alarms and SNS notifications when endpoints go unhealthy. The alarm history, notification payloads, and subscription configurations for Route 53-triggered alerts are stored in CloudWatch and SNS — both under US jurisdiction. For organizations using Route 53 alerts as part of incident response workflows, the alert history may contain operational security information about availability events.

GDPR Implications of AWS Route 53 for EU Applications

DNS query logs as personal data under GDPR Art.4(1). GDPR Article 4(1) defines personal data as "any information relating to an identified or identifiable natural person." IP addresses are personal data under established EU case law (CJEU C-582/14, Breyer v Bundesrepublik Deutschland, 2016). Route 53 Resolver query log records include source IP addresses — the IP of the EC2 instance or container that made the query, which in most architectures correlates to a specific user session.

When Route 53 Resolver query logging is enabled, Amazon is processing personal data on behalf of the EU controller (the organization operating the application). This processing relationship requires a Data Processing Agreement (DPA) under GDPR Article 28 covering the query log data. Amazon provides a DPA that includes SCCs for cross-border data transfers. However, the structural CLOUD Act exposure — a US government order can compel Amazon to produce these logs — is not resolved by SCCs. As established in Schrems II (CJEU C-311/18), standard contractual clauses cannot override US surveillance law when the data importer cannot comply with them.

Route 53 as infrastructure processor vs. data processor. For zone files and routing configuration without query logging, Route 53 operates more as an infrastructure service storing configuration data rather than personal data. This distinction matters for GDPR analysis: organizations may reasonably classify Route 53 zone configuration as non-personal-data infrastructure management. However, this analysis changes if query logging is enabled, if health checks process personal data (response content matching), or if domain registration personal data is held.

GDPR Art.25 — Privacy by Design for DNS architecture. GDPR Article 25(1) requires that controllers implement technical measures to integrate data protection into processing by design. For DNS architecture, this principle has a concrete implication: where a privacy-preserving DNS alternative exists (one not subject to US surveillance law), selecting it over a US-jurisdiction alternative is consistent with Privacy by Design. Selecting Route 53 when EU-native DNS alternatives provide equivalent functionality requires a documented justification — a Data Protection Impact Assessment (DPIA) that weighs the CLOUD Act exposure against the operational reasons for using Route 53.

GDPR Art.35 — DPIA requirement for query log processing. If Route 53 Resolver query logging is enabled for a production VPC that serves EU users, a DPIA is likely required under GDPR Article 35(1). The processing involves: systematic monitoring of user-correlated network activity (high-risk under Art.35(3)(c)), transfer of that monitoring data to a US entity subject to CLOUD Act, and potential disclosure to US law enforcement without EU user notification. The DPIA must assess whether query logging is necessary for the stated purpose and whether a less privacy-invasive alternative exists (EU-based DNS logging, application-level logging).

NIS2 supply chain risk for DNS. NIS2 Directive Article 21(2)(d) requires essential and important entities to implement supply chain security measures addressing ICT service providers. DNS is a critical dependency for internet-connected services — DNS failure makes an application unreachable. For NIS2 entities, reliance on Route 53 as the sole DNS provider creates a supply chain risk that should be assessed: the provider is a US entity, potentially subject to sanctions measures or government action that could affect service availability.

More concretely, the CLOUD Act creates a scenario where a US government order to Route 53 — in the context of a criminal or national security investigation involving a different customer — could disrupt DNS service through operational interference with the Route 53 control plane. This is a low-probability but high-impact scenario that NIS2 supply chain risk assessments should consider.

EU-Native DNS Alternatives to AWS Route 53

The DNS market has strong EU-native options that provide equivalent functionality without US jurisdiction exposure.

Hetzner DNS — Free, EU-native, no query logging. Hetzner Online GmbH is a German hosting provider based in Gunzenhausen, Bavaria. Hetzner DNS is a free managed DNS service with no query logging and no data processing beyond zone file storage. Hetzner provides an API for zone and record management. For organizations already using Hetzner for compute (Hetzner Cloud), using Hetzner DNS consolidates the infrastructure stack under a single EU entity.

Hetzner DNS lacks some Route 53 advanced features: no geolocation routing, no weighted routing, no health check integration. For applications requiring only standard DNS (A, AAAA, CNAME, MX, TXT records with reasonable TTLs), Hetzner DNS is a straightforward replacement. API documentation is available and Terraform providers exist for infrastructure-as-code management.

OVHcloud DNS — EU provider with full managed DNS. OVHcloud is a French company headquartered in Roubaix, France — Europe's largest cloud provider. OVHcloud provides managed DNS as part of its hosting services and as a standalone offering. OVHcloud DNS supports: anycast DNS delivery from EU-anchored infrastructure, DNSSEC, secondary DNS configuration, and API management. OVHcloud is subject to French law and EU GDPR, not US CLOUD Act jurisdiction.

For organizations requiring a more feature-complete managed DNS service with SLA guarantees, OVHcloud DNS offers paid tiers with additional capabilities. OVHcloud's infrastructure spans multiple EU countries with primary data centers in France and Germany.

Bunny DNS — EU CDN provider with integrated DNS. Bunny.net is a Slovenian company (Ljubljana, Slovenia) providing CDN and DNS services. Bunny DNS is a commercial DNS service with anycast delivery, a straightforward API, competitive pricing, and EU data processing. Bunny.net operates under Slovenian and EU law, not US jurisdiction. For organizations using Bunny CDN for content delivery, Bunny DNS provides an integrated stack under a single EU entity.

Bunny DNS supports: custom TTLs, DNSSEC, secondary DNS, GeoDNS routing (geolocation-based routing similar to Route 53 geolocation routing), and record-level analytics. The analytics feature — showing query volumes per record — does not expose individual query logs; it provides aggregated statistics without personal data association.

Scaleway DNS — EU cloud provider. Scaleway is a French cloud company (subsidiary of Iliad Group, Paris, France). Scaleway provides managed DNS as part of its Domains and DNS product offering. Scaleway DNS is integrated with Scaleway's compute and object storage infrastructure, supports API management via Scaleway's unified API, and provides DNSSEC support. For organizations building EU-native infrastructure on Scaleway compute, Scaleway DNS provides a consistent provider relationship under French/EU law.

INWX — German domain registrar with DNS. INWX GmbH is a German domain registrar and DNS provider based in Cologne. INWX provides managed DNS with a well-documented API, DNSSEC support, and secondary DNS services. For organizations requiring EU-jurisdiction domain registration (replacing Route 53 Domains), INWX handles both domain registration and DNS management under German law.

Self-hosted DNS: PowerDNS, BIND9, CoreDNS. For organizations with the operational capacity to manage their own DNS infrastructure, self-hosted DNS eliminates the third-party jurisdiction question entirely. The software is EU-controlled (subject to software licensing — all three are open source), the servers are EU-located, and there is no third-party data processor.

PowerDNS is a high-performance DNS server developed by a Dutch company (Open-Xchange AG subsidiary). It supports: a REST API for programmatic zone management, database-backed zone storage (PostgreSQL, MySQL, SQLite), DNSSEC, and a geographic load balancing module. PowerDNS Recursor (for resolver functionality) and PowerDNS Authoritative Server (for zone hosting) are separate components that can be deployed independently.

BIND9 is the reference DNS implementation, widely deployed globally. CoreDNS is a Go-based DNS server commonly used in Kubernetes environments (it is the default DNS for Kubernetes clusters) and can serve as an authoritative DNS server with plugin-based functionality. For Kubernetes-native organizations already running CoreDNS internally, extending it to handle external DNS zones is architecturally consistent.

Cloudflare DNS — not a GDPR-clean alternative. Cloudflare, Inc. is a Delaware corporation headquartered in San Francisco, California — a US entity subject to CLOUD Act. For EU organizations seeking to escape CLOUD Act exposure, Cloudflare DNS (including Cloudflare 1.1.1.1 as a resolver) does not resolve the jurisdiction problem. Cloudflare stores DNS query data under US jurisdiction and is subject to US government orders. Cloudflare's popularity in Europe does not change its legal status as a US data processor.

Migration: Moving from Route 53 to EU DNS

Zone export and import. Route 53 supports BIND-format zone file export via the CLI: aws route53 list-resource-record-sets --hosted-zone-id Z1234567890 | python3 -c "...". Most EU DNS providers accept BIND-format zone file imports. The migration process is: export all resource record sets from Route 53, convert to BIND format, import to the EU DNS provider, verify all records are correct, then update the NS records at your domain registrar.

Before changing NS records, reduce TTLs for all records to 60–300 seconds. This minimizes the propagation window during cutover — DNS caches will expire records quickly, and traffic will switch to the new provider within minutes rather than the 24–48 hours that high-TTL records require.

Health check replacement. Route 53 health checks can be replaced with external uptime monitoring services based in the EU. Hetrixtools is a Bulgarian company (EU) providing uptime monitoring. Freshping offers an EU-hosted option. Better Uptime (based in Estonia) provides HTTP/TCP monitoring with incident management. For organizations requiring DNS-integrated health check failover (Route 53's killer feature), Bunny DNS GeoDNS and commercial EU DNS providers support health-check-based failover via API.

DNSSEC migration. When migrating a DNSSEC-enabled zone, the process requires careful sequencing: disable DNSSEC at Route 53 (which removes the DS record from the parent zone), wait for the DS record TTL to expire at the parent zone, configure DNSSEC at the new provider, and publish the new DS record. Skipping the DS removal step causes DNSSEC validation failures during the transition period. Both the registrar (where the DS record lives) and the DNS provider must support DNSSEC for end-to-end signing.

Terraform migration. Most EU DNS providers have Terraform providers: petoju/terraform-provider-minio is commonly confused but petoju/terraform-provider-hetznerdns provides Hetzner DNS management; the OVH Terraform provider handles OVHcloud DNS; Bunny.net provides BunnyWay/bunnynet. For organizations managing Route 53 zones via aws_route53_zone and aws_route53_record Terraform resources, migration requires updating the provider configuration and resource types — the record data (IPs, TTLs) transfers directly.

What to Do About Route 53 Query Logging Now

If your organization has Route 53 Resolver query logging enabled on VPCs that serve EU users, the immediate action items are:

1. Audit query logging status. Run: aws route53resolver list-resolver-query-log-config-associations --region eu-central-1 (and other EU regions). List which VPCs have query logging enabled and where the logs are sent (CloudWatch Logs group or S3 bucket).

2. Assess whether query logging is required. Query logging serves legitimate purposes: DNS-based threat detection (identifying lookups to known malicious domains), compliance audit trails, and application debugging. If the purpose is achievable through application-level logging (which you control and can scope), query logging at the DNS level may not be necessary. Document the assessment under GDPR Art.5(2) accountability.

3. If query logging must continue, minimize retention. Set CloudWatch Logs retention to the minimum required for the stated purpose (7 days for debugging, 90 days for security monitoring). Do not retain query logs indefinitely. Implement lifecycle policies on S3 destinations.

4. Evaluate EU-native DNS resolver alternatives for VPCs. For VPCs in EU regions, consider running a private CoreDNS or PowerDNS Recursor instance as the VPC's DNS resolver, forwarding to EU authoritative servers. This keeps resolver query logs under your control (in your own infrastructure) rather than under Amazon's CLOUD Act jurisdiction.

The Structural Problem with Route 53 for EU Compliance

Route 53 is a well-engineered DNS service. Its availability record is strong, its integration with the AWS ecosystem is deep, and its advanced routing features (weighted, geolocation, latency, failover) make complex traffic management straightforward. These are real engineering advantages.

The structural problem is not Route 53's architecture — it is Route 53's ownership. Amazon Web Services, Inc. is a US corporation, and no amount of EU data center investment changes the legal obligation to comply with US government orders. For EU organizations where DNS query logs constitute personal data (because they're correlated with EU user sessions), storing those logs at a US entity creates a compliance exposure that cannot be resolved by contractual means alone.

This is the same analysis documented across the AWS stack: the technical capability exists in the EU, but the legal control does not. For EU development teams building applications subject to GDPR, the DNS layer — the first network hop that every user interaction triggers — deserves the same sovereignty analysis as the compute, storage, and database layers.

For applications where DNS is pure infrastructure (no query logging, no health checks on personal-data endpoints, no sensitive operational configuration), Route 53 exposure is limited. For applications with query logging enabled, with health checks against endpoints serving personal data, or with domain registration data processed by Amazon, the GDPR analysis points toward EU-native alternatives: Hetzner DNS for simplicity, Bunny DNS for GeoDNS, OVHcloud DNS for managed enterprise, or self-hosted PowerDNS for maximum control.

The DNS migration path is technically straightforward. The compliance benefit — removing the DNS control plane from US jurisdiction — is permanent.

sota.io deploys applications directly to EU-based infrastructure from git push, with no US-parent PaaS in the critical path. Start deploying