Editing article

Title

Summary

Content

<h3>Introduction</h3>When it comes to managed RDBMS solutions, Google Cloud Platform (GCP) offers two powerful solutions: Cloud SQL for managed relational databases and AlloyDB for PostgreSQL compatibility with high performance. Understanding how to connect to these databases is essential for any developer or administrator working with GCP.This blog dives into the world of private connectivity for AlloyDB, focusing on the benefits of Private Service Connect (PSC). Before we delve into the specific steps of creating a PSC endpoint for non-PSC enabled instances, let’s explore the scenarios where utilizing PSC with AlloyDB proves advantageous. Understanding these use cases will equip you with the foundational knowledge necessary to grasp the methods employed in specific situations.Firstly, we’ll differentiate between PSA (Private Service Access) and PSC, highlighting the evolution of private connectivity options for AlloyDB. This clarifies why PSC is the preferred approach for modern deployments.<blockquote>Note : For brevity, we’ll focus on AlloyDB, as networking concepts apply similarly to CloudSQL.</blockquote><h3>Networking Essentials for Connecting Applications to AlloyDB</h3>Connecting your applications to AlloyDB involves careful consideration of your network architecture. Let’s break down the key scenarios and how you can establish secure and reliable connections. We will only discuss methods to access the database using Private IP.<h4>Scenario 1: Application and AlloyDB in the Same Customer VPC Network</h4>This is the most straightforward setup. You can <a href="https://cloud.google.com/alloydb/docs/configure-connectivity#gcloud">use PSA to connect to your AlloyDB Instance</a>. Private services access is implemented as a <a href="https://cloud.google.com/vpc/docs/vpc-peering">VPC peering connection</a> between your <a href="https://cloud.google.com/vpc/docs/vpc">VPC network</a> and the underlying Google Cloud VPC network where your AlloyDB instance resides. Any service in Customer VPC network can use the Private IP of AlloyDB to connect to it.<figure><img alt="" src="https://cdn-images-1.medium.com/max/415/1*UwDvQ2oqjwyDWzPsJZFrpw.png" /><figcaption>Fig1: Simplified depiction of simplest Architecture</figcaption></figure><h4>Scenario 2: Application and Cloud SQL in a Shared VPC Network</h4><a href="https://cloud.google.com/vpc/docs/shared-vpc">Shared VPC networks</a> are designed to enable resource sharing across projects within an organization. This is the most commonly used network architecture in larger, multi-project environments.This simplifies the network architecture. Similar to the same VPC scenario, PSA is configured and services within Customer Shared VPC network can use the Private IP address, language connectors or AlloyDB Auth Proxy.<figure><img alt="" src="https://cdn-images-1.medium.com/max/635/1*F6StsaFJAqoHXiGNAH9VJw.png" /><figcaption>Fig2: Shared VPC</figcaption></figure>From above Illustration, We can see that GKE which is a separate Customer project (AlloyDB is in separate customer project) is able to access the AlloyDB using Private IP (PSA) as we are using shared VPC network and Shared VPC network is Peered to Google Managed AlloyDB VPC network.<h4>Scenario 3: Application and Cloud SQL in Different VPC Networks with VPC Peering</h4>This is when you want to manage separate VPC networks for separate projects or may be multiple Shared VPC networks.For example consider the diagram below<figure><img alt="" src="https://cdn-images-1.medium.com/max/625/1*vCXHqR5GmzlItj9_uZ5tHw.png" /><figcaption>Fig 3 Separate customer VPC networks for Application and AlloyDB</figcaption></figure>How would GKE in Customer GKE VPC connect to AlloyDB in AlloyDB VPC (PSA configured) ?The first solution that comes to mind to VPC Network peering.<figure><img alt="" src="https://cdn-images-1.medium.com/max/625/1*3vTqq8Mh8P4Tb1e_h3TdDA.png" /><figcaption>Fig 4 Transitive VPC Network Peering</figcaption></figure>Even If we peer Customer GKE VPC network to Customer AlloyDB VPC which is already peered to Google AlloyDB VPC through PSA, GKE pods using Customer GKE VPC network won’t be able to connect to AlloyDB Private IP because VPC Network Peering isn’t transitive.In Such a setup (Fig4. ), you can use the following ways to connect your AlloyDB instance to multiple VPCs using private IP :<ul><li><a href="https://cloud.google.com/sql/docs/mysql/connect-multiple-vpcs#custom-route">Connect using custom route advertisements</a></li><li><a href="https://cloud.google.com/sql/docs/mysql/connect-multiple-vpcs#intermediate-proxy">Connect using an intermediate proxy (SOCKS5)</a> or Connect using a TCP proxy such as <a href="https://manpages.ubuntu.com/manpages/trusty/man1/simpleproxy.1.html">simpleproxy</a></li></ul><figure><img alt="" src="https://cdn-images-1.medium.com/max/665/1*uz0NBlOxXS3LTy1EIbtgXQ.png" /><figcaption>Fig 5 TCP proxy on a VM hosted in Customer AlloyDB VPC</figcaption></figure>While setting up a proxy for PSC with AlloyDB is straightforward, managing a dedicated GCE VM within the customer’s AlloyDB project (VPC network) introduces additional operational overhead.<blockquote>You can’t use TCP Proxy if you intend to use AlloyDB Auth Proxy or language connectors for encryption and IAM authentication.</blockquote><h4>Scenario 4: Application and Cloud SQL in Different VPC Networks without VPC Peering</h4>This scenario is the main motivation for this post. PSC solves this challenge for us. PSC provides another connectivity option for AlloyDB users, with improvements on the legacy Service Networking (or PSA) framework, such as:<ul><li>Ability to make direct connections from multiple projects easily into AlloyDB resources, enabling new architectures.</li><li>Efficient use of IP address space, as a single IP address is required from a consumer VPC to connect to an AlloyDB instance. PSA requires a minimum of a /24 IP range.</li><li>More secure as consumer and producer VPCs are isolated, and only inbound connectivity to AlloyDB is allowed. PSA requires bidirectional connectivity between the consumer VPC and AlloyDB by default, which is a blocker for some customer use cases.</li></ul>Private Service Connect (PSC) for AlloyDB<a href="https://cloud.google.com/vpc/docs/private-service-connect">Private Service Connect</a> provides a powerful way to consume Google-managed services privately, even if they reside in a different project or network. PSC creates an internal DNS alias for your Cloud SQL instance. Your application can access it using this alias, and traffic is routed securely over Google’s private network.<figure><img alt="" src="https://cdn-images-1.medium.com/max/685/1*x6NJv3NHKO2mf97BZ-oeFA.png" /><figcaption>Fig6 Connect to AlloyDB using Private service connect</figcaption></figure>In Fig6, You can see resources from Customer GKE VPC network and Customer AlloyDB VPC network can connect to AlloyDB using a Private service connect endpoints (forwarding rules) in respective VPC networks. These forwarding rules use the service attachment which is created as part of Private service connect. We can whitelist projects where our applications or clients will reside, in the AlloyDB service attachment.This doesn’t requires Private service Access setup in Customer AlloyDB Project. AlloyDB Instance can be created with either PSC or PSA enabled.As of May 2024, both methods of private connectivity can’t be configured simultaneously. Same is true for CloudSQL as well. You can’t switch between PSC and PSA as of May 2024.<blockquote>You can also use <a href="https://cloud.google.com/alloydb/docs/configure-private-service-connect">Private service connect for AlloyDB</a> when Customer VPC networks don’t have PSA configured i.e. for all the above scenarios.</blockquote>You must create this endpoint in each customer VPC network where database access is needed.Private Service Connect endpoints that are used to access services are regional resources. However, you can make an endpoint available in other regions by <a href="https://cloud.google.com/vpc/docs/manage-endpoints-published-services#enable-global-access">configuring global access</a>.Can you enable PSC for existing AlloyDB Instance?So if you have an existing AlloyDB Instance with PSA enabled and you have an application in a separate VPC which is not peered to Customer AlloyDB VPC network. And you want to connect to AlloyDB using private IP, what options you do have?<figure><img alt="" src="https://cdn-images-1.medium.com/max/625/1*vCXHqR5GmzlItj9_uZ5tHw.png" /><figcaption>Fig 7 (same as Fig3)</figcaption></figure>You may do what we did in Scenario 3 i.e. create VPC peering between Customer GKE VPC and Customer AlloyDB VPC and use TCP Proxy or use custom route advertisements. But there is an overhead of managing routes or GCE VM running proxy.A solution like PSC enabled AlloyDB would be a good fit for such a scenario. As you can’t simply switch between PSA and PSC, you have below options:<ul><li>You can create a DMS job to migrate data between PSA enabled AlloyDB to PSC enabled AlloyDB. That means some extra work in setting up DMS and a small downtime as well.</li><li>You can export all you data and import into a new PSC enabled Instance and that means downtime.</li><li>You can create a PSC endpoint for a Non-PSC (PSA enabled) AlloyDB Instance. That will require some work but you will be able to use both PSA and PSC endpoints to connect the you AlloyDB Instance.</li></ul><h3>Create PSC endpoint for a Non-PSC (PSA enabled) AlloyDB Instance</h3>In this section, we will discuss what are the ways we can use to create a PSC endpoint for a PSA enabled AlloyDB Instance.<h4>Two Methods</h4><ul><li>Method 1: Create a service attachment in Customer AlloyDB VPC network which already has PSA enabled. This service attachment will use a producer forwarding rule in Customer AlloyDB VPC network that has a “target instance” as backend and that target instance points to the VM where we have a TCP proxy or SOCKS Proxy running (Fig 8.). Create a forwarding rule in Customer GKE VPC network with service attachment in Customer AlloyDB VPC network as target. Applications deployed on GCE/GKE in Customer GKE VPC network can connect to AlloyDB Instance using the private IP assigned to outgoing fowarding rule.</li></ul><figure><img alt="" src="https://cdn-images-1.medium.com/max/625/1*kgYwDyuLFp8jyBz8ik4L6Q.png" /><figcaption>Fig 8 Service attachment with tcp proxy running on a VM</figcaption></figure><ul><li>Method 2: Create a service attachment in Customer AlloyDB VPC network which already has PSA enabled. This service attachment will use a producer forwarding rule in Customer AlloyDB VPC network which has a backend service with Zonal hybrid network endpoint groups as targets. Zonal NEG has AlloyDB Private IP and port as endpoint. Create a forwarding rule in Customer GKE VPC network with service attachment in Customer AlloyDB VPC network as target. Applications deployed on GCE/GKE in Customer GKE VPC network can connect to AlloyDB Instance using the private IP assigned to outgoing fowarding rule.</li></ul><figure><img alt="" src="https://cdn-images-1.medium.com/max/625/1*pFwi78U_e74ckZSczhOMdg.png" /><figcaption>Fig 9 Service attachment connected to LB with zonal NEG as backend</figcaption></figure>Method 2 is a better option because<ul><li>It uses all the managed services rather than a Proxy running on VM.</li><li>You can use AlloyDB Auth proxy for encryption and IAM authentication</li></ul><h4>Assumptions before Implementation</h4><ul><li>You have a AlloyDB Cluster with primary Instance in Customer AlloyDB project which has PSA enabled</li><li>You have a customer AlloyDB project with customer AlloyDB VPC network and a Customer GKE/GCE project with Customer GKE/GCE VPC network</li><li>Your account has appropriate privileges to create and managed resources</li></ul><h4>Steps to implement Method 2</h4><ul><li>Read for environment variables</li></ul><pre> read -p &quot;region : &quot; REGION read -p &quot;projectid : &quot; DB_PROJECT read -p &quot;GCE_SUBNET : &quot; GCE_SUBNET read -p &quot;DB_VPC_NET : &quot; DB_VPC_NET read -p &quot;CIDR_TCPNAT : &quot; CIDR_TCPNAT read -p &quot;clientprojectid : &quot; CLIENT_PROJECT read -p &quot;AlloyDB Cluster : &quot; ADB_CLUSTER read -p &quot;AlloyDB Instance : &quot; ADB_INSTANCE read -p &quot;CLIENT_VPC_NET : &quot; CLIENT_VPC_NET read -p &quot;GCE_SUBNET_CLIENT : &quot; GCE_SUBNET_CLIENT read -p &quot;Resrverip : &quot; ADDR read -p &quot;PORT :&quot; PORT</pre>DB_VPC_NET — Customer AlloyDB VPC Network name DB_PROJECT — Customer AlloyDB VPC Project ID GCE_SUBNET — Subnet in Customer AlloyDB VPC Network CIDR_TCPNAT — CIDR for PSC subnet in Customer AlloyDB VPC Network CLIENT_PROJECT — Customer GKE/GCE VPC Project ID ADB_CLUSTER — AlloyDB Cluster name ADB_INSTANCE — AlloyDB Instance REGION — Region in which your AlloyDB Instance is created CLIENT_VPC_NET — Customer GKE/GCE VPC Network name GCE_SUBNET_CLIENT — Subnet in Customer AlloyDB VPC Network ADDR — IP address to be used by outgoing Forwarding rule PORT — PORT on which DB or Auth proxy is listening<ul><li>Authenticate and create a subnet for Private service connect in Customer AlloyDB VPC Network</li></ul><pre> # Authenticate gcloud auth login # Create a TCP NAT subnet. gcloud compute networks subnets create dms-psc-nat-${REGION}-tcp \ --network=${DB_VPC_NET} \ --project=${DB_PROJECT} \ --region=${REGION} \ --range=${CIDR_TCPNAT} \ --purpose=private-service-connect</pre><ul><li>Create a Zonal Network endpoint group of Hybrid type and add an endpoint which is private IP of the AlloyDB Instance. Port can be either be AlloyDB port (5432) or AlloyDB Auth proxy port(5433).</li><li>For Cloud SQL ports would be different. Cloud SQL Auth Proxy uses 3307.</li></ul><pre>### create NEG gcloud compute network-endpoint-groups create neg-$(date +%d%m%Y) --default-port=$PORT --network=${DB_VPC_NET} \ --network-endpoint-type=non-gcp-private-ip-port \ --project=${DB_PROJECT} \ --zone=${REGION}-a ### get private IP for AlloyDB or cloudSQL DB_PRIVATE_IP=$(gcloud beta alloydb instances describe $ADB_INSTANCE --cluster=$ADB_CLUSTER --region=$REGION --format json --project=${DB_PROJECT} | jq .ipAddress|tr -d &#39;&quot;&#39;) #neg endpoint gcloud compute network-endpoint-groups update neg-$(date +%d%m%Y) \ --zone=${REGION}-a \ --add-endpoint=&quot;ip=&quot;${DB_PRIVATE_IP}&quot;,port=&quot;$PORT --project=${DB_PROJECT}</pre><ul><li>Configure the load balancer i.e. a backend service with Hybrid NEG as backend, TCP proxy, and regional health check for the backends.</li></ul><pre> ### Health check probes for hybrid NEG backends originate from Envoy proxies in the proxy-only subnet. gcloud compute health-checks create tcp lb-hc-$(date +%d%m%Y) \ --region=${REGION} \ --use-serving-port --project=${DB_PROJECT} ##### Create a backend service. gcloud compute backend-services create bs-lb-$(date +%d%m%Y) \ --load-balancing-scheme=INTERNAL_MANAGED \ --protocol=TCP \ --region=${REGION} \ --health-checks=lb-hc-$(date +%d%m%Y) \ --health-checks-region=${REGION} --project=${DB_PROJECT} ## Add the hybrid NEG backend to the backend service. gcloud compute backend-services add-backend bs-lb-$(date +%d%m%Y) \ --network-endpoint-group=neg-$(date +%d%m%Y) \ --network-endpoint-group-zone=${REGION}-a \ --region=${REGION} \ --balancing-mode=CONNECTION \ --max-connections=100 --project=${DB_PROJECT} ### For MAX_CONNECTIONS, enter the maximum concurrent connections ### that the backend should handle. ###Create the target TCP proxy. gcloud compute target-tcp-proxies create tcp-proxy-$(date +%d%m%Y) \ --backend-service=bs-lb-$(date +%d%m%Y) \ --region=${REGION} \ --project=${DB_PROJECT} </pre><ul><li>Create the forwarding rule which has target tcp proxy which we created in previous step. The forwarding rule only forwards packets with a matching destination port.</li></ul><pre>## create incoming forwarding rule which acts a frontend for LB gcloud compute forwarding-rules create fr-psc-$(date +%d%m%Y) \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=${DB_VPC_NET} \ --subnet=${GCE_SUBNET} \ --ports=$PORT \ --region=${REGION} \ --target-tcp-proxy=tcp-proxy-$(date +%d%m%Y) \ --target-tcp-proxy-region=${REGION} --project=${DB_PROJECT}</pre><ul><li>Create Service attachment in Customer AlloyDB VPC network which points to the forwarding rule we created in previous step. We whitelisted Customer AlloyDB VPC network and Customer GCE/GKE VPC network for the service attachment.</li></ul><pre># Create a service attachment. gcloud compute service-attachments create dms-psc-svc-att-${REGION} \ --project=${DB_PROJECT} \ --region=${REGION} \ --producer-forwarding-rule=fr-psc-$(date +%d%m%Y) \ --connection-preference=ACCEPT_MANUAL \ --nat-subnets=dms-psc-nat-${REGION}-tcp \ --consumer-accept-list=${DB_PROJECT}=2000,${CLIENT_PROJECT}=2000</pre><ul><li>Create Firewall rule to allow ingress from service attachment subnet</li></ul><pre>gcloud compute \ --project=${DB_PROJECT} firewall-rules create fwr-dms-allow-psc-tcp \ --direction=INGRESS \ --priority=1000 \ --network=${DB_VPC_NET} \ --action=ALLOW \ --rules=all \ --source-ranges=${CIDR_TCPNAT} \ --enable-logging</pre><ul><li>Reserve an internal IP from GCE_SUBNET_CLIENT subnet. This will be used by forwarding rule. This IP will be used by client in Customer GCE/GKE VPC network to connect to AlloyDB.</li></ul><blockquote>If you want to use AlloyDB Auth proxy or language connector then this IP has to be same as PSA Private IP. That means you need to have a Subnet in Customer GCE VPC network with CIDR overlapping with part of your Private Service Access Allocated IP range in your Customer AlloyDB VPC network.</blockquote><pre>### Reserve a Private IP address gcloud compute addresses create addr-$(date +%d%m%Y) \ --project=${CLIENT_PROJECT} \ --region=${REGION} \ --subnet=${GCE_SUBNET_CLIENT} \ --addresses=${ADDR}</pre><ul><li>Create a forwarding rule in Customer GCE/GKE VPC network with target as service attachment in Customer AlloyDB VPC network</li></ul><pre>## create PSC endpoint (forwarding rule) gcloud compute forwarding-rules create fr-client-$(date +%d%m%Y) \ --address=addr-$(date +%d%m%Y) \ --project=${CLIENT_PROJECT} \ --region=${REGION} \ --network=${CLIENT_VPC_NET} \ --target-service-attachment=projects/${DB_PROJECT}/regions/${REGION}/serviceAttachments/dms-psc-svc-att-${REGION}</pre><ul><li>To test connectivity, Create a GCE VM in Customer GCE/GKE project using GCE_SUBNET_CLIENT of Customer GCE/GKE VPC network. Install postgresql-client</li></ul><pre>## create a Client VM gcloud compute instances create instance-$(date +%d%m%Y) \ --project=${CLIENT_PROJECT} \ --zone=${REGION}-a \ --image-family=debian-12 \ --image-project=debian-cloud \ --network-interface=network-tier=PREMIUM,stack-type=IPV4_ONLY,subnet=${GCE_SUBNET_CLIENT} \ --metadata=startup-script=&#39;#! /bin/bash apt-get install postgresql-client wget -y wget https://storage.googleapis.com/alloydb-auth-proxy/v1.7.1/alloydb-auth-proxy.linux.amd64 -O alloydb-auth-proxy chmod +x alloydb-auth-proxy &#39;</pre><ul><li>On the GCE VM in Customer GKE/GCE VPC network</li></ul><pre>### If Using AlloyDB Auth Proxy gcloud beta alloydb instances describe alloydb-ins-primary-$(date +%d%m%Y) --project=${DB_PROJECT} --cluster=alloydb-cls-001 --region=${REGION} --format json | jq .name ./alloydb-auth-proxy INST_URI </pre><ul><li>If you are configuring for Cloud SQL, <a href="https://cloud.google.com/sql/docs/postgres/connect-auth-proxy#start-proxy">use this public document to start Cloud SQL Auth Proxy</a>.</li><li>On the GCE VM in Customer GKE/GCE VPC network</li></ul><pre>### If using AlloyDB Auth Proxy psql -h 127.0.0.1 -U postgres postgres ### If using Private IP psql -h &lt;Private IP of forwarding rule in Customer GCE/GKE VPC network&gt; -U postgres postgres</pre>This method works well. I have tested this multiple times.Performance testing is advised before production deployment.<h3>Other notable key points</h3><ul><li>Prefer managed PSC enabled AlloyDB over such a manual solution</li><li>NEG used are hybrid zonal NEG, so in case of a failover you have to add new zonal NEG to backend service of load balancer.</li><li>You can use DMS service to migrate a PSA enabled AlloyDB to PSC AlloyDB.</li></ul><h3>References</h3><ul><li><a href="https://cloud.google.com/alloydb/docs/connect-external">Connect to a cluster from outside its VPC | AlloyDB for PostgreSQL | Google Cloud</a></li><li><a href="https://cloud.google.com/sql/docs/mysql/connect-multiple-vpcs">Connect your instance to multiple VPCs | Cloud SQL for MySQL | Google Cloud</a></li><li><a href="https://cloud.google.com/sql/docs/mysql/configure-private-service-connect">Connect to an instance using Private Service Connect | Cloud SQL for MySQL | Google Cloud</a></li></ul><img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=3f8eeed51d2a" width="1" height="1" alt=""><hr><a href="https://medium.com/google-cloud/connect-to-non-psc-alloydb-or-non-psc-cloud-sql-from-a-different-vpc-3f8eeed51d2a">Connect to Non-PSC AlloyDB or Non-PSC Cloud SQL from a different VPC</a> was originally published in <a href="https://medium.com/google-cloud">Google Cloud - Community</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Author

Link

Published date

Image url

Feed url

Guid

Hidden blurb

--- !ruby/object:Feedjira::Parser::RSSEntry
title: Connect to Non-PSC AlloyDB or Non-PSC Cloud SQL from a different VPC
url: https://medium.com/google-cloud/connect-to-non-psc-alloydb-or-non-psc-cloud-sql-from-a-different-vpc-3f8eeed51d2a?source=rss----e52cf94d98af---4
author: Harinderjit Singh
categories:
- data
- alloydb
- cloud-sql
- google-cloud-platform
- infrastructure
published: 2024-05-14 04:21:54.000000000 Z
entry_id: !ruby/object:Feedjira::Parser::GloballyUniqueIdentifier
 is_perma_link: 'false'
 guid: https://medium.com/p/3f8eeed51d2a
carlessian_info:
 news_filer_version: 2
 newspaper: Google Cloud - Medium
 macro_region: Blogs
rss_fields:
- title
- url
- author
- categories
- published
- entry_id
- content
content: '<h3>Introduction</h3>When it comes to managed RDBMS solutions, Google
 Cloud Platform (GCP) offers two powerful solutions: Cloud SQL for managed relational
 databases and AlloyDB for PostgreSQL compatibility with high performance. Understanding
 how to connect to these databases is essential for any developer or administrator
 working with GCP.This blog dives into the world of private connectivity for
 AlloyDB, focusing on the benefits of Private Service Connect (PSC). Before we delve
 into the specific steps of creating a PSC endpoint for non-PSC enabled instances,
 let’s explore the scenarios where utilizing PSC with AlloyDB proves advantageous.
 Understanding these use cases will equip you with the foundational knowledge necessary
 to grasp the methods employed in specific situations.Firstly, we’ll differentiate
 between PSA (Private Service Access) and PSC, highlighting the evolution of private
 connectivity options for AlloyDB. This clarifies why PSC is the preferred approach
 for modern deployments.<blockquote>Note : For brevity, we’ll focus on AlloyDB,
 as networking concepts apply similarly to CloudSQL.</blockquote><h3>Networking
 Essentials for Connecting Applications to AlloyDB</h3>Connecting your
 applications to AlloyDB involves careful consideration of your network architecture.
 Let’s break down the key scenarios and how you can establish secure and reliable
 connections. We will only discuss methods to access the database using Private IP.<h4>Scenario
 1: Application and AlloyDB in the Same Customer VPC Network</h4>This
 is the most straightforward setup. You can <a href="https://cloud.google.com/alloydb/docs/configure-connectivity#gcloud">use
 PSA to connect to your AlloyDB Instance</a>. Private services access
 is implemented as a <a href="https://cloud.google.com/vpc/docs/vpc-peering">VPC
 peering connection</a> between your <a href="https://cloud.google.com/vpc/docs/vpc">VPC
 network</a> and the underlying Google Cloud VPC network where your AlloyDB
 instance resides. Any service in Customer VPC network can use the Private IP of
 AlloyDB to connect to it.<figure><img alt="" src="https://cdn-images-1.medium.com/max/415/1*UwDvQ2oqjwyDWzPsJZFrpw.png"
 /><figcaption>Fig1: Simplified depiction of simplest Architecture</figcaption></figure><h4>Scenario
 2: Application and Cloud SQL in a Shared VPC Network</h4><a href="https://cloud.google.com/vpc/docs/shared-vpc">Shared
 VPC networks</a> are designed to enable resource sharing across projects within
 an organization. This is the most commonly used network architecture in larger,
 multi-project environments.This simplifies the network architecture. Similar
 to the same VPC scenario, PSA is configured and services within Customer Shared
 VPC network can use the Private IP address, language connectors or AlloyDB Auth Proxy.<figure><img
 alt="" src="https://cdn-images-1.medium.com/max/635/1*F6StsaFJAqoHXiGNAH9VJw.png"
 /><figcaption>Fig2: Shared VPC</figcaption></figure>From above Illustration,
 We can see that GKE which is a separate Customer project (AlloyDB is in separate
 customer project) is able to access the AlloyDB using Private IP (PSA) as we are
 using shared VPC network and Shared VPC network is Peered to Google Managed AlloyDB
 VPC network.<h4>Scenario 3: Application and Cloud SQL in Different VPC
 Networks with VPC Peering</h4>This is when you want to manage separate
 VPC networks for separate projects or may be multiple Shared VPC networks.For
 example consider the diagram below<figure><img alt="" src="https://cdn-images-1.medium.com/max/625/1*vCXHqR5GmzlItj9_uZ5tHw.png"
 /><figcaption>Fig 3 Separate customer VPC networks for Application and AlloyDB</figcaption></figure>How
 would GKE in Customer GKE VPC connect to AlloyDB in AlloyDB VPC (PSA configured) ?The
 first solution that comes to mind to VPC Network peering.<figure><img alt=""
 src="https://cdn-images-1.medium.com/max/625/1*3vTqq8Mh8P4Tb1e_h3TdDA.png" /><figcaption>Fig
 4 Transitive VPC Network Peering</figcaption></figure>Even If we peer Customer
 GKE VPC network to Customer AlloyDB VPC which is already peered to Google AlloyDB
 VPC through PSA, GKE pods using Customer GKE VPC network won’t be able to
 connect to AlloyDB Private IP because VPC Network Peering isn’t transitive.In
 Such a setup (Fig4. ), you can use the following ways to connect your AlloyDB instance
 to multiple VPCs using private IP :<ul><li><a href="https://cloud.google.com/sql/docs/mysql/connect-multiple-vpcs#custom-route">Connect
 using custom route advertisements</a></li><li><a href="https://cloud.google.com/sql/docs/mysql/connect-multiple-vpcs#intermediate-proxy">Connect
 using an intermediate proxy (SOCKS5)</a> or Connect using a TCP proxy such as <a
 href="https://manpages.ubuntu.com/manpages/trusty/man1/simpleproxy.1.html">simpleproxy</a></li></ul><figure><img
 alt="" src="https://cdn-images-1.medium.com/max/665/1*uz0NBlOxXS3LTy1EIbtgXQ.png"
 /><figcaption>Fig 5 TCP proxy on a VM hosted in Customer AlloyDB VPC</figcaption></figure>While
 setting up a proxy for PSC with AlloyDB is straightforward, managing a dedicated
 GCE VM within the customer’s AlloyDB project (VPC network) introduces additional
 operational overhead.<blockquote>You can’t use TCP Proxy if you intend to use
 AlloyDB Auth Proxy or language connectors for encryption and IAM authentication.</blockquote><h4>Scenario
 4: Application and Cloud SQL in Different VPC Networks without VPC Peering</h4>This
 scenario is the main motivation for this post. PSC solves this challenge for us.
 PSC provides another connectivity option for AlloyDB users, with improvements on
 the legacy Service Networking (or PSA) framework, such as:<ul><li>Ability to
 make direct connections from multiple projects easily into AlloyDB resources, enabling
 new architectures.</li><li>Efficient use of IP address space, as a single IP address
 is required from a consumer VPC to connect to an AlloyDB instance. PSA requires
 a minimum of a /24 IP range.</li><li>More secure as consumer and producer VPCs are
 isolated, and only inbound connectivity to AlloyDB is allowed. PSA requires bidirectional
 connectivity between the consumer VPC and AlloyDB by default, which is a blocker
 for some customer use cases.</li></ul>Private Service Connect (PSC) for AlloyDB<a
 href="https://cloud.google.com/vpc/docs/private-service-connect">Private Service
 Connect</a> provides a powerful way to consume Google-managed services privately,
 even if they reside in a different project or network. PSC creates an internal DNS
 alias for your Cloud SQL instance. Your application can access it using this alias,
 and traffic is routed securely over Google’s private network.<figure><img alt=""
 src="https://cdn-images-1.medium.com/max/685/1*x6NJv3NHKO2mf97BZ-oeFA.png" /><figcaption>Fig6
 Connect to AlloyDB using Private service connect</figcaption></figure>In Fig6,
 You can see resources from Customer GKE VPC network and Customer AlloyDB VPC network
 can connect to AlloyDB using a Private service connect endpoints (forwarding rules)
 in respective VPC networks. These forwarding rules use the service attachment which
 is created as part of Private service connect. We can whitelist projects where our
 applications or clients will reside, in the AlloyDB service attachment.This
 doesn’t requires Private service Access setup in Customer AlloyDB Project. AlloyDB
 Instance can be created with either PSC or PSA enabled.As of May 2024, both
 methods of private connectivity can’t be configured simultaneously. Same is true
 for CloudSQL as well. You can’t switch between PSC and PSA as of May 2024.<blockquote>You
 can also use <a href="https://cloud.google.com/alloydb/docs/configure-private-service-connect">Private
 service connect for AlloyDB</a> when Customer VPC networks don’t have PSA configured
 i.e. for all the above scenarios.</blockquote>You must create this endpoint in
 each customer VPC network where database access is needed.Private Service
 Connect endpoints that are used to access services are regional resources. However,
 you can make an endpoint available in other regions by <a href="https://cloud.google.com/vpc/docs/manage-endpoints-published-services#enable-global-access">configuring
 global access</a>.Can you enable PSC for existing AlloyDB Instance?So
 if you have an existing AlloyDB Instance with PSA enabled and you have an application
 in a separate VPC which is not peered to Customer AlloyDB VPC network. And you want
 to connect to AlloyDB using private IP, what options you do have?<figure><img
 alt="" src="https://cdn-images-1.medium.com/max/625/1*vCXHqR5GmzlItj9_uZ5tHw.png"
 /><figcaption>Fig 7 (same as Fig3)</figcaption></figure>You may do what we did
 in Scenario 3 i.e. create VPC peering between Customer GKE VPC and Customer AlloyDB
 VPC and use TCP Proxy or use custom route advertisements. But there is an overhead
 of managing routes or GCE VM running proxy.A solution like PSC enabled AlloyDB
 would be a good fit for such a scenario. As you can’t simply switch between PSA
 and PSC, you have below options:<ul><li>You can create a DMS job to migrate
 data between PSA enabled AlloyDB to PSC enabled AlloyDB. That means some extra work
 in setting up DMS and a small downtime as well.</li><li>You can export all you data
 and import into a new PSC enabled Instance and that means downtime.</li><li>You
 can create a PSC endpoint for a Non-PSC (PSA enabled) AlloyDB Instance. That will
 require some work but you will be able to use both PSA and PSC endpoints to connect
 the you AlloyDB Instance.</li></ul><h3>Create PSC endpoint for a Non-PSC
 (PSA enabled) AlloyDB Instance</h3>In this section, we will discuss what are
 the ways we can use to create a PSC endpoint for a PSA enabled AlloyDB Instance.<h4>Two
 Methods</h4><ul><li>Method 1: Create a service attachment in Customer
 AlloyDB VPC network which already has PSA enabled. This service attachment will
 use a producer forwarding rule in Customer AlloyDB VPC network that has a “target
 instance” as backend and that target instance points to the VM where we have a TCP
 proxy or SOCKS Proxy running (Fig 8.). Create a forwarding rule in Customer GKE
 VPC network with service attachment in Customer AlloyDB VPC network as target. Applications
 deployed on GCE/GKE in Customer GKE VPC network can connect to AlloyDB Instance
 using the private IP assigned to outgoing fowarding rule.</li></ul><figure><img
 alt="" src="https://cdn-images-1.medium.com/max/625/1*kgYwDyuLFp8jyBz8ik4L6Q.png"
 /><figcaption>Fig 8 Service attachment with tcp proxy running on a VM</figcaption></figure><ul><li>Method
 2: Create a service attachment in Customer AlloyDB VPC network which already
 has PSA enabled. This service attachment will use a producer forwarding rule in
 Customer AlloyDB VPC network which has a backend service with Zonal hybrid network
 endpoint groups as targets. Zonal NEG has AlloyDB Private IP and port as endpoint.
 Create a forwarding rule in Customer GKE VPC network with service attachment in
 Customer AlloyDB VPC network as target. Applications deployed on GCE/GKE in Customer
 GKE VPC network can connect to AlloyDB Instance using the private IP assigned to
 outgoing fowarding rule.</li></ul><figure><img alt="" src="https://cdn-images-1.medium.com/max/625/1*pFwi78U_e74ckZSczhOMdg.png"
 /><figcaption>Fig 9 Service attachment connected to LB with zonal NEG as backend</figcaption></figure>Method
 2 is a better option because<ul><li>It uses all the managed services
 rather than a Proxy running on VM.</li><li>You can use AlloyDB Auth proxy for encryption
 and IAM authentication</li></ul><h4>Assumptions before Implementation</h4><ul><li>You
 have a AlloyDB Cluster with primary Instance in Customer AlloyDB project which has
 PSA enabled</li><li>You have a customer AlloyDB project with customer AlloyDB VPC
 network and a Customer GKE/GCE project with Customer GKE/GCE VPC network</li><li>Your
 account has appropriate privileges to create and managed resources</li></ul><h4>Steps
 to implement Method 2</h4><ul><li>Read for environment variables</li></ul><pre> read
 -p &quot;region : &quot; REGION read -p &quot;projectid : &quot; DB_PROJECT read
 -p &quot;GCE_SUBNET : &quot; GCE_SUBNET read -p &quot;DB_VPC_NET : &quot; DB_VPC_NET read
 -p &quot;CIDR_TCPNAT : &quot; CIDR_TCPNAT read -p &quot;clientprojectid : &quot;
 CLIENT_PROJECT read -p &quot;AlloyDB Cluster : &quot; ADB_CLUSTER read -p
 &quot;AlloyDB Instance : &quot; ADB_INSTANCE read -p &quot;CLIENT_VPC_NET : &quot;
 CLIENT_VPC_NET read -p &quot;GCE_SUBNET_CLIENT : &quot; GCE_SUBNET_CLIENT read
 -p &quot;Resrverip : &quot; ADDR read -p &quot;PORT :&quot; PORT</pre>DB_VPC_NET — Customer
 AlloyDB VPC Network name DB_PROJECT — Customer AlloyDB VPC Project ID GCE_SUBNET — Subnet
 in Customer AlloyDB VPC Network CIDR_TCPNAT — CIDR for PSC subnet in Customer
 AlloyDB VPC Network CLIENT_PROJECT — Customer GKE/GCE VPC Project ID ADB_CLUSTER — AlloyDB
 Cluster name ADB_INSTANCE — AlloyDB Instance REGION — Region in which your
 AlloyDB Instance is created CLIENT_VPC_NET — Customer GKE/GCE VPC Network name
 GCE_SUBNET_CLIENT — Subnet in Customer AlloyDB VPC Network ADDR — IP address
 to be used by outgoing Forwarding rule PORT — PORT on which DB or Auth proxy
 is listening<ul><li>Authenticate and create a subnet for Private service
 connect in Customer AlloyDB VPC Network</li></ul><pre> # Authenticate gcloud
 auth login # Create a TCP NAT subnet. gcloud compute networks subnets
 create dms-psc-nat-${REGION}-tcp \ --network=${DB_VPC_NET} \ --project=${DB_PROJECT}
 \ --region=${REGION} \ --range=${CIDR_TCPNAT} \ --purpose=private-service-connect</pre><ul><li>Create
 a Zonal Network endpoint group of Hybrid type and add an endpoint which is private
 IP of the AlloyDB Instance. Port can be either be AlloyDB port (5432) or AlloyDB
 Auth proxy port(5433).</li><li>For Cloud SQL ports would be different. Cloud SQL
 Auth Proxy uses 3307.</li></ul><pre>### create NEG gcloud compute network-endpoint-groups
 create neg-$(date +%d%m%Y) --default-port=$PORT --network=${DB_VPC_NET} \ --network-endpoint-type=non-gcp-private-ip-port
 \ --project=${DB_PROJECT} \ --zone=${REGION}-a ### get private IP
 for AlloyDB or cloudSQL DB_PRIVATE_IP=$(gcloud beta alloydb instances describe
 $ADB_INSTANCE --cluster=$ADB_CLUSTER --region=$REGION --format json --project=${DB_PROJECT}
 | jq .ipAddress|tr -d &#39;&quot;&#39;) #neg endpoint gcloud compute network-endpoint-groups
 update neg-$(date +%d%m%Y) \ --zone=${REGION}-a \ --add-endpoint=&quot;ip=&quot;${DB_PRIVATE_IP}&quot;,port=&quot;$PORT
 --project=${DB_PROJECT}</pre><ul><li>Configure the load balancer i.e. a backend
 service with Hybrid NEG as backend, TCP proxy, and regional health check for the
 backends.</li></ul><pre> ### Health check probes for hybrid NEG backends originate
 from Envoy proxies in the proxy-only subnet. gcloud compute health-checks create
 tcp lb-hc-$(date +%d%m%Y) \ --region=${REGION} \ --use-serving-port
 --project=${DB_PROJECT} ##### Create a backend service. gcloud compute
 backend-services create bs-lb-$(date +%d%m%Y) \ --load-balancing-scheme=INTERNAL_MANAGED
 \ --protocol=TCP \ --region=${REGION} \ --health-checks=lb-hc-$(date
 +%d%m%Y) \ --health-checks-region=${REGION} --project=${DB_PROJECT} ##
 Add the hybrid NEG backend to the backend service. gcloud compute backend-services
 add-backend bs-lb-$(date +%d%m%Y) \ --network-endpoint-group=neg-$(date +%d%m%Y)
 \ --network-endpoint-group-zone=${REGION}-a \ --region=${REGION} \ --balancing-mode=CONNECTION
 \ --max-connections=100 --project=${DB_PROJECT} ### For MAX_CONNECTIONS,
 enter the maximum concurrent connections ### that the backend should handle. ###Create
 the target TCP proxy. gcloud compute target-tcp-proxies create tcp-proxy-$(date
 +%d%m%Y) \ --backend-service=bs-lb-$(date +%d%m%Y) \ --region=${REGION}
 \ --project=${DB_PROJECT} </pre><ul><li>Create the forwarding rule
 which has target tcp proxy which we created in previous step. The forwarding rule
 only forwards packets with a matching destination port.</li></ul><pre>## create
 incoming forwarding rule which acts a frontend for LB gcloud compute forwarding-rules
 create fr-psc-$(date +%d%m%Y) \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=${DB_VPC_NET}
 \ --subnet=${GCE_SUBNET} \ --ports=$PORT \ --region=${REGION}
 \ --target-tcp-proxy=tcp-proxy-$(date +%d%m%Y) \ --target-tcp-proxy-region=${REGION} --project=${DB_PROJECT}</pre><ul><li>Create
 Service attachment in Customer AlloyDB VPC network which points to the forwarding
 rule we created in previous step. We whitelisted Customer AlloyDB VPC network and
 Customer GCE/GKE VPC network for the service attachment.</li></ul><pre># Create
 a service attachment. gcloud compute service-attachments create dms-psc-svc-att-${REGION}
 \ --project=${DB_PROJECT} \ --region=${REGION} \ --producer-forwarding-rule=fr-psc-$(date
 +%d%m%Y) \ --connection-preference=ACCEPT_MANUAL \ --nat-subnets=dms-psc-nat-${REGION}-tcp
 \ --consumer-accept-list=${DB_PROJECT}=2000,${CLIENT_PROJECT}=2000</pre><ul><li>Create
 Firewall rule to allow ingress from service attachment subnet</li></ul><pre>gcloud
 compute \ --project=${DB_PROJECT} firewall-rules create fwr-dms-allow-psc-tcp
 \ --direction=INGRESS \ --priority=1000 \ --network=${DB_VPC_NET} \ --action=ALLOW
 \ --rules=all \ --source-ranges=${CIDR_TCPNAT} \ --enable-logging</pre><ul><li>Reserve
 an internal IP from GCE_SUBNET_CLIENT subnet. This will be used by forwarding rule.
 This IP will be used by client in Customer GCE/GKE VPC network to connect to AlloyDB.</li></ul><blockquote>If
 you want to use AlloyDB Auth proxy or language connector then this IP has to be
 same as PSA Private IP. That means you need to have a Subnet in Customer GCE VPC
 network with CIDR overlapping with part of your Private Service Access Allocated
 IP range in your Customer AlloyDB VPC network.</blockquote><pre>### Reserve a Private
 IP address gcloud compute addresses create addr-$(date +%d%m%Y) \ --project=${CLIENT_PROJECT}
 \ --region=${REGION} \ --subnet=${GCE_SUBNET_CLIENT} \ --addresses=${ADDR}</pre><ul><li>Create
 a forwarding rule in Customer GCE/GKE VPC network with target as service attachment
 in Customer AlloyDB VPC network</li></ul><pre>## create PSC endpoint (forwarding
 rule) gcloud compute forwarding-rules create fr-client-$(date +%d%m%Y) \ --address=addr-$(date
 +%d%m%Y) \ --project=${CLIENT_PROJECT} \ --region=${REGION} \ --network=${CLIENT_VPC_NET}
 \ --target-service-attachment=projects/${DB_PROJECT}/regions/${REGION}/serviceAttachments/dms-psc-svc-att-${REGION}</pre><ul><li>To
 test connectivity, Create a GCE VM in Customer GCE/GKE project using GCE_SUBNET_CLIENT
 of Customer GCE/GKE VPC network. Install postgresql-client</li></ul><pre>## create
 a Client VM gcloud compute instances create instance-$(date +%d%m%Y) \ --project=${CLIENT_PROJECT}
 \ --zone=${REGION}-a \ --image-family=debian-12 \ --image-project=debian-cloud
 \ --network-interface=network-tier=PREMIUM,stack-type=IPV4_ONLY,subnet=${GCE_SUBNET_CLIENT}
 \ --metadata=startup-script=&#39;#! /bin/bash apt-get install postgresql-client
 wget -y wget https://storage.googleapis.com/alloydb-auth-proxy/v1.7.1/alloydb-auth-proxy.linux.amd64
 -O alloydb-auth-proxy chmod +x alloydb-auth-proxy &#39;</pre><ul><li>On the
 GCE VM in Customer GKE/GCE VPC network</li></ul><pre>### If Using AlloyDB Auth Proxy gcloud
 beta alloydb instances describe alloydb-ins-primary-$(date +%d%m%Y) --project=${DB_PROJECT}
 --cluster=alloydb-cls-001 --region=${REGION} --format json | jq .name ./alloydb-auth-proxy
 INST_URI </pre><ul><li>If you are configuring for Cloud SQL, <a href="https://cloud.google.com/sql/docs/postgres/connect-auth-proxy#start-proxy">use
 this public document to start Cloud SQL Auth Proxy</a>.</li><li>On the GCE VM in
 Customer GKE/GCE VPC network</li></ul><pre>### If using AlloyDB Auth Proxy psql
 -h 127.0.0.1 -U postgres postgres ### If using Private IP psql -h &lt;Private
 IP of forwarding rule in Customer GCE/GKE VPC network&gt; -U postgres postgres</pre>This
 method works well. I have tested this multiple times.Performance testing
 is advised before production deployment.<h3>Other notable key points</h3><ul><li>Prefer
 managed PSC enabled AlloyDB over such a manual solution</li><li>NEG used are hybrid
 zonal NEG, so in case of a failover you have to add new zonal NEG to backend service
 of load balancer.</li><li>You can use DMS service to migrate a PSA enabled AlloyDB
 to PSC AlloyDB.</li></ul><h3>References</h3><ul><li><a href="https://cloud.google.com/alloydb/docs/connect-external">Connect
 to a cluster from outside its VPC | AlloyDB for PostgreSQL | Google Cloud</a></li><li><a
 href="https://cloud.google.com/sql/docs/mysql/connect-multiple-vpcs">Connect your
 instance to multiple VPCs | Cloud SQL for MySQL | Google Cloud</a></li><li><a href="https://cloud.google.com/sql/docs/mysql/configure-private-service-connect">Connect
 to an instance using Private Service Connect | Cloud SQL for MySQL | Google Cloud</a></li></ul><img
 src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=3f8eeed51d2a"
 width="1" height="1" alt=""><hr><a href="https://medium.com/google-cloud/connect-to-non-psc-alloydb-or-non-psc-cloud-sql-from-a-different-vpc-3f8eeed51d2a">Connect
 to Non-PSC AlloyDB or Non-PSC Cloud SQL from a different VPC</a> was originally
 published in <a href="https://medium.com/google-cloud">Google Cloud - Community</a>
 on Medium, where people are continuing the conversation by highlighting and responding
 to this story.'

Language

Active

Ricc internal notes

Ricc source

Show this article Back to articles