네트워킹

네트워킹은 Google Cloud 조직 내에서 그리고 클라우드 환경과 온프레미스 환경 사이의 통신을 위한 리소스에 반드시 필요합니다. 이 섹션에서는 VPC 네트워크, IP 주소 공간, DNS, 방화벽 정책, 온프레미스 환경에 대한 연결의 청사진 구조에 대해 설명합니다.

네트워크 토폴로지

청사진 저장소는 다음과 같은 네트워크 토폴로지 옵션을 제공합니다.

• 환경 간에 직접 허용되는 네트워크 트래픽 없이 각 환경에 개별 공유 VPC 네트워크 사용하기
• 허브 및 스포크 모델을 사용하여, 네트워크 가상 어플라이언스 (NVA)로 통제되는 환경 간의 네트워크 트래픽으로 Google Cloud의 각 환경을 연결하는 허브 네트워크 추가하기

환경 간에 직접 네트워크 연결을 원하지 않으면 각 환경의 공유 VPC 네트워크 토폴로지를 선택하세요. 해당 환경의 모든 서버에 직접 네트워크 경로가 필요한 기존 도구에 의지할 때처럼 NVA에서 필터링되는 환경 간에 네트워크 연결을 허용하려면 허브 및 스포크 네트워크 토폴로지를 선택하세요.

두 토폴로지 모두 공유 VPC를 기본 네트워킹 구성 요소로 사용하는데, 이는 공유 VPC는 책임 소재를 명확하게 구분할 수 있기 때문입니다. 네트워크 관리자는 중앙 집중식 호스트 프로젝트의 네트워크 리소스를 관리하고 워크로드팀은 자체 애플리케이션 리소스를 배포하고 호스트 프로젝트에 연결된 서비스 프로젝트에서 네트워크 리소스를 사용합니다.

각 환경 토폴로지의 공유 VPC 네트워크

Google Cloud에서 개발, 비프로덕션, 프로덕션 네트워크 간에 네트워크를 격리해야 하는 경우에는 각 환경 토폴로지에 공유 VPC 네트워크를 사용하는 것이 좋습니다. 이 토폴로지에서는 환경 간에 네트워크 트래픽이 허용되지 않습니다.

다음 다이어그램은 각 환경 토폴로지의 공유 VPC 네트워크를 보여줍니다.

이 다이어그램은 각 환경 토폴로지에 대한 공유 VPC의 다음과 같은 주요 개념을 설명합니다.

• 각 환경 (프로덕션, 비프로덕션, 개발)에는 공유 VPC 네트워크가 하나 있습니다. 이 다이어그램에서는 프로덕션 환경만 표시되어 있지만, 각 환경에는 동일한 패턴이 반복됩니다.
• 각 공유 VPC 네트워크에는 서브넷이 두 개 있으며 각 서브넷은 서로 다른 리전에 있습니다.
• 4개의 Cloud Router 서비스(중복화를 위해 각 리전에 2개씩)를 사용하여 각 공유 VPC 네트워크의 Dedicated Interconnect 인스턴스에 4개의 VLAN 연결을 통해 온프레미스 리소스와의 연결이 설정됩니다. 자세한 내용은 온프레미스 환경과 Google Cloud 사이의 하이브리드 연결을 참고하세요.

이 토폴로지는 네트워크 트래픽이 환경 간에 직접 이동할 수 없도록 설계되었습니다. 환경 간에 네트워크 트래픽이 직접 이동해야 하는 경우, 이 네트워크 경로를 허용하는 추가 단계를 수행해야 합니다. 예를 들어 한 VPC 네트워크의 서비스를 다른 VPC 네트워크에 노출하도록 Private Service Connect 엔드포인트를 구성할 수 있습니다. 또는 한Google Cloud 환경에서 온프레미스 환경으로 그런 다음 다른 Google Cloud 환경으로 트래픽이 전달될 수 있도록 온프레미스 네트워크를 구성할 수 있습니다.

허브 및 스포크 네트워크 토폴로지

여러 환경의 리소스에 대한 직접 네트워크 경로가 필요한 리소스를 Google Cloud 에 배포하는 경우에는 허브 및 스포크 네트워크 토폴로지를 사용하는 것이 좋습니다.

허브 및 스포크 토폴로지는 각 환경 토폴로지의 공유 VPC 네트워크에 포함된 여러 개념을 사용하지만 토폴로지를 수정하여 허브 네트워크를 추가합니다. 다음 다이어그램은 허브 및 스포크 토폴로지를 보여줍니다.

이 다이어그램에서는 허브 및 스포크 네트워크 토폴로지의 주요 개념을 설명합니다.

• 이 모델은 허브 네트워크를 추가하며, 각 개발, 비프로덕션, 프로덕션 네트워크(스포크)는 VPC 네트워크 피어링을 통해 허브 네트워크에 연결됩니다. 또는 할당량 한도 초과가 예상되면 대신 HA VPN 게이트웨이를 사용하면 됩니다.
• 허브 네트워크를 통해서만 온프레미스 네트워크에 연결할 수 있습니다. 모든 스포크 네트워크는 허브 네트워크의 공유 리소스와 통신하고 이 경로를 사용하여 온프레미스 네트워크에 연결할 수 있습니다.
• 허브 네트워크에는 내부 네트워크 부하 분산기 인스턴스 뒤에 중복 배포된 각 리전의 NVA가 포함됩니다. 이 NVA는 스포크 네트워크 간에 통신하는 트래픽을 허용하거나 거부하는 게이트웨이 역할을 합니다.
• 또한 허브 네트워크는 다른 모든 네트워크에 연결해야 하는 도구를 호스팅합니다. 예를 들어 구성 관리를 위해 VM 인스턴스의 도구를 공통 환경에 배포할 수 있습니다.

스포크 간 트래픽이 사용 설정되도록 청사진은 네트워크 간에 게이트웨이로 작동하는 NVA를 허브 공유 VPC 네트워크에 배포합니다. 경로는 커스텀 경로 교환을 통해 허브에서 스포크 VPC 네트워크로 교환됩니다. 이 시나리오에서는 VPC 네트워크 피어링은 전이적이지 않으므로 스포크 VPC 네트워크는 서로 직접 데이터를 교환할 수 없으므로 스포크 간의 연결은 NVA를 통해 라우팅되어야 합니다. 스포크 간의 트래픽을 선택적으로 허용하도록 가상 어플라이언스를 구성해야 합니다.

프로젝트 배포 패턴

워크로드용 새 프로젝트를 만들 때는 이 프로젝트의 리소스를 기존 네트워크에 연결하는 방법을 결정해야 합니다. 다음 표에서는 청사진에 사용되는 프로젝트를 배포하기 위한 패턴을 설명합니다.

패턴	설명	사용 예시
공유 VPC 서비스 프로젝트	이러한 프로젝트는 공유 VPC 호스트 프로젝트의 서비스 프로젝트로 구성됩니다. 프로젝트의 리소스에 다음 기준이 있는 경우 이 패턴을 사용합니다. 온프레미스 환경 또는 동일한 공유 VPC 토폴로지의 리소스에 대한 네트워크 연결이 필요한 경우	example_shared_vpc_project.tf
플로팅 프로젝트	플로팅 프로젝트는 토폴로지의 다른 VPC 네트워크에 연결되지 않습니다. 프로젝트의 리소스에 다음 기준이 있는 경우 이 패턴을 사용합니다. 온프레미스 환경 또는 공유 VPC 토폴로지의 리소스에 대한 풀 메시 연결이 필요하지 않은 경우 VPC 네트워크가 필요하지 않거나, 기본 VPC 네트워크 토폴로지와 독립적으로 이 프로젝트의 VPC 네트워크를 관리하려는 경우(예를 들어 이미 사용 중인 범위와 충돌하는 IP 주소 범위를 사용하려는 경우) 플로팅 프로젝트의 VPC 네트워크를 기본 VPC 네트워크 토폴로지와 별도로 유지하되 네트워크 간에 엔드포인트를 제한된 수만큼 노출하려는 경우가 있을 수 있습니다. 이럴 때 Private Service Connect를 사용하여 서비스를 게시하여 전체 네트워크를 노출하지 않고도 VPC 네트워크에서 개별 엔드포인트에 대한 네트워크 액세스를 공유합니다.	example_floating_project.tf
피어링 프로젝트	피어링 프로젝트는 자체 VPC 네트워크를 만들고 토폴로지의 다른 VPC 네트워크에 피어링합니다. 프로젝트의 리소스에 다음 기준이 있는 경우 이 패턴을 사용합니다. 직접 피어링된 VPC 네트워크에서 네트워크 연결이 필요하지만 온프레미스 환경 또는 다른 VPC 네트워크에 대한 전환 연결은 필요하지 않은 경우 기본 네트워크 토폴로지와 별개로 이 프로젝트의 VPC 네트워크를 관리해야 하는 경우 피어링 프로젝트를 만드는 경우 충돌하지 않는 IP 주소 범위를 할당하고 피어링 그룹 할당량을 계획하는 것은 사용자의 책임입니다.	example_peering_project.tf

IP 주소 할당

이 섹션에서는 청사진 아키텍처가 IP 주소 범위를 할당하는 방법을 소개합니다. 기존 하이브리드 환경의 IP 주소 가용성을 기반으로 사용되는 특정 IP 주소 범위를 변경해야 할 수 있습니다.

다음 표에서는 청사진에 할당된 IP 주소 공간에 대한 분석을 제공합니다. 허브 환경은 허브 및 스포크 토폴로지에서만 적용됩니다.

목적	리전	허브 환경	개발 환경	비프로덕션 환경	프로덕션 환경
기본 서브넷 범위	리전 1	10.8.0.0/18	10.8.64.0/18	10.8.128.0/18	10.8.192.0/18
	리전 2	10.9.0.0/18	10.9.64.0/18	10.9.128.0/18	10.9.192.0/18
	할당되지 않음	10.{10-15}.0.0/18	10.{10-15}.64.0/18	10.{10-15}.128.0/18	10.{10-15}.192.0/18
비공개 서비스 액세스	전역	10.16.32.0/21	10.16.40.0/21	10.16.48.0/21	10.16.56.0/21
Private Service Connect 엔드포인트	전역	10.17.0.5/32	10.17.0.6/32	10.17.0.7/32	10.17.0.8/32
프록시 전용 서브넷	리전 1	10.26.0.0/23	10.26.2.0/23	10.26.4.0/23	10.26.6.0/23
	리전 2	10.27.0.0/23	10.27.2.0/23	10.27.4.0/23	10.27.6.0/23
	할당되지 않음	10.{28-33}.0.0/23	10.{28-33}.2.0/23	10.{28-33}.4.0/23	10.{28-33}.6.0/23
보조 서브넷 범위	리전 1	100.72.0.0/18	100.72.64.0/18	100.72.128.0/18	100.72.192.0/18
	리전 2	100.73.0.0/18	100.73.64.0/18	100.73.128.0/18	100.73.192.0/18
	할당되지 않음	100.{74-79}.0.0/18	100.{74-79}.64.0/18	100.{74-79}.128.0/18	100.{74-79}.192.0/18

앞의 표는 IP 주소 범위 할당에 대한 다음의 개념을 보여줍니다.

• IP 주소 할당은 목적, 리전, 환경의 각 조합에 대한 범위로 세분화됩니다.
• 일부 리소스는 전역이며 각 리전별로 세분화할 필요가 없습니다.
• 기본적으로 리전별 리소스의 경우 청사진이 두 리전에 배포됩니다. 또한 사용되지 않는 IP 주소 범위도 있으므로 추가 리전 6개로 확장할 수 있습니다.
• 허브 네트워크는 허브 및 스포크 네트워크 토폴로지에서만 사용되는 반면 개발, 비프로덕션, 프로덕션 환경은 두 네트워크 토폴로지 모두에서 사용됩니다.

다음 표에서는 각 유형의 IP 주소 범위가 사용되는 방식을 보여줍니다.

목적	설명
기본 서브넷 범위	가상 머신 인스턴스와 같은 VPC 네트워크에 배포되는 리소스는 이 범위의 내부 IP 주소를 사용합니다.
비공개 서비스 액세스	Cloud SQL과 같은 일부 Google Cloud 서비스는 비공개 서비스 액세스에 사용할 서브넷 범위를 미리 할당해야 합니다. 청사진은 비공개 서비스 액세스가 필요한 서비스에 IP 주소를 할당하도록 공유 VPC 네트워크마다 전역적으로 /21 범위를 예약합니다. 비공개 서비스 액세스에 종속된 서비스를 만들 때는 예약된 /21 범위에서 리전 /24 서브넷을 할당합니다.
Private Service Connect	청사진은 Private Service Connect 엔드포인트가 있는 각 VPC 네트워크를 프로비저닝하여 Google Cloud API와 통신합니다. 이 엔드포인트를 사용하면 VPC 네트워크의 리소스가 인터넷이나 공개적으로 공지된 인터넷 범위에 대한 아웃바운드 트래픽을 사용하지 않고 Google Cloud API에 연결될 수 있습니다.
프록시 기반 부하 분산기	일부 유형의 애플리케이션 부하 분산기를 사용하려면 프록시 전용 서브넷을 미리 할당해야 합니다. 청사진은 이 범위가 필요한 애플리케이션 부하 분산기를 배포하지 않지만 미리 범위를 할당하면 특정 부하 분산기 리소스를 사용 설정하기 위해 새 서브넷 범위를 요청해야 할 때 워크로드에서 발생하는 문제를 줄일 수 있습니다.
보조 서브넷 범위	컨테이너 기반 워크로드와 같은 일부 사용 사례에서는 보조 범위가 필요합니다. 청사진은 보조 범위가 필요한 서비스를 배포하지는 않지만 보조 범위에 RFC 6598 IP 주소 공간의 범위를 할당합니다. 또는 이러한 서비스에 충분히 큰 CIDR 블록을 할당하는 데 어려움이 있는 경우 프로젝트 배포 패턴 섹션에서 소개된 플로팅 프로젝트 패턴에 이러한 서비스를 배포하는 것이 좋습니다.

중앙 집중식 DNS 설정

Google Cloud 와 온프레미스 환경 간의 DNS 변환을 위해서는 권한 있는 DNS 시스템 2개로 하이브리드 방식을 사용하는 것이 좋습니다. 이 방식에서는 Cloud DNS가Google Cloud 환경에 대한 권한 있는 DNS 변환을 처리하고, 기존 온프레미스 DNS 서버는 온프레미스 리소스에 대한 권한 있는 DNS 변환을 처리합니다. 온프레미스 환경과 Google Cloud 환경은 전달 요청을 통해 환경 간에 DNS 조회를 수행합니다.

다음은 청사진에 사용된 여러 VPC 네트워크의 DNS 토폴로지를 보여주는 다이어그램입니다.

이 다이어그램에서는 청사진에서 배포하는 DNS 설계의 다음 구성요소를 설명합니다.

• DNS 허브는 온프레미스 환경과 Google Cloud환경 간의 DNS 교환 중앙 지점입니다. DNS 전달은 이미 네트워크 토폴로지에 구성된 것과 동일한 Dedicated Interconnect 인스턴스와 Cloud Router를 사용합니다.
  • 각 환경 토폴로지의 공유 VPC 네트워크에서 DNS 프로젝트는 프로덕션 공유 VPC 호스트 프로젝트와 동일합니다.
  • 허브 및 스포크 토폴로지에서 DNS 허브 프로젝트는 허브 공유 VPC 호스트 프로젝트와 동일합니다.
• 각 공유 VPC 네트워크의 서버는 각 공유 VPC 호스트 프로젝트의 Cloud DNS와 DNS 허브 간에 구성된 DNS 전달을 통해 다른 공유 VPC 네트워크의 DNS 레코드를 확인할 수 있습니다.
• 온프레미스 서버는 온프레미스 서버의 쿼리를 허용하는 DNS 서버 정책을 사용하여 Google Cloud 환경에서 DNS 레코드를 확인할 수 있습니다. 청사진은 DNS 허브에 인바운드 서버 정책을 구성하여 IP 주소를 할당하고 온프레미스 DNS 서버에서 요청을 이러한 주소로 전달합니다. Google Cloud 에 대한 모든 DNS 요청은 먼저 DNS 허브에 도달한 후 DNS 피어의 레코드를 확인합니다.
• Google Cloud 의 서버는 온프레미스 서버를 쿼리하는 전달 영역을 사용하여 온프레미스 환경에서 DNS 레코드를 확인할 수 있습니다. 온프레미스 환경에 대한 모든 DNS 요청은 DNS 허브에서 시작됩니다. DNS 요청 소스는 35.199.192.0/19입니다.

방화벽 정책

Google Cloud 에는 여러 방화벽 정책 유형이 있습니다. 계층식 방화벽 정책은 계층 구조의 모든 리소스에서 방화벽 정책 규칙이 일관되게 상속되도록 조직 또는 폴더 수준에서 적용됩니다. 또한 VPC 네트워크마다 네트워크 방화벽 정책을 구성할 수 있습니다. 청사진은 계층식 방화벽 정책을 사용하여 모든 환경에 공통 구성을 적용하고, 각 개별 VPC 네트워크에서 네트워크 방화벽 정책을 사용하여 보다 구체적인 구성을 적용하는 이러한 방화벽 정책들을 결합합니다.

청사진에서는 기존 VPC 방화벽 규칙을 사용하지 않습니다. 방화벽 정책만 사용하고 기존 VPC 방화벽 규칙과 혼합하여 사용하지 않는 것이 좋습니다.

계층식 방화벽 정책

청사진은 단일 계층식 방화벽 정책을 정의하고 프로덕션, 비프로덕션, 개발, 부트스트랩, 공통 폴더 각각에 정책을 연결합니다. 이 계층식 방화벽 정책은 모든 환경에 광범위하게 적용되어야 하는 규칙을 포함하고 있으며 각 개별 환경의 네트워크 방화벽 정책에 더 세분화된 규칙 평가를 위임합니다.

다음 표에서는 청사진에서 배포한 계층식 방화벽 정책 규칙을 설명합니다.

규칙 설명	트래픽 방향	필터(IPv4 범위)	프로토콜 및 포트	작업
RFC 1918에서의 인바운드 트래픽의 평가를 계층 구조의 하위 수준으로 위임합니다.	Ingress	192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12	all	Go to next
RFC 1918으로 향하는 아웃바운드 트래픽의 평가를 계층 구조의 하위 수준으로 위임합니다.	Egress	192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12	all	Go to next
TCP 전달을 위한 IAP	Ingress	35.235.240.0/20	tcp:22,3389	Allow
Windows 서버 활성화	Egress	35.190.247.13/32	tcp:1688	Allow
Cloud Load Balancing 상태 점검	Ingress	130.211.0.0/22, 35.191.0.0/16, 209.85.152.0/22, 209.85.204.0/22	tcp:80,443	Allow

네트워크 방화벽 정책

청사진은 네트워크마다 네트워크 방화벽 정책을 구성합니다. 각 네트워크 방화벽 정책은 Google Cloud 서비스에 대한 액세스를 허용하고 다른 모든 IP 주소로의 이그레스를 거부하는 최소 규칙 세트로 시작합니다.

허브 및 스포크 모델의 네트워크 방화벽 정책에는 스포크 간 통신을 허용하는 추가 규칙이 포함되어 있습니다. 네트워크 방화벽 정책은 한 스포크에서 허브 또는 다른 스포크로의 아웃바운드 트래픽을 허용하고 허브 네트워크의 NVA에서 인바운드 트래픽을 허용합니다.

다음 표에서는 청사진의 각 VPC 네트워크에 배포된 전역 네트워크 방화벽 정책의 규칙을 설명합니다.

규칙 설명	트래픽 방향	필터	프로토콜 및 포트
Google Cloud API에 대한 아웃바운드 트래픽을 허용합니다.	Egress	각 개별 네트워크에 구성된 Private Service Connect 엔드포인트입니다. Google API에 대한 비공개 액세스를 참조하세요.	tcp:443
다른 규칙과 일치하지 않는 아웃바운드 트래픽을 거부합니다.	Egress	모두	all
한 스포크에서 다른 스포크로의 아웃바운드 트래픽을 허용합니다 (허브 및 스포크 모델만 해당).	Egress	허브 및 스포크 토폴로지에 사용된 모든 IP 주소의 집계입니다. 스포크 VPC에서 나가는 트래픽은 먼저 허브 네트워크의 NVA로 라우팅됩니다.	all
허브 네트워크의 NVA에서 스포크로의 인바운드 트래픽을 허용합니다(허브 및 스포크 모델에만 해당).	Ingress	허브 네트워크의 NVA에서 시작되는 트래픽	all

청사진을 처음 배포할 때 VPC 네트워크의 VM 인스턴스는 Google Cloud 서비스와 통신할 수 있지만 같은 VPC 네트워크의 다른 인프라 리소스와는 통신할 수 없습니다. VM 인스턴스가 통신하도록 하려면 네트워크 방화벽 정책에 규칙을 추가하고 VM 인스턴스의 통신을 명시적으로 허용하는 태그를 추가해야 합니다. 태그가 VM 인스턴스에 추가되고 트래픽은 이러한 태그를 기준으로 평가됩니다. 또한 태그에는 IAM 제어 기능이 있으므로 중앙에서 정의하고 사용을 다른 팀에 위임할 수 있습니다.

다음 다이어그램에서는 워크로드가 VPC 네트워크 내에서 통신할 수 있도록 커스텀 태그와 네트워크 방화벽 정책 규칙을 추가하는 방법의 예시를 보여줍니다.

이 다이어그램에서는 이 예시의 다음 개념을 보여줍니다.

• 네트워크 방화벽 정책에는 우선순위 65530에서 모든 소스의 아웃바운드 트래픽을 거부하는 규칙 1이 포함됩니다.
• 네트워크 방화벽 정책에는 우선순위 999에서 service=frontend 태그가 있는 인스턴스로부터 service=backend 태그가 있는 인스턴스로의 인바운드 트래픽을 허용하는 규칙 2가 포함됩니다.
• 트래픽이 규칙 2에서 허용되는 태그와 일치하므로 instance-2 VM은 instance-1에서 트래픽을 수신할 수 있습니다. 우선순위 값에 따라 규칙 1이 평가되기 전에 규칙 2가 일치합니다.
• instance-3 VM은 트래픽을 수신하지 않습니다. 이 트래픽과 일치하는 유일한 방화벽 정책 규칙은 규칙 1이므로 instance-1의 아웃바운드 트래픽이 거부됩니다.

Google Cloud API에 대한 비공개 액세스

VPC 네트워크 또는 온프레미스 환경의 리소스가Google Cloud 서비스에 연결될 수 있게 하려면 공개 API 엔드포인트로의 아웃바운드 인터넷 트래픽 대신 비공개 연결을 사용하는 것이 좋습니다. 이 청사진은 모든 서브넷에서 비공개 Google 액세스를 구성하고 Private Service Connect로 내부 엔드포인트를 만들어 Google Cloud 서비스와 통신하며, 이러한 엔드포인트로의 트래픽을 허용하도록 방화벽 정책 및 DNS 레코드를 구성합니다. 이러한 제어를 함께 사용하면 인터넷 아웃바운드 트래픽 또는 공개적으로 공지된 인터넷 범위를 사용하지 않고도 Google Cloud 서비스에 대한 비공개 경로를 허용할 수 있습니다.

청사진은 vpc-sc라는 API 번들로 Private Service Connect 엔드포인트를 구성하여 Google Cloud 제한된 VIP에서 지원하는 서비스에 액세스할 수 있도록 합니다. 이 제어 기능은 Google Cloud와 관련 없는 다른 Google API에 대한 액세스를 차단하여 무단 반출 위험을 완화하는 데 도움이 됩니다. 이 제어는 VPC 서비스 제어를 사용 설정하기 위한 기본 단계이기도 합니다. VPC 서비스 제어를 사용 설정하는 선택적 단계에 관한 자세한 내용은 VPC 서비스 제어로 리소스 보호를 참고하세요.

다음 표에서는 각 네트워크에 생성된 Private Service Connect 엔드포인트를 설명합니다.

환경	API 번들	Private Service Connect 엔드포인트 IP 주소
일반	vpc-sc	10.17.0.5/32
개발	vpc-sc	10.17.0.6/32
비프로덕션	vpc-sc	10.17.0.7/32
프로덕션	vpc-sc	10.17.0.8/32

Google Cloud 서비스의 트래픽에 올바른 엔드포인트에 대한 DNS 조회가 포함되도록 청사진은 VPC 네트워크마다 비공개 DNS 영역을 구성합니다. 다음 표에서는 이러한 비공개 DNS 영역을 설명합니다.

비공개 영역 이름	DNS 이름	레코드 유형	데이터
googleapis.com.	*.googleapis.com.	CNAME	restricted.googleapis.com.
	restricted.googleapis.com	A	해당 VPC 네트워크의 Private Service Connect 엔드포인트 IP 주소입니다.
gcr.io.	*.gcr.io	CNAME	gcr.io.
	gcr.io	A	해당 VPC 네트워크의 Private Service Connect 엔드포인트 IP 주소입니다.
pkg.dev.	*.pkg.dev.	CNAME	pkg.dev.
	pkg.dev.	A	해당 VPC 네트워크의 Private Service Connect 엔드포인트 IP 주소입니다.

청사진에는 이러한 Private Service Connect 엔드포인트가 일관되게 사용되도록 강제하는 추가 구성이 있습니다. 각 공유 VPC 네트워크도 다음을 구성을 적용합니다.

• 모든 소스에서 TCP:443으로 Private Service Connect 엔드포인트의 IP 주소로 아웃바운드 트래픽을 허용하는 네트워크 방화벽 정책 규칙
• Google Cloud 서비스에 액세스하는 데 사용되는 기본 도메인이 포함된 0.0.0.0/0에 대한 아웃바운드 트래픽을 거부하는 네트워크 방화벽 정책 규칙

인터넷 연결

청사진은 VPC 네트워크와 인터넷 간의 인바운드 또는 아웃바운드 트래픽을 허용하지 않습니다. 인터넷 연결이 필요한 워크로드의 경우 필요한 액세스 경로를 설계하려면 추가 단계를 수행해야 합니다.

인터넷으로 전송되는 아웃바운드 트래픽이 필요한 워크로드의 경우에는 원치 않는 인바운드 연결 없이 아웃바운드 트래픽을 허용하도록 Cloud NAT를 통해 아웃바운드 트래픽을 관리하거나, 더욱 안전한 제어가 가능한 보안 웹 프록시를 사용하여 신뢰할 수 있는 웹 서비스로 나가는 아웃바운드 트래픽만 허용하도록 관리하는 것이 좋습니다.

인터넷으로부터의 인바운드 트래픽이 필요한 워크로드의 경우에는 Cloud Load Balancing 및 Google Cloud Armor를 사용하여 DDoS 및 WAF 보호의 이점을 누리도록 워크로드를 설계하는 것이 좋습니다.

VM에서 외부 IP 주소를 사용하여 인터넷과 VM 간의 직접 연결을 허용하는 워크로드는 설계하지 않는 것을 권장합니다.

온프레미스 환경과 Google Cloud간의 하이브리드 연결

온프레미스 환경과Google Cloud간의 연결을 설정하려면 보안 및 안정성을 극대화하기 위해 Dedicated Interconnect를 사용하는 것이 좋습니다. Dedicated Interconnect 연결은 온프레미스 네트워크와Google Cloud간의 직접 링크입니다.

다음 다이어그램은 온프레미스 환경과 Google 가상 프라이빗 클라우드 네트워크 간의 하이브리드 연결을 보여줍니다.

이 다이어그램은 Dedicated Interconnect의 99.99% 가용성을 위한 패턴의 다음 구성요소를 설명합니다.

• Dedicated Interconnect 연결 4개(권역 하나에 연결 2개 및 다른 권역에 연결 2개) 권역마다 콜로케이션 시설 내에 고유한 영역 2개가 있습니다.
• 이러한 연결은 두 쌍으로 나뉘며, 각 쌍은 별도의 온프레미스 데이터 센터에 연결됩니다.
• VLAN 연결은 각 Dedicated Interconnect 인스턴스를 공유 VPC 토폴로지에 연결된 Cloud Router에 연결하는 데 사용됩니다.
• 각 공유 VPC 네트워크에는 리전당 2개씩, 총 4개의 Cloud Router가 있으며, 동적 라우팅 모드가 global로 설정되어 모든 Cloud Router가 리전에 관계없이 모든 서브넷을 공지할 수 있습니다.

전역 동적 라우팅을 사용하면 Cloud Router가 VPC 네트워크의 모든 서브넷으로 연결되는 경로를 공지합니다. Cloud Router는 로컬 서브넷(Cloud Router가 있는 리전 내의 서브넷)에 비해 원격 서브넷(Cloud Router가 있는 리전의 외부 서브넷)으로 연결되는 경로를 보다 낮은 우선순위로 공지합니다. 원하는 경우 Cloud Router의 BGP 세션을 구성할 때 공지된 프리픽스와 우선순위를 변경할 수 있습니다.

Google Cloud에서 온프레미스 환경으로의 트래픽은 클라우드 리소스와 가장 가까운 Cloud Router를 사용합니다. Google Cloud 단일 리전 내에서 온프레미스 네트워크로의 여러 경로는 동일한 멀티 종료 구분자(MED) 값을 가지며, Google Cloud 등가 멀티 경로 (ECMP) 라우팅을 사용하여 모든 가능한 경로 간에 아웃바운드 트래픽을 분산합니다.

온프레미스 구성 변경사항

온프레미스 환경과Google Cloud간의 연결을 구성하려면 온프레미스 환경에서 추가 변경사항을 구성해야 합니다. 청사진의 Terraform 코드는 자동으로Google Cloud 리소스를 구성하지만 온프레미스 네트워크 리소스를 수정하지 않습니다.

청사진에서는 다음을 포함하여 온프레미스 환경에서Google Cloud 로의 하이브리드 연결에 사용되는 일부 구성요소를 자동으로 사용 설정합니다.

• Cloud DNS는 DNS 설정의 설명대로 모든 공유 VPC 네트워크 간의 DNS 전달을 단일 허브로 구성합니다. Cloud DNS 서버 정책은 인바운드 전달자 IP 주소로 구성됩니다.
• Cloud Router는 Private Service Connect 엔드포인트에서 사용하는 IP 주소의 모든 서브넷 경로와 커스텀 경로를 내보내도록 구성됩니다.

하이브리드 연결을 사용 설정하려면 다음 추가 단계를 수행해야 합니다.

1. Dedicated Interconnect 연결을 주문합니다.
2. 온프레미스 라우터와 방화벽에서 IP 주소 공간 할당에 정의된 내부 IP 주소 공간에 대한 아웃바운드 트래픽을 허용하도록 구성합니다.
3. 온프레미스 DNS 서버에서Google Cloud 에 바인딩된 DNS 조회를 청사진에서 이미 구성한 인바운드 전달자 IP 주소로 전달하도록 구성합니다.
4. Cloud DNS 전달 영역(35.199.192.0/19)의 DNS 쿼리를 수락하도록 온프레미스 DNS 서버, 방화벽, 라우터를 구성합니다.
5. Cloud API에 대한 비공개 액세스에 정의된 IP 주소로 온프레미스 호스트에서 Google Cloud 서비스로의 쿼리에 응답하도록 온프레미스 DNS 서버를 구성합니다.
6. Dedicated Interconnect 연결을 통한 전송 중인 데이터 암호화의 경우 Cloud Interconnect용 MACsec를 구성하거나 IPsec 암호화를 위해 Cloud Interconnect를 통한 HA VPN을 구성합니다.

자세한 내용은 온프레미스 호스트용 비공개 Google 액세스를 참고하세요.

다음 단계

• 감지 제어(이 시리즈의 다음 문서) 읽어보기