Unable to use "Serverless VPC Access" across regions, but works within same region

[Hans Ravnaas]

Hello,

I'm running into the below and wanted to see if this is a known issue. According to this doc, "a connector can be in a different region than the resource it is sending traffic to", but I'm so far unable to accomplish this. Certainly possible I'm doing something wrong here of course. Here's my setup:

Fails with socket timeout:

Cloud Function (Java) in us-central1 -> serverless VPC connector in us-central1 -> internal IP of Cloud SQL (postgres 11) in us-west1-b

Works fine:

Cloud Function (Java) in us-central1 -> serverless VPC connector in us-central1 -> internal IP of Cloud SQL (postgres 11) in us-central1-a

I'm using the same connector in both of the above scenarios, and the SQL instance should be configured the same way as well, using the default VPC. The connector's ip-range is10.10.0.0/28. Wondering if there is a routing issue between 10.10.0.0/28 (us-central connector) and the default network in us-west1 where SQL resides? I have not changed or added any routes. Also, I don't see any firewall rules blocking here.

Any help appreciated!

Hans

[Hans Ravnaas]

If there is a better forum for this, please let me know.

[Kurtis Van Gent]

Hey Hans,

This is a fine form to ask this kind of question :). 

I looked into this a bit deeper, and Private IP on Cloud SQL currently requires the resource to be in the same region. Unfortunately in this case the VPC connector is in the same region with your Serverless deployment, and thus is unable to connect to the Cloud SQL instance via Private IP. There is work being done to remove this limitation, but unfortunately it isn't finished yet.

This is obviously confusing since the docs contradict, but I've filed an internal bug to try and clarify the position on the VPC Serverless page. Sorry for the confusion. 

Thanks,

Kurtis

[Hans Ravnaas]

Kurtis, thanks for a lot for looking into this and also considering updating the docs. It cost me a couple days of head scratching. Next up, moving SQL server to different region :-)

Hans