服務用戶在建立私人連線時,還必須提供分配的 IP 位址範圍。這個分配範圍是用來保留只有您 (服務供應商) 可使用的 IP 位址。舉例來說,當服務用戶布建資源時,您可以使用 Service Networking 在共用虛擬私人雲端網路中建立子網路,接著,Service Networking 會從分配的範圍中自動選取一個範圍做為子網路的 IP 位址範圍。這項程序可避免共用虛擬私人雲端網路和服務用戶虛擬私人雲端網路之間發生衝突。
共用虛擬私人雲端服務專案
您的代管服務在首次布建服務用戶的資源時,會將資源布建到與 Service Networking 主專案連結的共用虛擬私人雲端服務專案中。服務專案中的資源可透過這個共用虛擬私人雲端關係,使用共用虛擬私人雲端網路中的子網路。
代管服務會在獨立租用環境和預先指定 (在啟用程序中指定) 的資料夾中建立服務專案。這個資料夾和獨立租用環境和您的代管服務相關,與 Service Networking 使用的並不相同。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-09-04 (世界標準時間)。"],[],[],null,["# Enabling private services access\n\nAs a service producer, you can allow service consumers to provision resources\nwith private (RFC 1918) or public IP addresses. If service consumers want to use\nprivate IP addresses, they must use [private services\naccess](/vpc/docs/private-services-access). However, service\nconsumers can only use private service access if your managed service\noffers it. To offer private connectivity, you must complete a one-time\n[onboarding process](#onboarding).\n\nThe onboarding process requires you to use the Service Networking\nAPI and tenancy units. For detailed step-by-step instructions, contact your\nGoogle representative.\n\nOverview\n--------\n\nThe following sections describe the components and general network topology\nrequired to enable private services access for your managed service.\n\n### Tenancy units\n\nWhen a service consumer enables your managed service, the service create a\n[tenancy unit](/service-infrastructure/docs/tenancy-units-tutorial) to formalize\na relationship between your Google Cloud organization and the service\nconsumer's project. Tenancy units isolate resources and billing costs between\ndifferent service consumers.\n\nFor each service consumer, you will have two tenancy units. One for your managed\nservice and another for the private access management service. The managed\nservice is the external service that you're offering to service consumers, and\nthe private access management service manages private connections with service\nconsumer VPC networks. These tenancy units must be in the same\nGoogle Cloud organization where your managed service lives.\n\n### Service Networking\n\nService Networking automates the private connectivity set up\n(using VPC Network Peering) between you and the service consumer. You enable and\nuse Service Networking in the same project in which you created\nthe private access management service. This is a different project from the one\nthat contains your managed service.\n\nWhen a service consumer creates a private connection with your managed service,\nService Networking creates a *Shared VPC host project* and a\n*Shared VPC network* for you. The host project and network are created in a\npredesignated Google Cloud folder in your organization. You specify this\nfolder name as part of the onboarding process. The project and network are\ncontained in a tenancy unit, so they are isolated and can only be used by that\nservice consumer.\n\nAfter Service Networking creates the Shared VPC network,\nService Networking automatically creates a VPC\nNetworking Peering connection between the Shared VPC network and the service\nconsumer-specified VPC network.\n\nService consumers must also supply an allocated IP address range when they\ncreate the private connection. This allocation reserves IP addresses that can\nonly be used by you, a service producer. For example, when a service consumer\nprovisions a resource, you use Service Networking to create\nsubnets in the Shared VPC network. For the subnet's IP address range,\nService Networking automatically selects a range from the\nallocated range. This process prevents collisions between the Shared VPC network\nand service consumer VPC network.\n| **Note:** Creating a subnet is a long running operation. You can [poll](/service-infrastructure/docs/polling-operations) it regularly to check the status of the operation.\n\n#### Shared VPC service projects\n\nWhen your service provisions a service consumer's resource for the first time,\nyour managed service provisions it in a [Shared VPC service\nproject](/vpc/docs/shared-vpc), which is attached to the\nService Networking host project. This Shared VPC relationship\nenables resources in the service project to use subnets in the Shared VPC\nnetwork.\n\nYour managed service creates the service project in a tenancy unit and\npredesignated folder, specified during the onboarding process. The folder and\ntenancy unit are related to your managed service and are different from the ones\nthat Service Networking uses.\n\n### Network topology\n\nThe following example shows a single service consumer that has private\nconnectivity to a single service producer. The service consumer provisioned two\nresources in different regions. Because each resource is in a different region,\nthey are in different subnets.\n[](/static/service-infrastructure/images/service-networking-overview.svg) Overview of Service Networking for service producers (click to enlarge)\n\n- There are two Endpoints projects: one for the managed service\n and another one for the private access management service. These must be in\n the same Google Cloud organization.\n\n- Within the Google Cloud organization, there are two folders, one for\n each of the Endpoints services. The private access management\n service folder contains a Shared VPC host project for the private connection.\n The managed service folder contains a service project for service consumer\n resources.\n\n - In each folder, the service consumer-related projects are contained in tenancy units. Both tenancy units are associated with `consumer-project-a`.\n- Service consumers must initiate the private connection (which is also a\n VPC Network Peering connection). They must supply an allocated\n IP address range for the private connection from which the subnet IP addresses\n come. For more information about the service consumer steps, see [Configuring\n Private Services Access](/vpc/docs/configure-private-services-access).\n\n - If you offer multiple services, service consumers only need one private connection. All traffic to and from the service consumer goes through the Shared VPC host project.\n- In a single service consumer project, multiple VPC networks can\n privately connect to your services. This requires a Shared VPC\n host project for each connected VPC network. However, all of\n those projects can be contained in the same `consumer-project-a` tenancy unit.\n\n- In the host project, you must configure firewall rules and routes to enable\n connectivity to new resources. Because other services can use the same Shared\n VPC network, these rules can allow or deny connectivity between\n your different services.\n\nOnboarding process\n------------------\n\nThe following list is a general outline of the onboarding process. You must\ncomplete this process for each managed service that will offer private\nconnectivity. Contact your Google representative for more information.\n\n1. Create a peering management service.\n\n This is a managed service that a service producer builds through\n the Service Management and Endpoints API. For more\n information, contact your Google representative.\n2. Provide the following configuration information to your Google\n representative:\n\n - The minimum IP address range that service consumers must allocate when they connect to you, specified as an IPv4 prefix length. If you offer multiple services, you might want users to allocate a larger IP address range, such as `/16`.\n - The folder ID where your private access management service creates Shared VPC hosts projects. Use Resource Manager to find the folder ID.\n - The billing account that's associated with the organization where your private access management service creates Shared VPC host projects.\n - The principals (typically these are service account IDs) that manage the host project's network firewall rules.\n3. Activate the Compute Engine API.\n\n For each Shared VPC host project, activate the\n `compute.googleapis.com` API, which you can do by using the\n Service Usage APIs or in the project configuration.\n\n After resources have been provisioned, configure firewall rules for the\n Shared VPC network in the host project. You must use the identity that you\n provided during the onboarding process to access the VPC network. If you\n offer other services, those services might use the same VPC network. Don't\n create rules that might inadvertently allow or deny traffic to other\n services.\n4. Inform service consumers.\n\n Inform service consumers that they must establish a private connection. For\n more information, see [Configuring Private Services\n Access](/vpc/docs/private-access-options). Service consumers must provide\n the following information:\n - The name of their project and network where they want to establish private connectivity.\n - The Cloud region where the resource must be provisioned.\n\nWhat's next\n-----------\n\n- To enable Service Networking APIs, see [Getting Started with the\n Service Networking\n API](/service-infrastructure/docs/service-networking/getting-started).\n- For information about Service Networking private connection limits, see [Quotas and\n Limits](/service-infrastructure/docs/quotas#networking)."]]