Laboratório Hands-on Guiado: AZ-104 Microsoft Azure Administrator

Cenário

A Contoso Logística é uma empresa brasileira de transporte e armazenagem que opera centros de distribuição em São Paulo e no Rio de Janeiro. A empresa iniciou sua jornada de migração para a nuvem há seis meses e já possui uma subscription Azure ativa com um Resource Group de testes. O ambiente atual não possui redes virtuais configuradas, e todas as cargas de trabalho ainda dependem de acesso público direto pela internet, sem segmentação de rede, balanceamento de carga ou resolução DNS privada.

O objetivo deste laboratório é construir, do zero, toda a infraestrutura de rede Azure da Contoso Logística: redes virtuais segmentadas e emparelhadas, controle de tráfego com NSGs e rotas customizadas, acesso administrativo seguro via Bastion, integração privada com serviços PaaS, resolução DNS personalizada e balanceamento de carga para aplicações internas e públicas. Ao final, o ambiente deve estar pronto para receber cargas de trabalho de produção com conectividade segura, resiliente e auditável.

Pré-requisitos

Antes de iniciar a Fase 1, confirme ou crie os seguintes recursos:

Subscription Azure ativa com permissões de Owner ou Contributor no escopo da subscription.
Azure CLI instalada e autenticada (versão 2.50 ou superior). Execute az login e confirme a subscription correta com az account show.
Resource Group principal: crie o grupo de recursos que será utilizado em todo o laboratório.

Via Portal

Navegue até Portal Azure > Pesquise "Resource groups" > Clique em "Create" > Preencha:

Subscription: sua subscription ativa
Resource group: rg-contoso-lab
Region: East US 2
Clique em "Review + create" > "Create"

Via CLI

# Criar o Resource Group principal do laboratório
az group create \
  --name rg-contoso-lab \
  --location eastus2

Registro do provider Microsoft.Network: confirme que o provider está registrado.

az provider show --namespace Microsoft.Network --query "registrationState" -o tsv
# Saída esperada: Registered
# Se não estiver registrado:
az provider register --namespace Microsoft.Network

Registro do provider Microsoft.Storage (necessário para service endpoints na Fase 5):

az provider show --namespace Microsoft.Storage --query "registrationState" -o tsv

Tabela de Referência de Recursos

Recurso	Nome no lab	Região
Resource Group	rg-contoso-lab	East US 2
VNet Hub	vnet-hub-contoso	East US 2
Subnet Hub Default	snet-hub-default	East US 2
Subnet Hub Bastion	AzureBastionSubnet	East US 2
VNet Spoke SP	vnet-spoke-sp	East US 2
Subnet Spoke SP Workload	snet-sp-workload	East US 2
Subnet Spoke SP PaaS	snet-sp-paas	East US 2
VNet Spoke RJ	vnet-spoke-rj	East US 2
Subnet Spoke RJ Workload	snet-rj-workload	East US 2
Peering Hub-SP	peer-hub-to-sp / peer-sp-to-hub	East US 2
Peering Hub-RJ	peer-hub-to-rj / peer-rj-to-hub	East US 2
NSG Workload SP	nsg-sp-workload	East US 2
NSG Workload RJ	nsg-rj-workload	East US 2
ASG Web Servers	asg-web-servers	East US 2
ASG DB Servers	asg-db-servers	East US 2
Public IP (Bastion)	pip-bastion-hub	East US 2
Public IP (LB Externo)	pip-lb-external	East US 2
Azure Bastion	bastion-hub-contoso	East US 2
Route Table	rt-spoke-sp	East US 2
VM Hub (NVA simulada)	vm-nva-hub	East US 2
VM Spoke SP	vm-web-sp	East US 2
VM Spoke RJ	vm-web-rj	East US 2
Storage Account	stcontoso[sufixo]	East US 2
Private Endpoint (Storage)	pe-storage-contoso	East US 2
DNS Zone Privada	privatelink.blob.core.windows.net	Global
DNS Zone Pública	contoso-lab.com	Global
Load Balancer Interno	lb-internal-sp	East US 2
Load Balancer Público	lb-external-rj	East US 2

Fases do Laboratório

O laboratório está organizado em 7 fases progressivas. Cada fase constrói sobre os recursos criados anteriormente, formando uma infraestrutura de rede completa ao final.

Fase 1 — Redes Virtuais, Sub-redes e Endereços IP Públicos

Esta fase cobre os objetivos: Create and configure virtual networks and subnets e Configure public IP addresses. Você criará a topologia hub-spoke com três VNets, suas sub-redes e os endereços IP públicos necessários para fases posteriores.

Tarefa 1.1 — Criar a VNet Hub e suas sub-redes

A VNet Hub funcionará como o ponto central de conectividade da Contoso Logística, hospedando o Azure Bastion e a VM que simulará um Network Virtual Appliance (NVA). Você criará a VNet com duas sub-redes: uma padrão e a sub-rede obrigatória do Bastion.

Via Portal

Navegue até Portal Azure > Pesquise "Virtual networks" > Clique em "Create"
Na aba Basics:
- Subscription: sua subscription
- Resource group: rg-contoso-lab
- Virtual network name: vnet-hub-contoso
- Region: East US 2
Clique em "Next" até a aba IP Addresses
Em IPv4 address space, defina o espaço de endereçamento como 10.0.0.0/16
Clique em "Add a subnet":
- Subnet name: snet-hub-default
- Subnet address range: 10.0.1.0/24
- Clique em "Add"
Clique em "Add a subnet" novamente:
- Subnet name: AzureBastionSubnet
- Subnet address range: 10.0.2.0/26
- Clique em "Add"
Clique em "Review + create" > "Create"

Via CLI

# Criar a VNet Hub com o espaço de endereçamento principal
az network vnet create \
  --resource-group rg-contoso-lab \
  --name vnet-hub-contoso \
  --address-prefix 10.0.0.0/16 \
  --subnet-name snet-hub-default \
  --subnet-prefixes 10.0.1.0/24 \
  --location eastus2

# Criar a sub-rede obrigatória do Bastion (mínimo /26)
az network vnet subnet create \
  --resource-group rg-contoso-lab \
  --vnet-name vnet-hub-contoso \
  --name AzureBastionSubnet \
  --address-prefixes 10.0.2.0/26

A VNet Hub agora possui o espaço 10.0.0.0/16 com duas sub-redes: snet-hub-default para cargas de trabalho gerais e AzureBastionSubnet com o tamanho mínimo exigido pelo serviço Bastion.

Tarefa 1.2 — Criar as VNets Spoke SP e Spoke RJ

As VNets Spoke representam os centros de distribuição de São Paulo e Rio de Janeiro. Cada uma terá sub-redes dedicadas a cargas de trabalho e, no caso da Spoke SP, uma sub-rede adicional para integração com serviços PaaS.

Via Portal

Repita o processo de criação de VNet para vnet-spoke-sp:
- Virtual network name: vnet-spoke-sp
- Address space: 10.1.0.0/16
- Subnet 1: snet-sp-workload com range 10.1.1.0/24
- Subnet 2: snet-sp-paas com range 10.1.2.0/24
Repita para vnet-spoke-rj:
- Virtual network name: vnet-spoke-rj
- Address space: 10.2.0.0/16
- Subnet 1: snet-rj-workload com range 10.2.1.0/24

Via CLI

# Criar VNet Spoke SP com sub-rede de workload
az network vnet create \
  --resource-group rg-contoso-lab \
  --name vnet-spoke-sp \
  --address-prefix 10.1.0.0/16 \
  --subnet-name snet-sp-workload \
  --subnet-prefixes 10.1.1.0/24 \
  --location eastus2

# Adicionar sub-rede PaaS na Spoke SP
az network vnet subnet create \
  --resource-group rg-contoso-lab \
  --vnet-name vnet-spoke-sp \
  --name snet-sp-paas \
  --address-prefixes 10.1.2.0/24

# Criar VNet Spoke RJ com sub-rede de workload
az network vnet create \
  --resource-group rg-contoso-lab \
  --name vnet-spoke-rj \
  --address-prefix 10.2.0.0/16 \
  --subnet-name snet-rj-workload \
  --subnet-prefixes 10.2.1.0/24 \
  --location eastus2

Ao final desta tarefa, a topologia possui três VNets isoladas com espaços de endereçamento distintos e sem sobreposição, condição obrigatória para o peering que será configurado na Fase 2.

Tarefa 1.3 — Criar e configurar endereços IP públicos

Você criará dois endereços IP públicos: um para o Azure Bastion (obrigatoriamente SKU Standard) e outro para o Load Balancer externo que será configurado na Fase 7.

Via Portal

Navegue até Portal Azure > Pesquise "Public IP addresses" > Clique em "Create"
Para o IP do Bastion:
- Name: pip-bastion-hub
- SKU: Standard
- Tier: Regional
- Assignment: Static
- Resource group: rg-contoso-lab
- Region: East US 2
- Clique em "Create"
Repita para o IP do Load Balancer externo:
- Name: pip-lb-external
- SKU: Standard
- Assignment: Static
- Demais campos iguais ao anterior

Via CLI

# IP público para o Bastion (Standard SKU obrigatório)
az network public-ip create \
  --resource-group rg-contoso-lab \
  --name pip-bastion-hub \
  --sku Standard \
  --allocation-method Static \
  --location eastus2

# IP público para o Load Balancer externo
az network public-ip create \
  --resource-group rg-contoso-lab \
  --name pip-lb-external \
  --sku Standard \
  --allocation-method Static \
  --location eastus2

Ambos os IPs utilizam SKU Standard com alocação estática. O SKU Standard é obrigatório para o Bastion e recomendado para Load Balancers Standard. Diferentemente do SKU Basic, o Standard é zone-aware e seguro por padrão (nega tráfego inbound até que um NSG permita).

Tarefa 1.4 — Verificar a topologia e diagnosticar sobreposição de endereços

Antes de prosseguir para o peering, é necessário confirmar que não existe sobreposição entre os espaços de endereçamento das três VNets, pois isso impediria a criação do peering.

Via Portal

Navegue até Portal Azure > Pesquise "Virtual networks"
Para cada VNet (vnet-hub-contoso, vnet-spoke-sp, vnet-spoke-rj), clique na VNet > Selecione "Address space" no menu lateral
Confirme que os espaços são, respectivamente: 10.0.0.0/16, 10.1.0.0/16, 10.2.0.0/16
Confirme que nenhum espaço se sobrepõe aos demais

Via CLI

# Listar os address spaces de todas as VNets do lab
az network vnet list \
  --resource-group rg-contoso-lab \
  --query "[].{Name:name, AddressSpace:addressSpace.addressPrefixes}" \
  -o table

A saída deve exibir três VNets com espaços 10.0.0.0/16, 10.1.0.0/16 e 10.2.0.0/16. Se algum espaço estiver duplicado ou sobreposto, corrija antes de avançar para a Fase 2.

Fase 2 — Peering e Conectividade entre VNets

Esta fase cobre os objetivos: Create and configure virtual network peering e Troubleshoot network connectivity. Você estabelecerá o peering bidirecional entre a VNet Hub e cada Spoke, e diagnosticará cenários de falha de conectividade.

Os recursos utilizados desta fase anterior são: vnet-hub-contoso, vnet-spoke-sp e vnet-spoke-rj.

Tarefa 2.1 — Configurar peering Hub para Spoke SP (bidirecional)

O peering deve ser criado em ambas as direções: da Hub para a Spoke SP e da Spoke SP para a Hub. Apenas um lado configurado resulta em status "Initiated" e conectividade inexistente.

Via Portal

Navegue até vnet-hub-contoso > Selecione "Peerings" no menu lateral > Clique em "Add"
Preencha a seção This virtual network:
- Peering link name: peer-hub-to-sp
- Traffic to remote virtual network: Allow
- Traffic forwarded from remote virtual network: Allow
- Virtual network gateway or Route Server: None
Preencha a seção Remote virtual network:
- Peering link name: peer-sp-to-hub
- Virtual network: vnet-spoke-sp
- Traffic to remote virtual network: Allow
- Traffic forwarded from remote virtual network: Allow
Clique em "Add"

Via CLI

# Obter o resource ID da VNet Spoke SP
SPOKE_SP_ID=$(az network vnet show \
  --resource-group rg-contoso-lab \
  --name vnet-spoke-sp \
  --query id -o tsv)

# Criar peering da Hub para Spoke SP
az network vnet peering create \
  --resource-group rg-contoso-lab \
  --name peer-hub-to-sp \
  --vnet-name vnet-hub-contoso \
  --remote-vnet $SPOKE_SP_ID \
  --allow-vnet-access \
  --allow-forwarded-traffic

# Obter o resource ID da VNet Hub
HUB_ID=$(az network vnet show \
  --resource-group rg-contoso-lab \
  --name vnet-hub-contoso \
  --query id -o tsv)

# Criar peering da Spoke SP para Hub
az network vnet peering create \
  --resource-group rg-contoso-lab \
  --name peer-sp-to-hub \
  --vnet-name vnet-spoke-sp \
  --remote-vnet $HUB_ID \
  --allow-vnet-access \
  --allow-forwarded-traffic

Quando ambos os lados do peering estão configurados, o status muda de "Initiated" para "Connected". O tráfego entre as VNets flui diretamente pela backbone da Microsoft, sem passar pela internet pública.

Tarefa 2.2 — Configurar peering Hub para Spoke RJ

Repita o processo para conectar a Hub à Spoke RJ. Este peering é necessário para que o tráfego entre SP e RJ possa transitar pela Hub (modelo hub-spoke com roteamento centralizado, configurado na Fase 3).

Via Portal

Navegue até vnet-hub-contoso > Selecione "Peerings" > Clique em "Add"
Configure com os mesmos parâmetros da Tarefa 2.1, alterando:
- Peering link name (this): peer-hub-to-rj
- Peering link name (remote): peer-rj-to-hub
- Virtual network (remote): vnet-spoke-rj
Clique em "Add"

Via CLI

# Obter o resource ID da VNet Spoke RJ
SPOKE_RJ_ID=$(az network vnet show \
  --resource-group rg-contoso-lab \
  --name vnet-spoke-rj \
  --query id -o tsv)

# Criar peering bidirecional Hub <-> Spoke RJ
az network vnet peering create \
  --resource-group rg-contoso-lab \
  --name peer-hub-to-rj \
  --vnet-name vnet-hub-contoso \
  --remote-vnet $SPOKE_RJ_ID \
  --allow-vnet-access \
  --allow-forwarded-traffic

az network vnet peering create \
  --resource-group rg-contoso-lab \
  --name peer-rj-to-hub \
  --vnet-name vnet-spoke-rj \
  --remote-vnet $HUB_ID \
  --allow-vnet-access \
  --allow-forwarded-traffic

A VNet Hub agora está emparelhada com ambas as Spokes. Note que o peering não é transitivo: Spoke SP e Spoke RJ não se comunicam diretamente entre si, mesmo estando ambas conectadas à Hub. Essa conectividade transitiva será resolvida com rotas customizadas na Fase 3.

Tarefa 2.3 — Validar o status do peering e diagnosticar falha simulada

Você verificará o estado de todos os peerings e simulará uma falha para entender o comportamento de diagnóstico do Azure.

Via Portal

Navegue até vnet-hub-contoso > Selecione "Peerings"
Confirme que ambos os peerings (peer-hub-to-sp e peer-hub-to-rj) exibem Peering status: Connected
Navegue até vnet-spoke-sp > Selecione "Peerings"
Confirme que peer-sp-to-hub também exibe Connected

Simulação de falha: agora remova temporariamente um lado do peering para observar o efeito:

Navegue até vnet-spoke-sp > Peerings > Clique em peer-sp-to-hub > Clique em "Delete" > confirme
Retorne a vnet-hub-contoso > Peerings e observe que peer-hub-to-sp mudou para Disconnected
Esse estado unilateral impede qualquer tráfego entre as VNets

Restauração: recrie o peering peer-sp-to-hub conforme a Tarefa 2.1 para restaurar o status Connected em ambos os lados.

Via CLI

# Verificar status de todos os peerings da Hub
az network vnet peering list \
  --resource-group rg-contoso-lab \
  --vnet-name vnet-hub-contoso \
  --query "[].{Name:name, Status:peeringState}" \
  -o table

# Simular falha: deletar o lado Spoke SP do peering
az network vnet peering delete \
  --resource-group rg-contoso-lab \
  --vnet-name vnet-spoke-sp \
  --name peer-sp-to-hub

# Verificar que o lado Hub ficou Disconnected
az network vnet peering show \
  --resource-group rg-contoso-lab \
  --vnet-name vnet-hub-contoso \
  --name peer-hub-to-sp \
  --query peeringState -o tsv
# Saída esperada: Disconnected

# Restaurar o peering
az network vnet peering create \
  --resource-group rg-contoso-lab \
  --name peer-sp-to-hub \
  --vnet-name vnet-spoke-sp \
  --remote-vnet $HUB_ID \
  --allow-vnet-access \
  --allow-forwarded-traffic

# Confirmar restauração
az network vnet peering show \
  --resource-group rg-contoso-lab \
  --vnet-name vnet-hub-contoso \
  --name peer-hub-to-sp \
  --query peeringState -o tsv
# Saída esperada: Connected

Este exercício demonstra que o peering é um recurso bilateral: a exclusão de qualquer um dos lados invalida imediatamente a conectividade. O diagnóstico rápido envolve verificar o peeringState em ambos os lados da conexão.

Fase 3 — Rotas Definidas pelo Usuário (UDR) e NVA Simulada

Esta fase cobre o objetivo: Configure user-defined routes. Você criará uma VM para simular um Network Virtual Appliance na Hub e configurará uma Route Table para forçar o tráfego da Spoke SP a passar pela NVA antes de alcançar a Spoke RJ.

Os recursos utilizados das fases anteriores são: vnet-hub-contoso (sub-rede snet-hub-default), vnet-spoke-sp (sub-rede snet-sp-workload) e os peerings configurados na Fase 2.

Tarefa 3.1 — Criar a VM NVA na Hub e habilitar IP forwarding

A VM na Hub simulará um NVA. Para que o Azure permita que ela encaminhe pacotes que não são destinados ao seu próprio IP, é necessário habilitar o IP forwarding tanto na NIC quanto no sistema operacional.

Via Portal

Navegue até Portal Azure > Pesquise "Virtual machines" > Clique em "Create" > "Azure virtual machine"
Na aba Basics:
- Resource group: rg-contoso-lab
- Virtual machine name: vm-nva-hub
- Region: East US 2
- Image: Ubuntu Server 24.04 LTS
- Size: Standard_B1s (suficiente para o lab)
- Authentication type: Password
- Username: azureadmin
- Password: escolha uma senha forte
Na aba Networking:
- Virtual network: vnet-hub-contoso
- Subnet: snet-hub-default
- Public IP: None (acesso será via Bastion)
- NIC network security group: None (NSG será configurado separadamente)
Clique em "Review + create" > "Create"
Após a criação, navegue até a VM > Selecione "Networking" > Clique na interface de rede
Selecione "IP configurations" > Habilite "IP forwarding" > Clique em "Save"

Via CLI

# Criar a VM NVA (sem IP público, acesso via Bastion)
az vm create \
  --resource-group rg-contoso-lab \
  --name vm-nva-hub \
  --image Ubuntu2404 \
  --size Standard_B1s \
  --vnet-name vnet-hub-contoso \
  --subnet snet-hub-default \
  --public-ip-address "" \
  --admin-username azureadmin \
  --admin-password 'SuaSenhaForte123!' \
  --nsg "" \
  --location eastus2

# Obter o nome da NIC criada
NVA_NIC=$(az vm show \
  --resource-group rg-contoso-lab \
  --name vm-nva-hub \
  --query "networkProfile.networkInterfaces[0].id" -o tsv | xargs basename)

# Habilitar IP forwarding na NIC
az network nic update \
  --resource-group rg-contoso-lab \
  --name $NVA_NIC \
  --ip-forwarding true

# Obter o IP privado da NVA (necessário para a UDR)
NVA_PRIVATE_IP=$(az vm show \
  --resource-group rg-contoso-lab \
  --name vm-nva-hub \
  --show-details \
  --query privateIps -o tsv)

echo "IP privado da NVA: $NVA_PRIVATE_IP"

O IP forwarding na NIC permite que o Azure entregue pacotes destinados a outros IPs para esta VM. Sem essa configuração, o Azure descarta silenciosamente pacotes cujo destino não corresponde ao IP da NIC. Posteriormente, após configurar o Bastion, será necessário habilitar o forwarding também no SO da VM com sysctl.

Tarefa 3.2 — Criar a Route Table e associar à sub-rede Spoke SP

Você criará uma User Defined Route (UDR) que redireciona todo o tráfego destinado à Spoke RJ (10.2.0.0/16) para o IP privado da NVA na Hub, forçando inspeção centralizada.

Via Portal

Navegue até Portal Azure > Pesquise "Route tables" > Clique em "Create"
Preencha:
- Resource group: rg-contoso-lab
- Region: East US 2
- Name: rt-spoke-sp
- Propagate gateway routes: Yes
Clique em "Review + create" > "Create"
Após a criação, navegue até rt-spoke-sp > Selecione "Routes" > Clique em "Add"
Preencha:
- Route name: route-to-rj-via-nva
- Destination type: IP Addresses
- Destination IP addresses/CIDR ranges: 10.2.0.0/16
- Next hop type: Virtual appliance
- Next hop address: o IP privado da VM NVA (ex: 10.0.1.4)
Clique em "Add"
Selecione "Subnets" no menu lateral > Clique em "Associate"
Selecione:
- Virtual network: vnet-spoke-sp
- Subnet: snet-sp-workload
Clique em "OK"

Via CLI

# Criar a Route Table
az network route-table create \
  --resource-group rg-contoso-lab \
  --name rt-spoke-sp \
  --location eastus2 \
  --disable-bgp-route-propagation false

# Adicionar a rota customizada apontando para a NVA
az network route-table route create \
  --resource-group rg-contoso-lab \
  --route-table-name rt-spoke-sp \
  --name route-to-rj-via-nva \
  --address-prefix 10.2.0.0/16 \
  --next-hop-type VirtualAppliance \
  --next-hop-ip-address $NVA_PRIVATE_IP

# Associar a Route Table à sub-rede de workload da Spoke SP
az network vnet subnet update \
  --resource-group rg-contoso-lab \
  --vnet-name vnet-spoke-sp \
  --name snet-sp-workload \
  --route-table rt-spoke-sp

Com essa configuração, qualquer tráfego originado em snet-sp-workload com destino a 10.2.0.0/16 será redirecionado para a NVA antes de seguir para a Spoke RJ. Isso permite inspeção, logging e filtragem centralizada.

Tarefa 3.3 — Verificar rotas efetivas e identificar conflitos

Antes de testar o roteamento de ponta a ponta (o que requer VMs nas Spokes, criadas em fases posteriores), valide que as rotas efetivas na sub-rede Spoke SP refletem a UDR configurada.

Via Portal

Navegue até Portal Azure > Pesquise "Network Watcher" > Selecione "Effective routes" (em Network diagnostic tools)
Selecione:
- Subscription: sua subscription
- Resource group: rg-contoso-lab
- Virtual machine: vm-web-sp (quando disponível) ou consulte diretamente a NIC
Localize a rota para 10.2.0.0/16 e confirme que o Next hop type é Virtual Appliance e o Next hop IP corresponde ao IP da NVA

Via CLI

# Listar rotas efetivas (substitua pelo nome da NIC relevante)
az network nic show-effective-route-table \
  --resource-group rg-contoso-lab \
  --name $NVA_NIC \
  -o table

Na saída, observe que existem rotas de sistema (System) para os espaços de endereçamento peered e a rota customizada (User) para 10.2.0.0/16. A rota User tem precedência sobre rotas System para o mesmo prefixo, pois UDRs sempre sobrescrevem rotas de sistema quando o prefixo é mais específico ou igual.

Fase 4 — NSGs, ASGs e Segurança de Rede

Esta fase cobre os objetivos: Create and configure network security groups (NSGs) and application security groups, Evaluate effective security rules in NSGs e Implement Azure Bastion. Você criará NSGs com regras granulares, ASGs para agrupar VMs por função, implementará o Bastion para acesso seguro e avaliará regras efetivas.

Os recursos utilizados das fases anteriores são: todas as VNets, sub-redes, a VM NVA e os IPs públicos.

Tarefa 4.1 — Criar Application Security Groups

Os ASGs permitem agrupar VMs por função lógica (servidores web, servidores de banco) e referenciá-las em regras de NSG sem precisar especificar IPs individuais.

Via Portal

Navegue até Portal Azure > Pesquise "Application security groups" > Clique em "Create"
Preencha:
- Resource group: rg-contoso-lab
- Name: asg-web-servers
- Region: East US 2
Clique em "Review + create" > "Create"
Repita para:
- Name: asg-db-servers

Via CLI

# Criar ASG para servidores web
az network asg create \
  --resource-group rg-contoso-lab \
  --name asg-web-servers \
  --location eastus2

# Criar ASG para servidores de banco de dados
az network asg create \
  --resource-group rg-contoso-lab \
  --name asg-db-servers \
  --location eastus2

Os ASGs foram criados, mas ainda não estão associados a nenhuma NIC. A associação ocorrerá quando as VMs forem criadas nas tarefas seguintes.

Tarefa 4.2 — Criar NSGs com regras baseadas em ASGs

Você criará dois NSGs e configurará regras que utilizam os ASGs como source/destination, em vez de endereços IP estáticos.

Via Portal

Navegue até Portal Azure > Pesquise "Network security groups" > Clique em "Create"
Preencha:
- Resource group: rg-contoso-lab
- Name: nsg-sp-workload
- Region: East US 2
Clique em "Review + create" > "Create"
Após a criação, navegue até nsg-sp-workload > Selecione "Inbound security rules" > Clique em "Add"
Regra 1 (permitir HTTP nos web servers):
- Source: Application security group > asg-web-servers
- Source port ranges: *
- Destination: Application security group > asg-web-servers
- Destination port ranges: 80,443
- Protocol: TCP
- Action: Allow
- Priority: 100
- Name: Allow-HTTP-HTTPS-Web
Clique em "Add" e adicione Regra 2 (permitir tráfego dos web servers para os DB servers na porta 3306):
- Source: Application security group > asg-web-servers
- Destination: Application security group > asg-db-servers
- Destination port ranges: 3306
- Protocol: TCP
- Action: Allow
- Priority: 110
- Name: Allow-Web-to-DB
Regra 3 (negar todo o restante do tráfego inbound):
- Source: Any
- Destination: Any
- Destination port ranges: *
- Protocol: Any
- Action: Deny
- Priority: 4000
- Name: Deny-All-Inbound
Associe o NSG à sub-rede: Selecione "Subnets" > "Associate" > Virtual network: vnet-spoke-sp > Subnet: snet-sp-workload
Repita a criação do NSG nsg-rj-workload e associe-o a snet-rj-workload na vnet-spoke-rj, com regras equivalentes

Via CLI

# Criar NSG para Spoke SP
az network nsg create \
  --resource-group rg-contoso-lab \
  --name nsg-sp-workload \
  --location eastus2

# Regra: permitir HTTP/HTTPS para web servers
az network nsg rule create \
  --resource-group rg-contoso-lab \
  --nsg-name nsg-sp-workload \
  --name Allow-HTTP-HTTPS-Web \
  --priority 100 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-asgs asg-web-servers \
  --destination-asgs asg-web-servers \
  --destination-port-ranges 80 443

# Regra: permitir web servers acessarem DB servers na porta 3306
az network nsg rule create \
  --resource-group rg-contoso-lab \
  --nsg-name nsg-sp-workload \
  --name Allow-Web-to-DB \
  --priority 110 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-asgs asg-web-servers \
  --destination-asgs asg-db-servers \
  --destination-port-ranges 3306

# Regra: negar todo o restante
az network nsg rule create \
  --resource-group rg-contoso-lab \
  --nsg-name nsg-sp-workload \
  --name Deny-All-Inbound \
  --priority 4000 \
  --direction Inbound \
  --access Deny \
  --protocol '*' \
  --source-address-prefixes '*' \
  --destination-address-prefixes '*' \
  --destination-port-ranges '*'

# Associar NSG à sub-rede
az network vnet subnet update \
  --resource-group rg-contoso-lab \
  --vnet-name vnet-spoke-sp \
  --name snet-sp-workload \
  --network-security-group nsg-sp-workload

# Repetir para Spoke RJ
az network nsg create \
  --resource-group rg-contoso-lab \
  --name nsg-rj-workload \
  --location eastus2

az network nsg rule create \
  --resource-group rg-contoso-lab \
  --nsg-name nsg-rj-workload \
  --name Allow-HTTP-HTTPS-Web \
  --priority 100 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-asgs asg-web-servers \
  --destination-asgs asg-web-servers \
  --destination-port-ranges 80 443

az network nsg rule create \
  --resource-group rg-contoso-lab \
  --nsg-name nsg-rj-workload \
  --name Deny-All-Inbound \
  --priority 4000 \
  --direction Inbound \
  --access Deny \
  --protocol '*' \
  --source-address-prefixes '*' \
  --destination-address-prefixes '*' \
  --destination-port-ranges '*'

az network vnet subnet update \
  --resource-group rg-contoso-lab \
  --vnet-name vnet-spoke-rj \
  --name snet-rj-workload \
  --network-security-group nsg-rj-workload

Os NSGs agora controlam o tráfego nas sub-redes de workload. A regra Deny-All com prioridade 4000 garante que apenas o tráfego explicitamente permitido por regras de prioridade mais alta será aceito. As regras de sistema do Azure (prioridade 65000+) continuam ativas abaixo dessa camada.

Tarefa 4.3 — Implantar o Azure Bastion e criar VMs de teste

O Azure Bastion fornece acesso RDP/SSH seguro às VMs via portal, eliminando a necessidade de IPs públicos nas VMs. Você implantará o Bastion na Hub e criará VMs nas Spokes para testes de conectividade.

Via Portal

Navegue até Portal Azure > Pesquise "Bastions" > Clique em "Create"
Preencha:
- Resource group: rg-contoso-lab
- Name: bastion-hub-contoso
- Region: East US 2
- Virtual network: vnet-hub-contoso
- Subnet: AzureBastionSubnet (preenchido automaticamente)
- Public IP address: pip-bastion-hub
Clique em "Review + create" > "Create" (o provisionamento leva de 5 a 10 minutos)

Enquanto o Bastion é provisionado, crie as VMs de teste:

Crie a VM vm-web-sp:
- Resource group: rg-contoso-lab
- Name: vm-web-sp
- Region: East US 2
- Image: Ubuntu Server 24.04 LTS
- Size: Standard_B1s
- VNet: vnet-spoke-sp
- Subnet: snet-sp-workload
- Public IP: None
- NIC NSG: None (já há NSG na sub-rede)
Crie a VM vm-web-rj:
- Mesmos parâmetros, alterando para VNet vnet-spoke-rj, Subnet snet-rj-workload

Via CLI

# Criar o Azure Bastion
az network bastion create \
  --resource-group rg-contoso-lab \
  --name bastion-hub-contoso \
  --public-ip-address pip-bastion-hub \
  --vnet-name vnet-hub-contoso \
  --location eastus2 \
  --sku Basic

# Criar VM na Spoke SP
az vm create \
  --resource-group rg-contoso-lab \
  --name vm-web-sp \
  --image Ubuntu2404 \
  --size Standard_B1s \
  --vnet-name vnet-spoke-sp \
  --subnet snet-sp-workload \
  --public-ip-address "" \
  --admin-username azureadmin \
  --admin-password 'SuaSenhaForte123!' \
  --nsg "" \
  --location eastus2

# Criar VM na Spoke RJ
az vm create \
  --resource-group rg-contoso-lab \
  --name vm-web-rj \
  --image Ubuntu2404 \
  --size Standard_B1s \
  --vnet-name vnet-spoke-rj \
  --subnet snet-rj-workload \
  --public-ip-address "" \
  --admin-username azureadmin \
  --admin-password 'SuaSenhaForte123!' \
  --nsg "" \
  --location eastus2

Após o provisionamento, associe as NICs das VMs aos ASGs:

# Obter NIC da vm-web-sp
SP_NIC=$(az vm show --resource-group rg-contoso-lab --name vm-web-sp \
  --query "networkProfile.networkInterfaces[0].id" -o tsv | xargs basename)

# Associar ao ASG web-servers
az network nic ip-config update \
  --resource-group rg-contoso-lab \
  --nic-name $SP_NIC \
  --name ipconfig1 \
  --application-security-groups asg-web-servers

# Repetir para vm-web-rj
RJ_NIC=$(az vm show --resource-group rg-contoso-lab --name vm-web-rj \
  --query "networkProfile.networkInterfaces[0].id" -o tsv | xargs basename)

az network nic ip-config update \
  --resource-group rg-contoso-lab \
  --nic-name $RJ_NIC \
  --name ipconfig1 \
  --application-security-groups asg-web-servers

O Bastion permite conectar-se às VMs nas Spokes via peering. Como o peering entre Hub e Spokes está ativo, o Bastion na Hub consegue alcançar VMs em qualquer Spoke sem necessidade de IPs públicos individuais.

Tarefa 4.4 — Avaliar regras efetivas do NSG e diagnosticar bloqueio

Nesta tarefa você verificará as regras efetivas aplicadas à NIC de uma VM e diagnosticará um cenário onde o tráfego é bloqueado inesperadamente pela regra Deny-All.

Via Portal

Navegue até vm-web-sp > Selecione "Networking" > Observe a aba "Effective security rules"
Localize a regra Deny-All-Inbound com prioridade 4000
Observe as regras de sistema com prioridade 65000+ (AllowVnetInBound, AllowAzureLoadBalancerInBound, DenyAllInBound)
Teste com o Network Watcher: Navegue até "Network Watcher" > Selecione "IP flow verify"
Preencha:
- Virtual machine: vm-web-sp
- Direction: Inbound
- Protocol: TCP
- Local port: 22
- Remote IP address: 10.1.1.5 (IP fictício na mesma sub-rede)
- Remote port: 50000
Clique em "Check"
O resultado deve indicar que o tráfego é negado pela regra Deny-All-Inbound, pois não há regra explícita permitindo SSH na porta 22

Via CLI

# Verificar regras efetivas da NIC
az network nic list-effective-nsg \
  --resource-group rg-contoso-lab \
  --name $SP_NIC

# Testar com IP Flow Verify (substitua o IP local pelo IP real da VM)
SP_PRIVATE_IP=$(az vm show --resource-group rg-contoso-lab \
  --name vm-web-sp --show-details --query privateIps -o tsv)

az network watcher test-ip-flow \
  --resource-group rg-contoso-lab \
  --vm vm-web-sp \
  --direction Inbound \
  --protocol TCP \
  --local $SP_PRIVATE_IP:22 \
  --remote 10.1.1.5:50000
# Saída esperada: Access: Deny, Rule: Deny-All-Inbound

O IP Flow Verify é a ferramenta principal de diagnóstico de NSG. Ele informa exatamente qual regra está permitindo ou bloqueando o fluxo, eliminando a necessidade de revisar manualmente todas as regras e suas prioridades.

Tarefa 4.5 — Testar conectividade via Bastion e habilitar IP forwarding no SO

Conecte-se à VM NVA via Bastion e habilite o IP forwarding no sistema operacional, completando a configuração iniciada na Fase 3.

Via Portal

Navegue até vm-nva-hub > Clique em "Connect" > Selecione "Connect via Bastion"
Preencha as credenciais (azureadmin / sua senha)
No terminal SSH que abrir no navegador, execute:

# Verificar estado atual do IP forwarding no SO
sysctl net.ipv4.ip_forward
# Saída esperada: net.ipv4.ip_forward = 0

# Habilitar IP forwarding
sudo sysctl -w net.ipv4.ip_forward=1

# Tornar persistente
echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

# Confirmar
sysctl net.ipv4.ip_forward
# Saída esperada: net.ipv4.ip_forward = 1

Teste a conectividade da NVA para a VM na Spoke SP:

ping -c 4 10.1.1.4
# Substitua pelo IP real da vm-web-sp

O IP forwarding está agora habilitado em ambas as camadas (NIC Azure e SO Linux). Pacotes trafegando pela rota customizada da Fase 3 serão encaminhados pela NVA em vez de descartados.

Fase 5 — Service Endpoints e Private Endpoints para PaaS

Esta fase cobre os objetivos: Configure service endpoints for Azure PaaS e Configure private endpoints for Azure PaaS. Você configurará o acesso a um Storage Account usando ambas as abordagens e comparará os efeitos de cada uma.

Os recursos utilizados das fases anteriores são: vnet-spoke-sp (sub-redes snet-sp-workload e snet-sp-paas), NSGs e VMs.

Tarefa 5.1 — Criar o Storage Account e verificar acesso público

Antes de configurar os endpoints, crie um Storage Account e confirme que ele é acessível publicamente por padrão.

Via Portal

Navegue até Portal Azure > Pesquise "Storage accounts" > Clique em "Create"
Preencha:
- Resource group: rg-contoso-lab
- Storage account name: stcontoso seguido de um sufixo único (ex: stcontoso2026lab)
- Region: East US 2
- Performance: Standard
- Redundancy: LRS
Na aba Networking:
- Network access: Enabled from all networks (padrão)
Clique em "Review + create" > "Create"
Após a criação, navegue até o Storage Account > Selecione "Containers" > Crie um container chamado dados-teste com acesso Private
Faça upload de um arquivo de texto pequeno para o container

Via CLI

# Criar o Storage Account (nome deve ser globalmente único)
STORAGE_NAME="stcontoso$(date +%s | tail -c 6)"

az storage account create \
  --resource-group rg-contoso-lab \
  --name $STORAGE_NAME \
  --location eastus2 \
  --sku Standard_LRS \
  --kind StorageV2

# Criar um container de teste
az storage container create \
  --account-name $STORAGE_NAME \
  --name dados-teste \
  --auth-mode login

echo "Storage Account criado: $STORAGE_NAME"

Neste momento, o Storage Account aceita conexões de qualquer rede, incluindo a internet pública. Nas próximas tarefas, você restringirá esse acesso.

Tarefa 5.2 — Configurar Service Endpoint na sub-rede de workload

O Service Endpoint mantém o tráfego entre a VNet e o serviço PaaS na rede de backbone da Microsoft, mas o Storage Account continua tendo um endpoint público (acessível via IP público). A restrição é feita via firewall do Storage Account.

Via Portal

Navegue até vnet-spoke-sp > Selecione "Subnets" > Clique em snet-sp-workload
Em Service endpoints, clique em "Add" e selecione Microsoft.Storage
Clique em "Save"
Navegue até o Storage Account > Selecione "Networking"
Altere "Public network access" para Enabled from selected virtual networks and IP addresses
Em Virtual networks, clique em "Add existing virtual network":
- Virtual networks: vnet-spoke-sp
- Subnets: snet-sp-workload
Clique em "Add" > "Save"

Via CLI

# Habilitar Service Endpoint na sub-rede
az network vnet subnet update \
  --resource-group rg-contoso-lab \
  --vnet-name vnet-spoke-sp \
  --name snet-sp-workload \
  --service-endpoints Microsoft.Storage

# Restringir o Storage Account para aceitar apenas tráfego da sub-rede
az storage account network-rule add \
  --resource-group rg-contoso-lab \
  --account-name $STORAGE_NAME \
  --vnet-name vnet-spoke-sp \
  --subnet snet-sp-workload

# Alterar a regra padrão para Deny
az storage account update \
  --resource-group rg-contoso-lab \
  --name $STORAGE_NAME \
  --default-action Deny

Após essa configuração, apenas VMs na sub-rede snet-sp-workload podem acessar o Storage Account. Tráfego de outras redes, incluindo a internet e outras sub-redes, será negado. Note que o tráfego ainda utiliza o IP público do Storage Account como destino, mas é roteado internamente pela backbone da Microsoft.

Tarefa 5.3 — Configurar Private Endpoint na sub-rede PaaS

Diferentemente do Service Endpoint, o Private Endpoint atribui um IP privado da sua VNet ao recurso PaaS. O tráfego é resolvido via DNS para esse IP privado, eliminando completamente a exposição pública.

Via Portal

Navegue até o Storage Account > Selecione "Networking" > aba Private endpoint connections > Clique em "Private endpoint"
Na aba Basics:
- Resource group: rg-contoso-lab
- Name: pe-storage-contoso
- Network Interface Name: aceite o padrão
- Region: East US 2
Na aba Resource:
- Target sub-resource: blob
Na aba Virtual Network:
- Virtual network: vnet-spoke-sp
- Subnet: snet-sp-paas
- Private IP configuration: Dynamically allocate IP address
Na aba DNS:
- Integrate with private DNS zone: Yes
- Isso criará automaticamente a zona privatelink.blob.core.windows.net e o link para a VNet
Clique em "Review + create" > "Create"

Via CLI

# Obter o resource ID do Storage Account
STORAGE_ID=$(az storage account show \
  --resource-group rg-contoso-lab \
  --name $STORAGE_NAME \
  --query id -o tsv)

# Criar o Private Endpoint
az network private-endpoint create \
  --resource-group rg-contoso-lab \
  --name pe-storage-contoso \
  --vnet-name vnet-spoke-sp \
  --subnet snet-sp-paas \
  --private-connection-resource-id $STORAGE_ID \
  --group-id blob \
  --connection-name pe-connection-storage \
  --location eastus2

# Criar a zona DNS privada
az network private-dns zone create \
  --resource-group rg-contoso-lab \
  --name "privatelink.blob.core.windows.net"

# Vincular a zona DNS à VNet
az network private-dns link vnet create \
  --resource-group rg-contoso-lab \
  --zone-name "privatelink.blob.core.windows.net" \
  --name link-spoke-sp \
  --virtual-network vnet-spoke-sp \
  --registration-enabled false

# Criar o registro DNS para o endpoint
PE_NIC_ID=$(az network private-endpoint show \
  --resource-group rg-contoso-lab \
  --name pe-storage-contoso \
  --query "networkInterfaces[0].id" -o tsv)

PE_IP=$(az network nic show \
  --ids $PE_NIC_ID \
  --query "ipConfigurations[0].privateIpAddress" -o tsv)

az network private-dns record-set a create \
  --resource-group rg-contoso-lab \
  --zone-name "privatelink.blob.core.windows.net" \
  --name $STORAGE_NAME

az network private-dns record-set a add-record \
  --resource-group rg-contoso-lab \
  --zone-name "privatelink.blob.core.windows.net" \
  --record-set-name $STORAGE_NAME \
  --ipv4-address $PE_IP

echo "Private Endpoint IP: $PE_IP"

Com o Private Endpoint configurado, a resolução DNS de stcontoso*.blob.core.windows.net dentro da VNet retornará o IP privado (ex: 10.1.2.4) em vez do IP público. Isso garante que o tráfego nunca saia da rede privada.

Tarefa 5.4 — Validar resolução DNS e comparar ambas as abordagens

Conecte-se via Bastion à vm-web-sp e verifique como o DNS resolve o Storage Account a partir de dentro da VNet.

Via Portal

Navegue até vm-web-sp > Connect > Bastion
No terminal SSH, execute:

# Resolver o nome do Storage Account
nslookup stcontoso2026lab.blob.core.windows.net
# A resposta deve incluir um CNAME para privatelink.blob.core.windows.net
# e resolver para um IP privado (10.1.2.x)

# Comparar com resolução externa (se tiver acesso à internet)
# A resolução interna aponta para IP privado
# A resolução externa (de fora da VNet) apontaria para IP público

Tente acessar o blob:

# Instalar az CLI na VM (se necessário)
curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash

# Testar acesso ao container
az storage blob list \
  --account-name stcontoso2026lab \
  --container-name dados-teste \
  --auth-mode login

O Service Endpoint e o Private Endpoint atingem objetivos complementares: o Service Endpoint otimiza o roteamento e restringe acesso via firewall do serviço, enquanto o Private Endpoint elimina completamente a exposição pública atribuindo um IP privado ao recurso.

Fase 6 — Azure DNS (Zonas Públicas e Privadas)

Esta fase cobre o objetivo: Configure Azure DNS. Você configurará uma zona DNS pública para resolução externa e trabalhará com a zona DNS privada criada na Fase 5, expandindo-a para cenários adicionais.

Os recursos utilizados das fases anteriores são: a zona DNS privada privatelink.blob.core.windows.net, todas as VNets e VMs.

Tarefa 6.1 — Criar uma zona DNS pública

A Contoso Logística precisa de uma zona DNS pública para gerenciar registros do domínio contoso-lab.com (domínio fictício para fins do laboratório).

Via Portal

Navegue até Portal Azure > Pesquise "DNS zones" > Clique em "Create"
Preencha:
- Resource group: rg-contoso-lab
- Name: contoso-lab.com
- Type: Public
Clique em "Review + create" > "Create"
Após a criação, anote os name servers atribuídos pela Azure (ex: ns1-01.azure-dns.com)

Via CLI

# Criar zona DNS pública
az network dns zone create \
  --resource-group rg-contoso-lab \
  --name contoso-lab.com

# Listar os name servers atribuídos
az network dns zone show \
  --resource-group rg-contoso-lab \
  --name contoso-lab.com \
  --query nameServers -o tsv

A zona DNS foi criada, mas o domínio contoso-lab.com não é real. Em um ambiente de produção, você apontaria os NS records do registrador de domínio para os name servers do Azure DNS.

Tarefa 6.2 — Criar registros DNS na zona pública

Você adicionará registros A e CNAME para simular a configuração DNS de uma aplicação web.

Via Portal

Navegue até a zona contoso-lab.com > Clique em "Record set"
Registro A:
- Name: www
- Type: A
- TTL: 3600
- IP address: o IP público do Load Balancer externo (pip-lb-external; consulte o IP atribuído)
Clique em "OK"
Registro CNAME:
- Name: app
- Type: CNAME
- TTL: 3600
- Alias: www.contoso-lab.com
Clique em "OK"

Via CLI

# Obter o IP do Load Balancer externo (será criado na Fase 7,
# use um IP placeholder ou pule esta associação até a Fase 7)
LB_PUBLIC_IP=$(az network public-ip show \
  --resource-group rg-contoso-lab \
  --name pip-lb-external \
  --query ipAddress -o tsv 2>/dev/null || echo "0.0.0.0")

# Criar registro A
az network dns record-set a add-record \
  --resource-group rg-contoso-lab \
  --zone-name contoso-lab.com \
  --record-set-name www \
  --ipv4-address $LB_PUBLIC_IP

# Criar registro CNAME
az network dns record-set cname set-record \
  --resource-group rg-contoso-lab \
  --zone-name contoso-lab.com \
  --record-set-name app \
  --cname www.contoso-lab.com

Os registros DNS foram criados. O registro A mapeia www.contoso-lab.com para o IP do Load Balancer, e o CNAME cria um alias app.contoso-lab.com apontando para o registro www.

Tarefa 6.3 — Expandir a zona DNS privada e vincular a VNets adicionais

A zona DNS privada privatelink.blob.core.windows.net criada na Fase 5 está vinculada apenas à vnet-spoke-sp. Vincule-a também à Hub e à Spoke RJ para que VMs em todas as redes resolvam o Private Endpoint.

Via Portal

Navegue até Portal Azure > Pesquise "Private DNS zones" > Selecione privatelink.blob.core.windows.net
Selecione "Virtual network links" > Clique em "Add"
Preencha:
- Link name: link-hub
- Virtual network: vnet-hub-contoso
- Enable auto registration: No
Clique em "OK"
Repita para:
- Link name: link-spoke-rj
- Virtual network: vnet-spoke-rj

Via CLI

# Vincular a zona DNS privada à VNet Hub
az network private-dns link vnet create \
  --resource-group rg-contoso-lab \
  --zone-name "privatelink.blob.core.windows.net" \
  --name link-hub \
  --virtual-network vnet-hub-contoso \
  --registration-enabled false

# Vincular à Spoke RJ
az network private-dns link vnet create \
  --resource-group rg-contoso-lab \
  --zone-name "privatelink.blob.core.windows.net" \
  --name link-spoke-rj \
  --virtual-network vnet-spoke-rj \
  --registration-enabled false

Agora VMs em qualquer uma das três VNets resolverão stcontoso*.blob.core.windows.net para o IP privado do Private Endpoint. Sem esses links, VMs nas VNets Hub e Spoke RJ resolveriam o nome para o IP público do Storage, e o acesso seria negado pela regra de firewall configurada na Fase 5.

Tarefa 6.4 — Verificar resolução DNS de múltiplas VNets

Conecte-se via Bastion às VMs em VNets diferentes e confirme que a resolução DNS funciona corretamente em todas.

Via Portal

Conecte-se via Bastion à vm-nva-hub (na VNet Hub)
Execute:

nslookup stcontoso2026lab.blob.core.windows.net
# Deve resolver para o IP privado (10.1.2.x)

Conecte-se via Bastion à vm-web-rj (na Spoke RJ)
Execute o mesmo comando e confirme que o resultado é idêntico

Se a resolução na Spoke RJ retornar o IP público em vez do privado, verifique se o link da zona DNS privada para vnet-spoke-rj está com status Completed:

az network private-dns link vnet show \
  --resource-group rg-contoso-lab \
  --zone-name "privatelink.blob.core.windows.net" \
  --name link-spoke-rj \
  --query provisioningState -o tsv

Fase 7 — Load Balancers (Interno e Público)

Esta fase cobre os objetivos: Configure an internal or public load balancer e Troubleshoot load balancing. Você criará um Load Balancer interno na Spoke SP e um Load Balancer público na Spoke RJ, configurará health probes e regras de balanceamento, e diagnosticará problemas comuns.

Os recursos utilizados das fases anteriores são: vnet-spoke-sp com snet-sp-workload, vnet-spoke-rj com snet-rj-workload, pip-lb-external, VMs vm-web-sp e vm-web-rj, e NSGs.

Tarefa 7.1 — Criar o Load Balancer interno na Spoke SP

O Load Balancer interno distribuirá tráfego entre VMs na sub-rede de workload de SP, acessível apenas de dentro das VNets emparelhadas.

Via Portal

Navegue até Portal Azure > Pesquise "Load balancers" > Clique em "Create"
Na aba Basics:
- Resource group: rg-contoso-lab
- Name: lb-internal-sp
- Region: East US 2
- SKU: Standard
- Type: Internal
Na aba Frontend IP configuration > Clique em "Add a frontend IP configuration":
- Name: fe-internal-sp
- Virtual network: vnet-spoke-sp
- Subnet: snet-sp-workload
- Assignment: Dynamic
Na aba Backend pools > Clique em "Add a backend pool":
- Name: bp-web-sp
- Virtual network: vnet-spoke-sp
- Backend Pool Configuration: NIC
- Clique em "Add" > selecione vm-web-sp
Na aba Inbound rules > Clique em "Add a load balancing rule":
- Name: rule-http-sp
- Frontend IP: fe-internal-sp
- Backend pool: bp-web-sp
- Protocol: TCP
- Port: 80
- Backend port: 80
- Health probe: Clique em "Create new":
  - Name: probe-http-sp
  - Protocol: HTTP
  - Port: 80
  - Path: /
  - Interval: 5
  - Unhealthy threshold: 2
- Session persistence: None
- Idle timeout: 4
Clique em "Review + create" > "Create"

Via CLI

# Criar o Load Balancer interno
az network lb create \
  --resource-group rg-contoso-lab \
  --name lb-internal-sp \
  --sku Standard \
  --vnet-name vnet-spoke-sp \
  --subnet snet-sp-workload \
  --frontend-ip-name fe-internal-sp \
  --backend-pool-name bp-web-sp \
  --location eastus2

# Criar o health probe
az network lb probe create \
  --resource-group rg-contoso-lab \
  --lb-name lb-internal-sp \
  --name probe-http-sp \
  --protocol Http \
  --port 80 \
  --path "/" \
  --interval 5 \
  --threshold 2

# Criar a regra de balanceamento
az network lb rule create \
  --resource-group rg-contoso-lab \
  --lb-name lb-internal-sp \
  --name rule-http-sp \
  --frontend-ip-name fe-internal-sp \
  --backend-pool-name bp-web-sp \
  --protocol Tcp \
  --frontend-port 80 \
  --backend-port 80 \
  --probe-name probe-http-sp \
  --idle-timeout 4

# Adicionar a VM ao backend pool
SP_NIC_ID=$(az vm show --resource-group rg-contoso-lab \
  --name vm-web-sp \
  --query "networkProfile.networkInterfaces[0].id" -o tsv)

az network nic ip-config address-pool add \
  --resource-group rg-contoso-lab \
  --nic-name $SP_NIC \
  --ip-config-name ipconfig1 \
  --lb-name lb-internal-sp \
  --address-pool bp-web-sp

O Load Balancer interno recebe um IP privado da sub-rede e distribui tráfego na porta 80 para as VMs no backend pool. O health probe verifica a cada 5 segundos se a porta 80 responde.

Tarefa 7.2 — Criar o Load Balancer público na Spoke RJ

O Load Balancer público utiliza o IP público pip-lb-external e expõe os serviços da Spoke RJ para a internet.

Via Portal

Navegue até Portal Azure > Pesquise "Load balancers" > Clique em "Create"
Na aba Basics:
- Resource group: rg-contoso-lab
- Name: lb-external-rj
- Region: East US 2
- SKU: Standard
- Type: Public
Na aba Frontend IP configuration:
- Name: fe-external-rj
- Public IP address: pip-lb-external
Na aba Backend pools:
- Name: bp-web-rj
- Virtual network: vnet-spoke-rj
- Adicione vm-web-rj
Na aba Inbound rules, crie:
- Rule name: rule-http-rj
- Frontend IP: fe-external-rj
- Backend pool: bp-web-rj
- Protocol: TCP
- Port: 80
- Backend port: 80
- Health probe: crie probe-http-rj com mesmos parâmetros da Tarefa 7.1
Clique em "Review + create" > "Create"

Via CLI

# Criar o Load Balancer público
az network lb create \
  --resource-group rg-contoso-lab \
  --name lb-external-rj \
  --sku Standard \
  --public-ip-address pip-lb-external \
  --frontend-ip-name fe-external-rj \
  --backend-pool-name bp-web-rj \
  --location eastus2

# Criar health probe
az network lb probe create \
  --resource-group rg-contoso-lab \
  --lb-name lb-external-rj \
  --name probe-http-rj \
  --protocol Http \
  --port 80 \
  --path "/" \
  --interval 5 \
  --threshold 2

# Criar regra de balanceamento
az network lb rule create \
  --resource-group rg-contoso-lab \
  --lb-name lb-external-rj \
  --name rule-http-rj \
  --frontend-ip-name fe-external-rj \
  --backend-pool-name bp-web-rj \
  --protocol Tcp \
  --frontend-port 80 \
  --backend-port 80 \
  --probe-name probe-http-rj \
  --idle-timeout 4

# Adicionar VM ao backend pool
az network nic ip-config address-pool add \
  --resource-group rg-contoso-lab \
  --nic-name $RJ_NIC \
  --ip-config-name ipconfig1 \
  --lb-name lb-external-rj \
  --address-pool bp-web-rj

O Load Balancer público está configurado e acessível via o IP de pip-lb-external. Lembre-se de que VMs associadas a um Load Balancer Standard sem IP público próprio não possuem acesso outbound à internet por padrão; um NAT Gateway ou regra de outbound seria necessário para isso.

Tarefa 7.3 — Instalar web server e testar o balanceamento

Para que os health probes e o balanceamento funcionem, as VMs precisam responder na porta 80.

Conecte-se via Bastion à vm-web-sp e instale o nginx:

sudo apt update && sudo apt install -y nginx
echo "<h1>VM-WEB-SP</h1>" | sudo tee /var/www/html/index.html
sudo systemctl enable nginx

Conecte-se via Bastion à vm-web-rj e repita:

sudo apt update && sudo apt install -y nginx
echo "<h1>VM-WEB-RJ</h1>" | sudo tee /var/www/html/index.html
sudo systemctl enable nginx

Atualize o NSG nsg-rj-workload para permitir tráfego HTTP de entrada a partir da internet (necessário para o Load Balancer público):

az network nsg rule create \
  --resource-group rg-contoso-lab \
  --nsg-name nsg-rj-workload \
  --name Allow-HTTP-Internet \
  --priority 90 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-address-prefixes Internet \
  --destination-port-ranges 80

Teste o Load Balancer público acessando o IP de pip-lb-external no navegador. Você deve ver "VM-WEB-RJ".
Para o Load Balancer interno, conecte-se à vm-nva-hub via Bastion e execute:

# Obtenha o IP frontend do LB interno (ex: 10.1.1.5)
curl http://10.1.1.5
# Deve retornar "VM-WEB-SP"

Tarefa 7.4 — Diagnosticar falha de health probe

Simule uma falha de health probe e observe como o Load Balancer reage.

Conecte-se via Bastion à vm-web-rj e pare o nginx:

sudo systemctl stop nginx

Aguarde 15 segundos (3 intervalos do probe de 5s com threshold de 2)

Via Portal

Navegue até lb-external-rj > Selecione "Backend pool health" ou "Insights"
Observe que vm-web-rj mudou para status Unhealthy
Tente acessar o IP público no navegador. A conexão será recusada, pois não há backends saudáveis

Via CLI

# Verificar status do health probe
az network lb show \
  --resource-group rg-contoso-lab \
  --name lb-external-rj \
  --query "backendAddressPools[0].loadBalancerBackendAddresses[].{Name:name}" \
  -o table

Restaure o nginx:

sudo systemctl start nginx

Após aproximadamente 10 segundos, o health probe detecta a recuperação e o backend retorna ao estado Healthy. Verifique novamente no portal ou acessando o IP público.

Este exercício demonstra que o Load Balancer Standard depende inteiramente dos health probes para determinar a disponibilidade dos backends. Se todos os backends estiverem unhealthy, o Load Balancer retorna erro de conexão. Problemas comuns incluem: NSG bloqueando a porta do probe, aplicação não escutando na porta configurada, e path do health probe retornando código HTTP diferente de 200.

Tarefa 7.5 — Atualizar o registro DNS público

Agora que o Load Balancer público possui um IP atribuído, atualize o registro A na zona DNS pública criado na Fase 6.

Via CLI

# Obter IP real do LB público
LB_PUBLIC_IP=$(az network public-ip show \
  --resource-group rg-contoso-lab \
  --name pip-lb-external \
  --query ipAddress -o tsv)

# Atualizar o registro A (remover placeholder e adicionar IP real)
az network dns record-set a remove-record \
  --resource-group rg-contoso-lab \
  --zone-name contoso-lab.com \
  --record-set-name www \
  --ipv4-address "0.0.0.0" 2>/dev/null

az network dns record-set a add-record \
  --resource-group rg-contoso-lab \
  --zone-name contoso-lab.com \
  --record-set-name www \
  --ipv4-address $LB_PUBLIC_IP

O registro DNS agora aponta para o IP real do Load Balancer público, completando a integração entre DNS e balanceamento de carga.

Validação Final

Execute as seguintes verificações para confirmar que todo o laboratório foi concluído corretamente:

1. Conectividade via Bastion e peering (cobre: Bastion, peering, VNets)

Conecte-se via Bastion (no portal, em vm-web-sp > Connect > Bastion) à VM vm-web-sp na Spoke SP. No terminal SSH, execute ping -c 4 para o IP privado da vm-nva-hub. O ping deve ter sucesso, confirmando que o peering Hub-SP está funcional e o Bastion na Hub alcança VMs nas Spokes.

2. Roteamento via NVA (cobre: UDR, IP forwarding)

Na vm-web-sp, execute traceroute 10.2.1.4 (IP da vm-web-rj). O primeiro hop deve ser o IP da NVA (10.0.1.4). Se o traceroute não mostrar a NVA como hop intermediário, revise a Route Table rt-spoke-sp e o IP forwarding na NIC e no SO da NVA.

3. Bloqueio de tráfego pelo NSG (cobre: NSG, regras efetivas)

No Network Watcher > IP Flow Verify, teste tráfego inbound para vm-web-sp na porta 22 (SSH) com source 10.99.99.99. O resultado deve ser Deny com referência à regra Deny-All-Inbound. Teste novamente na porta 80 com source correspondente ao ASG asg-web-servers. O resultado deve ser Allow.

4. Resolução DNS privada entre VNets (cobre: DNS privado, Private Endpoint)

Conecte-se via Bastion à vm-web-rj (Spoke RJ) e execute nslookup <nome-do-storage>.blob.core.windows.net. O resultado deve resolver para um IP na faixa 10.1.2.x (sub-rede snet-sp-paas), confirmando que o link da zona DNS privada para a Spoke RJ está funcional.

5. Load Balancer público acessível externamente (cobre: LB público, health probe, NSG)

De um navegador externo (seu computador local), acesse http://<IP-de-pip-lb-external>. A página deve exibir "VM-WEB-RJ". Se a conexão falhar, verifique: (a) o health probe está saudável, (b) o NSG nsg-rj-workload permite HTTP na porta 80, (c) o nginx está rodando na VM.

Cleanup do Ambiente

Para evitar cobranças desnecessárias, remova todos os recursos criados durante o laboratório.

Via Portal

Navegue até Portal Azure > Pesquise "Resource groups"
Selecione rg-contoso-lab
Clique em "Delete resource group"
Digite o nome rg-contoso-lab no campo de confirmação
Clique em "Delete"
Aguarde a notificação de conclusão. Isso pode levar de 5 a 15 minutos, pois o Azure remove recursivamente todos os recursos filhos (VMs, discos, NICs, VNets, NSGs, Load Balancers, Bastion, DNS zones, endpoints, Storage Account)
Após a conclusão, pesquise "Resource groups" novamente e confirme que rg-contoso-lab não aparece mais na lista

Via CLI

# Remover todo o Resource Group e seus recursos filhos
# O --yes pula a confirmação interativa
# O --no-wait retorna imediatamente (a exclusão continua em background)
az group delete \
  --name rg-contoso-lab \
  --yes \
  --no-wait

# Verificar o status da exclusão
az group show --name rg-contoso-lab --query "properties.provisioningState" -o tsv 2>/dev/null
# Saída esperada: Deleting (ou erro indicando que o grupo não existe mais)

# Aguardar e confirmar exclusão completa
az group wait --name rg-contoso-lab --deleted 2>/dev/null
echo "Resource Group excluído com sucesso"

Após a conclusão, verifique também se não restaram recursos órfãos (como discos gerenciados ou IPs públicos) pesquisando "All resources" no portal e filtrando pela subscription utilizada.

Cenário​

Pré-requisitos​

Via Portal​

Via CLI​

Tabela de Referência de Recursos​

Fases do Laboratório​

Fase 1 — Redes Virtuais, Sub-redes e Endereços IP Públicos​

Tarefa 1.1 — Criar a VNet Hub e suas sub-redes​

Via Portal​

Via CLI​

Tarefa 1.2 — Criar as VNets Spoke SP e Spoke RJ​

Via Portal​

Via CLI​

Tarefa 1.3 — Criar e configurar endereços IP públicos​

Via Portal​

Via CLI​

Tarefa 1.4 — Verificar a topologia e diagnosticar sobreposição de endereços​

Via Portal​

Via CLI​

Fase 2 — Peering e Conectividade entre VNets​

Tarefa 2.1 — Configurar peering Hub para Spoke SP (bidirecional)​

Via Portal​

Via CLI​

Tarefa 2.2 — Configurar peering Hub para Spoke RJ​

Via Portal​

Via CLI​

Tarefa 2.3 — Validar o status do peering e diagnosticar falha simulada​

Via Portal​

Via CLI​

Fase 3 — Rotas Definidas pelo Usuário (UDR) e NVA Simulada​

Tarefa 3.1 — Criar a VM NVA na Hub e habilitar IP forwarding​

Via Portal​

Via CLI​

Tarefa 3.2 — Criar a Route Table e associar à sub-rede Spoke SP​

Via Portal​

Via CLI​

Tarefa 3.3 — Verificar rotas efetivas e identificar conflitos​

Via Portal​

Via CLI​

Fase 4 — NSGs, ASGs e Segurança de Rede​

Tarefa 4.1 — Criar Application Security Groups​

Via Portal​

Via CLI​

Tarefa 4.2 — Criar NSGs com regras baseadas em ASGs​

Via Portal​

Via CLI​

Tarefa 4.3 — Implantar o Azure Bastion e criar VMs de teste​

Via Portal​

Via CLI​

Tarefa 4.4 — Avaliar regras efetivas do NSG e diagnosticar bloqueio​

Via Portal​

Via CLI​

Tarefa 4.5 — Testar conectividade via Bastion e habilitar IP forwarding no SO​

Via Portal​

Fase 5 — Service Endpoints e Private Endpoints para PaaS​

Tarefa 5.1 — Criar o Storage Account e verificar acesso público​

Via Portal​

Via CLI​

Tarefa 5.2 — Configurar Service Endpoint na sub-rede de workload​

Via Portal​

Via CLI​

Tarefa 5.3 — Configurar Private Endpoint na sub-rede PaaS​

Via Portal​

Via CLI​

Tarefa 5.4 — Validar resolução DNS e comparar ambas as abordagens​

Via Portal​

Fase 6 — Azure DNS (Zonas Públicas e Privadas)​

Tarefa 6.1 — Criar uma zona DNS pública​

Via Portal​

Via CLI​

Tarefa 6.2 — Criar registros DNS na zona pública​

Via Portal​

Via CLI​

Tarefa 6.3 — Expandir a zona DNS privada e vincular a VNets adicionais​

Via Portal​

Via CLI​

Tarefa 6.4 — Verificar resolução DNS de múltiplas VNets​

Via Portal​

Fase 7 — Load Balancers (Interno e Público)​

Tarefa 7.1 — Criar o Load Balancer interno na Spoke SP​

Cenário

Pré-requisitos

Via Portal

Via CLI

Tabela de Referência de Recursos

Fases do Laboratório

Fase 1 — Redes Virtuais, Sub-redes e Endereços IP Públicos

Tarefa 1.1 — Criar a VNet Hub e suas sub-redes

Via Portal

Via CLI

Tarefa 1.2 — Criar as VNets Spoke SP e Spoke RJ

Via Portal

Via CLI

Tarefa 1.3 — Criar e configurar endereços IP públicos

Via Portal

Via CLI

Tarefa 1.4 — Verificar a topologia e diagnosticar sobreposição de endereços

Via Portal

Via CLI

Fase 2 — Peering e Conectividade entre VNets

Tarefa 2.1 — Configurar peering Hub para Spoke SP (bidirecional)

Via Portal

Via CLI

Tarefa 2.2 — Configurar peering Hub para Spoke RJ

Via Portal

Via CLI

Tarefa 2.3 — Validar o status do peering e diagnosticar falha simulada

Via Portal

Via CLI

Fase 3 — Rotas Definidas pelo Usuário (UDR) e NVA Simulada

Tarefa 3.1 — Criar a VM NVA na Hub e habilitar IP forwarding

Via Portal

Via CLI

Tarefa 3.2 — Criar a Route Table e associar à sub-rede Spoke SP

Via Portal

Via CLI

Tarefa 3.3 — Verificar rotas efetivas e identificar conflitos

Via Portal

Via CLI

Fase 4 — NSGs, ASGs e Segurança de Rede

Tarefa 4.1 — Criar Application Security Groups

Via Portal

Via CLI

Tarefa 4.2 — Criar NSGs com regras baseadas em ASGs

Via Portal

Via CLI

Tarefa 4.3 — Implantar o Azure Bastion e criar VMs de teste

Via Portal

Via CLI

Tarefa 4.4 — Avaliar regras efetivas do NSG e diagnosticar bloqueio

Via Portal

Via CLI

Tarefa 4.5 — Testar conectividade via Bastion e habilitar IP forwarding no SO

Via Portal

Fase 5 — Service Endpoints e Private Endpoints para PaaS

Tarefa 5.1 — Criar o Storage Account e verificar acesso público

Via Portal

Via CLI

Tarefa 5.2 — Configurar Service Endpoint na sub-rede de workload

Via Portal

Via CLI

Tarefa 5.3 — Configurar Private Endpoint na sub-rede PaaS

Via Portal

Via CLI

Tarefa 5.4 — Validar resolução DNS e comparar ambas as abordagens

Via Portal

Fase 6 — Azure DNS (Zonas Públicas e Privadas)

Tarefa 6.1 — Criar uma zona DNS pública

Via Portal

Via CLI

Tarefa 6.2 — Criar registros DNS na zona pública

Via Portal

Via CLI

Tarefa 6.3 — Expandir a zona DNS privada e vincular a VNets adicionais

Via Portal

Via CLI

Tarefa 6.4 — Verificar resolução DNS de múltiplas VNets

Via Portal

Fase 7 — Load Balancers (Interno e Público)

Tarefa 7.1 — Criar o Load Balancer interno na Spoke SP