공유 VPC를 사용하는 조직은 여러 프로젝트의 리소스를 공통 가상 프라이빗 클라우드(VPC) 네트워크에 연결할 수 있으므로 해당 네트워크의 내부 IP를 사용하여 서로 안전하고 효율적으로 통신할 수 있습니다.
공유 VPC를 사용하는 경우 프로젝트 하나를 공유 VPC 호스트 프로젝트로 지정하고 여기에 다른 서비스 프로젝트 하나 이상을 연결합니다. 공유 VPC 호스트 프로젝트의 VPC 네트워크를 공유 VPC 네트워크라고 합니다. 서비스 프로젝트의 요건을 충족하는 리소스는 공유 VPC 네트워크의 서브넷을 사용할 수 있습니다.
Migrate to Virtual Machines에서 공유 VPC 사용
Migrate to Virtual Machines 환경에서 공유 VPC를 사용하는 경우 마이그레이션된 VM을 Compute Engine 대상 프로젝트에 배포할 수 있도록 권한을 올바르게 구성했는지 확인해야 합니다.
예를 들어 다음과 같은 환경이 있다고 가정해 보겠습니다.
프로젝트 A - Migrate to Virtual Machines 호스트 프로젝트
프로젝트 B - 공유 VPC 호스트 프로젝트 및 서브넷 정의
프로젝트 C - Migrate to Virtual Machines 대상 프로젝트 및 공유 VPC 서비스 프로젝트
이 예시에서는 프로젝트 B에 공유 VPC를 정의합니다. 프로젝트 B를 공유 VPC 호스트 프로젝트라고 합니다.
그런 다음 VM을 Migrate to Virtual Machines 대상 프로젝트인 프로젝트 C의 Compute Engine 인스턴스로 마이그레이션합니다. 여기서 프로젝트 C는 공유 VPC에 액세스합니다. 이 예시에서 프로젝트 C를 공유 VPC 서비스 프로젝트라고 합니다. Compute Engine 인스턴스를 배포하기 전에 공유 VPC 프로비저닝에 설명된 대로 프로젝트 C가 프로젝트 B의 서비스 프로젝트로 작동하도록 구성한 상태여야 합니다.
하지만 Compute Engine 인스턴스를 배포하기 전에 프로젝트 A의 Migrate to Virtual Machines 기본 서비스 계정에 필요한 권한이 있는지 확인해야 합니다. 특히 Migrate to Virtual Machines에는 공유 VPC 호스트 프로젝트의 서브네트워크에 compute.networkUser 역할이 필요합니다.
다음 섹션에서는 Migrate to Virtual Machines 기본 서비스 계정을 구성하는 방법을 설명합니다.
공유 VPC에 액세스하는 대상 프로젝트에 Compute Engine 인스턴스를 배포하려면 공유 VPC 호스트 프로젝트의 서브네트워크에 대한 compute.networkUser 역할을 Migrate to Virtual Machines 기본 서비스 계정에 추가해야 합니다. 이 역할을 추가하는 방법에는 두 가지가 있습니다.
공유 VPC 호스트 프로젝트의 일부 서브넷에만 액세스할 수 있는 서비스 프로젝트 관리자가 되도록 Migrate to Virtual Machines 기본 서비스 계정을 할당합니다. 이 옵션에서는 공유 VPC 호스트 프로젝트의 일부 서브넷에 대해서만 compute.networkUser 역할을 부여하여 서비스 프로젝트 관리자를 정의하는 세분화된 방법을 제공합니다.
Migrate to Virtual Machines 기본 서비스 계정이 공유 VPC 호스트 프로젝트의 모든 서브넷에 액세스할 수 있는 서비스 프로젝트 관리자가 되도록 허용합니다. 이 경우 공유 VPC 호스트 프로젝트의 compute.networkUser 역할을 Migrate to Virtual Machines 기본 서비스 계정에 부여합니다. 그러면 기본 서비스 계정이 공유 VPC 호스트 프로젝트의 모든 기존 및 향후 서브넷에 액세스할 수 있습니다.
공유 VPC 호스트 프로젝트의 모든 서브넷에 액세스하도록 Migrate to Virtual Machines 기본 서비스 계정을 구성하려면 다음 안내를 따르세요.
Google Cloud 콘솔에서 Migrate to Virtual Machines 페이지를 엽니다.
[[["이해하기 쉬움","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-04-21(UTC)"],[],[],null,["# Configure permissions for a Shared VPC\n\n[Shared VPC](/vpc/docs/shared-vpc) allows an organization to connect\nresources from multiple projects to a common [Virtual Private Cloud (VPC) network](/vpc/docs/vpc)\nso that they can communicate with each other securely and efficiently using\ninternal IPs from that network.\n\nWhen you use Shared VPC, you designate a project as a\n*Shared VPC host project* and attach one or more *service projects* to\nit. The VPC networks in the Shared VPC host project are\ncalled *Shared VPC networks* . [Eligible resources](/vpc/docs/shared-vpc#resources_that_can_be_attached_to_shared_vpc_networks_from_a_service_project)\nfrom service projects can use subnets in the Shared VPC network.\n| **Note:** Both Migrate to Virtual Machines and Shared VPC use the term *host* project. For Migrate to Virtual Machines, you use the *host* project to perform migrations. For Shared VPC, you use the *host* project to define the VPC network.\n\nUse Shared VPC with Migrate to Virtual Machines\n-----------------------------------------------\n\nWhen your Migrate to Virtual Machines environment uses a Shared VPC, you must\nensure that you have configured permissions correctly so that you can deploy a\nmigrated VM to the Compute Engine target project.\n\nFor example, you have the following environment:\n\n- Project A - Migrate to Virtual Machines host project\n- Project B - Shared VPC host project and subnet definitions\n- Project C - Migrate to Virtual Machines target project and Shared VPC service project\n\nIn this example, you define a Shared VPC in Project B. Project B is\nreferred to as the Shared VPC *host project*.\n\nYou then migrate a VM to a Compute Engine instance in Project C, the\nMigrate to Virtual Machines target project, where Project C accesses the\nShared VPC. In this example, Project C is referred to as the\nShared VPC *service project* . You must have already configured Project C\nto function as a service project of Project B, as described in [Provisioning Shared VPC](/vpc/docs/provisioning-shared-vpc#create-shared), before you deploy the Compute Engine\ninstance.\n\nHowever, before you can deploy the Compute Engine instance, you must also\nensure that the Migrate to Virtual Machines default service account on Project A has\nthe required permissions. Specifically, Migrate to Virtual Machines requires the\n`compute.networkUser` role on the subnetworks in the Shared VPC host\nproject.\n\nThe following section describes how to configure the Migrate to Virtual Machines\ndefault service account.\n\nConfigure the Migrate to Virtual Machines default service account\n-----------------------------------------------------------------\n\nA default service account is created on the host project during the creation of\nthe first migration, as described in [Install the Migrate Connector](/migrate/virtual-machines/docs/5.0/migrate/migrate-connector).\n\nTo deploy a Compute Engine instance to a target project that accesses a\nShared VPC, you must add the `compute.networkUser` role on the\nsubnetworks in the Shared VPC host project to the Migrate to Virtual Machines\ndefault service account. You have two options for how you add this role:\n\n- Assign the Migrate to Virtual Machines default service account to be a\n *Service Project Admin* with access to only some of the subnets in the\n Shared VPC host project. This option provides a granular means to\n define Service Project Admins by granting them the `compute.networkUser` role\n for only some subnets in the Shared VPC host project.\n\n See [Service Project Admins for some subnets](/vpc/docs/provisioning-shared-vpc#networkuseratsubnet)\n for the steps to this procedure.\n- Allow the Migrate to Virtual Machines default service account to be a\n *Service Project Admin* with access to all subnets in the Shared VPC\n host project. In this case, you grant the role of `compute.networkUser` for\n the Shared VPC host project to the Migrate to Virtual Machines default\n service account. The default service account then has access to all the\n existing and future subnets in the Shared VPC host project.\n\nTo configure the Migrate to Virtual Machines default service account for access to\n**all subnets** in the Shared VPC host project:\n\n1. Open the Migrate to Virtual Machines page in the Google Cloud console:\n\n [Go to the Migrate to Virtual Machines page](https://console.cloud.google.com/compute/mfce)\n2. Select the **Targets** tab.\n\n At the top of the page is an information box showing the email address of the\n Migrate to Virtual Machines default service account in the form:\n\n `service-`\u003cvar translate=\"no\"\u003eM4CE_HOST_PROJECT_NUMBER\u003c/var\u003e`@gcp-sa-vmmigration.iam.gserviceaccount.com`\n3. Copy the email address.\n\n4. Use that email address to grant the `compute.networkUser` role on the\n Shared VPC host project to the Migrate to Virtual Machines default service account:\n\n ```\n gcloud projects add-iam-policy-binding VPC_HOST_PROJECT_ID \\\n --member=serviceAccount:service-M4CE_HOST_PROJECT_NUMBER@gcp-sa-vmmigration.iam.gserviceaccount.com \\\n --role=roles/compute.networkUser\n ```\n\nFor more on assigning roles and permissions to a user account, see\n[Granting, changing, and revoking access to resources](/iam/docs/granting-changing-revoking-access)."]]
