GCP AI Pharmacy Infrastructure

Infrastructure for a Java-based, AI-assisted pharmacy application on Google Cloud: private GKE, Cloud SQL, Secret Manager, Cloud Build and Artifact Registry, with logging and monitoring built in.

Problem

Healthcare-adjacent data needs private networking, auditable access and no credentials in code, while AI features add bursty, compute-heavy workloads next to a conventional API.

Solution

Private GKE with Workload Identity so pods get Google service-account permissions without keys, Cloud SQL over private IP, and separate node pools so inference load cannot starve the API.

• GKE
• Cloud SQL
• Secret Manager
• Cloud Build
• Artifact Registry
• Cloud Load Balancing
• Cloud Logging
• Cloud Monitoring
• Terraform
• Helm

• Workload Identity bindings per Kubernetes namespace/ServiceAccount (`google_service_account_iam_member` with `roles/iam.workloadIdentityUser`) — no `google_service_account_key` resource anywhere in the project.
• Six Terraform modules (project APIs, network, GKE cluster, Cloud SQL, Secret Manager, delivery) wired together in a reference example; audit-log and vulnerability-scanning requirements live in one module (delivery) rather than being duplicated.
• Two GKE node pools: an always-warm API pool and a tainted, spot-priced AI pool that scales from zero, so a Kubernetes scheduling decision — not a resource request — keeps inference off the API's nodes.
• Cloud Build trigger plus immutable-tag Artifact Registry; the build-time vulnerability-scan gate is documented as pipeline config (`cloudbuild.yaml`) rather than infrastructure, since scanning itself is a project-level API feature.

• No service-account keys anywhere — Workload Identity only, confirmed by grepping for `google_service_account_key` across the project.
• No public IPs on data stores: Cloud SQL has `ipv4_enabled = false`, GKE nodes are private, and the control plane endpoint is restricted to named networks, never `0.0.0.0/0`.
• Per-secret IAM in Secret Manager — the AI workload's service account cannot read the database credential secret, and vice versa.
• Data-access audit logs (`ADMIN_READ`/`DATA_READ`/`DATA_WRITE`) enabled for both Cloud SQL and Secret Manager, and Private Google Access instead of public egress for Google APIs.

• Regional GKE control plane and `REGIONAL` (HA) Cloud SQL with point-in-time recovery and 30 daily backups retained.
• Separate node pools isolate inference spikes from the API by scheduler taint, not just resource limits; a runaway inference job can only exhaust its own pool's autoscaler ceiling.
• PodDisruptionBudgets and health probes on both workloads keep a voluntary disruption from taking out every replica at once.

• Illustrative only: the AI pool is spot-priced and scales to zero, so an idle overnight inference fleet costs nothing, while the API pool stays small and steady.
• Cloud SQL HA roughly doubles a single-zone instance's compute cost — the main fixed line item alongside the always-on API pool.

No quantified results are published for this project. Figures from client work are confidential, and this portfolio only shows numbers that can be verified or reproduced.

• Workload Identity removes a whole class of secret-handling work — no key to generate, ship, rotate or leak.
• Separate the bursty and steady workloads early: a shared node pool means either over-provisioning for spikes or risking the steady workload getting starved.
• Project-level, authoritative settings (like audit-log config) need exactly one owning module, not one per consumer, or they fight each other.