Is Serverless VPC Access connector a single point of failure?

Question

I am wanting to connect my Cloud Run app to Postgres Cloud SQL instance without assigning the instance a public IP. Seems like the only way to do this is with a Serverless VPC Access connector.

The docs indicate that the Serverless VPC Access connector is billed as 1 e2-micro instance per 100Mbps. Does this indicate that the connector is simply a single e2-micro VM? Is there any redundancy/automated-failover configured behind the scenes?

I can't find any SLA for the Serverless VPC Access and am worried that it could be a single point of failure for my app that brings down all DB connections.

Hauteur

Answer 1

The VPC Access Connector is a Compute Engine instance privately managed by Google Cloud. You are billed per 100Mbit of capacity. The instance size can scale up but not back down. Is this a single point of failure, yes but the service will auto recover. Fault tolerance, recovery time and SLA are not published (AFAIK).

Additional information:

• The images for the VPC Access Connector instances are from the project serverless-vpc-access-image.
• These instances use RFC1918 addresses that cannot overlap your VPCs.
• These instances are basically NAT Gateways and require IP forwarding be allowed constraints/compute.vmCanIPForward.

Declension

Would be great if someone from GCP can chime in on fault tolerance/recovery time/SLA or if we can expect these details to be published soon. – Hauteur

@Hauteur - I am a Google Cloud GDE. I recommend that you speak to your account representative if you desire access to unpublished material. Documents/details are sometimes available under NDA. – Declension

"scale up but not back down" is somewhat surprising to me. My charges have doubled and this is the only thing that explains it. I wish GCP can remove such connector charges, it is charging the customer for their design decisions. – Whitford

@JonathanLin - The reason for only scaling up but not back down is that it is easy to grow an instance (memory, storage, cpu) thru live migration. Moving down is usually not possible because of memory. Note: I am not saying that Google is using live migration, just that the technology makes it possible to scale up but not back down. – Declension

@JohnHanley For the Serverless VPC Access I expected it to be a fleet of e2-micro instances (horizontal scaling), so there would be multiple e2-micro instances if necessary. I didn't really expect it to be a vertical scaling. Anyway there is a lack of documentation surrounding this currently. Found out the hard way in my billing. – Whitford

FWIW, I am being charged ~558 hours of E2 1 vCPU, 4GB RAM per month (~$18 in us-central1), with one connector that is 200-300Mbps in throughput (the lowest possible configuration in a connector, even on a new one). Sounds like an e2-medium or composition of 3 e2-micros? Can't explain the hours computation though (full month should be ~720hours). Hopefully GCP can provide more transparency, or charge by bandwidth (e.g. $0.01/GB in AWS) instead of instances. – Whitford

Is it based on usage or there is a min cost attached to it? – Italia