AWS CloudTrail EU Alternative 2026: Audit Logs, CLOUD Act, and GDPR Compliance

Post #707 in the sota.io EU Compliance Series

AWS CloudTrail is the audit backbone of the AWS ecosystem. Every API call made against any AWS service — every S3 file access, every Lambda invocation, every DynamoDB read, every IAM policy evaluation — generates a CloudTrail event. For security teams, CloudTrail is the source of truth for "who did what, when, from where." For GDPR compliance teams, CloudTrail is a structural problem.

The issue is straightforward: CloudTrail events contain personal data, and they are stored under US jurisdiction.

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 served a valid US government order. A CloudTrail trail configured to write to an S3 bucket in eu-central-1 (Frankfurt) still runs on AWS infrastructure controlled by a US entity. The region of the S3 bucket does not determine CLOUD Act applicability — the controlling entity's jurisdiction does.

For EU applications, every user who accesses data stored on AWS generates CloudTrail events that include their IP address, their session credentials, and metadata about what they accessed. Those events are personal data under GDPR. And unlike many GDPR compliance challenges, CloudTrail presents a structural problem that cannot be resolved by configuration changes: there is no mechanism to delete individual CloudTrail events.

What AWS CloudTrail Stores Under US Jurisdiction

Management Events: Every Control-Plane Action

CloudTrail Management Events (also called "control plane events") record every API call that creates, modifies, or deletes AWS resources. By default, all AWS accounts have a free management event trail limited to the last 90 days. A paid trail writes management events to S3 indefinitely.

A typical CloudTrail management event looks like this:

{
  "eventVersion": "1.09",
  "userIdentity": {
    "type": "IAMUser",
    "principalId": "AIDIODR4TAW7CSEXAMPLE",
    "arn": "arn:aws:iam::123456789012:user/alice@company.com",
    "accountId": "123456789012",
    "userName": "alice@company.com"
  },
  "eventTime": "2026-04-29T14:23:11Z",
  "eventSource": "s3.amazonaws.com",
  "eventName": "PutBucketPolicy",
  "sourceIPAddress": "203.0.113.42",
  "userAgent": "aws-cli/2.15.0",
  "requestParameters": {
    "bucketName": "my-company-user-data",
    "bucketPolicy": "..."
  },
  "responseElements": null,
  "requestID": "X5Y6Z7A8B9C0D1E2",
  "eventID": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "readOnly": false,
  "resources": [
    {
      "ARN": "arn:aws:s3:::my-company-user-data",
      "accountId": "123456789012",
      "type": "AWS::S3::Bucket"
    }
  ],
  "eventType": "AwsApiCall",
  "recipientAccountId": "123456789012"
}

From a GDPR perspective, several fields are immediately personal data:

• userIdentity.userName: alice@company.com is personal data under GDPR Art.4(1). It identifies a natural person.
• sourceIPAddress: The IP address of the person executing the API call. Personal data under GDPR when combined with timestamp and identity.
• userAgent: Browser or CLI version string. Personal data component (user profiling).
• eventTime: When the user performed the action. Combined with IP and identity, creates a behavioral record.

For IAM users whose identities are email addresses, CloudTrail management event logs are a complete behavioral history of named individuals: which AWS resources they accessed, when, from which IP addresses, using which tools. This is personal data processing under GDPR Art.4(2), subject to Art.6 legal basis requirements, Art.5(1)(e) storage limitation, and Art.17 erasure rights.

Data Events: Every S3 File Access and Lambda Invocation

CloudTrail Data Events (the "data plane" logging tier) capture individual data-level operations: every S3 GetObject and PutObject, every DynamoDB GetItem and PutItem, every Lambda Invoke. Data Events are not enabled by default — they generate extremely high log volumes and carry additional cost — but many security-conscious teams enable them for sensitive S3 buckets and DynamoDB tables.

When Data Events are enabled, every time a user accesses a file stored in S3, a CloudTrail event is written:

{
  "eventName": "GetObject",
  "eventSource": "s3.amazonaws.com",
  "userIdentity": {
    "type": "AssumedRole",
    "principalId": "AROAJQABLAH3AEXAMPLE:session-name",
    "arn": "arn:aws:sts::123456789012:assumed-role/AppRole/user-id-12345",
    "sessionContext": {
      "webIdFederationData": {
        "federatedIdentityId": "user-id-12345"
      }
    }
  },
  "sourceIPAddress": "203.0.113.99",
  "requestParameters": {
    "bucketName": "company-documents",
    "key": "users/12345/contracts/agreement-2026-01.pdf"
  }
}

This event reveals: user user-id-12345 accessed their contract document from IP 203.0.113.99 at a specific timestamp. The key field exposes the S3 object path — which in this case includes the user ID and document name.

For applications storing personal documents, medical records, financial data, or any other EU user data in S3, Data Events create a complete access log of who accessed what personal data, stored under US jurisdiction. This is precisely the kind of data processing that GDPR Art.6 and Art.30 (Records of Processing Activities) require to be documented and justified — and that GDPR Art.17 erasure requests can target.

CloudTrail Insights: Behavioral Analytics on User Actions

CloudTrail Insights automatically analyzes Management Event volumes to detect unusual patterns: a spike in IAM role assumptions, an unusual number of failed login attempts, an atypical rate of S3 bucket deletions. Insights events are written to a separate S3 prefix and remain queryable.

Insights represents a form of automated profiling of user behavior on your AWS infrastructure. For EU employees or contractors whose IAM actions are monitored by Insights, this is automated decision-making based on behavioral data — potentially subject to GDPR Art.22 restrictions on solely automated processing.

CloudTrail Lake: SQL Queries Across Years of Event History

AWS CloudTrail Lake (launched 2022) stores CloudTrail events in an AWS-managed data lake and provides SQL query capabilities via Athena-compatible interfaces. Retention can be configured from 1 to 7 years. CloudTrail Lake allows queries like:

SELECT
  userIdentity.username,
  sourceIPAddress,
  eventName,
  eventTime
FROM
  eds-id-abc123
WHERE
  eventTime > '2024-01-01 00:00:00'
  AND userIdentity.username = 'alice@company.com'

This is a queryable database of named individuals' behavior over multiple years, stored in AWS infrastructure under US jurisdiction. The retention capability and query interface make CloudTrail Lake explicitly a long-term personal data store — one that cannot be selectively deleted.

The Art.17 Structural Problem

GDPR Art.17 grants EU data subjects the right to erasure ("right to be forgotten"). When a user requests erasure of their personal data, you must delete it from all systems where it is stored — subject to lawful retention exceptions (legal obligation, public interest, legitimate interests that override the data subject's rights).

AWS CloudTrail makes Art.17 compliance structurally impossible for the personal data within event records.

There is no API to delete individual CloudTrail events. CloudTrail events, once written, are immutable. The only deletion mechanism is:

1. Trail deletion: Delete the entire trail, which stops future logging but does not delete existing S3 objects.
2. S3 object deletion: Delete individual CloudTrail log files (compressed JSON files covering a time window across all services). Each file contains thousands of events from multiple users. You cannot delete a single user's events without deleting the entire log file — which deletes all other users' audit records.
3. Lifecycle rules: Configure S3 lifecycle rules to expire objects after a fixed time period. This deletes all events older than N days — a blunt instrument that cannot target individual user records.

For an EU user who requests erasure of their personal data, a legally correct response under Art.17 requires deleting:

• Their IAM username/email from all CloudTrail management events
• Their IP address from all CloudTrail events
• All CloudTrail Data Events showing their access to personal data files

None of these deletions are possible without destroying audit records for all other users in the same log files.

The only compliant approach is to not generate the personal data in the first place — which means either not using CloudTrail (not viable for security-conscious teams) or not using AWS (viable, and the approach this guide recommends for EU applications).

S3 Object Lock: Intentional Art.17 Obstruction

A common security best practice for CloudTrail is to enable S3 Object Lock (WORM — Write Once, Read Many) on the S3 bucket where CloudTrail writes logs. Object Lock prevents deletion or modification of log files for a configured retention period. This is recommended by AWS security frameworks, SOC 2 auditors, and regulatory compliance teams for financial services.

Object Lock and GDPR Art.17 are directly contradictory for data stored under US jurisdiction:

• Object Lock says: These log files cannot be deleted for 7 years.
• GDPR Art.17 says: This user's personal data must be erased upon request.

A CloudTrail S3 bucket with Object Lock enabled legally cannot delete EU user data from its logs, regardless of erasure requests. If a DPA (Data Protection Authority) orders erasure of an EU user's data and it sits in Object Lock-protected CloudTrail logs on AWS, you face an impossible compliance situation: breach US financial regulations (by disabling Object Lock) or breach GDPR (by refusing erasure).

This contradiction is not resolvable within the AWS ecosystem. It requires using an audit logging solution where you control the storage and can implement selective erasure.

Who Is Affected

CloudTrail's GDPR implications affect EU organizations in specific scenarios:

SaaS applications with IAM-authenticated APIs: When EU employees or contractors use AWS CLI or SDK tools authenticated with IAM credentials, every API call they make generates a CloudTrail management event with their IAM username (often their email address) and IP address.

Applications storing EU personal data in S3 or DynamoDB: When Data Events are enabled, every user's access to their own data generates CloudTrail events. Even without Data Events, bucket-level S3 operations (listing, policy changes) are logged.

Multi-tenant SaaS on AWS: When each tenant has their own IAM role or when AssumedRole sessions include tenant identifiers, CloudTrail events link API actions to specific tenants — creating behavioral records of customer activity under US jurisdiction.

Developer teams with EU members: Every developer's interactions with the AWS console and CLI — creating instances, reading logs, modifying configs — are CloudTrail management events containing their email address and IP address.

EU-Native Audit Logging Alternatives

OpenTelemetry + Structured Logging (Self-Hosted)

The most flexible approach for EU-compliant audit logging is building structured audit logs using OpenTelemetry or direct JSON logging, storing them in EU-hosted infrastructure where you have selective deletion capabilities.

Architecture:

• Application emits audit events via OpenTelemetry SDK
• Collector forwards to EU-hosted Elasticsearch, ClickHouse, or PostgreSQL
• Retention managed via time-series partitioning (drop old partitions)
• Erasure implemented as DELETE WHERE user_id = ? SQL query

GDPR advantage: You control the schema, the storage, and the deletion logic. An erasure request becomes a parameterized SQL DELETE — selective, auditable, and complete.

Deploy on sota.io: sota.io provides managed container deployments in Hetzner's EU data centers under German law. An OpenTelemetry Collector container paired with a ClickHouse or Elasticsearch container can replace CloudTrail's audit function entirely, with full erasure capability.

Loki (Grafana) — EU-Hosted Log Aggregation

Grafana Loki is a horizontally scalable log aggregation system optimized for structured log queries. Deployed on EU infrastructure, Loki provides:

• Label-based log querying (query by user ID, service, action type)
• Configurable per-stream retention (retain security audit logs for 2 years; retain access logs for 90 days)
• Log deletion API: Loki supports selective log deletion via the POST /loki/api/v1/delete endpoint, providing what CloudTrail cannot — targeted erasure of specific user's log entries by time range and label selector.

# Delete all logs for a specific user (GDPR Art.17 erasure)
curl -X POST "https://loki.internal/loki/api/v1/delete" \
  --data-urlencode 'query={user_id="eu-user-12345"}' \
  --data-urlencode 'start=2024-01-01T00:00:00Z' \
  --data-urlencode 'end=2026-12-31T23:59:59Z'

This is GDPR Art.17 compliance implemented as a single API call — impossible with CloudTrail.

Seq (Datalust) — Structured Log Server

Seq is a self-hosted structured log server with strong query and retention capabilities, commonly used in .NET ecosystems but language-agnostic via Serilog, NLog, or direct HTTP ingest. Deployed on EU infrastructure:

• Per-signal retention policies (audit events: 1 year; debug logs: 7 days)
• Selective event deletion via the API
• Role-based access control to audit log queries
• Alerting on security-relevant event patterns

OpenSearch / Elasticsearch — EU-Hosted Search and Analytics

For teams that need CloudTrail-equivalent "search across all events" capability without US jurisdiction:

• Deploy OpenSearch on Hetzner (EU) via sota.io or bare metal
• Ingest audit events from application code directly (no AWS intermediary)
• Use Index Lifecycle Management (ILM) to roll over and delete old indices
• Implement a delete_by_query operation for GDPR erasure requests

OpenSearch delete_by_query supports selective deletion:

POST /audit-events-*/_delete_by_query
{
  "query": {
    "bool": {
      "must": [
        { "term": { "user_id": "eu-user-12345" } }
      ]
    }
  }
}

This deletes only the target user's events, preserving all other audit records — exactly the granularity that GDPR Art.17 requires.

Comparison Table: CloudTrail vs EU Alternatives

The Meta-Problem: CloudTrail Audits AWS — Without AWS, You Audit Yourself

CloudTrail's architectural purpose is to audit AWS API calls. If you migrate away from AWS and run your workloads on EU-native infrastructure (Hetzner, OVH, Scaleway, or a managed PaaS like sota.io), you no longer need CloudTrail — because there are no AWS API calls to audit.

The audit logging need doesn't disappear. You still need to know who accessed which data, when, from where. But the audit logging system you build on EU infrastructure can be designed from the ground up for GDPR compliance:

• Schema design: Include a user_id field for every event. This makes erasure trivial: DELETE WHERE user_id = ?.
• No CloudTrail-style immutability: Don't use WORM storage for personal data audit logs. Use append-only for integrity, but with deletion capabilities for erasure.
• Pseudonymization: Hash user IP addresses in audit logs. Store the salt separately, allowing re-identification if needed for security investigations, but not by default.
• Data minimization (Art.5(1)(c)): Log only what you need. CloudTrail logs everything by default — often more than any security team actually reviews. Application-level audit logging can be scoped to security-relevant events only.

How sota.io Compares

sota.io is a managed application deployment platform built on Hetzner infrastructure in Germany and Finland, operated by a German company under German law. When you deploy on sota.io:

• No CloudTrail: Your application runs in containers on EU infrastructure. There are no AWS API calls to audit.
• Audit logs under your control: Application-level audit logging writes to databases or log stores you control in the same EU infrastructure.
• CLOUD Act inapplicable: sota.io is not a US entity. The CLOUD Act does not apply. EU GDPR, German BDSG, and the GDPR enforcement regime of the BSI (Bundesamt für Sicherheit in der Informationstechnik) apply.
• Art.17 implementable: When you build audit logging on sota.io's infrastructure, you choose the storage backend. Selective deletion is a SQL DELETE or Loki delete API call.

For EU startups and scale-ups where the entire compliance discussion centers on keeping data under EU jurisdiction, sota.io eliminates the CloudTrail problem by eliminating AWS from the stack.

Migration Path: From CloudTrail to EU Audit Logging

Step 1: Inventory CloudTrail personal data

• Identify which CloudTrail events contain personal data (IAM username = email? IP addresses in Data Events?)
• Determine current S3 retention and whether Object Lock is enabled
• Document the legal basis for current retention (Art.6 + Art.30 RoPA entry)

Step 2: Design EU replacement

• Choose storage: Loki, OpenSearch, PostgreSQL, or ClickHouse on EU infrastructure
• Define audit event schema with explicit user_id field for erasure targeting
• Implement erasure procedure and test it (annual dry-run recommended)

Step 3: Migrate workloads to EU-native infrastructure

• Move compute to Hetzner/OVH/Scaleway or managed PaaS (sota.io)
• Replace AWS services with EU equivalents (see the full sota.io EU Compliance Series)
• Disable CloudTrail Data Events on migrated workloads first; Management Events last

Step 4: Handle existing CloudTrail logs

• Decide: delete (if retention period allows), pseudonymize (if technically feasible), or document as a legacy system with a sunset date
• If Object Lock prevents deletion: document as a compliance exception with legal review
• Update Art.30 RoPA to reflect the transition

See Also

• AWS S3 EU Alternative — Where CloudTrail logs are stored
• AWS IAM EU Alternative — Identity data in CloudTrail events
• AWS CloudWatch EU Alternative — Where execution logs from CloudTrail go
• AWS Lambda EU Alternative — Lambda Data Events in CloudTrail
• AWS API Gateway EU Alternative — Access logs and execution logs feeding CloudTrail