Configurando Health Checks Confiáveis para IIS no Azure Application Gateway

Ao hospedar aplicações baseadas em IIS atrás de um Azure Application Gateway, um dos incidentes de produção mais frequentes é o surgimento intermitente de erros 502 Bad Gateway ou 504 Gateway Timeout, mesmo quando a aplicação parece estar operacional. Em grande parte dos casos, a raiz do problema não está no código da aplicação, mas em uma implementação inadequada ou mal configurada das health probes.

Durante migrações de cargas de trabalho IIS para infraestrutura IaaS no Azure, observamos que o comportamento padrão das health probes frequentemente falha ao lidar com cenários complexos, como rotas protegidas por autenticação, redirecionamentos HTTP ou validações de certificados. Este artigo analisa como projetar health endpoints robustos, otimizados para o ambiente do Azure Application Gateway e focados em estabilidade operacional.

Por que as Health Probes são críticas no Azure Application Gateway

O Azure Application Gateway depende exclusivamente das health probes para determinar o status de disponibilidade dos backend instances. Se uma probe:

• Receber uma resposta diferente de HTTP 200 OK;
• Expirar (timeout);
• For redirecionada (3xx);
• Requerer autenticação;

... o back-end é marcado como Unhealthy e o tráfego é interrompido. É fundamental compreender que uma aplicação IIS funcional não garante um back-end "saudável" do ponto de vista do Application Gateway.

O Fluxo da Falha: Como uma configuração incorreta gera erros 502

É comum times de TI se depararem com erros 502 Bad Gateway enquanto a aplicação IIS está rodando sem problemas. Isso ocorre porque o Application Gateway marca o destino como Unhealthy ao detectar falhas na probe e cessa o roteamento. O diagrama abaixo ilustra como essa falha acontece:

Key takeaway: A maioria dos erros 502 em infraestruturas Azure Application Gateway são falhas de detecção (probes), não falhas da aplicação.

Como projetar um Health Endpoint Confiável

Um health endpoint ideal deve ser:

1. Lightweight: Baixo consumo de CPU/Memória.
2. Anonymous: Deve permitir acesso sem autenticação.
3. Performático: Latência abaixo de 100 ms.
4. Estável: Sempre retornar HTTP 200, independente de lógica de negócio ou dependências externas como banco de dados.

Implementação na Prática

1. Crie um endpoint dedicado

Recomendamos o caminho /health. Se a sua aplicação utiliza autenticação, configure o seu web.config para permitir acesso anônimo exclusivamente a este caminho:

Copiar<location path="health">
  <system.webServer>
    <security>
      <authentication>
        <anonymousAuthentication enabled="true" />
        <windowsAuthentication enabled="false" />
      </authentication>
    </security>
  </system.webServer>
</location>

2. Configure a Probe no Azure Application Gateway

• Protocol: HTTPS
• Path: /health
• Pick host name from backend: Enabled (Essencial para validação de certificados SNI/Host Header).

Boas Práticas para Prod

Validar o comportamento é tão importante quanto configurar. Use comandos como Invoke-WebRequest dentro de suas VMs back-end para garantir que o endpoint responda exatamente 200 OK sem redirects. Monitore essas falhas como indicadores de alerta precoce antes que o tráfego real seja impactado. Ao reduzir a complexidade da verificação, você elimina os falsos negativos que degradam o SLA e a experiência do usuário final.

---

Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.