apointoo.
Request access
Healthcare Cloud

Does a Regional Healthcare Workload Keep Google Cloud Logs in the Same Region?

cmsapointoo··9 min read

No. Deploying a healthcare workload in one Google Cloud region does not place its Cloud Logging data in that region. Workload placement, log-bucket location, sink destination, and saved-query location are separate controls. A regional application can therefore write logs to system buckets whose location does not match the application.

Cloud Logging creates _Default and _Required buckets for projects and other resource types. Without a preconfigured organization or folder default, Google documents these system buckets in the global location. Default settings can choose their storage location in new child resources, but they are prospective. They do not relocate buckets that already exist, and an existing log bucket’s location cannot be changed.

Workload location and log location are different facts

A service deployed in a named region has a workload-location fact. Cloud Logging stores log entries in log buckets, and each bucket has its own location. Google describes log buckets as regional resources because the infrastructure that stores, indexes, and searches those entries is located in a specific geographical location.

The source application does not confer its region on the destination bucket. The Log Router evaluates log entries and sends them according to sink definitions. It processes an entry in the region where it is received, may buffer it temporarily, and may route it to another region. Sharing log data with another service can also introduce another location decision.

The guide to single-region Pub/Sub message storage has a related service boundary. A region setting controls only what the product documentation assigns to it. Architecture records should name the resource, property, scope, and exceptions instead of saying that the whole project is regional.

What the two system buckets contain

Cloud Logging creates a _Required bucket and a _Default bucket for each project, billing account, folder, and organization. They have correspondingly named sinks. The two buckets serve different log classes and cannot be treated as interchangeable copies.

The _Required bucket receives logs that Google retains for compliance or auditing purposes, including Admin Activity and System Event audit logs. Its routing is constrained: redirecting the _Default sink does not redirect the _Required sink. The _Default bucket receives logs not automatically placed in _Required, including application logs and some audit-log categories depending on configuration.

A review that inspects only _Default can miss the location of required audit evidence. A review that inspects only _Required can miss application logs containing resource metadata or sensitive values. Inventory both buckets, their locations, included log classes, readers, retention, and downstream sinks.

Why default storage settings must come before project creation

Organizations and folders can define default Cloud Logging settings inherited by new child resources. A storage-location setting controls where new system-created _Default and _Required buckets are created. It can also control the location used for new and recent queries in Logs Explorer or Observability Analytics.

Google states that changed defaults apply only to resources created after configuration. Existing resources do not inherit the new location retroactively. If a team sets an organization default today, projects created yesterday keep their existing bucket locations. The console may show a desired organization setting while old projects retain a different reality.

The order of operations matters: approve the location, set the organization or folder default, verify inheritance, then create the project. Preserve the output that shows the effective settings and the bucket locations. A policy document without resource evidence cannot prove where existing logs are stored.

Existing buckets cannot be relocated

Cloud Logging fixes a bucket’s location at creation. Google says the location of an existing bucket cannot be changed. Updating a label, retention period, sink, or organization default does not turn that bucket into a bucket in another region.

For logs routed through _Default, a team can create a user-defined bucket in the approved location and update the _Default sink to send future matching entries there. That changes the future destination. It does not move entries already stored in the old bucket, and it does not change the separate _Required path.

A migration plan should therefore distinguish old records, future records, and required logs. Record the cutover time, test a synthetic log entry, query the intended bucket, and confirm that exclusions do not create a silent gap. The review of AWS CloudTrail multi-Region routing uses the same discipline on another provider: collection topology and destination location need their own evidence.

Redirecting _Default leaves _Required as a separate gate

Google’s regionalization guide shows how to create a bucket in a selected region and update the _Default sink. The guide also warns that the _Required sink cannot be changed in that existing setup. Required logs continue to their own system bucket.

A _Default redirect supports a narrow claim about the log classes it matches after cutover. It does not prove that all logs are regional. The evidence says nothing about excluded entries, logs already retained elsewhere, required audit logs, or copies sent to other destinations.

If _Required must start in a chosen location, use the documented organization or folder default before creating the child resource. For an existing project, assess the fixed bucket location and available architecture options rather than presenting a _Default redirect as a relocation.

Queries, connected services, and names can widen the boundary

Bucket storage is not the only location fact. Default settings can affect where Logs Explorer and Observability Analytics store new and recent queries. Google also warns that services which query log data may store query results in a global location. A regional bucket does not automatically regionalize every tool that reads from it.

Sinks can route entries to other projects or supported destinations. Security services can consume log data. Exports for archives or analysis introduce their own storage, access, key, and retention decisions. Each downstream path needs a location and contract review.

Google’s HIPAA guide advises customers to avoid putting protected health information or security credentials in resource metadata because metadata can appear in logs. Keep patient identifiers, conditions, appointment details, and treatment names out of resource names and free-form log messages. That advice reduces exposure, but it does not replace bucket controls or access review.

BAA coverage is not configuration validation

Google lists Cloud Logging among products covered by its Cloud BAA and says the agreement covers its infrastructure. The same guide describes HIPAA compliance as a shared responsibility. The customer remains responsible for deciding whether a BAA is required, accepting it where necessary, using covered services, and configuring and securing the application.

A BAA does not inspect bucket locations, sink filters, IAM roles, exported copies, log contents, or saved-query behavior. It also does not turn a regional design into a HIPAA requirement. Contract coverage and configuration evidence answer different questions.

The article on why a Google Cloud BAA does not cover Google Ads explains this product boundary. Even inside covered Google Cloud services, the customer must validate the actual path. Agreement scope is necessary where applicable, but it is not proof that the path meets the organization’s legal, contractual, security, and residency decisions.

A practical evidence checklist

  1. Record the workload’s region separately from every log bucket location.
  2. Describe effective Cloud Logging defaults at the organization and folder.
  3. List _Default, _Required, and user-defined buckets for each resource.
  4. Capture bucket locations from the service, not from the architecture diagram alone.
  5. Map every sink, filter, exclusion, destination, and cutover timestamp.
  6. Test future routing with synthetic log entries that contain no health information.
  7. Check saved-query location and any service that consumes or exports logs.
  8. Review IAM readers, retention, encryption decisions, and downstream copies.
  9. Keep BAA evidence separate from configuration and compliance approval.

State only what the evidence shows: named log classes generated after a recorded time were routed to a verified bucket location under the captured configuration. Do not upgrade that finding into “all project data stays in region.” That broader claim includes services and paths this logging review did not test.

Common failure modes during regionalization

One failure starts with timing: the default is configured after project creation, so the project keeps old bucket locations. Another changes _Default and forgets _Required. A third validates the bucket but ignores an export sink or globally stored query result.

Teams also confuse an empty regional bucket with successful routing. Send a synthetic event and verify it in the intended log view. Confirm that required logs remain accounted for and that no exclusion filter suppresses evidence needed for operations or investigation.

A regional logging decision also affects incident work. Responders need access to the approved buckets without copying entries into an unreviewed workspace. Preserve a tested query and escalation process. Region controls should survive an incident instead of being bypassed when evidence is needed quickly.

Frequently asked questions

If Cloud Run is regional, are its logs regional too?

Not by that fact alone. Cloud Run resource location and Cloud Logging bucket location are separate. Inspect the project’s system buckets, effective defaults, sinks, and downstream destinations.

Can changing the organization default move existing log buckets?

No. Google says changed default settings apply to resources created afterward, and existing bucket locations cannot be changed. The team must assess existing data and future-routing options separately.

Does redirecting _Default regionalize every audit log?

No. The _Required sink and bucket are separate. Redirecting _Default covers only future entries matched by that sink and does not relocate existing entries.

Does Google’s BAA make the logging design HIPAA compliant?

No. Google describes compliance as shared responsibility. BAA coverage is a contract fact; bucket locations, access, log contents, retention, exports, application controls, and the customer’s compliance assessment remain separate.

References

Related articles