VCF 9 – Parte 4: Configurando NSX Virtual Private Cloud (VPC)

por virtualizandoaju, publicado em VMware

Vamos de introdução?! Olá virtualization warrior! Seja bem vindo ao meu escritório mais uma vez! Hoje falaremos do VPC (Virtual Private Cloud) no NSX que é, basicamente, a forma “cloud-like” de organizar rede e segurança dentro do seu data center VCF 9. Em vez de todo mundo disputar o mesmo “grande NSX compartilhado”, você cria ambientes lógicos isolados — as VPCs — onde cada time/projeto tem sua própria fatia de rede, com segmentação, regras de firewall, NAT, load balancer etc., tudo encapsulado e pronto para consumo em modo self-service.

Se você já está acostumado com o conceito de VPC em nuvem pública (como AWS, por exemplo), a ideia aqui é muito parecida: uma “rede virtual privada” isolada dentro de uma infraestrutura maior. A diferença é que, com NSX VPC no VCF 9, essa experiência passa a estar integrada ao seu private cloud on-premises, aproveitando todo o stack do VMware Cloud Foundation (vSphere, vSAN, NSX, etc.).

Do ponto de vista da arquitetura NSX, a VPC é uma camada de abstração em cima dos projetos (projects). Ela permite criar “mini-datacenters” lógicos, cada um com seus próprios blocos de IP, segmentos, rotas, políticas de segurança e objetos de rede, com isolamento tanto de dados quanto de plano de controle. Isso habilita um modelo de multitenancy muito mais organizado, onde cada time de aplicação enxerga e gerencia apenas o seu próprio VPC.

No VCF 9, o conceito de VPC deixa de ser “recurso avançado escondido” e passa a ser parte central do modelo de operação da plataforma. A solução vem “VPC Ready”, permitindo consumir VPCs diretamente via vCenter, VCF Ops/Automation, APIs e o próprio NSX, com menos esforço de deployment e integração. Além disso, novas opções de conectividade — como o modelo distribuído, que permite alcançar a rede física sem precisar de NSX Edge VM em certos cenários — simplificam bastante o desenho de north-south.

Em termos práticos, o que isso significa para o seu dia a dia como admin ou arquiteto de infraestrutura?

  • Isolamento forte por projeto/cliente/time: cada VPC é um “mundo à parte” em termos de rede e segurança.
  • Self-service real para donos de aplicação: dentro da VPC, o próprio time pode criar segmentos, ajustar regras de firewall, configurar NAT e balanceamento de carga, dentro dos limites que você definir.
  • Consistência de políticas: você aplica guardrails globais no NSX/VCF, e cada VPC herda essas políticas, mantendo governança sem virar gargalo operacional.
  • Operação mais próxima da experiência de nuvem pública: o modelo de VPC ajuda a oferecer para os times internos a mesma experiência que eles estão acostumados a consumir em hyperscalers — só que agora no seu private cloud com VCF 9.

Nesta Parte 4 da série “VCF 9 – Configurando NSX Virtual Private Cloud (VPC)”, vamos pegar esse conceito e traduzi-lo em prática: você vai ver como habilitar o recurso no ambiente, criar sua primeira VPC e preparar o terreno para que os times de aplicação comecem a consumir rede e segurança de forma autônoma, mas ainda totalmente alinhada aos padrões que você definiu para a plataforma.

Referência de desenho:

Existem duas opções de configuração:

Distributed External Conncetion – > Não depende uma estrutura com edge e usa vlan.

Centralized External Conncetion -> Depende de uma estrutura com pelo menos dois edges que suporta NAT e configurações mais avanaçads como load balancer.

REQUISITOS

Pilha VMware VCF 9X implantada.

VLAN TEP cofigurada. (ACESSO AO MUNDO REAL)

Documentação VMware VPC

CONFIGURAÇÃO PARA VPC Centralized External Conncetion

Etapa 1 – Preparando o cluster para VPC: ativando o NSX nos DVPGs

Antes de falar em VPC, a base precisa estar pronta. O NSX só consegue entregar rede e segurança “as-a-service” para as VPCs se os hosts ESXi do cluster já estiverem integrados à malha de transporte do NSX. É exatamente isso que fazemos nesta primeira etapa: ativar o NSX nos Distributed Virtual Port Groups (DVPGs) do cluster.

Na prática, quando você ativa o NSX sobre os DVPGs de um vSphere Distributed Switch:

  • o cluster passa a fazer parte da NSX fabric, pronto para receber políticas de segurança distribuída (DFW) e segmentos lógicos;
  • os hosts ESXi são preparados como transport nodes, conseguindo participar da malha de overlay do NSX;
  • você garante que esse cluster está apto a hospedar workloads dentro de VPCs, com conectividade e segurança gerenciadas pelo NSX em vez de depender apenas da rede “tradicional” do vSphere.

Nesta etapa, então, o objetivo não é “criar a VPC” ainda, mas garantir que o cluster onde as VPCs vão viver já está NSX-ready. A partir daí, fica muito mais simples consumir VPCs como um serviço de rede dentro do VCF 9. Acesse → NSX Manager → System → depois Hosts.

A ativação do NSX em Grupos de Portas Virtuais Distribuídas (DVPGs) ativará o NSX em todas as portas dentro dos DVPGs encontrados neste cluster. Clique em Sim para continuar.

Etapa 2 – Configurando a conectividade de rede do Datacenter para uso com VPCs

Depois de preparar o cluster e ativar o NSX nos DVPGs, o próximo passo é dizer ao vSphere/NSX como esse datacenter se conecta ao restante da rede. É isso que fazemos na aba Networks → Network Connectivity do vCenter.

Nesta etapa, o objetivo é estabelecer a conectividade de rede que será utilizada pelas futuras VPCs, definindo por onde o tráfego vai entrar e sair do ambiente:

  • qual infraestrutura de rede física/vLANs será usada como “underlay”;
  • como o tráfego das VPCs poderá alcançar redes externas (outros segmentos internos, internet, DMZ, etc.);
  • quais recursos do NSX (como serviços L3, NAT, DHCP e afins) poderão ser consumidos a partir desse datacenter.

Em outras palavras, aqui nós preparamos o “backbone” de rede do datacenter para que, nas próximas etapas, a criação de VPCs seja basicamente um consumo de serviço — sem ter que redesenhar conectividade toda vez.

A partir do botão Configure Network Connectivity, o administrador entra no assistente que amarra o vCenter ao NSX para prover essa camada de conectividade compartilhada que todas as VPCs vão usar.

Etapa 3 – Escolhendo o tipo de Gateway para as VPCs

Nesta etapa do assistente Configure Network Connectivity, definimos como as VPCs vão se conectar com o mundo externo. É aqui que escolhemos o Gateway Type.

No cenário do artigo, selecionamos Centralized Connectivity. Esse modo usa um NSX Edge Cluster para concentrar os serviços de borda, o que permite:

  • usar NAT, DHCP, serviços L3 e futuramente Load Balancer para as VPCs;
  • ter um ponto claro de saída/entrada do tráfego (gateway central), facilitando operação, troubleshooting e observabilidade;
  • desenhar uma borda mais parecida com o modelo tradicional de data center, porém consumida como serviço pelas VPCs.

A opção Distributed Connectivity é mais enxuta e indicada para ambientes que precisam apenas de serviços básicos (como DHCP e IP externo) e querem minimizar dependência de Edge. Como o objetivo deste laboratório é explorar o máximo dos recursos de rede da VPC, seguimos com Centralized Connectivity e avançamos em Next para continuar o assistente.

Etapa 4 – Validando os pré-requisitos de rede

Ao escolher o tipo de gateway, o assistente exibe a janela Networking Prerequisites.
Ela não configura nada por você: é um checklist para garantir que o ambiente está pronto para receber o Edge Cluster e, consequentemente, as VPCs.

Aqui o ponto principal é confirmar que você já possui:

  • VLAN para TEP do Edge (pode ser a mesma VLAN dos TEPs de host, se planejado assim);
  • Recursos de CPU/RAM suficientes no cluster para pelo menos dois Edge Nodes;
  • Conectividade de management entre Edge Nodes e NSX Manager;
  • DNS configurado para os componentes NSX;
  • Planejamento de roteamento dinâmico (BGP) ou estático, incluindo ASN, peers e, se necessário, VIP para Tier-0;
  • Blocos de IP externos reservados para a conectividade das VPCs (sem sobreposição com management, uplinks e TEP).

Em laboratório, normalmente marcamos Select All porque esses itens já foram considerados no deployment do VCF/NSX.
Em produção, vale tratar essa tela como um lembrete importante: só clique em Continue depois de validar cada um desses pontos no seu desenho de rede.

Etapa 5 – Definindo o Edge Cluster que vai entregar serviços às VPCs

Agora entramos na parte mais crítica da conectividade: criar o Edge Cluster que vai entregar os serviços de rede para as VPCs (NAT, DHCP, roteamento L3, VPN etc.).

Nesta tela, fazemos três coisas principais:

  1. Nome do Edge Cluster
    Damos um nome lógico, por exemplo vcf-edge-cluster.
    É esse cluster de Edges que será referenciado depois pelos Tier-0/Tier-1 e, consequentemente, pelas VPCs.
  2. Parâmetros gerais do Edge
    • Tunnel Endpoint MTU: define o MTU usado nos túneis Geneve dos Edges (normalmente alinhado ao MTU do underlay).
    • Edge Form Factor: escolhemos o tamanho da VM de Edge (Small, Medium, Large…), de acordo com o porte do ambiente. No lab, “Medium” costuma ser suficiente.
  3. Inclusão dos NSX Edge Nodes
    Clicamos em Add para adicionar os Edge Nodes que farão parte desse cluster.
    O wizard exige no mínimo dois Edges, garantindo alta disponibilidade dos serviços de borda.

Concluída essa etapa, temos a “borda NSX” pronta para ser usada como fundação de conectividade para todas as VPCs que criaremos a seguir.

Etapa 5 (continuação) – Configurando o Edge Node 01 (parte 1)

Com o Edge Cluster criado, o próximo passo é definir os detalhes do primeiro Edge Node (edge01a), que será uma VM responsável pelos serviços de borda usados pelas VPCs.

Nesta tela, amarramos o Edge à infraestrutura vSphere e à rede de gestão:

  • Edge Node Name (FQDN)
    Definimos o nome completo do Edge (ex.: edge01a.virtualizandoaju.com.br).
    Esse FQDN deve existir no seu DNS, pois será usado pelo NSX e pelas ferramentas de operação.
  • vSphere Cluster / Resource Pool / Datastore
    Escolhemos onde a VM do Edge será criada:
    • o cluster (no exemplo, VCF-Mgmt-Cluster),
    • o Resource Pool (para organizar recursos)
    • e o datastore (vsanDatastore).
      Aqui garantimos que o Edge fique próximo aos componentes de management e com recursos adequados.
  • Management IP
    Definimos como o Edge será alcançado na rede de gestão:
    • Tipo de alocação (Static no exemplo);
    • Port Group de management (DVPG_FOR_VM_MANAGEMENT);
    • Endereço IP de gestão do Edge (192.168.79.17/24) e Default Gateway (192.168.79.254).
    É por esse IP que o NSX Manager e demais ferramentas vão falar com o Edge Node.
  • Uplinks
    Mantemos marcada a opção para usar a mesma configuração de overlay dos hosts. Isso simplifica o desenho, reaproveitando a VLAN/TEP já planejada para o ambiente.

Com essas definições, garantimos que o Edge01 está corretamente posicionado e acessível, pronto para receber as interfaces de overlay/uplink que vão suportar o tráfego das VPCs nas próximas configurações.

Etapa 5 (continuação) – Mapeando uplinks e TEP do Edge01

Para que o Edge01 participe da malha de overlay do NSX e fale com a rede física, precisamos finalizar o mapeamento de uplinks e TEP.

Nesta parte da tela configuramos:

  • Edge Node Uplink Mapping
    • Associamos as interfaces lógicas do Edge (fp-eth0 e fp-eth1) à(s) vmnic(s) físicas do host (no exemplo, ambas em vmnic2). SÓ ESTAMOS USANDO UMA VMNIC!
    • É por essas interfaces que o Edge vai enviar/receber o tráfego de overlay e uplink.
  • TEP VLAN e IP Pool
    • Definimos a VLAN de TEP usada pelo Edge (ex.: VLAN 60), que deve ser a mesma planejada no underlay para o tráfego Geneve.
    • Em IP Pool, selecionamos o pool (tep01) de onde o Edge vai receber o endereço TEP. Esse IP é o “ponto de túnel” do Edge na malha NSX.

Com uplinks e TEP configurados, o Edge01 passa a ter:

  • um IP de management para controle;
  • e um IP TEP para participar do overlay.

Depois disso, basta clicar em Apply para concluir a criação do primeiro Edge Node dentro do Edge Cluster.

Etapa 5 (continuação) – Mapeando uplinks e TEP do Edge02
Etapa 5 (continuação) – Mapeando uplinks e TEP do Edge02
Etapa 5 (continuação) – Edge01 e Edge02 criados.
Etapa 6 – Configurando o uplink do Gateway (conectividade com a rede física)

Com o Edge01a e o Edge02b prontos, precisamos dizer como ele vai conversar com a rede física. É aqui que entram os Gateway Uplinks, que fazem a ponte entre o Tier-0/Tier-1 do NSX e o roteador/ToR do data center.

Nesta tela, configuramos o First Uplink do Edge:

  • Gateway Interface VLAN
    Informamos a VLAN usada na conexão entre o Edge e o switch físico (no exemplo, 70 configurado no MikroTik CRS304-4XG-IN).
    Essa VLAN deve estar configurada na porta do switch onde o host/Edge está conectado.
  • Gateway Interface CIDR Edge01a
    Definimos o endereço IP do lado NSX nessa VLAN (ex.: 10.10.70.2/24).
    O roteador físico terá um IP na mesma rede (por exemplo, 10.10.70.1/24), formando o par de roteamento.
  • Gateway Interface CIDR Edge01b
    Definimos o endereço IP do lado NSX nessa VLAN (ex.: 10.10.70.3/24).
    O roteador físico terá um IP na mesma rede (por exemplo, 10.10.70.1/24), formando o par de roteamento.

Opcionalmente, é possível configurar um Second Uplink para redundância ou para outro caminho de saída, mas para o lab um único uplink já é suficiente.

Com esse passo, fechamos a perna north-south: o Edge passa a ter um caminho claro até o roteador físico, por onde o tráfego das VPCs poderá chegar às demais redes da empresa e à internet.

Edge01a:

Edge01b:

Etapa 7 – Uplink do segundo Edge (resumo)

Esta etapa repete a lógica da Etapa 6, só que agora para o segundo Edge Node (edge01b), garantindo alta disponibilidade da saída para a rede física.

De forma resumida, fazemos:

  • Mesma VLAN de uplink usada no Edge01a
    • Gateway Interface VLAN: 70
      Assim, os dois Edges ficam no mesmo domínio de camada 2, falando com o mesmo roteador físico.
  • Novo IP na mesma sub-rede
    • Gateway Interface CIDR: 10.10.70.3/24
      Esse endereço complementa o par com o roteador (e com o IP do Edge01a, 10.10.70.2/24), permitindo que o Tier-0 use ambos os Edges em modo ativo/standby ou ativo/ativo, conforme o design.

Em resumo: a Etapa 7 apenas replica o uplink para o segundo Edge, fechando o par de borda que vai sustentar o tráfego das VPCs com redundância.

Etapa 8 – Amarrando o domínio de workload ao TRANSIT GATEWAY

Aqui nós “fechamos o desenho” de conectividade entre o Edge Cluster e o domínio de workload onde as VPCs vão rodar.

Os principais pontos dessa tela:

  • Gateway Name
    Criamos o gateway lógico (Tier-0/Tier-1 de transit gateway) – no exemplo, transit-gw.
    Ele será a borda padrão usada pelas VPCs para sair do ambiente.
  • High Availability Mode
    Selecionamos Active Standby, usando os dois Edges (edge01a e edge01b) em modo redundante: um ativo, outro em espera.
    É um modelo simples e suficiente para a maioria dos labs e muitos cenários de produção.
  • Routing Configuration
    Escolhemos o tipo de roteamento entre o NSX e o roteador físico:
    • No lab, foi usado Static, para simplificar;
    • Em ambientes maiores, normalmente entra BGP para automação de rotas. (Um post dedicado)
  • VPC Configuration
    • VPC External IP Blocks (10.10.10.0/24): faixa de IPs que será usada como “lado externo” das VPCs (NAT, IPs de publicação, etc.).
    • Private – Transit Gateway IP Blocks (172.16.10.0/24): rede interna usada pelo transite gateway para falar com as VPCs.

Com essa etapa, definimos quem é o gateway de saída, como ele roteia e quais faixas de IP serão usadas para expor as VPCs e conectar tudo ao resto da rede. Depois disso, basta avançar para a revisão e deployment das configurações.

Etapa 9 – Review and Deploy (fechando a conectividade)
Etapa 10 – Review and Deploy (fechando a conectividade)

Chegamos à tela final do assistente. Aqui o vSphere/NSX apresenta um resumo visual de todo o desenho:

  • Edge Cluster e Edge Nodes;
  • Uplinks até o ToR (VLAN 70);
  • redes de Management, Overlay/TEP e blocos de IP definidos para as VPCs.

Vale apenas conferir rapidamente nomes, VLANs e redes. Estando tudo de acordo com o planejamento, basta clicar em Deploy.

O wizard então cria o Edge Cluster, os Edge Nodes, o transit gateway e toda a conectividade north-south, deixando o ambiente pronto para começar a provisionar VPCs nas próximas etapas do artigo.

Resultado 🙂

Etapa 11 – Começando, finalmente, a criação da VPC.

Com a conectividade de rede já configurada (passos anteriores marcados como Completed), o vCenter libera o painel de Virtual Private Clouds.

Aqui fazemos duas coisas:

  • No inventário, selecionamos o VCF-Datacenter → Virtual Private Clouds;
  • No painel à direita, verificamos que o passo “Setup Network Connectivity” está concluído e clicamos em Add VPC.

A partir deste ponto, saímos da parte de “fundação de rede” e entramos, de fato, na provisão da primeira VPC – definindo nome, blocos de IP, segmentos e serviços que serão consumidos pelas workloads.

Etapa 12 – Criando a VPC e definindo o bloco de IP

Agora sim, criamos de fato a primeira VPC.

Na janela New Virtual Private Cloud:

  • Name – Damos um nome amigável para o time/projeto, no exemplo: VPC-WARRIOR-01.
  • Description – Campo opcional, bom para documentar dono da VPC, ambiente (lab, prod) etc.
  • Private – VPC IP CIDRs – Definimos o bloco de IP privado que será usado internamente pela VPC, aqui 172.20.79.0/24.
    • Esse range será “quebrado” depois em sub-redes/segmentos para as VMs.
    • Ele não pode se sobrepor às redes já usadas no seu ambiente (management, TEP, uplinks, outras VPCs).

Depois de revisar o nome e o CIDR, clicamos em Save.
Com isso, o objeto VPC-WARRIOR-01 é criado e já fica pronto para receber segmentos, regras de segurança e serviços de rede nas próximas etapas.

Etapa 13 – Criando A primeirA subnet dentro da VPC

Com a VPC-WARRIOR-01 criada, o próximo passo é entregar rede “de fato” para as VMs por meio de subnets.

No inventário, selecionamos a VPC (VCF-Datacenter → Virtual Private Clouds → VPC-WARRIOR-01) e, no canto superior direito, vamos em Actions → New Subnet.

Aqui estamos dizendo ao NSX:

“Dentro do bloco 172.20.79.0/24 dessa VPC, quero criar uma rede específica para workloads.”

Cada subnet que criarmos vai representar uma rede lógica (segmento) onde as VMs poderão ser conectadas – por exemplo, Frontend, Backend, DB, etc. Na próxima etapa, definimos o CIDR e os detalhes dessa primeira subnet.

Etapa 14 – Definindo as características da subnet PUBLIC VPC

Na tela Add Subnet | VPC-WARRIOR-01, criamos a primeira rede lógica da VPC, ajustando alguns pontos chave:

  • Name – Damos um nome descritivo para o subnet, por exemplo: vpc-01-public-sub-warrior.
  • Access Mode: Public – Indica que essa rede poderá ter saída/entrada via o gateway da VPC, ideal para workloads que precisam falar com outras redes ou internet.
  • Auto allocate Subnet CIDR from IP Blocks: Yes – O NSX escolhe automaticamente um bloco /CIDR livre dentro do range 10.10.10.0/24 definido para a VPC.
  • Subnet size: 64 – Cria um /26 (até 64 endereços), suficiente para um subnet de aplicação pequeno/médio.
  • Gateway Connectivity: Yes – Garante que o subnet terá rota padrão via gateway da VPC (senão seria uma rede isolada).
  • DHCP Config: DHCP Server – A própria VPC passa a entregar IP automaticamente para as VMs conectadas a esse subnet, sem precisar de servidor DHCP externo.

Com essas opções, estamos criando uma rede “publiczinha” pronta para uso, na qual as VMs já nascem com IP via DHCP e rota de saída pelo gateway da VPC. Na próxima etapa, só revisamos e concluímos a criação do subnet.

Etapa 15 – Definindo as características dA subnet PRIVADA da VPC

A segunda sub-rede, denominada  vpc-01-private-sub-warrior , que também terá o DHCP ativado, alocará endereços do CIDR privado da VPC (por exemplo, 172.20.79.0/26).

Etapa 16 – Se você estiver usando roteamento estático e quisermos permitir uma rota para o mundo externo, precisamos criar uma rota padrão para o nosso gateway T0.

Logue no NSX Manager e navegue para Networking -> Connectivity -> Tier-0 Gateways -> (Edit the selected T0) -> (Expand Routing) -> Static Routes -> Configure.

Rounting -> static routers.

Clique em -> Set Netx Hops
default” e a rede “0.0.0.0/0” e clique em “Next Hop”.

Insira o gateway da VLAN 70 (Uplink T0) e salve a configuração.

Etapa 17 – Crie um VIP do NSX para os seus nós de borda do NSX.

Isso pode ser útil se você precisar criar rotas estáticas adicionais. Navegue até  Networking -> Connectivity -> Tier-0 Gateways -> (Edit selected T0) -> High Availability VIP configuration  e selecione todas as interfaces dos nós de borda do NSX. Em seguida, especifique um endereço IP da VLAN 70 que atuará como seu VIP (por exemplo, 10.10.70.5/24). Se precisar criar rotas estáticas para acessar o bloco de IPs externos da sua VPC, você criará uma rota para uma das interfaces dos nós de borda do NSX ou, se já tiver um VIP do NSX criado, o endereço será o do VIP.

💡 Nota de design (produção vs lab)
Neste lab, usei blocos pequenos (10.10.10.0/24 e 172.20.79.0/24) apenas para facilitar o entendimento.
Em um ambiente real, com várias VPCs e sub-redes, o ideal é reservar blocos maiores, como:

  • 10.10.0.0/16 para IPs externos das VPCs
  • 172.20.0.0/16 para IPs privados das VPCs
    e então subdividir em /24 ou /26 por VPC e por subnet.
18 – Criando rota no Mikrotik para o bloco externo da VPC

Como definimos anteriormente, a VPC usa o bloco 10.10.10.0/24 como VPC External IP Block, e o Tier-0 possui um VIP de alta disponibilidade em 10.10.70.5 na VLAN 70.

No Mikrotik, criamos uma rota estática para que todo o tráfego destinado à rede 10.10.10.0/24 seja enviado para o VIP do Tier-0:

/ip route
add dst-address=10.10.10.0/24 gateway=10.10.70.5 comment="VPC External Block via NSX VIP"

Com isso, o caminho Mikrotik → NSX T0 → VPC Public fica corretamente estabelecido.
Nesse momento já é possível pingar uma VM da VPC a partir do Mikrotik, por exemplo:

19 – Configurando NAT (masquerade) no Mikrotik para saída à Internet

O próximo passo é permitir que o tráfego vindo da VPC (10.10.10.0/24) consiga sair para a Internet através do meu roteador doméstico (192.168.0.1).
Para isso, configuramos uma regra de masquerade no Mikrotik, na interface que está conectada à rede 192.168.0.0/24 (no meu caso, interface bridge):

/ip firewall nat
add chain=srcnat out-interface=bridge action=masquerade comment="NAT geral para Internet via 192.168.0.1"

Essa regra faz com que qualquer tráfego que saia pela initerface bridge tenha o endereço de origem reescrito para o IP do próprio Mikrotik nessa rede (192.168.0.250).
Do ponto de vista do roteador da operadora, todo o tráfego da VPC passa a vir “do Mikrotik”, o que simplifica o retorno.

CONCLUSÃO

Com isso, finalizamos a jornada desde a preparação do cluster com NSX, passando pela criação do Edge Cluster, uplinks e transit gateway, até a configuração da conectividade do domínio de workload. Em seguida, criamos a VPC-WARRIOR-01, definindo seu bloco de endereços privados. Por fim, provisionamos o primeiro subnet público da VPC, já com gateway e DHCP habilitados, pronto para receber workloads. A partir daqui, o próximo passo é começar a publicar VMs nessa VPC e evoluir para regras de segurança, NAT e cenários de consumo real.

REFLEXÃO DO DIA!

“Não te preocupes em chegar, mas sim em avançar. Ir avançando é estar chegando.”

Alejandro Jodorowsky

Avatar de Desconhecido

Publicado por virtualizandoaju

SOBRE O BLOG: Virtualizandoaju é o meu blog pessoal, visa a criação de tutoriais para uma ampla gama de soluções de data center. Temas populares incluem VMware vSphere, VMware vCenter, VMware vRealize e cloud.