Region Pinning
Some data may not legally leave a jurisdiction — EU GDPR, Canadian PIPEDA, Australian IRAP, US-only contracts. Tetrapus pins each Org to a single region at provisioning time. Once locked, the gateway rejects any cross-region call to that Org with a 403 — the request never reaches the wrong data plane.
org_data_residency table
A single row per Org records the pin. locked_at exists to make it explicit that the binding is not a mutable preference — it is a fact about where the Org's data lives.
CREATE TABLE org_data_residency (
org_id UUID PRIMARY KEY REFERENCES orgs(id) ON DELETE CASCADE,
region_code TEXT NOT NULL, -- e.g. 'us-east-1', 'eu-central-1', 'ap-southeast-2'
locked_at TIMESTAMPTZ NOT NULL DEFAULT now()
); Gateway enforcement
Tetrapus runs one logical control plane and N regional data planes. The control-plane gateway holds the org_data_residency map in memory and uses it to route — and to reject — every authenticated request before it touches storage.
The check happens in two places for defence in depth:
- Gateway: JWT carries
org_id; gateway looks upregion_codeand rejects if it does not match the data plane the request landed on. - Data plane: Same lookup runs again before any DB query, so a mis-routed request from a faulty load balancer cannot leak data.
Region migration is manual
Documented constraint
Moving an Org between regions is not a live operation. There is no streaming dual-write; there is no online cutover. The supported procedure is:
- Quiesce the Org (set
control_orgs.status = 'suspended'). - Take a signed snapshot in the source region (see Backup Attestation).
- Restore-verify in the target region; confirm the manifest signature.
- Update
org_data_residency.region_code+ reassign incontrol_org_assignments. - Tear down the source-region copy.
- Resume (
status = 'active').
Expect a maintenance window proportional to dataset size. Customers with strict uptime SLAs should plan migrations during scheduled maintenance.
Region codes
Region codes are opaque strings — Tetrapus does not interpret them beyond exact-match comparison. They typically mirror the underlying cloud's region naming so operators can reason about them with their existing mental model.
| Common code | Coverage | Typical compliance fit |
|---|---|---|
| us-east-1 | United States (Virginia) | SOC 2, FedRAMP Mod, IL4 |
| us-gov-west-1 | US GovCloud | FedRAMP High, IL4 / IL5 path |
| eu-central-1 | EU (Frankfurt) | GDPR, BSI C5 |
| ap-southeast-2 | Australia (Sydney) | IRAP PROTECTED |
| ca-central-1 | Canada (Montreal) | PIPEDA, federal CCCS |
Pairing with CMEK
Customers who pin to a region almost always also want their CMEK key in the same region. Tetrapus does not enforce this — your KMS-region choice is yours — but the operator runbook flags it as a configuration warning if the regions diverge, since cross-region KMS calls add latency to every JWT mint.
Related
- – CMEK / BYOK — keep keys local to the data
- – Backup Attestation — required for region migration
- – Compliance Matrix — which regions cover which framework
- – Back to Enterprise
Questions?
Reach out for help with integration, deployment, or custom domain codecs.