Why Deleting an Azure Log Analytics Table Does Not Delete Healthcare Log Data

cmsapointoo on August 16, 2026

Deleting an Azure Log Analytics table does not necessarily delete the healthcare log data stored in it. Azure documents different results for Azure tables, custom tables, search-results tables, and restored tables. For an Analytics or Basic custom table, deleting the table does not delete its data. Stopping a resource from sending logs also leaves existing records in the workspace until the applicable retention period ends.

A deletion review must name the table type, plan, retention settings, ingestion path, and every copy. Subject-level removal uses separate Delete Data or Purge operations. Exports to Storage or Event Hubs and data mirrored to another service have their own lifecycle. None of these Azure mechanics decides whether HIPAA, GDPR, a contract, or another rule requires retention or deletion.

Which Azure action is being called deletion?

Teams often use one word for four different actions: stopping a data source, deleting a table definition, shortening retention, and removing matching records. Azure treats them differently. A support ticket that says “the logs were deleted” cannot prove which action occurred or whether any record became unrecoverable.

Start with the object. Record the workspace, table name, table type, plan, configured analytics retention, total retention, and connected sources. Then identify the requested outcome. An incident cleanup, a privacy request, a tenant offboarding, and an expired retention period may need different approvals and evidence.

The distinction resembles the one in regional healthcare logging on Google Cloud: a control proves only the property assigned to it. A table deletion event cannot stand in for proof about data in exports, mirrors, backups, or another workspace.

What happens when a table or source is removed?

For an Azure table populated by an Azure resource or solution, Microsoft says that stopping the resource or solution from sending data leaves existing records in the workspace until the table’s retention period ends. The source stops producing new entries, but historical records remain queryable or retained according to their current state.

Custom tables behave differently by plan. Microsoft states that deleting a custom table on the Analytics or Basic plan does not delete its data. The table name remains reserved for 15 days, and the documented retention behavior continues. An Auxiliary custom table enters its own 15-day deletion path. Search-results tables can delete their data immediately, while deleting a restored table removes the hot cache but not the source data.

Those differences make table type part of the deletion record. A screenshot of a missing table in the portal is not enough. Preserve the API-visible plan and retention settings, the action timestamp, and the later check that shows what remained or expired.

Why does shortening retention not prove immediate removal?

Azure Monitor separates analytics retention from total retention. Data can leave the interactive analytics state and remain in long-term retention, where a search job can retrieve it. A query that no longer returns a row in the normal experience does not prove that the row no longer exists.

Microsoft also documents a 30-day waiting period when total retention is shortened. The delay lets an administrator reverse an accidental change. That safety feature means a lower number in configuration is not evidence that older records disappeared on the same day.

The special immediatePurgeDataOn30Days workspace property applies to the documented 30-day configuration. It should not be generalized into an arbitrary deletion switch. Record the actual setting and verify the resulting state instead of inferring it from a policy target.

When are Delete Data and Purge relevant?

Microsoft describes the Delete Data API as an asynchronous way to remove matching data from a specific table. It advises using the operation sparingly because deletion can affect performance, measurements, and aggregations. The predicate should therefore be tested as a query before a destructive request is approved.

The Purge API is a different operation. Microsoft authorizes it for requests required for GDPR compliance, limits request volume, and gives purge operations a formal completion service level of up to 30 days. A 202 Accepted response starts the process; it does not prove completion. The response supplies a status location that must be polled.

Purge also has coverage limits. Microsoft says it cannot purge Basic or Auxiliary tables. Purging an Analytics table does not purge a copy mirrored to Microsoft Sentinel data lake. The legal and privacy team decides whether a request qualifies and what must be retained. The platform team maps that decision to supported operations without broadening the predicate.

How do exports and mirrors change the scope?

Log Analytics data-export rules continuously send new records from selected tables to Azure Storage or Event Hubs as data reaches Azure Monitor. The exported destination is a separate store. Removing a record from the workspace does not, by itself, establish what happened to the destination’s copy.

Microsoft says export rules send all incoming data for a selected table unless an ingestion-time transformation filters or changes it. Rules apply from configuration time and do not backfill historical records. These facts help define the copy inventory: capture the rule, selected tables, activation time, destination, transformation, storage redundancy, and destination retention.

Mirrors require the same discipline. The Sentinel data-lake limitation in the Purge documentation is explicit. Other downstream systems should be checked from their own product documentation and contract. The audit method used for AWS CloudTrail routing and residency is useful here: collection, destination, access, and retention are separate facts.

What should a controlled deletion workflow record?

  1. Confirm the approved legal, contractual, or policy instruction and its exact scope.
  2. Identify the workspace, table, plan, data source, retention state, and subject predicate.
  3. Inventory exports, mirrors, search-result tables, restored tables, and support copies.
  4. Stop new ingestion only when the approved outcome requires it.
  5. Run a read-only query to test which rows the proposed predicate would match.
  6. Select retention expiry, Delete Data, Purge, or another documented route for each store.
  7. Require separate approval before any destructive operation.
  8. Poll asynchronous status and verify the final state in every covered destination.
  9. Store evidence without copying the sensitive log content into a general ticket.

Use synthetic identifiers when testing the workflow. If a real request must be checked, restrict query access and record counts, timestamps, operation IDs, and outcomes rather than pasting patient names or clinical text into the evidence packet.

How should healthcare teams limit log content?

Microsoft recommends filtering, obfuscating, anonymizing, or otherwise excluding personal data before collection when possible. It also suggests separating an internal identifier from the lookup that connects it to a person. These choices reduce the number of rows and copies that a later request must locate.

Do not log intake text, diagnosis, treatment, appointment reason, or other health detail merely because the logging service can store it. Keep an allowlist for event fields and inspect exception messages, URLs, query strings, resource names, and custom dimensions. Access controls and retention do not cure unnecessary collection.

The workflow for a HIPAA business associate supporting an access request provides a related role boundary. Technical retrieval or deletion work can sit with a vendor, while the covered entity or other controller retains the decision assigned by law and contract.

What can the final evidence honestly prove?

A strong result names the records and stores covered by the test. For example: a documented predicate matched a stated count in one Analytics table, the approved operation reached its completed status, the follow-up query returned no matching rows, and named export destinations received separate checks.

That evidence should not become a claim that all healthcare data was deleted from Azure. It does not cover unknown tables, backups, support artifacts, endpoints outside the inventory, or legally retained records. It also does not prove HIPAA or GDPR compliance. Those conclusions require the organization’s facts, roles, contracts, and qualified review.

Frequently asked questions

Does deleting a custom Analytics table delete its data?

No. Microsoft states that deleting an Analytics or Basic custom table does not delete its data. Table-plan and retention behavior must be checked separately.

Does stopping ingestion remove old log entries?

No. Existing records remain subject to the table’s analytics and total retention. Stopping a source controls future ingestion, not historical expiry.

Does a 202 response from the Purge API prove deletion?

No. It means Azure accepted an asynchronous request. Poll the supplied status location and then verify the target table and any separate copies.

Can one purge remove every exported or mirrored copy?

Do not assume so. Microsoft expressly says an Analytics-table purge does not purge its Sentinel data-lake mirror. Storage, Event Hubs, and other destinations have independent controls that need their own review.

References

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

cmsapointoo on August 16, 2026

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

Do AWS CloudTrail Multi-Region Trails Move Healthcare Audit Data Into One Region?

cmsapointoo on August 16, 2026

Yes. An AWS CloudTrail multi-Region trail can centralize events from enabled AWS Regions into one selected Amazon S3 bucket. The bucket may be in any AWS Region. That behavior can move audit records out of the Region where an API action occurred, depending on the trail and bucket configuration. It does not mean HIPAA requires or forbids that topology.

HIPAA’s audit-controls standard requires mechanisms that record and examine activity in systems containing or using electronic protected health information. It does not prescribe CloudTrail or a storage Region. The customer still classifies event contents, chooses an approved zone, configures the controls, and preserves coverage. CloudTrail eligibility and an AWS Business Associate Addendum do not validate those choices.

What does the HIPAA audit-controls standard require?

Regulation: 45 CFR 164.312(b) requires a covered entity or business associate to implement hardware, software, or procedural mechanisms that record and examine activity in information systems containing or using electronic protected health information. The sentence defines a control outcome. It does not specify CloudTrail, one central bucket, US storage, or a particular AWS Region.

A trail can support that outcome by recording AWS activity, but the regulation does not make every event sufficient evidence. The organization decides which systems are in scope, what needs review, and who examines it.

Editorial recommendation: write the requirement and the implementation as separate statements. For example, document that section 164.312(b) is the regulatory requirement, while a named trail, event selection, S3 bucket, access policy, and review process are the chosen controls. This prevents a vendor feature from being described as the law.

What does a multi-Region CloudTrail trail do?

Vendor fact: AWS says a multi-Region trail records events in all AWS Regions enabled in the account and delivers the resulting log files to the S3 bucket specified for that trail. It also extends coverage to Regions enabled after the trail is created. Trails created in the AWS Management Console are multi-Region trails.

The S3 bucket can be in any AWS Region. The destination does not need to match the Region where an event occurred. A trail covering activity in several Regions can therefore produce one centralized collection in the bucket’s Region. Organization trails can extend a similar centralized model across accounts in an AWS organization.

Centralization may help operations, but it remains a location decision. The article on single-Region Pub/Sub controls covers another provider, yet applies the same discipline: describe a setting’s scope before claiming a regional boundary.

Why does the selected S3 bucket affect residency?

Vendor fact: CloudTrail delivers trail log files to the selected S3 bucket. If events occur in several enabled Regions and the bucket is in one Region, the retained log files are centralized in that destination. The event’s awsRegion field can identify the AWS Region associated with the request, but that field is not the storage location of the delivered log object.

Editorial recommendation: treat the bucket Region as part of the audit architecture. Record trail and bucket homes, encryption administration, readers, replication, lifecycle, and exports. Do not call a workload region-contained while its audit records go elsewhere.

HIPAA does not supply the missing location policy. The approved zone may come from another applicable law, a customer contract, a risk decision, or internal architecture. Keep that source beside the configuration. A general comparison of AWS and Google Cloud health-data islands can help frame the operational trade, but it does not decide the trail’s Region.

What sensitive content can appear in CloudTrail events?

Vendor fact: the CloudTrail event record reference documents fields for the caller identity, source IP address, AWS Region, request parameters, response elements, account identifiers, resources, and resource ARNs. The exact record varies by AWS service, event type, and request. Audit metadata should not be assumed harmless merely because it is not an application database row.

Request parameters can reflect values sent to an AWS API. Resource names, tags, and free-form fields can reveal context. AWS recommends avoiding confidential or sensitive information in tags or free-form name fields because it may appear in billing or diagnostic logs.

Editorial recommendation: inspect event schemas with synthetic activity before approving a destination. Review identities, resource names, parameters, errors, and metadata. Remove sensitive naming patterns and broad readers. The guide to measurement without appointment details offers a related minimum-data pattern.

What does CloudTrail’s HIPAA eligibility prove?

Vendor fact: AWS lists CloudTrail in its current HIPAA Eligible Services Reference. AWS also says customers must have an AWS Business Associate Addendum in place before using eligible services to process, store, or transmit protected health information. The reference describes eligibility and agreement scope, not certification of a customer’s application.

A covered-service listing does not select events, keep sensitive values out of requests, choose the bucket Region, configure encryption, restrict IAM access, or establish review. Those remain customer tasks under AWS’s shared-responsibility model.

Editorial recommendation: preserve three separate artifacts: evidence that CloudTrail was on the eligible-services list on the review date, evidence of the applicable AWS agreement, and evidence that the actual trail design passed the organization’s control review. The analysis of Google Cloud BAA boundaries concerns another provider, but its contract lesson applies here: agreement scope does not follow data into an unreviewed service or destination.

When should regional trails replace one multi-Region trail?

Vendor fact: AWS supports both multi-Region and single-Region trails. A single-Region trail records events only in its AWS Region. AWS describes multi-Region trails as a best practice because they help capture activity across enabled Regions, including newly enabled ones.

Editorial recommendation: use separate regional trails only when a documented boundary requires audit records to remain in distinct zones and the team can preserve equivalent coverage. Each zone should have its own approved S3 destination, access model, encryption administration, lifecycle, monitoring, and evidence review. Prevent unapproved replication or export from silently recreating centralization.

This is a trade, not a universal compliance improvement. Regional trails add configuration and can miss activity if a Region lacks a trail. Detect uncovered Regions. Without a separate location requirement, a multi-Region trail may offer simpler coverage.

How can regional trails preserve global-service-event coverage?

Vendor fact: CloudTrail documents special handling for global-service events and options that control whether a trail includes them. Multi-Region trails provide broad coverage, while single-Region designs require deliberate treatment of those events. Service behavior and trail settings must be checked rather than inferred from the number of trail resources.

Editorial recommendation: inventory global services and create safe synthetic management actions. Verify which trail records each action, where its log lands, and whether monitoring receives it. Preserve identifiers, service, recorded Region, bucket, and query result without copying request content.

Testing only a regional service does not prove isolation. Identity and account activity may matter during an investigation. If global-service coverage is incomplete, retain the multi-Region trail or revise the zone decision.

What evidence should a CloudTrail residency review retain?

Editorial recommendation: a review should prove both location and audit completeness. Screenshots alone are weak because they may omit inherited policies, bucket settings, and later drift.

  1. Record account and organization scope, enabled Regions, trail type, and trail home Region.
  2. Record the exact S3 bucket, bucket Region, access policy, replication, and lifecycle configuration.
  3. Record encryption, key administrators, decryptors, and access boundaries.
  4. List event selectors and the systems containing or using electronic protected health information.
  5. Inspect synthetic events for identities, IPs, parameters, account IDs, and ARNs.
  6. Test one approved regional action and the required global-service actions.
  7. Confirm that expected records reach the intended bucket and the review or alert path.
  8. Recheck service eligibility and the agreement at the freshness interval.

Regulation: this evidence supports the audit-control implementation, but the regulation does not prescribe this checklist. The checklist is an editorial translation of the mapped legal and vendor boundaries. Reopen the review when Regions, accounts, services, selectors, buckets, keys, replication, or retention change.

Frequently asked questions

Does HIPAA require CloudTrail logs to stay in the United States?

No such location rule appears in 45 CFR 164.312(b). The provision requires mechanisms to record and examine system activity. Another law, contract, or approved risk policy may impose a location boundary for the specific organization.

Does a multi-Region trail keep each Region’s logs in that Region?

No. AWS says the trail delivers log files from enabled Regions to its selected S3 bucket, and that bucket may be in any AWS Region. The event can retain a Region field while the log object is stored elsewhere.

Does CloudTrail’s HIPAA eligibility make the trail compliant?

No. Eligibility identifies a service that may be used under AWS’s stated HIPAA program and agreement conditions. The customer still owns event selection, data content, access, bucket location, encryption, retention, monitoring, and the compliance assessment.

Are separate regional trails always safer?

No. They can enforce a chosen zone boundary, but they also add coverage and drift risks. Verify every enabled Region and preserve required global-service events before replacing a multi-Region trail.

References

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

cmsapointoo on August 16, 2026

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

AWS Lambda and DynamoDB vs Cloud Run and Firestore: Serverless Cost Drivers for a Health Data Island

cmsapointoo on August 16, 2026

AWS Lambda with DynamoDB and Google Cloud Run with Firestore can both support a small isolated health workload. Neither stack is the universal monthly cost winner. The result depends on region, request pattern, execution duration, memory, concurrency, document or item size, consistency, query shape, storage, backups, logs, and network paths.

A useful comparison converts the same observed workload into each provider’s billing units, applies current regional rates and allowances, and exposes excluded services. This produces a reproducible estimate without presenting a temporary rate as permanent.

Start with one normalized workload

Freeze the period, region, traffic, retention, and recovery policy. Use production telemetry when available. Otherwise, label low, expected, and burst cases as assumptions. Give both stacks equal durability and observability.

Input Unit to record Why it changes cost
Requests Monthly successful and failed invocations Runtime request charges and retry volume
Compute Duration, CPU, memory, concurrency GB-seconds or vCPU and GiB seconds
Database reads Items, documents, index entries, consistency Billing unit differs by database and query
Database writes Writes, deletes, transactions, replicated writes Size and mode can multiply units
Storage Data, metadata, indexes, monthly growth Stored shape can exceed logical payload size
Recovery Backup size, retention, restore frequency Optional recovery features have separate charges
Operations Log volume, retention, metrics, traces Verbose output can dominate a small workload
Network Origin, destination, direction, bytes Region and egress path determine treatment

If one design batches writes, caches reads, or uses higher concurrency, show it as a named architecture variant. For broader budgeting, compare the cloud bill with the operating program instead of mixing staff work into request rates.

Lambda and Cloud Run compute differently

AWS Lambda charges for requests and execution duration measured in GB-seconds. Allocated memory affects the duration charge and the compute resources available to the function. Architecture and region can change the applicable rate. As of August 16, 2026, the published free tier includes one million requests and 400,000 GB-seconds per month, but the estimate should still show gross usage before the allowance.

For Lambda, collect invocations, billed duration, memory, architecture, region, and retries. Multiply billed seconds by allocated memory in GB for each function class. Use provider billing metrics rather than wall-clock latency. Include provisioned concurrency only when used. The Lambda runtime boundary review distinguishes compute from adjacent services.

Cloud Run supports request-based and instance-based billing. Request-based billing charges CPU and memory during billable instance time, with idle charges possible for minimum instances. Instance-based billing charges for the container instance lifetime and has a minimum duration. Concurrency changes how many requests share an instance, so requests and latency alone cannot reproduce cost.

For Cloud Run, record billing mode, vCPU, memory, requests, billable instance seconds, concurrency, minimum instances, region, and retries. As of August 16, 2026, the request-based allowance uses active us-central1 pricing and corresponds to 180,000 vCPU-seconds, 360,000 GiB-seconds, and two million requests per month. The instance-based service allowance uses us-central1 pricing and corresponds to 240,000 vCPU-seconds and 450,000 GiB-seconds per month.

DynamoDB and Firestore operations are not equivalent

DynamoDB offers on-demand and provisioned capacity modes. On-demand bills read and write request units. Provisioned mode bills hourly capacity allocated, even when actual use is lower. For on-demand reads, item size and consistency matter: reads are calculated in 4 KB increments, with eventually consistent, strongly consistent, and transactional reads consuming different units. Writes use 1 KB increments, and transactional writes consume more units than standard writes.

“Ten million reads” is not yet a price input. Add item size, consistency, transactions, table class, region, replication, streams, and commitments. Large items can consume several units. Global tables add regional storage and replicated writes.

Firestore Standard edition charges document reads, writes, deletes, index-entry reads, stored data including indexes and metadata, and network bandwidth. Query shape matters. A query can incur document reads plus index-entry reads. Listeners may create reads when results change or clients reconnect. Offsets can charge for skipped documents. Security-rule evaluation can require dependent-document reads.

Do not translate one DynamoDB read unit into one Firestore document read. Model operations produced by each access pattern. Test indexes and authorization queries with synthetic data. The Firestore database proof connects access and billing behavior.

Free allowances need their own row

Free usage can hide boundaries. Lambda’s request and duration allocations are monthly. As of August 16, 2026, DynamoDB’s free tier for provisioned Standard tables applies per Region and payer account. It includes 25 write capacity units, 25 read capacity units, 25 replicated write capacity units for global tables across two Regions, 25 GB of storage, 2.5 million DynamoDB Streams read requests, and 1 GB of data transfer out per month, with 15 GB of transfer for the first 12 months. It does not apply provisioned capacity to on-demand mode.

Cloud Run allowances depend on billing mode and use a us-central1 price equivalent. A deployment in another region should apply the current regional mechanics from the pricing page. Firestore permits free quota for only one database per project. Its published free quota includes 1 GiB of storage, 50,000 document reads per day, 20,000 writes per day, 20,000 deletes per day, and 10 GiB of outbound transfer per month. Daily quotas reset around midnight Pacific time.

Firestore provides no free usage for point-in-time recovery data, backup data, restore, clone, and TTL deletes. Daily quota also does not protect a burst from limits. Show gross units, eligible allowance, and billable units separately. Confirm account eligibility, database count, region, mode, and cadence before subtraction.

Storage, backups, logs, and egress close the gap

Logical payload size is not total storage. DynamoDB storage depends on table class and region, while indexes, streams, backups, point-in-time recovery, and global replicas create additional surfaces. On-demand backup storage and recovery features are billed separately. Cross-region paths can add transfer charges.

Firestore storage includes document data, metadata, and indexes, calculated from daily storage over the month. Point-in-time recovery, backups, restore, and clone have separate treatment. An index-heavy model can grow faster than the visible records. Compare retention and restore objectives, not only live database size.

Logs, audit records, traces, metrics, and exports need explicit inputs. Estimate bytes per request and retention, then test a synthetic run. Keep record contents out of logs. For network, record source, destination, direction, and bytes. Internet egress, cross-region traffic, database responses, and external calls can follow different schedules.

Also list adjacent components that the architecture actually uses: API gateway or load balancer, queue, scheduler, object store, key service, secrets, DNS, monitoring, and support. Do not assign them to a runtime price line. The pooled regional stack model is useful when fixed resources are shared across isolated workloads.

Build a reproducible calculator

Create one input sheet, two translation sheets, and one comparison sheet. Save source URL, retrieval date, currency, region, architecture, billing mode, and rate beside every unit price. Rates should be replaceable without rewriting formulas.

AWS monthly usage =
  max(0, Lambda requests - eligible request allowance) * regional request rate
  + max(0, Lambda GB-seconds - eligible duration allowance) * regional duration rate
  + DynamoDB read units * selected read rate
  + DynamoDB write units * selected write rate
  + table and index storage * regional storage rate
  + backups + recovery + logs + network + adjacent services

Google Cloud monthly usage =
  billable Cloud Run requests * regional request rate
  + billable vCPU-seconds * regional CPU rate
  + billable GiB-seconds * regional memory rate
  + Firestore document and index reads * regional read rates
  + writes and deletes * regional operation rates
  + database and index storage * regional storage rate
  + backups + recovery + logs + network + adjacent services

For Lambda, compute GB-seconds = invocations × billed seconds × allocated memory in GB by function class. For Cloud Run, use provider billable instance metrics rather than deriving them from request latency when possible. For DynamoDB, translate each operation by item size, consistency, transaction type, and capacity mode. For Firestore, count document operations and index-entry reads by query.

Run low, expected, and burst rows. Add sensitivity for duration, item size, indexes, log retention, backup growth, and cross-region egress. This shows which measurement deserves engineering work.

How to interpret the result

Use the range that matches observed behavior. Lambda with DynamoDB may suit one spiky, item-oriented workload. Cloud Run with Firestore may suit another with favorable concurrency and document access. Change consistency, duration, index fan-out, region, or minimum instances and the ranking can reverse.

Keep cost and control claims separate. Service eligibility, configuration, isolation, backup proof, incident readiness, and contract review require their own evidence. Prefer the estimate that can be reproduced and operated within the required boundary.

Frequently asked questions

Which stack is cheaper for a small health data island?

There is no universal answer. Use the same region, traffic, duration, memory, read and write behavior, storage, backup, logging, and egress assumptions, then apply current provider rates.

Can I compare Lambda requests with Cloud Run requests directly?

Only one part maps directly. Compute also depends on Lambda GB-seconds or Cloud Run CPU and memory billable time, billing mode, concurrency, minimum instances, architecture, and region.

Can free allowances make the monthly bill zero?

They may reduce eligible usage, but they have different limits, cadence, regions, modes, and exclusions. Backups, logs, egress, extra databases, recovery features, and adjacent services can still generate charges.

How often should the calculator be refreshed?

Refresh rates before procurement and after a region, architecture, billing mode, workload, retention, or recovery change. Preserve the retrieval date and recalculate from observed metrics each month during early operation.

References