AWS Network Firewall EU Alternative 2026: Deep Packet Inspection, Flow Logs, and GDPR Under the CLOUD Act

Post #747 in the sota.io EU Compliance Series

AWS Network Firewall is Amazon's managed network security service for VPCs. It provides stateful and stateless packet filtering, intrusion prevention system (IPS) capabilities powered by Suricata-compatible rule groups, and deep packet inspection for traffic flowing through your VPCs. Unlike security groups and NACLs — which operate at the packet header level — Network Firewall can inspect packet payloads, perform protocol anomaly detection, and enforce URL filtering. It integrates with AWS Firewall Manager for centralized policy management across AWS Organizations, and ships logs to Amazon CloudWatch Logs, Amazon S3, and Amazon Kinesis Data Firehose.

Network Firewall addresses genuine security requirements. VPC traffic inspection catches threats that security groups miss: command-and-control traffic on allowed ports, data exfiltration via DNS tunneling, protocol violations that indicate compromise, lateral movement within VPC subnets. The Suricata rule engine provides access to open-source threat intelligence rulesets (Emerging Threats, commercial feeds) and custom Suricata rules that detection teams can tailor to organizational environments.

The structural GDPR problem: Network Firewall operates at the intersection of network security and personal data. Every connection that passes through a Network Firewall endpoint is logged — source IP, destination IP, port, protocol, connection state, packet payload snippets for matched rules. In organizational AWS environments, source IPs map to EC2 instances running specific workloads, to VPN endpoints used by named employees, or to containers processing user data. The connection logs and alert records Network Firewall produces contain personal data about employees, users, and the behavioral patterns of systems processing EU personal data. These logs flow to CloudWatch Logs or S3 — both operated by a US company subject to CLOUD Act jurisdiction.

What AWS Network Firewall Actually Does

Network Firewall deploys as a set of firewall endpoints within your VPC subnets. Traffic is routed through these endpoints via VPC route table entries: traffic that would normally flow directly between subnets, to internet gateways, or through VPC peering connections is instead routed through the firewall endpoint for inspection.

The firewall engine processes packets through two tiers: stateless rules (evaluated against individual packets without connection tracking, analogous to enhanced NACLs) and stateful rules (evaluated with connection state awareness, enabling detection of connection-level patterns). Stateful rules support three rule formats: Suricata-compatible IPS rules (full signature syntax with payload inspection), domain list rules (URL filtering and SNI inspection for TLS traffic), and standard stateful 5-tuple rules (protocol, source IP/port, destination IP/port with pass/drop/alert actions).

For TLS traffic, Network Firewall can inspect the Server Name Indication (SNI) field in the TLS ClientHello without decrypting the payload. This enables domain-based filtering for encrypted HTTPS traffic. Full TLS decryption and inspection requires AWS TLS inspection configuration, which terminates TLS at the firewall endpoint, inspects the decrypted payload, and re-encrypts for forwarding — with the decrypted traffic briefly in memory on AWS-managed infrastructure.

Alert logs capture every Suricata rule match: rule signature ID, category, source and destination IP/port, timestamp, and optionally packet payload excerpts. Flow logs capture connection-level telemetry: source IP, destination IP, source port, destination port, protocol, bytes transferred, packets, connection state, start time, end time. Both log types flow to one or more configured log destinations — CloudWatch Logs log groups, S3 buckets, or Kinesis Data Firehose delivery streams.

GDPR Exposure Point 1: Employee IP Addresses as Personal Data in Flow Logs

The foundational GDPR issue with AWS Network Firewall flow logs is the personal data embedded in network flow records. Under Breyer v. Germany (C-582/14), the CJEU established that dynamic IP addresses can constitute personal data when the data controller has the legal means to identify the natural person to whom the address corresponds. In organizational AWS environments, IP addresses in Network Firewall flow logs frequently map to identifiable individuals.

VPN gateway connections: Organizations using AWS Client VPN or Site-to-Site VPN assign IP addresses to employee VPN connections. The assigned IP appears as the source address in flow logs for the duration of the VPN session. If VPN assignment records link employee identities to session IPs — which they do for any VPN implementation with per-user authentication — then flow log records containing those IPs are personal data records about specific employees.

EC2 instances with known functions: An EC2 instance running an HR application, processing customer data, or serving a development environment has a known IP address. Flow logs showing connections to and from that instance constitute records of who accessed what data — particularly where the destination IPs map to known data stores (RDS cluster endpoints, S3 service endpoints, specific application IPs).

Container workloads: ECS and EKS workloads run on EC2 instances or Fargate tasks with assigned IP addresses. If network addressing policies assign consistent IPs to containers running workloads for specific teams or services, flow logs provide a record of those workloads' network behavior — and through the workload mapping, the behavior of the employees who built and operated them.

Under GDPR Art. 4(1), this data is personal data to the extent it can be linked to identified or identifiable natural persons. Under Art. 5(1)(b) (purpose limitation), network security monitoring is a legitimate purpose for collecting network flow data — but that purpose does not automatically justify storage of that data on US-jurisdiction infrastructure under the control of a US company subject to CLOUD Act. Under Art. 5(1)(e) (storage limitation), flow log retention must not exceed what is necessary for the security monitoring purpose.

GDPR Exposure Point 2: Suricata Alert Logs — Behavioral Profiles Through Security Events

Suricata-compatible IPS rules match against network traffic and generate alert records when signatures fire. Alert logs are where Network Firewall's personal data processing becomes most significant from a GDPR perspective. Alert records contain not just connection metadata but often payload excerpts, protocol details, and the full context of the matched event.

Alert categories reveal behavioral patterns. An alert for a match on an Emerging Threats signature for "Malware C2" reveals that a specific IP (potentially linked to an employee device or workload) communicated with a known command-and-control server. An alert for "Unauthorized Data Exfiltration" reveals that a specific workload transferred an unusual volume of data to an external IP. An alert for "Policy Violation — Social Media Access" reveals that a specific internal IP accessed blocked social media platforms during work hours.

The aggregation of alert records creates a behavioral profile of network activity — which systems communicated with which external services, when, with what frequency, and whether those communications triggered security concerns. For employees whose devices or VPN sessions are associated with specific IPs, this profile is personal data about their professional network behavior.

Under GDPR Art. 22 (automated individual decision-making), if alert patterns contribute to automated decisions affecting employees — disciplinary procedures, access revocation, security investigations — the creation of behavioral profiles from Network Firewall alerts requires appropriate safeguards including meaningful information to employees about the monitoring and the logic involved. German works council consultation requirements (BDSG §26) apply to employee monitoring systems, which Network Firewall with behavioral logging potentially constitutes.

Under the CLOUD Act, alert logs stored in CloudWatch Logs or S3 are subject to compelled disclosure to US authorities. A CLOUD Act request could yield a complete record of every security alert triggered by employee or workload activity over the retention period — including the behavioral inferences embedded in alert categories and the payload excerpts that triggered matched signatures.

GDPR Exposure Point 3: TLS Inspection and Payload Processing Under US Jurisdiction

AWS Network Firewall's TLS inspection capability creates a particularly acute GDPR exposure. When TLS inspection is enabled, Network Firewall performs a man-in-the-middle operation: it terminates the TLS connection from the originating client, inspects the decrypted payload, and establishes a new TLS connection to the destination. The decrypted payload is processed on AWS-managed infrastructure.

For traffic that carries personal data — HTTPS API calls that include user data payloads, TLS-wrapped database connections, encrypted file transfers — TLS inspection means the personal data within that traffic passes through AWS infrastructure in decrypted form. AWS manages the firewall endpoint infrastructure that performs this decryption.

Under GDPR Art. 28, any organization that processes personal data on behalf of a controller is a data processor and requires a Data Processing Agreement. AWS provides a DPA for its services. But the TLS inspection use case requires careful Art. 28 analysis: AWS, as the processor operating the infrastructure that decrypts and re-encrypts traffic, has access to the plaintext personal data for the duration of the inspection. This access is operationally necessary for the service but creates a disclosure surface under CLOUD Act that would not exist without TLS inspection.

Organizations using Network Firewall TLS inspection for traffic carrying EU personal data should document this under GDPR Art. 30 (Records of Processing Activities) with explicit notation of the TLS interception, the categories of personal data potentially exposed during inspection, and the CLOUD Act jurisdictional risk. The DPA's standard contractual clauses may not address the specific risk profile of momentary decryption on AWS infrastructure.

GDPR Exposure Point 4: Centralized Logging as Organizational Intelligence

Network Firewall logs shipped to CloudWatch Logs create centralized records of network behavior across VPC environments. For organizations with multiple VPCs in EU regions — a common pattern for environment separation (dev/staging/production) or workload isolation — the aggregate Network Firewall log stream contains a complete map of inter-VPC communication patterns.

This communication map constitutes organizational intelligence: which development environments connect to which production databases, which services communicate with which third-party APIs, which workloads have anomalous traffic patterns that might indicate compromise or misconfiguration. Under CLOUD Act, a demand for the CloudWatch Logs log group containing Network Firewall flow logs would yield this complete communication map for all VPCs logging to that group.

For organizations subject to NIS2 Article 21 (network and information systems security measures), Network Firewall with centralized logging serves a legitimate compliance function: demonstrating that network traffic is monitored and that security incidents are detected and logged. But NIS2's network security requirements do not require that the monitoring infrastructure be operated by a US company — and Article 21(1) explicitly states that security measures must take into account the state of the art, including appropriate technical and organizational measures.

A network security architecture that uses EU-jurisdiction logging infrastructure (self-hosted Suricata with Elasticsearch on EU-hosted infrastructure, or Network Firewall with logs delivered to a Kinesis Firehose endpoint backed by EU-hosted storage) satisfies NIS2's intent while maintaining GDPR jurisdiction control over the generated personal data.

GDPR Exposure Point 5: DNS Query Logging via Domain List Rules

Network Firewall's domain list rules inspect DNS queries and TLS SNI fields to enforce URL filtering. When traffic to a domain matches a deny rule, Network Firewall drops the connection and logs the block. When monitoring rules fire alerts on domain matches, the alert record includes the queried domain and the source IP.

DNS query records constitute personal data when the source IP is associated with an identifiable individual. The queried domain additionally reveals behavioral information: which external services an employee or workload accessed, which third-party APIs a service communicates with, which external resources a workload depends on. DNS query patterns can reveal operational details (which SaaS tools teams use), security concerns (which threat intelligence domains were queried), or sensitive activities (HR systems, legal services, medical resources).

Domain list rules with logging enabled create an ongoing record of network communication patterns that, per the Breyer v. Germany analysis, may constitute personal data about the employees whose devices or services generate the DNS traffic. This record flows to CloudWatch Logs or S3 under US jurisdiction.

Under GDPR Art. 13/14 (transparency), employees whose network traffic is inspected by Network Firewall have a right to information about the monitoring. The data processing notice must cover: what categories of data are collected (connection metadata, DNS queries, alert records), the legal basis for collection (Art. 6(1)(f) legitimate interests or Art. 6(1)(c) legal obligation for security monitoring), the retention period, and the recipients — including AWS as a data processor and the potential for CLOUD Act disclosure to US authorities.

GDPR Exposure Point 6: Firewall Manager Integration — Multi-Account Policy as Organizational Map

When AWS Firewall Manager manages Network Firewall policies across an AWS Organizations structure, it creates a centralized record of the network security posture for the entire organization. Firewall Manager stores policy definitions, compliance status reports, and policy violation records in the AWS management account.

The compliance status data from Firewall Manager reveals which accounts and VPCs are protected by which firewall policies, which accounts have non-compliant network configurations, and which VPCs are missing required firewall endpoints. This organizational map of network security posture — stored in the Firewall Manager management account under US jurisdiction — is subject to CLOUD Act disclosure with a single demand to the management account.

For organizations with Security Hub integration, Network Firewall findings route to Security Hub as security findings in the ASFF format. The centralized Security Hub findings aggregator in the management account pulls these findings from all member accounts, creating a consolidated view of network security events across the organization. The CLOUD Act exposure of Security Hub findings (covered in our AWS Security Hub post in this series) extends to include Network Firewall alert data routed through Security Hub.

EU-Native Alternatives to AWS Network Firewall

The functions of AWS Network Firewall — stateful packet filtering, IPS, domain filtering, flow logging — are achievable with EU-hosted open-source and commercial tooling that keeps network security telemetry under EU jurisdiction.

Suricata (self-hosted) is the IPS engine that powers AWS Network Firewall's signature-based detection. Deploying Suricata directly on EC2 instances in EU regions (or on bare-metal infrastructure in EU data centers) provides identical IPS capabilities with logs written to local storage you control. Suricata supports the same Emerging Threats and commercial rulesets available through Network Firewall, plus custom Suricata rules, without any data flowing to AWS-managed infrastructure. Configure Suricata to log to Elasticsearch running in your EU-hosted environment for queryable alert and flow log storage.

OPNsense and pfSense are open-source firewall distributions based on FreeBSD that provide stateful packet filtering, IPS (via Suricata or Snort plugins), DNS filtering (pfBlockerNG), and VPN capabilities. Deployed on EC2 instances in EU regions or on physical hardware in EU data centers, they provide Network Firewall-equivalent capabilities without AWS dependency. All logs write to local syslog or an on-premises SIEM.

VyOS is an open-source network OS supporting stateful firewall, IPS via Suricata, VPN, and routing. It runs on EC2 instances or physical hardware, stores all configuration and telemetry locally, and integrates with standard syslog infrastructure. For organizations running Terraform-managed infrastructure, VyOS configurations are fully scriptable.

Stamus Networks (France) provides a Suricata-based network security solution with EU data residency. As a French company, it is not subject to US CLOUD Act jurisdiction, and its data processing infrastructure operates within the EU. Stamus Networks Scirius CE (community edition) is open source.

Gatewatcher (France) provides network detection and response specifically designed for critical infrastructure and compliance-sensitive environments in the EU. It processes network telemetry on EU-hosted infrastructure and is built for French/EU regulatory environments including NIS2 and ANSSI requirements.

A practical self-hosted deployment for organizations migrating from Network Firewall:

# Deploy Suricata on an EC2 instance in eu-central-1
# All logs stay in your EU-hosted Elasticsearch cluster

# Install Suricata
sudo apt-get install -y suricata

# Configure EVE JSON logging (equivalent to Network Firewall alert/flow logs)
sudo tee /etc/suricata/suricata.yaml << 'EOF'
outputs:
  - eve-log:
      enabled: yes
      filetype: regular
      filename: /var/log/suricata/eve.json
      types:
        - alert:
            payload: yes
            payload-buffer-size: 4kb
        - flow
        - dns
        - http
        - tls
EOF

# Update threat intelligence rules (equivalent to Network Firewall managed rule groups)
sudo suricata-update update-sources
sudo suricata-update enable-source et/open      # Emerging Threats Open
sudo suricata-update

# Start Suricata on network interface
sudo suricata -c /etc/suricata/suricata.yaml -i eth0 --af-packet

Configure Filebeat on the same instance to ship eve.json to your Elasticsearch cluster running in eu-central-1. The complete Network Firewall-equivalent monitoring stack — IPS engine, alert logs, flow logs, threat intelligence — runs on infrastructure you control, with logs stored in EU jurisdiction.

For VPC-level traffic inspection (equivalent to Network Firewall's VPC endpoint deployment), use EC2 instances with traffic mirroring or Gateway Load Balancer to route VPC traffic through self-hosted Suricata instances before forwarding.

The NIS2 Compliance Angle

NIS2 Article 21 requires operators of essential services and important entities to implement appropriate network security measures including "policies and procedures for the use of cryptography and, where appropriate, encryption" and "the security of network and information systems." NIS2 explicitly requires supply chain security measures addressing the security practices of service providers.

Deploying AWS Network Firewall for NIS2-covered workloads requires an analysis of whether using a US-jurisdiction service provider for a core network security function satisfies NIS2's supply chain security requirements. NIS2 does not prohibit US cloud services, but it requires that appropriate measures are in place — including understanding the CLOUD Act exposure of security telemetry generated by the service.

The ENISA NIS2 Implementation Guidance (2024) notes that organizations should consider "the ability of service providers to provide evidence of security measures and to respond to audits, as well as the risk of dependency on non-EU service providers." AWS Network Firewall's CLOUD Act exposure for network security telemetry is exactly the kind of non-EU service provider risk NIS2 implementation guidance requires organizations to assess.

Self-hosted Suricata or EU-native network security tooling on sota.io infrastructure provides NIS2-aligned network security without the supply chain risk of US-jurisdiction telemetry storage.

Summary

AWS Network Firewall's GDPR exposure under CLOUD Act derives from six structural characteristics: employee IP addresses in flow logs constitute personal data under Breyer v. Germany, Suricata alert logs create behavioral profiles through accumulated security events, TLS inspection briefly exposes personal data payloads on AWS-managed infrastructure, centralized CloudWatch logging creates organizational communication maps under US jurisdiction, DNS query records via domain list rules reveal individual browsing and service access patterns, and Firewall Manager integration exposes multi-account security posture as consolidated intelligence.

All six exposures share the same root: Network Firewall stores its operational output in AWS-managed infrastructure subject to US jurisdiction. Moving network security monitoring to self-hosted Suricata, OPNsense, or EU-native commercial tools on EU-hosted infrastructure keeps network security telemetry — which includes personal data about employees and users — under EU jurisdiction where CLOUD Act does not apply.

Deploying network security infrastructure on sota.io's EU-native PaaS in Frankfurt provides the operational environment for self-hosted Suricata or OPNsense, with all flow logs, alert records, and DNS query data stored in EU jurisdiction from the moment of generation.

Part of the sota.io EU Compliance Series — practical GDPR analysis for developers deploying on AWS.