AWS Shield EU Alternative 2026: DDoS Protection, SRT Access, and the GDPR Problem

Post #730 in the sota.io EU Compliance Series

AWS Shield is the default DDoS protection layer for applications running on AWS. Shield Standard is included automatically for all AWS customers — no configuration required. Shield Advanced is the premium tier: it adds intelligent DDoS detection, integration with AWS WAF, cost protection during DDoS-induced traffic spikes, and access to Amazon's Shield Response Team (SRT) for hands-on attack mitigation support.

For European applications, Shield looks like a sensible infrastructure choice. DDoS attacks are a genuine operational threat, Shield is deeply integrated with existing AWS services, and CloudFront edge locations in Europe mean much of the traffic scrubbing happens geographically close to EU users.

This integration obscures a structural GDPR problem. 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. But AWS Shield goes further than simple data storage: it creates ongoing relationships between your application traffic, AWS employees, and a global threat-intelligence infrastructure — all under US jurisdiction.

This analysis examines six distinct GDPR exposure points in AWS Shield that European development teams frequently overlook.

The Shield Response Team: AWS Employees in Your Traffic

AWS Shield Advanced includes access to the Shield Response Team (SRT) — a group of Amazon security engineers who can assist during active DDoS events. Proactive Engagement is the Shield Advanced feature that enables this: when Shield detects a potential DDoS event affecting your application, the SRT proactively contacts you and offers direct assistance.

For the SRT to assist effectively, they need access to your infrastructure. Shield Advanced allows you to grant the SRT access to your:

• Amazon CloudWatch alarms and dashboards
• AWS WAF rules and logs (including request logs with source IPs)
• Elastic Load Balancing and AWS Global Accelerator configurations
• Route 53 hosted zones and health check configurations
• CloudFront distributions and access logs
• Amazon EC2 network flow logs

This is not theoretical access. When Proactive Engagement is active and a DDoS event is detected, AWS engineers are reviewing your traffic logs, your WAF rule matches, and your application availability status.

The GDPR problem: AWS employees are natural persons subject to US law. Any data they access in the course of SRT incident response is data that has been processed by a US-jurisdiction party. Under GDPR Art. 28, any party that processes personal data on behalf of a controller must be covered by a Data Processing Agreement that specifies the processing conditions. AWS's standard DPA covers AWS's automated infrastructure operations — it does not create a separate legal framework for human SRT employees accessing your WAF logs, which contain user IP addresses, HTTP headers, and request URIs.

When the SRT reviews your WAF request logs to identify attack patterns, they are processing personal data (source IP addresses, HTTP headers) under the control of a US entity. A CLOUD Act order served on Amazon can compel disclosure of what the SRT accessed — and because the access was real-time and human-mediated, the scope of potential disclosure is broader than a simple data export.

Global Threat Intelligence: Your Traffic Contributes to AWS's Dataset

Shield Advanced does not operate in isolation. AWS describes Shield's detection capabilities as powered by a "global threat environment" — attack patterns observed across all Shield customers are used to improve detection for all Shield customers. When Shield detects a DDoS attack against your application, the attack characteristics (source IP ranges, attack vectors, traffic volumes, protocol patterns) become part of AWS's global threat-intelligence dataset.

This cross-customer data aggregation has a legitimate technical purpose: DDoS attacks targeting one customer often precede or accompany attacks on others. Shared threat intelligence improves collective defense.

The GDPR problem: Source IP addresses in DDoS traffic are personal data under GDPR. In a volumetric UDP flood, the source IPs are often spoofed. In application-layer attacks (HTTP floods), the source IPs are real — they include legitimate EU users whose requests have been incorrectly classified as attack traffic, bystander IPs caught in collateral traffic, and in some cases the IPs of actual human actors.

When these IPs are ingested into AWS's global threat-intelligence infrastructure, they are being processed for a secondary purpose (training AWS's threat models) beyond the original purpose (protecting your specific application). GDPR Art. 5(1)(b) requires that personal data is collected for specified, explicit, and legitimate purposes and not further processed in a manner incompatible with those purposes. The question of whether contributing user-associated IP data to a proprietary threat-intelligence network is compatible with the original collection purpose (providing a service to your users) is not resolved by AWS's terms of service.

WAF Request Logging: A Full Personal Data Record of Every Request

Shield Advanced is deeply integrated with AWS WAF — to the point that Shield Advanced customers are strongly encouraged to deploy WAF alongside Shield. AWS uses WAF rule matches to improve Shield's application-layer DDoS detection.

AWS WAF can log all web requests that it inspects. Each WAF request log record contains:

• The source IP address of the request
• The HTTP request method, URI, and query string
• The HTTP request headers (including User-Agent, Referer, Cookie headers)
• The geo-location country derived from the source IP
• The timestamp of the request
• The WAF rule that matched (or the default action applied)

This is a complete behavioral record of every user who visited your application, structured as a security log. WAF logs are sent to an Amazon CloudWatch Logs log group, an Amazon S3 bucket, or an Amazon Kinesis Data Firehose delivery stream. If you are using CloudWatch Logs (the default for Shield Advanced integration), these logs are processed and stored under AWS's US-jurisdiction infrastructure.

The GDPR problem: WAF request logs are personal data records under GDPR Art. 4(1). An IP address combined with a timestamp and a URI is sufficient to identify a natural person's online activity. Cookie header values in WAF logs can contain session identifiers, authentication tokens, or persistent tracking identifiers. The User-Agent header reveals device and browser information. These records, collected at volume, constitute detailed personal data about your users' interaction with your application.

If WAF logs are sent to CloudWatch Logs (us-east-1 default), they are stored under US jurisdiction. A valid CLOUD Act request can reach these logs. European data protection authorities — including the German and Dutch DPAs — have taken the position that transferring such behavioral data to US-jurisdiction services without Standard Contractual Clauses and a Transfer Impact Assessment constitutes a GDPR violation. See also: AWS CloudWatch EU Alternative and AWS WAF EU Alternative.

Route 53 Health-Based Detection: Availability Data Under US Jurisdiction

Shield Advanced uses Route 53 health checks as an input signal for DDoS detection. Proactive Engagement specifically requires that you associate Shield Advanced protections with Route 53 health checks. Shield monitors the health check status — when your application becomes unhealthy, Shield treats this as a potential DDoS indicator and may engage the SRT.

Route 53 is an AWS US-jurisdiction service. Health check configuration, health check results, and health check history are stored in Route 53's infrastructure. This means the operational availability state of your application — which endpoints are healthy, which are degraded, when outages occurred — is maintained under US-jurisdiction control.

The GDPR problem: Application availability data is operational metadata about your system. Under GDPR, this is not directly personal data. However, availability events are causally linked to user experience — a service degradation at 14:32 UTC correlates with user sessions that were active at that time. In combination with other data sources, availability telemetry can be used to reconstruct information about user activity.

More directly: the architectural dependency on Route 53 for Shield Advanced Proactive Engagement creates a structural coupling between your DDoS protection and a US-jurisdiction DNS service. Replacing Shield Advanced without also replacing Route 53 breaks the Proactive Engagement integration. This creates lock-in that extends beyond Shield itself. The full scope of this lock-in is documented in AWS Route 53 EU Alternative.

Attack Telemetry Retention: How Long Does AWS Keep Your DDoS Data?

Shield Advanced generates detailed attack telemetry for each DDoS event: start and end times, attack vectors, peak request rates, source IP ranges contributing to the attack, mitigation actions taken, and the effectiveness of each mitigation.

This telemetry is surfaced in the Shield console and available via the Shield API. AWS retains Shield attack telemetry for 13 months. This retention period is set by AWS — not configurable by the customer.

The GDPR problem: If the attack traffic included legitimate EU user IPs that were incorrectly flagged (a common occurrence in application-layer floods where attacker traffic blends with real user traffic), those IPs appear in the attack telemetry and are retained for 13 months. The affected users have no visibility into this retention. GDPR Art. 5(1)(e) requires that personal data is kept for no longer than necessary — a blanket 13-month retention for potentially misclassified user IPs, set unilaterally by AWS, is difficult to reconcile with this requirement.

Additionally, this attack telemetry is under CLOUD Act reach for the full 13-month retention window.

The CloudFront Dependency: Extending the Jurisdiction Chain

Shield Advanced integration with Amazon CloudFront extends the jurisdiction problem further. CloudFront is AWS's content delivery network. When Shield Advanced protects a CloudFront distribution, attack traffic is mitigated at CloudFront edge locations — including edge locations in the United States.

This means EU user traffic destined for your European application may be routed through US-located CloudFront edge nodes for DDoS scrubbing before being forwarded to your EU origin server. During a DDoS event, user IP addresses, request content, and HTTP headers pass through AWS infrastructure on US soil — subject to direct US legal process, not just CLOUD Act cloud-storage requests.

For applications with strict EU data residency requirements: AWS CloudFront does not guarantee that traffic from EU users will be processed exclusively at EU edge locations. The anycast routing that underlies CloudFront distributes traffic globally based on network conditions. A GDPR legal basis that relies on data not leaving the EU cannot be satisfied by a CDN architecture that routes traffic globally as a matter of normal operation. The CloudFront jurisdiction problem is documented in detail in AWS CloudFront EU Alternative.

EU Alternatives to AWS Shield

European organizations need DDoS protection that does not carry US-jurisdiction exposure. The following alternatives provide effective mitigation without the structural GDPR problems documented above.

Hetzner DDoS Protection

Hetzner Online GmbH is a German company headquartered in Gunzenhausen, Bavaria. DDoS protection is included automatically with all Hetzner Cloud and dedicated server products — there is no separate Shield-equivalent service to configure or pay for.

Hetzner's infrastructure is located in Germany (Nuremberg, Falkenstein, Nuremberg) and Finland (Helsinki). Traffic does not route through US PoPs. The legal entity is a German GmbH subject exclusively to German and EU law. There is no CLOUD Act exposure — the CLOUD Act applies to US companies only.

The protection covers volumetric attacks (UDP floods, ICMP floods, SYN floods) at the network layer. For application-layer protection equivalent to Shield Advanced + WAF, you would deploy an application-layer firewall separately (nginx rate limiting, fail2ban, ModSecurity, or a dedicated WAF appliance).

OVHcloud Anti-DDoS (VAC Technology)

OVHcloud is a French company headquartered in Roubaix. Its proprietary anti-DDoS technology — called VAC (Vacuum) — is deployed across all OVHcloud data centers including Strasbourg, Gravelines, Roubaix (France), Warsaw (Poland), Frankfurt, and London.

OVHcloud Anti-DDoS is included with dedicated servers and available as an option for Public Cloud instances. The VAC system scrubs traffic at the PoP closest to the attack source, returning clean traffic to your server. This architecture keeps EU user traffic within EU network infrastructure.

OVHcloud operates under French and EU law. Its DPA is fully GDPR-compliant and covers all data processed in the course of DDoS mitigation.

Cloudflare DDoS Protection and Magic Transit

Cloudflare operates a European legal entity (Cloudflare Ltd, registered in Ireland) and processes data under EU-US Data Privacy Framework adequacy. For GDPR-sensitive applications, Cloudflare's European Union configuration — which restricts data processing to EU PoPs — is available under Cloudflare for Teams and Magic Transit contracts.

Cloudflare's DDoS protection is network-level (Magic Transit, Layer 3/4) and application-level (via the Cloudflare WAF, Layer 7). Magic Transit uses BGP anycast to route your IP prefixes through Cloudflare's network, providing scrubbing before traffic reaches your origin.

Key distinction from AWS Shield: Cloudflare does not have a personnel access model equivalent to the SRT. DDoS detection and mitigation is automated. No Cloudflare employee has automatic access to your request logs during an attack event.

Important caveat: Cloudflare is a US company (Cloudflare, Inc., San Francisco). Even with EU-entity contractual arrangements, the parent company is subject to US jurisdiction. This is a more nuanced exposure than AWS Shield — the EU adequacy decision and Cloudflare's architectural commitment to EU data processing provide meaningful mitigation — but it is not equivalent to a purely EU-domiciled provider.

Stormwall

Stormwall is a DDoS protection provider with EU-located scrubbing infrastructure. Unlike hyperscaler DDoS protection, Stormwall is purpose-built for DDoS mitigation and does not carry the cross-service data aggregation risks of AWS Shield.

On-Premises and Self-Hosted Options

For organizations with strict data sovereignty requirements, on-premises DDoS mitigation is possible:

• NETSCOUT Arbor — deployable in your own data center, EU-only processing
• Radware DefensePro — hardware appliance, no cloud component required
• OPNsense / pfSense + crowdsec — open-source application-layer protection for smaller applications

sota.io: EU-Native Infrastructure with Network Protection

Applications deployed on sota.io run on EU-located infrastructure under EU jurisdiction. Network-level protection is part of the underlying infrastructure. There is no SRT-equivalent giving platform employees access to your traffic data, no global threat-intelligence network absorbing your attack telemetry, and no Route 53 dependency coupling your DDoS protection to US-jurisdiction DNS.

For applications moving from AWS, sota.io eliminates the entire category of Shield-related GDPR exposure by placing the application in an EU-jurisdiction environment from the start.

Summary: What Makes AWS Shield a GDPR Risk

AWS Shield's GDPR exposure is not primarily about where data is stored — it is about who can access your traffic data, under what legal authority, and for how long. The SRT access model, the global threat-intelligence aggregation, and the Route 53 health-check dependency each create structural connections between your EU users' traffic and US-jurisdiction parties. For European applications where data sovereignty is a genuine requirement, these connections are not resolvable through configuration alone.

The posts in this series cover the same structural US-jurisdiction problem across the AWS stack: AWS WAF, AWS CloudFront, AWS Route 53, AWS CloudWatch, AWS S3, AWS VPC, AWS Shield.