Secure Cloud Run to Cloud SQL via VPC Connector: Minimal Architecture and Operational Checklist

Problem Statement

When deploying stateless web services on Cloud Run, developers often need to access a relational database such as Cloud SQL. Exposing the database to a public IP is undesirable for security reasons. The challenge is to enable a fully managed Cloud Run service to reach a private Cloud SQL instance without opening any public ingress paths, while keeping the deployment as lightweight as possible.

Requirements

• Cloud Run (fully managed) in a specific region.
• Cloud SQL instance (PostgreSQL, MySQL, or SQL Server) with a private IP address.
• Serverless VPC Access connector matching the Cloud Run region.
• Dedicated service account with:
  • iam.serviceAccountUser on the connector.
  • cloudsql.client on the Cloud SQL instance.
  • logging.logWriter for Cloud Run logs.
• Firewall rule allowing egress from the connector subnet to the Cloud SQL instance’s private IP.
• Cloud SQL Auth Proxy binary (or sidecar) bundled with the application image.

Smallest Viable Design

The minimal architecture consists of four components:

1. Cloud Run Service – runs the application container.
2. Serverless VPC Access Connector – provides a private IP path into the VPC.
3. Cloud SQL Instance – holds the data behind a private IP.
4. Cloud SQL Auth Proxy – forwards encrypted connections from the service to the instance.

Dockerfile Example

# Use a minimal base image
FROM gcr.io/distroless/base

# Install Cloud SQL Auth Proxy binary
COPY cloud_sql_proxy /usr/local/bin/cloud_sql_proxy

# Copy application code
COPY app /app

# Expose application port
EXPOSE 8080

# Start proxy and application
CMD ["sh", "-c", "cloud_sql_proxy -instances=my-project:us-central1:my-instance=tcp:5432 & sleep 1 && exec /app/server"]

Deploy Command

gcloud run deploy my-service \
  --image gcr.io/my-project/my-image \
  --platform managed \
  --region us-central1 \
  --vpc-connector my-connector \
  --service-account [contact removed] \
  --port 8080 \
  --memory 512Mi \
  --allow-unauthenticated

Replace my-project, my-instance, and my-connector with your actual identifiers.

Trust & Data Boundaries

Defining clear boundaries prevents accidental data exposure:

• Service Account Scope – the service account is the only identity that can call the Cloud SQL Auth Proxy and access the database. It should have the least privilege necessary.
• Firewall Rules – restrict egress from the connector’s subnet to the Cloud SQL instance’s private IP only. Example rule:

  gcloud compute firewall-rules create allow-cloudsql-connector \
    --direction=EGRESS \
    --priority=1000 \
    --network=default \
    --destination-range=10.128.0.0/20 \
    --source-ranges=10.128.0.0/20 \
    --action=ALLOW \
    --rules=tcp:5432
  

• VPC Connector Tagging – apply a network tag to the connector and reference that tag in the firewall rule to avoid accidental changes.

Operational Checks

Continuous health verification keeps the service reliable:

• Cloud Run Uptime Check – create an uptime check in Cloud Monitoring that pings the service’s HTTP endpoint every minute.
• Connection Metrics – set a metric alert on cloudsql.googleapis.com/connection/failed to detect authentication or network failures.
• Connector Health – query the connector status:

  gcloud compute networks vpc-access connectors describe my-connector \
    --region us-central1
  

  The state field should be READY.
• Cloud Logging – enable logs for the Cloud SQL Auth Proxy and Cloud Run service. Look for proxy: connection established entries.
• IAM Verification – periodically impersonate the service account and list Cloud SQL instances to confirm permissions:

  gcloud sql instances list --impersonate-service-account [contact removed]
  

Failure Modes & Detection

Failure Mode	Cause	Detection
Connector misconfiguration	Wrong region, subnet, or missing connector	Connector status FAILED or absence in Cloud Run description
Firewall rule change	Blocking traffic to Cloud SQL	Failed connection metric spikes; logs show connection refused
IAM permission loss	Service account revoked cloudsql.client or iam.serviceAccountUser	Proxy logs show authentication errors; Cloud Run health check fails
Cloud SQL instance outage	Instance stopped or network issue	Connection failures; Cloud SQL instance health in Cloud Console
Proxy binary missing	Image build error or missing binary	Application startup logs; container crashes

When to Re‑architect

The minimal design works well for low‑to‑medium concurrency workloads and simple request‑response patterns. Consider alternative patterns when:

• Concurrency exceeds 1000 – Cloud Run’s default concurrency may throttle performance; Cloud Run Jobs or Cloud Run on GKE can handle higher parallelism.
• Batch or background jobs are required – Cloud Run Jobs or Cloud Run on GKE with a dedicated worker pool provide better control.
• Hybrid or on‑prem integration is needed – a VPC‑to‑on‑prem VPN or Cloud Interconnect may be required; Cloud Run on GKE can use internal services more flexibly.
• Zero‑downtime migrations or multi‑region deployment – Cloud Run on GKE with Istio or Cloud Run Jobs can orchestrate traffic shifting.

Practical Verification Checklist

1. Run gcloud run services describe my-service --platform managed --region us-central1 and confirm the vpcAccessConnector matches my-connector.
2. Check gcloud compute networks vpc-access connectors describe my-connector --region us-central1 – state should be READY.
3. Verify firewall rule allows traffic from 10.128.0.0/20 to the Cloud SQL instance’s private IP.
4. Confirm Cloud SQL logs show client_ip entries from the connector’s subnet.
5. Set up Cloud Monitoring alerts for cloudsql.googleapis.com/connection/failed and Cloud Run uptime checks.
6. Impersonate the service account and list Cloud SQL instances to ensure IAM is intact.

Following this architecture note ensures a minimal, secure, and operationally sound connection between Cloud Run and Cloud SQL, while clearly defining when the design should evolve.