AWS GuardDuty EU Alternative 2026: Threat Detection, DNS Analysis, and GDPR Compliance

Post #709 in the sota.io EU Compliance Series

AWS GuardDuty is the security service you deploy to protect your EU users. It watches your AWS environment for malicious activity — compromised credentials, cryptomining instances, exfiltration attempts, command-and-control communication. Enabling it is security best practice. Your security team wants it. Your compliance audit will ask about it.

Here is the paradox: by deploying GuardDuty, you create a comprehensive behavioral surveillance record of your EU users and hand it to a US company.

GuardDuty works by continuously analyzing three data sources: VPC Flow Logs (network metadata for every connection), DNS query logs (every domain lookup your infrastructure makes), and CloudTrail management events (every API call in your account). All of this analysis happens under AWS infrastructure. All of it is subject to CLOUD Act (18 U.S.C. § 2713). The threat detection service that protects your EU users from attackers creates a parallel surveillance capability that US government orders can compel.

This is not a theoretical risk. It is the architectural reality of how GuardDuty works.

What GuardDuty Analyzes Under US Jurisdiction

VPC Flow Logs: Network Behavioral Profiles

VPC Flow Logs capture the metadata of every network connection in your AWS environment:

version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status
2 123456789012 eni-0a1b2c3d 203.0.113.12 10.0.1.5 54321 443 6 20 4200 1714384000 1714384060 ACCEPT OK
2 123456789012 eni-0a1b2c3d 10.0.1.5 203.0.113.12 443 54321 6 25 52400 1714384000 1714384060 ACCEPT OK

For a GDPR analysis, the critical fields are srcaddr and dstaddr. The source address is your EU user's IP — either directly or after Network Address Translation, traceable to an individual. The destination addresses reveal which services the user is accessing.

GuardDuty ingests this flow data continuously. Its ML models build a behavioral baseline for your account: what is normal traffic volume, what connection patterns are expected, which geographic regions should be seeing connections. Any deviation from baseline triggers a finding.

The baseline itself is personal data under GDPR. A behavioral model of "what eu-user-8847261 normally does at 09:00 on Tuesday" is a data profile. When GuardDuty builds this model to detect anomalies, it creates a derived representation of individual behavior — generated by a US company from EU user traffic — under US jurisdiction.

DNS Query Analysis: The Behavioral Data Problem

DNS queries are particularly sensitive because they are predictive of health, beliefs, and private associations in ways that standard network metadata is not.

GuardDuty's DNS threat detection analyzes queries against threat intelligence databases to identify:

• Connections to known malware command-and-control domains
• Domain generation algorithm (DGA) patterns (malware generating random-looking domains)
• Cryptomining pool domains
• Fast-flux DNS patterns used by botnets

To perform this analysis, GuardDuty must see the DNS query: the domain being looked up, the timestamp, the source IP.

Consider what DNS queries from an EU application reveal:

10.0.1.5 → query: medical-records-system.eu-hospital.de
10.0.1.5 → query: patient-portal.berlin-klinik.de
10.0.1.5 → query: diabetes-treatment-platform.de

If your application integrates with healthcare APIs, pharmacy systems, or mental health platforms, DNS queries reveal which EU users are accessing which health services. Under GDPR Article 9, health data is special category data requiring explicit consent and heightened protection. DNS queries that reveal health service access are special category data.

GuardDuty's DNS analysis creates a log of these queries — timestamped, IP-attributed, and retained by a US company under CLOUD Act.

The threat detection value is real. The surveillance exposure is equally real. EU organizations in healthcare, legal, financial, and any sensitive domain are creating behavioral intelligence about their users that US authorities can compel.

CloudTrail Integration: API-Level User Profiling

GuardDuty processes CloudTrail management events to detect credential abuse, privilege escalation, and reconnaissance activity. This involves analyzing:

• IAM policy queries (what permissions is this principal checking?)
• Resource enumeration (what S3 buckets, EC2 instances, RDS databases exist?)
• Unusual geographic login patterns (EU user logging in from unexpected location)
• Credential exfiltration attempts (GetSecretValue called from unexpected source)

A GuardDuty finding for an anomalous login event contains:

{
  "type": "UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B",
  "severity": 5,
  "description": "An API call was made that resulted in a successful console login to an account...",
  "service": {
    "additionalInfo": {
      "userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)",
      "userCredentialUsed": "Password",
      "loginResult": "Success"
    },
    "action": {
      "actionType": "AWS_API_CALL",
      "awsApiCallAction": {
        "api": "ConsoleLogin",
        "callerType": "Remote IP",
        "remoteIpDetails": {
          "ipAddressV4": "203.0.113.42",
          "country": {"countryName": "Germany"},
          "city": {"cityName": "Berlin"},
          "geoLocation": {"lat": 52.52, "lon": 13.40}
        }
      }
    }
  }
}

This finding identifies a specific EU user by IP address and location, timestamped, describing their login behavior. Under GDPR, this is personal data. Under CLOUD Act, it is accessible to US authorities without EU legal process.

The Security-as-Surveillance Paradox

The fundamental GDPR problem with GuardDuty is not that it collects the wrong data. It is that to do its job well, it must collect and analyze the right data — and in doing so, it creates a detailed surveillance record of EU user behavior.

The paradox:

1. You want to detect threats to EU user data → you deploy GuardDuty
2. GuardDuty builds behavioral models of EU users → this is effective threat detection
3. Those behavioral models are retained by a US company → CLOUD Act jurisdiction
4. US authorities can compel behavioral profiles of your EU users → GDPR violation
5. The service that protects your users is also surveilling them under foreign jurisdiction

This is structurally different from many other CLOUD Act problems in this series. With S3, the exposure is data at rest — you know what's there. With CloudTrail, the exposure is historical API logs — static events. With GuardDuty, the exposure is continuously generated behavioral intelligence — a live profile of EU user activity that grows with every connection, every DNS query, every API call.

CLOUD Act and GuardDuty Findings

What a CLOUD Act Order Can Compel

A CLOUD Act order to AWS for GuardDuty-related data could compel:

1. All GuardDuty findings for an account or time period — identifying which EU users triggered anomaly alerts, when, what they were doing
2. The underlying VPC Flow Log data that GuardDuty ingested for threat analysis
3. DNS query logs ingested by GuardDuty from Route 53 Resolver
4. The behavioral baselines GuardDuty built — effectively behavioral profiles of EU users

The findings themselves are the most immediately sensitive: a finding indicates that a specific entity (identifiable by IP, IAM identity, or account) exhibited behavior that triggered a security rule. In an investigation context, findings are evidence of specific behavior.

GuardDuty Organizations: Centralized Surveillance Risk

GuardDuty supports AWS Organizations, allowing a Security Delegated Admin account to aggregate findings from all member accounts. Large organizations running multi-account AWS setups enable this as a security best practice.

The compliance implication: a single CLOUD Act order against the Admin account can compel GuardDuty findings for all member accounts simultaneously. If your AWS Organization contains accounts processing EU user data across multiple business units, a single court order provides access to behavioral intelligence about all of them.

For companies that have enabled GuardDuty Organizations, the aggregated finding data represents a comprehensive intelligence picture of all EU user activity across the entire organization — centralized, retained, and subject to US jurisdiction.

GuardDuty Finding Types and Personal Data Content

Not all GuardDuty findings contain equal personal data exposure. Understanding which finding types carry the most sensitive data helps prioritize the compliance risk:

The Trojan:EC2/DNSDataExfiltration finding type is the most concerning from a GDPR perspective: GuardDuty captures and stores DNS query content as evidence of the potential attack. If that DNS content includes queries to sensitive domains (healthcare, legal, financial), the finding contains special category data evidence under US custody.

GDPR Compliance Implications

GuardDuty as a Data Controller Problem

Under GDPR, GuardDuty creates a specific legal structure problem. When GuardDuty processes EU user data (VPC flows, DNS queries, CloudTrail events) for threat detection:

• You are the data controller (you have a GDPR lawful basis for security monitoring)
• AWS is your data processor (covered by the AWS Data Processing Agreement)
• AWS GuardDuty performs processing on your behalf

Your AWS DPA with AWS covers the processor relationship. However, the CLOUD Act problem is that AWS — as a US entity — can be compelled to produce findings data independently of the controller-processor relationship. The DPA does not protect against mandatory disclosure to US authorities. Your data subjects' rights cannot be enforced against a CLOUD Act order.

This is a gap in the GDPR controller-processor framework when the processor is subject to foreign mandatory disclosure laws: the processor's own legal obligations can override the contractual data processing limitations you have set.

Article 5(1)(e): Storage Limitation

GuardDuty retains findings for 90 days by default. You can extend this by exporting findings to S3. Many security operations teams export findings to SIEM systems for long-term retention.

Under GDPR Article 5(1)(e), personal data must not be "kept in a form which permits identification of data subjects for longer than is necessary." Security findings containing EU user behavioral data that are retained indefinitely in US-jurisdiction systems violate this principle.

The practical compliance challenge: security teams need finding retention for incident investigation and forensics. Retaining findings in a US-jurisdiction system indefinitely creates ongoing GDPR exposure.

Article 32: Appropriate Technical Measures

GDPR Article 32 requires "appropriate technical and organisational measures" to protect personal data. GuardDuty creates an interesting inversion: deploying it is an Article 32 measure (threat detection) that simultaneously creates an Article 32 risk (behavioral data under US jurisdiction).

DPOs assessing GuardDuty under Article 32 should document:

1. What personal data is processed by GuardDuty and for how long
2. What CLOUD Act exposure exists for that data
3. Whether the security benefit outweighs the privacy risk under a proportionality assessment
4. What alternative measures exist that achieve equivalent security with reduced CLOUD Act exposure

Most Article 32 assessments for GuardDuty currently omit steps 2-4.

EU-Native Threat Detection Alternatives

Wazuh (Open Source, Self-Hosted)

Wazuh is the dominant open-source security platform for organizations building EU-sovereign SOC capabilities. It provides:

• SIEM functionality: Log collection, indexing, and analysis from all infrastructure sources
• Intrusion Detection: File integrity monitoring, rootkit detection, vulnerability assessment
• Threat Intelligence: Integration with EU-hosted threat feeds (abuse.ch, MISP instances, ISACs)
• Compliance Modules: GDPR, NIS2, ISO 27001 compliance dashboards built in
• Kubernetes and Container Security: Runtime threat detection without cloud provider dependency

When deployed on EU infrastructure (Hetzner, OVH, Scaleway), Wazuh keeps all behavioral data — network flows, DNS queries, security events — under EU jurisdiction. No CLOUD Act exposure.

# Wazuh agent configuration for EU-sovereign deployment
<ossec_config>
  <client>
    <server>
      <address>wazuh-manager.eu-infra.example.com</address>
      <port>1514</port>
      <protocol>tcp</protocol>
    </server>
  </client>
  <syscheck>
    <frequency>43200</frequency>
    <directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
  </syscheck>
  <rootcheck>
    <disabled>no</disabled>
  </rootcheck>
</ossec_config>

Wazuh is used by European public sector organizations, healthcare providers, and financial institutions as a GDPR-compliant GuardDuty replacement.

Falco (Cloud Native Threat Detection)

Falco is a CNCF-graduated open-source project for runtime security in containerized environments. It monitors kernel system calls and Kubernetes API events to detect:

• Container escape attempts
• Privilege escalation in pods
• Unexpected network connections from containers
• Sensitive file access (reading /etc/shadow, /proc/*/mem)
• Cryptomining behavior

# Falco rule: Detect unexpected outbound connection from EU workload
- rule: EU Workload Unexpected External Connection
  desc: Detects outbound connection to non-approved external IPs
  condition: >
    outbound and
    not proc.name in (approved_processes) and
    not fd.ip in (approved_ips)
  output: >
    Unexpected external connection from EU workload
    (proc=%proc.name ip=%fd.ip cmdline=%proc.cmdline)
  priority: WARNING
  tags: [network, gdpr, eu-compliance]

Falco deployed on EU-jurisdiction Kubernetes clusters processes security events locally. Findings stay on EU infrastructure under EU legal jurisdiction.

Elastic Security (Self-Hosted)

The Elastic Stack (Elasticsearch + Kibana + Beats) provides enterprise-grade SIEM capabilities when self-hosted. Elastic Security adds:

• ML-based anomaly detection
• Entity Analytics (UEBA — user and entity behavior analytics)
• Threat Intelligence integration
• Detection rules aligned with MITRE ATT&CK

For organizations already running the Elastic Stack for observability, adding Elastic Security provides GuardDuty-equivalent capabilities with the same infrastructure team managing the system. EU-hosted Elastic clusters keep all SIEM data under EU jurisdiction.

Graylog Security

Graylog is a German-origin (Hamburg) SIEM platform with a strong EU adoption base. Graylog Security adds:

• Threat detection rules based on Sigma (cross-platform detection format)
• Illuminate packs for AWS, GCP, Azure log normalization
• Anomaly detection
• Compliance reporting

Graylog's German origins mean strong GDPR alignment in the product design. EU enterprise customers in banking and insurance commonly use Graylog as their central SIEM with no US cloud dependency.

Security Onion

Security Onion is a free open-source Linux distribution for threat hunting and enterprise security monitoring. It bundles Zeek (network analysis), Suricata (IDS/IPS), and Elastic Stack. For organizations running on-premises or EU VPS infrastructure:

• Network packet analysis without cloud provider involvement
• Zeek logs replace VPC Flow Logs for network behavioral analysis
• Suricata provides signature-based IDS equivalent to GuardDuty network threat detection
• All data remains on the customer's own infrastructure

How sota.io Handles Security Monitoring

sota.io is a European PaaS operating entirely on EU infrastructure without US cloud dependencies. Our security monitoring approach:

No GuardDuty. Security monitoring runs on EU-controlled infrastructure using EU-jurisdiction tooling. Customer deployment behavioral data does not leave EU infrastructure or fall under CLOUD Act jurisdiction.

EU threat intelligence. Threat detection uses EU-based threat intelligence feeds rather than US government-maintained databases. This eliminates one dependency on US-controlled security infrastructure.

Customer behavioral data isolation. Each customer deployment runs in an isolated environment. Security events related to one customer's deployment are not aggregated into a centralized US-accessible intelligence repository.

GDPR-by-design security logging. Security logs are subject to the same data minimization principles as application logs: collect what is necessary for threat detection, retain for the required period, delete thereafter. EU jurisdiction throughout.

For teams running GDPR-sensitive applications, sota.io eliminates the GuardDuty surveillance paradox at the infrastructure layer.

GDPR Implications Summary

Migration Path: From GuardDuty to EU-Sovereign Threat Detection

Step 1: Audit current GuardDuty data flows

# List active GuardDuty detectors
aws guardduty list-detectors --region eu-central-1

# Check finding export configuration
aws guardduty get-findings-export --detector-id <id>

# Review what data sources are enabled
aws guardduty get-detector --detector-id <id> \
  --query 'DataSources'

Step 2: Categorize behavioral data exposure

• Identify which DNS logs are feeding GuardDuty (sensitive domains?)
• Review VPC Flow Log sources — which contain EU user IP addresses?
• Check CloudTrail sources — which events identify EU users?

Step 3: Select EU-native replacement

• Container workloads: Falco + Wazuh
• General SIEM: Elastic Security or Graylog on EU infra
• Full SOC replacement: Wazuh or Security Onion

Step 4: Migrate finding export pipeline

# Disable GuardDuty finding export to S3 (stops US-jurisdiction retention)
aws guardduty update-findings-feedback \
  --detector-id <id> \
  --finding-ids <ids> \
  --feedback USEFUL

# Route findings to EU SIEM before disabling
# (configure Wazuh/Elastic to ingest existing findings first)

Step 5: Update DPIA and Art.30 documentation

• Remove GuardDuty from data flow diagrams in Art.30 Record
• Document EU-native threat detection measures in DPIA
• Update DPA with customers to reflect no US-jurisdiction behavioral profiling

See Also

• AWS CloudTrail EU Alternative — The audit trail GuardDuty uses as one of its data sources
• AWS IAM EU Alternative — Identity data that GuardDuty findings reference
• AWS VPC EU Alternative — The network layer GuardDuty monitors via Flow Logs
• AWS S3 EU Alternative — Where GuardDuty exports findings for long-term retention
• AWS KMS EU Alternative — Encryption keys that GuardDuty findings may reference