Implemente uma rede hub-and-spoke usando um balanceador de carga como o próximo salto

Este tutorial descreve como usar o VPC Network Peering para implementar uma arquitetura de hub e raios.

Este tutorial destina-se a engenheiros de rede na nuvem e profissionais de operações que querem implementar uma arquitetura de hub e raios no respetivo Google Cloud ambiente através de dispositivos centralizados que consistem em máquinas virtuais do Compute Engine. Neste tutorial, implementa estas máquinas virtuais como gateways NAT, mas pode usar a mesma abordagem para outras funções, como firewalls de nova geração. Este tutorial pressupõe que tem conhecimentos sobre as redes VPC e o Compute Engine.

Arquitetura

Nesta arquitetura, um conjunto de redes VPC spoke comunica com o exterior através de uma rede VPC hub na qual o tráfego é encaminhado através de um conjunto centralizado de dispositivos, neste caso, gateways de tradução de endereços de rede (NAT). Os encaminhamentos relevantes são exportados da rede VPC do hub para as redes VPC spoke. Os gateways NAT estão configurados como back-ends de um balanceador de carga interno com uma nova rota predefinida, que tem um balanceador de carga de rede de encaminhamento interno do Cloud Load Balancing como o próximo salto.

Pode alcançar o mesmo tipo de distribuição de carga e alta disponibilidade usando várias rotas com o encaminhamento de vários caminhos de custo igual (ECMP). No entanto, a utilização do balanceador de carga de passagem interno tem as seguintes vantagens:

• O tráfego só é encaminhado para instâncias em bom estado quando usa verificações de estado. Com o ECMP, o tráfego é encaminhado para todas as instâncias ativas para as quais a rota aponta. A utilização de um balanceador de carga de rede de encaminhamento interno elimina a possibilidade de rotas não utilizadas. Além disso, não é necessário limpar as rotas quando as instâncias são terminadas ou reiniciadas.
• Existe uma comutação por falha potencialmente mais rápida porque pode ajustar os temporizadores de verificação do estado. Se usar grupos de instâncias geridos e a autorrecuperação, ainda pode personalizar os temporizadores de verificação de estado, mas estes são usados para recriar a instância, não para encaminhar tráfego.

A Google também oferece o Cloud NAT como um serviço gerido, que oferece alta disponibilidade sem gestão nem intervenção do utilizador. No entanto, o Cloud NAT não é suportado neste exemplo de utilização porque a configuração de NAT não é importada para uma rede com peering.

O diagrama seguinte mostra a topologia que cria neste tutorial.

A topologia consiste numa rede VPC central e duas redes VPC periféricas que estão interligadas com a rede VPC central através do intercâmbio da rede da VPC. A rede VPC do hub tem duas instâncias do gateway NAT atrás de um balanceador de carga de rede de encaminhamento interno. Uma rota predefinida estática (0/0 NAT-GW-ILB) aponta para o balanceador de carga de passagem interno como o salto seguinte. Este encaminhamento predefinido estático é exportado através da interligação de redes VPC com encaminhamentos personalizados.

Objetivos

• Crie várias redes VPC e estabeleça peering entre elas através de uma arquitetura de hub e raio.
• Crie e configure gateways de NAT na rede VPC do hub.
• Configure o Network Load Balancer de encaminhamento interno como o próximo salto.
• Verifique a conetividade das redes VPC spoke à Internet pública.

Custos

Neste documento, usa os seguintes componentes faturáveis do Google Cloud:

• Compute Engine

Para gerar uma estimativa de custos com base na sua utilização projetada, use a calculadora de preços.

Os novos Google Cloud utilizadores podem ser elegíveis para uma avaliação gratuita.

Quando terminar as tarefas descritas neste documento, pode evitar a faturação contínua eliminando os recursos que criou. Para mais informações, consulte o artigo Limpe.

Antes de começar

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Compute Engine API.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the API

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Enable the Compute Engine API.

Roles required to enable APIs

To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

Enable the API

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

Neste tutorial, executa todos os comandos a partir do Cloud Shell.

Configurar o seu ambiente

1. No Cloud Shell, certifique-se de que está a trabalhar no Google Cloud projeto que criou ou selecionou. Substitua project-id pelo seu Google Cloud projeto.

   gcloud config set project project-id
   
   export PROJECT_ID=`gcloud config list --format="value(core.project)"`
   

2. Defina a região e a zona de computação predefinidas.

   gcloud config set compute/region us-central1
   gcloud config set compute/zone us-central1-c
   export REGION=us-central1
   export ZONE=us-central1-c
   

   Neste tutorial, a região é us-central1 e a zona é us-central1-c.

Criar as redes VPC e as sub-redes

1. No Cloud Shell, crie a rede VPC e a sub-rede do hub:

   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
   

2. Crie as redes VPC spoke, denominadas spoke1-vpc e spoke2-vpc, com uma sub-rede cada:

   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
   

3. Crie regras de firewall na rede VPC do hub e nas redes VPC spoke. Estas regras permitem o tráfego interno (TCP/80 e 443, UDP/53 e ICMP) dos intervalos RFC 1918 especificados:

   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
   

4. Crie regras de firewall na rede de VPC do hub e nas redes de VPC spoke para permitir que o IAP para SSH aceda a todas as suas máquinas virtuais:

   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
   

   Este tutorial usa o Identity-Aware Proxy (IAP) para SSH. Para mais informações, consulte o artigo Estabelecer ligação a instâncias que não têm endereços IP externos.

5. Crie uma regra de firewall para permitir verificações de funcionamento para grupos de instâncias de autorrecuperação na rede da VPC do hub:

   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
   

Criar as instâncias e os trajetos necessários

1. No Cloud Shell, crie o modelo de instância para a gateway NAT que tem um script de arranque que configura a gateway 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'
   

   Este tutorial usa n1-standard-2 como o tipo de instância, mas pode usar qualquer outro número ou tamanho de gateway que quiser. Certifique-se de que considera fatores como a largura de banda de saída máxima por VM.

2. Crie uma verificação de funcionamento de HTTP:

   gcloud compute health-checks create http nat-gw-ilbnhop-health-check \
       --region us-central1 \
       --port 80
   

3. Crie um grupo de instâncias regional com duas instâncias distribuídas por uma única região:

   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
   

   Neste tutorial, o atraso inicial está definido como 15 segundos. Numa implementação de produção, personalize esta definição de acordo com os seus requisitos. Este tutorial não usa políticas de escalabilidade automática.

4. Crie um serviço de back-end e adicione o grupo de instâncias:

   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
   

5. Crie uma regra de encaminhamento:

   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-ilbnhop
   

   Embora a regra de encaminhamento seja definida apenas com TCP, quando usa o Network Load Balancer de passagem interno como o próximo salto, a regra de encaminhamento encaminha todo o tráfego para todas as portas nas VMs de back-end. O balanceador de carga de rede de encaminhamento interno é um balanceador de carga regional.

6. Crie uma nova rota com a regra de encaminhamento como o próximo salto:

   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
   

   Pode especificar etiquetas de rede para que a rota de próximo salto se aplique apenas a instâncias de cliente que tenham sido configuradas com a etiqueta, mas as etiquetas não são exportadas nem importadas através da interligação de redes VPC.

7. Elimine o encaminhamento predefinido da VPC do hub:

   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 -q
   

8. Crie uma nova rota etiquetada para permitir tráfego apenas a partir dos gateways de NAT:

   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
   

9. Elimine as rotas predefinidas para a Internet da VPC de cada hub:

   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
   

   Quando existe um conflito entre rotas locais e importadas, as rotas locais têm sempre precedência. Para mais informações, consulte o artigo Ordem do planeamento de trajeto.

10. Crie VMs de cliente:

    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'
    

Criar as ligações de intercâmbio da rede da VPC

O intercâmbio da rede de VPC é bidirecional e, por isso, tem de ser definido em ambas as extremidades. Uma rede VPC pode estabelecer intercâmbio com várias redes VPC, mas aplicam-se limites. Para alcançar o encaminhamento predefinido através do intercâmbio da rede da VPC, use a funcionalidade importar e exportar encaminhamentos personalizados através do intercâmbio da rede da VPC.

Para este tutorial, cria todas as redes VPC no mesmoGoogle Cloud projeto.

1. No Cloud Shell, crie as ligações da VPC da rede da VPC do hub para as redes da VPC spoke com a flag de exportação de rotas ativada:

   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
   

2. Crie uma ligação de intercâmbio da rede da VPC da spoke1 rede da VPC para a rede da VPC do hub com a flag de importação de rotas ativada:

   gcloud compute networks peerings create spoke1-to-hub \
       --network spoke1-vpc --peer-network hub-vpc \
       --peer-project $PROJECT_ID \
       --import-custom-routes
   

3. Crie uma ligação de intercâmbio da rede da VPC da spoke2 rede da VPC para a rede da VPC do hub com a flag de importação de rotas ativada:

   gcloud compute networks peerings create spoke2-to-hub \
       --network spoke2-vpc --peer-network hub-vpc \
       --peer-project $PROJECT_ID \
       --import-custom-routes
   

Validar a propagação e a conetividade da rota

1. No Cloud Shell, verifique se as rotas estáticas foram criadas corretamente como parte dos scripts de arranque.

   gcloud compute routes list --filter="network:hub-vpc"
   

   Certifique-se de que as rotas hub-default-tagged e hub-nat-gw-ilbanhop estão presentes no resultado:

   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
   

2. Verifique a tabela de encaminhamento spoke1-vpc para se certificar de que a rota predefinida foi importada corretamente:

   gcloud compute routes list --filter="network:spoke1-vpc"
   

   Certifique-se de que existe uma rota que começa com peering-route com 0.0.0.0/0 como o valor DEST_RANGE na saída:

   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
   

3. Ligue-se a um dos clientes através de SSH através do IAP:

   gcloud compute ssh spoke1-client --tunnel-through-iap
   

4. Valide a conetividade testando o DNS público da Google através do gateway NAT:

   sudo hping3 -S -p 80 -c 3 dns.google
   

   Uma vez que o balanceador de carga de rede de encaminhamento interno suporta TCP e UDP, não pode validar a conetividade à Internet através de um ping baseado em ICMP. Por isso, tem de usar uma ferramenta como o hping3.

   O resultado é semelhante ao seguinte:

   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
   

5. Valide o endereço IP público que usa para comunicar com a Internet:

   curl ifconfig.co
   

   O resultado apresenta um endereço IP público de uma das instâncias do gateway NAT. Se executar o comando novamente, o resultado pode apresentar um endereço IP público diferente porque as ligações são distribuídas através da afinidade de sessão de balanceamento de carga interno configurada (por predefinição, IP do cliente, protocolo e porta).

   O intercâmbio das redes da VPC não é transitivo, pelo que não existe conetividade entre as redes da VPC spoke através do intercâmbio das redes da VPC.

Considerações para um ambiente de produção

A configuração que cria neste tutorial fornece dois gateways NAT numa única região. No entanto, o equilíbrio de carga ECMP não é perfeito e um fluxo individual não é distribuído por vários links, que é o que quer quando usa dispositivos com estado, como firewalls de nova geração.

Para implementar esta configuração no ambiente de produção, considere os seguintes pontos:

• Esta configuração é mais adequada para links externos efémeros ou sem estado. Se o tamanho do conjunto do gateway NAT mudar, as ligações TCP podem ser reequilibradas, o que pode resultar na reposição de uma ligação estabelecida.
• Os nós não são atualizados automaticamente. Por isso, se uma instalação predefinida do Debian tiver uma vulnerabilidade de segurança, tem de atualizar a imagem manualmente.
• Se tiver VMs em várias regiões, tem de configurar gateways NAT em cada região.
• A largura de banda por gateway pode variar consoante o tipo de hardware. Certifique-se de que considera fatores como a largura de banda de saída máxima por VM. Durante uma falha do gateway, o tráfego é distribuído pelos gateways restantes. Uma vez que os fluxos em execução não são reprogramados, o tráfego não é imediatamente resolvido quando o gateway volta a ficar online. Por isso, certifique-se de que permite uma sobrecarga suficiente ao dimensionar.
• Para receber alertas sobre resultados inesperados, use o Cloud Monitoring para monitorizar os grupos de instâncias geridos e o tráfego de rede.

Limpar

A forma mais fácil de eliminar a faturação é eliminar o Google Cloud projeto que criou para o tutorial. Em alternativa, pode eliminar os recursos individuais.

Elimine o projeto

Atenção: a eliminação de um projeto tem os seguintes efeitos:
• Tudo no projeto é eliminado. Se usou um projeto existente para as tarefas neste documento, quando o elimina, também elimina qualquer outro trabalho que tenha feito no projeto.
• Os IDs dos projetos personalizados são perdidos. Quando criou este projeto, pode ter criado um ID do projeto personalizado que quer usar no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, elimine os recursos selecionados no projeto em vez de eliminar o projeto inteiro.
1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

Elimine os recursos individuais

Se quiser manter o Google Cloud projeto, pode eliminar os recursos que criou para este tutorial.

1. Elimine as ligações de intercâmbio da rede de 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
   

2. Elimine as instâncias, os recursos do balanceador de carga, os modelos e as rotas:

   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
   

3. Elimine as regras de firewall, as sub-redes e as redes de 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
   

O que se segue?

• Leia sobre as práticas recomendadas e as arquiteturas de referência para o design de VPC.
• Reveja a documentação sobre o intercâmbio da rede da VPC e os balanceadores de carga de rede de encaminhamento interno como saltos seguintes.
• Leia sobre as configurações especiais para instâncias de VM.