AWS ELB/ALB EU Alternative 2026: Access Logs, WAF Data, and GDPR Under the CLOUD Act

Post #726 in the sota.io EU Compliance Series

AWS Elastic Load Balancing (ELB) sits at the entry point of most AWS architectures — it receives every incoming HTTP request before it reaches your application. Application Load Balancers (ALB) handle HTTP/HTTPS traffic for web applications, APIs, and microservices. Network Load Balancers (NLB) handle TCP/UDP at Layer 4. Classic Load Balancers (CLB) serve legacy workloads still running on EC2-Classic infrastructure.

For European companies, ELB and ALB are the internet-facing gateway through which every user interaction passes. This architectural position — first point of contact for all incoming traffic — means the load balancer infrastructure sees, logs, and processes metadata about every user request. ALB access logs contain source IP addresses. WAF integration logs rule match data. Sticky sessions create behavioral linkage between users and backend targets. Request tracing propagates identifiers through distributed systems.

Amazon operates ELB in European regions: eu-west-1 (Ireland), eu-central-1 (Frankfurt), eu-west-3 (Paris), eu-south-1 (Milan), eu-north-1 (Stockholm). Load balancer endpoints serve traffic in Europe. European development teams frequently treat their ELB deployments as inherently GDPR-compliant based on this geographic presence.

The jurisdictional problem is not geographic. 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 customer data stored anywhere in the world when ordered by a US court or government agency. A valid US government order can reach your ALB access logs in Frankfurt — logs that contain the IP addresses of every person who has ever sent a request to your application.

What ELB and ALB Store That Touches Personal Data

ELB and ALB sit at the traffic ingestion point of your architecture. This privileged position creates multiple categories of personal data exposure.

ALB Access Logs: IP Addresses as Personal Data Under GDPR Art. 4

ALB access log files are stored in S3 buckets that you designate, but the data flowing into those logs passes through AWS infrastructure and the log delivery mechanism is operated by AWS. The access log format for ALB includes, among other fields:

• client:port — the IP address and port of the requesting client
• user_agent — the HTTP User-Agent header, which can identify browser version, OS, and device type
• request — the full HTTP request line, including path and query string
• target:port — the IP address of the backend instance that handled the request
• response_processing_time — timing data that reveals user behavioral patterns
• request_id — a unique identifier for every request

Under GDPR Article 4(1), personal data is "any information relating to an identified or identifiable natural person." The Court of Justice of the European Union ruled in Breyer v. Germany (C-582/14, 2016) that IP addresses are personal data when the data controller has the legal means to identify the person behind the IP address — a standard that applies to virtually any European business operating a customer-facing service.

Every ALB access log entry is therefore a personal data record. ALB access logs for a production application serving 10,000 daily users generate tens of thousands of personal data records per day. Those records are stored in S3 under AWS control, subject to CLOUD Act compulsion.

The GDPR Art. 5(1)(e) storage limitation principle requires that personal data be "kept in a form which permits identification of data subjects for no longer than is necessary." Default ALB access log retention is governed by your S3 lifecycle policy. Without explicit configuration, access logs accumulate indefinitely. Most teams set S3 lifecycle policies for cost control but rarely consider GDPR Art. 5(1)(e) compliance when doing so.

WAF Behavioral Logs: Rule Triggers as Behavioral Analytics

AWS WAF integrates directly with ALB to inspect HTTP requests before they reach backend targets. When WAF rules trigger — for SQL injection patterns, XSS payloads, rate limiting thresholds, geographic restrictions, or custom rule conditions — that trigger event is logged through AWS Kinesis Data Firehose to S3, CloudWatch Logs, or another destination.

WAF log records contain:

• The source IP address of the blocked or allowed request
• The HTTP request headers that triggered the rule
• The rule ID and rule group that matched
• The action taken (ALLOW, BLOCK, COUNT)
• A timestamp and request ID

For GDPR purposes, WAF behavioral logs are particularly sensitive. A WAF log entry showing that a specific IP address triggered a rule for "geographic restriction: IP in Russia" reveals behavioral context beyond simple request tracking. A log entry showing repeated SQL injection attempts from the same IP creates a behavioral profile. Rate-limiting logs linking IP addresses to request frequency patterns constitute processing of personal data under Art. 4.

AWS Firewall Manager — the managed service for WAF policy administration across multiple accounts — is operated by Amazon Web Services, Inc. Policy enforcement decisions, log routing configuration, and rule group management traverse the Firewall Manager control plane under US jurisdiction. For regulated industries processing health data (GDPR Art. 9) or financial data, WAF behavioral logs under CLOUD Act jurisdiction create compliance exposure that security teams frequently overlook.

Sticky Sessions: Session Affinity Data Under US Control

ALB sticky sessions allow the load balancer to route successive requests from the same client to the same backend target. This session affinity is implemented through two mechanisms:

Duration-based stickiness — ALB generates the AWSALB cookie, a Base64-encoded value that maps the client to a specific target. The cookie is set by ALB infrastructure and read by ALB infrastructure on each subsequent request. The mapping between the cookie value and the backend target is maintained in ALB's internal routing tables, which are managed by AWS.

Application-based stickiness — ALB reads a cookie generated by your application to determine target affinity. The cookie name is configured in the target group settings. ALB inspects the cookie on each request and routes accordingly — meaning ALB reads application-generated session identifiers.

Under GDPR, sticky session infrastructure creates a processing relationship. The AWSALB cookie links the user's session to a specific backend server. That linkage — maintained in ALB routing tables under AWS control — is processing of data that can identify users across requests. When the sticky session lifetime exceeds the session's legitimate purpose (for example, a shopping cart cookie with 7-day stickiness persisting after a transaction completes), this creates Art. 5(1)(e) storage limitation and Art. 5(1)(b) purpose limitation violations that flow from the load balancer configuration.

Application-based stickiness adds another dimension: ALB is reading your application's session cookies to make routing decisions. If your application session cookie contains encrypted user identifiers or session tokens, ALB is processing those values as opaque strings. Those values pass through AWS infrastructure on every request.

Connection Draining: In-Flight Data Retention Risk

When a backend target is deregistered from an ALB target group — for scaling down, deployment, or maintenance — ALB enters a connection draining (deregistration delay) period. During this period, ALB stops sending new requests to the deregistering target but continues to complete existing in-flight requests.

The default deregistration delay is 300 seconds (5 minutes). Maximum is 3,600 seconds (1 hour). During this window:

• Active HTTP connections to the deregistering target remain open
• In-flight requests that have not received a response continue to be processed
• ALB maintains the routing table entry for the draining target

For applications where HTTP requests carry personal data in request bodies (user registration, profile updates, medical record submissions, financial transactions), the connection draining period extends the lifetime of those in-flight requests. The ALB's awareness of which connections are actively draining — and the routing metadata for those connections — persists under AWS control for the duration of the draining window.

For compliance-sensitive architectures, the deregistration delay represents a configurable data retention parameter with GDPR implications. Setting the delay too high violates the data minimization principle (Art. 5(1)(c)) for in-flight processing. Setting it too low risks dropped connections for legitimate in-progress requests. This tension is a consequence of the load balancer infrastructure being operated by a US entity.

ALB Request Tracing: X-Amzn-Trace-Id Across Distributed Systems

ALB automatically inserts the X-Amzn-Trace-Id header into every incoming HTTP request that does not already contain one. This header contains a Root identifier and optional Parent and Sampled fields used by AWS X-Ray for distributed tracing.

The trace ID format: Root=1-67891233-abcdef012345678912345678

When your application is instrumented with AWS X-Ray SDK (or the AWS Distro for OpenTelemetry with X-Ray integration), these trace IDs link HTTP requests across microservices, Lambda functions, DynamoDB calls, and other AWS services into a unified trace. X-Ray traces are stored in the AWS X-Ray service — a managed service operated by Amazon Web Services, Inc.

For GDPR purposes, the X-Amzn-Trace-Id chain creates a behavioral linking mechanism. A trace that spans an ALB request → ECS microservice → RDS database query links together:

• The user's source IP (from ALB access logs)
• The request path and parameters
• The database query pattern (which may reveal what data was accessed)
• Timing and performance data revealing user behavior patterns

This behavioral linkage — maintained in X-Ray under AWS control — constitutes processing of personal data under Art. 4 when the trace can be linked back to identified or identifiable users. For SaaS applications where users are authenticated, every X-Ray trace linked to an authenticated session is a personal data record.

ALB OIDC Authentication: Identity Provider Integration Through AWS Infrastructure

ALB supports built-in OIDC authentication, allowing the load balancer to authenticate users directly before forwarding requests to backend targets. When ALB OIDC is configured:

1. ALB redirects unauthenticated users to the configured identity provider
2. The identity provider redirects back to ALB with an authorization code
3. ALB exchanges the authorization code for ID and access tokens directly with the identity provider
4. ALB stores the token in an encrypted session cookie (AWSELBAuthSessionCookie-*)
5. ALB forwards the decoded JWT claims to the backend in X-Amzn-Oidc-* headers

The ALB OIDC flow means that AWS infrastructure handles OAuth authorization codes and exchanges them for identity tokens. The encrypted session cookie containing those tokens is managed by ALB — readable by ALB on every request to extract the user identity. For applications authenticating EU users through GDPR-regulated identity providers (including social login through Google, which operates EU-local data processing under SCCs), the ALB OIDC integration routes those credentials through US-entity-operated infrastructure.

Under GDPR Art. 32, the pseudonymization and encryption of authentication tokens must be "state of the art." When AWS controls the encryption of authentication session cookies, the controller does not have sole custody of the keys — the encryption is performed by AWS infrastructure, using AWS-managed key material (unless explicitly overridden with customer-managed KMS keys, which add complexity without eliminating US entity access).

The CLOUD Act Problem for Load Balancer Infrastructure

ELB and ALB are not just passive traffic forwarders. They actively generate, store, and process data about user interactions:

• Access logs record every user request with IP address as a personal data point
• WAF logs create behavioral profiles from security rule evaluations
• Sticky session cookies maintain user-to-server routing linkages
• X-Ray trace IDs chain user behavior across distributed system components
• OIDC session management handles user authentication tokens

All of this infrastructure is operated by Amazon Web Services, Inc. under US jurisdiction. The CLOUD Act (18 U.S.C. § 2713) compels AWS to produce this data when ordered by US authorities — without requiring notification to you (the GDPR controller) or your users (the data subjects).

GDPR Recital 101 and Art. 46 require that transfers of personal data to third countries provide "appropriate safeguards." The EU-US Data Privacy Framework (DPF, 2023) provides a transfer mechanism for US companies certified under DPF. Amazon AWS is DPF-certified. However, the Court of Justice EU's Schrems II decision (C-311/18, 2020) established that DPF-equivalent mechanisms do not eliminate CLOUD Act risk for data categories that US intelligence programs specifically target — and network traffic metadata (precisely what ALB access logs contain) falls within PRISM program collection authorities.

For regulated industries — health data processors under GDPR Art. 9, financial data processors under PSD2 and DORA, legal data processors under attorney-client privilege requirements — relying on DPF certification alone for load balancer infrastructure under CLOUD Act jurisdiction creates legal exposure that most Data Protection Officers have not fully assessed.

EU-Native Load Balancing Alternatives

Hetzner Cloud Load Balancer

Hetzner Online GmbH is a German company headquartered in Gunzenhausen, Bavaria. Load Balancers are a native Hetzner Cloud service.

Pricing: From €5.39/month (LB11: 25 services, 25 targets, 20 TB traffic included). No per-request pricing — fixed monthly cost.

Feature coverage:

• HTTP and HTTPS load balancing (Layer 7)
• TCP load balancing (Layer 4)
• Health checks with configurable intervals and thresholds
• SSL/TLS termination with Let's Encrypt integration
• Sticky sessions via cookie
• Round-robin, least-connections, source IP hash algorithms
• Private network integration (no public IP required for targets)
• Metrics and monitoring via Hetzner Cloud API

GDPR position: Hetzner Online GmbH is subject to German law (BDSG) and EU jurisdiction. No US parent company. No CLOUD Act exposure. DPA standard contractual clauses with Hetzner are intra-EU transfers — no Art. 46 mechanism required. Hetzner's data centers are in Germany (Nuremberg, Falkenstein) and Finland (Helsinki). ISO 27001 certified.

Limitation vs ALB: No WAF integration at the load balancer level (WAF is separate — Hetzner does not offer a managed WAF). No OIDC authentication built in (must be implemented at application layer). No native AWS ecosystem integration (no ECS, no Lambda targets).

Scaleway Load Balancer

Scaleway SAS is a French company headquartered in Paris, part of the Iliad Group. Load Balancer is a managed service available in Paris (fr-par), Amsterdam (nl-ams), and Warsaw (pl-waw).

Pricing: From €9.99/month for the load balancer itself, plus €0.006/GB for additional traffic beyond the included 60 TB.

Feature coverage:

• HTTP/HTTPS and TCP load balancing
• SSL/TLS termination
• ACL rules for traffic filtering (equivalent to WAF-lite)
• Sticky sessions
• Health checks
• Private Networks integration
• Multiple backends with different protocols

GDPR position: Scaleway SAS is subject to French law and EU jurisdiction. Iliad Group is listed on Euronext Paris (ILD). No US parent company. Intra-EU data transfer for French customers. ISO 27001, SecNumCloud (for specific services) certification.

OVHcloud Load Balancer

OVHcloud (OVH SAS) is a French company headquartered in Roubaix, part of the OVH Groupe SA. Load Balancer is available across OVHcloud's European infrastructure.

Pricing: VPS Load Balancer from €4.49/month. OVHcloud Load Balancer (Managed) from €29/month.

GDPR position: OVH SAS is subject to French law and EU jurisdiction. OVH Groupe SA is listed on Euronext Paris (OVH). SecNumCloud certification available for highest-sensitivity workloads. No US parent company. No CLOUD Act exposure.

Traefik on EU Infrastructure

Traefik is an open-source cloud-native reverse proxy and load balancer, originally developed by Containous SAS (France), now part of Traefik Labs (French company). Traefik Proxy is MIT-licensed. Traefik Enterprise (commercial) is available through Traefik Labs.

When deployed on EU-jurisdiction infrastructure (Hetzner, OVHcloud, Scaleway, Exoscale), Traefik provides:

• HTTP/HTTPS and TCP load balancing
• Automatic SSL certificate management (Let's Encrypt)
• Middleware-based WAF integration (Coraza, ModSecurity)
• OIDC authentication via plugin or middleware
• Access logging (fully under your control — no cloud provider access)
• Metrics export (Prometheus, InfluxDB)
• Docker/Kubernetes native service discovery

The critical difference: when you run Traefik on EU-jurisdiction infrastructure, you control the access logs. IP addresses from access logs are stored in your infrastructure, not a US cloud provider's S3 bucket. WAF rule decisions are processed by your infrastructure. Sticky sessions are managed by your proxy layer.

sota.io: EU-Native PaaS with Built-in Load Balancing

sota.io is an EU-native Platform-as-a-Service built entirely on EU-jurisdiction infrastructure. Every deployment on sota.io runs behind Traefik (EU-origin reverse proxy) on servers in Germany. Load balancing between application instances is part of the platform — not a separately managed AWS-equivalent service.

GDPR position: sota.io's infrastructure is German/EU jurisdiction. No US parent company. No CLOUD Act exposure. Access logs from the load balancing layer are not transmitted to US-controlled cloud storage. Sticky session management is handled by Traefik under EU control.

What sota.io eliminates:

• No ALB access logs in US-controlled S3 buckets
• No WAF behavioral logs in AWS Kinesis/Firewall Manager
• No ALB OIDC token management by AWS infrastructure
• No X-Amzn-Trace-Id generation by AWS load balancers
• No connection draining data retention managed by a US entity

What you get instead: Deploy your application with sota deploy. Traefik handles SSL termination, routing, and load balancing across your instances. Access logs remain in your application's log stream. You don't manage ALB target groups, listener rules, or WAF rule groups — the platform layer handles routing with EU-jurisdiction infrastructure.

Pricing: From €9/month for 512MB RAM. Managed PostgreSQL included. No per-request charges, no WAF add-on costs, no S3 log storage costs.

Migration Path: From ALB to EU-Native Load Balancing

Step 1: Audit Current ALB Usage

Before migrating, map your ALB configuration:

# List all ALBs and their target groups
aws elbv2 describe-load-balancers --region eu-central-1 \
  --query 'LoadBalancers[*].[LoadBalancerArn,DNSName,Type]' \
  --output table

# Check WAF associations
aws wafv2 list-web-acls --scope REGIONAL --region eu-central-1

# Check listener rules
aws elbv2 describe-listeners \
  --load-balancer-arn <ALB_ARN> \
  --query 'Listeners[*].[ListenerArn,Protocol,Port]'

Step 2: Identify GDPR-Relevant Configurations

Document ALB features with GDPR implications:

• Access log bucket location and retention — Map to Art. 5(1)(e) storage limitation requirements
• WAF rule groups — Determine if WAF behavioral logs contain Art. 9 special category data
• OIDC authentication — Identify if ALB handles EU user identity tokens
• Sticky session lifetime — Evaluate against Art. 5(1)(b) purpose limitation for session use

Step 3: Choose EU-Native Alternative Based on Use Case

Step 4: Migrate Access Log Compliance First

If immediate migration is not feasible, address the highest-risk exposure:

1. Reduce ALB access log retention — Apply S3 lifecycle policies aligned with GDPR Art. 5(1)(e). For most applications, 30 days is defensible; for high-sensitivity data (Art. 9), consider 7 days with explicit justification.

2. Enable ALB access log field masking — ALB supports field masking to omit query strings from access logs. This does not eliminate IP logging but reduces Art. 4 personal data volume.

3. Disable X-Ray trace injection — If not using X-Ray for debugging, configure ALB to not inject trace IDs: this eliminates the behavioral linkage mechanism in distributed traces.

4. Review sticky session lifetimes — Align AWSALB cookie duration with the minimum necessary for your use case. A 1-hour sticky session for a checkout flow is Art. 5(1)(c) minimization-compliant; a 7-day sticky session for a stateless API is not.

GDPR Compliance Assessment for ELB/ALB

The Architectural Principle: First-Point-of-Contact GDPR Exposure

Load balancers occupy the most sensitive architectural position for GDPR compliance: they see every request before your application code does. This means:

1. They log more personal data than any other infrastructure component — every user interaction, before any application-layer filtering
2. They implement authentication (OIDC) before your code runs — meaning US-entity infrastructure handles user identity
3. They generate behavioral analytics (WAF, X-Ray) about user patterns across your entire application
4. They control session persistence through sticky session cookies

When this first-point-of-contact infrastructure is operated by a US entity subject to the CLOUD Act, every user interaction with your European application creates personal data records under US jurisdiction. The "data resides in Frankfurt" argument does not address this structural exposure — the management plane, log delivery infrastructure, WAF service, and session management are all operated by Amazon Web Services, Inc.

EU-native load balancing alternatives — Hetzner, Scaleway, OVHcloud, Traefik on EU infrastructure, or sota.io's managed platform layer — eliminate this first-contact CLOUD Act exposure. They provide the same HTTP routing, SSL termination, and health checking capabilities without the jurisdictional overhead.

Running AWS ELB/ALB for a European application handling personal data? sota.io is the EU-native managed platform that replaces your ALB with Traefik-based routing under EU jurisdiction — no access logs in US-controlled S3, no WAF behavioral analytics in AWS Firewall Manager, no OIDC token management by a US entity. Deploy in minutes: npm install -g @sota/cli && sota deploy.