Azure Front Door vs. Application Gateway: El Enfrentamiento Arquitectónico de 2026

En 2026, el debate arquitectónico entre Azure Front Door (AFD) y Application Gateway ya no se trata de "Global vs. Regional" como una elección binaria; se trata de dónde tiene la intención de terminar su handshake TLS y cuánto está dispuesto a pagar por el privilegio de un backhaul con Private Link. Si todavía está implementando Application Gateways como su "edge ingress" principal para microservicios multiregión, es probable que esté sobrediseñando sus costos de computo mientras subutiliza la masiva capacidad de Anycast edge de Microsoft.

La Divergencia Estructural: Capa 7 en el Edge vs. en la VNet

Azure Front Door es un servicio distribuido, multi-tenant que opera en los más de 190 PoP (Puntos de Presencia) de Microsoft. Utiliza Anycast para enrutar el tráfico a la ubicación edge más cercana. Por el contrario, Application Gateway (AppGW) es un recurso regional gestionado inyectado directamente en su Virtual Network (VNet). La distinción es crítica: AFD termina TCP/TLS en el edge (reduciendo el tiempo de ida y vuelta para el handshake inicial), mientras que AppGW lo termina dentro de su región específica de Azure.

Para cargas de trabajo de alto rendimiento en 2026, la arquitectura "Split-TCP" de Front Door es el claro ganador en cuanto a latencia. Al terminar el handshake más cerca del usuario, los paquetes atraviesan la backbone de fibra privada de Microsoft desde el PoP hasta el origen, en lugar del enrutamiento de "cold potato" (enrutamiento de baja eficiencia) de Internet público. Si sus usuarios están distribuidos globalmente, colocar un AppGW detrás de una IP pública es un patrón de diseño anticuado que introduce jitter y latencia innecesaria.

AFD Premium: ¿El Fin del Application Gateway de cara al público?

La introducción de Azure Front Door Premium y su profunda integración con Private Link ha cambiado fundamentalmente la matriz de decisión. Anteriormente, el requisito de "Public IP" de AFD significaba que su App Service o Internal Load Balancer (ILB) necesitaba permitir los rangos de IP de AFD (Service Tags), lo que a menudo era un obstáculo de cumplimiento.

Con AFD Premium, ahora puede usar Private Link para conectarse a sus backends. Esto significa que su backend, ya sea un ILB para un cluster de AKS, una cuenta de almacenamiento o un conjunto de VMs, ya no necesita un endpoint público. Esto efectivamente deja obsoleto el Application Gateway de cara al público para la mayoría de los escenarios multiregión. ¿Por qué gestionar la complejidad de un AppGW Scale Set (y sus agonizantes tiempos de despliegue de 15 minutos) cuando puede aprovechar la escala global de AFD con un túnel privado?

# Example: Checking Private Link Status for AFD Origin 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: El Último Baluarte de la VNet

Entonces, ¿cuándo tiene sentido el Application Gateway v2 en 2026? Hay tres escenarios específicos donde sigue siendo la elección superior, si no la única:

• Balanceo de Carga Solo Interno: Si su tráfico es estrictamente "East-West" o "North-South" desde un ExpressRoute/VPN on-premise, AFD no puede tocarlo. Necesita AppGW para el enrutamiento L7 interno de la VNet.
• Reglas WAF Personalizadas con Límites de Inspección Elevados: Si bien el WAF de AFD es potente, el WAF v2 de AppGW permite un control más granular sobre las inspecciones del cuerpo de la solicitud (hasta 128 KB estándar, pero personalizable en algunas configuraciones) y las necesidades de residencia de datos para el cumplimiento regional específico.
• Estrictos Requisitos de Mutual TLS (mTLS): Aunque AFD soporta mTLS, la configuración y gestión de certificados para mTLS complejo de grado empresarial a menudo se siente más "nativo" y controlable en una instancia de AppGW donde se gestiona la CA raíz de confianza a nivel del gateway.

También vale la pena señalar que el AppGW v2 "Basic" SKU (si podemos llamar así a las versiones simplificadas) sigue siendo una pesadilla para el rendimiento durante los eventos de escalado. Apegúese al Standard_v2 o WAF_v2, y siempre mantenga una capacidad mínima de 2 unidades para evitar la penalización de "cold-start".

La Matemática del Ingress: Costo por RPS

Hablemos de números fríos y duros. En 2026, el costo de la salida de datos (egress) y las "Request Processing Units" (RPUs) o "Capacity Units" romperán su presupuesto si elige incorrectamente. Para un sitio de alto tráfico que procesa 5.000 RPS:

Azure Front Door (Standard/Premium)

• Cuota Base: ~$35 (Standard) a $330 (Premium) por mes.
• Cuota por Solicitud: ~$0.75 por millón de solicitudes.
• Transferencia de Datos: Usted paga por los datos de salida desde el Edge al Usuario. Los datos desde el Origen de Azure al Edge son $0 (esto es un ahorro masivo y oculto).

Application Gateway v2

• Costo Fijo: ~$180/mes (WAF_v2).
• Costo por Unidad de Capacidad (CU): $0.008 por CU-hora. 5.000 RPS (asumiendo un tamaño promedio de 10 KB y un encabezado de 2 KB) generalmente se traduce en aproximadamente 10-15 CUs.
• Transferencia de Datos: Usted paga las tarifas de egress estándar de VNet, que pueden ser significativamente más altas que las tarifas con descuento de AFD para grandes volúmenes.

Veredicto: Para tráfico global de alto volumen, Front Door es casi siempre más barato porque elimina el impuesto de egress "Origen-a-Internet". Para obtener más información sobre cómo optimizar su gasto en la nube, consulte nuestra guía sobre optimización de costos para ExpressRoute y Egress.

Estrategias Avanzadas de WAF: Limitación de Velocidad y Defensa contra Bots

El WAF en Front Door Premium está a años luz del WAF regional de AppGW. En 2026, los ataques automatizados de bots y los ataques DDoS de "Low and Slow" son la norma. AFD Premium incluye Bot Manager Rule Sets basados en Microsoft Threat Intelligence, que identifica "bots buenos" conocidos (Google, Bing) y desafía o bloquea "bots maliciosos" antes de que lleguen a su región de Azure.

La limitación de velocidad en AFD también es más robusta. Puede definir límites de velocidad basados en la IP del Cliente, la ubicación geográfica o incluso encabezados de solicitud específicos. Al pasar de un diseño centrado en AppGW a uno centrado en AFD, usted gana la capacidad de descartar el tráfico en el edge, ahorrando ciclos de cómputo de su backend (y costos de autoscale) para usuarios legítimos.

# Partial ARM Template for AFD Rate Limiting Rule
{
  "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 Disponibilidad Multiregión (DR)

Si está construyendo para una Real Alta Disponibilidad (99.99%+), Application Gateway es un punto de fallo de una sola región. Si bien puede implementar un AppGW en cada región y colocar Azure Traffic Manager (basado en DNS) frente a ellos, esto es un balanceo de carga global de "baja calidad". El failover basado en DNS es víctima del TTL (Time to Live) caching, lo que significa que sus usuarios podrían estar llegando a una región inactiva durante minutos después de un fallo.

Azure Front Door utiliza "HTTP-level health probes" y Anycast. Si su región de West US 2 se cae, los PoPs del edge inmediatamente (en segundos) redirigen el tráfico a East US o North Europe. No hay retraso en la propagación de DNS. Por eso AFD es la columna vertebral de los propios servicios de Microsoft como Office 365 y Xbox Live.

Hemos discutido patrones arquitectónicos similares en nuestro análisis profundo sobre Multi-Region AKS Networking, donde explicamos por qué AppGW debería residir detrás de AFD solo si necesita un requisito específico de inyección en la VNet.

Veredicto: La Recomendación de TechLeague

En 2026, la jerarquía de elección es clara. Si su aplicación está orientada al público, utilice Azure Front Door Premium. La combinación de la reducción de latencia de Anycast, el Edge WAF y el soporte de origen de Private Link lo convierte en la opción superior para seguridad y rendimiento. Utilice Application Gateway v2 solo como un "backend consumer" para tráfico interno o si tiene un requisito Legacy para reescrituras WAF específicas que el motor de AFD aún no soporta.

Deje de tratar la Nube como un centro de datos físico. Su WAF pertenece a la "puerta principal" de Internet, no escondido en una subred a 40ms de sus usuarios. Para revisiones de arquitectura o capacitación especializada en estos stacks, consulte nuestros talleres intensivos en techleague.io.

Preguntas Frecuentes