공유 VPC

이 페이지에서는 Google Cloud의 공유 VPC를 간략히 설명합니다. 공유 VPC를 사용하는 조직은 여러 프로젝트의 리소스를 공통 Virtual Private Cloud(VPC) 네트워크에 연결할 수 있으므로 해당 네트워크의 내부 IP를 사용하여 서로 안전하고 효율적으로 통신할 수 있습니다.

공유 VPC를 사용하면 프로젝트를 호스트 프로젝트로 지정한 후 하나 이상의 다른 서비스 프로젝트를 여기에 연결합니다. 호스트 프로젝트의 VPC 네트워크를 공유 VPC 네트워크라고 합니다. 서비스 프로젝트의 운영 가능 리소스는 공유 VPC 네트워크의 서브넷을 사용할 수 있습니다.

공유 VPC를 사용하면 조직 관리자가 서브넷, 경로, 방화벽과 같은 네트워크 리소스를 중앙에서 제어하면서 서비스 프로젝트 관리자에게 인스턴스 생성 및 관리와 같은 관리 책임을 위임할 수 있습니다. 이 모델을 사용하면 조직에서 다음을 수��할 수 있습니다.

네트워크 관리, 감사, 액세스 제어에 대한 최소 권한의 보안 권장사항을 구현합니다. 공유 VPC 관리자는 서비스 프로젝트 관리자가 네트워크에 영향을 미치는 변경 작업을 하지 않아도 공유 VPC 네트워크의 네트워크 및 보안 관리자에게 네트워크 관리 작업을 위임할 수 있습니다. 서비스 프로젝트 관리자에게는 공유 VPC 네트워크를 사용하는 인스턴스를 만들고 관리할 수 있는 권한만 제공됩니다. 자세한 내용은 관리자 및 IAM 섹션을 참조하세요.
관리 책임을 위임하는 동시에 조직의 여러 서비스 프로젝트에 대해 네트워크 수준에서 일관된 액세스 제어 정책을 적용하고 시행합니다. 예를 들어 서비스 프로젝트 관리자는 프로젝트에서 Compute 인스턴스 관리자가 되어 공유 VPC 호스트 프로젝트에서 승인된 서브넷을 사용하는 인스턴스를 만들고 삭제할 수 있습니다.
서비스 프로젝트를 사용하여 예산 또는 내부 비용 센터를 분리합니다. 자세한 내용은 청구 섹션을 참조하세요.

개념

조직, 폴더, 프로젝트

공유 VPC는 동일한 조직 내에서 프로젝트를 연결합니다. 연결된 프로젝트는 같은 폴더나 다른 폴더에 있을 수 있지만, 서로 다른 폴더에 있는 경우에는 관리자에게 두 폴더에 대한 공유 VPC 관리자 권한이 있어야 합니다. 조직, 폴더, 프로젝트에 대한 자세한 내용은 Google Cloud 리소스 계층 구조를 참조하세요.

참여하는 호스트 및 서비스 프로젝트는 다른 조직에 속할 수 없습니다. 유일한 예외는 프로젝트를 한 조직에서 다른 조직으로 마이그레이션하는 동안입니다. 마이그레이션 중에 서비스 프로젝트는 호스트 프로젝트와 일시적으로 다른 조직에 있을 수 있습니다. 프로젝트 마이그레이션에 대한 자세한 내용은 프로젝트 마이그레이션을 참조하세요.

공유 VPC에 참여하는 프로젝트는 호스트 프로젝트 또는 서비스 프로젝트입니다.

호스트 프로젝트에는 하나 이상의 공유 VPC 네트워크가 포함됩니다. 공유 VPC 관리자가 먼저 프로젝트를 호스트 프로젝트로 사용 설정해야 합니다. 그런 다음 공유 VPC 관리자가 호스트 프로젝트에 하나 이상의 서비스 프로젝트를 연결할 수 있습니다.
서비스 프로젝트는 공유 VPC 관리자가 호스트 프로젝트에 연결한 프로젝트입니다. 이 연결을 사용하면 이 프로젝트가 공유 VPC에 참여할 수 있습니다. 여러 서비스 프로젝트를 조직의 여러 부서 또는 팀에서 운영하고 관리하는 것이 일반적인 방식입니다.
프로젝트는 호스트 프로젝트와 서비스 프로젝트가 동시에 될 수 없습니다. 따라서 서비스 프로젝트를 호스트 프로젝트로 설정하여 프로젝트를 더 제공할 수 없습니다.
다중 호스트 프로젝트를 만들어 사용할 수 있지만 각 서비스 프로젝트는 단일 호스트 프로젝트에만 연결할 수 있습니다. 이미지는 여러 호스트 프로젝트 예시를 참조하세요.
호스트 프로젝트에서 네트워크, 서브넷, 보조 IP 주소 범위, 방화벽 규칙, 기타 네트워크 리소스를 만들 수 있습니다. 그런 다음 호스트 프로젝트는 보조 범위를 포함하여 선택된 서브넷을 서비스 프로젝트와 공유할 수 있습니다. 서비스 프로젝트에서 실행되는 서비스는 공유 VPC를 사용해서 다른 서비스 프로젝트에서 실행 중인 리소스와 통신할 수 있습니다.

명확하게 하기 위해 공유 VPC에 참여하지 않는 프로젝트를 독립형 프로젝트라고 합니다. 이름을 통해 해당 프로젝트가 호스트 프로젝트가 아니고 서비스 프로젝트도 아님을 잘 알 수 있습니다.

독립형 VPC 네트워크는 독립형 프로젝트 또는 서비스 프로젝트에 있는 공유되지 않은 VPC 네트워크입니다.

네트워크

공유 VPC 네트워크는 호스트 프로젝트에 정의된 VPC 네트워크이며 서비스 프로젝트에서 실행되는 리소스의 중앙 공유 네트워크로 사용할 수 있습니다. 공유 VPC 네트워크는 자동 또는 커스텀 모드일 수 있지만 레거시 네트워크는 지원되지 않습니다.

호스트 프로젝트가 사용 설정된 경우 네트워크를 공유하는 옵션은 두 가지입니다.

모든 호스트 프로젝트 서브넷을 공유할 수 있습니다. 이 옵션을 선택하면 새 네트워크의 서브넷을 포함하여 호스트 프로젝트에서 만든 모든 새 서브넷도 공유됩니다.
공유할 개별 서브넷을 지정할 수 있습니다. 개별적으로 서브넷을 공유하는 경우 수동으로 목록을 변경하지 않는 한 해당 서브넷만 공유됩니다.

호스트 및 서비스 프로젝트는 프로젝트 수준에서 첨부파일로 연결됩니다. 호스트 프로젝트에서 공유 VPC 네트워크의 서브넷은 다음 섹션인 관리자 및 IAM에서 설명하는 대로 서비스 프로젝트 관리자가 액세스할 수 있습니다.

조직 정책 제약조건

조직 정책과 IAM 권한이 함께 작동하여 다양한 수준의 액세스 제어를 제공합니다. 조직 정책을 사용하면 조직, 폴더 또는 프로젝트 수준에서 제어를 설정할 수 있습니다.

조직 정책 관리자는 조직 정책에 다음과 같은 공유 VPC 제약조건을 지정할 수 있습니다.

폴더 또는 조직에서 하나 이상의 호스트가 아닌 프로젝트를 연결할 수 있는 호스트 프로젝트 집합을 제한할 수 있습니다. 이 제약조건은 공유 VPC 관리자가 서비스 프로젝트를 호스트 프로젝트에 연결할 때 적용됩니다. 이 제약조건은 기존 연결에 영향을 주지 않습니다. 정책이 새 연결을 거부하더라도 기존 연결은 그대로 유지됩니다. 자세한 내용은 constraints/compute.restrictSharedVpcHostProject 제약조건을 참조하세요.
서비스 프로젝트가 프로젝트, 폴더, 조직 수준에서 액세스할 수 있는 공유 VPC 서브넷을 지정할 수 있습니다. 이 제약조건은 지정된 서브넷에 새 리소스를 만들 때 적용되며 기존 리소스에 영향을 주지 않습니다. 정책 때문에 새 리소스를 추가하지 못하더라도 기존 리소스는 서브넷에서 정상적으로 계속 작동합니다. 자세한 내용은 constraints/compute.restrictSharedVpcSubnetworks 제약조건을 참조하세요.

관리자 및 IAM

공유 VPC는 위임된 관리를 위해 Identity and Access Management(IAM) 역할을 사용합니다. IAM 주 구성원에게 부여할 수 있는 역할은 사용자, Google 그룹스, Google Domains 또는 Google Cloud 서비스 계정 등입니다. 이러한 관리자에게 문의해야 하는 경우 조직 또는 프로젝트의 IAM 정책에서 관리자를 찾아볼 수 있습니다. 필수 권한이 없으면 조직의 네트워크 또는 프로젝트 관리자에게 문의해야 합니다.

필수 관리 역할

관리자(IAM 역할)	용도
조직 관리자(`resourcemanager.organizationAdmin`) • 조직의 IAM 주 구성원	조직 관리자는 조직의 `resourcemanager.organizationAdmin` 역할을 합니다. 조직 관리자는 적절한 프로젝트 생성 및 삭제 역할과 조직의 공유 VPC 관리자 역할을 부여하여 공유 VPC 관리자를 지정합니다. 이러한 관리자는 조직 수준 정책을 정의할 수 있지만 특정 폴더 및 프로젝트 작업에는 추가 폴더 및 프로젝트 역할이 필요합니다.
공유 VPC 관리자 (`compute.xpnAdmin` 및 `resourcemanager.projectIamAdmin`) • 조직의 IAM 주 구성원 또는 • 폴더의 IAM 주 구성원	공유 관리자에게는 조직 또는 하나 이상의 폴더에 대한 Compute 공유 VPC 관리자(`compute.xpnAdmin`) 및 프로젝트 IAM 관리자(`resourcemanager.projectIamAdmin`) 역할이 있습니다. 공유 VPC 관리자는 호스트 프로젝트 사용 설정, 호스트 프로젝트에 서비스 프로젝트 연결, 서비스 프로젝트 관리자에게 공유 VPC 네트워크의 일부 또는 모든 서브넷에 대한 액세스 권한 위임과 같은 공유 VPC 설정에 필요한 다양한 작업을 수행합니다. 지정된 호스트 프로젝트의 공유 VPC 관리자는 일반적으로 프로젝트 소유자이기도 합니다. 조직의 Compute 공유 VPC 관리자 역할이 할당된 사용자에게는 조직의 모든 폴더에 대한 역할이 있습니다. 폴더에 대한 역할이 할당된 사용자에게는 지정된 폴더와 그 아래에 중첩된 폴더에 대한 해당 역할이 있습니다. 공유 VPC 관리자는 관리자에게 폴더 두 개에 대한 역할이 있는 경우에만 두 개의 다른 폴더에 있는 프로젝트를 연결할 수 있습니다.
서비스 프로젝트 관리자 (`compute.networkUser`) • 조직의 IAM 주 구성원 또는 • 호스트 프로젝트의 IAM 주 구성원 또는 • 호스트 프로젝트의 일부 서브넷에 있는 IAM 주 구성원	공유 VPC 관리자는 IAM 주 구성원에게 전체 호스트 프로젝트 또는 공유 VPC 네트워크의 일부 서브넷에 대한 네트워크 사용자(`compute.networkUser`) 역할을 부여하여 서비스 프로젝트 관리자를 정의합니다. 또한 서비스 프로젝트 관리자는 서비스 프로젝트에 정의된 리소스에 대한 소유권과 제어를 유지하므로 해당 서비스 프로젝트에 대한 인스턴스 관리자(`compute.instanceAdmin`) 역할을 갖습니다. 이들은 프로젝트 소유자와 같이 서비스 프로젝트에 대한 추가 IAM 역할을 수행할 수 있습니다.

서비스 프로젝트 관리자

각 서비스 프로젝트 관리자를 정의할 때 공유 VPC 관리자는 전체 호스트 프로젝트 또는 일부 서브넷을 사용할 수 있는 권한을 부여할 수 있습니다.

프로젝트 수준 권한: 공유 VPC 관리자가 서비스 프로젝트 관리자에게 전체 호스트 프로젝트의 compute.networkUser 역할을 부여하면 서비스 프로젝트 관리자는 호스트 프로젝트의 모든 서브넷을 사용할 수 있는 권한을 갖도록 정의됩니다. 결과적으로 서비스 프로젝트 관리자는 앞으로 호스트 프로젝트에 추가되는 서브넷 및 VPC 네트워크를 포함하여 호스트 프로젝트의 모든 VPC 네트워크에서 모든 서브넷을 사용할 수 있는 권한을 갖게 됩니다.
서브넷 수준 권한: 또는 공유 VPC 관리자가 일부 서브넷에 대한 compute.networkUser 역할을 서비스 프로젝트 관리자에게 부여한 경우, 서비스 프로젝트 관리자에게 보다 제한된 권한 집합으로 일부 서브넷만 사용할 수 있는 권한을 부여할 수도 있습니다. 서브넷 수준의 권한만 가진 서비스 프로젝트 관리자는 해당 서브넷만 사용할 수 있습니다. 호스트 프로젝트에 새 공유 VPC 네트워크 또는 새 서브넷이 추가되면 공유 VPC 관리자는 compute.networkUser 역할의 권한 바인딩을 검토하여 모든 서비스 프로젝트 관리자의 서브넷 수준 권한이 의도한 구성과 일치하는지 확인해야 합니다.

네트워크 및 보안 관리자

공유 VPC 관리자는 공유 VPC 네트워크 관리를 포함하여 호스트 프로젝트의 리소스를 완벽하게 제어할 수 있습니다. 원하는 경우 특정 네트워크 관리 작업을 다른 IAM 주 구성원에게 위임할 수 있습니다.

관리자	용도
네트워크 관리자 • 호스트 프로젝트의 IAM 주 구성원 또는 • 조직의 IAM 주 구성원	공유 VPC 관리자는 IAM 주 구성원에게 호스트 프로젝트에 대한 네트워크 관리자(`compute.networkAdmin`) 역할을 부여하여 네트워크 관리자를 정의합니다. 네트워크 관리자는 방화벽 규칙 및 SSL 인증서를 제외한 모든 네트워크 리소스를 완벽하게 제어할 수 있습니다.
보안 관리자 • 호스트 프로젝트의 IAM 주 구성원 또는 • 조직의 IAM 주 구성원	공유 VPC 관리자는 IAM 주 구성원에게 호스트 프로젝트에 대한 보안 관리자(`compute.securityAdmin`) 역할을 부여하여 보안 관리자를 정의할 수 있습니다. 보안 관리자는 방화벽 규칙 및 SSL 인증서를 관리합니다.

사양

할당량 및 한도

공유 VPC 호스트 프로젝트에는 표준 프로젝트별 VPC 할당량이 적용됩니다. 공유 VPC 네트워크에는 VPC 네트워크의 네트워크별 한도와 인스턴스별 한도가 적용됩니다. 또한 호스트 프로젝트와 서비스 프로젝트 간의 관계에는 공유 VPC에 한정되는 한도가 적용됩니다.

결제

공유 VPC 네트워크에 참여하는 리소스에 대한 결제는 리소스가 호스트 프로젝트에서 공유 VPC 네트워크를 사용하더라도 리소스가 있는 서비스 프로젝트에서 발생합니다.

공유 VPC 네트워크를 사용하는 서비스 프로젝트에서 리소스 청구 금액을 계산하는 데 사용되는 요율 및 규칙은 리소스가 호스트 프로젝트 자체에 있는 경우와 같습니다.
리소스에 의해 생성된 아웃바운드 트래픽에 대한 요금은 리소스가 정의된 프로젝트에 대해 청구됩니다.
- 인스턴스의 아웃바운드 트래픽은 해당 인스턴스가 포함된 프로젝트에 대해 청구됩니다. 예를 들어 인스턴스가 서비스 프로젝트에서 생성되었지만 공유 VPC 네트워크를 사용하는 경우 생성되는 아웃바운드 트래픽에 대한 요금은 해당 서비스 프로젝트에 대해 청구됩니다. 이런 식으로 공유 VPC를 사용하여 리소스를 조직의 비용 센터로 구성할 수 있습니다.
- 부하 분산기 관련 비용은 부하 분산기 구성요소가 포함된 프로젝트에 청구됩니다. 부하 분산 및 공유 VPC에 대한 자세한 내용은 부하 분산 섹션을 참조하세요.
- VPN에 대한 아웃바운드 트래픽은 VPN 게이트웨이 리소스를 포함하는 프로젝트에 청구합니다. 예를 들어 VPN 게이트웨이가 공유 VPC 네트워크에서 생성된 경우에는 호스트 프로젝트에 포함됩니다. 어느 서비스 프로젝트에서 아웃바운드 데이터 전송이 시작되었는지에 관계없이 VPN 게이트웨이를 통한 아웃바운드 트래픽은 호스트 프로젝트로 청구됩니다.
- VLAN 연결을 통해 전송되는 공유 VPC 서비스 프로젝트의 리소스에서 발생��는 트래픽 비용은 VLAN 연결이 있는 프로젝트에 청구됩니다. 자세한 내용은 Cloud Interconnect 가격 책정을 참조하세요.

리소스

운영 가능 리소스

공유 VPC 서비스 프로젝트에서 대부분의 Google Cloud 제품과 기능을 사용할 수 있습니다.

공유 VPC 시나리오에 참여할 수 있는 리소스에는 다음 제한사항이 적용됩니다.

공유 VPC 네트워크 사용은 필수 사항이 아닙니다. 예를 들어 인스턴스 관리자는 해당 프로젝트에서 VPC 네트워크를 사용하는 인스턴스를 서비스 프로젝트에 만들 수 있습니다. 서비스 프로젝트에서 정의된 네트워크는 공유되지 않습니다.
공유 VPC 네트워크를 사용하려면 일부 리소스를 다시 만들어야 합니다. 공유 VPC 관리자가 기존 프로젝트를 호스트 프로젝트에 연결하면 이 프로젝트는 서비스 프로젝트가 되지만, 기존 리소스가 자동으로 공유 네트워크 리소스를 사용하지는 않습니다. 공유 VPC 네트워크를 사용하려면 서비스 프로젝트 관리자는 운영 가능 리소스를 생성하고 공유 VPC 네트워크의 서브넷을 사용하도록 구성해야 합니다. 예를 들어 서비스 프로젝트의 기존 인스턴스는 공유 VPC 네트워크를 사용하도록 재구성할 수 없지만 새 인스턴스를 만들어 공유 VPC 네트워크에서 사용 가능한 서브넷을 사용할 수 있습니다. 이 제한은 비공개 영역에 적용됩니다.

IP 주소

서비스 프로젝트에서 인스턴스를 만들 때 호스트 프로젝트의 서브넷 구성에 따라 단일 스택(IPv4 전용) 인스턴스 또는 이중 스택(IPv4 및 IPv6) 인스턴스로 구성할 수 있습니다. 자세한 내용은 인스턴스 만들기를 참조하세요.

동일한 공유 VPC 네트워크를 통해 호스트 프로젝트에 연결된 서비스 프로젝트의 인스턴스는 내부 IPv4 주소를 사용하거나 내부 또는 외부 IPv6 주소를 사용하여 내부에서 서로 통신할 수 있으며, 이 경우 관련 방화벽 규칙이 적용됩니다.

서비스 프로젝트 관리자는 다음 IP 주소 유형 중 하나를 서비스 프로젝트의 리소스에 할당할 수 있습니다.

임시 IPv4 및 IPv6 주소: 임시 IP 주소가 서비스 프로젝트의 인스턴스에 자동으로 할당될 수 있습니다. 예를 들어 서비스 프로젝트 관리자는 인스턴스를 만들 때 공유 VPC 네트워크와 사용 가능한 공유 서브넷을 선택합니다. 인스턴스의 기본 내부 IPv4 주소는 선택된 공유 서브넷의 기본 IPv4 주소 범위에 있는 사용 가능한 IP 주소의 범위에서 가져옵니다. 인스턴스를 이중 스택 인스턴스로 구성할 경우 인스턴스의 IPv6 주소를 선택된 공유 서브넷의 IPv6 서브넷 범위에서 사용 가능한 IP 주소 범위에서 가져옵니다.

임시 IPv4 주소가 내부 부하 분산기에 자동으로 할당될 수도 있습니다. 자세한 내용은 내부 패스 스루 네트워크 부하 분산기 만들기 또는 내부 애플리케이션 부하 분산기 만들기를 참조하세요.
고정 내부 IPv4 및 IPv6 주소: 고정 내부 IPv4 또는 IPv6 주소가 서비스 프로젝트에 예약될 수 있습니다. IP 주소 값을 공유 VPC 네트워크에서 선택한 공유 서브넷의 사용 가능한 IP 주소에서 가져오더라도 내부 IPv4 또는 IPv6 주소 객체는 이 객체를 사용하는 리소스와 동일한 서비스 프로젝트에 만들어야 합니다. 자세한 내용은 '공유 VPC 프로비저닝' 페이지의 고정 내부 IP4 및 IPv6 주소 예약을 참조하세요.
고정 외부 IPv4 주소: 호스트 프로젝트에 정의된 외부 IPv4 주소 객체는 호스트 프로젝트 또는 연결된 서비스 프로젝트 중 하나의 리소스에서 사용할 수 있습니다. 서비스 프로젝트는 자체 외부 IPv4 주소 객체를 사용할 수도 있습니다. 예를 들어 서비스 프로젝트의 인스턴스는 서비스 프로젝트 또는 호스트 프로젝트에 정의된 리전 외부 IPv4 주소를 사용할 수 있습니다.
고정 외부 IPv6 주소: 서비스 프로젝트 관리자는 고정 외부 IPv6 주소를 예약하도록 선택할 수도 있습니다. IP 주소 값을 공유 VPC 네트워크의 선택한 공유 서브넷에서 사용 가능한 IPv6 주소에서 가져오더라도 외부 IPv6 주소 객체는 이 객체를 사용하는 리소스와 동일한 서비스 프로젝트에 만들어야 합니다. 자세한 내용은 공유 VPC 프로비저닝 페이지의 고정 외부 IPv6 주소 예약을 참조하세요.

내부 DNS

동일한 서비스 프로젝트의 VM은 Google Cloud에서 자동으로 생성하는 내부 DNS 이름을 사용하여 서로 연결할 수 있습니다. 이러한 DNS 이름이 호스트 프로젝트의 내부 IP 주소를 가리키는 경우에도 해당 이름은 VM이 생성되는 서비스 프로젝트의 프로젝트 ID를 사용합니다. 자세한 설명은 내부 DNS 문서의 내부 DNS 이름 및 공유 VPC를 참조하세요.

Cloud DNS 비공개 영역

공유 VPC 네트워크에서 Cloud DNS 비공개 영역을 사용할 수 있습니다. 호스트 프로젝트에서 비공개 영역을 만들고 공유 VPC 네트워크에 이 영역에 대한 액세스를 승인하거나 프로젝트 간 바인딩을 사용하여 서비스 프로젝트에서 영역을 설정할 수 있습니다.

부하 분산

공유 VPC는 Cloud Load Balancing과 함께 사용할 수 있습니다. 대부분의 경우 서비스 프로젝트에서 백엔드 인스턴스를 만듭니다. 이 경우 모든 부하 분산기 구성요소가 해당 프로젝트에서 생성됩니다. 이 설정으로 호스트 프로젝트에 백엔드 인스턴스를 만들 수 있지만 네트워크 관리와 서비스 개발 책임이 분리되지 않으므로 일반적인 공유 VPC 배포에는 적합하지 않습니다.

다음 표의 링크를 사용하여 각 부하 분산기 유형에 지원되는 공유 VPC 아키텍처에 대해 자세히 알아보세요.

부하 분산기 유형	링크
외부 애플리케이션 부하 분산기	공유 VPC 아키텍처
내부 애플리케이션 부하 분산기	공유 VPC 아키텍처
외부 프록시 네트워크 부하 분산기	공유 VPC 아키텍처
내부 프록시 네트워크 부하 분산기	공유 VPC 아키텍처
내부 패스 스루 네트워크 부하 분산기	공유 VPC 아키텍처
외부 패스 스루 네트워크 부하 분산기	공유 VPC 아키텍처

예제 및 사용 사례

기본 개념

그림 1은 간단한 공유 VPC 시나리오를 보여줍니다.

**그림 1.** 공유 VPC 네트워크가 있는 호스트 프로젝트는 두 개의 서비스 프로젝트에 내부 연결을 제공하는 반면, 독립형 프로젝트는 공유 VPC를 사용하지 않습니다(확대하려면 클릭).

조직의 공유 VPC 관리자가 호스트 프로젝트를 만들고 여기에 두 개의 서비스 프로젝트를 연결했습니다.
- Service project A의 서비스 프로젝트 관리자는 공유 VPC 네트워크의 모든 서브넷 또는 일부 서브넷에 액세스하도록 구성할 수 있습니다. 10.0.1.0/24 subnet에 대한 최소한 서브넷 수준의 권한이 있는 서비스 프로젝트 관리자가 us-west1 리전의 영역에 Instance A를 만들었습니다. 이 인스턴스는 10.0.1.0/24 CIDR 블록에서 내부 IP 주소 10.0.1.3를 수신합니다.
- Service project B의 서비스 프로젝트 관리자는 공유 VPC 네트워크의 모든 서브넷 또는 일부 서브넷에 액세스하도록 구성할 수 있습니다. 10.15.2.0/24 subnet에 대한 최소한 서브넷 수준의 권한이 있는 서비스 프로젝트 관리자가 us-east1 리전의 영역에 Instance B를 만들었습니다. 이 인스턴스는 10.15.2.0/24 CIDR 블록에서 내부 IP 주소 10.15.2.4를 수신합니다.
독립형 프로젝트는 공유 VPC에 전혀 참여하지 않습니다. 호스트도 아니고 서비스 프로젝트도 아닙니다. 독립형 인스턴스는 프로젝트에 대해 compute.InstanceAdmin 이상의 역할이 있는 IAM 주 구성원에 의해 생성됩니다.

여러 호스트 프로젝트

그림 2에서는 공유 VPC를 사용하여 별도의 테스트 및 프로덕션 환경을 구축하는 방법을 보여줍니다. 이 경우 조직에서는 별도의 두 호스트 프로젝트인 테스트 환경과 프로덕션 환경을 사용하기로 결정했습니다.

**그림 2.** 테스트 환경 호스트 프로젝트와 프로덕션 환경 호스트 프로젝트는 공유 VPC를 사용하여 고유한 프로덕션 및 테스트 환경을 만듭니다(확대하려면 클릭).

조직의 공유 VPC 관리자가 두 개의 호스트 프로젝트를 만들고 여기에 두 개의 서비스 프로젝트를 다음과 같이 연결했습니다.
- Apps testing 및 Mobile testing 서비스 프로젝트는 Test environment 호스트 프로젝트에 연결되었습니다. 각 프로젝트의 서비스 프로젝트 관리자는 Testing network의 서브넷 전체 또는 일부에 액세스하도록 구성할 수 있습니다.
- Apps production 및 Mobile production 서비스 프로젝트는 Production environment 호스트 프로젝트에 연결되었습니다. 각 프로젝트의 서비스 프로젝트 관리자는 Production network의 서브넷 전체 또는 일부에 액세스하도록 구성할 수 있습니다.
두 호스트 프로젝트에는 동일한 CIDR 범위를 사용하도록 구성된 서브넷이 있는 공유 VPC 네트워크가 하나 있습니다. Testing network와 Production network에서 두 서브넷은 다음과 같습니다.
- us-west1 리전의 10.0.1.0/24 subnet
- us-east1 리전의 10.15.2.0/24 subnet
Apps testing 서비스 프로젝트의 Instance AT와 Apps production 서비스 프로젝트의 Instance AP를 고려해 보세요.
- 서비스 프로젝트 관리자는 10.0.1.0/24 subnet에 대한 서브넷 수준 이상의 권한이 있어야만 이러한 인스턴스를 만들 수 있습니다.
- 두 인스턴스 모두 IP 주소 10.0.1.3을 사용합니다. 이는 각 인스턴스가 자체 공유 VPC 네트워크가 포함된 고유한 호스트 프로젝트에 연결된 서비스 프로젝트에 존재하기 때문에 허용됩니다. 테스트 네트워크와 프로덕션 네트워크는 동일한 방식으로 의도적으로 구성되었습니다.
- 서브넷과 인스턴스가 서로 다른 프로젝트에 정의되어 있어도 10.0.1.0/24 subnet을 사용하는 인스턴스는 서브넷과 같은 리전의 영역에 있어야 합니다. 10.0.1.0/24 subnet이 us-west1 리전에 있으므로 이 서브넷을 사용하여 인스턴스를 생성하는 서비스 프로젝트 관리자는 us-west1-a와 같이 동일한 리전의 영역을 선택해야 합니다.

하이브리드 클라우드 시나리오

그림 3에서는 하이브리드 환경에서 공유 VPC를 사용하는 방법을 보여줍니다.

**그림 3.** 공유 VPC 네트워크가 온프레미스 네트워크와 3개의 서비스 프로젝트에 연결됩니다(확대하려면 클릭).

이 예에서 조직은 단일 공유 VPC 네트워크가 있는 단일 호스트 프로젝트를 만들었습니다. 공유 VPC 네트워크는 Cloud VPN을 통해 온프레미스 네트워크에 연결됩니다. ��부 서비스와 애플리케이션은 Google Cloud에서 호스팅되지만 다른 서비스와 애플리케이션은 온프레미스로 유지됩니다.

공유 VPC 관리자가 호스트 프로젝트를 사용 설정하고 여기에 세 개의 서비스 프로젝트 Service project A, Service project B, Service project C를 연결했습니다.
- 별도의 팀이 각 서비스 프로젝트를 관리할 수 있습니다. 한 프로젝트의 서비스 프로젝트 관리자가 다른 서비스 프로젝트에 대한 권한을 가지지 않도록 IAM 권한이 구성되었습니다.
- 공유 VPC 관리자는 공유 VPC 네트워크를 사용하는 인스턴스를 만들 수 있도록 필요한 서비스 프로젝트 관리자에게 서브넷 수준 또는 프로젝트 수준 권한을 부여했습니다.
  - 10.0.1.0/24 subnet에 대한 서브넷 수준 권한이 있는 Service project A의 서비스 프로젝트 관리자는 그 안에 Instance A를 만들 수 있습니다. 서비스 프로젝트 관리자는 인스턴스의 us-west1 리전에서 영역을 선택해야 합니다. 이 리전이 10.0.1.0/24 subnet 서브넷을 포함하는 리전이기 때문입니다. Instance A는 10.0.1.0/24 subnet의 무료 IP 주소 범위에서 IP 주소 10.0.1.3을 받습니다.
  - 10.15.2.0/24 subnet에 대한 서브넷 수준 권한이 있는 Service project B의 서비스 프로젝트 관리자는 그 안에 Instance B를 만들 수 있습니다. 서비스 프로젝트 관리자는 인스턴스의 us-east1 리전에서 영역을 선택해야 합니다. 이 리전이 10.15.2.0/24 subnet 서브넷을 포함하는 리전이기 때문입니다. Instance B는 10.15.2.0/24 subnet의 무료 IP 주소 범위에서 IP 주소 10.15.2.4를 받습니다.
  - 전체 호스트 프로젝트에 대한 프로젝트 수준 권한이 있는 Service project C의 서비스 프로젝트 관리자는 호스트 프로젝트의 VPC 네트워크에 포함된 서브넷에 인스턴스를 만들 수 있습니다. 예를 들어 서비스 프로젝트 관리자는 10.7.1.0/24 subnet에서 Instance C를 생성하여 us-east1 리전에서 이 서브넷의 리전과 일치하는 영역을 선택할 수 있습니다. Instance C는 10.7.1.0/24 Subnet의 무료 IP 주소 범위에서 IP 주소 10.7.1.50을 받습니다.
- 각 서비스 프로젝트는 별도로 청구됩니다.
- 각 프로젝트의 서비스 프로젝트 관리자는 리소스를 만들고 관리해야 합니다.
공유 VPC 관리자가 네트워크 관리 작업을 공유 VPC 네트워크의 네트워크 및 보안 관리자인 다른 IAM 주 구성원에게 위임했습니다.
- 네트워크 관리자가 Cloud VPN 게이트웨이를 만들고 인터넷을 통해 온프레미스 게이트웨이로 VPN 터널을 구성했습니다. 동일한 us-east1 리전의 해당 Cloud Router가 구성되었으므로 Cloud VPN은 온프레미스의 대응 라우터와 경로를 교환하고 수신합니다.
- VPC의 동적 라우팅 모드가 전역인 경우 Cloud Router는 학습된 경로를 VPC 네트워크의 모든 서브넷에 있는 온프레미스 네트워크에 적용하고 온프레미스 대응 라우터와 함께 모든 VPC 서브넷에 대한 경로를 공유합니다.
- 보안 관리자는 공유 VPC 네트워크에서 방화벽 규칙을 만들고 관리하여 Google Cloud 및 온프레미스 네트워크에서 인스턴스 간 트래픽을 제어합니다.
- 적용 가능한 방화벽 규칙에 따라 서비스 프로젝트의 인스턴스를 온프레미스 데이터베이스 또는 디렉터리 서버와 같은 내부 서비스와 통신하도록 구성할 수 있습니다.

2단계 웹 서비스

그림 4에서는 공유 VPC를 사용하여 관리 책임을 위임하고 최소 권한의 원칙을 유지하는 방법을 보여줍니다. 이 경우 조직에는 두 개의 단계로 분리된 웹 서비스가 있으며 각기 다른 팀이 각 단계를 관리합니��. 단계 1은 HTTP(S) 부하 분산기 뒤에 있는 외부에 노출된 구성요소를 나타냅니다. 단계 2는 단계 1이 의존하는 내부 서비스를 나타내며 내부 TCP/UDP 부하 분산기를 사용하여 균형을 이룹니다.

공유 VPC를 사용하면 웹 서비스의 각 단계를 다른 프로젝트에 매핑하여 공통 VPC 네트워크를 공유하면서 다른 팀에서 관리할 수 있습니다.

각 단계의 인스턴스 및 부하 분산기 구성요소와 같은 리소스는 여러 팀이 관리하는 개별 서비스 프로젝트에 배치됩니다.
각 단계 서비스 프로젝트는 공유 VPC 관리자에 의해 호스트 프로젝트에 연결되었습니다. 공유 VPC 관리자는 호스트 프로젝트도 사용 설정했습니다.
- 개별 팀은 적절한 서비스 프로젝트에서 서비스 프로젝트 관리자가 되어 웹 서비스의 각 단계를 관리할 수 있습니다.
- 각 서비스 프로젝트는 별도로 청구됩니다.
- 각 프로젝트의 서비스 프로젝트 관리자는 리소스를 만들고 관리해야 합니다.
네트워크 액세스 제어는 다음과 같이 구분됩니다.
- 단계 1에서만 작업하는 IAM 주 구성원은 Tier 1 service project의 서비스 프로젝트 관리자이고 10.0.1.0/24 subnet에 대한 서브넷 수준 권한만 부여됩니다. 이 예시에서는 이러한 서비스 프로젝트 관리자가 해당 서브넷에 세 개의 Tier 1 instances를 만들었습니다.
- 단계 2에서만 작업하는 IAM 주 구성원은 Tier 2 service project의 서비스 프로젝트 관리자이고 10.0.2.0/24 subnet에 대한 서브넷 수준 권한만 부여됩니다. 이 예시에서는 다른 서비스 프로젝트 관리자가 전달 규칙이 해당 서브넷에서 사용할 수 있는 IP 주소를 사용하는 내부 부하 분산기와 함께 해당 서브넷에 세 개의 Tier 2 instances를 만들었습니다.
- 전체 웹 서비스를 감독하는 IAM 주 구성원은 두 서비스 프로젝트의 서비스 프로젝트 관리자이며 호스트 프로젝트에 대한 프로젝트 수준의 권한을 가지고 있어 여기에서 정의된 모든 서브넷을 사용할 수 있습니다.
- 원하는 경우 공유 VPC 관리자는 네트워크 관리 작업을 네트워크 및 보안 관리자에게 위임할 수 있습니다.

다음 단계

공유 VPC를 설정하려면 공유 VPC 프로비저닝을 참조하세요.
공유 VPC로 Kubernetes Engine 클러스터를 설정하려면 공유 VPC를 사용하여 클러스터 설정을 참조하세요.
공유 VPC 설정을 삭제하려면 공유 VPC 프로비저닝 해제를 참조하세요.