EU data residency: how to architect it without doubling your cloud bill

EU data residency: how to architect it without doubling your cloud bill

A client recently showed us a quote from their cloud provider: +73% annual cost increase to move the entire infrastructure to EU regions and satisfy data residency requirements. The problem wasn't the regulation. It was the architecture.

The core misconception

EU data residency does not mean "everything in Europe". It means that personal and sensitive data of EU citizens cannot be persistently processed or stored outside EU borders without adequate safeguards (Schrems II, GDPR Art. 44-49).

Most companies interpret this as: move every application component to EU. The result is a full stack duplication on EU regions, worse latency for non-EU users, doubled infrastructure costs, and no real competitive advantage.

What actually needs to be in the EU (and what doesn't)

The first step is rigorous data classification. Not all data is equal under GDPR.

| Category | Example | Residency constraint | |---|---|---| | Identifiable personal data | Name, email, tax ID | Yes, persistent EU storage | | Pseudonymised data | UUID, token | Depends on reversibility | | Aggregated/anonymised data | Aggregate analytics | No | | Technical metadata | Infra logs without PII | No | | Generic business data | Product SKUs, prices | No |

If your main database has a users table with PII and a products table with catalog data, you don't need to move the entire database to EU. You need to separate the two domains.

Concrete architectural patterns

1. Residency-based database sharding

The most direct pattern for multi-region applications is to isolate personal data storage in a dedicated EU cluster, keeping everything else on lower-cost, better-performing regions.

# Example: two connection strings in application config
databases:
  core_business:
    host: db-us-east-1.internal
    region: us-east-1
    contains_pii: false
  user_profiles:
    host: db-eu-west-1.internal
    region: eu-west-1
    contains_pii: true
    encryption_at_rest: AES-256
    backup_region: eu-central-1

The application always resolves user data against the EU cluster. Everything else runs on the most cost-effective region. The added complexity is real but bounded: a repository-pattern abstraction handles routing.

2. PII tokenisation in data pipelines

For analytics, ML or event pipelines (Kafka, Kinesis), PII should never enter the raw stream. Tokenise upstream, process tokens, keep real data in EU.

# Pseudocode: tokenise before sending to non-EU pipeline
def emit_event(user_id: str, event: dict) -> None:
    token = tokenizer.get_or_create(user_id)  # call to EU vault
    sanitized_event = {
        **event,
        "user_id": token,           # opaque token, not reversible without EU vault
        "email": None,              # PII explicitly removed
        "ip_address": mask_ip(event.get("ip_address")),  # pseudonymisation
    }
    kafka_producer.send("events", sanitized_event)  # any region

The tokenisation vault lives in EU. The rest of the pipeline can run anywhere.

3. CDN and edge: watch out for logs

Many teams overlook that CDN logs (Cloudflare, Fastly, CloudFront) contain user IPs, which are PII under GDPR. If these logs are written to S3 in us-east-1 without explicit configuration, you have a residency violation.

Fix: enable log forwarding to an EU bucket and set a short retention policy (7-30 days) for raw logs. Aggregated logs (metrics, percentiles) can go anywhere.

# Terraform: EU-resident S3 bucket for CDN logs
resource "aws_s3_bucket" "cdn_logs_eu" {
  bucket = "company-cdn-logs-eu"
  
  # Force EU region
  provider = aws.eu-west-1
}

resource "aws_s3_bucket_lifecycle_configuration" "cdn_logs_eu" {
  bucket = aws_s3_bucket.cdn_logs_eu.id
  rule {
    id     = "expire-raw-logs"
    status = "Enabled"
    expiration { days = 14 }
  }
}

How much can you actually save

Back to the client with the +73% quote: after data classification and applying the patterns above, the real delta was +18% over the original setup. Most of the workload kept running on lower-cost US regions. Only 15-20% of the data was actually PII and required EU storage.

The main additional costs, in order:

1. Cross-region data transfer: minimised with aggressive caching and designs that reduce EU↔US round-trips in the critical path.
2. Dual backup: only needed for EU clusters, not for the full stack.
3. Operational complexity: the hidden cost. Monitoring, runbooks, on-call must cover multiple regions. Address this with automation, not headcount.

Operational takeaways

1. Classify data before touching infrastructure. Without knowing what is and isn't PII, any architectural decision is guesswork.
2. Separate storage domains. A monolithic database mixing PII with business data is the most common — and most expensive — problem to fix after the fact.
3. Tokenise at system boundaries. Any data crossing a boundary (external API, pipeline, CDN) must be stripped of PII before leaving the EU perimeter.
4. This is a design problem, not a legal one. GDPR doesn't tell you how to build systems. It tells you what to protect. Architecture is a technical choice.

---

If you're planning an infrastructure review with data residency constraints, the Evviva Group team can support you through assessment and architectural design.