Google Cloud Platform

Auth & config

# Interactive user login (browser)
gcloud auth login

# Application Default Credentials for local SDK/code
gcloud auth application-default login

# Pin the active project for all subsequent commands
gcloud config set project PROJECT_ID

# Inspect current config (account, project, region)
gcloud config list

# What am I, and what can I see?
gcloud auth list
gcloud projects list

Projects & billing

# Create a new project (use a non-PHI, non-identifying name)
gcloud projects create prod-phi-app-01 --name="Prod PHI App"

# Find your billing account, then link the project to it
gcloud billing accounts list
gcloud billing projects link prod-phi-app-01 \
    --billing-account=0X0X0X-0X0X0X-0X0X0X

Compute / Run / GKE quickies

# Deploy a container to Cloud Run (private by default below)
gcloud run deploy intake-api \
    --image us-docker.pkg.dev/PROJECT_ID/app/intake-api:latest \
    --region us-central1 --no-allow-unauthenticated

# List VMs
gcloud compute instances list

# Wire kubectl to a GKE cluster, then look around
gcloud container clusters get-credentials phi-cluster --region us-central1
kubectl get pods

Storage & data

gcloud storage is the modern, faster replacement for gsutil — prefer it for new scripts.

# Object storage
gcloud storage ls
gcloud storage cp report.pdf gs://BUCKET/intake/        # filename only, no PHI in the name

# BigQuery (standard SQL)
bq ls
bq query --use_legacy_sql=false 'SELECT COUNT(*) FROM `PROJECT.dataset.encounters`'

IAM & secrets

# Grant a role at the project level (least privilege!)
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:intake-api@PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/datastore.user"

# Create a dedicated service account for one workload
gcloud iam service-accounts create intake-api \
    --display-name="Intake API runtime"

# Secret Manager: create then read a secret version
gcloud secrets create db-password --replication-policy="automatic"
gcloud secrets versions access latest --secret="db-password"

Logging

# Read recent audit/admin activity (no resource CONTENTS appear here)
gcloud logging read 'logName:"cloudaudit.googleapis.com"' --limit=20 --freshness=1h

# Route logs to long-term storage / analysis sinks
gcloud logging sinks create audit-archive \
    storage.googleapis.com/AUDIT_BUCKET \
    --log-filter='logName:"cloudaudit.googleapis.com"'

At-a-glance

gcloud config set \
  project OTHER_ID

gcloud projects \
  get-iam-policy PROJECT_ID

gcloud services enable \
  healthcare.googleapis.com

gcloud run services \
  logs read intake-api \
  --region us-central1

Install the SDK

Install the Google Cloud CLI (search "Install the Google Cloud CLI" in Google's docs), then initialize it and add the components you need.

# First-run setup: pick account, project, default region
gcloud init

# Keep the CLI current
gcloud components update

# Add the components a HIPAA web app typically needs
gcloud components install kubectl gke-gcloud-auth-plugin

Resource hierarchy

GCP resources live in a tree: Organization → Folders → Projects → Resources. IAM bindings and Organization Policies set high in the tree inherit downward. A deliberate hierarchy — with PHI workloads isolated in their own project(s) and separated from dev/test by folder — is the foundation of an auditable HIPAA environment. It lets you apply a tight org policy and VPC Service Controls perimeter to exactly the projects that touch PHI, and nowhere else.

Sign the BAA (step zero for HIPAA)

Billing guardrails

Set budgets and alerts early so a runaway pipeline or misconfigured autoscaler doesn't surprise you, and export billing data to BigQuery for analysis.

# Create a budget with alert thresholds
gcloud billing budgets create \
    --billing-account=0X0X0X-0X0X0X-0X0X0X \
    --display-name="Prod PHI monthly" \
    --budget-amount=5000USD \
    --threshold-rule=percent=0.5 \
    --threshold-rule=percent=0.9 \
    --threshold-rule=percent=1.0

# Then enable Billing export to BigQuery in the console:
#   Billing -> Billing export -> BigQuery export

First-project IAM basics

Grant the least privilege that gets the job done. Prefer predefined roles over the broad basic roles (Owner/Editor/Viewer); reach for custom roles only when predefined ones don't fit. Give each workload its own service account — and treat SA keys as high-value secrets, because they can reach PHI.

# A dedicated, least-privilege service account per workload
gcloud iam service-accounts create intake-api \
    --display-name="Intake API runtime"

# Grant only the specific roles the workload needs
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:intake-api@PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/healthcare.fhirResourceEditor"

Pre-flight checklist for any new PHI-handling service

Run through this before pointing real PHI at any new service:

• BAA signed and current.
• Every product in the data path is on the covered list — no preview/Pre-GA surfaces.
• IAM scoped to least privilege; service account keys controlled (ideally none).
• Encryption decision made — default Google-managed keys vs CMEK/Cloud HSM.
• Audit logging on, exported (Cloud Storage for archive, BigQuery for analysis), and access-controlled.
• No PHI in names, labels, metadata, headers, or logs.
• VPC Service Controls considered for a perimeter around PHI services.
• Sensitive Data Protection (DLP) considered for discovery and de-identification.

Cloud Run

What it is. Fully managed serverless container hosting. Hand it a container image (or source); it runs and autoscales it, down to zero. No servers to patch.

Reach for it when. You're building a web app, API, or microservice and don't want to manage infrastructure; you want pay-per-use with scale-to-zero for spiky or low-traffic intake workloads; you're deploying a stateless service — or even hosting your own MCP server.

Claude / MCP. An official open-source Cloud Run MCP server (Gemini CLI extension) lets an agent deploy and manage apps; it's also drivable via the gcloud MCP server.

Cloud Run functions

What it is. Event-driven functions (the evolution of Cloud Functions). Run a snippet of code in response to an HTTP call, a Pub/Sub message, or a file landing in a bucket.

Reach for it when. You need glue logic between services (e.g. "when a document uploads, kick off de-identification"), or want the smallest possible unit of deploy for a single task.

Claude / MCP. Deploy and manage via the gcloud MCP or the Cloud Run MCP server.

Google Kubernetes Engine (GKE)

What it is. Managed Kubernetes — full control over containerized workloads, networking, and scaling, at the cost of more operational complexity than Cloud Run.

Reach for it when. You have many interdependent services, need fine-grained control, are migrating an existing Kubernetes setup, or need advanced networking, stateful workloads, or specific scheduling that Cloud Run's request/response, stateless model can't accommodate.

HIPAA. Covered — along with Backup for GKE, GKE Enterprise Config Management, and GKE Hub.

Claude / MCP. Has both a Google-managed remote MCP server and an open-source one. The MCP server exposes a structured interface so an agent can diagnose issues, remediate failures, and optimize costs without parsing brittle CLI output — a strong fit for ops/SRE assistance.

Compute Engine (GCE)

What it is. Raw virtual machines in Google's data centers. Maximum control, maximum responsibility — you patch the OS.

Reach for it when. You're lifting-and-shifting a legacy app that expects a VM; you need a specific OS, GPU, or machine type that containers don't cleanly support; or you have licensing/compliance reasons to run on dedicated or sole-tenant hardware.

HIPAA. Covered — along with Persistent Disk and Sole-Tenant Nodes.

Claude / MCP. Google-managed remote MCP server for Compute Engine — provision and manage instances through an agent.

App Engine

What it is. The original GCP platform-as-a-service: push code, it runs and scales. Largely superseded by Cloud Run for new work, but still solid.

Reach for it when. You're maintaining an existing App Engine app, or want PaaS simplicity and your app fits the standard/flex runtimes. (For new builds, prefer Cloud Run.)

Claude / MCP. Via the gcloud MCP.

Batch

What it is. Managed scheduling and running of batch jobs across pools of VMs.

Reach for it when. You have large, parallelizable, finite jobs — bulk document processing, data transformation, or ML preprocessing over a corpus of records.

Claude / MCP. Via the gcloud MCP.

Deploying to Cloud Run (the safe defaults)

A PHI-appropriate deploy is private by default, runs as a dedicated least-privilege service account, pulls secrets from Secret Manager rather than baking them into the image, and routes egress through your VPC.

gcloud run deploy intake-api \
    --image us-docker.pkg.dev/PROJECT_ID/app/intake-api:latest \
    --region us-central1 \
    --no-allow-unauthenticated \
    --service-account intake-api@PROJECT_ID.iam.gserviceaccount.com \
    --set-secrets "DB_PASSWORD=db-password:latest" \
    --network projects/PROJECT_ID/global/networks/phi-vpc \
    --subnet phi-subnet-uscentral1 \
    --vpc-egress all-traffic

• --no-allow-unauthenticated — require IAM auth; put a load balancer / IAP or API gateway in front for external users.
• --service-account — run as a scoped identity, not the default compute SA.
• --set-secrets — mount Secret Manager values at runtime; nothing lands in the image.
• --network / --subnet / --vpc-egress — send outbound traffic through your VPC so it stays inside a VPC Service Controls perimeter.

Because Cloud Run hosts any container, it's also a clean place to run your own MCP server — deploy it private, front it with auth, and keep it inside the perimeter alongside your other PHI services.

Which compute should I pick?

Databases

What it is. Fully managed relational database for MySQL, PostgreSQL, and SQL Server — the default relational choice for most apps.

Reach for it when. You want standard SQL without managing the engine, backups, or patching; your data is relational and fits comfortably on a single primary (with read replicas); or you're migrating an existing MySQL/Postgres/SQL Server app.

Claude / MCP. Google-managed remote MCP servers for all three engines. Also fronted by the OSS MCP Toolbox for Databases.

What it is. PostgreSQL-compatible database tuned for demanding enterprise workloads — faster than standard Postgres on mixed transactional/analytical loads, with built-in AI/vector features.

Reach for it when. You've outgrown Cloud SQL Postgres on performance, or you want Postgres compatibility plus heavy analytical queries or vector search in the same database.

Claude / MCP. Google-managed remote MCP server, plus the OSS MCP Toolbox.

What it is. Serverless NoSQL document database with real-time sync and MongoDB compatibility. Scales automatically; flexible schemas.

Reach for it when. You're building mobile/web apps that need real-time updates and offline sync, your data is document-shaped, and you don't want to manage capacity.

Claude / MCP. Google-managed remote MCP server, plus the OSS MCP Toolbox.

What it is. Cloud-native relational database with effectively unlimited horizontal scale and 99.999% availability — globally distributed and strongly consistent. The "Google-scale" relational option.

Reach for it when. You need relational semantics and massive scale / global distribution, you can't accept the single-primary ceiling of Cloud SQL, or financial-grade availability matters.

Claude / MCP. Google-managed remote MCP server, plus the OSS MCP Toolbox.

What it is. Cloud-native wide-column NoSQL database for huge-scale, low-latency workloads (the database behind many Google products).

Reach for it when. You have enormous volumes of time-series, IoT, or analytical key-value data; you need single-digit-millisecond reads/writes at scale; and your access pattern is key-based, not relational.

Claude / MCP. Google-managed remote MCP server, plus the OSS MCP Toolbox.

What it is. Fully managed Redis and Memcached for sub-millisecond in-memory data access.

Reach for it when. You need a cache in front of a database, fast session storage, rate limiting, or ephemeral state.

Claude / MCP. Via the gcloud MCP (no dedicated database MCP server).

What it is. The older NoSQL document database (Firestore in Datastore mode is the modern path). Still covered and supported.

Reach for it when. You're maintaining an existing Datastore app. For new builds, prefer Firestore.

Claude / MCP. Via the gcloud MCP.

Database decision table

Creating a PHI-safe Cloud SQL instance

A PHI database should have no public IP, require SSL, keep automated backups, and be reachable only over Private IP / Private Service Connect — never the public internet.

gcloud sql instances create phi-pg-01 \
    --database-version=POSTGRES_15 \
    --region=us-central1 \
    --tier=db-custom-2-7680 \
    --no-assign-ip \
    --network=projects/PROJECT_ID/global/networks/phi-vpc \
    --enable-google-private-path \
    --ssl-mode=ENCRYPTED_ONLY \
    --require-ssl \
    --backup \
    --backup-start-time=03:00 \
    --retained-backups-count=30 \
    --availability-type=REGIONAL

• --no-assign-ip — Private IP only; the instance is never given a public address.
• --network / --enable-google-private-path — reachable only from inside your VPC.
• --ssl-mode=ENCRYPTED_ONLY / --require-ssl — reject unencrypted connections.
• --backup / --retained-backups-count — automated, retained backups for recovery.
• --availability-type=REGIONAL — high-availability failover across zones.

Storage

What it is. Object storage — secure, durable, scalable buckets for files of any kind. The default home for uploaded documents, medical images, data exports, ML training data, and long-term audit-log archives.

Reach for it when. You need to store and serve files (uploads, reports, images, exports), stage data for BigQuery or ML pipelines, or archive audit logs for long-term retention.

Two standing recommendations. Enable Object Versioning to recover from accidental deletion, and never request caching of PHI via Cloud CDN — CDN caches are not a place for protected data.

Claude / MCP. Open-source Cloud Storage MCP server (googleapis/gcloud-mcp) — read/write objects and provide buckets as agent context for unstructured data.

What it is. Managed, scalable network file storage (NFS) that VMs and GKE clusters can mount like a shared drive.

Reach for it when. An application expects a POSIX file system / shared mount, or your GKE / Compute Engine workloads need shared file access. Use IP-based access control to restrict which clients can mount it, and enable backups.

What it is. Block storage attached to Compute Engine VMs — the durable disks behind your instances, surviving restarts.

What it is. Managed file storage for NFS, SMB, and multi-protocol environments — enterprise NAS in the cloud, for migrating workloads that need SMB or multi-protocol shares.

What it is. Centralized, application-consistent backup and disaster recovery across your GCP resources. For PHI, a managed backup/restore and DR strategy is not optional.

What it is. Move large volumes of data into Cloud Storage — online (Storage Transfer Service) or via shipped hardware (Transfer Appliance) for very large datasets migrating from on-prem or another cloud.

Storage decision table

Creating a PHI-safe bucket

Lock the bucket to uniform bucket-level access (IAM only, no per-object ACLs), turn on versioning, and add a lifecycle / retention policy. Layer CMEK when you need key custody.

# Create with uniform access + CMEK at creation time
gcloud storage buckets create gs://phi-app-intake-01 \
    --location=us-central1 \
    --uniform-bucket-level-access \
    --public-access-prevention \
    --default-encryption-key=projects/PROJECT_ID/locations/us-central1/keyRings/phi-kr/cryptoKeys/phi-key

# Turn on Object Versioning (recover from accidental deletes)
gcloud storage buckets update gs://phi-app-intake-01 --versioning

# Upload an object — filename only, NEVER PHI in the object name
gcloud storage cp report.pdf gs://phi-app-intake-01/intake/

• --uniform-bucket-level-access — access governed solely by IAM, no surprise per-object ACLs.
• --public-access-prevention — the bucket can never be made public.
• --default-encryption-key — CMEK so you hold the key (default encryption-at-rest is always on; this adds key custody).
• For retention, attach a lifecycle rule (e.g. transition to Archive class, set a retention period for the audit-log archive).

The pieces

What it is. Your private, isolated network in Google Cloud — subnets, routing, and firewall rules for every resource.

Reach for it when. Always — every resource lives in a VPC. Design subnets and firewall rules to isolate PHI-handling services, and pair it with VPC Service Controls (Security & Identity) for an exfiltration perimeter.

What it is. Distribute traffic across instances and regions — global or regional, HTTP(S) or TCP/UDP — for services that need to scale or stay highly available.

What it is. Web application firewall and DDoS protection — security policies (including OWASP rules) that sit in front of your load balancers. Reach for it whenever you expose a public endpoint and need protection against web attacks and volumetric DDoS.

What it is. Managed, low-latency DNS for your domains.

What it is. Gives private instances outbound internet access without exposing them with public IPs. Reach for it when private VMs/containers need to reach the internet (e.g. pull packages) but must stay unreachable from outside — the standard egress path for a private data tier.

What it is. Content delivery network — cache and serve static web/video content close to users.

What it is. Hybrid connectivity — connect your on-prem network to GCP over the internet (VPN) or via dedicated physical links (Interconnect), with Cloud Router, Network Connectivity Center, Private Service Connect, and Service Directory rounding out the toolkit.

Reach for it when. You're hybrid — on-prem systems need private connectivity to GCP (common for existing health systems with their own data centers). Prefer Private IP for database connectivity so a PHI database is never exposed to the internet.

Claude / MCP. All of the above are driven via the gcloud MCP.

Reference topology for a PHI web app

A defensible layout pushes all the sensitive work behind a private boundary:

• Edge: external HTTPS Load Balancer with Cloud Armor (OWASP + DDoS) in front.
• App tier: Cloud Run / GKE deployed privately (no public ingress; reachable only through the LB / IAP).
• Data tier: Cloud SQL reached over Private IP — no public address on the database.
• Egress: Cloud NAT for outbound from private instances; no public IPs anywhere on the data tier.
• Perimeter: a VPC Service Controls boundary around the PHI services (see Security & Identity).

# A custom VPC with one private subnet
gcloud compute networks create phi-vpc --subnet-mode=custom

gcloud compute networks subnets create phi-subnet-uscentral1 \
    --network=phi-vpc \
    --region=us-central1 \
    --range=10.10.0.0/20 \
    --enable-private-ip-google-access

# Default-deny posture: allow internal traffic only, no broad ingress
gcloud compute firewall-rules create phi-allow-internal \
    --network=phi-vpc \
    --direction=INGRESS \
    --action=ALLOW \
    --rules=tcp:443,tcp:5432 \
    --source-ranges=10.10.0.0/20

--enable-private-ip-google-access lets private instances reach Google APIs without a public IP; the firewall rule restricts ingress to in-VPC source ranges only.

Networking decision table

Identity & Access Management (IAM)

What it is. The permission system for all of Google Cloud — who can do what to which resource.

Reach for it when. Always. Every project needs least privilege from day one. Prefer predefined roles over broad basic roles; use custom roles only when predefined ones don't fit. Tightly control service accounts and their keys — they can reach PHI. IAM is the single biggest lever on Security Rule compliance.

Claude / MCP. Via the gcloud MCP; Cloud Resource Manager (project/org/folder management) has its own Google-managed remote MCP server.

Cloud KMS / Cloud HSM / Key Access Justifications

What it is. Manage encryption keys (KMS), optionally hardware-backed (HSM). Enables CMEK so you hold the keys rather than relying solely on Google's default encryption. Key Access Justifications (KAJ) requires a stated reason before a key is used.

Reach for it when. Your posture requires customer-managed keys, hardware key custody (HSM), or an auditable justification on every key access (KAJ).

# A keyring + key for PHI workloads (then reference it as CMEK)
gcloud kms keyrings create phi-kr --location=us-central1

gcloud kms keys create phi-key \
    --location=us-central1 \
    --keyring=phi-kr \
    --purpose=encryption \
    --rotation-period=90d \
    --next-rotation-time=$(date -u -d '+90 days' +%Y-%m-%dT%H:%M:%SZ)

Secret Manager

What it is. Secure, versioned, IAM-gated storage for API keys, passwords, certificates, and other credentials — so they never live in code or config.

# Create a secret, add a version, then read it back (IAM-gated)
gcloud secrets create db-password --replication-policy="automatic"

printf '%s' "$DB_PASSWORD" | \
    gcloud secrets versions add db-password --data-file=-

gcloud secrets versions access latest --secret="db-password"

Sensitive Data Protection (Cloud DLP)

What it is. The de-identification engine — discover, classify, and de-identify PHI/PII across BigQuery, Cloud Storage, and databases (redact, mask, or tokenize).

Reach for it when. You need to scan for PHI/PII across your data stores, de-identify data before analytics or sharing, or verify PHI hasn't leaked somewhere it shouldn't be. Write DLP output only to targets inside your secure environment. This is the same de-identification engine referenced again in the Healthcare API section.

Security Command Center

What it is. The central posture / misconfiguration / threat dashboard — a single pane for security findings across your GCP estate, and useful evidence when demonstrating monitoring for compliance.

Claude / MCP. Part of the open-source Google Cloud Security MCP (google/mcp-security), which bundles SCC, Chronicle, and more so an agent can investigate findings.

Google Security Operations (Chronicle)

What it is. SIEM/SOAR — detect, investigate, and respond to threats across security telemetry at scale.

Reach for it when. You're running a security operations function and want threat detection/response or incident log analysis.

Claude / MCP. Both a Google-managed remote MCP server and coverage in the OSS Google Cloud Security MCP — a strong fit for agent-assisted security investigation.

Model Armor

What it is. A guardrail layer that defends AI agents/applications against threats like indirect prompt injection.

Reach for it when. You're wiring agents (including ones that call MCP servers) into PHI-handling systems and need protection against prompt-injection and agentic threats. Conceptually it wraps around your agent stack.

VPC Service Controls

What it is. Draw a security perimeter around GCP services so data can't exfiltrate outside it — even with valid credentials. A high-value control for HIPAA architectures and the perimeter referenced throughout the networking and storage sections.

Assured Workloads

What it is. Programmatic enforcement of compliance controls — data residency and personnel controls — across sensitive workloads, so the guardrails are enforced rather than merely documented.

Identity Platform

What it is. End-user authentication for your app — sign-in, identity federation, and user management. The enterprise sibling of Firebase Auth.

Reach for it when. You need end-user auth in a PHI product. Prefer Identity Platform over Firebase Auth — it's on the covered list; follow its specific HIPAA practices.

Also covered, reach for as needed

All Covered and driven via the gcloud MCP: Access Approval, Access Transparency, Access Context Manager, Binary Authorization, Identity-Aware Proxy (IAP), Certificate Authority Service, reCAPTCHA Enterprise (keep PHI out of URIs/actions), and Managed Service for Microsoft Active Directory.

Security decision table

Least-privilege IAM binding

Bind a specific predefined role to a dedicated service account — never a broad basic role on a PHI project.

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:intake-api@PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/cloudsql.client" \
    --condition=None

Data & analytics

What it is. Serverless data warehouse and analytics platform — query petabytes with standard SQL, no infrastructure to manage. It's also where you analyze the audit logs you export for HIPAA: Google recommends routing Cloud Audit Logs to BigQuery for long-term, queryable security/compliance analysis (the log sink set up in section 02 / 06 lands here).

Reach for it when. You need analytics over large datasets, you're building reporting / dashboards / ML feature pipelines, or you're doing large-scale audit-log analysis for security and compliance.

HIPAA. Covered — along with BigQuery Data Transfer Service, BigQuery Omni, and Gemini in BigQuery. Keep PHI out of dataset/table/column names (they're metadata); de-identify before any analytics that doesn't strictly need identified PHI (see section 09).

Claude / MCP. One of the first GCP MCP servers Google shipped — a Google-managed remote server lets an agent run queries and pull structured results directly. Also fronted by the OSS MCP Toolbox for Databases.

Query exported audit logs (standard SQL)

-- Who accessed PHI resources in the last 7 days?
SELECT
  protopayload_auditlog.authenticationInfo.principalEmail AS actor,
  protopayload_auditlog.methodName              AS method,
  resource.type                                 AS resource_type,
  COUNT(*)                                       AS events
FROM `PROJECT.audit_dataset.cloudaudit_googleapis_com_data_access`
WHERE timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
GROUP BY actor, method, resource_type
ORDER BY events DESC;

Same idea from the CLI

# Run against an analytics dataset (de-identified, no PHI in the query text)
bq query --use_legacy_sql=false \
    'SELECT COUNT(*) AS encounters
     FROM `PROJECT.deid_analytics.encounters`
     WHERE service_month = "2026-05"'

What it is. Business-intelligence and data-application platform — define metrics once in LookML, build governed dashboards, embed analytics into a product.

Reach for it when. You need governed, consistent BI on top of your warehouse, or you're embedding analytics into your app.

HIPAA. Covered when governed under your Google Cloud Agreement. Keep PHI out of LookML / query business logic — the model definitions are metadata, not a data store. A Looker-managed MCP server exists but is in preview; treat preview as Verify for PHI until it goes GA.

What it is. Managed stream and batch processing on Apache Beam — the workhorse for ETL/ELT, enrichment, and real-time analytics pipelines.

What it is. The event backbone — asynchronous messaging for event ingestion and delivery. Reach for it to decouple services, fan out a single event to multiple consumers (a new record triggers several downstream jobs), or ingest high-volume streams.

What it is. Manage your BigQuery SQL transformations as version-controlled code — testing, dependencies, and CI like software.

What it is. Metadata catalog for discovering and governing data assets; Knowledge Catalog is the AI-era evolution that gives agents structured + unstructured data context. Keep PHI/PII out of lineage Process.attributes and Run.attributes — lineage metadata is widely readable. A Knowledge Catalog MCP server exists for agent data context.

What it is. Visual, no-code data integration for building and managing pipelines without writing Beam code.

What it is. Managed versions of the popular OSS tools — Kafka (streaming), Spark (processing), Airflow (orchestration). Reach for them when your team already knows the tool and wants it managed.

Data-stack decision table

Enterprise AI / ML

Google renamed much of its AI stack to the Gemini Enterprise / Gemini Enterprise Agent Platform branding (formerly Vertex AI). The covered-products list uses the newer names; older names are given in parentheses where useful. The healthcare-specific Cloud Healthcare API is not here — it's section 09.

What it is. The unified platform to train, tune, deploy, and serve models and to build agents — with Model Garden access to 200+ models from Google and partners.

Reach for it when. You're serving or fine-tuning models inside your own product, or building AI agents that need enterprise governance.

HIPAA. Covered — including Generative AI on the Agent Platform, Agent Search, Gemini Enterprise, Colab Enterprise, Vertex AI Workbench instances, NotebookLM Enterprise, and AI Platform Training and Prediction. For PHI, use regional APIs and resource locations — especially with Agent Search.

What it is. OCR plus form/entity parsing — turn paper and PDFs into structured data. Reach for it to digitize intake forms, insurance documents, and lab reports into queryable fields. Covered along with Document AI Warehouse.

What it is. Transcribe audio to text across 125+ languages — clinical dictation, telehealth audio, or call-center recordings.

What it is. Synthesize natural speech in 220+ voices and 40+ languages — IVR, accessibility, and patient reminders.

What it is. Analyze images (Vision) and video (Video Intelligence) — detect objects and text, classify media, OCR scanned images. Both covered, along with the AutoML variants (Vision, Video, Natural Language, Tables, Translation).

What it is. Translate patient-facing content (Translation) and run entity / sentiment / syntax analysis on unstructured clinical text (Natural Language API). Both covered.

What it is. Build conversational chat/voice bots and AI-augmented contact-center solutions — patient-facing bots, IVR, and agent assist. Keep PHI out of intents, training phrases, and entities (these are model configuration, not a PHI store).

AI / media decision table

The badge legend

Every product in this guide carries badges. Here's exactly what they mean — rendered with the real badge styles so you recognize them throughout:

The shared-responsibility model

Google secures the infrastructure — data centers, hardware, network, and default encryption at rest. You secure what you build on top — access control, application logic, and not leaking PHI where it doesn't belong. HIPAA compliance is a split job: Google can't make you compliant, and you can't be compliant without Google's BAA.

Step zero — sign the BAA

The three HIPAA rules

The gotchas that bite HIPAA teams

From Google's own guidance: most leaks happen not in the data itself but in metadata, logs, and labels. These are the recurring "you configured it wrong" failure modes.

Encryption options

All customer content is encrypted at rest by default on Google Cloud — always on, nothing to configure. If your org needs to hold the keys, layer on the options below.

NOT on the covered list — verify before PHI

Being popular on GCP does not make a product covered. The default assumption for anything not explicitly named is not covered — check first. Notable traps:

• Firebase platform features beyond Firestore / Cloud Storage. Firestore and Cloud Storage are covered; Firebase Auth and Firebase Hosting are a separate surface. For end-user auth, use Identity Platform (the enterprise sibling of Firebase Auth) — it is covered.
• Pre-GA / preview features of any product, including new MCP servers in preview. Preview ≠ covered unless the offering says so.
• Consumer Gemini / AI Studio surfaces (as opposed to the covered enterprise Gemini products).
• Anything not explicitly named on the covered-products list below.

The covered-products reference list

The complete BAA covered-products list as published by Google, last updated 2026-05-15. The BAA also covers Google Cloud's entire infrastructure (all regions, zones, network paths, and points of presence) in addition to these.

* Data Studio is covered only if you have opted to have it governed under your Google Cloud Agreement.

Google updates this list as products join the program — treat the live page (cloud.google.com/security/compliance/hipaa) as the source of truth and re-check periodically.

Pre-flight checklist (canonical)

The compliance checklist for any new PHI-handling service — the canonical version of the list introduced in section 02:

• BAA signed and current.
• Every product in the data path is on the covered list — no preview / Pre-GA surfaces.
• IAM scoped to least privilege; service-account keys controlled (ideally none).
• Encryption decision made — default Google-managed keys vs CMEK / Cloud HSM.
• Audit logging on, exported (Cloud Storage for archive, BigQuery for analysis), and access-controlled.
• No PHI in names, labels, metadata, headers, or logs.
• VPC Service Controls perimeter considered around PHI services.
• Sensitive Data Protection (DLP) considered for discovery and de-identification.

Cloud Healthcare API

What it is. Native support for the three health-data lingua francas — FHIR, HL7v2, and DICOM — each in its own store type:

• FHIR stores — interoperable, structured patient and clinical data. The modern standard for EHR-style records and data exchange.
• HL7v2 stores — the legacy messaging feeds (ADT, ORM, ORU, etc.) emitted by existing hospital systems.
• DICOM stores — medical imaging (radiology, etc.).

Reach for it when. You're ingesting or exchanging clinical data — EHR records, lab results, imaging, or HL7v2 feeds from upstream systems — and need interoperable storage that speaks the standards.

HIPAA. Covered — a purpose-built PHI product. It is still your job to configure IAM least-privilege on datasets/stores, de-identification, regional locations, and access. Use a regional location for PHI.

Claude / MCP. No dedicated healthcare MCP server today — drive it via the gcloud CLI / its REST API, or wrap your own MCP server (deployable private on Cloud Run, inside the perimeter).

Enable the API, create a dataset + FHIR store

# Enable the Healthcare API
gcloud services enable healthcare.googleapis.com

# A dataset is a regional container — pick a region for PHI
gcloud healthcare datasets create clinical-ds \
    --location=us-central1

# A FHIR store inside the dataset (R4)
gcloud healthcare fhir-stores create patient-fhir \
    --dataset=clinical-ds \
    --location=us-central1 \
    --version=R4

POST a FHIR resource to the store's REST endpoint

curl -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/fhir+json" \
  --data '{"resourceType":"Patient","active":true}' \
  "https://healthcare.googleapis.com/v1/projects/PROJECT_ID/locations/us-central1/datasets/clinical-ds/fhirStores/patient-fhir/fhir/Patient"

For analytics, the Healthcare API can export FHIR resources to BigQuery (gcloud healthcare fhir-stores export bq) — ideally a de-identified copy (below), so the analytics dataset never holds identified PHI.

De-identification

The pattern: keep an identified PHI dataset locked down in a dedicated PHI project, and produce a de-identified copy for analytics, ML, and sharing. Two complementary tools:

• Healthcare API built-in de-identification — redacts/transforms PHI in FHIR and DICOM stores (e.g. gcloud healthcare fhir-stores deidentify produces a de-identified destination store).
• Sensitive Data Protection (DLP) (from section 06) — complements it for free-text and other stores: discover, classify, redact, mask, or tokenize. Write DLP output only to targets inside your secure environment.

# De-identify a FHIR store into a new destination store
gcloud healthcare fhir-stores deidentify patient-fhir \
    --dataset=clinical-ds \
    --location=us-central1 \
    --destination-store=projects/PROJECT_ID/locations/us-central1/datasets/deid-ds/fhirStores/patient-deid

Related health-data products

What it is. Harmonizes data from multiple healthcare sources into a longitudinal patient record for analytics and AI — unifying fragmented clinical data into a single patient view.

What it is. Run large-scale genomics and life-sciences research pipelines at scale.

Reference clinical-data flow

A defensible pipeline keeps identified PHI in a locked project and only ever exposes a de-identified copy downstream:

1. Ingest — HL7v2 feeds, FHIR resources, and DICOM imaging arrive from upstream systems.
2. Store (identified) — land in Cloud Healthcare API FHIR / HL7v2 / DICOM stores, in a regional location, inside a locked-down PHI project.
3. De-identify — produce a de-identified copy with the Healthcare API (FHIR/DICOM) and DLP (free-text and other stores).
4. Analyze / model — export the de-identified copy to BigQuery for analytics, or to Vertex AI / the Agent Platform for ML.
5. Results — dashboards, models, and insights, built without exposing identified PHI.

Data type → store / standard

Reference architecture for a PHI web app

Read this top-to-bottom as the path a request takes — from the public edge, through your app tier, down to PHI at rest — with crosscutting controls wrapping the whole PHI project.

1. Edge / ingress. External HTTPS Load Balancing terminates TLS at the edge; Cloud Armor sits in front as WAF + DDoS protection. End-user authentication is handled by Identity-Aware Proxy (for internal/employee apps) and/or Identity Platform (for patient/consumer sign-in) — never roll your own.
2. App tier. Cloud Run services, deployed private (--no-allow-unauthenticated), each running as a dedicated least-privilege service account. Secrets come from Secret Manager at runtime; outbound traffic leaves through Cloud NAT over a VPC connector; no public IPs on the services themselves.
3. Data tier. Cloud SQL (Private IP) for transactional records; Cloud Storage (uniform bucket-level access, object versioning, CMEK) for uploaded documents and exports; Cloud Healthcare API FHIR / HL7v2 / DICOM stores for clinical data. All of it lives inside one locked-down PHI project.
4. Analytics. Never analytics-query identified PHI you don't need. De-identify first — Healthcare API (FHIR/DICOM) and Sensitive Data Protection / DLP (free text) — then land the de-identified copy in BigQuery for dashboards and modeling.
5. Crosscutting. CMEK via Cloud KMS; a VPC Service Controls perimeter around the PHI services; Cloud Logging audit logs exported to Cloud Storage (archive) and BigQuery (analysis); Security Command Center + Chronicle for posture and threat detection; Assured Workloads if you need residency or personnel controls.

Layered controls

The same stack, sliced by the layer of defense each control provides:

Project & environment isolation

Put PHI workloads in dedicated prod-PHI projects under their own folder, separated from dev/test (which carry only synthetic or de-identified data). Then constrain those projects with Organization Policies so guardrails are enforced by the platform rather than relying on reviewer discipline. A few representative constraints:

• gcp.resourceLocations — restrict resources to your approved region(s), so PHI never lands outside your residency boundary.
• iam.disableServiceAccountKeyCreation — block downloaded SA keys (the most common PHI-reachable credential leak).
• storage.uniformBucketLevelAccess — force uniform bucket-level access on every new bucket.
• gcp.restrictNonCmekServices — require CMEK on the services where your posture demands customer-managed keys.

Audit logging done right

Admin Activity logs are always on, but Data Access logs (Data Read / Data Write) are not enabled by default for most services — and those are exactly the ones that prove who touched PHI. Turn them on for your PHI services in the project IAM policy's audit config, then aggregate every log into a locked archive bucket and a BigQuery dataset for analysis.

# Enable Data Access audit logs in the project IAM policy
# (auditConfigs block; apply via: gcloud projects set-iam-policy)
auditConfigs:
- service: healthcare.googleapis.com
  auditLogConfigs:
  - logType: DATA_READ
  - logType: DATA_WRITE
- service: storage.googleapis.com
  auditLogConfigs:
  - logType: DATA_READ
  - logType: DATA_WRITE

Create an aggregated sink at the folder/org level so logs flow even if a project's own config drifts:

# Sink to a locked Cloud Storage archive bucket
gcloud logging sinks create audit-archive \
    storage.googleapis.com/AUDIT_ARCHIVE_BUCKET \
    --log-filter='logName:"cloudaudit.googleapis.com"'

# (Repeat with a bigquery.googleapis.com/... destination for analysis)

Control access tightly: Logs Viewer (roles/logging.viewer) sees Admin Activity logs; reading Data Access logs requires Private Logs Viewer (roles/logging.privateLogViewer). Grant the latter to a small audit group only.

Consolidated HIPAA controls checklist

The whole guide, distilled to a pre-launch gate for the PHI environment:

• BAA signed and current, covering every product in the data path.
• PHI workloads isolated in dedicated prod-PHI projects under their own folder.
• Least-privilege IAM; no basic/primitive roles (Owner/Editor/Viewer) granted on PHI projects.
• Service-account key creation disabled (or tightly controlled and Secret-Manager-only).
• CMEK applied where your posture requires customer-held keys.
• VPC Service Controls perimeter around the PHI services.
• Private IP data tier — no public IPs on databases or services.
• Audit logging enabled (incl. Data Access), exported, and access-controlled.
• De-identification (DLP / Healthcare API) before any analytics or AI that doesn't need identified PHI.
• No PHI in names, labels, metadata, logs, headers, or CDN caches.
• Backups and a tested DR plan in place.
• Security Command Center monitoring active and reviewed.

Why IaC for HIPAA

When your entire environment is declared in code, every change is a reviewable diff, every state is reproducible, and "who changed this and when" is answered by Git history plus audit logs — exactly the evidence a compliance program wants. Your options on GCP:

• Terraform — the de facto standard, via the google / google-beta providers. Terraform itself is tooling, not a PHI data path; it provisions resources but should never carry protected data.
• Infrastructure Manager Covered — Google-managed Terraform: Google runs the apply for you, integrated with IAM and audit logging.
• Cloud Deployment Manager Covered — the native, template-based predecessor (largely legacy; prefer Terraform / Infra Manager for new work).

HIPAA-relevant CI/CD products

Managed build/test/deploy in containers. Keep PHI out of build configs, source control, and build artifacts — the pipeline is not a place for protected data.

Stores container images and packages, with a CMEK option. Never encode PHI in artifact names — metadata is visible to anyone with Reader/Viewer roles and shows up in logs. (Prefer it over the legacy Container Registry for new work.)

Governed continuous delivery to Cloud Run / GKE with promotion through dev → staging → prod and approval gates — a clean fit for change control on PHI environments.

Managed, private Git hosting inside your GCP perimeter, governed by GCP IAM — an alternative to external SaaS source control when you want the repo inside your security boundary.

Terraform examples

All HCL below targets the google provider. Wire these together and you've codified most of section 10.

provider "google" {
  project = var.project_id
  region  = "us-central1"
}

resource "google_storage_bucket" "phi_uploads" {
  name     = "phi-uploads-${var.project_id}"   # no PHI in the name
  location = "US-CENTRAL1"

  uniform_bucket_level_access = true

  versioning { enabled = true }

  encryption {
    default_kms_key_name = google_kms_crypto_key.phi.id
  }
}

resource "google_kms_key_ring" "phi" {
  name     = "phi-keyring"
  location = "us-central1"
}

resource "google_kms_crypto_key" "phi" {
  name            = "phi-bucket-key"
  key_ring        = google_kms_key_ring.phi.id
  rotation_period = "7776000s"   # 90 days
}

# Let the Cloud Storage service agent use the key
data "google_storage_project_service_account" "gcs" {}

resource "google_kms_crypto_key_iam_member" "gcs_cmek" {
  crypto_key_id = google_kms_crypto_key.phi.id
  role          = "roles/cloudkms.cryptoKeyEncrypterDecrypter"
  member        = "serviceAccount:${data.google_storage_project_service_account.gcs.email_address}"
}

resource "google_service_account" "intake_api" {
  account_id   = "intake-api"
  display_name = "Intake API runtime"
}

# Grant only what the workload needs — never roles/editor
resource "google_project_iam_member" "intake_api_sql" {
  project = var.project_id
  role    = "roles/cloudsql.client"
  member  = "serviceAccount:${google_service_account.intake_api.email}"
}

resource "google_cloud_run_v2_service" "intake_api" {
  name     = "intake-api"
  location = "us-central1"
  ingress  = "INGRESS_TRAFFIC_INTERNAL_LOAD_BALANCER"

  template {
    service_account = google_service_account.intake_api.email

    containers {
      image = "us-docker.pkg.dev/${var.project_id}/app/intake-api:latest"

      env {
        name = "DB_PASSWORD"
        value_source {
          secret_key_ref {
            secret  = "db-password"   # Secret Manager reference, not a literal
            version = "latest"
          }
        }
      }
    }
  }
}

resource "google_logging_project_sink" "audit_bq" {
  name                   = "audit-to-bq"
  destination            = "bigquery.googleapis.com/projects/${var.project_id}/datasets/audit_logs"
  filter                 = "logName:\"cloudaudit.googleapis.com\""
  unique_writer_identity = true   # creates a dedicated sink SA to grant on the dataset
}

resource "google_org_policy_policy" "no_sa_keys" {
  name   = "projects/${var.project_id}/policies/iam.disableServiceAccountKeyCreation"
  parent = "projects/${var.project_id}"

  spec {
    rules { enforce = "TRUE" }
  }
}

A note on remote state

Store Terraform state in a dedicated GCS bucket with CMEK encryption, object versioning, and locking. State can contain sensitive values (generated passwords, connection strings, IAM members), so treat the state bucket as sensitive infrastructure: lock its IAM to the CI service account and your platform team, and turn on Data Access audit logs for it. The goal is still to keep actual PHI out of variables and state entirely — the state bucket protects secrets, not patient data.

terraform {
  backend "gcs" {
    bucket = "tfstate-prod-phi"     # versioned + CMEK + locked IAM
    prefix = "infra/prod-phi"
  }
}

Observability

The GCP observability suite — all on the covered list:

Centralized audit, platform, and application logs. Export to Storage + BigQuery (section 10).

Metrics, dashboards, uptime checks, and alerting for infra and app health.

Distributed tracing for request flow and latency across microservices.

Continuous CPU/heap profiling to find production hotspots.

Managed, Prometheus-compatible metrics for teams already on Prometheus/Grafana.

Reading logs with a filter, and a reminder that the durable copy lives in your export sinks:

# Recent errors from a specific Cloud Run service
gcloud logging read \
  'resource.type="cloud_run_revision"
   AND resource.labels.service_name="intake-api"
   AND severity>=ERROR' \
  --limit=50 --freshness=1h

# Long-term retention/analysis comes from the sinks in section 10
# (Cloud Storage archive + BigQuery dataset), not the live log buffer.

Cost management

Set guardrails, then tune the big levers. Export billing to BigQuery for analysis and create budgets with threshold alerts:

# Budget with alert thresholds (enable BigQuery billing export in the console)
gcloud billing budgets create \
    --billing-account=0X0X0X-0X0X0X-0X0X0X \
    --display-name="Prod PHI monthly" \
    --budget-amount=5000USD \
    --threshold-rule=percent=0.5 \
    --threshold-rule=percent=0.9 \
    --threshold-rule=percent=1.0

Troubleshooting

Day-2 ops commands

gcloud run services \
  describe intake-api \
  --region us-central1

gcloud compute \
  instances list

gcloud run services \
  logs read intake-api \
  --region us-central1

gcloud compute ssh VM \
  --tunnel-through-iap \
  --zone us-central1-a

gcloud run services \
  update-traffic intake-api \
  --to-revisions LATEST=100 \
  --region us-central1

gcloud projects \
  get-iam-policy PROJECT_ID