Four patterns cover most residency designs: a single stack with region pinned data stores, a regional data plane with a global control plane, fully separate regional stacks, and a customer hosted option. The more isolation you need, the more engineering and operating cost you carry.
Pattern 1: one stack, regional storage
Your application runs in one place and the customer database or object store for each tenant is in the chosen region.
- Good for: early stage products, mild customer requests.
- Weakness: compute, logs and caches still sit in the home region. Personal data passes through them.
Pattern 2: regional data plane, global control plane
Each region runs the services that touch customer data. A global control plane handles accounts, billing and configuration, and holds no customer content.
- Good for: most B2B SaaS with EU customers.
- Weakness: you must define what is customer content versus control data, and keep personal data out of the control plane. Admin user emails often leak into it.
Pattern 3: fully separate regional stacks
Each region is an independent deployment with its own identity, data, logs and operations staff access.
- Good for: strict contracts, regulated sectors, localisation rules.
- Weakness: cost, release coordination, and cross region features such as global search or shared analytics.
Pattern 4: customer hosted or runner based
Customer data is processed inside the customer's own environment, and the vendor sees only results.
- Good for: customers that cannot move data at all.
- Weakness: support burden and version drift.
How to choose
- What does the contract or law require: storage only, processing, staff access?
- How many customers need it? One large account may justify pattern 3 on its own.
- Which data must be in region: content, metadata, logs, backups?
- Who needs support access, and from where? Remote access from outside the region may still be a transfer. See remote support access.
- What can you operate? Two stacks you cannot patch on time are worse than one.
Design rules that apply to all four
- Tenant to region mapping is explicit and immutable without a migration process.
- Region is part of every resource name and every log line.
- No default regions in infrastructure code.
- Backups follow the same rule as primary data.
- Tests verify that a request for an EU tenant never touches another region.
Migration between patterns
Most companies start at pattern 1 and move to pattern 2. The hardest part is cleaning the control plane of customer content. Do it early by classifying every field in your global services as control data or customer content, and by blocking customer content in global services with automated checks.
Cost to expect
Each added region multiplies work: deployments, monitoring, on call knowledge, incident response and compliance evidence. Price that before you promise a new region, and decide how many regions you will support in total.
Things that cross regions
Identity is the common trap. A single global login service is convenient but stores user emails, which are personal data. Decide whether identity is regional or global, and document which user attributes the global part can hold.
Quick check
Is pattern 2 enough for EU customers?
Often, if the control plane holds no customer content and you can prove it. Check each contract.
Last reviewed: 19 October 2026.
