This page provides an overview of the ways in which you can connect to your AlloyDB for PostgreSQL instance using private IP addresses.
Using private IP addresses keeps your data traffic within a secured network and minimizes risk of interception. A resource's internal IP address, being internal to its network and inaccessible from the internet, effectively limits both its scope of accessing an AlloyDB instance and potential attack surface.
Private IP connectivity methods
To access your AlloyDB instances using private IP, you can choose either private services access or Private Service Connect. Since each connection method offers distinct advantages and trade-offs, use the information in this document to choose the best approach for your specific requirements.
Private services access
Private services access is implemented as a Virtual Private Cloud (VPC) peering connection between your VPC network and the underlying Google Cloud VPC network where your AlloyDB for PostgreSQL instance resides. The private connection enables VM instances in your VPC network and the services that you access to communicate exclusively by using internal IP addresses. VM instances don't need Internet access or external IP addresses to reach services that are available through private services access.
To automate the setup of AlloyDB clusters with private services access using Terraform, see Deploy AlloyDB using Terraform.
For more information about using private services access for connectivity, see Private services access overview.
Private Service Connect
Private Service Connect lets you create private and secure connections between your VPC networks and the Google Cloud service, such as AlloyDB for PostgreSQL. You can connect to your AlloyDB instance from multiple VPC networks that belong to different groups, teams, projects, or organizations. When you create an AlloyDB cluster, you can enable it to support Private Service Connect. When creating an AlloyDB instance within the cluster, you specify which projects from your VPC network can access it.
For more information about using Private Service Connect, see Private Service Connect overview and the video What is Private Service Connect?.
Choose between methods to use
Before you make a decision about whether to use private services access or Private Service Connect as your connection method, consider the following comparison:
Private services access | Private Service Connect |
---|---|
Requires reserving a CIDR range (/24 at a minimum) from the consumer VPC. A range of IPs is reserved regardless of whether they are in use, leading to lock on all IP addresses in the range. | Requires a single IP address to create a forwarding rule at the endpoint per VPC network. |
Limited to RFC 1918 IP ranges | Both RFC 1918 and Non-RFC 1918 ranges can be used for endpoints. |
Connect to projects within the same VPC network. | Connect across multiple VPCs or projects. |
Opt for small-scale, single-VPC scenarios. | Opt for large-scale, multi-VPC setups. |
Minimal cost since you use existing VPC peering included in your project. | More expensive as compared to private services access due to costs involved in initial setup, use of each endpoint per hour, and data transfer per GiB. |
Less secure compared to Private Service Connect due to direct connection. | More secure due to isolation of consumer and producer VPC. |
Connections are bi-directional allowing inbound and outbound connections. | Connections are unidirectional allowing inbound connections only. |
What's next
- Private services access overview
- Private Service Connect overview
- Watch a Cloud Skills Boost video to learn how to use private services access to provide access to producer services.