apointoo.
Request access
HIPAA

Why a Tenant Home Region Should Become Immutable

cmsapointoo··7 min read

A tenant home region should be assigned by an authorized server workflow before the first protected write and then treated as immutable. Browser location, a query parameter, or a mutable preference cannot decide where protected records, backups, logs, keys, and queues are stored. Immutability turns regional placement into a control that can be tested.

The goal is not to claim that a region alone solves compliance. The goal is to prevent silent drift. A tenant may later move through an approved export and import project, but an ordinary request must not change its home region while routing a user.

Isolation model and threat boundary

Use a control-plane record containing an opaque tenant identifier, home region, deployment state, and billing reference. Resolve an authenticated user’s membership against that record. Route the request to the home-region service. The service then resolves data access using server-owned tenant context.

Google Cloud’s Cloud Run Locations documentation describes regional availability and location choices. Its availability list is not a legal or compliance guarantee. A selected region is useful only when the application, storage, logs, backups, queues, secrets, and support process follow the same location policy.

Firestore’s Firestore Locations documentation makes location an architecture choice. A database location cannot be treated as a per-request routing flag. If a tenant is assigned incorrectly, fixing it may require export, import, verification, and deletion rather than changing one field.

For a broader isolation comparison, see pooled versus silo tenant isolation. For database-specific controls, see shared table versus database per tenant.

Enforcement path and bypasses

Assign the home region through an authorized onboarding operation. Require an immutable field or a tightly controlled state transition. Reject attempts to alter it through ordinary tenant settings. Treat a support request to change the region as a migration request with approval, not as a profile update.

Layer Control Failure to test
Onboarding Server assigns approved region Client posts a preferred region
Routing Membership resolves home region Host or query string overrides routing
Data Regional store matches home region Fallback store accepts a cross-region write
Operations Logs, queues, keys, and backups match zone Global service creates a hidden copy
Migration Explicit export and import workflow Mutable flag changes location without cleanup

Google Cloud’s Define Resource Locations with Organization Policy documentation provides a control for restricting resource creation. Organization policy helps prevent accidental placement, but it does not replace application authorization or deletion proof. Record which projects, services, and identities are covered.

Regional architecture that stays aligned

Control plane
  opaque tenant ID + immutable home region
             |
             v
  regional hostname selected by server
             |
  +----------+----------+
  |                     |
  v                     v
home-region service   home-region recovery
database and files    backups, logs, keys, queues

Do not put appointment, service, contact, or conversion records in a global control plane merely to make routing convenient. If a global service must hold metadata, limit it to what is needed for routing, account state, and billing. Document any external provider access as part of the data-flow review.

Use region-specific credentials and secrets where the platform supports them. Review DNS, build artifacts, monitoring, support tools, incident copies, and restore destinations. A database in one region does not prove that a support export or log sink stays there.

Audit, restore, support, and offboarding

Audit onboarding, routing decisions, denied region changes, migrations, restores, support access, and deletion. Store the tenant identifier and region, not record content. A reviewer should be able to answer which actor made the decision, when it happened, what policy applied, and where the evidence is stored.

Restore inside the approved geography. Verify that the restored service still resolves tenant membership and cannot use a global fallback. Remove the temporary copy after the test, and retain the test result separately from the restored records.

Support access from another country may create a transfer or contract issue even when storage remains in the home region. Route support through approved identities, time-limited sessions, and an audited ticket. Offboarding should handle regional exports, working copies, backups, logs, and keys in one inventory.

See regional backup and restore testing for a detailed test sequence. See tenant return and destruction proof for exit behavior.

Runnable proof tests

Create synthetic tenants in at least two approved regions. Run these checks before accepting the architecture.

onboard tenant:
  ignore browser region
  assign approved home region on the server
  assert the region cannot change through tenant settings

request from each tenant:
  alter host, query, header, and payload region values
  assert routing uses the stored home region
  assert writes outside that region fail closed

restore and support:
  restore into an approved regional destination
  open a time-limited support session
  assert audit records contain actor, tenant, region, action, and result
  assert temporary copies are removed after review

Stop if a browser value selects a destination, a failed regional service silently writes to another zone, or a migration has no deletion and reconciliation evidence. Fix the control before adding tenants.

Onboarding and change control

Make onboarding a server-side state transition. The workflow should verify the tenant, contract scope, approved geography, available services, and operator authority before creating the home-region record. Write the decision once, emit an audit event, and block ordinary updates to that field.

When a region must change, create a migration record with source and destination, purpose, approval, export scope, reconciliation method, backup plan, and deletion steps. Treat the old region as active until the new copy passes validation and approved cleanup is complete. Do not use a feature flag as a substitute for this record.

Review failure handling. If a regional service is unavailable, fail closed or route to a documented recovery destination. Do not write to a global fallback because the request is inconvenient to reject. A fallback is safe only when its geography, access, keys, logs, and deletion behavior are approved.

Evidence reviewers should request

  • Tenant onboarding event and immutable region record.
  • Resource-location policy and list of covered projects.
  • Routing test with altered browser and header values.
  • Backup and restore result inside the approved geography.
  • Support access and cross-border review.
  • Migration or offboarding reconciliation and cleanup evidence.

Frequently asked questions

Why not let the browser choose the region?

The browser is an untrusted input. It can be altered, and it does not prove membership, contract, or approved data location. The server should select the home region after authenticating the request and resolving tenant membership.

Can a tenant ever move regions?

Yes, but treat it as an approved export and import project. Reconcile records, review contracts and transfer mechanisms, verify backups and logs, revoke old access, and prove deletion where required.

Does a regional provider list prove compliance?

No. It proves, at most, that a provider documents a service or location. Application controls, contracts, risk analysis, access procedures, and operational evidence remain separate questions.

References

Related articles