AWS CloudFront EU Alternative 2026: CDN Telemetry, Edge Cache Data, and CLOUD Act Exposure

Post #699 in the sota.io EU Compliance Series

AWS CloudFront is Amazon's global content delivery network, serving cached content from 600+ edge locations across 90+ cities worldwide. For web applications, CloudFront reduces latency by caching static assets, API responses, and HTML pages close to end users. For security, CloudFront integrates with AWS WAF and AWS Shield. For serverless edge computing, CloudFront enables Lambda@Edge and CloudFront Functions to execute code at edge locations. As the CDN layer in AWS-native architectures, CloudFront typically sits in front of S3 origins, Application Load Balancers, API Gateway endpoints, and EC2 origins.

The compliance problem with CloudFront is structural and persists even for organizations that have otherwise addressed their AWS data residency concerns. AWS CloudFront is operated by Amazon Web Services, Inc., a US corporation subject to the CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 18 U.S.C. § 2713). The CLOUD Act allows US law enforcement to compel Amazon to disclose data held in CloudFront infrastructure — access logs, distribution configurations, cache behaviors, Lambda@Edge function code, and CloudFront Functions source — through a warrant process that bypasses the Mutual Legal Assistance Treaty (MLAT) framework.

There is an additional, widely overlooked dimension to CloudFront's compliance status: CloudFront is not included in AWS European Sovereign Cloud (ESC). When Amazon announced AWS ESC in January 2026 as a dedicated cloud environment for EU data sovereignty, the service list included approximately 90 AWS services. CloudFront was absent. This means that organizations that have adopted AWS ESC specifically to address CLOUD Act concerns still rely on standard US-jurisdiction CloudFront for their CDN layer — creating a gap in their sovereignty architecture that sits precisely at the user-facing edge.

What CloudFront Stores Under US Jurisdiction

The data exposure from CloudFront spans the entire lifecycle of content delivery, from distribution configuration through individual request processing to long-term access logging.

Distribution configuration and cache behaviors. A CloudFront distribution defines how content is cached and delivered. Distribution configuration stored under US jurisdiction includes: the list of origins (including their endpoints, protocols, and authentication credentials for origin access controls), cache behavior rules (which URL patterns cache for how long), geographic restrictions (which countries are allowed or blocked), custom headers injected into origin requests, and SSL/TLS certificate configurations. For organizations using CloudFront as a security layer, the WAF ACL associations and the specific WAF rules applied are visible in distribution configuration.

The origin configuration is particularly sensitive: an origin access control (OAC) for S3 or an origin authentication header for an API Gateway endpoint reveals the structure and authentication mechanism of the backend infrastructure. Under a CLOUD Act warrant targeting the CloudFront distribution, this configuration data exposes the entire backend architecture of the application.

Access logs with user IP addresses and request data. CloudFront standard logging captures a detailed record of every request served by the distribution. Each log entry includes: the date and time of the request, the edge location that served the request, the viewer's IP address, the HTTP method and URI requested, the response status code and bytes transferred, the referrer and user agent strings, the cache hit/miss status, and the SSL protocol version used.

Under GDPR Article 4(1), IP addresses are personal data. CloudFront access logs therefore constitute a record of personal data processed on behalf of the data controller. These logs are stored in S3 under US jurisdiction. For EU websites serving EU users, the complete request history — which pages each user IP address visited, when, from what referrer, using what device — is stored in a system accessible under US law.

CloudFront real-time logging extends this further: real-time logs can deliver access records to Amazon Kinesis Data Streams within seconds of requests, capturing additional fields including request headers (which may include authentication tokens, session identifiers, or other personal data), cookies, and query string parameters. For applications that pass personal data in query strings or cookies, real-time logs create a near-complete record of personal data flows under US jurisdiction.

Lambda@Edge function code and execution data. Lambda@Edge allows Lambda functions to execute at CloudFront edge locations, modifying requests and responses as they pass through the CDN. Lambda@Edge functions can be used for: authentication and authorization (validating JWT tokens, checking session cookies), request transformation (URL rewriting, header manipulation), A/B testing and personalization, and bot detection.

Lambda@Edge function code is deployed globally to CloudFront edge locations. Unlike regional Lambda functions that execute in a defined AWS region, Lambda@Edge code executes at whichever edge location processes the request — including edge locations outside the EU. For EU users whose requests are processed at edge locations in the UK, Switzerland, or other non-EU countries, Lambda@Edge execution occurs outside the EU entirely. The function code, execution environment, and any data processed during Lambda@Edge execution are under US jurisdiction regardless of where the physical edge location is.

Lambda@Edge execution logs are delivered to CloudWatch Logs in the AWS region closest to the edge location where the function executed — not necessarily in the eu-west or eu-central regions. For a Lambda@Edge function invoked at a London edge location, the execution logs are delivered to eu-west-2 (London), which is outside the EU. For a function invoked at a Zurich edge location, logs go to eu-central-2 (Zurich), also outside the EU.

CloudFront Functions source code and execution metrics. CloudFront Functions are lightweight JavaScript functions that execute at CloudFront edge locations for request/response manipulation. Unlike Lambda@Edge (which runs on Lambda infrastructure), CloudFront Functions run directly on CloudFront edge infrastructure with sub-millisecond execution times. CloudFront Functions source code is stored in the CloudFront service under US jurisdiction. For organizations using CloudFront Functions for authentication, personalization, or security enforcement, the function logic is part of the data covered by CLOUD Act jurisdiction.

Origin Shield request logs and cache data. CloudFront Origin Shield is an additional caching layer that sits between edge locations and the origin, reducing origin load by consolidating cache fills through a single regional layer. When Origin Shield is enabled, all origin requests pass through the designated Origin Shield region. For EU origins, Origin Shield can be placed in eu-west-1 (Ireland) or eu-central-1 (Frankfurt) to minimize origin latency — but the Origin Shield itself remains part of the Amazon Web Services, Inc. infrastructure subject to CLOUD Act.

Field-level encryption data. CloudFront field-level encryption allows specific form fields to be encrypted at the edge using a public key, ensuring that only specific application components can decrypt the fields. Organizations use field-level encryption for sensitive form data such as payment card numbers, health information, or social security numbers. The CloudFront field-level encryption configuration — including the public key used for encryption and the specific form fields targeted — is stored under US jurisdiction. While the encrypted data itself may not be readable to Amazon, the knowledge of which fields are encrypted and with which keys is sensitive operational information.

The AWS European Sovereign Cloud Gap

Amazon Web Services launched AWS European Sovereign Cloud (AWS ESC) in January 2026 as a dedicated cloud environment operating independently from the standard AWS commercial regions. AWS ESC is specifically designed for EU organizations that require data residency guarantees and operational independence from US entities.

The initial AWS ESC service availability includes approximately 90 AWS services: EC2, EKS, RDS, S3, IAM, KMS, CloudWatch, and other core infrastructure services. Notably absent from the AWS ESC service list are several services that comprise the edge and content delivery layer:

• CloudFront — not included in AWS ESC
• Lambda@Edge — not included (depends on CloudFront infrastructure)
• CloudFront Functions — not included
• AWS WAF (as a CloudFront-integrated service) — not included for CloudFront attachments
• AWS Global Accelerator — not included

This means that an organization running its entire compute, storage, and database infrastructure in AWS ESC — achieving genuine data residency for the core application layer — must still use standard US-jurisdiction CloudFront to deliver content to EU users. The user-facing edge of the application is outside the sovereignty perimeter, regardless of where the origin infrastructure is located.

For EU organizations that have invested in AWS ESC as their data sovereignty strategy, the CloudFront gap creates a two-tier architecture: EU-sovereign origin, US-jurisdiction CDN. Every user request passes through the US-jurisdiction layer before it reaches the EU-sovereign origin. Access logs, request metadata, and edge execution (Lambda@Edge/CloudFront Functions) occur under US law.

This gap is a structural limitation of the AWS ESC approach that is not resolvable within the AWS ecosystem: there is no AWS ESC-equivalent CDN service. EU organizations that require full-stack data sovereignty must use a non-AWS CDN.

GDPR Implications of CDN-Level US Jurisdiction

Personal data in access logs. The most direct GDPR implication of CloudFront's jurisdiction is the personal data in access logs. IP addresses are personal data under GDPR. For EU websites using CloudFront, the complete IP-level request history of EU users is stored in S3 under US jurisdiction. This constitutes a transfer of personal data to a US entity — Amazon Web Services, Inc. — that must be covered by a valid GDPR transfer mechanism (SCCs, BCRs, or adequacy decision).

Amazon's standard Data Processing Addendum (DPA) with SCCs covers CloudFront deployments in EU regions for standard data protection purposes. However, following Schrems II (C-311/18), the SCCs must be supplemented by a transfer impact assessment (TIA) that evaluates whether the SCCs provide adequate protection in light of US law, including CLOUD Act. For organizations processing access logs that constitute records of EU users' browsing behavior, the TIA for CloudFront must address the risk that a CLOUD Act warrant could compel Amazon to disclose those records.

Analytics and behavioral data at the CDN layer. Organizations using CloudFront as an analytics collection point — routing analytics beacon requests through CloudFront to capture user behavior data — should be aware that the complete analytics payload passes through US-jurisdiction infrastructure. For behavioral analytics (page views, click events, scroll depth, session replay data) that capture EU user behavior, the CDN-level processing under US jurisdiction is a data transfer that requires legal basis under GDPR Articles 44-49.

NIS2 and CDN as critical infrastructure. For organizations classified as essential entities under NIS2 (healthcare providers, energy operators, financial market infrastructure, digital infrastructure providers), the CDN layer is critical infrastructure for service delivery. Article 21 of NIS2 requires supply chain security measures that include managing the jurisdictional risk of critical third-party dependencies. CloudFront, as the CDN serving an NIS2 essential entity's public-facing services, is a critical ICT third-party dependency whose US jurisdiction creates supply chain risk under NIS2's framework.

EU-Native CDN Alternatives to CloudFront

The EU CDN market has matured significantly, with several EU-jurisdictioned providers offering comparable performance to CloudFront for EU-origin deployments.

Bunny CDN (Bunny.net). Bunny.net is incorporated in Slovenia (EU member state) and operates a global CDN network with 114 PoPs including extensive EU coverage. Bunny CDN is operated entirely by a EU-incorporated entity, with no US parent company. The company is GDPR-compliant by corporate structure rather than contractual mechanism. For EU web applications where content is primarily served to European users, Bunny CDN's EU PoP density provides excellent performance with EU jurisdiction. Bunny CDN supports: custom domains with free SSL, image optimization, video streaming (Bunny Stream), edge storage (Bunny Storage), and Perma-Cache for high-traffic content.

Gcore CDN (G-Core Labs). Gcore is incorporated in Luxembourg (EU member state) and operates a CDN with 160+ PoPs, including EU data centers in Frankfurt, Amsterdam, Paris, Warsaw, Stockholm, and other major EU cities. For EU organizations requiring high-performance CDN with EU jurisdiction and a Luxembourg-incorporated entity, Gcore provides enterprise-grade CDN with DDoS protection, video delivery, and edge computing capabilities.

Fastly (EU-restricted configuration). Fastly is a US-incorporated CDN provider (Fastly, Inc., San Francisco, California). However, Fastly provides geographic restriction capabilities that can limit edge location usage to EU PoPs only. This reduces — but does not eliminate — the jurisdiction issue: Fastly remains a US entity subject to CLOUD Act regardless of which PoPs serve the traffic. Organizations using Fastly should conduct a transfer impact assessment as they would for any US CDN provider.

Self-hosted Varnish or nginx caching on EU infrastructure. For organizations with sufficient traffic to justify the operational overhead, self-hosted caching layers (Varnish Cache, nginx reverse proxy with caching) deployed on EU-jurisdictioned infrastructure (Hetzner, OVHcloud, Scaleway) provide CDN-equivalent functionality with complete data residency control. This approach is suitable for organizations where CDN performance is primarily needed for EU users and where the origin infrastructure is already EU-based.

sota.io origin with Bunny CDN edge. For teams building on sota.io as their EU-sovereign application platform, the recommended CDN architecture combines sota.io origin deployments (EU-jurisdiction container deployments) with Bunny CDN as the edge layer. This produces a fully EU-sovereign stack: EU-origin compute on sota.io, EU-CDN edge on Bunny.net, with no US-incorporated entity in the request path. The origin-CDN integration uses sota.io's custom domain and origin authentication; Bunny CDN's pull zone configuration handles the edge caching layer.

CloudFront vs EU CDN — Compliance Comparison

Migration Path from CloudFront to EU CDN

Phase 1: Map CloudFront distribution usage. Audit your CloudFront distributions to identify: which origins they front (S3, ALB, API Gateway, EC2), which Lambda@Edge or CloudFront Functions are attached, what cache behaviors are configured, and what WAF rules are applied. This audit identifies the migration scope.

Phase 2: Replace Lambda@Edge with origin-side logic. Any authentication, personalization, or request transformation logic running in Lambda@Edge must move to the origin application. This is the most significant refactoring effort: Lambda@Edge code typically handles JWT validation, A/B test routing, or URL canonicalization that must be reimplemented as origin middleware or reverse proxy configuration when moving to a CDN without edge compute.

Phase 3: Configure EU CDN pull zones. Bunny CDN and Gcore both support pull zone configuration that maps directly to CloudFront distribution concepts: an origin URL (the EU-sovereign origin), cache rules (TTLs by content type or URL pattern), and custom headers. The configuration migration from CloudFront distribution settings to Bunny CDN pull zone settings is straightforward for standard static asset caching use cases.

Phase 4: Update DNS and SSL. CDN migration requires DNS cutover from CloudFront distribution domains to the EU CDN domain. Both Bunny CDN and Gcore support custom domains with automatic SSL certificate provisioning, replacing CloudFront's ACM certificate integration. The DNS cutover is typically the final step, performed with a low TTL to enable rapid rollback.

See Also

• AWS Lambda EU Alternative 2026 — Serverless execution environment and event payload jurisdiction
• AWS S3 EU Alternative 2026 — Object storage under US jurisdiction (CloudFront's typical origin)
• AWS CloudWatch EU Alternative 2026 — Logs and metrics stored under US law
• AWS ECS EU Alternative 2026 — Container orchestration as EU-native origin alternative