Azure Front Door vs. Application Gateway: O Confronto Arquitetural de 2026

Em 2026, o debate arquitetural entre Azure Front Door (AFD) e Application Gateway não é mais uma escolha binária entre "Global vs. Regional"; trata-se de onde você pretende encerrar seu TLS handshake e o quanto está disposto a pagar pelo privilégio de um backhaul via Private Link. Se você ainda está implantando Application Gateways como seu ingresso de borda primário para microsserviços multi-região, provavelmente está superdimensionando seus custos de computação enquanto subutiliza a enorme capacidade de borda Anycast da Microsoft.

A Divergência Estrutural: Camada 7 na Borda vs. na VNet

Azure Front Door é um serviço distribuído e multi-tenant que opera nos mais de 190 Pontos de Presença (PoPs) da Microsoft. Ele usa Anycast para rotear o tráfego para o local de borda mais próximo. Por outro lado, Application Gateway (AppGW) é um recurso regional gerenciado, injetado diretamente em sua Virtual Network (VNet). A distinção é crucial: o AFD encerra o TCP/TLS na borda (reduzindo o round-trip time para o handshake inicial), enquanto o AppGW o encerra dentro de sua região específica do Azure.

Para workloads de alta performance em 2026, a arquitetura "Split-TCP" do Front Door é a vencedora clara em termos de latência. Ao encerrar o handshake mais perto do usuário, os pacotes trafegam pela backbone de fibra privada da Microsoft do PoP até a origem, em vez do roteamento "cold potato" da internet pública. Se seus usuários estão distribuídos globalmente, colocar um AppGW atrás de um IP público é um padrão de design antiquado que introduz jitter e latência desnecessária.

AFD Premium: A Morte do Application Gateway com Exposição Pública?

A introdução do Azure Front Door Premium e sua profunda integração com Private Link mudaram fundamentalmente a matriz de decisão. Anteriormente, o requisito de "IP Público" do AFD significava que seu App Service ou Internal Load Balancer (ILB) precisava permitir os ranges de IP do AFD (Service Tags), o que frequentemente era um obstáculo de compliance.

Com o AFD Premium, agora você pode usar Private Link para se conectar aos seus backends. Isso significa que seu backend — seja ele um ILB para um cluster AKS, uma Storage Account ou um conjunto de VMs — não precisa mais de um endpoint público. Isso efetivamente torna o Application Gateway com exposição pública obsoleto para a maioria dos cenários multi-região. Por que gerenciar a complexidade de um AppGW Scale Set (e seus agonizantemente lentos tempos de implantação de 15 minutos) quando você pode aproveitar a escala global do AFD com um túnel privado?

# Exemplo: Verificando o Status do Private Link para uma Origem AFD via CLI
az afd origin show \
  --origin-name my-aks-origin \
  --profile-name my-afd-profile \
  --resource-group rg-prod-network \
  --query "privateLinkAlias"

Application Gateway v2: O Último Reduto da VNet

Então, quando o Application Gateway v2 realmente faz sentido em 2026? Existem três cenários específicos onde ele permanece a escolha superior, senão a única:

• Balanceamento de Carga Somente Interno: Se seu tráfego é estritamente "East-West" ou "North-South" a partir de uma ExpressRoute/VPN on-premise, o AFD não pode intervir. Você precisa do AppGW para roteamento L7 interno à VNet.
• Regras de WAF Personalizadas com Altos Limites de Inspeção: Embora o WAF do AFD seja poderoso, o WAF v2 do AppGW permite um controle mais granular sobre inspeções de corpo de requisição (até 128 KB padrão, mas personalizável em algumas configurações) e necessidades específicas de residência de dados para compliance regional.
• Requisitos Estritos de Mutual TLS (mTLS): Embora o AFD suporte mTLS, a configuração e o gerenciamento de certificados para mTLS complexo de nível empresarial frequentemente parecem mais "nativos" e controláveis em uma instância do AppGW, onde você gerencia a CA raiz confiável no nível do gateway.

Vale a pena notar também que o SKU "Basic" do AppGW v2 (se pudermos chamar assim as versões simplificadas) ainda é um pesadelo para o desempenho durante eventos de escalonamento. Mantenha-se nos SKUs Standard_v2 ou WAF_v2 e sempre mantenha uma capacidade mínima de 2 unidades para evitar a penalidade de cold-start.

A Matemática do Ingress: Custo por RPS

Vamos falar de números frios e concretos. Em 2026, o custo da egress de dados e das "Request Processing Units" (RPUs) ou "Capacity Units" irá estourar seu orçamento se você escolher incorretamente. Para um site de alto tráfego processando 5.000 Requisições Por Segundo (RPS):

Azure Front Door (Standard/Premium)

• Taxa Base: Aproximadamente US$35 (Standard) a US$330 (Premium) por mês.
• Taxa por Requisição: Aproximadamente US$0,75 por milhão de requisições.
• Transferência de Dados: Você paga pela saída de dados da Borda para o Usuário. Dados do Azure Origin para a Borda custam US$0 (esta é uma enorme economia oculta).

Application Gateway v2

• Custo Fixo: Aproximadamente US$180/mês (WAF_v2).
• Custo da Capacity Unit (CU): US$0,008 por CU-hora. 5.000 RPS (assumindo tamanho médio de 10 KB e header de 2 KB) geralmente se traduz em aproximadamente 10-15 CUs.
• Transferência de Dados: Você paga taxas padrão de egress da VNet, que podem ser significativamente mais altas do que as taxas com desconto do AFD para grandes volumes.

Veredito: Para tráfego global de alto volume, o Front Door é quase sempre mais barato porque elimina o imposto de egress "Origin-to-Internet". Para mais informações sobre como otimizar seus gastos com a nuvem, consulte nosso guia sobre otimização de custos para ExpressRoute e Egress.

Estratégias Avançadas de WAF: Rate Limiting e Bot Defense

O WAF no Front Door Premium está anos-luz à frente do WAF regional do AppGW. Em 2026, ataques de bot automatizados e ataques DDoS "Low and Slow" são a norma. O AFD Premium inclui Bot Manager Rule Sets baseados na Microsoft Threat Intelligence, que identifica "good bots" conhecidos (Google, Bing) e desafia ou bloqueia "malicious bots" antes mesmo que eles atinjam sua região do Azure.

O rate limiting no AFD também é mais robusto. Você pode definir rate limits com base no Client IP, localização geográfica ou até mesmo em Request Headers específicos. Ao migrar de um design centrado em AppGW para um centrado em AFD, você ganha a capacidade de descartar tráfego na borda, economizando ciclos de computação do seu backend (e custos de autoscaling) para usuários legítimos.

# Fragmento de ARM Template para Regra de Rate Limiting do AFD
{
  "name": "RateLimitRule",
  "priority": 100,
  "ruleType": "RateLimitRule",
  "action": "Block",
  "matchConditions": [
    {
      "matchVariable": "RemoteAddr",
      "operator": "IPMatch",
      "negateCondition": false,
      "matchValue": ["0.0.0.0/0"]
    }
  ],
  "rateLimitThreshold": 1000,
  "rateLimitDurationInMinutes": 1
}

Alta Disponibilidade Multi-Região (DR)

Se você está construindo para True High Availability (99,99%+), o Application Gateway é um ponto único de falha regional. Embora você possa implantar um AppGW em cada região e colocar o Azure Traffic Manager (baseado em DNS) na frente deles, isso é um balanceamento de carga global "para os pobres". O failover baseado em DNS é vítima do cache de TTL (Time to Live), o que significa que seus usuários podem estar acessando uma região inoperante por minutos após uma falha.

O Azure Front Door usa probes de saúde de nível HTTP e Anycast. Se sua região Oeste dos EUA 2 ficar inoperante, os PoPs de borda imediatamente (em segundos) redirecionam o tráfego para Leste dos EUA ou Norte da Europa. Não há atraso de propagação de DNS. É por isso que o AFD é a espinha dorsal dos próprios serviços da Microsoft, como Office 365 e Xbox Live.

Discutimos padrões arquiteturais semelhantes em nosso aprofundamento sobre Redes AKS Multi-Região, onde explicamos por que o AppGW deve residir atrás do AFD apenas se você precisar de um requisito específico de injeção de VNet.

Veredito: A Recomendação da TechLeague

Em 2026, a hierarquia de escolha é clara. Se sua aplicação é pública, use Azure Front Door Premium. A combinação de redução de latência com Anycast, Edge WAF e suporte a origins via Private Link o torna a escolha superior para segurança e performance. Use o Application Gateway v2 apenas como um "consumidor de backend" para tráfego interno ou se você tiver um requisito legado para reescritas específicas de WAF que o motor do AFD ainda não suporta.

Pare de tratar a nuvem como um data center físico. Seu WAF pertence à porta de entrada da internet, não escondido em uma sub-rede a 40ms de seus usuários. Para revisões de arquitetura ou treinamento especializado nessas tecnologias, confira nossos workshops intensivos em techleague.io.

Perguntas Frequentes