🚨 GCP Error Guide: 'VPC connector is not ready yet' — Fix Serverless VPC Access

Overview

Deploying a Cloud Run service, Cloud Function, or App Engine app that references a Serverless VPC Access connector fails when the connector is not in a healthy READY state. The literal error reads:

VPC Access connector projects/PROJECT/locations/REGION/connectors/CONNECTOR is not ready yet, or does not exist. Please visit https://cloud.google.com/functions/docs/networking/connecting-vpc to learn more.

Inspecting the connector directly often shows it stuck or errored:

state: ERROR
# or
state: CREATING   # never progressing to READY

A Serverless VPC connector is a managed pool of small instances that bridge serverless workloads to your VPC’s internal IPs. If the connector can’t be created or has fallen into an error state — usually a subnet, IP-range, or firewall problem — every deploy that references it fails, and existing traffic through it breaks.

Symptoms

• Cloud Run / Cloud Functions deploys fail with connector ... is not ready yet, or does not exist.
• A connector stuck in CREATING for a long time, or sitting in ERROR.
• Serverless workloads suddenly unable to reach internal IPs (Cloud SQL private IP, internal LBs, on-prem via VPN).
• Connector creation fails outright complaining about the subnet or IP range.
• Throughput warnings or dropped egress under load through an undersized connector.

Common Root Causes

• Subnet not a dedicated /28 — a connector needs an unused /28 subnet reserved exclusively for it; overlapping or wrong-sized ranges fail creation.
• IP range overlap — the connector’s range overlaps an existing subnet or route, blocking creation.
• Missing firewall rules — the implicit rules that let the connector reach resources (or return traffic) were removed or overridden by a deny rule.
• Connector in ERROR state — a transient platform issue or a config change left it unhealthy; it won’t self-heal and must be recreated.
• Region mismatch — the connector must be in the same region as the serverless service referencing it.
• Throughput exhaustion — an undersized connector (min/max instances too low) drops egress under load, presenting as flaky connectivity.

Diagnostic Workflow

Check the connector’s actual state — this is the first thing to confirm:

gcloud compute networks vpc-access connectors describe CONNECTOR \
  --region=REGION \
  --format='value(state, network, ipCidrRange, minThroughput, maxThroughput)'

Verify the subnet/range is a dedicated /28 with no overlap:

gcloud compute networks subnets list --filter="region:REGION" \
  --format='table(name, ipCidrRange, network)'

Confirm firewall rules allow the connector’s range to reach your resources and return traffic:

gcloud compute firewall-rules list \
  --format='table(name, direction, sourceRanges.list(), allowed[].map().firewall_rule().list(), disabled)'

Check that the serverless service references the connector in the same region:

gcloud run services describe SERVICE --region=REGION \
  --format='value(spec.template.metadata.annotations["run.googleapis.com/vpc-access-connector"])'

Example Root Cause Analysis

A Cloud Run service that reached Cloud SQL over private IP suddenly failed to deploy with VPC Access connector ... is not ready yet, and existing revisions lost database connectivity.

Diagnosis: describe showed the connector in state: ERROR. Reviewing recent changes, a network team had tightened firewall rules and added a broad egress deny that no longer excepted the connector’s /28 range. Without the return path, the connector’s health checks failed and it dropped into ERROR, from which it does not recover on its own.

Root cause: a new deny-egress firewall rule overrode the implicit allow the connector relied on, driving the connector into an unrecoverable ERROR state.

Fix: add an explicit firewall rule allowing the connector’s /28 range the egress it needs (and the corresponding ingress on the targets), then recreate the connector since an ERROR connector won’t self-heal, and re-point the service at the fresh connector. Deploys and database connectivity were restored.

Prevention Best Practices

• Give each connector a dedicated, unused /28 subnet and document it so nothing else claims the range.
• When adding deny firewall rules, explicitly except the connector’s IP range for both egress and the targets’ ingress.
• Keep the connector in the same region as every serverless service that uses it.
• Size the connector’s min/max throughput for peak egress; monitor for throughput exhaustion rather than discovering it as flaky connectivity.
• Treat an ERROR-state connector as disposable — recreate it rather than waiting for a self-heal that won’t come.
• Use infrastructure-as-code for connectors and their firewall exceptions so a network change can’t silently orphan them.

Quick Command Reference

# Check connector state and config
gcloud compute networks vpc-access connectors describe CONNECTOR --region=REGION \
  --format='value(state, ipCidrRange, minThroughput, maxThroughput)'

# List subnets to verify a dedicated /28
gcloud compute networks subnets list --filter="region:REGION" \
  --format='table(name, ipCidrRange, network)'

# Recreate an ERROR-state connector
gcloud compute networks vpc-access connectors delete CONNECTOR --region=REGION
gcloud compute networks vpc-access connectors create CONNECTOR --region=REGION \
  --subnet=SUBNET --min-instances=2 --max-instances=10

# Confirm the service references it in the same region
gcloud run services describe SERVICE --region=REGION \
  --format='value(spec.template.metadata.annotations)'

Conclusion

Serverless VPC Access connector is not ready yet means the connector that bridges your serverless workloads to the VPC is not in a healthy READY state — almost always a dedicated-/28, IP-range, or firewall problem, and sometimes an ERROR state it can’t recover from. Confirm the connector’s state first, verify it has an exclusive /28 with no overlap and the firewall rules to reach and return traffic, and keep it in the same region as the service. Because an ERROR connector won’t self-heal, fix the underlying network issue and recreate it rather than waiting.