[[["易于理解","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-21。"],[],[],null,["# About service connection policies\n=================================\n\nThis document explains how network administrators can use service connection\npolicies to provide connectivity to supported managed service instances through\nservice connectivity automation. Before reading this document, ensure that\nyou're familiar with the concepts explained in [About service connectivity\nautomation](/vpc/docs/about-service-connectivity-automation).\n\nSpecifications\n--------------\n\nService connection policies have the following specifications:\n\n- You can create only one service connection policy for each combination of\n network, region, and [service\n class](/vpc/docs/about-service-connectivity-automation#service-class). For\n example, you can have only one service connection policy for `vpc1` in\n `us-central1` for `google-cloud-sql`. This validation means that only one\n service connection policy governs a given Private Service Connect\n endpoint.\n\n- Service instance administrators can use the service's administrative API or\n UI to deploy that service and configure connectivity by using service\n connectivity automation.\n\n- If the creation or deletion of an endpoint through\n service connectivity automation is blocked, an\n [automated process periodically retries the operation](/vpc/docs/about-service-connectivity-automation#endpoint-automation)\n until the blocking issue is resolved.\n\n- The subnets that are included in the service connection policy configuration\n provide IP addresses that are assigned to Private Service Connect\n endpoints. These IP addresses are automatically\n allocated and returned to the subnet's pool as managed service instances are\n created and deleted.\n\n The subnets must be [regular\n subnets](/vpc/docs/subnets#purpose), and they must be in the same region as\n the service connection policy. Regular subnets are different from\n Private Service Connect subnets.\n\n As a best practice, we recommend that you avoid using the subnets for other\n resources. If other resources consume IP addresses from the subnet, you\n might run out of IP addresses to assign to endpoints.\n- Managed services that use service connection policies might support\n [connecting to service instances by using IPv4 endpoints, IPv6 endpoints, or\n both](#ip-versions). If the service supports both IPv4 and IPv6, service\n instance administrators can choose an IP version when deploying a service\n instance.\n\n- You can [use service connection policies with Shared VPC](#shared-vpc).\n\n- By default, the service instance and the endpoints that connect to the\n service instance must be in the same project (or in the case of\n Shared VPC, in connected projects).\n\n Supported Google services let you configure a [custom service instance\n scope](#custom-scope).\n- Endpoints that are created through service connectivity automation might\n have labels applied to them by the service producer. For more information\n about labels, see [Organize resources using\n labels](/compute/docs/labeling-resources).\n\n- If you want to use Private Service Connect service automation with\n multiple VPC networks that are in the same project, create a\n service connection policy for each network.\n\n- You can optionally configure a connection limit to specify the maximum\n number of Private Service Connect connections that a\n given service producer can create in the policy's VPC\n network and region.\n\n- Endpoints that are created through service connection policies can be made\n available in other VPC networks through [connection\n propagation](/vpc/docs/about-propagated-connections).\n\nAuthorization\n-------------\n\nService connection policies let consumers delegate the deployment of\nconnectivity to managed services. The service producer doesn't have direct\naccess or IAM privileges for the consumer project. Instead, the\nproducer configures a service connection map in their own project.\n\nWhen the service connection map is created or updated, typically in response to\na request from a consumer service administrator to the managed service's\nadministrative API or UI, service connectivity automation performs a series of\nauthorization checks. If all of the checks pass,\nPrivate Service Connect endpoints are created as specified in the\nrequest.\n\nFor information about authorization, see\n[Authorization model](/vpc/docs/about-service-connectivity-automation#authorization).\n\nConnection policies in Shared VPC networks\n------------------------------------------\n\nService connection policies can automate connectivity to service instances that\nare located in host projects or in attached service projects.\n\nIf you're using Shared VPC, you must create the service connection\npolicy in the host project. Endpoints are created in the project that is\nspecified in the service instance configuration.\n\nIf you create a service connection policy in a Shared VPC network\nand deploy a service instance in a service project, service\nconnectivity automation shares the subnets that are associated with the\nservice connection policy by updating the service project's\n[Network Connectivity Service Account](/iam/docs/service-agents#network-connectivity-service-account).\nThis service account is granted the\n[Compute Network User role](/compute/docs/access/iam#compute.networkUser)\n(`roles/compute.networkUser`) on the shared subnets.\n\nFor a deployment example, see\n[Shared VPC](/vpc/docs/about-service-connectivity-automation#shared-vpc).\n\nConnection policies with custom service instance scope\n------------------------------------------------------\n\nBy default, service connectivity automation creates endpoints for service\ninstances and associated service connection policies that are in the same\nGoogle Cloud project (or in the case of Shared VPC, in connected projects).\nFor supported Google services, service instances and connecting endpoints\ncan also be in different projects or organizations.\n\nNot all Google services support configuring a custom service instance scope.\nTo determine whether a service supports a custom service instance scope, see the\ndocumentation for the specific service.\n\nUse the **Service instance scope** (`--producer-instance-location`)\nsetting to configure connectivity to service instances that are in other\nResource Manager nodes (projects, folders, and organizations).\n\n- If it's set to `no_producer_instance_location`, endpoints are created in the same project only. This is the default value.\n- If it's set to `custom_resource_hierarchy_levels`, you specify the list of Resource Manager nodes in the `--allowed-google-producers-resource-hierarchy-level` field.\n\nIf you update the service instance scope for a service connection policy,\nexisting endpoints aren't affected.\n\nFor a deployment example, see [Google services with custom service instance\nscope](/vpc/docs/about-service-connectivity-automation#google-custom-scope).\n\nEndpoint IP versions\n--------------------\n\nThe possible IP versions of endpoints that connect to service instances\n(IPv4, IPv6, or both) is determined by the service producer, not by service\nconnectivity automation. If the service supports both IPv4 and IPv6,\nservice instance administrators can choose an IP version when deploying an\ninstance through a service's administrative API.\nFor information about a service's supported IP versions, see the service's\ndocumentation.\n\nWhen a service instance administrator chooses an IP version, service\nconnectivity automation checks the service connection policy for compatible\nsubnets to use for creating endpoint IP addresses:\n\n- IPv4-only subnets support IPv4 endpoints.\n- Dual-stack subnets support both IPv4 and IPv6 endpoints.\n- IPv6-only subnets support IPv6 endpoints.\n\nIf the service connection policy doesn't have a compatible subnet, the request\nfails, and no endpoint is created.\n\nAdditionally, the IP version of the endpoint must be compatible with the IP\nversion of the service instance, which is determined by the associated service\nattachment's forwarding rule. Private Service Connect supports\nthe following IP version combinations:\n\n- IPv4 endpoint to IPv4 service attachment\n- IPv6 endpoint to IPv6 service attachment\n- IPv6 endpoint to IPv4 service attachment\n\n In this configuration, Private Service Connect automatically\n translates between the two IP versions.\n\nConnecting an IPv4 endpoint to an IPv6 service attachment isn't supported.\n\nIf you want to let both IPv4 and IPv6 clients access a managed service instance,\nconfigure connectivity for separate IPv4 and IPv6 endpoints that\nconnect to the same service.\n\nLimitations\n-----------\n\n- Service connection policies only support automating the creation of Private Service Connect endpoints. Creating Private Service Connect backends or service attachments isn't supported.\n- You cannot directly delete Private Service Connect endpoints that are created through service connectivity automation. To trigger deletion of these endpoints, [decommission service connectivity](/vpc/docs/deploy-service-instance-service-connection-policies#decommission-service).\n- You can only update the subnets and connection limit for a service connection policy. If you want to update other fields, [delete the policy](/vpc/docs/configure-service-connection-policies#delete-policy) and [create a new one](/vpc/docs/configure-service-connection-policies#create-policy).\n\nPricing\n-------\n\nPricing for Private Service Connect is described on the\n[VPC pricing page](/vpc/pricing#psc-automation).\n\nWhat's next\n-----------\n\n- [Configure service connection policies](/vpc/docs/configure-service-connection-policies)"]]
