Cloud Function Not Connected to VPC: Why It Matters and How to Fix It

Cloud Functions are great for gluing systems together without managing servers. The downside is that, by default, they run in a Google-managed network with no direct line into your private VPC. If a function needs to talk to a Cloud SQL instance over a private IP, a Memorystore Redis cluster, or an internal service running on a Compute Engine VM, that traffic either fails or gets routed over the public internet. Serverless VPC Access fixes both problems by giving the function a path into your VPC.

This check, functions_novpcaccess, looks for any Cloud Function that has no VPC connector attached. It is a signal that the function is either operating in an over-exposed way or relying on public endpoints it should not need.

---

What this check detects

Lensix inspects each Cloud Function in your GCP projects and reports any function where the VPC connector setting is empty. In practice that means the function has no vpcConnector field set and is not using Serverless VPC Access.

A function in this state can only reach resources that are exposed on public IP addresses. It cannot reach anything that lives behind a private IP inside your VPC, and any outbound traffic leaves through Google's default egress path rather than through your network where you control routing and firewalls.

---

Why it matters

The risk here is twofold: data exposure and loss of network control.

Private resources get reached over the public internet

Say your function needs to query a Cloud SQL database. Without a VPC connector, you are pushed toward enabling a public IP on that database and connecting over the internet. That public IP is now a target. Even with authorized networks and SSL enforced, you have widened the attack surface of a system that should never have been reachable from outside your network in the first place.

You lose firewall and egress controls

When function traffic flows through your VPC, it is subject to your firewall rules, VPC Service Controls perimeters, and egress routing. You can force outbound traffic through Cloud NAT with a known static IP, which is often required when calling third-party APIs that allowlist IPs. Without a connector, you give all of that up. Function egress comes from a shifting pool of Google-owned addresses you cannot pin down.

Compliance implications

Frameworks like PCI DSS and HIPAA expect sensitive workloads to operate inside controlled network boundaries. A serverless function that touches cardholder data or PHI but routes around your VPC controls is hard to defend in an audit.

---

How to fix it

Fixing this is a two-step process: create a Serverless VPC Access connector, then attach it to the function.

Step 1: Enable the API

gcloud services enable vpcaccess.googleapis.com --project=YOUR_PROJECT_ID

Step 2: Create a connector

Pick an unused /28 CIDR range that does not overlap with any existing subnet in your VPC. The connector needs that range exclusively.

gcloud compute networks vpc-access connectors create my-connector \
  --project=YOUR_PROJECT_ID \
  --region=us-central1 \
  --network=default \
  --range=10.8.0.0/28 \
  --min-instances=2 \
  --max-instances=3 \
  --machine-type=e2-micro

Step 3: Attach the connector to your function

For a Gen 2 function:

gcloud functions deploy my-function \
  --gen2 \
  --region=us-central1 \
  --vpc-connector=my-connector \
  --egress-settings=private-ranges-only

The --egress-settings flag controls what goes through the connector:

• private-ranges-only routes only requests to RFC 1918 private IPs through the VPC. Public traffic still uses the default path.
• all-traffic routes everything through the VPC, which is what you want if you need a static egress IP via Cloud NAT or full firewall control.

Console steps

If you prefer the console:

1. Open the function in Cloud Functions and click Edit.
2. Expand Runtime, build, connections and security settings.
3. Under the Connections tab, set Egress settings and choose your VPC connector (or create one inline).
4. Click Next, then Deploy.

Terraform

If you manage infrastructure as code, define both the connector and the function binding:

resource "google_vpc_access_connector" "connector" {
  name          = "my-connector"
  region        = "us-central1"
  network       = "default"
  ip_cidr_range = "10.8.0.0/28"
  min_instances = 2
  max_instances = 3
}

resource "google_cloudfunctions2_function" "fn" {
  name     = "my-function"
  location = "us-central1"

  service_config {
    vpc_connector                 = google_vpc_access_connector.connector.id
    vpc_connector_egress_settings = "PRIVATE_RANGES_ONLY"
    # ... other service config
  }
  # ... build config
}

---

How to prevent it from happening again

One-off fixes do not hold up. New functions get deployed by different teams, and the default is no connector. Put a gate in front of deployments.

Policy as code with Terraform

If you use Terraform, an OPA or Conftest policy can reject any function resource that lacks a connector:

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "google_cloudfunctions2_function"
  not resource.change.after.service_config[_].vpc_connector
  msg := sprintf("Function '%s' has no VPC connector", [resource.change.after.name])
}

Organization policy

GCP does not have a built-in org policy constraint that mandates a VPC connector, so enforcement is best done in CI/CD plus continuous scanning. Run the Lensix functions_novpcaccess check on a schedule so any function that slips through the deployment gate is caught and surfaced quickly.

---

Best practices

• Use private IPs for backend services. Once a connector is in place, disable public IPs on Cloud SQL and other backends and connect over the private path.
• Set egress deliberately. Use private-ranges-only for functions that only touch internal resources, and all-traffic when you need full egress control or a static NAT IP.
• Add VPC firewall egress rules. Once function traffic enters your VPC, write deny-by-default egress rules so a compromised function cannot reach arbitrary destinations.
• Combine with VPC Service Controls. For functions handling sensitive data, place the resources inside a service perimeter to block data movement outside the boundary.
• Right-size the connector. Match min-instances and machine-type to actual throughput. Oversized connectors waste money, undersized ones throttle traffic under load.
• Audit regularly. Connectors and functions drift over time. Continuous scanning keeps the gap between intended and actual state from widening.

Connecting your Cloud Functions to a VPC is a small configuration change with outsized security value. It pulls serverless traffic back under the same network controls you already apply to the rest of your infrastructure, and it removes the temptation to expose private backends to the public internet.