IBM Cloud Docs
Centralize a comunicação por meio de uma arquitetura VPC Transit Hub and Spoke - Parte um

Centralize a comunicação por meio de uma arquitetura VPC Transit Hub and Spoke - Parte um

Este tutorial pode incorrer em custos. Use o Estimador de custos para gerar uma estimativa do custo baseada em seu uso projetado.

Um Virtual Private Cloud (VPC) fornece isolamento de rede e segurança no IBM Cloud. Uma VPC pode ser um bloco de construção que encapsula uma divisão corporativa (marketing, desenvolvimento, contabilidade, etc.) ou uma coleção de microsserviços pertencentes a uma equipe de DevSecOps. Os VPCs podem ser conectados a um empreendimento no local e um ao outro. Isso pode criar a necessidade de rotear o tráfego através de dispositivos de gateway de firewall centralizados. Este tutorial caminhará pela implementação de um hub e arquitetura falada retratada nesta visão de alto nível:

de arquitetura do

Esta é parte um de um tutorial de duas partes. Esta parte introduzirá o hub de trânsito VPC como o conduto para a empresa. Empresa para falar conectividade VPC entre microserviços será discutida e implementada. Esta arquitetura apoiará uma série de cenários:

  • O hub é um ponto central de roteamento de tráfego entre a empresa e a nuvem.
  • O tráfego corporativo para nuvem é roteado por meio do hub e pode ser monitorado e registrado por meio de um dispositivo Network Function Virtualization (NFV) em execução dentro do hub.
  • O hub pode monitorar todo ou parte do tráfego: spoke <-> spoke, spoke <-> transit ou spoke <-> corporativo.
  • O hub pode conter microsserviços compartilhados usados por spokes..
  • O hub pode conter recursos de nuvem compartilhados, como bancos de dados, acessados por meio de gateways de terminais privados virtuais controlados por grupos de segurança de VPC e listas de controle de acesso de sub-rede, compartilhados por spokes
  • O hub pode segurar os recursos de VPN que são compartilhados pelos spokes.

(Parte dois) irá estender este tutorial roteirizando todo o tráfego VPC para o tráfego VPC através do hub, implementar um firewall altamente disponível-roteador e tráfego de rotas para IBM Cloud instâncias de serviço com resolução DNS.

Há um acompanhante GitHub repositório que provisiona recursos e configura roteamento em camadas incrementais. No tutorial as camadas finas permitem a introdução de desafios e soluções de tamanho de mordida.

Durante a viagem os seguintes são explorados:

Uma arquitetura em camadas introduzirá recursos e demonstrará conectividade. Cada camada adicionará conectividade e recursos adicionais. Uma camada pode introduzir pequenos problemas e demonstrar soluções no contexto de uma arquitetura maior. As camadas são implementadas usando Infra-estrutura como Código na forma de arquivos de configuração Terraform. Será possível alterar parâmetros, como número de zonas, alterando uma variável Terraform.

Objetivos

  • Entenda os conceitos por trás de um hub baseado em VPC e modelo falado.
  • Entenda a implementação de um firewall-roteador e um ambiente VPC de trânsito.
  • Entenda o ingresso VPC e o roteamento de egressos.
  • Identificar e resolver opcionalmente problemas de roteamento assimétrico.
  • Conecte VPCs através de um Transit Gateway.

Antes de Iniciar

Este tutorial requer:

  • terraform para usar Infraestrutura como código para provisionar recursos,
  • python para executar opcionalmente os comandos pytest,
  • Implementar um firewall-roteador exigirá que você ative verificações de spoofing IP,
  • Uma chave SSH para se conectar aos servidores virtuais. Se você não tiver uma chave SSH, siga as instruções para criar uma chave para a VPC.

Veja os pré-requisitos para algumas opções incluindo um Dockerfile para criar facilmente o ambiente de pré-requisitos.

Além disso:

Endereço IP e Layout de Subnet

Nesta etapa você irá provisionar os recursos da rede VPC. Planee cuidadosamente o projetando um plano de endereçamento para um VPC e use blocos CIDR não sobrepostos.

É tentador dividir o espaço CIDR primeiro pela VPC mas isso complica o roteamento. Em vez disso pense em uma zona de disponibilidade como um único bloco CIDR e cada VPC como consumir uma fatia dele.

Zonas
Zonas

Este diagrama mostra apenas a zona 1 em mais detalhes. Os tamanhos subnet e o layout são idênticos nas outras zonas:

Layout de VPC
Layout de VPC

Acima a empresa está à esquerda e a IBM Cloud à direita. No IBM Cloud para simplictiy uma única zona é representada para o VPC de trânsito e o Spoke 0. Percebem que os blocos CIDR não se sobrepõem e VPCs todos consomem um bloco CIDR em cada zona:

  • O CIDR no local é 192.168.0.0/16.
  • As zonas nesta região de multi-zona são 10.*.0.0/16. O segundo dígito: 1, 2, 3 é o número da zona (mostrado para Dallas/us-sul):
    • 10.10.1.0.0/16, zona 1, Dallas 1, us-south-1.
    • 10.10.2.0.0/16, zona 2, Dallas 2, us-south-2.
    • 10.10.3.0.0/16, zona 3, Dallas 3, us-south-3.
  • O VPC de trânsito consome CIDRs 10.*.15.0/24:
    • 10.1.15.0/24, zona 1.
    • 10.2.15.0/24, zona 2.
    • 10.3.15.0/24, zona 3
  • O spoke 0 consome 10.*.0.0/24 ou CIDRs:
    • 10.1.0.0/24, zona 1.
    • 10.2.0.0/24, zona 2.
    • 10.3.0.0/24, zona 3.
  • Os CIDRs sub-net dividem ainda mais o /24 em /26.

As sub-redes no trânsito e spoke são para os diferentes tipos de recursos:

  • worker-network acessível recursos de cálculo VPC instâncias, balanceadores de carga, Red Hat OpenShift, etc. As instâncias do VPC são demonstradas neste tutorial.
  • dns- DNS Services aparelhos de localização usados na parte dois.
  • vpe- VPE for VPC usado na parte dois.
  • Instâncias do VPC fw-firewall-router (somente em trânsito).

Provimento de recursos de rede VPC

  1. A companheira GitHub Repositório tem os arquivos de origem para implementar a arquitetura. Em um shell de desktop clone o repositório:

    git clone https://github.com/IBM-Cloud/vpc-transit
    cd vpc-transit
    
  2. O diretório config_tf contém variáveis de configuração que você é necessário para configurar.

    cp config_tf/template.terraform.tfvars config_tf/terraform.tfvars
    
  3. Edite config_tf/terraform.tfvars e use os comentários nesse arquivo como seu guia.

  4. Uma vez que é importante que cada camada esteja instalada na ordem correta e algumas etapas neste tutorial instalará várias camadas um comando shell ./apply.sh é fornecido. A seguir exibirá ajuda:

    ./apply.sh
    
  5. Você poderia aplicar todas as camadas configuradas executando ./apply.sh : :. Os dois pontos são abreviados para primeiro (ou config_tf) e último (power_tf). O -p imprime as camadas:

    ./apply.sh -p : :
    

    Será algo parecido com:

    directories: config_tf enterprise_tf transit_tf spokes_tf transit_spoke_tgw_tf test_instances_tf test_lbs_tf enterprise_link_tf firewall_tf transit_ingress_tf spokes_egress_tf all_firewall_tf all_firewall_asym_tf dns_tf vpe_transit_tf vpe_spokes_tf power_tf
    
  6. Se você ainda não tiver uma, obtenha uma chave de API da plataforma e exporte a chave de API para uso pelo Terraform:

    export IBMCLOUD_API_KEY=YourAPIKEy
    
  7. Nesta primeira etapa, aplique-se em config_tf, enterprise_tf, transit_tf, porta-voz e transit_spoke_tgw_tf:

    ./apply.sh : transit_spoke_tgw_tf
    

Os VPCs e as sub-redes foram criados O VPC de trânsito e os VPCs spoke foram conectados por meio de um Transit Gatewayprovisionado. Abra o Virtual Private Clouds no navegador.. Abra o VPC de trânsito e observe os blocos CIDR para prefixos de endereço e sub-redes. Examine os VPCs corporativos e spoke também. Abra Transit Gateway e clique no gateway de trânsito para ver a conexão entre as VPCs de trânsito e spoke.

Criar instâncias de teste

As Instâncias do Servidor Virtual do VPC, VSIs, são provisionadas para testar a conectividade de rede. Uma instância de teste será adicionada a cada uma das sub-redes do trabalhador (um por zona) na empresa, no trânsito e em cada uma das spokes. Se a configuração padrão de 3 zonas e 2 spokes for usada então 12 instâncias serão provisionadas.

Instâncias de Teste
Instâncias de Teste
.

  1. Criar as instâncias de teste

    ./apply.sh test_instances_tf
    

Pode ser esclarecedor para explorar os recursos criados em cada etapa no console IBM Cloud. Opcionalmente abra o Virtual Private Clouds. No clique esquerdo sobre as instâncias do servidor virtual e observe as instâncias que foram criadas.

Teste

Este tutorial irá adicionar caminhos de comunicação uma camada de cada vez. Uma suíte de testes pytest será usada para testar exaustivamente caminhos de comunicação. Até o final do tutorial todos os testes devem passar.

Não é necessário que o leitor use pytest para verificar os resultados. Siga junto no tutorial, aplique as camadas e confie nos resultados descritos no tutorial. O leitor ainda pode explorar os recursos de VPC como VSIs, sub-redes e tabelas de rotas após serem criados.

Cada teste de pytest irá SSH para uma das instâncias e executará um tipo de teste de conectividade, como executar um comando curl para uma das outras instâncias. O ambiente SSH padrão é usado para fazer login nas instâncias. Se você ver resultados de teste inesperados tente a seção resolução de problemas pytest.

  1. Execute os testes da zona 1 curl na suíte usando a bandeira -m (marcadores). Escolha os testes marcados com curl, lz1 (zona esquerda 1) e rz1 (zona direita 1).

    Seus resultados esperados são: a Conectividade dentro de uma VPC, como corporativa <-> corporativa será APROVADA A conectividade entre o trânsito e os spokes será Passada A VPC cruzada de enterprise-> transit ou spokes será FAILED.

    pytest -m "curl and lz1 and rz1"
    

    Abaixo está um exemplo de saída:

    root@ea28970e0897:/usr/src/app# pytest -m "curl and lz1 and rz1"
    ===================================================== test session starts ======================================================
    platform linux -- Python 3.12.3, pytest-8.1.1, pluggy-1.4.0 -- /usr/local/bin/python
    cachedir: .pytest_cache
    rootdir: /usr/src/app
    configfile: pytest.ini
    testpaths: py
    plugins: xdist-3.5.0
    collected 36 items / 20 deselected / 16 selected
    
    py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-enterprise-z1-worker] PASSED                                   [  6%]
    py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-transit-z1-worker] FAILED                                      [ 12%]
    py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke0-z1-worker] FAILED                                       [ 18%]
    py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke1-z1-worker] FAILED                                       [ 25%]
    py/test_transit.py::test_curl[l-transit-z1-worker -> r-enterprise-z1-worker] FAILED                                      [ 31%]
    py/test_transit.py::test_curl[l-transit-z1-worker -> r-transit-z1-worker] PASSED                                         [ 37%]
    py/test_transit.py::test_curl[l-transit-z1-worker -> r-spoke0-z1-worker] PASSED                                          [ 43%]
    py/test_transit.py::test_curl[l-transit-z1-worker -> r-spoke1-z1-worker] PASSED                                          [ 50%]
    py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-enterprise-z1-worker] FAILED                                       [ 56%]
    py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-transit-z1-worker] PASSED                                          [ 62%]
    py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-spoke0-z1-worker] PASSED                                           [ 68%]
    py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-spoke1-z1-worker] PASSED                                           [ 75%]
    py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-enterprise-z1-worker] FAILED                                       [ 81%]
    py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-transit-z1-worker] PASSED                                          [ 87%]
    py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-spoke0-z1-worker] PASSED                                           [ 93%]
    py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-spoke1-z1-worker] PASSED                                           [100%]
    
    =================================================== short test summary info ====================================================
    FAILED py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-transit-z1-worker] - assert False
    FAILED py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke0-z1-worker] - assert False
    FAILED py/test_transit.py::test_curl[l-enterprise-z1-worker -> r-spoke1-z1-worker] - assert False
    FAILED py/test_transit.py::test_curl[l-transit-z1-worker -> r-enterprise-z1-worker] - assert False
    FAILED py/test_transit.py::test_curl[l-spoke0-z1-worker -> r-enterprise-z1-worker] - assert False
    FAILED py/test_transit.py::test_curl[l-spoke1-z1-worker -> r-enterprise-z1-worker] - assert False
    ========================================= 6 failed, 10 passed, 20 deselected in 38.76s =========================================
    

Uma mudança para a configuração da rede pode levar um par de corridas para que o sistema de rede VPC subjacente se torne consistente. Se você não ver os resultados esperados inicialmente esteja preparado para executar o teste novamente algumas vezes.

O stand r- e l- para o r ight e l eft. A parte média do nome identifica empresa, trânsito, spoke0, spoke1, ... O z1, z2, ... identificar a zona. O teste irá SSH para a instância da esquerda. Na instância da esquerda a conectividade com a instância certa é tentada. O test_curl executa uma conectividade de curl na instância da esquerda para a instância certa.

Em resumo, o teste test_curl[l-enterprise-z1 -> r-transit-z1] irá:

  1. SSH a uma instância de teste na zona corporativa 1.
  2. Executar um curl para a zona de trânsito 1.
  3. Assert a string de retorno contém o ID da zona de trânsito 1 para marcar passe ou falha.

O README.md na companheira GitHub Repositório tem mais detalhes e o código fonte.

Conectar Enterprise ao Transit via Direct Link e Transit Gateway

Provisionar um IBM Cloud® Direct Link usando Transit Gateway.

Link corporativo
Link corporativo

IBM Cloud® Direct Link é um caminho de dados seguro de alta velocidade para conexão de uma empresa ao IBM Cloud. Neste tutorial Transit Gateway é usado para distribuição. O uso de Transit Gateway é opcional para uma conexão no local.

A empresa neste tutorial é simulada com outro VPCs. Conectando esta empresa simulada (na verdade outro VPC) via o Transit Gateway irá garantir uma experiência muito próxima do que você experimentaria com um Direct Link.

  1. Aplique a camada enterprise_link_tf:

    ./apply.sh enterprise_link_tf
    
  2. Execute os testes de curl da zona 1 na suíte minha usando a bandeira -m (marcadores). Escolha os testes marcados com curl, lz1 (zona esquerda 1) e rz1 (zona direita 1).

    Os seus resultados esperados são: Conectividade dentro de um VPC, trânsito <-> falou (s), empresa <-> trânsito, falou (s) <-> falou (s) pass mas enterprise <-> falou (s) fail (s).

    pytest -m "curl and lz1 and rz1"
    

Conectar Enterprise ao Spoke (s) via Transit NFV Firewall-Router

O incentivo para um VPC de trânsito para empreendimento <-> tráfego de nuvem é tipicamente rotear, inspecionar, monitorar e registrar o tráfego de rede. Nesta etapa um dispositivo de roteador de firewall será instalado em cada zona do VPC de trânsito.

Roteador NFV

Provisionar os aparelhos de roteador de firewall. Uma tabela de rotas de ingresso para Transit Gateway foi incluída no VPC de trânsito conforme indicado pelas linhas pontilhadas. Uma sub-rede foi criada em cada uma das zonas do VPC de trânsito para realizar o roteador de firewall.

Firewall
Firewall

A conectividade da empresa para um falado é obtida por meio de uma Virtualização de Function de Rede, NFV, instância de roteador de firewall no VPC de trânsito. Na produção você pode escolher uma a partir do catálogo ou trazer a sua. Esta demonstração usará uma imagem de estoque Ubuntu com iptables kernel configurados para encaminharão todos os pacotes da fonte para o destino. Neste tutorial, nenhuma inspeção de firewall é executada

A configuração Terraform configurará a instância do firewall-roteador com allow_ip_spoofing. Você deve ativar verificações de spoofing IP antes de continuar.

  1. Aplique a camada firewall_tf:

    ./apply.sh firewall_tf
    
  2. Execute a suíte de testes.

    Os seus resultados esperados são: Conectividade dentro de um VPC, empresa-> trânsito, empresa <-> falou mesmo passagem de zona. Mas todo o trânsito-> falou, todo o trânsito-> empresa falha devido a problemas de roteamento assimétricos.

    pytest -m "curl and lz1 and (rz1 or rz2)"
    

    Parte dois deste tutorial roteará todo o tráfego de VPC <-> diferente por meio do roteador de firewall e resolverá esses problemas. Mas primeiro é importante aprender o que está acontecendo.

Roteamento de ingresso

O tráfego atinge o dispositivo de roteador de firewall através de tabelas de roteamento.

  1. Visite os VPCs no console IBM Cloud.
  2. Selecione o VPC de trânsito.
  3. Clique em Gerenciar tabelas de roteamento.
  4. Clique na tabela de roteamento tgw-ingress.

A zona é determinada pelo Transit Gateway que examinará o endereço IP de destino de cada pacote e o roteará para a zona correspondente com base nas rotas aprendidas. O Transit Gateway aprende as rotas anunciadas nas conexões. Cada VPC anunciará seus prefixos de endereço que permitem que as VPCs se comuniquem entre si após se conectarem a um Transit Gateway. Mas como os spokes aprenderiam as rotas para a empresa? Como a empresa aprende as rotas para os spokes? A empresa e os spokes não são conectados ao mesmo Transit Gateway.

Ambos os conjuntos de rotas estão na tabela de roteamento de entrada do trânsito (mostrada para Dallas/us-south). E a sinalização Anunciar é configurada como ON para passar essas rotas para todos os Transit Gateways.

Zona Destino Próximo salto Anúncio
Dallas 1 10.1.0.0/16 10.1.15.197 On
Dallas 2 10.2.0.0/16 10.2.15.197 On
Dallas 3 10.3.0.0/16 10.3.15.197 On
Dallas 1 192.168.0.0/16 10.1.15.197 On
Dallas 2 192.168.0.0/16 10.2.15.197 On
Dallas 3 192.168.0.0/16 10.3.15.197 On

O next_hop identifica o roteador de firewall. Na tabela acima, 10.1.15.196 zona Dallas 1 e 10.2.15.196 zona Dallas 2, etc. Você pode observar isso usando o console IBM Cloud.

  1. Abra instâncias do servidor virtual para VPC para encontrar as instâncias fw e IP Reservado associado (clique no cabeçalho da coluna Nome para classificar).
  2. Combine-os com a tabela acima para verificar a próxima relação de salto.

Removendo o firewall para o tráfego de destino de trânsito

O IBM Cloud VPC usa o roteamento baseado em estado padrão de mercado para rastreamento de conexão TCP segura. Ele requer que as conexões TCP utilizem o mesmo caminho na forma de como sair. Uma exceção é o Direct Server Return usado por roteadores como Network Load Balancers. Ele permite que as conexões recebidas da empresa passem pelo firewall para a instância de teste de trânsito e depois retornam diretamente para o originador.

Conexões recebidas da empresa passam pelo firewall
Conexões recebidas da empresa passam pelo firewall

Isso não ajuda com o tráfego originado na instância de teste de trânsito que passa pelo Transit Gateway então de volta através de roteamento de ingresso para o roteador de firewall. Esta conexão fica presa no firewall-roteador (3) e não será encaminhada de volta para o trabalhador como mostrado em vermelho abaixo. Trânsito de tráfego-> empresa e trânsito-> falou estão falhando.

Tráfego entre o trânsito e a empresa e o trânsito e o spoke está falhando
O tráfego entre o trânsito e a empresa e o trânsito para o spoke está falhando

Uma solução possível é deixar de enviar tráfego destinado ao VPC de trânsito para o roteador de firewall. As amplas rotas de ingresso para o trânsito estão atualmente roteando o tráfego para o roteador de firewall. Rotas mais específicas podem ser adicionadas para o trânsito em Delegado para o comportamento padrão-enviar diretamente para o destino pretendido em vez do roteador de firewall.

Este diagrama mostra o fluxo de tráfego desejado para esta etapa. Apenas a empresa <-> falou está passando pelo firewall:

Somente rotear a empresa para falar por meio do firewall
Somente rotear a empresa para falar por meio do firewall

  1. empresa <-> trânsito
  2. falou <-> trânsito
  3. falou <-> falou
  4. empresa <--transit firewall-router--> spoke

Esse roteamento pode ser alcançado adicionando-se essas rotas para a tabela de rotas de ingresso de trânsito:

Zona Destino Próximo salto
Dallas 1 10.1.15.0/24 Delegate
Dallas 2 10.2.15.0/24 Delegate
Dallas 3 10.3.15.0/24 Delegate
  1. Para observar o valor atual da tabela de rotas de ingresso visite as tabelas de roteamento para VPC no console IBM Cloud. Selecione o VPC de trânsito da queda para baixo e, em seguida, selecione a tabela de roteamento tgw-ingress.

  2. Faça as alterações na tabela de roteamento, aplicando a camada transit_ingresso:

./apply.sh transit_ingress_tf
  1. Atualize o display do navegador da tabela de roteamento para observar as novas rotas.

  2. Execute a suíte de testes.

    Os resultados esperados são: Todos os testes resultarão em APROVADO.

    pytest -m "curl and lz1 and (rz1 or rz2)"
    

É interessante observar como o tráfego entre zonas flui entre a empresa e os spokes na configuração. A empresa envia o tráfego para a zona correta e por meio do roteador de firewall por meio do roteamento de ingresso na VPC de trânsito O Transit Gateway aprendeu que 192.168.0.0/16 está disponível em todas as zonas e roteará para o VPC de trânsito usando as rotas corporativas anunciadas na mesma zona que o spoke, conforme mostrado no diagrama abaixo:

Roteando o tráfego da empresa <-> spoke usando rotas anunciadas
Roteando o tráfego do spoke para o trânsito com uma tabela de roteamento de egresso
..

Resumo de Ro

O roteamento básico está completo:

  • empresa <-> trânsito
  • trânsito <-> falou (s)
  • empresa < -- (firewall de trânsito-roteador)--> falou

Diagrama final da parte um
Diagrama final da parte um

Notas de Produção e Conclusões

A arquitetura de referência do VPC para o IBM Cloud para Serviços Financeiros tem muito mais detalhes em garantir cargas de trabalho no IBM Cloud.

Algumas mudanças óbvias para fazer:

  • Os blocos CIDR foram escolhidos para clareza e facilidade de explicação. As Zonas de Disponibilidade na Região da Zona Multi poderiam ser 10.0.0.0/10, 10.64.0.0/10, 10.128.0.0/10 para conservar o espaço de endereço. O espaço de endereço para nós do Trabalhador poderia ser expandido em detrimento do firewall, do DNS e do espaço VPE.
  • Os Grupos de Segurança para cada uma das interfaces de rede para VSIs do trabalhador, Gateways de Terminal Privado Virtual, Locais DNS e firewalls devem ser cuidadosamente considerados.
  • Listas De Controle De Acesso À Rede para cada sub-rede devem ser cuidadosamente consideradas.

Os IPs flutuantes foram anexados a todas as instâncias de teste para suportar testes de conectividade via SSH. Isso não é necessário ou desejável na produção.

Implementar restrições baseadas em contexto regras para controlar ainda mais o acesso a todos os recursos.

Neste tutorial você criou um VPC de hub e um conjunto de VPCs falados. Você identificou as zonas de Disponibilidade Necessárias para a arquitetura e criou um conjunto de sub-redes nos VPCs. Você criou um roteador de firewall de VPC de trânsito em cada zona para encaminhar o tráfego As instâncias de teste foram usadas para verificar a conectividade e identificar problemas potenciais. As rotas da tabela de roteamento foram usadas para identificar os caminhos de tráfego necessários.

Remover recursos

Não é necessário remover os recursos se você planeja continuar com a segunda parte deste tutorial

Execute terraform destroy em todos os diretórios em ordem inversa usando o comando ./apply.sh :

./apply.sh -d : spokes_egress_tf

Expandir o tutorial

Você é encorajado a continuar na parte dois deste tutorial em que todo o tráfego de VPC cruzado é roteado através do firewall-roteador, VPE for VPC e DNS são examinados.

A sua arquitetura provavelmente será diferente da apresentada mas provavelmente será construída a partir dos componentes fundamentais discutidos aqui. Ideias para expandir este tutorial: