Data-Residency-Konfiguration
Pinne Org-Daten beim Signup an US oder EU. Verifiziere Residency, verstehe Cross-Region-Read-Prevention, plane eine Migration bei sich ändernden Business-Anforderungen.
Moonborn ist an der Org-Grenze regionalisiert: US und EU. Die Region wird beim Signup gewählt und ist danach gelockt (ADR 0011). Alle persistenten Daten — Personas, Chat-Transcripts, Audit-Log, Embeddings, Billing-Records — bleiben in der gewählten Region.
Verifiziere deine Region
const org = await client.organizations.getCurrent();
console.log(org.region); // "us" | "eu"Die Region ist auch in Settings → Organization → Region sichtbar.
Cross-Region-Reads
Cross-Region-Reads sind an der Datenbank-Grenze geblockt — kein
Policy-Check, eine physische Isolation. Ein EU-Region-API-Key kann US-
Daten nicht lesen, selbst mit der richtigen RBAC; der Request gibt
403 cross_region_blocked zurück.
Das heißt:
- Deine EU-Nutzer teilen nie Infrastruktur mit US-Daten.
- Ein US-Admin kann nicht versehentlich EU-Records in sein Dashboard ziehen.
- Subprocessors in einer Region tragen keine Daten aus der anderen.
Compliance-Posture
| Anforderung | Region |
|---|---|
| GDPR (EU-Residency) | EU |
| US HIPAA BAA | US |
| Kunde in beiden? | Eine Org pro Region |
Migration
Regionswechsel wird in-flight nicht unterstützt. Um zu migrieren:
- Export aus aktueller Region:
await client.privacy.requestDsarExport({ orgId: oldOrg.id }); - Eine frische Org in der Zielregion anlegen.
- Den Export in die neue Org importieren:
await client.privacy.importExport({ archive }); - SSO-/SCIM-Endpoints auf die neue Org zeigen lassen.
- Die alte Org nach Verifikation decommissionieren.
ADR 0011 erklärt das Design: In-Flight-Migration würde komplexes Consistency-Reasoning über Regionen hinweg erfordern und das „Region ist eine Eigenschaft der Org"-Invariant brechen.
Tarif
US/EU-Wahl: jeder Tier (Default US). Region-Lock: für jeden Tier durchgesetzt. EU-Residency-vertragliche Garantien: Enterprise.