AWS CloudWatch EU Alternative 2026: Logs, Metrics, and the GDPR Problem

Post #687 in the sota.io EU Compliance Series

AWS CloudWatch is the default observability platform for applications running on AWS. Application logs flow into CloudWatch Logs. Infrastructure metrics — CPU, memory, network, database connections — are published to CloudWatch Metrics. Alarms notify on-call engineers. Dashboards display system health. For teams building on AWS, CloudWatch is the operational backbone.

Amazon operates CloudWatch in European regions: eu-west-1 (Ireland), eu-central-1 (Frankfurt), eu-west-3 (Paris). Log data written to a CloudWatch Log Group in Frankfurt stays in Frankfurt infrastructure. Many development teams treat this as a compliant configuration.

It is not. 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. A valid government order served on Amazon in Seattle can reach your CloudWatch log data in Frankfurt — your application logs, your traces, your custom metrics, and the PII embedded in all of them.

This is the same structural US jurisdiction problem documented across the AWS stack: AWS RDS, AWS S3, AWS Lambda, AWS SES. CloudWatch adds a particularly acute dimension: observability data is specifically designed to capture detailed application behavior — and application behavior routinely involves processing personal data.

What AWS CloudWatch Stores About Your Application and Users

CloudWatch is not a simple metric counter. It stores rich operational data across logs, metrics, traces, and alarms — and much of that data directly involves or can be correlated with personal data about your users.

CloudWatch Logs: Full Application Log Content

CloudWatch Logs stores the complete text output of your application logs. Log groups collect log streams from Lambda functions, EC2 instances, ECS containers, EKS pods, API Gateway requests, VPC flow logs, Route 53 query logs, and any application that writes to the CloudWatch Logs API.

Application logs routinely contain personal data:

• User IDs, email addresses, and account identifiers in request logs
• IP addresses of connecting clients (personal data under GDPR Art.4(1) when linked to identifiable individuals)
• Authentication events (login attempts, password resets, session creation/destruction)
• API request parameters that include names, addresses, or account details
• Error messages that capture input data for debugging (which may include form field content)
• Database query logs with customer identifiers in query parameters

The scope of PII in application logs varies by development practice, but in production applications processing user data, log output without PII is the exception rather than the rule. Every log line written to CloudWatch Logs is stored by a US entity and is accessible under CLOUD Act compulsion.

The Log Group Retention Problem: Default Is Never Expire

CloudWatch Log Groups have a retention setting that determines how long log data is kept before automatic deletion. The default retention setting is Never Expire — logs are kept indefinitely unless you explicitly configure a retention period.

This default directly conflicts with GDPR Art.5(1)(e), the storage limitation principle: personal data must be kept in a form that permits identification of data subjects for no longer than necessary for the purposes for which the data are processed.

An application that logs user IDs, IP addresses, or any other personal data to CloudWatch with the default retention setting is storing personal data indefinitely under US jurisdiction. Many teams are unaware of this default — they configure CloudWatch Logs for operational reasons and never revisit retention settings.

Even teams that do configure retention periods are storing personal data in CloudWatch Logs during that retention window. The CLOUD Act reach applies throughout the retention period, not just to data stored indefinitely.

CloudWatch Logs Insights: Query Language Traverses PII

CloudWatch Logs Insights is a query language for searching and analyzing log data. Teams use it for operational troubleshooting: finding errors, analyzing request patterns, correlating events across services.

Logs Insights queries can extract structured data from unstructured log text — parsing fields, filtering on values, aggregating counts. This capability is precisely what makes Logs Insights powerful for debugging, and precisely what makes it a GDPR concern: it enables structured querying over log content that contains PII.

A support engineer investigating a user complaint might run a Logs Insights query that filters on a specific user ID, email address, or account number to retrieve all log events related to that user. The query results — a structured view of all log activity associated with an identifiable individual — are generated and displayed by CloudWatch infrastructure under US entity control.

The query capability itself — the ability to extract and view personal data from logs — is a data processing operation subject to GDPR. CloudWatch Logs Insights performs this processing within AWS (US entity) infrastructure.

CloudWatch Metrics: Custom Dimensions Encode Business Data

CloudWatch Metrics has two categories: AWS service metrics (CPU, network, disk — relatively low PII risk) and custom metrics published by your application.

Custom metrics can include dimension values that encode business context. Dimension values are string identifiers attached to metric data points to enable filtering and aggregation. Common patterns include:

• CustomerID=eu-customer-12345 (dimension identifying which customer generated the metric)
• Environment=production&Region=eu-central-1&UserTier=enterprise (business segmentation dimensions)
• TenantID=tenant_abc123 (multi-tenant SaaS identifier)

Dimension values that identify specific customers, tenants, or user segments may constitute personal data when they can be linked to natural persons. Custom metric dimensions are stored as part of the metric data point and retained in CloudWatch for the metric retention period (typically 15 months for standard resolution metrics).

Custom metric data, including potentially identifying dimension values, is stored by AWS (US entity) and accessible under CLOUD Act compulsion.

CloudWatch Metric Filters: Regex Parsing of Log Content for PII

CloudWatch Metric Filters extract numeric metrics from log content using pattern matching. A metric filter watches a log group, applies a filter pattern (a regex or simple pattern match), and publishes a count or extracted value to CloudWatch Metrics when the pattern matches.

Common metric filter use cases include counting HTTP error codes, measuring request durations, or alerting on specific error messages. The filter pattern runs against the full text of each log line.

Metric filters configured to extract values from log content that includes PII (counting failed logins per user ID, measuring response times per customer tier) process that personal data within CloudWatch infrastructure. The metric filter evaluation — the parsing of log content against the filter pattern — occurs in AWS (US entity) systems.

Application Insights, Container Insights, Lambda Insights: APM Under US Jurisdiction

CloudWatch Application Insights provides automated monitoring for .NET, Java, and other application frameworks. It collects application performance data, automatically discovers application components, and synthesizes operational recommendations.

CloudWatch Container Insights collects metrics and logs from Amazon ECS and Amazon EKS clusters. It captures:

• Container CPU and memory usage
• Pod-level metrics (EKS)
• Container log output
• Network metrics between services

CloudWatch Lambda Insights provides enhanced monitoring for Lambda functions:

• Cold start latency and duration per invocation
• Memory usage and reported duration per invocation
• Error counts and throttles

These enhanced insights products collect application execution data at the invocation level — meaning they can capture per-request performance data that may correlate with individual user activity. A Lambda function invoked in response to a user action generates a Lambda Insights data point tied to that invocation. The invocation context may link back to an identifiable user through request IDs, trace IDs, or correlation identifiers.

All Application Insights, Container Insights, and Lambda Insights data is stored and processed by AWS (US entity) infrastructure.

AWS X-Ray: Distributed Traces Capture Request Paths

AWS X-Ray is the distributed tracing service integrated with CloudWatch. X-Ray instruments application code to capture trace data showing how requests flow through services: which Lambda functions were called, which DynamoDB tables were queried, which external HTTP calls were made, and how long each segment took.

X-Ray trace data includes:

• The full request path through your service architecture (service map)
• Timing data for each service segment and subsegment
• Annotations and metadata added by your application code (which may include user identifiers or request parameters)
• Error details for failed requests (which may include exception messages with user data)
• HTTP request URLs and response codes for each service call

Teams routinely annotate X-Ray traces with correlation identifiers — user IDs, session IDs, request context — to enable investigation of specific user-reported issues. A trace annotated with a user ID is personal data under GDPR.

X-Ray traces are stored in the AWS X-Ray service, operated by Amazon Web Services, Inc. (US entity), accessible under CLOUD Act compulsion. Trace data is retained for 30 days by default with no option for longer retention (it auto-deletes), but the 30-day window during which personal-data-containing traces are stored under US jurisdiction remains.

CloudWatch Events and Amazon EventBridge: PII in Event Payloads

CloudWatch Events (now Amazon EventBridge) is AWS's event routing service. Events from AWS services and custom applications flow through EventBridge, which routes them to configured targets (Lambda functions, SQS queues, API Gateway endpoints, etc.).

Event payloads routinely contain business context data. A user account creation event might include the user's email address and account tier. An order fulfillment event might include customer name and shipping address. A payment processing event might include transaction amounts and customer identifiers.

EventBridge archives can store event payloads for replay — a feature that stores a history of events for later processing. EventBridge archives with PII-containing event payloads are personal data stores operated by AWS (US entity), accessible under CLOUD Act compulsion.

GDPR Articles Directly Implicated

Art.44-49 (International Transfers): CloudWatch involves a US entity with the ability to disclose data to US authorities. Standard Contractual Clauses (SCCs) are invalidated by the Schrems II ruling (CJEU C-311/18) when the service provider is subject to surveillance laws that override contractual obligations. The CLOUD Act provides exactly such override authority.

Art.5(1)(e) (Storage Limitation): CloudWatch Log Groups default to Never Expire retention. Applications that write PII to CloudWatch Logs without configuring a retention period are storing personal data indefinitely under US jurisdiction, incompatible with the storage limitation principle.

Art.25 (Data Protection by Design and by Default): GDPR Art.25 requires that systems be designed with data protection as a default. A monitoring system whose default behavior is indefinite log retention under US jurisdiction fails this standard. Compliance requires active override of defaults.

Art.32 (Security): Technical and organizational measures must protect personal data against unauthorized access. Storing application logs containing PII in a system where a US government order can compel access does not constitute adequate security measures for GDPR purposes.

Art.28 (Processors): AWS is a data processor for personal data processed via CloudWatch. A data processing agreement (DPA) with Amazon cannot protect against CLOUD Act compulsion — the CLOUD Act explicitly enables orders that override contractual obligations between AWS and its customers.

Art.5(1)(c) (Data Minimization): If application logs routinely capture PII that is not necessary for the logging purpose, this violates the data minimization principle. CloudWatch does not prevent or warn about PII in log content — it stores whatever your application writes.

EU-Native Observability Alternatives

Grafana LGTM Stack — Self-Hosted EU Infrastructure

The Grafana LGTM stack (Loki for logs, Mimir for metrics, Tempo for traces, Grafana for visualization) is the open-source alternative that most closely mirrors the CloudWatch feature set. Deployed on EU infrastructure under your control, it eliminates the US jurisdiction problem entirely.

Grafana Loki is a horizontally scalable log aggregation system designed for cost-efficient storage of application logs. Unlike CloudWatch Logs, Loki indexes only log labels (not full text), making it cheaper to operate. Logs Insights queries equivalent to CloudWatch Logs Insights are executed by your Loki instance, not by AWS.

Grafana Mimir is a horizontally scalable, highly available Prometheus metrics backend. Custom metrics, infrastructure metrics, and alerting rules run on your infrastructure. Metrics are not accessible to any US entity.

Grafana Tempo is a distributed tracing backend compatible with OpenTelemetry, Jaeger, and Zipkin. Traces are stored on your infrastructure, with the same 30-day or configurable retention you need — without US jurisdiction.

Grafana provides the unified visualization layer across all three data sources, replacing CloudWatch Dashboards.

Deploying the full LGTM stack requires Kubernetes or Docker infrastructure and dedicated DevOps capacity. Managed hosting options are available from Grafana Labs, headquartered in the US, but with EU-region hosting options. If using managed Grafana Cloud with EU hosting, verify that the Grafana Labs legal entity operating the EU service is not subject to US jurisdiction for your specific deployment.

VictoriaMetrics — Vienna, Austria (EU)

VictoriaMetrics is an open-source time series database and monitoring solution developed by a Vienna-based company. It provides high-performance storage and querying for Prometheus-compatible metrics with lower resource requirements than Prometheus itself.

VictoriaMetrics Cloud offers managed hosting with EU-region infrastructure (Vienna) under Austrian/EU legal jurisdiction. As an EU entity, VictoriaMetrics is not subject to the CLOUD Act.

VictoriaMetrics covers the metrics and alerting layer (replacing CloudWatch Metrics and CloudWatch Alarms). For logs, it integrates with Grafana Loki or its own VictoriaLogs component. For traces, OpenTelemetry-compatible backends.

Elastic Cloud — EU-Region Deployment

Elastic (the company behind Elasticsearch, Kibana, and the Elastic Observability platform) offers Elastic Cloud with EU region options including Frankfurt (GCP eu-west-3) and other European data centers. Elastic Cloud on AWS European regions still involves an AWS entity as the infrastructure provider; Elastic Cloud on Google Cloud Frankfurt involves a Google entity.

For maximum EU sovereignty, Elastic's self-managed deployment (Elasticsearch + Kibana + Elastic APM Server) on your own EU infrastructure eliminates third-party US entity involvement. Elastic's Observability solution covers:

• Log ingestion and search (Elastic equivalent of CloudWatch Logs and Logs Insights)
• Infrastructure metrics (Elastic equivalent of CloudWatch Metrics)
• APM and distributed tracing (Elastic equivalent of X-Ray)
• Alerting and dashboards (Elastic equivalent of CloudWatch Alarms and Dashboards)

The Elastic stack is operationally complex but feature-complete as a CloudWatch replacement.

OpenTelemetry with EU-Native Backends

OpenTelemetry is the CNCF standard for instrumentation — vendor-neutral APIs and SDKs for generating traces, metrics, and logs from application code. CloudWatch does not support OpenTelemetry natively (AWS uses X-Ray SDK for tracing and CloudWatch Logs API for logs).

Migrating from CloudWatch to any EU-native observability solution is substantially easier if you first instrument your application with OpenTelemetry. OpenTelemetry exporters can target any backend: Grafana Tempo, Jaeger, Zipkin for traces; Prometheus, VictoriaMetrics for metrics; Loki, Elasticsearch for logs.

EU-native managed OpenTelemetry backends:

• Grafana Cloud EU region (Grafana Labs, check legal entity for EU hosting)
• New Relic EU data center (US company, EU data residency — verify CLOUD Act exposure)
• Honeycomb (US company — same CLOUD Act structural problem as CloudWatch)

For genuine EU sovereignty, self-hosted OpenTelemetry collectors forwarding to self-hosted EU backends (Loki + Mimir + Tempo) is the most defensible architecture.

Migration Path from CloudWatch

Step 1: Audit Your Current CloudWatch Usage

Before migrating, inventory what you are actually using:

• Log Groups: Which applications write to CloudWatch Logs? What retention periods are configured? What PII appears in log content?
• Custom Metrics: Which services publish custom metrics? What dimension values are used?
• Alarms: What thresholds and actions are configured?
• Dashboards: What do teams monitor daily?
• Insights Queries: Which saved queries are in active use?

This audit determines migration scope and helps prioritize high-PII-risk components.

Step 2: Instrument with OpenTelemetry

The lowest-friction path to any EU-native backend is OpenTelemetry instrumentation. Replace AWS X-Ray SDK calls with OpenTelemetry SDK calls. Replace CloudWatch Metrics API calls with Prometheus/OpenTelemetry metrics SDK calls. Application log output (stdout/stderr) can be routed to any backend via OpenTelemetry log pipeline.

OpenTelemetry instrumentation is a one-time code change that makes your application backend-agnostic.

Step 3: Deploy EU-Native Backends

For a minimum viable migration:

• Deploy Grafana Loki for logs (or Elasticsearch)
• Deploy Prometheus + Grafana Mimir for metrics
• Deploy Grafana Tempo for traces
• Deploy Grafana for visualization

Configure your OpenTelemetry Collector to forward telemetry to these backends instead of CloudWatch and X-Ray.

Step 4: Configure Retention Policies Explicitly

Whatever EU-native backend you deploy, configure explicit retention policies from the start. Do not accept defaults. Define retention periods for:

• Application logs (typically 30-90 days for operational use)
• Audit logs (potentially longer, but with explicit legal basis)
• Traces (typically 7-30 days)
• Metrics (typically 1-13 months depending on resolution)

Document the legal basis and purpose for each retention period in your GDPR records of processing activities (Art.30).

Step 5: Update Your DPA

Terminate the AWS DPA for CloudWatch and execute a new DPA with your EU-native provider. If self-hosting, your own organization is the controller and processor for the observability data — document this in your Art.30 records.

Comparison Table

The Log Retention Default Is the Most Immediate GDPR Risk

Of all the CloudWatch GDPR compliance issues, the Never Expire default log retention is the most immediately actionable. It is easy to audit (check the CloudWatch Console → Log Groups → Retention settings), and the fix — setting an appropriate retention period — takes minutes per log group.

If your application logs contain any personal data (user IDs, email addresses, IP addresses, request parameters), and your CloudWatch Log Groups have Never Expire retention, you are storing personal data indefinitely under US jurisdiction. This violates GDPR Art.5(1)(e) regardless of any other compliance measures you have taken.

Immediate action: Audit every CloudWatch Log Group in your AWS accounts. Identify groups with Never Expire retention. Set a retention period appropriate to your data retention policy (typically 30-90 days for operational logs). Do this even if you are not ready to migrate to an EU-native backend — it reduces your GDPR exposure immediately.

Practical Steps for European Companies

1. Audit log retention settings: Every CloudWatch Log Group should have an explicit retention period, not Never Expire.
2. Inventory PII in logs: Review what your applications write to CloudWatch Logs — are user IDs, email addresses, or IP addresses logged?
3. Evaluate X-Ray trace annotations: Do your traces include user identifiers or other personal data in annotations?
4. Adopt OpenTelemetry instrumentation: Decouple your observability data from CloudWatch/X-Ray APIs before migrating.
5. Choose your EU-native backend: Grafana LGTM stack for self-hosted control; VictoriaMetrics Cloud for managed EU metrics.
6. Update your DPA and Art.30 records: Document the new controller-processor relationships for observability data.

Related posts in this series:

• AWS RDS EU Alternative: The Managed Database GDPR Problem
• AWS S3 EU Alternative: Object Storage and the CLOUD Act
• AWS DynamoDB EU Alternative: NoSQL Under US Jurisdiction
• AWS Lambda EU Alternative: Serverless and the Execution Environment Problem
• AWS ElastiCache EU Alternative: In-Memory Data and GDPR
• AWS SES EU Alternative: Email Sending, Bounce Data, and the GDPR Problem