Ship an EU Data Region in 90 Days: A CTO Playbook After Fastmail’s Move

Your next enterprise deal will die on a single line: “Where does the data live?” Fastmail just announced an EU data region. They didn’t do it for fun; they did it because customers demanded it. If you sell to Europe and still run a single US region, you’re leaving money on the table and handing RFPs to competitors who can answer “Frankfurt.”

This post gives you a 90‑day playbook to stand up an EU data region without a ground‑up rewrite. It’s opinionated, testable, and designed for a scale‑up team with 8–20 backend engineers. You’ll separate control and data planes, pin tenants to regions, keep encryption keys regional, and prove (not promise) that PII never leaves the EU.

What “Data Residency” Actually Means (Pick Your Level)

Before you start provisioning, define residency scope. Your legal team will thank you, and your architecture won’t drift.

• Storage residency: Customer PII at rest stored only in the region (DB, object storage, backups).
• Processing residency: Compute that touches PII runs in‑region (APIs, jobs, support tooling).
• Access residency: Human access to PII is restricted to staff with approved regional context and auditable controls.
• Dependency residency: Subprocessors used with PII are region‑pinned and disclosed in your DPA.

Most customers asking for “EU data residency” mean at least storage and processing. Many will accept encrypted cross‑region backups if the encryption keys never leave the EU. A few require hard isolation (no cross‑region flows at all, even encrypted). Decide your target and write it down.

A Simple Data Classification That Won’t Collapse Under Load

• P0 (PII/core secrets): names, emails, phone numbers, physical addresses, government IDs, access tokens, raw content users upload.
• P1 (soft PII/business data): resource metadata, usage counters, workflow state that is not directly identifying but becomes sensitive when joined with P0.
• P2 (operational telemetry): logs, metrics, traces, billing aggregates, product analytics with P0 stripped or salted beyond reversal.

Policy: P0 and P1 never cross the region boundary. P2 may be exported as long as irreversible transformations happen before egress, in‑region.

Tenancy Strategy: Start Simple, Don’t Regret It Later

You have three options. Only one ships in 90 days without painting you into a corner.

• Org‑pinned tenancy (recommended): Each customer org selects a region at signup or during migration. All their P0/P1 lives and is processed in that region. Cleanest for B2B. Easy to reason about, audit, and sell.
• User‑pinned tenancy: Per‑user residency inside a global org. Sounds nice for “hybrid” teams, but fans out complexity to auth, collaboration, and reporting. Don’t start here.
• Object‑pinned tenancy: Each piece of content chooses a region. Great for consumer content networks; terrible for enterprise audit. Avoid unless your product is inherently global content distribution.

Pick org‑pinned and move on. You can add per‑user exceptions later if a whale customer forces it.

Control Plane vs Data Plane: The Only Boundary That Scales

Your current architecture probably smears both together. Untangle them:

• Global control plane: Tenant directory, plan/billing metadata, feature flags, routing table (org → region), and no P0. It orchestrates, it never stores PII.
• Regional data planes (EU, US, …): API frontends, databases, object storage, search, queues, batch jobs—everything that touches P0/P1. They don’t talk to each other except via well‑defined, audited channels for P2 exports or optional encrypted DR.

This is the pattern Fastmail and other mature SaaS providers converge on because it aligns incentives: auditors inspect data planes; the control plane remains simple and global.

The 90‑Day Build: A Concrete Blueprint

Day 0–15: Inventory, Policy, and Schema Hooks

• Inventory subprocessors: List every vendor that sees PII today (email, support, analytics, APM, error tracking). Color‑code by EU capability.
• Pick your EU region: AWS eu‑central‑1 (Frankfurt) or eu‑west‑1 (Ireland) are common. Latency ~20–40ms from major EU hubs. Don’t overthink it.
• Add region to tenancy schema: Org table gets region_code (e.g., EU, US). Enforce foreign keys from all P0/P1 tables back to org. If you’re multi‑tenant, add CHECK (region_code = current_setting('app.region')) style constraints per schema or use Row Level Security (RLS) bound to app.region. Make it impossible to write cross‑region by accident.
• Decide DR posture now: Option A (strict): no cross‑region copies at all; accept regional DR only. Option B (balanced): replicate encrypted backups across regions with keys that never leave the source region. Write this into your DPA and your runbooks.

Day 16–35: Stand Up the EU Stack (Parity, Not Perfection)

• Database: Separate Postgres or MySQL cluster in EU. No logical replication from US. Same schemas, same extensions. Target p95 API read latencies ≤50ms inside region.
• Object storage: Regional buckets (S3 eu‑central‑1/eu‑west‑1, GCS europe‑west). Use Object Lock and lifecycle rules. Don’t replicate raw objects out of region unless DR policy allows and keys remain EU‑bound.
• KMS/keys: Per‑region KMS keys. Do not export keys. If you do encrypted cross‑region DR, use multi‑copy of ciphertext with non‑exportable keys bound to EU. Key rotation SLA: 90 days; emergency rotation: 24 hours.
• Queues/jobs: Regional SQS/PubSub and workers. No global queues for P0/P1 work. Tag jobs with org_id and assert region on consume.
• Search: Run a regional index (OpenSearch/Elasticsearch) fed from EU DB. No global search for EU tenants. If you must unify, do it with P2 summaries.
• Feature flags: Either choose a vendor with EU data residency or self‑host a simple flags service (OpenFeature + Redis) per region. Flags are P1 at worst; keep them where tenants live.

Day 36–60: Traffic, Identity, and Observability That Don’t Leak

• Routing: Explicit region subdomains: eu.yourapp.com and us.yourapp.com. At login, resolve org → region in the control plane and 302 to the right subdomain. Avoid GeoIP. Make it deterministic and auditable.
• Auth/SSO: Tokens minted and verified in‑region. Keys (JWKS) hosted per region. The control plane can federate identity without seeing P0 if you only store org‑scoped issuer and user IDs that are opaque to the control plane.
• Logs/metrics/traces: Ingest and store in‑region. Strip P0 at source. For exports to a global SIEM, pre‑hash emails (salted per region) and redact paths/queries with P0. Set up egress tests that fail builds if a new log field contains P0.
• Analytics: Run an in‑region warehouse (BigQuery EU dataset, Snowflake EU, or ClickHouse EU) fed by PII‑strip jobs. Export only aggregated P2 with k‑anonymity thresholds (e.g., suppress cohorts with n<10). No raw event export to global endpoints.
• Email/SMS: Use EU‑capable endpoints (SES eu‑west‑1, EU‑based providers). Ensure templates are rendered in‑region and only P2 leaves (delivery status). Update your subprocessor list.

Day 61–90: Migration, DR, and Proof

• Tenant enrollment: New EU prospects default to EU region. Migrations for existing EU customers are batched: export from US encrypted, import into EU, cutover DNS/app routing, then hard‑delete old P0 after customer sign‑off. Typical medium org (10–50 GB P0/P1) can be moved in a weekend maintenance window.
• DR and backups: Prove your declared posture. If strict, run regional backup/restore drills quarterly in EU. If balanced, replicate encrypted snapshots to a secondary EU region (not US) and test keys never leaving EU vaults. Document RPO/RTO targets (e.g., RPO≤15 min, RTO≤2 h).
• Support access: JIT access with approval. EU tenants trigger EU‑only support pools by default. Session recording tools run in‑region; scrub P0. All access is logged to the EU SIEM. Break‑glass needs VP approval and is auto‑reported to the customer within 24 hours.
• Verification: Build canary PII (e.g., emails like eu‑leak‑probe+GUID@yourapp.test) in staging and prod. Honeytokens alert if they show up in any non‑EU system. Add eBPF/VPC Flow Log alerts for unexpected egress to non‑EU IP ranges from EU VPCs.

Costs and Headcount: What This Really Takes

• Infra multiplier: Expect a 25–40% increase in infra spend to run a second region at parity (DB, object storage, search, queues, observability). You can keep shared global control plane minimal.
• People: 2–3 FTE months of senior backend time to get to first EU tenants, plus 0.5 FTE ongoing SRE/Platform to keep parity. If you have a strong platform team, you can compress the initial timeline.
• Performance: EU tenants will see 100–200 ms end‑to‑end latency improvements vs hitting US. Your US tenants won’t notice EU standing up if you isolate paths correctly.

In exchange, your sales team can stop dodging questionnaires about Schrems II and your procurement cycles will shorten. In our experience, residency unlocks enterprise pilots worth 6–7 figures with CAC payback in a single year.

Common Failure Modes (And How to Preempt Them)

• “Global” cron jobs: Batch jobs that iterate all orgs will accidentally cross regions. Fix by sharding schedulers per region and driving batch by regional queues.
• Shared Redis: Do not point EU workers at a US Redis because “it’s just a cache.” Caches leak P0 and become state. Run regional Redis/Valkey and set TTLs aggressively.
• Admin backdoors: Internal admin UIs that read across regions “for convenience” are discovery engines for auditors. Make admins pick region scope explicitly and enforce it at the query layer.
• Logging everything: If your logs contain raw emails or request bodies, you don’t have data residency—you have data leakage. Fix logging hygiene before you scale EU traffic.
• Third‑party sprawl: Your security vendor’s browser plugin, your QA tool’s screenshot uploader, your marketing pixel—these are subprocessors. Inventory and fence them.

How to Talk About This in Security Reviews

Auditors don’t want poetry; they want architecture and evidence. Put this into a 2‑page appendix you can share under NDA:

• One diagram: Control plane (global, no P0) and two data planes (EU, US) with arrows showing only P2 egress.
• One table: For each system (DB, object storage, search, logs, analytics, email, support), list region, workloads, and whether P0/P1/P2 is processed or stored.
• One policy: P0/P1 never leaves region. P2 egress only after irreversible transforms. Keys are regional and non‑exportable.
• One test: Canary PII and egress monitoring that runs daily with alerts to security@.
• One SLA: RPO/RTO by region and DR posture (strict or balanced) and the cadence of restore drills.

Do You Really Need This Now?

If either of these is true, yes:

• You’ve lost ≥1 enterprise deal in the last two quarters over residency.
• ≥10% of your pipeline contains EU prospects who asked where data lives.

If neither is true, build the hooks anyway: add region_code to orgs, fence P0 in your logs, stop using global queues, and separate control/data plane concerns. Those changes make you better even if you never open Frankfurt.

Why a Nearshore Pod Helps

This work is cross‑cutting: DB schema, job systems, observability, security, and legal. It competes with product roadmaps. A focused nearshore pod—6–8 hours of overlap with your US core team—can run the blueprint without thrashing your feature teams. The fastest rollouts we’ve seen pair a platform lead stateside with a Brazilian backend/SRE squad delivering the regional clones, KMS policy, and verification tests in parallel.

What Fastmail’s Move Signals

Email is the hardest class of PII—identity, content, and continuous processing. If a mail provider can offer an EU data region with clean boundaries, your B2B workflow tool, analytics platform, or collaboration app has no excuse. Customers now treat residency like SSO: a checkbox they expect to see. You can either build it now on your terms or build it later in a panic after losing a logo you wanted on your homepage.

Key Takeaways

• Define residency scope early: storage, processing, access, and dependencies. Write it down.
• Adopt org‑pinned tenancy and a global control plane with regional data planes. Keep P0/P1 regional, always.
• Use per‑region KMS keys, regional DB/storage/search/queues, and explicit region subdomains for routing.
• Make telemetry safe: strip P0 in‑region, export only P2 aggregates with k‑anonymity.
• Choose a DR posture you can prove. Test restores quarterly, document RPO/RTO, and keep keys regional.
• Budget a 25–40% infra uplift and 2–3 FTE months to reach first EU tenants. Sales upside often pays back in a year.
• Build verification: canary PII, egress monitors, and admin scoping. Evidence beats promises in audits.