apointoo.
Request access
HIPAA

Cloud Run Regions and Immutable Tenant Home Zones

cmsapointoo··7 min read

Short answer: Cloud Run should be deployed in a tenant home region that is assigned by trusted server policy, with storage, keys, backups, logs, queues, and support procedures aligned to that region. As of 2026-08-15, Google Cloud documents Cloud Run locations, Firestore locations, and organization policies for resource locations. A regional service is not proof that every downstream copy stays regional.

GCP service fit and regional boundary

Cloud Run region selection is an architectural decision, not a complete residency guarantee. Google Cloud’s Cloud Run Locations page describes available deployment locations. Firestore Locations describes database location choices, and resource-location organization policy can constrain where resources are created. Use these documents to establish technical controls, then verify every data path and contract.

Choose tenant home region before onboarding. The control plane can hold opaque tenant ID, home region, deployment state, and billing references. It should not hold patient, appointment, service, click, or conversion records. The application resolves membership and home region server-side. Browser geolocation or a client-provided region must never authorize access or route protected data.

Operate one pooled stack per approved active zone where the product and contract permit it. Keep Cloud Run, database, object storage, keys, secrets, logs, backups, queues, and workers in the same policy boundary. If a service has a global control plane or global endpoint, document what metadata crosses it and whether the customer permits that path.

Resource Regional rule Proof
Compute Deploy service in tenant home region Service location and route test
Data Use region-matched store and files Write and read inventory
Operations Keep logs, queues, backups, and keys aligned Configuration and restore test
Governance Block unapproved resource locations Organization policy denial

Compare this with Firestore’s one-time location decision, regional keys, and DynamoDB global table residency.

Request, data, key, and identity path

Route by trusted tenant configuration, not by client input. Authenticate the caller, resolve membership, read immutable home region, and select the regional endpoint or service. Reject a request that supplies a different region or tenant. Log the decision without copying the full request.

Keep the data payload minimum necessary. A generic conversion record can contain an approved event type, time, currency, value, and opaque internal reference only when the tenant and counsel approve the exact use. Do not send patient names, email addresses, phone numbers, hashed identifiers, service names, treatment details, or clinical text to advertising systems.

Regional keys and secrets should follow the data store. Deployment identity should not automatically read production data. Support and restore identities need separate approvals. If a job runs globally, either prove it carries no protected data or redesign it to execute inside the tenant home zone.

control plane
  tenant ID -> immutable home region
                    |
         regional hostname and service
                    |
       database, files, keys, logs, backups

Jobs, audit, backup, and failure handling

Regional promises fail in background systems first. Inspect scheduled jobs, queue destinations, dead letters, logging sinks, monitoring, error reports, snapshots, key replicas, support exports, and restore targets. A Cloud Run service can be regional while its logging or backup path is not. Verify actual resource location and access identity.

Use organization policy to block creation outside approved locations, then test the denial with a non-production service. Do not rely on policy alone: a resource may be created in an approved region and still call a global or foreign service. Test wrong-region writes, alternate hostnames, direct API calls, and job triggers.

Backups and restore need the same home-zone rule. Create synthetic tenants, back up, restore inside the approved region, verify keys and tenant membership, inspect logs, and delete the test copy. Test an attempted restore outside the zone and record the denial or approval process.

Incident response should identify who can contain a service, revoke a role, inspect logs, restore data, and notify the customer. Remote support access from another country may be a transfer or contract issue even if the database remains regional. Keep the legal analysis separate and route it to counsel.

Cost and proof gate

Every active region adds a fixed operational floor. Estimate Cloud Run, ingress, database, storage, logs, keys, secrets, backups, queues, DNS, and support per region. Label provider prices as estimates with region, workload, retention, and date. Do not assume three regions cost only three times request charges when fixed resources dominate.

  • Assign home region before protected onboarding.
  • Use organization policy to restrict resource locations.
  • Inspect global endpoint and support paths.
  • Test data, logs, keys, backups, and restore in region.
  • Recalculate price and recheck region availability before launch.

Regional proof checklist

Use one synthetic tenant per approved zone.

  1. Assign immutable home region on the server.
  2. Deploy service, store, key, queue, log, and backup in that region.
  3. Run normal, wrong-tenant, wrong-region, and alternate-host requests.
  4. Attempt resource creation outside policy and verify denial.
  5. Inspect actual locations and operator identities.
  6. Restore synthetic data and verify authorization before read.
  7. Record transfer and support questions for counsel.

The final claim should name the verified resources and remaining exceptions. A region setting alone does not establish a residency or legal conclusion.

Home-region assignment should be a controlled onboarding state transition. Before the first protected write, an authorized workflow validates customer jurisdiction, contract, region availability, resource template, key, backup, and support policy. After assignment, ordinary users and browser requests can read the region but cannot change it. A move requires export, import, reconciliation, deletion, approval, and an audit trail.

Test location using observed artifacts. Inspect resource metadata, database location, storage bucket, key ring, log bucket, queue, backup, and restore target. Check deployment and support identities. A policy file is useful, but a smoke test should prove that an unapproved resource creation or wrong-region request is rejected. Record exceptions explicitly.

Regional stacks can be pooled across tenants in the same approved zone, but pooled storage still needs tenant authorization. A region boundary does not replace a database policy, application membership, or support review. Use the Firestore location article when a database cannot be moved in place, and Cloud SQL RLS when row policy is a required backstop.

Include region activation in product economics. A new zone adds compute, ingress, database or document store, keys, secrets, logs, backups, monitoring, support, and testing. Provision it only after a tenant and contract require it, then run the synthetic proof before production.

Frequently asked questions

Can Cloud Run be deployed in one home region?

Yes, where the selected service and product plan support it, but the rest of the data path must match. Verify database, files, logs, keys, backups, queues, workers, and support access.

Can a browser choose tenant region?

No. Resolve membership and immutable home region from trusted server-side configuration. Browser input can request a route but cannot authorize a region or tenant.

Do organization policies prove residency?

No. They can block some resource locations. They do not eliminate global endpoints, service calls, logs, backups, support access, or application routing that creates another path.

When should a new region be activated?

Activate it when a contract and paying tenant need it, after a synthetic regional proof. Include fixed cloud, operations, recovery, support, and legal review costs.

References

Related articles