This chapter covers the Cloud Run VPC Connector, a critical component for securely connecting serverless workloads to private VPC resources. For the ACE exam, questions about VPC connectors appear in roughly 5-8% of scenarios within the Security and Networking domains, often testing your ability to choose the right connectivity method for Cloud Run. You will learn the connector's internal mechanism, configuration defaults, and how it differs from alternatives like Cloud NAT and Private Service Connect.
Jump to a section
Imagine a company building on a public park (the internet) but needing secure access to a private office building (the VPC). The company installs a private bridge (the VPC connector) that connects the park directly to the office's secure entrance. Without the bridge, employees in the park would have to cross a busy public road (the internet) and enter through a guarded gate (a Cloud NAT or public IP), exposing their activities to traffic and requiring special passes. With the bridge, they walk directly into the office's private lobby, unseen by outsiders. The bridge has a tollbooth (the connector's routing logic) that logs every crossing and ensures only authorized park visitors (Cloud Run requests) can use it. If too many people try to cross at once, the tollbooth queues them (connector scaling limits). The bridge is built to a specific width (bandwidth) and can be expanded by adding lanes (increasing connector capacity). Importantly, the bridge only works one way: visitors from the park can enter the office, but people in the office cannot use the bridge to go to the park—that requires a separate route (Serverless VPC Access for egress).
A Cloud Run VPC Connector is a Google Cloud resource that enables a Cloud Run service to send outbound requests to resources inside a VPC network without traversing the public internet. It is a managed component based on the Serverless VPC Access feature. The connector acts as a bridge between the serverless environment and your VPC, allowing Cloud Run instances to reach internal IP addresses, such as those of Compute Engine VMs, Cloud SQL instances, or on-premises networks connected via Cloud VPN or Cloud Interconnect.
Why It Exists
By default, Cloud Run services run in a Google-managed environment that has no direct network path to your VPC. Outbound traffic from Cloud Run goes through the internet. To access private resources, you need a mechanism that routes traffic from the serverless platform into your VPC. The VPC connector provides this by creating a dedicated network path using a set of managed VMs (the connector instances) that run in your VPC and handle traffic forwarding.
How It Works Internally
The VPC connector uses a set of Compute Engine instances (managed by Google) that run in your VPC subnet. When a Cloud Run instance sends a packet to a private IP (e.g., 10.0.0.5), the packet is intercepted by the serverless infrastructure and forwarded to one of the connector's VMs. The VM then routes the packet into the VPC using standard networking rules. The connector uses source network address translation (SNAT) so that responses are returned to the connector, which then forwards them back to the Cloud Run instance. The connector handles both TCP and UDP traffic, but not ICMP.
Key Components, Values, and Defaults
Connector Type: There are two types: dedicated (for high throughput) and shared (for cost savings). The ACE exam focuses on the default dedicated type.
Machine Types: The connector is backed by Compute Engine instances. You choose a machine type that determines throughput and cost. Options include e2-micro (lowest throughput) up to e2-standard-8 (highest). The default is e2-micro. Throughput scales linearly with machine size: e2-micro offers ~50 Mbps, e2-standard-8 offers ~800 Mbps.
Scaling: The connector can scale from a minimum of 2 instances to a maximum of 10 instances (default min=2, max=10). Each instance can handle up to 100 concurrent connections. The connector scales based on CPU utilization and number of connections.
Subnet: You must specify a subnet in your VPC where the connector's VMs will be placed. The subnet must have enough IP addresses for the maximum number of instances (e.g., /28 subnet for up to 10 instances). The connector's VMs use IPs from this subnet.
Timeouts: The connector has a connection idle timeout of 10 minutes (default). If no traffic flows for 10 minutes, the connection is closed.
Port Range: The connector uses ephemeral ports in the range 1024-65535 for SNAT.
Configuration and Verification Commands
To create a VPC connector using gcloud:
gcloud compute networks vpc-access connectors create CONNECTOR_NAME \
--region=REGION \
--network=VPC_NETWORK \
--range=IP_RANGE # e.g., 10.8.0.0/28To update a connector (only machine type and scaling can be changed after creation):
gcloud compute networks vpc-access connectors update CONNECTOR_NAME \
--machine-type=e2-standard-4 \
--min-instances=3 \
--max-instances=8To verify the connector status:
gcloud compute networks vpc-access connectors describe CONNECTOR_NAMEOutput includes state (READY, CREATING, DELETING, ERROR), machineType, minInstances, maxInstances, network, and subnet.
Interaction with Related Technologies
Cloud Run: To use the connector, you specify it in the Cloud Run service configuration via the --vpc-connector flag or in the YAML under spec.template.spec.vpcAccess.connector.
VPC Firewall Rules: The connector's VMs are subject to VPC firewall rules. You must allow ingress traffic from the connector's subnet to your private resources, and allow egress from those resources to the connector's subnet for return traffic.
Cloud NAT: If you need outbound internet access from Cloud Run (e.g., for API calls) while also using a VPC connector, you can combine them. The connector handles private IP destinations; Cloud NAT handles public IP destinations. The connector does not provide NAT for internet traffic.
Private Google Access: If your Cloud Run service needs to reach Google APIs (e.g., Cloud Storage), you can use Private Google Access on the VPC subnet where the connector resides, allowing traffic to Google APIs to stay within Google's network.
Shared VPC: The connector can be deployed in a Shared VPC environment. You must create the connector in the host project and grant the appropriate IAM roles (compute.networkUser on the host project) to the service project's Cloud Run service account.
Performance and Limits
Throughput: As mentioned, scales with machine type. For most applications, e2-micro or e2-small suffices. For high-throughput workloads (e.g., streaming data), use e2-standard-4 or higher.
Latency: The connector adds approximately 1-2 ms of latency per packet due to the extra hop.
Concurrent Connections: Each connector instance supports up to 100 concurrent connections. With max instances of 10, total concurrent connections = 1000.
Quota: There is a project-level quota of 10 connectors per region by default, but you can request an increase.
Common Misconfigurations
Insufficient Subnet Size: If the subnet does not have enough IPs for the maximum instances, the connector creation fails. Always use a /28 or larger.
Missing Firewall Rules: If firewall rules block traffic between the connector's subnet and your resources, connections time out.
Wrong Region: The connector must be in the same region as the Cloud Run service. Cross-region is not supported.
Using a Connector for Ingress: The VPC connector only handles egress from Cloud Run to the VPC. It does not allow ingress from the VPC to Cloud Run. For that, use an Internal Load Balancer with Serverless NEG.
Create VPC subnet for connector
Before creating a connector, you need a subnet in your VPC with a CIDR range large enough to accommodate the connector's VMs. A /28 subnet (16 IPs) is recommended for up to 10 instances. This subnet should not overlap with any other subnet in the VPC or with on-premises ranges. The subnet must be in the same region as the Cloud Run service. Use `gcloud compute networks subnets create` to create it. For example: `gcloud compute networks subnets create connector-subnet --network=my-vpc --region=us-central1 --range=10.8.0.0/28`.
Create the VPC connector
Use the `gcloud compute networks vpc-access connectors create` command. Specify the connector name, region, network, and the subnet range (or subnet name). You can optionally set the machine type, minimum and maximum instances. The command triggers the creation of managed VMs in the subnet. The process takes about 5-10 minutes. Example: `gcloud compute networks vpc-access connectors create my-connector --region=us-central1 --network=my-vpc --range=10.8.0.0/28 --machine-type=e2-micro --min-instances=2 --max-instances=10`.
Verify connector readiness
Check the connector state using `gcloud compute networks vpc-access connectors describe my-connector`. The state should be 'READY'. If it is 'CREATING', wait and retry. If it is 'ERROR', check the logs in Google Cloud Console under 'Serverless VPC Access' for details. Common errors include insufficient IP space or quota limits. The describe command also shows the machine type, instance counts, and the subnet being used.
Configure Cloud Run to use connector
When deploying or updating a Cloud Run service, specify the VPC connector. Use the `--vpc-connector` flag with the connector name (full resource name or just name if in same project and region). Optionally, set `--vpc-egress` to specify which traffic goes through the connector: 'all-traffic' (default) sends all outbound traffic through the connector, 'private-ranges-only' sends only traffic to private IPs (RFC 1918 and non-RFC 1918 private ranges) through the connector, while public traffic goes directly to the internet. Example: `gcloud run deploy my-service --image gcr.io/my-project/my-image --region us-central1 --vpc-connector my-connector --vpc-egress private-ranges-only`.
Test connectivity to private resources
After deployment, test that the Cloud Run service can reach a private IP (e.g., a Compute Engine VM with internal IP 10.0.0.5). You can do this by having the Cloud Run service make an HTTP request to that IP. Monitor the connector's metrics in Cloud Monitoring (e.g., 'connector/sent_bytes_count', 'connector/active_connections'). If connectivity fails, check firewall rules: ensure ingress to the target resource from the connector's subnet (10.8.0.0/28) is allowed, and egress from the target back to the connector's subnet is allowed. Also verify that the target resource's firewall does not block the connector's source IP range.
Enterprise Scenario 1: Secure Database Access
A financial services company runs a Cloud Run-based API that needs to query a Cloud SQL PostgreSQL database. The database is configured with a private IP and is only accessible within the VPC. Without a VPC connector, the API would have to use Cloud SQL's public IP with authorized networks, which is insecure. The company deploys a VPC connector in the same region as Cloud SQL and configures the Cloud Run service to use the connector with --vpc-egress private-ranges-only. This ensures that only database traffic goes through the VPC, while external API calls (e.g., to Stripe) go directly to the internet. They set the connector machine type to e2-small because the API handles ~50 concurrent requests. They also configure firewall rules to allow traffic from the connector's subnet (10.8.0.0/28) to the Cloud SQL private IP. In production, they monitor connector CPU utilization and increase max instances to 5 during peak hours.
Enterprise Scenario 2: Hybrid Cloud Workload
A retail company has an on-premises data center connected to Google Cloud via Cloud VPN. Their Cloud Run service needs to query an on-premises inventory database at 192.168.1.10. They create a VPC connector in the same region as Cloud Run, and ensure the VPC has a route to the on-premises network via the VPN tunnel. They configure Cloud Run with --vpc-egress all-traffic so that all outbound traffic goes through the connector, including traffic to the on-premises IP. The connector's VMs route the traffic via the VPC's route table. They set the connector to e2-standard-2 to handle the higher throughput. They also configure firewall rules to allow traffic from the connector's subnet to the on-premises IP range. During a Black Friday sale, they notice increased latency; they scale up the connector by increasing max instances to 8 and upgrading to e2-standard-4.
Common Pitfalls
Subnet Exhaustion: A startup used a /29 subnet (8 IPs) but set max instances to 10. The connector creation failed because the subnet didn't have enough IPs. They had to delete and recreate with a /28.
Firewall Misconfiguration: A developer forgot to allow egress from the target VM to the connector's subnet. The Cloud Run service could initiate connections, but responses were dropped, causing timeouts. The fix was adding an egress rule allowing traffic from the VM to the connector's subnet.
Wrong Region: A team created the connector in us-east1 but deployed Cloud Run in us-central1. The connector was not visible to the service, leading to deployment errors. They had to recreate the connector in us-central1.
ACE Exam Focus: Cloud Run VPC Connector (Objective 5.2)
The ACE exam tests your ability to choose the correct networking solution for serverless workloads. For VPC connector questions, expect scenario-based items where you must decide between VPC connector, Cloud NAT, Private Service Connect, or direct VPC peering. Key areas:
When to use a VPC connector: The exam will present a scenario where a Cloud Run service needs to access a private IP (e.g., Cloud SQL private IP, Compute Engine internal IP). The correct answer is the VPC connector. Wrong answers include Cloud NAT (which provides internet access, not private IP access) or Private Service Connect (which is for accessing Google-managed services privately).
VPC egress setting: The exam tests the difference between all-traffic and private-ranges-only. A common trap: a candidate chooses all-traffic when the service only needs private access, increasing cost and latency. The correct choice is private-ranges-only if the service also needs internet access directly.
Connector placement: The connector must be in the same region as the Cloud Run service. A wrong answer might suggest any region or the same zone.
Subnet requirements: The subnet must have a CIDR range large enough for the maximum instances. The exam may ask for the minimum subnet size for a given max instances (e.g., max=10 requires at least /28).
Firewall rules: You need to allow ingress from the connector's subnet to your resources, and egress back. A distractor might say 'no firewall changes needed' or 'only ingress rules needed'.
Shared VPC: If using a Shared VPC, the connector must be created in the host project, and the service project's Cloud Run service account needs compute.networkUser role on the host project. The exam may test this with a multi-project scenario.
Limits: Default max connectors per region is 10. Machine types affect throughput. The exam may ask which machine type to choose for a given throughput requirement.
Combination with Cloud NAT: If Cloud Run needs both private IP access and internet access, you can use a VPC connector for private traffic and Cloud NAT for internet traffic. The exam may present a scenario where both are needed.
Elimination Strategy: If the question mentions 'private IP' or 'VPC resources', eliminate options that provide internet access (Cloud NAT, public IP). If it mentions 'serverless', eliminate options that require VMs (e.g., VPC peering with a VM proxy). If it mentions 'ingress from VPC to Cloud Run', eliminate VPC connector (it only does egress) and look for Internal Load Balancer with Serverless NEG.
VPC Connector enables Cloud Run to send outbound traffic to private IPs in a VPC.
The connector is regional and must be in the same region as the Cloud Run service.
Default machine type is e2-micro; throughput scales with machine size.
Minimum subnet size for max instances of 10 is /28 (16 IPs).
Use --vpc-egress private-ranges-only to only send private IP traffic through the connector.
Firewall rules must allow traffic between the connector's subnet and target resources.
Connector does not support ingress from VPC to Cloud Run.
Maximum 10 connectors per region by default (quota can be increased).
In Shared VPC, create connector in host project and grant compute.networkUser to service project.
Combine with Cloud NAT if both private and internet access are needed.
These come up on the exam all the time. Here's how to tell them apart.
VPC Connector
Enables access to private IPs in VPC
Does not provide internet access (unless combined with Cloud NAT)
Adds 1-2 ms latency
Requires a subnet for connector VMs
Best for accessing internal resources like Cloud SQL private IP
Cloud NAT
Enables outbound internet access with a static IP
Does not provide access to private IPs
Adds minimal latency (NAT gateway)
Runs on Cloud Routers, no separate subnet needed
Best for providing internet access to resources without public IPs
Mistake
The VPC connector allows ingress traffic from the VPC to Cloud Run.
Correct
The VPC connector only handles outbound traffic from Cloud Run to the VPC. For inbound traffic from the VPC to Cloud Run, you need an Internal Load Balancer with a Serverless NEG.
Mistake
You must use a VPC connector if you want Cloud Run to access the internet.
Correct
Cloud Run can access the internet directly without any connector. The VPC connector is only needed for accessing private IPs in a VPC. For internet access, you can use Cloud NAT if you want a static IP or if the traffic must go through the VPC.
Mistake
The VPC connector provides a static IP address for Cloud Run.
Correct
The VPC connector does not assign a static IP to Cloud Run. Outbound traffic from the connector uses ephemeral IPs from the connector's subnet. To get a static IP, you need to use Cloud NAT with a static IP address.
Mistake
You can share a single VPC connector across multiple regions.
Correct
A VPC connector is regional. You must create one connector per region where you have Cloud Run services that need VPC access. Cross-region connectivity is not supported.
Mistake
The VPC connector can be used with Cloud Functions and App Engine as well.
Correct
Yes, the Serverless VPC Access feature (which powers the connector) works with Cloud Run, Cloud Functions (1st and 2nd gen), and App Engine Standard and Flexible environments. The same connector can be used by multiple serverless services in the same region.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No, the VPC connector does not provide a static IP. It uses ephemeral IPs from the connector's subnet. To get a static outbound IP, you must use Cloud NAT with a static IP address. You can combine a VPC connector (for private access) with Cloud NAT (for internet access) if needed.
`all-traffic` sends all outbound traffic from Cloud Run through the VPC connector, including traffic to the internet. `private-ranges-only` only sends traffic to private IP ranges (RFC 1918 and non-RFC 1918 private addresses) through the connector; internet traffic goes directly. Use `private-ranges-only` to reduce latency and cost when only private access is needed.
By default, you can create up to 10 connectors per region per project. This is a quota that can be increased by requesting a quota increase in the Google Cloud Console. Each connector can have up to 10 instances, and each instance handles up to 100 concurrent connections.
Yes, the VPC connector supports both TCP and UDP traffic. However, it does not support ICMP. If you need to ping a resource, you cannot use a VPC connector; you would need to use a VM-based solution.
Yes, you can update the machine type, minimum instances, and maximum instances of an existing connector using the `gcloud compute networks vpc-access connectors update` command. The connector will be updated without downtime, though there may be a brief period of reduced capacity.
If the subnet runs out of IP addresses, the connector cannot scale up to its maximum instances. New connections may fail. To avoid this, ensure the subnet has enough IPs for the maximum instances (e.g., /28 for up to 10 instances). You cannot change the subnet after creation, so plan carefully.
Yes, in a Shared VPC environment, the VPC connector must be created in the host project. The service project's Cloud Run service account needs the `compute.networkUser` role on the host project (or on the subnet). Additionally, the service project must have the Serverless VPC Access API enabled.
You've just covered Cloud Run VPC Connector — now see how well it sticks with free ACE practice questions. Full explanations included, no account needed.
Done with this chapter?