청사진 배포

Last reviewed 2023-12-20 UTC

이 섹션에서는 청사진을 배포하는 데 사용할 수 있는 프로세스, 이름 지정 규칙, 청사진 권장사항의 대안에 대해 설명합니다.

총정리

이 청사진의 권장사항에 따라 자체 엔터프라이즈 기반을 배포하려면 이 섹션에 요약된 주요 태스크를 수행하세요. 배포를 위해서는 기본 요건 설정 단계, GitHub의 terraform-example-foundation을 통한 자동화 배포, 초기 기반 배포가 완료된 후 수동으로 구성해야 하는 추가 단계를 조합해야 합니다.

프로세스 단계

기반 파이프라인 리소스 배포 전 기본 요건

기반 파이프라인을 배포하기 전에 다음 단계를 완료하세요.

기존 온프레미스 환경에 연결하려면 다음을 준비하세요.

GitHub에서 terraform-example-foundation 배포 단계

각 단계의 README 안내에 따라 GitHub에서 terraform-example-foundation을 배포합니다.

  • 기반 파이프라인을 만들기 위해 0-bootstrap을 스테이징합니다.

    셀프서비스 결제 계정을 사용하는 경우 다음 단계로 진행하기 전 추가 프로젝트 할당량을 요청해야 합니다.

  • 조직 수준 리소스를 구성하기 위해 1-org를 스테이징합니다.
  • 환경을 만들기 위해 2-environments를 스테이징합니다.
  • 원하는 토폴로지로 네트워킹 리소스를 만들기 위해 3-networks-dual-svpc or 3-networks-hub-and-spoke를 스테이징합니다.
  • 인프라 파이프라인을 만들기 위해 4-projects를 스테이징합니다.
  • 선택적으로 인프라 파이프라인의 샘플 사용을 위해 5-app-infra를 스테이징합니다.

IaC 배포 후 추가 단계

Terraform 코드를 배포한 후 다음을 완료합니다.

민감한 워크로드를 사용하는 고객의 추가 관리 제어

Google Cloud는 보안 및 규정 준수 요구사항에 도움이 되는 추가 관리 제어를 제공합니다. 그러나 일부 제어에는 고객에 따라 적합하지 않을 수 있는 추가 비용 또는 운영상의 장단점이 있습니다. 이러한 제어는 또한 모든 고객에 대한 기본값을 사용하여 청사진에서 완전히 자동화할 수 없는 특정 요구사항에 따라 맞춤설정된 입력이 요구됩니다.

이 섹션에서는 사용자 기반에 대해 중앙에서 적용하는 보안 제어를 보여줍니다. 이 섹션은 특정 워크로드에 적용할 수 있는 모든 보안 제어를 포함하지 않습니다. Google 보안 제품 및 솔루션에 대한 자세한 내용은 Google Cloud 보안 권장사항 센터를 참조하세요.

규정 준수 요구사항, 위험 성향, 데이터 민감도를 기준으로 다음 제어가 사용자 기반에 적합한지 여부를 평가하세요.

제어 설명

VPC 서비스 제어로 리소스 보호

VPC 서비스 제어는 신뢰할 수 있는 경계 외부의 Google 관리형 서비스에 대한 액세스를 차단하고, 신뢰할 수 없는 위치의 데이터에 대한 액세스를 차단하고, 데이터 무단 반출 위험을 완화하는 보안 정책을 정의할 수 있도록 합니다. 그러나 VPC 서비스 제어를 사용하면 의도한 액세스 패턴을 허용하도록 예외를 정의할 때까지 기존 서비스가 중단될 수 있습니다.

유출 위험 완화로 얻을 수 있는 가치가 VPC 서비스 제어 채택으로 인한 복잡성 증가와 운영 오버헤드보다 나은지 평가합니다. 청사진은 VPC 서비스 제어를 구성하도록 제한된 네트워크 및 선택적인 변수를 준비하지만 이를 설계하고 사용 설정하기 위해 추가 단계를 수행할 때까지는 경계가 사용 설정되지 않습니다.

리소스 위치 제한

규제 요구사항에 따라 클라우드 리소스를 승인된 지리적 위치에만 배포해야 할 수 있습니다. 이 조직 정책 제약조건에 따라서는 정의한 위치 목록에만 리소스를 배포할 수 있습니다.

Assured Workloads 사용 설정

Assured Workloads는 특정 규제 체제를 충족하는 데 도움이 되는 추가 규정 준수 제어를 제공합니다. 청사진은 배포 파이프라인에서 사용 설정을 위한 선택적인 변수를 제공합니다.

데이터 액세스 로그 사용 설정

요구사항에 따라 특정 민감한 정보 또는 리소스에 대한 모든 액세스를 로깅해야 할 수 있습니다.

워크로드가 데이터 액세스 로그를 필요로 하는 민감한 정보를 처리하는 위치를 평가하고 민감한 정보로 작동하는 각 서비스 및 환경에 대해 로그를 사용 설정합니다.

액세스 승인 사용 설정

액세스 승인을 사용하면 Cloud Customer Care 및 엔지니어링에서 고객 콘텐츠에 액세스해야 할 때마다 명시적인 승인을 요구하도록 보장합니다.

지원 이슈 해결 시 발생 가능한 지연을 완화하기 위해 액세스 승인 요청을 검토하는 데 필요한 운영 프로세스를 평가합니다.

키 액세스 근거 사용 설정

키 액세스 근거를 사용하면 자동화된 작업을 포함하고 고객 지원이 고객 콘텐츠에 액세스할 수 있도록 Google이 암호화 키에 액세스할 수 있는지 여부를 프로그래매틱 방식으로 제어할 수 있습니다.

Cloud 외부 키 관리자(Cloud EKM)에 대한 종속 항목과 함께 키 액세스 근거와 관련된 비용 및 운영 오버헤드를 평가합니다.

Cloud Shell 사용 중지

Cloud Shell은 온라인 개발 환경입니다. 이 셸은 환경 외부의 Google 관리 서버에서 호스팅되므로 자체 개발자 워크스테이션에 구현된 제어가 적용되지 않습니다.

개발자가 클라우드 리소스에 액세스하기 위해 사용할 수 있는 워크스테이션을 엄격하게 제어하려면 Cloud Shell을 사용 중지하세요. 또한 자체 환경에서 구성 가능한 워크스테이션 옵션에 대해 Cloud Workstations를 평가할 수 있습니다.

Google Cloud 콘솔 액세스 제한

Google Cloud를 사용하면 그룹 멤버십, 신뢰할 수 있는 IP 주소 범위, 기기 확인과 같이 액세스 수준 속성 기반의 Google Cloud 콘솔에 대한 액세스를 제한할 수 있습니다. 일부 속성에는 BeyondCorp Enterprise에 대한 추가 구독이 필요합니다.

더 큰 제로 트러스트 배포의 일부로 콘솔과 같은 웹 기반 애플리케이션의 사용자 액세스에 대해 신뢰하는 액세스 패턴을 평가합니다.

이름 지정 규칙

Google Cloud 리소스에 대해 표준화된 이름 지정 규칙을 사용하는 것이 좋습니다. 다음 표에서는 청사진에서 리소스 이름에 대해 권장되는 규칙을 설명합니다.

리소스 이름 지정 규칙

폴더

fldr-environment

environment는 Google Cloud 조직 내에서 폴더 수준 리소스에 대한 설명입니다. 예를 들면 bootstrap, common, production, nonproduction, development, network입니다.

예: fldr-production

프로젝트 ID

prj-environmentcode-description-randomid

  • environmentcode는 환경 필드(b, c, p, n, d, net 중 하나)의 약식 형태입니다. 공유 VPC 호스트 프로젝트는 연결된 환경의 environmentcode를 사용합니다. interconnect 프로젝트와 같이 환경 간에 공유된 네트워킹 리소스에 대한 프로젝트는 net 환경 코드를 사용합니다.
  • description은 프로젝트에 대한 추가 정보입니다. 인간이 읽을 수 있는 짧은 약어를 사용할 수 있습니다.
  • randomid는 전역적으로 고유해야 하는 리소스 이름의 충돌을 방지하고 리소스 이름을 추측하는 공격자를 방어하기 위해 무작위로 생성된 서픽스입니다. 청사진은 4글자로 된 무작위 영숫자 식별자를 자동으로 추가합니다.

예: prj-c-logging-a1b2

VPC 네트워크

vpc-environmentcode-vpctype-vpcconfig

  • environmentcode는 환경 필드(b, c, p, n, d, net 중 하나)의 약식 형태입니다.
  • vpctype은 shared, float, peer 중 하나입니다.
  • vpcconfig는 네트워크가 VPC 서비스 제어에 사용하도록 의도되었는지 여부를 나타내는 base 또는 restricted입니다.

예: vpc-p-shared-base

서브넷

sn-environmentcode-vpctype-vpcconfig-region{-description}

  • environmentcode는 환경 필드(b, c, p, n, d, net 중 하나)의 약식 형태입니다.
  • vpctype은 shared, float, peer 중 하나입니다.
  • vpcconfig는 네트워크가 VPC 서비스 제어에 사용하도록 의도되었는지 여부를 나타내는 base 또는 restricted입니다.
  • region은 리소스가 있는 모든 유효한 Google Cloud 리전입니다. 하이픈을 삭제하고 글자 수 제한에 걸리지 않도록 일부 리전 및 방향의 약식 형태를 사용하는 것이 좋습니다. 예를 들면 au(오스트레일리아), na(북미), sa(남미), eu(유럽), se(남동), ne(북동)입니다.
  • description은 서브넷에 대한 추가 정보입니다. 인간이 읽을 수 있는 짧은 약어를 사용할 수 있습니다.

예: sn-p-shared-restricted-uswest1

방화벽 정책

fw-firewalltype-scope-environmentcode{-description}

  • firewalltype은 hierarchical 또는 network입니다.
  • scope은 global 또는 리소스가 있는 Google Cloud 리전입니다. 하이픈을 삭제하고 글자 수 제한에 걸리지 않도록 일부 리전 및 방향의 약식 형태를 사용하는 것이 좋습니다. 예를 들면 au(오스트레일리아), na(북미), sa(남미), eu(유럽), se(남동), ne(북동)입니다.
  • environmentcode는 정책 리소스를 소유하는 환경 필드(b, c, p, n, d, net 중 하나)의 약식 형태입니다.
  • description은 계층적 방화벽 정책에 대한 추가 정보입니다. 인간이 읽을 수 있는 짧은 약어를 사용할 수 있습니다.

예를 들면 다음과 같습니다.

fw-hierarchical-global-c-01

fw-network-uswest1-p-shared-base

Cloud Router

cr-environmentcode-vpctype-vpcconfig-region{-description}

  • environmentcode는 환경 필드(b, c, p, n, d, net 중 하나)의 약식 형태입니다.
  • vpctype은 shared, float, peer 중 하나입니다.
  • vpcconfig는 네트워크가 VPC 서비스 제어에 사용하도록 의도되었는지 여부를 나타내는 base 또는 restricted입니다.
  • region은 리소스가 있는 모든 유효한 Google Cloud 리전입니다. 하이픈을 삭제하고 글자 수 제한에 걸리지 않도록 일부 리전 및 방향의 약식 형태를 사용하는 것이 좋습니다. 예를 들면 au(오스트레일리아), na(북미), sa(남미), eu(유럽), se(남동), ne(북동)입니다.
  • description은 Cloud Router에 대한 추가 정보입니다. 인간이 읽을 수 있는 짧은 약어를 사용할 수 있습니다.

예: cr-p-shared-base-useast1-cr1

Cloud Interconnect 연결

ic-dc-colo

  • dc는 Cloud Interconnect가 연결된 데이터 센터의 이름입니다.
  • colo는 온프레미스 데이터 센터의 Cloud Interconnect가 피어링되는 코로케이션 시설 이름입니다.

예: ic-mydatacenter-lgazone1

Cloud Interconnect VLAN 연결

vl-dc-colo-environmentcode-vpctype-vpcconfig-region{-description}

  • dc는 Cloud Interconnect가 연결된 데이터 센터의 이름입니다.
  • colo는 온프레미스 데이터 센터의 Cloud Interconnect가 피어링되는 코로케이션 시설 이름입니다.
  • environmentcode는 환경 필드(b, c, p, n, d, net 중 하나)의 약식 형태입니다.
  • vpctype은 shared, float, peer 중 하나입니다.
  • vpcconfig는 네트워크가 VPC 서비스 제어에 사용하도록 의도되었는지 여부를 나타내는 base 또는 restricted입니다.
  • region은 리소스가 있는 모든 유효한 Google Cloud 리전입니다. 하이픈을 삭제하고 글자 수 제한에 걸리지 않도록 일부 리전 및 방향의 약식 형태를 사용하는 것이 좋습니다. 예를 들면 au(오스트레일리아), na(북미), sa(남미), eu(유럽), se(남동), ne(북동)입니다.
  • description은 VLAN에 대한 추가 정보입니다. 인간이 읽을 수 있는 짧은 약어를 사용할 수 있습니다.

예: vl-mydatacenter-lgazone1-p-shared-base-useast1-cr1

그룹

grp-gcp-description@example.com

여기서 description은 그룹에 대한 추가 정보입니다. 인간이 읽을 수 있는 짧은 약어를 사용할 수 있습니다.

예: grp-gcp-billingadmin@example.com

커스텀 역할

rl-description

여기서 description은 역할에 대한 추가 정보입니다. 인간이 읽을 수 있는 짧은 약어를 사용할 수 있습니다.

예: rl-customcomputeadmin

서비스 계정

sa-description@projectid.iam.gserviceaccount.com

각 항목의 의미는 다음과 같습니다.

  • description은 서비스 계정에 대한 추가 정보입니다. 인간이 읽을 수 있는 짧은 약어를 사용할 수 있습니다.
  • projectid는 전역적으로 고유한 프로젝트 식별자입니다.

예: sa-terraform-net@prj-b-seed-a1b2.iam.gserviceaccount.com

스토리지 버킷

bkt-projectid-description

각 항목의 의미는 다음과 같습니다.

  • projectid는 전역적으로 고유한 프로젝트 식별자입니다.
  • description은 스토리지 버킷에 대한 추가 정보입니다. 인간이 읽을 수 있는 짧은 약어를 사용할 수 있습니다.

예: bkt-prj-c-infra-pipeline-a1b2-app-artifacts

기본 권장사항의 대안

청사진에 권장되는 권장사항이 모든 고객에게 적합하지는 않을 수 있습니다. 특정 요구사항을 충족하도록 권장사항을 맞춤설정할 수 있습니다. 다음 표에서는 기존 기술 스택 및 작동 방법에 따라 필요할 수 있는 일반적인 변형을 보여줍니다.

결정 영역 가능한 대안

조직: 청사진은 단일 조직을 모든 리소스의 루트 노드로 사용합니다.

Google Cloud 시작 영역의 리소스 계층 구조 결정에서는 다음과 같이 여러 조직을 선호할 수 있는 시나리오에 대해 설명합니다.

  • 조직에 이후에 판매될 가능성이 있거나 완전히 별개의 항목으로 실행되는 하위 회사가 포함되어 있습니다.
  • 기존 조직에 연결되지 않은 샌드박스 환경에서 실험하려고 합니다.

폴더 구조: 청사진에 워크로드가 최상위 계층의 production, non-production 및 development 폴더로 분할된 단순 폴더 구조가 포함됩니다.

Google Cloud 시작 영역의 리소스 계층 구조 결정에서는 다음과 같이 원하는 리소스 관리 및 정책 상속 방법을 기준으로 폴더를 구성하는 다른 방법을 설명합니다.

  • 애플리케이션 환경 기반 폴더
  • 리전 항목 및 자회사 기반 폴더
  • 책임성 프레임워크 기반 폴더

조직 정책: 청사진이 조직 노드에서 모든 조직 정책 제약조건을 적용합니다.

비즈니스의 여러 부분에 따라 보안 정책 또는 작동 방식이 서로 다를 수 있습니다. 이 시나리오에서는 리소스 계층 구조의 하위 노드에서 조직 정책 제약조건을 적용합니다. 요구사항을 충족하는 데 도움이 되는 조직 정책 제약조건의 전체 목록을 검토하세요.

배포 파이프라인 도구: 청사진은 Cloud Build를 사용하여 자동화 파이프라인을 실행합니다.

Terraform Enterprise, GitLab Runners, GitHub Actions, Jenkins와 같이 배포 파이프라인에 대해 다른 제품을 선호할 수 있습니다. 청사진에는 각 제품의 대안 안내가 포함되어 있습니다.

배포를 위한 코드 저장소: 청사진은 Cloud Source Repositories를 관리되는 비공개 Git 저장소로 사용합니다.

GitLab, GitHub, Bitbucket과 같이 코드 저장소 관리를 위해 선호되는 버전 제어 시스템을 사용하세요.

온프레미스 환경에 호스팅되는 비공개 저장소를 사용하는 경우 저장소에서 Google Cloud 환경으로의 비공개 네트워크 경로를 구성합니다.

ID 공급업체: 청사진은 온프레미스 Active Directory를 가정하고 Google Cloud 디렉터리 동기화를 사용해서 ID를 Cloud ID에 통합합니다.

이미 Google Workspace를 사용하는 경우 이미 Google Workspace에서 관리되는 Google ID를 사용할 수 있습니다.

기존 ID 공급업체가 없으면 Cloud ID에서 직접 사용자 ID를 만들고 관리할 수 있습니다.

Okta, Ping, Azure Entra ID와 같은 기존 ID 공급업체를 사용하는 경우 기존 ID 공급업체에서 사용자 계정을 관리하고 Cloud ID에 동기화할 수 있습니다.

데이터 주권 또는 규정 준수 요구사항에 따라 Cloud ID 사용이 금지되고 Google Ads 또는 Google Marketing Platform과 같은 다른 Google 서비스에 대해 관리되는 Google 사용자 ID가 필요하지 않으면 직원 ID 제후를 선호할 수 있습니다. 이 시나리오에서는 지원되는 서비스 관련 제한사항에 주의하세요.

여러 리전: 청사진은 고가용성 및 재해 복구 요구사항을 고려해서 워크로드 설계를 사용 설정하는 데 도움이 되도록 리전 리소스를 두 가지 서로 다른 Google Cloud 리전에 배포합니다.

더 많은 지리적 위치에 최종 사용자가 있으면 리소스를 최종 사용자에게 더 가깝게 만들고 지연 시간을 줄이기 위해 더 많은 Google Cloud 리전을 구성할 수 있습니다.

데이터 주권 제약조건 또는 가용성 요구를 단일 리전으로 충족할 수 있으면 Google Cloud 리전을 하나만 구성할 수 있습니다.

IP 주소 할당: 청사진은 IP 주소 범위 집합을 제공합니다.

기존 하이브리드 환경의 IP 주소 가용성을 기반으로 사용되는 특정 IP 주소 범위를 변경해야 할 수 있습니다. IP 주소 범위를 수정할 경우 필요한 범위 수 및 크기에 대한 안내에 따라 청사진을 사용하고 Google Cloud에 유효한 IP 주소 범위를 검토합니다.

하이브리드 네트워킹: 청사진은 최대한의 대역폭 및 가용성을 위해 여러 물리적 사이트 및 Google Cloud 리전 간에 Dedicated Interconnect를 사용합니다.

비용, 대역폭, 신뢰성 요구사항에 따라 Partner Interconnect 또는 Cloud VPN을 대신 구성할 수 있습니다.

Dedicated Interconnect를 완료하기 전 비공개 연결로 리소스 배포를 시작해야 하는 경우 Cloud VPN으로 시작해서 나중에 Dedicated Interconnect를 사용하도록 변경할 수 있습니다.

기존 온프레미스 환경이 없으면 하이브리드 네트워킹이 필요하지 않을 수 있습니다.

VPC 서비스 제어 경계: 청사진에서는 제한된 VPC 네트워크와 연결된 모든 서비스 프로젝트를 포함하는 단일 경계가 권장됩니다. 기본 VPC 네트워크와 연결된 프로젝트는 경계 내에 포함되지 않습니다.

사용 사례에 따라 조직에 여러 경계가 필요할 수도 있고 VPC 서비스 제어를 전혀 사용하지 않도록 결정할 수도 있습니다.

자세한 내용은 Google API를 통한 데이터 무단 반출 완화 방법 결정을 참조하세요.

Secret Manager: 청사진은 조직 전체 보안 비밀에 대해 common 폴더에서 Secret Manager를 사용하도록 프로젝트를 배포하고, 환경 특정 보안 비밀에 대해서는 각 환경 폴더에 프로젝트를 배포합니다.

조직 전체에서 민감한 보안 비밀을 관리 및 감사하는 단일 팀이 있으면 단일 프로젝트만 사용해서 보안 비밀 액세스를 관리하는 방식을 선호할 수 있습니다.

워크로드팀이 자체 보안 비밀을 관리하도록 허용할 경우 보안 비밀 액세스 관리를 위해 중앙 집중화된 프로젝트를 사용하는 대신 팀이 워크로드 프로젝트에서 자체 Secret Manager 인스턴스를 사용하도록 허용할 수 있습니다.

Cloud KMS: 청사진은 조직 전체 키에 대해 common 폴더에서 Cloud KMS 사용을 위해 프로젝트를 배포하고 각 환경의 키에 대해서는 각 환경 폴더에 대해 프로젝트를 배포합니다.

조직 전체에서 암호화 키를 관리 및 감사하는 단일 팀이 있으면 단일 프로젝트만 사용해서 키 액세스를 관리하는 방식을 선호할 수 있습니다. 중앙 집중화된 방식은 PCI 키 관리자와 같은 규정 준수 요구사항을 충족하는 데 도움이 될 수 있습니다.

워크로드팀이 자체 키를 관리하도록 허용할 경우 키 액세스 관리를 위해 중앙 집중화된 프로젝트를 사용하는 대신 팀이 워크로드 프로젝트에서 자체 Cloud KMS 인스턴스를 사용하도록 허용할 수 있습니다.

집계된 로그 싱크: 청사진은 중앙 보안팀이 전체 조직의 감사 로그를 검토할 수 있도록 조직 노드에서 로그 싱크 집합을 구성합니다.

여러 비즈니스 부분을 감사하는 여러 팀이 있고 이러한 팀에서 해당 작업 수행을 위해 서로 다른 로그가 필요할 수 있습니다. 이 시나리오에서는 적절한 폴더 및 프로젝트에서 여러 집계된 싱크를 설계하고 필터를 만들어서 각 팀에 필요한 로그만 수신되도록 하거나 일반적인 로그 버킷에 대해 세부적인 액세스 제어를 위해 로그 보기를 설계합니다.

모니터링 범위 지정 프로젝트: 청사진은 각 환경에 대해 단일 모니터링 범위 지정 프로젝트를 구성합니다.

각 팀이 관리하는 애플리케이션이 포함된 프로젝트 집합으로 범위가 지정된 여러 팀에서 관리되는 보다 세부적인 범위 지정 프로젝트를 구성할 수 있습니다.

인프라 파이프라인 세분성: 청사진은 각 비즈니스 단위에 워크로드 프로젝트 관리를 위한 개별 인프라 파이프라인이 있는 모델을 사용합니다.

모든 프로젝트 및 인프라 배포를 책임지는 중앙 팀이 있는 경우 중앙 팀에서 관리되는 단일 인프라 파이프라인을 선호할 수 있습니다. 이러한 중앙 팀은 워크로드팀의 pull 요청을 수락하여 프로젝트 생성 전 검토 및 승인을 수행하거나 티켓 시스템에 대한 응답으로 자체적으로 pull 요청을 만들 수 있습니다.

개별 워크로드팀에 자체 파이프라인을 맞춤설정하는 기능이 있고 파이프라인에 대해 보다 세부적인 권한 서비스 계정을 설계하려는 경우 보다 세부적인 파이프라인을 선호할 수 있습니다.

SIEM 내보내기:청사진은 Security Command Center에서 모든 보안 발견 항목을 관리합니다.

Security Command Center의 보안 발견 항목을 Google Security Operations 또는 기존 SIEM과 같은 도구로 내보내거나 팀이 콘솔을 사용해서 보안 발견 항목을 보고 관리할지 여부를 결정합니다. 범위 및 책임이 서로 다른 각 팀에 대해 고유한 필터를 사용해서 여러 내보내기를 구성할 수 있습니다.

온프레미스에서 Google Cloud 서비스에 대한 DNS 조회: 청사진은 여러 VPC 서비스 제어 경계로 설계를 사용 설정하는 데 도움이 되는 각 공유 VPC에 대해 고유한 Private Service Connect 엔드포인트를 구성합니다.

여러 VPC 서비스 제어 경계가 필요하지 않으면 이 세분성 수준에서 온프레미스 환경에서 Private Service Connect 엔드포인트로 라우팅이 필요하지 않을 수 있습니다.

환경에 따라 온프레미스 호스트를 Private Service Connect 엔드포인트에 매핑하는 대신 적합한 API 번들과 함께 단일 Private Service Connect 엔드포인트를 사용하거나 private.googlepais.com 및 restricted.googleapis.com에 대해 일반 엔드포인트를 사용하도록 이 설계를 단순화할 수 있습니다.

다음 단계