●LL Cloud
$ cat gdpr-logging-eu-regions.md

GDPR-aware logging: keep your data in the EU.

· 5 min read · observability

Your application runs in eu-central-1. Your error tracker is in Oregon. The IP address that triggered the error is now personal data sitting on a server in Oregon. You may have just imported a sub-processor problem you didn't know you had.

Logging used to be a developer concern. Now it's a legal one. Logs almost always contain personal data — IPs, user IDs, sometimes email addresses or full request bodies — and under GDPR, where that data lives matters. For Greek and EU teams, the bar is simple: process and store personal data in the EU unless you have a documented reason not to.

The trap is that the default region for most popular observability tools is the US, and the dropdown to change it is buried.

The default region of every tool you'll touch

Tool                  Default region   EU region available?
─────────────────────────────────────────────────────────────────
Datadog               US               Yes — datadoghq.eu (Frankfurt)
Sentry                US (SaaS)        Yes — sentry.io EU instance
New Relic             US               Yes — eu.newrelic.com
LogRocket             US               Limited — EU on Enterprise tier
Grafana Cloud         US               Yes — multiple EU stacks
Honeycomb             US               EU launched 2023
Posthog Cloud         US               Yes — eu.posthog.com
AWS CloudWatch        Per-region       Yes — pin to eu-* regions
GCP Cloud Logging     Per-region       Yes — pin to europe-* regions

Three things to internalize:

  1. The default is not the right answer for you. Every SaaS in this list will sign you up to the US instance unless you go looking for the EU one.
  2. You usually can't migrate later. Datadog, Sentry, New Relic — all of them treat EU and US as separate accounts. You can't move historical data; you can only start fresh.
  3. "EU instance" doesn't always mean "EU only". Read the sub-processor list. Some vendors process metadata, billing, or support tickets in the US even when telemetry stays in the EU.

The minimum viable setup

For a typical Greek SaaS startup, this is the setup that doesn't make your DPO unhappy:

For each of these, document which sub-processors are involved and where they're located. That's a one-page artifact your DPO will love and your auditors will demand.

Strip personal data before it leaves the application

Even with EU-region storage, you should not be sending raw IPs, full request bodies, or email addresses to your observability stack unless you actually need them. Log enrichment middleware costs nothing and pays back the first time someone asks what data you have on a deleted user.

// Express example — drop or hash sensitive fields before logging
const redact = (req) => ({
  method: req.method,
  path: req.path,
  user_id: req.user?.id,
  ip_hash: hash(req.ip + process.env.IP_SALT),  // pseudonymise
  ua: req.get('user-agent'),
  // note: no email, no full IP, no body
});

logger.info(redact(req), 'request');

Salted hashes give you the ability to correlate events ("how many requests from this same client?") without storing the original IP. When the salt rotates monthly, you also get automatic forgetting.

Retention is part of compliance, not a cost optimization

GDPR doesn't set a specific retention limit, but Article 5(1)(e) requires data to be kept "no longer than is necessary". For most application logs, that's 30–90 days for hot storage, 6–12 months for cold. Anything beyond that needs a documented reason — security forensics, regulatory audit, fraud investigation.

# CloudWatch log group with sane retention
resource "aws_cloudwatch_log_group" "app" {
  name              = "/app/api"
  retention_in_days = 90
  kms_key_id        = aws_kms_key.logs.arn
}

Set retention at the log group, not in your collection pipeline. If someone deletes the pipeline config later, the data still expires.

The audit trail you'll wish you had

If you're ever subject to a Greek DPA inquiry or a customer DSAR (data subject access request), the question you'll be asked is: where, exactly, is the personal data of this person stored?

"In our logs" is not an answer. "In CloudWatch in eu-central-1, retained 90 days, encrypted with KMS key alias/app-logs, accessible to engineers in groups X and Y, no replication" is.

Build that document on day one. It's two pages. It's the cheapest insurance you'll ever buy.

The 30-second sanity check. Open every observability tool you use. Find the region/data-residency setting. Screenshot it. If anything says "United States" or "Global" — that's tomorrow's work.

Untangling an observability stack for GDPR is dull, important work. We do this for Greek and EU teams. Get in touch.