Laboratório de Troubleshooting: Plan and configure shared or dedicated subnets
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe implantou um Azure API Management (modo externo) em uma VNet existente. A sub-rede escolhida tem /27 e já hospeda duas máquinas virtuais de monitoramento com IPs estáticos atribuídos. O NSG da sub-rede permite tráfego de entrada nas portas 80 e 443 de qualquer origem.
Após o deploy concluir com sucesso no portal, os health checks internos do API Management começam a falhar intermitentemente. O time de operações abre um diagnóstico e coleta os seguintes eventos no log de atividades:
[APIM] Health probe to backend pool: TIMEOUT
[APIM] Management endpoint 3443 unreachable from control plane
[APIM] Gateway status: Degraded
Source IP of probe: 20.37.158.0/23 (tag: ApiManagement)
O time identifica que as VMs de monitoramento estão operando normalmente e que o tráfego de usuários na porta 443 está chegando ao gateway. A equipe suspeita de sobrecarga nas VMs como causa do timeout.
Qual é a causa raiz do comportamento observado?
A) O tamanho /27 da sub-rede esgotou os endereços IP disponíveis após a alocação das VMs, impedindo que o APIM crie suas instâncias internas de health probe.
B) O NSG da sub-rede não permite tráfego de entrada na porta 3443 originado da tag de serviço ApiManagement, bloqueando o plano de controle do serviço.
C) As VMs de monitoramento com IPs estáticos conflitam com os endereços reservados pelo Azure API Management, causando colisão de endereçamento.
D) O modo externo do API Management exige uma sub-rede sem nenhum recurso preexistente, e a presença das VMs invalida a configuração do gateway.
Cenário 2 — Decisão de Ação
A equipe de infraestrutura identificou que um Azure SQL Managed Instance em produção está sofrendo falhas de conectividade intermitentes para clientes dentro da mesma VNet. A causa foi confirmada: uma User Defined Route (UDR) associada à sub-rede do Managed Instance redireciona o tráfego de saída via um NVA (Network Virtual Appliance) que está com alta latência e descartando pacotes ocasionalmente.
O ambiente possui as seguintes restrições:
- O Managed Instance está em uso contínuo por uma aplicação financeira com SLA de 99,9%
- A UDR foi aplicada há 3 dias por outra equipe como parte de um projeto de auditoria de tráfego
- Remover a UDR requer aprovação do comitê de segurança, que só se reúne semanalmente
- O NVA pertence a uma subscription diferente gerenciada pelo time de segurança
- Existe uma janela de manutenção programada para 72 horas após o incidente
Qual é a ação correta a tomar neste momento?
A) Remover imediatamente a UDR da sub-rede do Managed Instance para restaurar o roteamento padrão, já que a causa está confirmada e o impacto em produção justifica a ação.
B) Escalar o incidente ao time de segurança com a evidência da causa raiz, solicitar que o NVA seja estabilizado ou bypass temporário seja aprovado em regime de emergência, sem alterar a UDR sem autorização.
C) Aguardar a janela de manutenção em 72 horas para aplicar a correção de forma controlada, documentando o impacto no período intermediário.
D) Recriar o Managed Instance em uma nova sub-rede sem a UDR problemática, aproveitando que a causa está identificada e o ambiente permite failover.
Cenário 3 — Causa Raiz
Um engenheiro tenta implantar um Azure Container Apps Environment em uma sub-rede existente de uma VNet corporativa. O deploy falha com a seguinte mensagem:
Error: InsufficientSubnetSize
Message: "The subnet '/subscriptions/.../subnets/aca-subnet' does not have
enough available IP addresses. Required: 27, Available: 14."
O engenheiro inspeciona a sub-rede e coleta as seguintes informações:
Subnet CIDR: 10.1.4.0/27
Total addresses: 32
Reserved by Azure: 5
Currently allocated:
- 10.1.4.5 (VM jumpbox)
- 10.1.4.6 (VM jumpbox replica)
- 10.1.4.7 (Private Endpoint - Storage Account)
- 10.1.4.8 (Private Endpoint - Key Vault)
Total used: 9
Available: 18 (32 - 5 - 9 = 18)
O engenheiro conclui que há 18 endereços disponíveis e que o erro de "14 disponíveis" está incorreto, interpretando o problema como um bug de atualização no portal. Ele decide tentar o deploy novamente sem alterações.
Qual é a causa raiz real da falha?
A) O Azure Container Apps Environment requer delegação de sub-rede para Microsoft.App/environments, e a ausência dessa delegação faz o serviço reportar erroneamente uma contagem de IPs menor do que a real.
B) Private Endpoints consomem um bloco de IPs adicionais invisíveis no portal para suas interfaces de rede internas, reduzindo o espaço real disponível abaixo do que o cálculo manual indica.
C) A sub-rede /27 possui apenas 32 endereços totais, e o Azure Container Apps Environment exige um mínimo de /27 com pelo menos 27 endereços livres, tornando qualquer uso prévio da sub-rede incompatível com o deploy.
D) O cálculo do engenheiro está incorreto: os Private Endpoints consomem endereços adicionais para suas NICs que não aparecem na listagem de IPs alocados do portal, e o espaço real disponível é inferior ao calculado manualmente.
Cenário 4 — Sequência de Diagnóstico
Um time recebe o seguinte alerta em um ambiente de produção:
"VMs na subnet
app-subnetperderam conectividade com VMs na subnetdb-subnetdentro da mesma VNet. A conectividade externa das VMs naapp-subnetestá normal."
Os passos de investigação disponíveis são:
- Verificar se há uma UDR associada a uma das sub-redes que redirecione o tráfego para um next hop incorreto ou inexistente
- Confirmar que as duas sub-redes pertencem à mesma VNet e que não há VNet peering mal configurado entre elas
- Verificar as regras de NSG associadas à
db-subnetpara identificar se há uma regra de negação explícita para o range de IPs daapp-subnet - Usar o Network Watcher — IP Flow Verify para testar a conectividade do IP de origem para o IP de destino na porta afetada
- Checar se o Azure Firewall ou NVA está interceptando o tráfego entre sub-redes e descartando pacotes sem log visível
Qual é a sequência correta de investigação?
A) 2 -> 3 -> 1 -> 4 -> 5
B) 4 -> 2 -> 3 -> 1 -> 5
C) 1 -> 5 -> 2 -> 3 -> 4
D) 2 -> 4 -> 3 -> 1 -> 5
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está no log coletado: a porta 3443 é a porta de gerenciamento do Azure API Management, usada pelo plano de controle da Microsoft para verificar a saúde e configurar o gateway. A tag de serviço ApiManagement representa os IPs de infraestrutura do Azure que precisam alcançar o serviço nessa porta. O NSG da sub-rede foi configurado apenas para 80 e 443, deixando a 3443 bloqueada.
O sintoma "gateway degradado com health probes falhando" com tráfego de usuário funcionando normalmente é exatamente o padrão de uma falha no plano de controle, não no plano de dados. Isso elimina as alternativas A e C.
A informação sobre as VMs de monitoramento operando normalmente é irrelevante e foi inserida para induzir o diagnóstico errado da alternativa C. O fato de o deploy ter "concluído com sucesso" também é uma armadilha: o APIM pode provisionar antes de validar as regras de NSG, tornando a falha pós-deploy o comportamento esperado quando a configuração de rede está incompleta.
O distrator mais perigoso é A: focar no tamanho da sub-rede quando o esgotamento de IPs não está evidenciado nos logs e os IPs das instâncias foram alocados com sucesso durante o deploy.
Gabarito — Cenário 2
Resposta: B
A causa está confirmada, mas a restrição crítica é que remover a UDR exige aprovação do comitê de segurança. A alternativa A ignora essa restrição de governança e representa uma ação tecnicamente correta aplicada sem autorização em um ambiente com controles formais. Em ambientes corporativos, agir fora do processo de aprovação pode criar problemas de compliance mais graves do que a falha original.
A alternativa C é incorreta porque o SLA de 99,9% não tolera 72 horas de degradação sem ação, e aguardar passivamente contraria qualquer obrigação de resposta a incidente.
A alternativa D é tecnicamente inviável em produção com SLA ativo: recriar um Managed Instance é uma operação demorada e de alto risco que poderia causar janela de indisponibilidade maior do que a falha atual.
A ação correta é escalar com evidência e solicitar aprovação emergencial ao time responsável pela UDR, que tem autonomia sobre o NVA. Isso respeita os controles de governança sem ignorar o impacto em produção.
Gabarito — Cenário 3
Resposta: D
O erro do engenheiro foi confiar no cálculo manual baseado na listagem de IPs visíveis no portal. Private Endpoints alocam uma NIC (Network Interface Card) para cada endpoint, e essa NIC consome endereços IP adicionais que frequentemente não aparecem na visão consolidada de IPs alocados da sub-rede no portal. A contagem real de endereços disponíveis é inferior à calculada manualmente.
A alternativa B descreve o mesmo fenômeno de forma imprecisa ao mencionar "bloco de IPs adicionais invisíveis", o que não é tecnicamente correto. A NIC do Private Endpoint é um recurso real e visível se inspecionado individualmente; o problema é que a visão de sub-rede no portal não o consolida corretamente em todos os contextos.
A alternativa A é um distrator plausível porque a delegação é de fato necessária para alguns serviços de Container Apps, mas não é a causa do erro InsufficientSubnetSize, que é explicitamente um problema de endereçamento.
A informação sobre a decisão do engenheiro de "repetir o deploy sem alterações" é irrelevante para identificar a causa raiz, mas foi incluída para testar se o leitor foca no sintoma técnico real, não no comportamento do engenheiro.
Gabarito — Cenário 4
Resposta: A
A sequência correta é 2 -> 3 -> 1 -> 4 -> 5, que segue a lógica de eliminação progressiva do mais simples para o mais complexo.
Passo 2 primeiro: confirmar que as sub-redes estão na mesma VNet elimina imediatamente causas de roteamento externo. Tráfego dentro da mesma VNet não precisa de peering, e validar isso leva segundos.
Passo 3 segundo: com o escopo de rede confirmado, verificar NSGs na sub-rede de destino é a causa mais comum de bloqueio intra-VNet. É simples, direto e resolve a maioria dos casos.
Passo 1 terceiro: UDRs são a segunda causa mais comum de desvio de rota, mas exigem mais análise. Só faz sentido investigar após eliminar NSG.
Passo 4 quarto: o IP Flow Verify valida a hipótese dos passos anteriores com um teste ativo. Usá-lo antes dos passos 3 e 1 inverte a lógica: ele confirma o bloqueio, mas não diz onde está configurado.
Passo 5 por último: investigar o Firewall ou NVA é o caminho mais complexo e invasivo, adequado apenas quando as causas mais diretas foram eliminadas.
A alternativa B comete o erro clássico de iniciar pela ferramenta de diagnóstico (IP Flow Verify) antes de inspecionar as configurações, o que pode confirmar o sintoma sem aproximar do diagnóstico da causa.
Árvore de Troubleshooting: Plan and configure shared or dedicated subnets
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão binária ou por estado) |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece pelo nó raiz identificando se a falha ocorreu no momento do deploy ou após ele. Siga as ramificações respondendo cada pergunta com base no que é observável diretamente: mensagem de erro, estado do NSG, presença de UDR, comportamento do plano de controle. Resista ao impulso de pular para as perguntas mais complexas como UDRs ou NVAs antes de eliminar causas simples como NSG e delegação. Os nós laranja marcam os pontos onde uma validação ativa com ferramenta é necessária antes de agir, evitando correções prematuras baseadas em suposição.