Network Connectivity Center를 통한 Private Service Connect 연결 전파
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
Private Service Connect를 사용하면 소비자가 Virtual Private Cloud(VPC) 내부에서 비공개로 관리형 서비스에 액세스할 수 있습니다. 마찬가지로 이를 이용해 관리형 서비스 프로듀서는 별도의 개별 VPC 네트워크 및 프로젝트에서 이러한 서비스를 호스팅하고 소비자에게 비공개 연결을 제공할 수 있습니다.
Private Service Connect 연결은 VPC 스포크 간에 전이되지 않습니다. Network Connectivity Center 허브를 통해 Private Service Connect 서비스를 전파하면 동일한 허브의 다른 스포크 VPC에서 라우트 테이블을 통해 이러한 서비스에 액세스할 수 있습니다.
Network Connectivity Center Private Service Connect 연결 전파 기능은 다음과 같은 사용 사례에 이점을 제공합니다.
공통 서비스 VPC 네트워크를 사용하여 여러 Private Service Connect 소비자 엔드포인트를 만들 수 있습니다. 단일 공통 서비스 VPC 네트워크를 Network Connectivity Center 허브에 추가하면 VPC 네트워크의 모든 Private Service Connect 소비자 엔드포인트에 있는 Network Connectivity Center 허브를 통해 다른 VPC 스포크에서 전환하여 액세스할 수 있습니다. 이 연결을 사용하면 각 VPC 네트워크에서 각 Private Service Connect 엔드포인트를 개별적으로 관리할 필요가 없습니다.
하이브리드 스포크에서 연결할 수 있는 온프레미스 네트워크에서 VPC 스포크 네트워크의 관리형 서비스에 액세스할 수 있습니다.
VPC 스포크를 전파된 연결이 사용 설정된 허브에 연결하면 Network Connectivity Center가 엔드포인트의 서브넷이 제외되지 않는 한 동일한 허브에 연결된 모든 엔드포인트에 대해 해당 스포크에서 전파된 연결을 만듭니다. 엔드포인트의 서브넷이 내보내기에서 제외되지 않는 한, VPC 네트워크가 Network Connectivity Center 허브에 VPC 스포크로 추가되면 새로운 Private Service Connect 엔드포인트도 전파됩니다.
Private Service Connect 전파 연결을 활성화하도록 허브를 설정하려면 허브 관리자가 Private Service Connect 전파를 사용하여 허브를 만들거나, --export-psc 플래그를 사용하여 전파 설정을 업데이트해야 합니다. 그런 다음 허브 관리자가 VPC 네트워크를 허브에 스포크로 추가해야 합니다. 스포크 소유자는 --exclude-export-ranges 및 --include-export-ranges 플래그를 사용하여 Network Connectivity Center 라우팅에서 특정 Private Service Connect 할당 서브넷을 제외하여 다른 VPC 네트워크에서 특정 서브넷에 연결할 수 없도록 하여 로컬 VPC 네트워크에 대해 비공개로 유지할 수 있습니다.
Private Service Connect 전파 연결에 대한 자세한 내용은 전파된 연결 정보를 참고하세요.
--exclude-export-ranges 및 --include-export-ranges 플래그에 대한 자세한 내용은 내보내기 필터를 사용한 VPC 연결을 참고하세요.
Private Service Connect 전파 연결을 위한 허브 설정에 대한 자세한 내용은 허브 구성을 참조하세요.
Private Service Connect 전파 연결을 사용 설정하기 전에 다음을 고려하세요.
Private Service Connect 전파된 연결은 VPC 스포크에서만 작동합니다.
VPC 스포크 간 Private Service Connect IPv6 전파 연결은 지원되지 않습니다.
하이브리드 스포크에 연결된 온프레미스 네트워크에서 전파된 Private Service Connect 연결을 사용할 수 있어야 하는 경우 다음 단계를 따르세요.
Network Connectivity Center 허브에는 모든 하이브리드 스포크가 포함된 라우팅 VPC 네트워크가 하나만 있어야 합니다.
허브의 단일 라우팅 VPC 네트워크도 VPC 스포크여야 합니다.
허브에 라우팅 VPC 네트워크가 2개 이상 있는 경우 라우팅 VPC 네트워크 중 어느 것도 VPC 스포크가 될 수 없습니다.
따라서 라우팅 VPC 네트워크가 2개 이상인 허브는 온프레미스 네트워크에 전파된 Private Service Connect 연결을 제공할 수 없습니다.
Private Service Connect 전파가 하이브리드 스포크와 함께 작동하려면 라우팅 VPC 네트워크도 VPC 스포크로 추가해야 합니다.
스포크가 만들어진 후에는 해당 스포크에 대해 --exclude-export-ranges 필터를 변경할 수 없으므로, Private Service Connect 엔드포인트를 호스팅할 서브넷을 두 개(하나는 VPC 내 네트워크 전용 Private Service Connect 엔드포인트용 서브넷, 다른 하나는 허브에 공유되는 Private Service Connect 엔드포인트용 서브넷)를 만드는 것이 좋습니다. 허브에 VPC 네트워크를 스포크로 추가하는 경우, 허브와 공유되지 않도록 VPC 네트워크 내 전용 VPC 네트워크를 호스팅하는 서브넷의 IP 주소 범위를 --exclude-export-ranges 필터에 추가하세요.
VPC 스포크의 서브넷이 Network Connectivity Center 허브에 액세스하도록 Private NAT로 구성된 경우 서브넷에서 전파된 Private Service Connect 서비스로의 트래픽이 삭제됩니다.
Private NAT 게이트웨이가 --nat-all-subnet-ip-ranges로 구성된 경우 Network Connectivity Center를 통한 Private Service Connect 전파가 이 스포크 VPC의 일부 서브넷에서 작동하지 않습니다. 이 VPC 스포크의 겹치지 않는 서브넷에서 작동하도록 하려면 Private NAT 게이트웨이에 --nat-custom-subnet-ip-ranges를 사용하세요. 겹치지 않는 서브넷에서 Network Connectivity Center 허브로 트래픽을 라우팅하는 데 NAT를 사용하지 마세요.
짧은 시간 내에 Private Service Connect 엔드포인트를 만들고 삭제한 후 다시 만들면 적용 상태가 정확하지 않을 수 있습니다. 그러나 시간이 지나면 전파 상태가 정확해지고 전파된 연결의 실제 상태를 반영합니다. 여기에는 최대 15분이 소요될 수 있습니다.
스포크 생성 또는 삭제 후 Private Service Connect 연결 전파는 비동기식입니다. VPC 스포크가 허브에서 삭제되면 전파된 Private Service Connect 연결을 업데이트하는 데 다소 시간이 걸릴 수 있습니다. Private Service Connect 전파 연결 업데이트가 진행되는 동안 VPC 스포크가 새 허브에 추가된 후에도 VPC 네트워크 내 VM의 트래픽이 백엔드로 전송될 수 있습니다.
백엔드로의 트래픽 흐름을 방지하려면 스포크를 다른 허브에 추가하기 전에 이전 허브의 VPC 네트워크에 대한 모든 전파 상태 항목(소스 스포크 또는 타겟 스포크)이 삭제되었는지 확인하세요.
Private Service Connect 연결 전파 상태
Network Connectivity Center를 사용하면 Network Connectivity Center 허브 내에서 Private Service Connect 연결 전파 상태를 볼 수 있습니다.
상태 요약을 보거나 특정 오류를 드릴다운하여 오류 세부정보를 볼 수 있습니다.
다음 표에는 전파 상태 코드와 그 의미가 나와 있습니다.
코드
메시지
레디
전파된 Private Service Connect 연결이 준비되었습니다.
전파 중
Private Service Connect 연결 전파가 대기 중입니다. 이는 일시적인 상태입니다.
오류, 프로듀서 전파된 연결 한도 초과
대상 스포크의 VPC 네트워크 또는 프로젝트가 프로듀서가 설정한 전파 연결 한도를 초과하여 전파된 Private Service Connect 연결 전파에 실패했습니다. 이 문제를 해결하려면 프로듀서의 문서를 참고하거나 프로듀서 지원팀에 문의하세요.
오류, 프로듀서 NAT IP 공간 소진됨
NAT IP 서브넷 공간이 소진되어 Private Service Connect 연결 전파에 실패했습니다. PSC 연결의 Needs attention 상태와 같습니다. 자세한 내용은 Private Service Connect 문서의 연결 상태를 참고하세요.
오류, 프로듀서 할당량 초과
프로듀서 VPC 네트워크의 PSC_ILB_CONSUMER_FORWARDING_RULES_PER_PRODUCER_NETWORK 할당량을 초과하여 Private Service Connect 연결 전파에 실패했습니다.
오류, 소비자 할당량 초과
소비자 VPC 네트워크의 PSC_PROPAGATED_CONNECTIONS_PER_VPC_NETWORK 할당량을 초과하여 Private Service Connect 연결 전파에 실패했습니다.
[[["이해하기 쉬움","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-08-12(UTC)"],[],[],null,["# Private Service Connect connection propagation through Network Connectivity Center\n\n[Private Service Connect](/vpc/docs/private-service-connect)\nlets *consumers* access *managed services* privately from\ninside their Virtual Private Cloud (VPC) network. Similarly, it lets managed service\n*producers* host these services in their own separate VPC\nnetworks and projects and offer a private connection to their consumers.\nPrivate Service Connect connections aren't transitive between\nVPC spokes. The\npropagation of Private Service Connect services through the\nNetwork Connectivity Center hub enables these services to be reachable by any other\nspoke VPC in the same hub through the route table.\n\nNetwork Connectivity Center also supports regional endpoint propagation. For more\ninformation about regional endpoints, see\n[About accessing regional endpoints through Private Service Connect endpoints](/vpc/docs/about-accessing-regional-google-apis-endpoints).\n\nThe Network Connectivity Center Private Service Connect connection\npropagation feature benefits the following use cases:\n\n- You can use a common services VPC network to create multiple\n Private Service Connect consumer endpoints. By adding a single\n common services VPC network to the Network Connectivity Center hub, all\n Private Service Connect consumer endpoints in the VPC\n network become transitively accessible to other VPC spokes\n through the Network Connectivity Center hub. This connectivity eliminates the need to\n individually manage each Private Service Connect endpoint in\n each VPC network.\n\n- You can access managed services in a VPC spoke network from\n on-premises networks that are reachable by hybrid spokes.\n\nWhen you connect a VPC spoke to a hub that has propagated\nconnections enabled, Network Connectivity Center creates propagated\nconnections in that spoke for any endpoints that are\nattached to the same hub, unless the endpoint's subnet is excluded from being\nexported. After a VPC network is added to a Network Connectivity Center\nhub as a VPC spoke, new Private Service Connect\nendpoints are also propagated, unless the endpoint's subnet is excluded from\nexport.\n\nTo set up a hub with a Private Service Connect propagated connection\nenabled, the hub administrator must [create a hub](/network-connectivity/docs/network-connectivity-center/how-to/vpc-configure-hub)\nwith Private Service Connect propagation or update the\npropagation setting by using the\n`--export-psc` flag. Then the hub administrator must\nadd the VPC networks as spokes to the hub. The spoke owner\ncan use the `--exclude-export-ranges` and `--include-export-ranges` flags to exclude specific\nPrivate Service Connect allocated subnets from the\nNetwork Connectivity Center routing so that specified subnets can't be reached from other\nVPC networks, thus keeping them private to the local\nVPC network.\n| **Note:** Connections are propagated asynchronously and could take up to 24 hours to propagate.\n\nFor information about Private Service Connect propagated\nconnections, see [About propagated connections](/vpc/docs/about-propagated-connections).\n\nFor information about the `--exclude-export-ranges` and\n`--include-export-ranges` flags, see [VPC connectivity with export filters](/network-connectivity/docs/network-connectivity-center/concepts/vpc-spokes-overview#vpc-connectivity-with-export-filters).\n\nFor detailed information about setting up a hub for a Private Service Connect\npropagated connection, see [Configure a hub](/network-connectivity/docs/network-connectivity-center/how-to/vpc-configure-hub).\n\nConnection propagation limit\n----------------------------\n\nFor details about propagated connection limits, see\n[Propagated connection limit](/vpc/docs/about-vpc-hosted-services#propagated-connection-limit).\n\nConsiderations\n--------------\n\nConsider the following before you enable a Private Service Connect\npropagated connection:\n\n- A Private Service Connect propagated connection works only with\n VPC spokes.\n\n- Private Service Connect IPv6 propagated connections across\n VPC spokes aren't supported.\n\n- If you need to make propagated Private Service Connect\n connections available to on-premises networks connected to hybrid spokes:\n\n - Your Network Connectivity Center hub must have only one [routing\n VPC\n network](/network-connectivity/docs/network-connectivity-center/concepts/dynamic-route-exchange-with-vpc-spokes#routing-vpc) that contains all of\n its hybrid spokes.\n\n - The hub's single routing VPC network must also be a\n VPC spoke.\n\n If a hub has two or more routing VPC networks, none of the\n routing VPC networks can also be VPC spokes.\n Consequently, hubs with two or more routing VPC networks can't\n make propagated Private Service Connect connections available\n to on-premises networks.\n- For Private Service Connect propagation to work with hybrid\n spokes, the routing VPC network must also be added as a\n VPC spoke.\n\n- Because the `--exclude-export-ranges` filter is not mutable for a spoke after\n the spoke is created, we recommend that you create two subnets to host\n Private Service Connect endpoints---one subnet for\n within-VPC-network-only Private Service Connect\n endpoints and the other for the Private Service Connect\n endpoints shared to the hub. When you add the VPC network to a\n hub as a spoke, add the IP address range of the subnet that hosts the\n within-VPC-network-only VPC network to the\n `--exclude-export-ranges` filter so that it is not shared with the hub.\n\n- Private Service Connect endpoints using privately used public\n IP address ranges aren't propagated to the Network Connectivity Center hub.\n\n- If a subnet in a VPC spoke is configured with Private NAT\n to access the Network Connectivity Center hub, the traffic from the subnet to the\n propagated Private Service Connect service is dropped.\n If the Private NAT gateway is configured with `--nat-all-subnet-ip-ranges`,\n then Private Service Connect propagation through\n Network Connectivity Center doesn't work for all subnets in this spoke\n VPC. To get it to work from non-overlapping subnets of this\n VPC spoke, use `--nat-custom-subnet-ip-ranges` for the\n Private NAT gateway. Don't use NAT to route traffic from\n non-overlapping subnets to the Network Connectivity Center hub.\n\n- The propagation status might be inaccurate if you\n create, delete, and re-create the Private Service Connect\n endpoint within a short timeframe. However, after some time,\n the propagation status becomes accurate and reflects the actual state of the\n propagated connection. This could take up to 15 minutes.\n\n- Private Service Connect connection propagation is asynchronous\n after spoke creation or deletion. When a VPC spoke is removed\n from a hub, it can take some time to update propagated\n Private Service Connect connections. While the\n Private Service Connect propagation connection update is\n in progress, traffic from the VM within the VPC network can flow to\n the backend, even after the VPC spoke is added to a new hub.\n To avoid traffic flow to the backend, before adding the spoke to another hub,\n make sure that all of the propagation status entries for the\n VPC network in the\n previous hub, whether as a source spoke or a target spoke, are deleted.\n\nPrivate Service Connect connection propagation status\n-----------------------------------------------------\n\nNetwork Connectivity Center lets you view the status of the\nPrivate Service Connect connection propagation within a\nNetwork Connectivity Center hub.\nYou can view a summary of statuses or drill down on specific\nerrors to view error details.\n\nThe following table lists the propagation status codes and what they mean.\n\nFor information about how to view Private Service Connect\nconnection propagation statuses, see\n[View the Private Service Connect connection propagation status](/network-connectivity/docs/network-connectivity-center/how-to/working-with-hubs-spokes#view-psc-propagation-status). For\nPrivate Service Connect connection propagation troubleshooting\ninformation, see [Troubleshoot Private Service Connect connection propagation errors](/network-connectivity/docs/network-connectivity-center/support/troubleshooting#troubleshoot-psc-propagation-errors).\n\nWhat's next\n-----------\n\n- To create hubs and spokes, see [Work with hubs and spokes](/network-connectivity/docs/network-connectivity-center/how-to/working-with-hubs-spokes).\n- To view a list of partners whose solutions are integrated with Network Connectivity Center, see [Network Connectivity Center partners](/network-connectivity/docs/network-connectivity-center/partners).\n- To find solutions for common issues, see [Troubleshooting](/network-connectivity/docs/network-connectivity-center/support/troubleshooting).\n- To get details about API and Google Cloud CLI commands, see [APIs and reference](/network-connectivity/docs/network-connectivity-center/apis)."]]
