apointoo.
Request access
Healthcare Cloud

Google Cloud Pub/Sub Message Storage Policy for Single-Region Health Workloads

cmsapointoo··9 min read

A Google Cloud Pub/Sub topic needs more than a single value in allowedPersistenceRegions to support a strict single-region design. That list constrains where Pub/Sub stores and processes message content. Setting enforceInTransit to true adds rejection behavior for publish, pull, and streaming pull operations received in a disallowed region. For stronger regional isolation, Google recommends pairing those settings with a regional endpoint in the allowed region.

This control has sharp boundaries. It does not cover topic names, labels, or IAM settings. A policy update does not relocate messages published under the old policy. One allowed region also concentrates availability on that region. HIPAA coverage under Google’s Business Associate Agreement does not remove the customer’s responsibility to configure and secure the workload.

What the message storage policy controls

Google documents messageStoragePolicy as a topic property. Its allowedPersistenceRegions field lists Google Cloud regions where messages published to the topic may persist in storage. If a publisher runs in a different Google Cloud region or outside Google Cloud, Pub/Sub can route the message for storage in an allowed region.

The configuration page describes the policy as controlling where message contents are stored and processed, regardless of where publish or subscribe requests originate. If more than one region is allowed, Pub/Sub stores a published message in an allowed region close to where the message enters Google’s network.

For a single-region health workload, the list contains one supported region. That is a technical architecture choice, not a statement that HIPAA requires US-only or single-region storage. The service setting must follow the organization’s legal, contractual, resilience, and operational decision.

What enforceInTransit adds

Storage location and request processing are separate concerns until enforceInTransit is enabled. The REST API reference says that, when true, the allowed-region list also enforces in-transit guarantees. Pub/Sub fails publish operations and subscribe operations on attached subscriptions when those operations occur in a region outside the list.

The configuration guide names publish, pull, and streaming pull requests and states that Pub/Sub returns FAILED_PRECONDITION when a request is received in a disallowed region. It also says push delivery is handled only within allowed Cloud regions. A constrained combination of message location, allowed regions, and export-resource location can pause push delivery.

This behavior should be tested, not inferred from a successful topic creation. Run synthetic publish and consume checks through the intended endpoint and a deliberately disallowed endpoint. Confirm the expected success and rejection without putting health information in the test messages.

Why the endpoint matters

Pub/Sub has global, regional, and locational endpoints. The API overview says a regional endpoint always routes requests to Pub/Sub in the specified region and does not reroute them elsewhere. The message storage policy must include that target region. Google recommends a regional endpoint for strict data residency and isolation with enforceInTransit set to true.

The global endpoint behaves differently. Requests from outside Google Cloud can reach a nearby available region that may not be in the policy. With in-transit enforcement, that can produce FAILED_PRECONDITION. Requests originating inside Google Cloud normally route in their origin region, but a client placed in the wrong region can still fail.

Locational endpoints do not provide the same strong assurance as regional endpoints. Google says requests to them are almost always routed to the named region, while regional endpoints are never rerouted. Use the regional endpoint when it is available for the chosen region and strict isolation is the stated goal.

Message content is not all Pub/Sub data

The configuration guide states that the message storage policy applies only to message contents. It does not apply to topic names, labels, or IAM settings. A design document should therefore avoid saying that the policy makes the complete Pub/Sub resource regional.

Names and labels can disclose operational context even when they do not contain message content. Keep health conditions, patient references, and other sensitive details out of resource names and labels. That is editorial architecture advice based on the documented scope boundary, not a claim that the policy governs metadata.

The namespace is also global. Google’s reliability guidance says topics and subscriptions cannot be tied to a region as namespace objects, although resource configuration is replicated to local data stores. If administrative operations and namespace isolation are also required, Pub/Sub may not satisfy that broader requirement without a different service decision.

Policy changes are not retroactive

Changing a topic’s message storage policy affects messages published after the update. Google states that messages already stored under the earlier policy are not moved to comply with the new one. Tightening a topic from several regions to one therefore does not prove that every retained message now sits in the final region.

Organization policy has another drift boundary. New topics can inherit the effective Resource Location Restriction policy, but later organization-policy changes do not automatically propagate to existing topics. An existing topic can become inconsistent with current organization requirements until it is updated.

Migration evidence should separate old and new messages. Record the topic policy before and after the change, the effective timestamp, retention settings, backlog state, regional storage metrics, and the point at which pre-update messages expire or are otherwise handled under an approved plan. Do not claim retroactive relocation without direct service evidence.

The availability cost of one allowed region

A single allowed region creates a deliberate failure boundary. Google’s configuration guide says a distributed application with publishers in several regions becomes only as available as the one allowed region. Adding other publisher locations does not restore storage availability when the policy permits only one destination.

In-transit enforcement can also reject clients that enter through the wrong region instead of routing their requests. Push and export dependencies may stop delivery when their location constraints cannot be satisfied. Ordering and exactly-once behavior have endpoint requirements that also need review for the chosen client.

Document the trade. If regional isolation wins, define what the application does during a regional Pub/Sub outage: stop intake, retain data in another approved component, return an error, or use a separately approved recovery design. Do not silently widen the allowed-region list during an incident. The comparison of serverless health-data island cost drivers also shows why resilience and architecture choices need to be evaluated together.

HIPAA coverage is a separate gate

Google’s HIPAA guide lists Pub/Sub among products covered by the Google Cloud BAA. It also says compliance is a shared responsibility. Customers must accept the BAA where required, use covered products, and configure and secure the applications they build. Google does not present the product list as certification of the customer’s workload.

Message storage policy is one technical control within that larger system. Identity, least privilege, encryption decisions, logging, retention, subscriber behavior, dead-letter handling, exports, backups, incident response, and downstream services remain part of the customer design. A covered service can still be used in an unsuitable flow.

Keep product boundaries explicit. A Google Cloud BAA does not follow a message into an unrelated destination. See why a Google Cloud BAA does not cover Google Ads. Contract scope also does not authorize unrelated reuse, as the BAA and cross-tenant benchmarking review explains.

A verification checklist for a single-region topic

  1. Choose one supported Google Cloud region through the organization’s approved architecture process.
  2. Create or update the topic with only that region in allowedPersistenceRegions.
  3. Set enforceInTransit to true and use the matching regional endpoint.
  4. Verify publisher, pull subscriber, streaming pull, push, export, transform, and dead-letter dependencies against the same region boundary.
  5. Test allowed and disallowed routes with synthetic messages and preserve the results.
  6. Inspect existing topics for drift after organization-policy changes.
  7. Separate pre-update messages from messages published under the new policy.
  8. Monitor stored-message metrics by region and alert on unexpected location or delivery failure.
  9. Exercise the documented outage behavior without widening the policy automatically.

This checklist is editorial guidance derived from current Google documentation. It is not a Google guarantee, a HIPAA requirement, or a complete security program. For queue operations and reconciliation evidence, the outbox reporting guide offers a related state model, although its advertising use case is separate from this health workload.

Frequently asked questions

Does one allowed persistence region keep every Pub/Sub datum there?

No. Google says the policy applies to message contents, not topic names, labels, or IAM settings. Pre-existing messages also remain governed by the policy in effect when they were published.

Can a client keep using the global endpoint?

Google advises using a regional endpoint for strict residency with in-transit enforcement. A global-endpoint request may reach a disallowed region and fail, especially from outside Google Cloud or from a client deployed in another region.

Does single-region configuration improve availability?

Not generally. It limits the service to one allowed region for this topic and creates a regional dependency. The design should record that trade and define outage behavior.

Does Pub/Sub’s place on the covered-product list make the workload HIPAA compliant?

No. Google’s guide describes shared responsibility. BAA scope and product coverage are provider facts; the customer remains responsible for the application, configuration, access, data flow, and compliance assessment.

References

Related articles