Cloud Run
Cloud Run runs containers as managed services that scale with requests, down to zero. The GCP platform runs three Cloud Run services: the web application's single-page front end (SPA), the ETL trigger that starts Spark batches, and an optional notifier for Security Command Center findings.
What it does
A Cloud Run service runs a container image under a service identity; each deployment creates an immutable revision, and traffic moves to a revision once it is ready. Ingress settings decide who can reach the service: everyone, internal traffic only, or internal traffic plus Google's load balancers. Invoker IAM decides whether a caller needs roles/run.invoker. Direct VPC egress gives the instances addresses in a subnet. Instances scale between a minimum and a maximum and can bill CPU only while serving.
How BuiltForProd uses it
The organization policy run.allowedIngress allows only internal and load-balancer ingress on every project, so no Cloud Run service on the platform can be public on its own.
| Service | Repository | Ingress | Identity |
|---|---|---|---|
<prefix>-frontend (SPA) | Web App Blueprint | Internal and load balancing | sa-acme-frontend, no roles |
<prefix>-etl-trigger | Data and ETL Blueprint | Internal only | sa-<prefix>-etltrig |
acme-scc-notifier (optional) | GCP Enterprise Baseline | Internal only | sa-acme-scc-notifier |
The SPA. nginx serving the built front end on port 8080, behind the SPA's load balancer and Cloud CDN through a serverless NEG. The run.app URL is disabled and invoker IAM is off, so the load balancer is the only way in. It scales from min_instances (0) to max_instances (10), one CPU and 256 MiB, 80 concurrent requests per instance, CPU billed only while serving. The infrastructure creates the service once on a placeholder image; the code pipeline (scripts/deploy-frontend.sh) deploys every revision with gcloud run services update, checks that the new revision is ready and serving the image, and records the tag. Its identity holds roles/run.developer on this service only.
The ETL trigger. Receives Cloud Storage events from Eventarc and submits Dataproc Serverless batches. It allows no unauthenticated calls, handles one event per instance with a 300-second timeout, scales to at most spark_max_concurrent_batches instances, and sends all egress through the stage's data subnet by direct VPC egress, with Google APIs over Private Google Access. Its identity holds roles/dataproc.editor and roles/logging.logWriter, read access to the raw bucket and permission to act as the Spark identity.
The image tag lives in Parameter Manager. Artifact Registry tags are immutable, so a service cannot follow a moving tag. Each blueprint service has a Parameter Manager parameter, frontend--image-tag or etl-trigger--image-tag, created once by the infrastructure and then written only by the code pipeline after each deploy. The infrastructure reads it back to build the image reference and ignores image changes on the service, so a plan always shows the image that runs and never rolls a deployment back.
The notifier exists only with enable_scc_notifier = true in security.hcl. A push subscription on the alerts topic calls it with an OIDC token; it logs every finding and can remove public bindings from buckets; see Security Command Center. Its image comes from the Baseline's notifier-image.yml workflow.
Terms you will see
| Term | Meaning |
|---|---|
| Revision | An immutable deployment of a service; traffic moves when it is ready. |
| Internal and load balancing | Ingress that admits only the VPC and Google's load balancers. |
| Direct VPC egress | Instances with addresses in a VPC subnet, sending traffic through it. |
frontend--image-tag | The parameter that records the SPA image a stage runs. |
| Placeholder image | What the SPA runs until the pipeline has deployed a real tag. |
Where to read more
- GCP Web App Blueprint overview and the GCP Data and ETL Blueprint overview.
- Cloud Load Balancing for the front end's entry point.
- Parameter Manager for the recorded image tags.