공유 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에 참여할 수 있습니다. 여러 서비스 프로젝트를 조직의 여러 부서 또는 팀에서 운영하고 관리하는 것이 일반적인 방식입니다.

  • 프로젝트는 호스트 프로젝트인 동시에 서비스 프로젝트일 수 없습니다. 따라서 서비스 프로젝트는 다른 서비스 프로젝트의 호스트 프로젝트일 수 없습니다.

  • 여러 호스트 프로젝트를 만들어 사용할 수 있지만 각 서비스 프로젝트를 하나의 호스트 프로젝트에만 연결할 수 있습니다. 이미지는 여러 호스트 프로젝트 예시를 참조하세요.

명확하게 하기 위해 공유 VPC에 참여하지 않는 프로젝트를 독립형 프로젝트라고 합니다. 이 이름은 호스트 프로젝트도 아니고 서비스 프로젝트도 아님을 강조합니다.

네트워크

공유 VPC 네트워크는 호스트 프로젝트에 정의된 VPC 네트워크이며 서비스 프로젝트의 운영 가능 리소스를 위해 중앙에서 공유되는 네트워크로 제공됩니다. 공유 VPC 네트워크는 자동 또는 커스텀 모드일 수 있지만 레거시 네트워크는 지원되지 않습니다.

호스트 프로젝트가 사용 설정되면 기존의 모든 해당 VPC 네트워크가 공유 VPC 네트워크가 되고, 그 안에서 생성된 새로운 네트워크도 모두 자동으로 공유 VPC 네트워크가 됩니다. 따라서 단일 호스트 프로젝트에 두 개 이상의 공유 VPC 네트워크가 존재할 수 있습니다.

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

조직 정책 제약조건

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

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

  • 폴더 또는 조직에서 하나 이상의 호스트가 아닌 프로젝트를 연결할 수 있는 호스트 프로젝트 집합을 제한할 수 있습니다. 이 제약조건은 공유 VPC 관리자가 서비스 프로젝트를 호스트 프로젝트에 연결할 때 적용됩니다. 이 제약조건은 기존 연결에 영향을 주지 않습니다. 정책이 새 연결을 거부하더라도 기존 연결은 그대로 유지됩니다. 자세한 내용은 constraints/compute.restrictSharedVpcHostProject 제약조건을 참조하세요.

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

관리자 및 IAM

beta

공유 VPC는 위임된 관리에 Identity and Access Management(IAM) 역할을 사용합니다. IAM 구성원에게 부여할 수 있는 역할은 사용자, Google 그룹, Google 도메인 또는 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 게이트웨이를 통한 이그레스 트래픽은 이그레스를 시작한 서비스 프로젝트에 관계없이 호스트 프로젝트에 청구됩니다.

리소스

운영 가능 리소스

다음 서비스 프로젝트 리소스는 공유 VPC에 참여할 수 있지만 몇 가지 실질적 제한사항이 적용됩니다.

기타 운영 가능 리소스는 관련 제품의 문서를 참조하세요.

운영 가능 리소스에 대한 실질적인 제한사항

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

  • 공유 VPC 네트워크 사용은 필수 사항이 아닙니다. 예를 들어 인스턴스 관리자는 서비스 프로젝트에 해당 프로젝트의 VPC 네트워크를 사용하는 인스턴스를 만들 수 있습니다. 서비스 프로젝트에서 정의된 네트워크는 공유되지 않습니다.

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

사용 불가 리소스

Deployment Manager는 단일 프로젝트 내의 리소스만 관리할 수 있으므로 공유 VPC 시나리오에서 리소스를 사용하려면 특정한 설정이 필요합니다. 자세한 내용은 배포 관리자를 통한 공유 VPC 만들기를 참조하세요.

IP 주소

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

임시 내부 IP 주소가 서비스 프로젝트의 인스턴스에 자동으로 할당될 수 있습니다. 예를 들어 서비스 프로젝트 관리자는 인스턴스를 만들 때 영역, 공유 VPC 네트워크, 사용 가능한 서브넷을 선택합니다. IP 주소는 선택한 공유 서브넷에서 사용 가능한 IP 주소의 범위에서 가져옵니다.

또는 서비스 프로젝트 관리자가 정적 내부 IP 주소를 예약하도록 선택할 수 있습니다. IP 주소 값은 공유 VPC 네트워크의 선택한 공유 서브넷에 있는 사용 가능한 IP 범위에서 가져오지만, IP 주소 객체 자체는 이 객체를 사용할 인스턴스와 동일한 서비스 프로젝트에서 만들어야 합니다. 자세한 내용은 공유 VPC 프로비저닝 페이지의 고정 내부 IP 예약을 참조하세요.

호스트 프로젝트에 정의된 외부 IP 주소는 해당 프로젝트의 리소스에서만 사용할 수 있습니다. 서비스 프로젝트에는 사용할 수 없습니다. 서비스 프로젝트는 자체 외부 IP 주소 집합을 유지 관리할 수 있습니다. 예를 들어 서비스 프로젝트의 인스턴스는 동일한 서비스 프로젝트에 정의된 외부 IP 주소를 사용해야 합니다. 인스턴스가 호스트 프로젝트에서 공유 VPC 네트워크의 내부 IP 주소를 사용하는 경우에도 마찬가지입니다.

내부 DNS

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

Cloud DNS 비공개 영역

공유 VPC 네트워크에서 Cloud DNS 비공개 영역을 사용할 수 있습니다. 호스트 프로젝트에 비공개 영역을 만들고 공유 VPC 네트워크에 이 영역에 대한 액세스를 승인해야 합니다.

부하 분산

공유 VPC는 부하 분산과 함께 사용할 수 있습니다. 모든 부하 분산 구성요소는 모두 하나의 호스트 프로젝트에 있든 모두 하나의 서비스 프로젝트에 있든 동일한 프로젝트에 있어야 합니다. 일부 부하 분산기 구성요소는 호스트 프로젝트에서 만들고 나머지는 연결된 서비스 프로젝트에서 만드는 방식은 지원되지 않습니다. 그러나 서비스 프로젝트에서 내부 TCP/UDP 부하 분산기에 대한 내부 전달 규칙을 만들 때 서비스 프로젝트가 연결된 호스트 프로젝트의 공유 서브넷을 참조합니다. 자세한 내용은 공유 VPC 프로비저닝 페이지에서 내부 TCP/UDP 부하 분산기 생성을 참조하세요.

다음 표에는 HTTP(S), SSL 프록시, TCP 프록시 부하 분산을 위한 구성요소가 요약되어 있습니다. 백엔드 인스턴스는 대개 서비스 프로젝트에서 만듭니다. 이 경우 모든 부하 분산기 구성요소가 해당 프로젝트에서 생성됩니다. 호스트 프로젝트에서 백엔드 인스턴스를 만들 수도 있습니다. 이 경우 모든 부하 분산기 구성요소가 호스트 프로젝트에 있어야 합니다.

부하 분산기 IP 주소 전달 규칙 기타 프론트엔드 구성 요소 백엔드 구성요소
HTTP(S) 부하 분산 외부 IP 주소는 부하가 분산되는 인스턴스와 동일한 프로젝트(서비스 프로젝트)에 정의되어야 합니다. 외부 전달 규칙은 백엔드 인스턴스와 동일한 프로젝트(서비스 프로젝트)에 정의되어야 합니다. 대상 HTTP 프록시 또는 대상 HTTPS 프록시와 연결된 URL 맵은 백엔드 인스턴스와 동일한 프로젝트에 정의되어야 합니다. 전역 백엔드 서비스는 백엔드 인스턴스와 동일한 프로젝트에 정의되어야 합니다. 이 인스턴스는 백엔드 서비스에 백엔드로 연결된 인스턴스 그룹에 있어야 합니다. 백엔드 서비스와 관련된 상태 확인은 백엔드 서비스와 동일한 프로젝트에 정의되어야 합니다.
SSL 프록시 부하 분산 대상 SSL 프록시는 백엔드 인스턴스와 동일한 프로젝트에 정의되어야 합니다.
TCP 프록시 부하 분산 대상 TCP 프록시는 백엔드 인스턴스와 동일한 프로젝트에 정의되어야 합니다.

다음 표에는 네트워크 부하 분산의 구성요소가 요약되어 있습니다.

IP 주소 전달 규칙 백엔드 구성요소
리전 외부 IP 주소는 부하가 분산되는 인스턴스와 동일한 프로젝트에 정의되어야 합니다. 리전 외부 전달 규칙은 대상 풀의 인스턴스와 동일한 프로젝트(서비스 프로젝트)에 정의되어야 합니다. 대상 풀은 대상 풀의 인스턴스가 있는 동일한 프로젝트 및 동일한 리전에 정의되어야 합니다. 대상 풀과 관련된 상태 검사도 동일한 프로젝트에 정의되어야 합니다.

다음 표에는 내부 TCP/UDP 부하 분산의 구성요소가 요약되어 있습니다. 예시는 공유 VPC 프로비저닝 페이지에서 내부 TCP/UDP 부하 분산기 만들기를 참조하세요.

IP 주소 전달 규칙 백엔드 구성요소
내부 IP 주소 객체는 부하가 분산되는 VM과 동일한 프로젝트에 정의되어야 합니다.

공유 VPC 네트워크에서 부하 분산기를 사용하려면 Google Cloud 내부 IP 주소 객체가 반드시 백엔드 VM이 있는 서비스 프로젝트와 동일한 서비스 프로젝트에 정의되어야 하고 또한 호스트 프로젝트에 있는 원하는 공유 VPC 네트워크의 서브넷을 참조해야 합니다. 주소 자체는 참조된 서브넷의 기본 IP 범위에서 가져옵니다.

서비스 프로젝트에서 이 서비스 프로젝트 자체의 VPC 네트워크 안의 서브넷을 참조하는 내부 IP 주소 객체를 생성하면 내부 TCP/UDP 부하 분산기는 공유 VPC 네트워크가 아니라 해당 네트워크에 대해 로컬입니다.
내부 전달 규칙은 부하가 분산되는 VM과 동일한 프로젝트에 정의되어야 합니다.

공유 VPC 네트워크에서 부하 분산기를 사용하려면 내부 전달 규칙이 반드시 백엔드 VM이 있는 서비스 프로젝트와 동일한 서비스 프로젝트에 정의되어야 하고 또한 연결된 내부 IP 주소가 참조하는 것과 동일한 서브넷(공유 VPC 네트워크의)을 참조해야 합니다.

서비스 프로젝트에서 이 서비스 프로젝트 자체의 VPC 네트워크 안의 서브넷을 참조하는 내부 전달 규칙을 생성하면 내부 TCP/UDP 부하 분산기는 공유 VPC 네트워크가 아니라 해당 네트워크에 대해 로컬입니다.
공유 VPC 시나리오에서 백엔드 VM은 서비스 프로젝트에 있습니다. 바로 이 서비스 프로젝트에 리전 내부 백엔드 서비스와 상태 확인이 정의되어야 합니다.

예시 및 사용 사례

기본 개념

다음 예시는 간단한 공유 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 구성원에 의해 생성됩니다.

여러 호스트 프로젝트

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

여러 호스트 프로젝트(확대하려면 클릭)
여러 호스트 프로젝트(확대하려면 클릭)
  • 조직의 공유 VPC 관리자가 두 개의 호스트 프로젝트를 만들고 여기에 두 개의 서비스 프로젝트를 다음과 같이 연결했습니다.

    • Apps TestingMobile Testing 서비스 프로젝트는 Test Environment 호스트 프로젝트에 연결되었습니다. 각 서비스 프로젝트 관리자는 Testing Network의 서브넷 전체 또는 일부에 액세스하도록 구성될 수 있습니다.

    • Apps ProductionMobile Production 서비스 프로젝트는 Production Environment 호스트 프로젝트에 연결되었습니다. 각 서비스 프로젝트 관리자는 Production Network의 서브넷 전체 또는 일부에 액세스하도록 구성될 수 있습니다.

  • 두 호스트 프로젝트에는 동일한 CIDR 범위를 사용하도록 구성된 서브넷이 있는 공유 VPC 네트워크가 하나 있습니다. Testing NetworkProduction Network에서 두 서브넷은 다음과 같습니다.

    • us-west1 리전의 10.0.1.0/24 Subnet

    • us-east1 리전의 10.15.2.0/24 Subnet

  • Apps Testing 서비스 프로젝트의 Instance ATApps 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 Subnetus-west1 리전에 있으므로 이 서브넷을 사용하여 인스턴스를 생성하는 서비스 프로젝트 관리자는 us-west1-a와 같이 동일한 리전의 영역을 선택해야 합니다.

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

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

하이브리드 클라우드(확대하려면 클릭)
하이브리드 클라우드(확대하려면 클릭)

이 예시에서 조직은 단일 공유 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 A10.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 B10.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 C10.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단계 웹 서비스

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

2단계 웹 서비스(확대하려면 클릭)
2단계 웹 서비스(확대하려면 클릭)

공유 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 관리자는 네트워크 관리 작업을 네트워크 및 보안 관리자에게 위임할 수 있습니다.

다음 단계