이 튜토리얼에서는 VPC 네트워크 피어링을 사용하여 허브 및 스포크 아키텍처를 배포하는 방법을 설명합니다.
이 튜토리얼은 Compute Engine 가상 머신으로 구성되는 중앙화된 어플라이언스를 사용하여 Google Cloud 환경에 허브 및 스포크 아키텍처를 구현하려는 클라우드 네트워크 엔지니어 및 운영 전문가를 대상으로 합니다. 이 가이드에서는 이러한 가상 머신을 NAT 게이트웨이로 배포하지만 차세대 방화벽과 같은 다른 기능과 동일한 접근 방법을 사용할 수 있습니다. 이 튜토리얼에서는 사용자가 VPC 네트워크 및 Compute Engine에 익숙하다고 가정합니다.
아키텍처
이 아키텍처에서 스포크 VPC 네트워크 집합은 중앙화된 어플라이언스 풀(여기에서는 네트워크 주소 변환(NAT) 게이트웨이)을 통해 트래픽이 라우팅되는 허브 VPC 네트워크를 통해 외부와 통신합니다. 관련 경로는 허브 VPC 네트워크에서 스포크 VPC 네트워크로 내보내집니다. NAT 게이트웨이는 새로운 기본 경로를 포함하고 Cloud Load Balancing의 내부 패스 스루 네트워크 부하 분산기를 다음 홉으로 포함하는 내부 부하 분산기의 백엔드로 구성됩니다.
등가 다중 경로(ECMP) 라우팅을 포함하는 여러 경로를 사용하여 동일한 유형의 부하 분산 및 고가용성을 얻을 수 있습니다. 하지만 내부 패스 스루 네트워크 부하 분산기를 사용하면 다음과 같은 이점이 있습니다.
- 상태 점검을 사용할 때 트래픽은 정상 상태의 인스턴스에게만 전달됩니다. ECMP를 사용하면 경로가 지정된 모든 활성 상태의 인스턴스로 트래픽이 전달됩니다. 내부 패스 스루 네트워크 부하 분산기를 사용하면 경로가 사용되지 않을 가능성이 없어집니다. 또한 인스턴스가 종료되거나 재시작될 때 경로를 삭제할 필요가 없습니다.
- 상태 확인 타이머를 미세 조정할 수 있기 때문에 더 빠른 장애 조치가 가능할 수 있습니다. 관리형 인스턴스 그룹 및 자동 복구를 사용하는 경우에도 상태 확인 타이머를 맞춤설정할 수 있지만 트래픽을 라우팅하는 대신 인스턴스를 다시 만들기 위해 사용됩니다.
Google은 또한 Cloud NAT를 관리형 서비스로 제공하여, 사용자 관리 및 개입 없이 고가용성을 지원합니다. 하지만 이 사용 사례에서는 NAT 구성을 피어링된 네트워크로 가져오지 않기 때문에 Cloud NAT가 지원되지 않습니다.
다음 다이어그램은 이 가이드에서 빌드하는 토폴로지를 보여줍니다.
이 토폴로지는 허브 VPC 네트워크 하나와 VPC 네트워크 피어링을 사용해서 이 허브 VPC 네트워크와 피어링된 스포크 VPC 네트워크 2개로 구성됩니다. 허브 VPC 네트워크에는 내부 패스 스루 네트워크 부하 분산기 뒤에 있는 NAT 게이트웨이 인스턴스 2개가 포함됩니다.
정적 기본 경로(0/0 NAT-GW-ILB)는 내부 패스 스루 네트워크 부하 분산기에 다음 홉으로 연결됩니다. 이 정적 기본 경로는 커스텀 경로를 사용하여 VPC 네트워크 피어링을 통해 내보내집니다.
목표
- 여러 VPC 네트워크를 만들고 허브 및 스포크 아키텍처를 사용해서 이를 피어링합니다.
- 허브 VPC 네트워크에서 NAT 게이트웨이를 만들고 구성합니다.
- 내부 패스 스루 네트워크 부하 분산기를 설정하고 다음 홉으로 구성합니다.
- 스포크 VPC 네트워크에서 공개 인터넷으로 연결을 확인합니다.
비용
이 문서에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.
프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요.
이 문서에 설명된 태스크를 완료했으면 만든 리소스를 삭제하여 청구가 계속되는 것을 방지할 수 있습니다. 자세한 내용은 삭제를 참조하세요.
시작하기 전에
- Google Cloud 계정에 로그인합니다. Google Cloud를 처음 사용하는 경우 계정을 만들고 Google 제품의 실제 성능을 평가해 보세요. 신규 고객에게는 워크로드를 실행, 테스트, 배포하는 데 사용할 수 있는 $300의 무료 크레딧이 제공됩니다.
-
Google Cloud Console의 프로젝트 선택기 페이지에서 Google Cloud 프로젝트를 선택하거나 만듭니다.
-
Compute Engine API 사용 설정
-
Google Cloud Console의 프로젝트 선택기 페이지에서 Google Cloud 프로젝트를 선택하거나 만듭니다.
-
Compute Engine API 사용 설정
-
Google Cloud 콘솔에서 Cloud Shell을 활성화합니다.
Google Cloud 콘솔 하단에서 Cloud Shell 세션이 시작되고 명령줄 프롬프트가 표시됩니다. Cloud Shell은 Google Cloud CLI가 사전 설치된 셸 환경으로, 현재 프로젝트의 값이 이미 설정되어 있습니다. 세션이 초기화되는 데 몇 초 정도 걸릴 수 있습니다.
이 튜토리얼에서는 Cloud Shell에서 모든 명령어를 실행합니다.
환경 설정
Cloud Shell에서 작업하려는 Google 클라우드 프로젝트가 자신이 만들거나 선택한 것인지 확인합니다.
project-id를 Google Cloud 프로젝트로 바꿉니다.gcloud config set project project-id export PROJECT_ID=`gcloud config list --format="value(core.project)"`
기본 컴퓨팅 리전 및 영역을 설정합니다.
gcloud config set compute/region us-central1 gcloud config set compute/zone us-central1-c export REGION=us-central1 export ZONE=us-central1-c이 가이드에서 리전은
us-central1이고 영역은us-central1-c입니다.
VPC 네트워크 및 서브넷 만들기
Cloud Shell에서 허브 VPC 네트워크 및 서브넷을 만듭니다.
gcloud compute networks create hub-vpc --subnet-mode custom gcloud compute networks subnets create hub-subnet1 \ --network hub-vpc --range 10.0.0.0/24서브넷이 각 하나씩 포함된
spoke1-vpc및spoke2-vpc라는 스포크 VPC 네트워크를 만듭니다.gcloud compute networks create spoke1-vpc --subnet-mode custom gcloud compute networks create spoke2-vpc --subnet-mode custom gcloud compute networks subnets create spoke1-subnet1 \ --network spoke1-vpc --range 192.168.1.0/24 gcloud compute networks subnets create spoke2-subnet1 \ --network spoke2-vpc --range 192.168.2.0/24허브 VPC 네트워크 및 스포크 VPC 네트워크에서 방화벽 규칙을 만듭니다. 이 규칙은 지정된 RFC 1918 범위의 내부 트래픽(TCP/80 및 443, UDP/53 및 ICMP)을 허용합니다.
gcloud compute firewall-rules create hub-vpc-web-ping-dns \ --network hub-vpc --allow tcp:80,tcp:443,icmp,udp:53 \ --source-ranges 10.0.0.0/24,192.168.1.0/24,192.168.2.0/24 gcloud compute firewall-rules create spoke1-vpc-web-ping-dns \ --network spoke1-vpc --allow tcp:80,tcp:443,icmp,udp:53 \ --source-ranges 10.0.0.0/24,192.168.1.0/24 gcloud compute firewall-rules create spoke2-vpc-web-ping-dns \ --network spoke2-vpc --allow tcp:80,tcp:443,icmp,udp:53 \ --source-ranges 10.0.0.0/24,192.168.2.0/24모든 가상 머신에 액세스할 수 있도록 허브 VPC 네트워크 및 스포크 VPC 네트워크에서 SSH용 IAP를 허용하는 방화벽 규칙을 만듭니다.
gcloud compute firewall-rules create hub-vpc-iap \ --network hub-vpc --allow tcp:22 \ --source-ranges 35.235.240.0/20 gcloud compute firewall-rules create spoke1-vpc-iap \ --network spoke1-vpc --allow tcp:22 \ --source-ranges 35.235.240.0/20 gcloud compute firewall-rules create spoke2-vpc-iap \ --network spoke2-vpc --allow tcp:22 \ --source-ranges 35.235.240.0/20이 가이드에서는 SSH용 IAP(Identity-Aware Proxy)가 사용됩니다. 자세한 내용은 외부 IP 주소가 없는 인스턴스에 연결을 참조하세요.
허브 VPC 네트워크에서 인스턴스 그룹 자동 복구를 위한 상태 확인을 허용하는 방화벽 규칙을 만듭니다.
gcloud compute firewall-rules create hub-vpc-health-checks \ --network hub-vpc --allow tcp:443 --target-tags nat-gw \ --source-ranges 130.211.0.0/22,35.191.0.0/16
인스턴스 및 필요한 경로 만들기
Cloud Shell에서 NAT 게이트웨이를 설정하는 시작 스크립트가 포함된 NAT 게이트웨이에 대한 인스턴스 템플릿을 만듭니다.
gcloud compute instance-templates create \ hub-nat-gw-ilbnhop-template \ --network hub-vpc \ --subnet hub-subnet1 \ --machine-type n1-standard-2 --can-ip-forward \ --tags nat-gw --scopes default,compute-rw \ --metadata startup-script='#! /bin/bash apt-get update # Enable IP forwarding: echo 1 > /proc/sys/net/ipv4/ip_forward echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/20-example.conf # Read VM network configuration: md_vm="http://metadata.google.internal/computeMetadata/v1/instance/" md_net="$md_vm/network-interfaces" nic0_gw="$(curl $md_net/0/gateway -H "Metadata-Flavor:Google")" nic0_mask="$(curl $md_net/0/subnetmask -H "Metadata-Flavor:Google")" nic0_addr="$(curl $md_net/0/ip -H "Metadata-Flavor:Google")" nic0_id="$(ip addr show | grep $nic0_addr | tail -c 5)" # Use a web server to pass the health check for this example. # In production, use a more complete test. sudo apt-get update sudo apt-get install apache2 -y sudo a2ensite default-ssl sudo a2enmod ssl echo "Example web page to pass health check" | \ tee /var/www/html/index.html sudo systemctl restart apache2 # Enable IP masquerading iptables -t nat -A POSTROUTING -o $nic0_id -j MASQUERADE'이 가이드에서는
n1-standard-2가 인스턴스 유형으로 사용되지만 원하는 다른 번호 또는 게이트웨이 크기를 사용할 수 있습니다. VM당 최대 이그레스 대역폭과 같은 요소를 고려해야 합니다.HTTP 상태 점검을 만듭니다.
gcloud compute health-checks create http nat-gw-ilbnhop-health-check \ --region us-central1 \ --port 80단일 리전에 분산되는 두 인스턴스가 포함된 리전별 인스턴스 그룹을 만듭니다.
gcloud compute instance-groups managed create \ hub-nat-gw-ilbnhop-mig \ --region us-central1 --size=2 \ --template=hub-nat-gw-ilbnhop-template \ --health-check nat-gw-ilbnhop-health-check \ --initial-delay 15이 가이드에서는 최초 지연이 15초로 설정됩니다. 프로덕션 배포에서 요구사항에 따라 이 설정을 맞춤설정합니다. 이 가이드에서는 자동 복구 정책을 사용하지 않습니다.
백엔드 서비스를 만들고 인스턴스 그룹을 추가합니다.
gcloud compute backend-services create hub-nat-gw-ilbnhop-backend \ --load-balancing-scheme=internal \ --protocol=tcp \ --health-checks=nat-gw-ilbnhop-health-check gcloud compute backend-services add-backend \ hub-nat-gw-ilbnhop-backend \ --instance-group=hub-nat-gw-ilbnhop-mig \ --instance-group-region=us-central1전달 규칙을 만듭니다.
gcloud compute forwarding-rules create \ hub-nat-gw-ilbnhop \ --load-balancing-scheme=internal \ --network=hub-vpc \ --subnet=hub-subnet1 \ --address=10.0.0.10 \ --ip-protocol=TCP \ --ports=all \ --backend-service=hub-nat-gw-ilbnhop-backend \ --backend-service-region=us-central1 \ --service-label=hub-nat-gw-ilbnhopTCP로만 전달 규칙을 정의하더라도 내부 패스 스루 네트워크 부하 분산기를 다음 홉으로 사용하면 전달 규칙이 백엔드 VM의 모든 포트로 모든 트래픽을 전달합니다. 내부 패스 스루 네트워크 부하 분산기는 리전별 부하 분산기입니다.
전달 규칙이 다음 홉으로 포함된 새 경로를 만듭니다.
gcloud compute routes create hub-nat-gw-ilbnhop \ --network=hub-vpc \ --destination-range=0.0.0.0/0 \ --next-hop-ilb=hub-nat-gw-ilbnhop \ --next-hop-ilb-region=us-central1 \ --priority=800네트워크 태그를 지정하여 다음 홉 경로가 태그로 구성된 클라이언트 인스턴스에만 적용되고 VPC 네트워크 피어링을 통해 태그를 내보내거나 가져오지 않도록 할 수 있습니다.
허브 VPC에서 기본 경로를 삭제합니다.
export hub_default_route=$(gcloud compute routes list \ --format="value(name)" --filter="network:hub-vpc AND \ nextHopGateway:default-internet-gateway" | head -n 1) gcloud compute routes delete $hub_default_route -qNAT 게이트웨이에서만 트래픽을 허용하도록 태그 지정된 새 경로를 만듭니다.
gcloud compute routes create hub-default-tagged \ --network hub-vpc --destination-range 0.0.0.0/0 \ --next-hop-gateway default-internet-gateway \ --priority 700 --tags nat-gw각 스포크의 VPC에서 인터넷으로의 기본 경로를 삭제합니다.
export spoke1_default_route=$(gcloud compute routes list \ --format="value(name)" --filter="network:spoke1-vpc AND \ nextHopGateway:default-internet-gateway") gcloud compute routes delete $spoke1_default_route -q export spoke2_default_route=$(gcloud compute routes list \ --format="value(name)" \ --filter="network:spoke2-vpc AND nextHopGateway:default-internet-gateway") gcloud compute routes delete $spoke2_default_route -q로컬 경로와 가져온 경로 사이에 충돌이 있으면 로컬 경로가 항상 우선 적용됩니다. 자세한 내용은 라우팅 순서를 참조하세요.
클라이언트 VM을 만듭니다.
gcloud compute instances create spoke1-client \ --subnet=spoke1-subnet1 --no-address \ --metadata startup-script='#! /bin/bash apt-get update apt-get install dnsutils -y' gcloud compute instances create spoke2-client \ --subnet=spoke2-subnet1 --no-address \ --metadata startup-script='#! /bin/bash apt-get update apt-get install dnsutils -y'
VPC 네트워크 피어링 연결 만들기
VPC 네트워크 피어링은 양방향이므로, 양쪽 끝에 정의되어야 합니다. VPC 네트워크는 여러 VPC 네트워크와 피어링될 수 있지만 제한이 있습니다. VPC 네트워크 피어링으로 기본 경로에 연결하려면 VPC 네트워크 피어링으로 커스텀 경로 가져오기 및 내보내기 기능을 사용합니다.
이 튜토리얼에서는 동일한 Google 클라우드 프로젝트에 모든 VPC 네트워크를 만듭니다.
Cloud Shell에서 경로 내보내기 플래그를 사용 설정하여 허브 VPC 네트워크에서 스포크 VPC 네트워크로의 VPC 연결을 만듭니다.
gcloud compute networks peerings create hub-to-spoke1 \ --network hub-vpc --peer-network spoke1-vpc \ --peer-project $PROJECT_ID \ --export-custom-routes gcloud compute networks peerings create hub-to-spoke2 \ --network hub-vpc --peer-network spoke2-vpc \ --peer-project $PROJECT_ID \ --export-custom-routes경로 가져오기 플래그를 사용 설정하여
spoke1VPC 네트워크에서 허브 VPC 네트워크로의 VPC 연결을 만듭니다.gcloud compute networks peerings create spoke1-to-hub \ --network spoke1-vpc --peer-network hub-vpc \ --peer-project $PROJECT_ID \ --import-custom-routes경로 가져오기 플래그를 사용 설정하여
spoke2VPC 네트워크에서 허브 VPC 네트워크로의 VPC 연결을 만듭니다.gcloud compute networks peerings create spoke2-to-hub \ --network spoke2-vpc --peer-network hub-vpc \ --peer-project $PROJECT_ID \ --import-custom-routes
경로 전파 및 연결 확인
Cloud Shell에서 시작 스크립트 중에 정적 경로가 올바르게 생성되었는지 확인합니다.
gcloud compute routes list --filter="network:hub-vpc"hub-default-tagged및hub-nat-gw-ilbanhop경로가 출력에 있는지 확인합니다.NAME NETWORK DEST_RANGE NEXT_HOP PRIORITY default-route-13a4b635b5eab48c hub-vpc 10.0.0.0/24 hub-vpc 1000 hub-default-tagged hub-vpc 0.0.0.0/0 default-internet-gateway 700 hub-nat-gw-ilbanhop hub-vpc 0.0.0.0/0 10.0.0.10 800 peering-route-3274f1257a9842a0 hub-vpc 192.168.2.0/24 hub-to-spoke2 1000 peering-route-798c5777f13094bc hub-vpc 192.168.1.0/24 hub-to-spoke1 1000
spoke1-vpc라우팅 테이블에서 기본 경로를 올바르게 가져왔는지 확인합니다.gcloud compute routes list --filter="network:spoke1-vpc"출력에서
DEST_RANGE값이0.0.0.0/0인peering-route로 시작하는 경로가 있는지 확인합니다.NAME NETWORK DEST_RANGE NEXT_HOP PRIORITY default-route-75f6ea8f5fc54813 spoke1-vpc 192.168.1.0/24 spoke1-vpc 1000 peering-route-6c7f130b860bfd39 spoke1-vpc 10.0.0.0/24 spoke1-to-hub 1000 peering-route-9d44d362f98afbd8 spoke1-vpc 0.0.0.0/0 spoke1-to-hub 800
IAP를 통한 SSH를 사용하여 클라이언트 중 하나에 연결합니다.
gcloud compute ssh spoke1-client --tunnel-through-iapNAT 게이트웨이를 통해 Google 공개 DNS를 테스트하여 연결을 확인합니다.
sudo hping3 -S -p 80 -c 3 dns.google내부 패스 스루 네트워크 부하 분산기가 TCP 및 UDP를 지원하기 때문에, ICMP 기반 ping을 사용해서 인터넷 연결을 확인할 수 없으므로, hping3와 같은 도구를 사용해야 합니다.
출력은 다음과 비슷합니다.
HPING dns.google (eth0 8.8.4.4): S set, 40 headers + 0 data bytes len=44 ip=8.8.4.4 ttl=126 DF id=0 sport=80 flags=SA seq=0 win=65535 rtt=4.6 ms len=44 ip=8.8.4.4 ttl=126 DF id=0 sport=80 flags=SA seq=1 win=65535 rtt=4.4 ms len=44 ip=8.8.4.4 ttl=126 DF id=0 sport=80 flags=SA seq=2 win=65535 rtt=4.3 ms --- dns.google hping statistic --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 4.3/4.4/4.6 ms
인터넷과 통신하기 위해 사용하는 공개 IP 주소를 확인합니다.
curl ifconfig.co출력에 NAT 게이트웨이 인스턴스 중 하나의 공개 IP 주소가 표시됩니다. 명령어를 다시 실행하면 구성된 내부 부하 분산 세션 어피니티(기본적으로 클라이언트 IP, 프로토콜, 포트)를 사용하여 연결이 분산되어 있기 때문에 출력에 다른 공개 IP 주소가 표시될 수 있습니다.
VPC 네트워크 피어링은 비전이적이므로, VPC 네트워크 피어링을 통한 스포크 VPC 네트워크 간 연결이 없습니다.
프로덕션 환경 고려사항
이 튜토리얼에서 만드는 구성은 단일 리전의 NAT 게이트웨이 2개를 제공합니다. 하지만 ECMP 부하 분산은 완벽하지 않으며, 차세대 방화벽과 같은 스테이트풀(Stateful) 기기를 사용할 때 요구되는 것처럼 개별 흐름이 여러 링크 간에 분산되지도 않습니다.
프로덕션 환경에서 이 구성을 배포하려면 다음을 고려해야 합니다.
- 이 구성은 임시 또는 비스테이트풀(Stateful) 발신 링크에 가장 적합합니다. NAT 게이트웨이 풀의 크기가 변경되는 경우 TCP 연결의 부하가 다시 분산되고, 이로 인해 기존 연결이 재설정될 수 있습니다.
- 노드가 자동으로 업데이트되지 않으므로, 기본 Debian 설치에 보안 취약점이 있는 경우 이미지를 수동으로 업데이트해야 합니다.
- 여러 리전에 VM에 있으면 각 리전에서 NAT 게이트웨이를 설정해야 합니다.
- 게이트웨이별 대역폭은 하드웨어 유형에 따라 다를 수 있습니다. VM당 최대 이그레스 대역폭과 같은 요소를 고려해야 합니다. 게이트웨이 오류가 발생한 동안 트래픽은 나머지 게이트웨이로 분산됩니다. 실행 중인 흐름이 다시 프로그래밍되지 않으므로, 게이트웨이가 다시 온라인으로 복구되었을 때 트래픽이 즉시 다시 돌아오지 않습니다. 따라서 규모를 설정할 때 충분한 오버헤드를 허용해야 합니다.
- 예상치 못한 결과에 대한 알림을 받으려면 Cloud Monitoring을 사용하여 관리형 인스턴스 그룹과 네트워크 트래픽을 모니터링합니다.
삭제
비용이 청구되지 않도록 하는 가장 쉬운 방법은 가이드에서 만든 Google Cloud 프로젝트를 삭제하는 것입니다. 또는 개별 리소스를 삭제할 수 있습니다.
프로젝트 삭제
- Google Cloud 콘솔에서 리소스 관리 페이지로 이동합니다.
- 프로젝트 목록에서 삭제할 프로젝트를 선택하고 삭제를 클릭합니다.
- 대화상자에서 프로젝트 ID를 입력한 후 종료를 클릭하여 프로젝트를 삭제합니다.
개별 리소스 삭제
Google 클라우드 프로젝트를 보존하려면 이 가이드에서 만든 리소스를 삭제할 수 있습니다.
VPC 네트워크 피어링 연결을 삭제합니다.
gcloud compute networks peerings delete spoke2-to-hub \ --network spoke2-vpc -q gcloud compute networks peerings delete spoke1-to-hub \ --network spoke1-vpc -q gcloud compute networks peerings delete hub-to-spoke1 \ --network hub-vpc -q gcloud compute networks peerings delete hub-to-spoke2 \ --network hub-vpc -q인스턴스, 부하 분산기 리소스, 템플릿, 경로를 삭제합니다.
gcloud compute instances delete spoke1-client \ --zone=us-central1-c -q gcloud compute instances delete spoke2-client \ --zone=us-central1-c -q gcloud compute routes delete hub-nat-gw-ilbnhop -q gcloud compute forwarding-rules delete hub-nat-gw-ilbnhop -q gcloud compute backend-services delete -q hub-nat-gw-ilbnhop-backend -q gcloud compute instance-groups managed delete hub-nat-gw-ilbnhop-mig \ --region us-central1 -q gcloud compute health-checks delete nat-gw-ilbnhop-health-check -q gcloud compute instance-templates delete hub-nat-gw-ilbnhop-template -q gcloud compute routes delete hub-default-tagged -q방화벽 규칙, 서브넷, VPC 네트워크를 삭제합니다.
gcloud compute firewall-rules delete spoke2-vpc-iap -q gcloud compute firewall-rules delete spoke2-vpc-web-ping-dns -q gcloud compute firewall-rules delete spoke1-vpc-iap -q gcloud compute firewall-rules delete spoke1-vpc-web-ping-dns -q gcloud compute firewall-rules delete hub-vpc-iap -q gcloud compute firewall-rules delete hub-vpc-web-ping-dns -q gcloud compute firewall-rules delete hub-vpc-health-checks -q gcloud compute networks subnets delete spoke1-subnet1 \ --region us-central1 -q gcloud compute networks subnets delete spoke2-subnet1 \ --region us-central1 -q gcloud compute networks subnets delete hub-subnet1 \ --region us-central1 -q gcloud compute networks delete spoke1-vpc -q gcloud compute networks delete spoke2-vpc -q gcloud compute networks delete hub-vpc -q
다음 단계
- VPC 디자인을 위한 권장사항 및 참조 아키텍처 읽어보기
- VPC 네트워크 피어링 및 다음 홉으로 사용하는 내부 패스 스루 네트워크 부하 분산기 문서 검토하기
- VM 인스턴스의 특수 구성 읽어보기