서비스 제작자는 서비스 소비자가 비공개(RFC 1918) 또는 공개 IP 주소로 리소스를 프로비저닝하도록 허용할 수 있습니다. 비공개 IP 주소를 사용하려는 서비스 소비자는 비공개 서비스 액세스를 사용해야 합니다. 하지만 서비스 소비자는 관리형 서비스가 제공하는 경우에만 비공개 서비스 액세스를 사용할 수 있습니다. 비공개 연결을 제공하려면 일회성 온보딩 프로세스를 완료해야 합니다.
온보딩 프로세스를 수행하려면 Service Networking API 및 테넌시 유닛을 사용해야 합니다. 자세한 단계별 지침은 Google 담당자에게 문의하세요.
개요
다음 섹션에서는 관리형 서비스에 비공개 서비스 액세스를 사용 설정하는 데 필요한 구성요소 및 일반 네트워크 토폴로지를 설명합니다.
테넌시 유닛
서비스 소비자가 관리형 서비스를 사용 설정하면 서비스가 테넌시 유닛을 만들어 Google Cloud 조직과 서비스 소비자 프로젝트 간의 관계를 공식화합니다. 테넌시 유닛은 서비스 소비자별로 리소스와 청구 비용을 분리합니다.
각 서비스 소비자에는 두 개의 테넌시 유닛이 있습니다. 하나는 관리형 서비스용이고 다른 하나는 비공개 액세스 관리 서비스용입니다. 관리형 서비스는 서비스 소비자에게 제공하는 외부 서비스이며, 비공개 액세스 관리 서비스는 서비스 소비자 VPC 네트워크와의 비공개 연결을 관리합니다. 이 테넌시 유닛은 관리 서비스가 있는 동일한Google Cloud 조직에 있어야 합니다.
서비스 네트워킹
서비스 네트워킹은 서비스 제작자와 서비스 소비자 간의 비공개 연결 설정(VPC 네트워크 피어링 사용)을 자동화합니다. 비공개 액세스 관리 서비스를 만든 프로젝트에서 서비스 네트워킹을 사용 설정하고 사용하세요. 이는 관리형 서비스가 포함된 프로젝트와 다른 프로젝트입니다.
서비스 소비자가 관리형 서비스와의 비공개 연결을 설정하면 서비스 네트워킹은 공유 VPC 호스트 프로젝트와 공유 VPC 네트워크를 자동으로 생성합니다. 호스트 프로젝트 및 네트워크는 조직의 미리 지정된 Google Cloud 폴더에 생성됩니다. 이 폴더 이름은 온보딩 프로세스 중에 지정합니다. 프로젝트와 네트워크는 테넌시 유닛에 포함되어 있으므로 격리되어 있으며 해당 서비스 소비자만 사용할 수 있습니다.
서비스 네트워킹은 공유 VPC 네트워크를 만든 후 공유 VPC 네트워크와 서비스 소비자의 VPC 네트워크 사이에 VPC 네트워킹 피어링 연결을 자동으로 설정합니다.
서비스 소비자는 비공개 연결을 설정할 때 할당된 IP 주소 범위도 지정해야 합니다. 이 할당은 서비스 제작자만 사용할 수 있는 IP 주소를 예약합니다. 예를 들어 서비스 소비자가 리소스를 프로비저닝할 때 서비스 제작자는 서비스 네트워킹을 사용하여 공유 VPC 네트워크에 서브넷을 만듭니다. 서브넷의 IP 주소 범위는 할당된 범위 내에서 서비스 네트워킹이 자동으로 선택합니다. 이 프로세스는 공유 VPC 네트워크와 서비스 소유자 VPC 네트워크 간의 충돌을 방지합니다.
공유 VPC 서비스 프로젝트
서비스에서 처음으로 서비스 소비자의 리소스를 프로비저닝하면 관리형 서비스가 서비스 네트워킹 호스트 프로젝트에 연결된 공유 VPC 서비스 프로젝트에 해당 리소스를 프로비저닝합니다. 이러한 공유 VPC 관계를 통해 서비스 프로젝트의 리소스가 공유 VPC 네트워크의 서브넷을 사용할 수 있습니다.
관리형 서비스는 온보딩 프로세스 중에 미리 지정된 폴더와 테넌시 유닛에 서비스 프로젝트를 만듭니다. 이 폴더와 테넌시 유닛은 관리형 서비스와 관련이 있으며 서비스 네트워킹이 사용하는 것과는 다릅니다.
네트워크 토폴로지
다음 예에서는 단일 서비스 제작자에 대한 비공개 연결이 설정된 단일 서비스 소비자를 보여줍니다. 이 서비스 소비자는 여러 리전에 두 개의 리소스를 프로비저닝했습니다. 각 리소스는 다른 리전에 있으므로 다른 서브넷에 있습니다.
서비스 제작자의 서비스 네트워킹 개요(확대하려면 클릭)
엔드포인트 프로젝트는 두 개가 있는데, 하나는 관리형 서비스용이고 다른 하나는 비공개 액세스 관리 서비스용입니다. 이는 동일한 Google Cloud 조직에 있어야 합니다.
Google Cloud 조직 내에는 각 Endpoints 서비스당 하나씩 총 두 개의 폴더가 있습니다. 비공개 액세스 관리 서비스 폴더에는 비공개 연결용 공유 VPC 호스트 프로젝트가 있습니다.
관리형 서비스 폴더에는 서비스 소비자 리소스용 서비스 프로젝트가 포함됩니다.
각 폴더에서 서비스 소비자 관련 프로젝트는 테넌시 유닛에 포함됩니다. 두 테넌시 유닛이 모두 consumer-project-a와 연결됩니다.
서비스 소비자는 비공개 연결(VPC 네트워크 피어링 연결이기도 함)을 시작해야 합니다. 서브넷 IP 주소가 수신되는 비공개 연결에 할당된 IP 주소 범위를 제공해야 합니다. 서비스 소비자 단계에 대한 자세한 내용은 비공개 서비스 액세스 구성을 참조하세요.
여러 서비스를 제공하는 경우 서비스 소비자는 하나의 비공개 연결만 필요로 합니다. 서비스 소비자와 주고받는 모든 트래픽은 공유 VPC 호스트 프로젝트를 거칩니다.
단일 서비스 소비자 프로젝트에서 여러 VPC 네트워크가 비공개로 서비스에 연결할 수 있습니다. 이 경우 연결된 VPC 네트워크마다 공유 VPC 호스트 프로젝트가 필요합니다. 그러나 이러한 프로젝트 모두 동일한 consumer-project-a 테넌시 유닛에 포함될 수 있습니다.
호스트 프로젝트에서 방화벽 규칙 및 경로를 구성하여 새 리소스에 대한 연결을 사용 설정해야 합니다. 다른 서비스가 동일한 공유 VPC 네트워크를 사용할 수 있으므로 이러한 규칙은 서로 다른 서비스 간의 연결을 허용하거나 거부할 수 있습니다.
온보딩 프로세스
다음은 온보딩 프로세스의 일반적인 개요 목록입니다. 비공개 연결을 제공할 관리형 서비스마다 이 프로세스를 완료해야 합니다. 자세한 내용은 Google 담당자에게 문의하세요.
피어링 관리 서비스를 만듭니다.
이는 서비스 제작자가 Service Management and Endpoints API를 통해 빌드하는 관리형 서비스입니다. 자세한 내용은 Google 담당자에게 문의하세요.
Google 담당자에게 다음 구성 정보를 제공합니다.
서비스 소비자가 서비스 제작자에게 연결할 때 할당해야 하는 최소 IP 주소 범위(IPv4 프리픽스 길이로 지정). 여러 서비스를 제공하는 경우 사용자가 /16과 같이 더 큰 IP 주소 범위를 할당하도록 하는 것이 좋습니다.
비공개 액세스 관리 서비스가 공유 VPC 호스트 프로젝트를 만드는 폴더 ID. Resource Manager를 사용하여 폴더 ID를 확인하세요.
비공개 액세스 관리 서비스가 공유 VPC 호스트 프로젝트를 만드는 조직과 연결된 결제 계정
호스트 프로젝트의 네트워크 방화벽 규칙을 관리하는 주 구성원(일반적으로 서비스 계정 ID)
Compute Engine API를 활성화합니다.
각 공유 VPC 호스트 프로젝트에 대해 compute.googleapis.com API를 활성화합니다. 이 작업은 Service Usage API를 사용하거나 프로젝트 구성에서 수행할 수 있습니다.
리소스가 프로비저닝된 후 호스트 프로젝트에 공유 VPC 네트워크의 방화벽 규칙을 구성합니다. VPC 네트워크에 액세스할 때는 온보드 프로세스 중에 지정한 ID를 사용해야 합니다. 다른 서비스를 제공하는 경우 해당 서비스가 동일한 VPC 네트워크를 사용할 수도 있습니다. 다른 서비스로 가는 트래픽을 실수로 허용하거나 거부할 수 있는 규칙을 만들지 마세요.
서비스 소비자에게 알려줍니다.
서비스 소비자에게 비공개 연결을 설정해야 한다고 알려주세요. 자세한 내용은 비공개 서비스 액세스 구성을 참조하세요. 서비스 소비자는 다음 정보를 제공해야 합니다.
[[["이해하기 쉬움","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(UTC)"],[],[],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)."]]
