2026-04-30·12 min read·

AWS WAF EU Alternative 2026: Web Traffic Inspection, GDPR Compliance, and CLOUD Act Risk

Post #714 in the sota.io EU Compliance Series

Every HTTP request your EU users send to your application passes through AWS WAF before it reaches your code. AWS WAF sees the IP address, the HTTP headers, the URL path, the query parameters, and optionally the request body. It evaluates this data against your Web ACL rules, makes an allow or block decision, and — if you have logging enabled — stores a full record of that decision in Amazon CloudWatch Logs or Amazon Kinesis Data Firehose.

That record is personal data under GDPR. The IP address alone is sufficient for GDPR classification under Article 4(1) and CJEU case law (Breyer v Bundesrepublik Deutschland, C-582/14). The combination of IP address, timestamp, user agent, and URL path creates a behavioral profile of individual users — data that, under the CLOUD Act, the US government can compel AWS to disclose without notifying you or your users.

AWS WAF is positioned as a security control. Under GDPR, it is also a data processing operation on your EU users' personal data, operated by a US company, subject to US extraterritorial jurisdiction.

What AWS WAF Processes for Every Request

AWS WAF operates at Layer 7 of the OSI model. To make allow/block decisions, it must inspect the full HTTP request. Understanding what it processes is the foundation of the GDPR analysis.

The WAF Log Entry

When AWS WAF logging is enabled, each evaluated request generates a log entry in the following format:

{
  "timestamp": 1746000000000,
  "formatVersion": 1,
  "webaclId": "arn:aws:wafv2:eu-central-1:123456789:regional/webacl/ProductionWAF/...",
  "terminatingRuleId": "AWSManagedRulesCommonRuleSet",
  "terminatingRuleType": "MANAGED_RULE_GROUP",
  "action": "BLOCK",
  "httpSourceName": "ALB",
  "httpSourceId": "123456789-app/my-load-balancer/...",
  "ruleGroupList": [...],
  "httpRequest": {
    "clientIp": "203.0.113.42",
    "country": "DE",
    "headers": [
      {"name": "Host", "value": "api.yourapp.eu"},
      {"name": "User-Agent", "value": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)..."},
      {"name": "Accept-Language", "value": "de-DE,de;q=0.9"},
      {"name": "Cookie", "value": "session_id=abc123; _ga=GA1.2..."},
      {"name": "X-Forwarded-For", "value": "203.0.113.42, 10.0.0.1"}
    ],
    "uri": "/api/users/profile",
    "args": "user_id=99142&action=update",
    "httpMethod": "POST",
    "requestId": "1-67a4b5c6-7d8e9f0a1b2c3d4e5f6a7b8c"
  }
}

Every field in this log entry is potentially personal data under GDPR:

clientIp: IP address. Personal data under GDPR per CJEU Breyer ruling. Identifies the user's device, location, and ISP.
country: Derived geolocation data. Inferred from IP, retained as a data point.
headers.Cookie: Session identifiers, analytics cookies, authentication tokens. Directly identifies authenticated users. This is personal data per GDPR Art. 4(1) and recital 30.
headers.User-Agent: Device fingerprinting data. Combined with IP and timestamp, enables cross-session user identification.
headers.Accept-Language: Language preference. In combination with other headers, contributes to user profiling.
uri + args: URL paths and query parameters. For most applications, these contain resource identifiers — user IDs, document IDs, search queries — that directly or indirectly identify natural persons.
httpRequest.requestId: A unique identifier for each request, enabling correlation across log entries for the same user session.

GDPR Article 4(1) defines personal data as "any information relating to an identified or identifiable natural person." A log entry combining IP address, session cookie, user agent, timestamp, and URL path with embedded user IDs does not require a stretch of interpretation. It is personal data by any reasonable reading of the definition.

AWS WAF Managed Rule Groups

AWS provides managed rule groups — curated sets of WAF rules maintained by AWS threat intelligence teams. These rule groups process your users' requests through proprietary detection logic:

AWSManagedRulesCommonRuleSet (CRS): The baseline ruleset. Inspects request bodies, headers, and URIs for common web exploits. The rule group applies pattern matching against all request components, including POST body content that may contain form submissions with personal data.

AWSManagedRulesKnownBadInputsRuleSet: Blocks requests matching signatures for known attack patterns. Requires inspection of full request content.

AWSManagedRulesAmazonIpReputationList: Evaluates every source IP against Amazon's threat intelligence database. AWS maintains and updates this database with IP reputation data derived from its global infrastructure visibility. Your users' IP addresses are matched against a US-maintained intelligence feed.

AWSManagedRulesBotControlRuleSet: This rule group has the most significant GDPR implications, discussed separately below.

AWSManagedRulesSQLiRuleSet, AWSManagedRulesLinuxRuleSet, AWSManagedRulesWindowsRuleSet: Inspection of request bodies for injection attack patterns. If your application accepts form data containing personal information, WAF's body inspection rules process that data.

AWS Bot Control is a premium WAF rule group that uses machine learning to classify web traffic as human or automated. It is activated separately and billed per million requests processed.

Bot Control creates a profiling pipeline for every request from your EU users:

A user makes a request to your application.
Bot Control inspects the request — IP address, headers, browser fingerprint signals, behavioral patterns.
Bot Control assigns a bot category (VERIFIED_BOT, HTTP_LIBRARY, BROWSER, SCRIPTED_BROWSER) and confidence score.
The classification and score are logged as part of the WAF decision.
AWS's ML models are updated with signals from your traffic to improve classification accuracy across all AWS customers.

Under GDPR Article 22(1), data subjects have the right "not to be subject to a decision based solely on automated processing, including profiling, which produces legal or other similarly significant effects concerning him or her." If your application denies a request based solely on Bot Control's ML classification — and the user is in fact human — that is an automated decision with significant effect.

More broadly, Bot Control performs profiling of EU users within the meaning of GDPR Article 4(4): "any form of automated processing of personal data consisting of the use of personal data to evaluate certain personal aspects relating to a natural person." The behavioral signals Bot Control uses — request timing, header patterns, JavaScript execution characteristics — are derived from personal data.

AWS's Bot Control documentation acknowledges that the rule group collects usage data to improve detection accuracy. This creates a secondary data flow: your EU users' traffic patterns inform AWS's global ML training data, under US jurisdiction.

The CLOUD Act Exposure

AWS WAF stores its logs in AWS infrastructure — Amazon CloudWatch Logs, Amazon S3, or Amazon Kinesis Data Firehose depending on your configuration. All of these services are operated by AWS Inc., a US company subject to the CLOUD Act (18 U.S.C. § 2713).

The CLOUD Act requires US cloud providers to preserve and disclose data stored on US-controlled infrastructure regardless of where the data is physically stored. An AWS eu-central-1 (Frankfurt) CloudWatch Logs group containing your WAF logs is not protected from US government compelled disclosure by virtue of being in Germany. AWS is a US company. The CLOUD Act applies.

Compelled disclosure of WAF logs would expose:

Traffic patterns: Volume and frequency of requests, time-of-day patterns, which endpoints are accessed most frequently — all indicative of business intelligence about your EU users' behavior.
User identification data: IP addresses, session cookies, user agent strings for your entire user base.
Blocked request intelligence: Every blocked request — including potential security testing, scraping attempts, or API abuse — with full HTTP details.
Geographic distribution: Country-level geolocation for your EU user base derived from IP analysis.
Application structure inference: URL paths and API endpoints reveal your application architecture, business logic, and data models.

Unlike a database subpoena that requires navigating your schema to extract personal data, WAF logs are already structured and indexed by IP address and timestamp. They represent a ready-made dossier on your EU user traffic, accessible to US authorities under a single court order.

AWS WAF processes personal data on your behalf, which makes AWS a data processor under GDPR Article 28. The Article 28 requirements are:

A written Data Processing Agreement (DPA) with AWS
Subprocessor lists and change notification mechanisms
Audit rights or third-party certification (AWS SOC 2, ISO 27001 fulfills the certification requirement)
Data deletion obligations when the controller-processor relationship ends
Breach notification obligations for WAF-related incidents

AWS provides a standard DPA through its Service Terms. However, the DPA cannot override the CLOUD Act. AWS's DPA explicitly carves out legally compelled disclosures. The DPA grants you certain contractual protections; it does not provide the data sovereignty protection that EU organizations increasingly require under post-Schrems II compliance frameworks.

The Schrems II ruling (C-311/18) invalidated Privacy Shield and established that US surveillance law creates an obstacle to EU-US data transfers that standard contractual clauses cannot remedy for high-risk transfers. GDPR Chapter V requires that personal data transferred to third countries provide an equivalent level of protection to that guaranteed in the EU. WAF logs transferred to or accessible from the US present this equivalence question.

The Article 28 DPA Chain

AWS WAF's Managed Rule Groups introduce additional data processor relationships. AWS threat intelligence teams that maintain and update managed rule groups process signal data from your traffic. Third-party partner rule groups from AWS Marketplace introduce additional processors beyond AWS itself. Each processor in this chain requires GDPR Article 28 coverage, and the chain is difficult to audit completely.

AWS WAF and CloudFront: The Edge Network Problem

AWS WAF can be deployed in two modes: regional (attached to Application Load Balancers or API Gateway) or CloudFront-attached. When you attach AWS WAF to CloudFront, every request from your EU users is evaluated at one of CloudFront's 400+ global points of presence before it reaches your regional infrastructure.

CloudFront PoPs are distributed globally and not confined to EU territory. A German user's HTTPS request may be routed to a Frankfurt CloudFront PoP, but the routing is determined by network topology, not by data residency requirements. The request is evaluated by WAF at the edge, and the WAF decision log — including the full personal data payload — is written to your CloudFront-associated log destination.

CloudFront-attached WAF introduces a geographic distribution problem on top of the jurisdiction problem: your EU users' request data is evaluated at non-EU edge nodes, with logs aggregated in the region you designate for your CloudFront distribution's logging. This creates data flows that extend beyond EU territory even when your application backend is entirely EU-hosted.

EU Alternatives: WAF Options Without US Jurisdiction

Self-Hosted WAF Solutions (Full Data Sovereignty)

ModSecurity with OWASP Core Rule Set (CRS)

ModSecurity is the established open-source WAF engine, running as a module for Apache, Nginx, and as a standalone reverse proxy. Combined with the OWASP CRS — the community-maintained ruleset covering OWASP Top 10 and more — it provides detection capabilities comparable to AWS's CRS managed rule group.

Deployment on EU infrastructure (Hetzner, OVH, Scaleway) keeps all log data under EU-controlled storage. Configuration for CloudWatch-equivalent logging goes to your own Elasticsearch/OpenSearch cluster or Grafana Loki — both deployable in Germany, France, or other EU jurisdictions.

ModSecurity with OWASP CRS is not a drop-in replacement for AWS WAF's managed rules. Bot detection is less sophisticated, and IP reputation scoring requires integration with external feeds (AbuseIPDB, Spamhaus) that introduce their own data sharing considerations. For the majority of OWASP Top 10 protection use cases, however, ModSecurity with OWASP CRS covers the requirement.

Coraza WAF

Coraza is a modern Go implementation of the ModSecurity engine, designed for cloud-native deployments. It is OWASP CRS compatible and can be embedded directly into Go HTTP servers or deployed as a sidecar. Coraza is maintained by the OWASP Foundation — no US commercial entity controls the roadmap or data flows.

Key advantages for EU deployments:

Native integration with Caddy server (European-neutral hosting)
Low memory footprint suitable for container-native deployments
OWASP CRS 3.x and 4.x compatible
Active development with cloud-native deployment patterns

BunkerWeb

BunkerWeb is an open-source WAF built on Nginx, packaged for container deployment, with a focus on modern cloud-native environments. It bundles OWASP CRS, bad bot detection, rate limiting, anti-DDoS rules, and Let's Encrypt integration in a single deployment unit.

BunkerWeb is developed by a French team (Bunker Group) and explicitly designed for GDPR-aware deployments. The project documentation addresses data protection requirements and provides configuration options for minimizing log retention. For small-to-medium EU deployments that need a single-image WAF solution, BunkerWeb is the most operationally complete EU alternative.

HAProxy Enterprise with WAF Module

HAProxy is a European-origin project (France). HAProxy Enterprise — the commercial distribution — includes a WAF module that supports OWASP CRS. Combined with HAProxy's load balancing, it provides a single entry point for traffic management and security inspection under EU jurisdiction.

EU-Resident CDN and WAF Services

Fastly with WAF (Regional Data Residency)

Fastly offers WAF functionality with EU data residency options for enterprise customers. Unlike AWS WAF, Fastly provides contractual commitments to EU data processing under DPA frameworks specifically designed to address Schrems II concerns. Fastly has published public documentation on its legal analysis for EU data sovereignty.

Fastly's network includes EU-based PoPs with commitments around data residency for enterprise configurations. The pricing model is consumption-based and significantly higher than AWS WAF for high-traffic applications, but appropriate for organizations that need CDN+WAF with auditable EU data processing commitments.

Hetzner + BunkerWeb Stack

For deployments that are already running on Hetzner, OVH, or Scaleway, the simplest EU-native WAF deployment is BunkerWeb running on the same infrastructure:

Internet → [Hetzner Load Balancer] → [BunkerWeb Container on Hetzner VPS] → [Application Containers]

All components operate in Germany (Hetzner NBG1/FSN1 or HEL1). WAF logs stay on Hetzner-hosted storage. No US entities in the processing chain. This architecture is deployable in an afternoon for existing Hetzner-based workloads and eliminates the AWS WAF jurisdiction problem entirely.

Deploying with sota.io

Applications deployed on sota.io run on EU-sovereign infrastructure without AWS WAF in the traffic path. The platform does not use AWS infrastructure for traffic inspection or routing.

For WAF functionality on sota.io-deployed applications, you have two options:

Option 1: Nginx WAF sidecar. Deploy a Coraza or ModSecurity+CRS Nginx container alongside your application container. Traffic routes through the WAF container before reaching your application. Logs write to your application's log stream, which you control completely.

Option 2: BunkerWeb as reverse proxy. Deploy BunkerWeb as the entry-point container for your application. Configure your sota.io project to expose BunkerWeb's port. BunkerWeb handles WAF inspection, rate limiting, and bad bot blocking with logs that stay within your deployment environment.

Neither option routes your EU users' HTTP traffic through a US-controlled inspection layer.

Migrating from AWS WAF

A WAF migration has two components: rule coverage migration and log destination migration.

Phase 1: Audit Current Rule Coverage

Before migrating, understand what AWS WAF is currently doing for you:

# List all Web ACLs
aws wafv2 list-web-acls --scope REGIONAL --region eu-central-1

# Get rule details for a specific Web ACL
aws wafv2 get-web-acl --name ProductionWAF --scope REGIONAL --region eu-central-1 --id <webacl-id>

# Review recent blocked requests
aws cloudwatch get-log-events \
  --log-group-name aws-waf-logs-production \
  --log-stream-name <stream> \
  --start-time $(date -d '7 days ago' +%s000) \
  | jq '.events[].message | fromjson | select(.action == "BLOCK") | {ip: .httpRequest.clientIp, rule: .terminatingRuleId, uri: .httpRequest.uri}'

Document: which managed rule groups are active, which custom rules exist, what the false-positive rate is (block vs. allow ratio), which URIs generate the most blocks.

Phase 2: Deploy EU-Native WAF in Parallel

Deploy BunkerWeb or Coraza on your EU infrastructure alongside existing AWS WAF. Configure it with OWASP CRS at the same detection level as your current AWS WAF configuration. Route a test traffic segment through the EU WAF.

# BunkerWeb Docker Compose example (EU-hosted)
version: '3'
services:
  bunkerweb:
    image: bunkerity/bunkerweb:latest
    environment:
      - SERVER_NAME=yourapp.eu
      - USE_MODSECURITY=yes
      - USE_MODSECURITY_CRS=yes
      - MODSECURITY_SEC_RULE_ENGINE=On
      - USE_BAD_BEHAVIOR=yes
      - BAD_BEHAVIOR_COUNT_TIME=60
      - USE_LIMIT_REQ=yes
      - LIMIT_REQ_RATE=100r/s
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./bw-data:/data

Phase 3: Validate Log Coverage and False Positive Rates

Compare blocked request logs from EU WAF against AWS WAF logs for the same traffic period. Tune OWASP CRS paranoia level and exception rules to match your acceptable false-positive rate.

# Count blocks per hour in BunkerWeb logs
grep "bunkerweb" /var/log/syslog | grep "blocked" | \
  awk '{print $1" "$2}' | \
  sed 's/:.*//' | \
  sort | uniq -c

Phase 4: Migrate DNS and Disable AWS WAF

Once log analysis confirms equivalent protection with acceptable false-positive rates, update your load balancer or CloudFront distribution to remove the AWS WAF Web ACL association. Update DNS to route traffic through your EU-hosted WAF layer.

# Remove WAF association from ALB (disassociate Web ACL)
aws wafv2 disassociate-web-acl \
  --resource-arn arn:aws:elasticloadbalancing:eu-central-1:123456789:loadbalancer/app/...

# Verify disassociation
aws wafv2 get-web-acl-for-resource \
  --resource-arn arn:aws:elasticloadbalancing:eu-central-1:123456789:loadbalancer/app/...

Log destination migration: Disable CloudWatch Logs delivery for your AWS WAF Web ACL and delete the CloudWatch Log Group containing WAF logs after your retention period obligation has passed. For GDPR compliance, ensure your log retention settings on the EU-native WAF match your documented data retention policy.

Ready to move to EU-sovereign infrastructure?

sota.io is a German-hosted PaaS — no CLOUD Act exposure, no US jurisdiction, full GDPR compliance by design. Deploy your first app in minutes.

Start free — no credit card View pricing