13.2 Cloud Run CPU, Private Egress, and Secrets

CPU Allocation Models: Throttling vs. Always-Allocated

Cloud Run provides two distinct CPU allocation models that dictate how the virtual CPU behaves throughout the container lifecycle:

## Model 1: CPU allocated only during request processing (default)
gcloud run services update order-service --cpu-throttling --region=us-central1

## Model 2: CPU always allocated (continuous execution)
gcloud run services update order-service --no-cpu-throttling --region=us-central1

Exam Trap: A common exam scenario involves an application that returns an HTTP 200 OK to a client and attempts to process data or write analytics asynchronously on a background worker thread. With default CPU throttling, Cloud Run freezes the CPU milliseconds after the HTTP response is sent. The background thread halts mid-execution until another request happens to hit that same container instance! For best-effort between-request work, choose instance-based CPU allocation. For invoice generation or other required business effects, enqueue durable work and acknowledge only after completion; CPU allocation alone cannot guarantee completion.

---

Networking: Ingress & Egress Architectures

Cloud Run microservices operate within a multi-tenant Google frontend architecture. Securing ingress paths and controlling outbound egress routing are essential developer requirements.

Ingress Controls

Ingress controls restrict the network origins from which requests can reach your Cloud Run service:

Using internal-and-cloud-load-balancing is an enterprise best practice: it restricts external traffic to supported load-balancer ingress while still allowing recognized internal access to the default URL. IAM remains separate. Route public traffic through a Cloud Load Balancer equipped with Cloud Armor (DDoS mitigation, WAF rules) and Cloud CDN caching.

Egress Controls: Direct VPC Egress vs. Serverless VPC Access

To communicate privately with internal VPC workloads (such as private Cloud SQL instances, Memorystore Redis caches, internal GKE services, or on-premises servers via Cloud Interconnect), Cloud Run must route egress traffic into your VPC.

1. Serverless VPC Access Connector (--vpc-connector):
   • Requires creating a dedicated /28 CIDR connector subnet.
   • Provisions Google-managed connector VMs (e2-micro or f1-micro) inside your project.
   • Bandwidth throughput is constrained by connector VM instance count and introduces billing overhead for idle connector VMs.
2. Direct VPC Egress (--network and --subnet):
   • Attaches subnetwork interfaces directly to Cloud Run container instances without intermediary connector VMs.
   • Offers higher network throughput, sub-millisecond latency improvements, and zero VM maintenance costs.
   • Modern standard for Cloud Run VPC connectivity.

Routing All Egress via Cloud NAT for Static Public IPs

By default, Cloud Run egress to the public internet uses dynamic Google IP pools. If an external third-party API requires IP whitelisting, you must force all outbound traffic through your VPC:

1. Configure Direct VPC egress: --network=prod-vpc --subnet=backend-subnet.
2. Set --vpc-egress=all-traffic (routes RFC 1918 private ranges AND public internet ranges through the VPC subnet).
3. Attach a Cloud NAT gateway with a reserved Static Cloud External IP to the VPC subnet.
4. All outbound calls to third-party endpoints will originate deterministically from the reserved Static IP address.

---

Environment Variables, Secret Manager & Volume Mounts

Applications require externalized configuration and sensitive credentials at runtime.

Environment Variables & Secret Manager Integration

## Injecting plain environment variables and Secret Manager secrets
gcloud run services update order-service \
    --set-env-vars=FEATURE_FLAG_NEW_CHECKOUT=true,CACHE_TTL=3600 \
    --set-secrets=DATABASE_PASSWORD=order-db-secret:latest,STRIPE_KEY=stripe-api-token:2

Secret Injection Trade-offs:

• Environment Variables (--set-secrets=ENV_VAR=SECRET:VERSION): Fast and convenient. However, secrets injected as environment variables are evaluated only during container startup. If you reference latest and update the secret version in Secret Manager, running instances continue using the old version until a new revision is deployed or instances restart.
• Volume Mounts (--set-secrets=/secrets/api-key=SECRET:VERSION): Mounts the secret as a read-only file at the specified filesystem path. Applications reading from the file system can detect updated secret versions without restarting containers.

Cloud Storage FUSE Mounts & In-Memory Volumes

Cloud Run supports second-generation execution environments that allow mounting Cloud Storage buckets and temporary memory filesystems:

• Cloud Storage FUSE Mounts: Mounts a Cloud Storage bucket directly into the container filesystem namespace (--add-volume=name=docs-vol,type=cloud-storage,bucket=corp-docs-bucket and --add-volume-mount=volume=docs-vol,mount-path=/mnt/docs). Ideal for reading static assets, machine learning model weights, or large batch files using standard POSIX file I/O.
• In-Memory Volumes (emptyDir): Mounts an ephemeral RAM-backed filesystem (medium: Memory). Writing to an in-memory volume consumes container RAM but provides ultra-high IOPS for temporary scratch files, image transforms, or ephemeral caches without persisting data to disk.

---

Revision Tagging & Targeted Routing

Changes to the revision template create a new immutable Revision; traffic-only or service-level changes need not create one. Cloud Run allows assigning traffic tags to specific revisions using --tag:

## Deploying a new revision with a dedicated URL tag
gcloud run deploy order-service \
    --image=us-central1-docker.pkg.dev/my-project/app-repo/order-service:v2.2.0 \
    --tag=canary \
    --no-traffic

Assigning --tag=canary generates a unique, deterministic URL: https://canary---order-service-67abcde-uc.a.run.app

This architecture allows internal integration test suites, QA teams, or automated synthetic monitors to send live HTTP requests directly to the new container revision while 100% of public user traffic remains safely pinned to the stable production revision.

Official references checked October 18, 2026: Google Cloud 1.