Google 和第三方(统称为“服务提供方”)可以提供托管在 VPC 网络中的服务。通过专用服务访问通道,您可以在自己的 VPC 网络和服务提供方的 VPC 网络之间创建专用连接来访问这些服务。专用服务访问通道流量在 Google 网络内部传输,而不是通过公共互联网传输。如需详细了解如何使用专用服务访问通道,请参阅配置专用服务访问通道。
专用连接将您的 VPC 网络与服务提供方的 VPC 网络相链接。通过此连接,您的 VPC 网络中的虚拟机实例可以使用内部 IPv4 地址来访问服务资源的内部 IPv4 地址。您的实例可以具有外部 IP 地址,但专用服务访问通道不需要且不使用外部 IP 地址。
如果服务提供方提供多种服务,您只需要一个专用连接。创建专用连接时,您会使用 Service Networking API 进行创建。但是, Google Cloud将此连接实现为 VPC 网络与服务提供方 VPC 网络之间的 VPC 网络对等互连连接。您的 VPC 网络将其显示为对等互连连接;要删除该专用连接,您必须删除对等互连连接。
在专用连接的 Google 服务端,Google 会为客户创建一个项目。该项目是独立的,这意味着没有其他客户共享该项目,并且客户只需要为客户预配的资源付费。 Google 还会在此隔离的项目中创建一个 VPC 网络,并使用 VPC 网络对等互连将其连接到客户网络。
每项 Google 服务都会创建一个子网,用于预配资源。子网的 IP 地址范围是在分配的 IP 地址范围内的 CIDR 块。CIDR 块由服务选择,通常具有 /29 到 /24 IP 地址范围。您无法修改服务提供方的子网。服务在现有区域子网(以前由该服务创建)中预配新资源。如果子网已满,该服务便会在同一区域中创建新子网。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-07-26。"],[],[],null,["# Private services access\n=======================\n\nThis page provides an overview of private services access.\n\nGoogle and third parties (together known as *service producers* ) can offer\nservices that are hosted in a VPC network. Private services\naccess lets you reach those services by creating a private connection between\nyour VPC network and the service producer's VPC\nnetwork. Private services access traffic travels internally within\nGoogle's network, not through the public internet. For more information about\nusing private services access, see [Configure private services\naccess](/vpc/docs/configure-private-services-access).\n\nPrivate services access requires you to first allocate an internal IPv4 address\nrange and then create a private connection. An allocated range is a reserved\nCIDR block that can't be used in your local VPC network. It's set\naside for service producers only and prevents overlap between your\nVPC network and the service producer's VPC\nnetwork.\n\nThe private connection links your VPC network with the service\nproducer's VPC network. This connection lets VM instances in your\nVPC network use internal IPv4 addresses to reach the internal\nIPv4 addresses of the service resources. Your instances can have external IP\naddresses, but external IP addresses are not required for, and are not used by,\nprivate services access.\n\nIf a service producer offers multiple services, you only need one private\nconnection. When you create a private connection, you use the\nService Networking API to create it. However, Google Cloud\nimplements this connection as a [VPC Network Peering](/vpc/docs/vpc-peering) connection between your VPC\nnetwork and the service producer's VPC network. Your\nVPC network shows the private connection as a\nVPC Network Peering connection.\n\n\nUsing IPv6 address ranges with private services access is not supported.\n\nYou can use private services access only with services that\n[support](#private-services-supported-services) it. Check with the service\nproducer before creating a private connection.\n\nService producer network\n------------------------\n\nOn the service producer's side of the private connection is a VPC\nnetwork, where your service resources are provisioned. The service producer's\nnetwork is created exclusively for you and contains only your resources.\n\nA resource in the service producer network is similar to other resources in your\nVPC network. For example, it's reachable through internal IP\naddresses by other resources in your VPC network. You can also\ncreate firewall rules in your VPC network to control access to\nthe service producer's network.\n\nFor details about the service producer side, see [Enable private services\naccess](/service-infrastructure/docs/enabling-private-services-access) in the\nService Infrastructure documentation. This documentation is for your information\nonly and is not required for you to enable or use private services access.\n\nPrivate services access and on-premises connectivity\n----------------------------------------------------\n\nIn hybrid networking scenarios, an on-premises network is connected to a\nVPC network either through a\n[Cloud VPN](/network-connectivity/docs/vpn) or\n[Cloud Interconnect](/network-connectivity/docs/interconnect) connection.\nBy default, on-premises hosts can't reach the service producer's network by\nusing private services access.\n\nIn the VPC network, you might have custom static or dynamic\nroutes to correctly direct traffic to your on-premises network. However, the\nservice producer's network doesn't contain those same routes. When you create a\nprivate connection, the VPC network and service producer network\nexchange subnet routes only.\n\nThe service producer's network contains a default route (`0.0.0.0/0`) that\ngoes to the internet. If you export a default route to the service producer's\nnetwork, it is ignored because the service producer network's default route\ntakes precedence. Instead, define and export a custom route with a more specific\ndestination. For more information, see [Routing\norder](/vpc/docs/routes#routeselection).\n\nYou must export the VPC network's custom routes so that the\nservice provider's network can import them and correctly route traffic to your\non-premises network. Update the [VPC peering\nconfiguration](/vpc/docs/using-vpc-peering#update-peer-connection) associated\nwith the private connection to export custom routes.\n\nService transitivity with Network Connectivity Center\n-----------------------------------------------------\n\nFor some services that are available through private services access, you can\nuse Network Connectivity Center to make the service reachable by other spokes on\na hub by creating a *producer VPC spoke* . For more information, including which\nservices are supported, see [Producer VPC spokes](/network-connectivity/docs/network-connectivity-center/concepts/producer-vpc-spokes-overview).\n| **Note:** You can't delete a private services access connection if it's in use by a producer VPC spoke. To delete the connection, you must first delete the producer VPC spoke.\n\nConsiderations\n--------------\n\nBefore you configure private services access, understand the\n[considerations](/vpc/docs/configure-private-services-access#considerations)\nfor choosing a VPC network and IP address range.\n\nSupported services\n------------------\n\nThe following Google services support private services access:\n\n- [AI Platform Training](/ai-platform/training/docs/vpc-peering)\n- [AlloyDB for PostgreSQL](/alloydb/docs/configure-connectivity)\n- [Apigee](/apigee/docs/api-platform/get-started/configure-service-networking)\n- [Backup and DR](/backup-disaster-recovery/docs/configuration/deployment-plan#overview_of_the_service_architecture)\n- [Cloud Build](/build/docs/private-pools/private-pools-overview)\n- [Cloud Intrusion Detection System](/intrusion-detection-system/docs/configuring-ids)\n- [Cloud SQL](/sql/docs/mysql/private-ip) (does not support [DNS\n peering](/vpc/docs/configure-private-services-access#dns-peering))\n- [Cloud TPU](/tpu/docs/shared-vpc-networks)\n- [Converge Enterprise Cloud with IBM Power for Google Cloud](https://console.cloud.google.com/marketplace/product/ibm-sg/ibm-power-cloud-for-gcp)\n- [Filestore](/filestore/docs/networking)\n- [Google Cloud Managed Lustre](/managed-lustre/docs/vpc)\n- [Google Cloud VMware Engine](/vmware-engine/docs/networking/howto-setup-private-service-access)\n- [Looker (Google Cloud core)](/looker/docs/looker-core-create-private-ip)\n- [Memorystore for Memcached](/memorystore/docs/memcached/establishing-connection)\n- [Memorystore for Redis](/memorystore/docs/redis/establishing-connection)\n- [Vertex AI](/vertex-ai/docs/general/vpc-peering)\n\n| **Note:** When you use private services access as a service consumer, you are solely responsible for securing your VPC networks and all resources and data available on them. Google is not responsible for how your data and resources may be accessed or used by the third party that you are connecting with.\n\nExample\n-------\n\nIn the following example, the customer VPC network allocated the `10.240.0.0/16`\naddress range for Google services and established a private connection that uses\nthe allocated range. Each Google service creates a subnet from the allocated\nblock to provision new resources in a given region, such as Cloud SQL\ninstances.\n[](/static/vpc/images/private-services-access-sql.svg) Private services access (click to enlarge).\n\n- The private connection is assigned the `10.240.0.0/16` allocated range. From this allocation, Google services can create subnets where new resources are provisioned.\n- On the Google services side of the private connection, Google creates a project for the customer. The project is isolated, meaning no other customers share it and the customer is billed for only the resources the customer provisions. Google also creates a VPC network in this isolated project and connects it to the customer network by using VPC Network Peering.\n- Each Google service creates a subnet in which to provision resources. The subnet's IP address range is a CIDR block that comes from the allocated IP address range. The CIDR block is chosen by the service, and typically has a `/29` to `/24` IP address range. You cannot modify the service producer's subnet. A service provisions new resources in existing regional subnets that were previously created by that service. If a subnet is full, the service creates a new subnet in the same region.\n- After the subnet is created, the customer network imports routes from the service network.\n- VM instances in the customer's network can access service resources in any region if the service supports it. Some services might not support cross-region communication. See the relevant service's documentation for more information.\n- The Cloud SQL instance is assigned the IP address `10.240.0.2`. In the Customer VPC network, requests with a destination of `10.240.0.2` are routed to the private connection over to the service producer's network. After reaching the service network, the service network contains routes that direct the request to the correct resource.\n- Traffic between VPC networks travels internally within Google's network, not through the public internet.\n\nPricing\n-------\n\nFor private services access pricing, see\n[Private services access](/vpc/pricing#psa-pricing) on the VPC\npricing page.\n\nWhat's next\n-----------\n\n- To allocate IP address ranges, create private connections, or share private DNS zones, see [Configure\n private services access](/vpc/docs/configure-private-services-access)."]]