Entrega y rendimiento de aplicaciones

Este artículo le ayuda a seleccionar el Azure servicio de equilibrio de carga adecuado para la carga de trabajo. Compara Azure Load Balancer, Application Gateway y Azure Front Door para la distribución del tráfico regional y global. También se explica cuándo combinarlos. Para una visión más breve, servicio por servicio, véase ¿Qué es el balanceo de carga y la entrega de contenido?

Lo que trata este artículo

La entrega de aplicaciones incluye cómo tu red distribuye el tráfico entre los recursos del backend una vez que llega al perímetro de la red. En este artículo se tratan el equilibrio de carga de nivel 4 y el nivel 7 y la aceleración global del tráfico. También abarca los criterios de decisión para elegir entre los tres servicios principales de equilibrio de carga de Azure.

Note

Este artículo complementa la entrada a Internet: exponga la aplicación a Internet, que se centra en cómo llega el tráfico a la red. Este artículo se centra en cómo equilibrar y entregar ese tráfico a los back-end de la aplicación.

Quién necesita este artículo

Lea este artículo si:

  • Hospede aplicaciones web o API que necesitan alta disponibilidad en varias instancias de back-end.
  • Necesitas descarga SSL/TLS, enrutamiento basado en URL o protección contra Web Application Firewall (WAF) para tráfico HTTP/HTTPS.
  • Distribuya el tráfico entre varias regiones de Azure para el rendimiento o la recuperación ante desastres.
  • Ejecuta cargas de trabajo que no sean HTTP (TCP/UDP) y que requieran equilibrio de carga regional con pruebas de estado.
  • Quiere comprender qué equilibrador de carga se ajusta al tipo de tráfico, el ámbito geográfico y los requisitos de seguridad.

Enfoque lift-and-shift: Muchas aplicaciones internas reubicadas solo necesitan un Load Balancer regional. Agregue servicios de entrega accesibles desde Internet al publicar una aplicación a los clientes.

Enfoque de modernización: Elige la entrega según el tipo de aplicación: Azure Front Door para aplicaciones web globales y Traffic Manager para aplicaciones que no sean web, con puntos de conexión regionales activos-activos como front-end.

Enfoque entre nubes: Asigna los equilibradores de carga de otras nubes a sus equivalentes en Azure (por ejemplo, AWS ALB a Application Gateway, NLB a Azure Load Balancer) y realiza la entrega a través del spoke detrás del firewall del hub.

servicios y características de Azure

En la tabla siguiente se resumen los tres principales servicios de equilibrio de carga de Azure.

Servicio Qué proporciona Cuándo usarlo Restricciones de clave
Equilibrador de carga estándar de Azure Equilibrio de carga de nivel 4 (TCP/UDP) dentro de una región. Pruebas de estado, redundancia de zonas, reglas SNAT de salida y puertos de alta disponibilidad para dispositivos virtuales de red. Virtual Machine Scale Sets, tráfico interno de AKS, cargas de trabajo regionales que no sean HTTP/S y alta disponibilidad de NVA. Sin terminación SSL/TLS; sin WAF; sin enrutamiento basado en direcciones URL; solo ámbito regional.
Azure Application Gateway Equilibrio de carga regional de nivel 7 (HTTP/HTTPS). Terminación SSL/TLS, enrutamiento basado en la ruta de la URL, alojamiento multisitio, afinidad de sesión basada en cookies e integración opcional con WAF. Aplicaciones web regionales que necesitan descarga SSL, enrutamiento de direcciones URL, compatibilidad con WebSocket o protección de WAF. Solo regional; requiere una subred dedicada; no es adecuado para escenarios de enrutamiento global o cdn.
Azure Front Door Equilibrio de carga anycast global y CDN. Terminación TLS en el perímetro, WAF integrado, pruebas de estado de origen, división del tráfico y almacenamiento en caché en más de 190 puntos de presencia (PoP) globales. Aplicaciones web globales, implementaciones multiregión activas, CDN y almacenamiento en caché, y aplicación global de WAF. Solo HTTP/HTTPS; los orígenes deben ser accesibles públicamente o accesibles a través de Private Link (nivel Premium).

Redundancia de zona

La redundancia de zona protege el nivel de entrega de la aplicación frente a errores del centro de datos. Cada servicio controla las zonas de disponibilidad de forma diferente:

  • Standard Load Balancer (público) es con redundancia de zona de forma predeterminada porque las direcciones IP públicas estándar tienen como valor predeterminado la configuración con redundancia de zona. El tráfico continúa fluyendo incluso si se produce un error en una zona de disponibilidad. El Load Balancer estándar (interno) requiere una configuración explícita de front-end con redundancia de zona: debe seleccionar varias zonas al crear la IP de front-end.
  • Application Gateway v2 admite redundancia de zona al implementar instancias en varias zonas de disponibilidad. Especifique las zonas durante la implementación. Una instancia de Application Gateway con redundancia de zona distribuye las instancias entre las zonas que seleccione, manteniendo la disponibilidad si una sola zona se queda sin conexión.
  • Azure Front Door es intrínsecamente redundante por zonas, al tratarse de un servicio global de anycast. Sus más de 190 puntos de presencia (PoP) en el perímetro abarcan múltiples regiones de todo el mundo, por lo que el error de una sola zona o región no afecta al enrutamiento del tráfico global.

Autoscaling

Cada servicio controla la escala de forma diferente:

  • Application Gateway v2 (niveles de Standard_v2 y WAF_v2) admite el escalado automático en función de la carga del tráfico. Se configuran los recuentos mínimo y máximo de instancias, y la puerta de enlace se escala dentro de esos límites. Los precios usan unidades de capacidad: una medida compuesta de nuevas conexiones por segundo, conexiones persistentes y rendimiento. Establece un conteo mínimo de instancias de al menos dos para cargas de producción para evitar la latencia de arranque en frío durante picos de tráfico.
  • Azure Front Door escala automáticamente como servicio global administrado. No necesita planificación de capacidad ni dimensionamiento de instancias.
  • Standard Load Balancer escala a millones de flujos TCP/UDP sin intervención manual ni cambios de configuración. Es un servicio de plataforma totalmente administrado sin concepto de instancia.

Comprobaciones de salud

Los tres servicios utilizan pruebas de estado para detectar backends que no funcionan correctamente y dejar de redirigir el tráfico hacia ellos:

  • Standard Load Balancer admite sondeos de estado TCP, HTTP y HTTPS. Configura los intervalos de las pruebas y los umbrales de estado anómalo para controlar la velocidad de conmutación por error. Los intervalos más cortos detectan errores más rápidos, pero generan más tráfico de sondeo.
  • Application Gateway usa sondeos de estado HTTP/HTTPS con rutas de acceso personalizables, nombres de host y coincidencias de respuesta. Los sondeos personalizados permiten validar la lógica de la aplicación (por ejemplo, comprobar un /health punto de conexión que comprueba la conectividad de la base de datos).
  • Front Door utiliza pruebas de estado HTTP/HTTPS en los orígenes. Admite rutas de sondeo configurables, intervalos y coincidencias de código de respuesta. Front Door comprueba los orígenes desde múltiples puntos de presencia (PoP), lo que proporciona una verificación de estado distribuida.

Cómo elegir

El siguiente diagrama de flujo resume el proceso principal de toma de decisiones para seleccionar un servicio de equilibrio de carga de Azure.

Diagrama de flujo seleccionando un servicio de balanceo de carga de Azure mediante ramificaciones entre tráfico HTTP vs. no HTTP, y luego alcance de región única vs. global.

Use las siguientes tablas de decisión para seleccionar el servicio de equilibrio de carga adecuado para su escenario.

¿Qué equilibrador de carga necesito?

Necesito... Uso
Equilibrio de carga del tráfico TCP/UDP dentro de una sola región Equilibrador de carga estándar de Azure: Distribución de capa 4 con pruebas de estado, redundancia de zonas y puertos de alta disponibilidad.
Finalizar SSL/TLS, enrutar por ruta de acceso url o nombre de host y agregar WAF para una aplicación web regional Azure Application Gateway: equilibrio de carga regional de capa 7 con WAF integrado (SKU v2).
Enruta el tráfico HTTP/S a nivel global, reduce la latencia con el almacenamiento en caché perimetral o realiza la conmutación por error entre regiones Azure Front Door: Anycast global con CDN, WAF y pruebas de estado de orígenes multirregionales.

Comparación de restricciones clave

Servicio Nivel Ámbito Limitación de claves
Balanceador de carga estándar Capa 4 (TCP/UDP) Regional Sin reconocimiento de aplicaciones: no se pueden inspeccionar encabezados HTTP, direcciones URL ni cookies.
Application Gateway Capa 7 (HTTP/HTTPS) Regional Requiere una subred dedicada (/24 recomendada); no puede enrutar el tráfico globalmente.
Front Door Capa 7 (HTTP/HTTPS) Global Origins debe ser público o accesible a través de Private Link (solo nivel Premium); no hay soporte TCP/UDP.

Combinación de servicios

Muchas arquitecturas de producción combinan varios servicios de equilibrio de carga en una cadena. Cada servicio se encarga de aquello que mejor hace:

  • Front Door + Application Gateway: Utilice Front Door para la distribución global del tráfico y el WAF en el perímetro, y luego redirija el tráfico a instancias regionales de Application Gateway para el enrutamiento basado en la ruta de la URL y la administración del grupo de back-end. Front Door Premium puede conectarse a Application Gateway a través de Private Link, manteniendo privado Application Gateway. Este patrón se adapta a las implementaciones de varias regiones en las que cada región tiene requisitos complejos de enrutamiento de direcciones URL.
  • Front Door + Load Balancer: Utilice Front Door para la distribución global de HTTP/HTTPS, con un Load Balancer estándar interno detrás para distribuir el tráfico entre Virtual Machine Scale Sets o NVA dentro de una región. Front Door controla el enrutamiento global y el almacenamiento en caché, mientras que Load Balancer proporciona distribución de nivel 4 a las instancias de proceso.
  • Application Gateway + Load Balancer: use Application Gateway para la administración del tráfico HTTP/HTTPS en el front-end y Load Balancer para los niveles de back-end que no son HTTP (bases de datos, colas de mensajes) en la misma implementación. Este patrón mantiene la inteligencia de Capa 7 en el borde, con una distribución ligera de Capa 4 internamente.

Capacidades de enrutamiento

Comprender las funcionalidades de enrutamiento ayuda a restringir su elección:

Capacidad Balanceador de carga estándar Application Gateway Front Door
Enrutamiento basado en la ruta URL No Sí Sí
Enrutamiento multisitio (encabezado de host) No Sí Sí
Afinidad de sesión basada en cookies No Sí Sí
División de tráfico ponderada No No Sí
Enrutamiento geográfico No No Sí
Descarga de SSL/TLS No Sí Sí
Compatibilidad con WebSocket Paso a través Sí Sí
Compatibilidad con HTTP/2 No Sí Sí

Sugerencia

Application Gateway v2 escala automáticamente entre un recuento mínimo y máximo de instancias, y paga por al menos la capacidad mínima incluso cuando el tráfico está inactivo. Establezca el número mínimo de instancias según la carga base, no según la carga máxima, y deje que el escalado automático absorba los picos de demanda. El sobreaprovisionamiento de la capacidad mínima es una causa habitual de costes evitables de Application Gateway.

Consideraciones de diseño

Enfoque de diseño de entrega de aplicaciones lift-and-shift

  • Utilice un Azure Load Balancer interno para el tráfico este-oeste entre los niveles de una aplicación realojada, de forma que coincida con el equilibrio de carga del que ya dependía la aplicación.
  • Agregue servicios de entrega pública solo para las aplicaciones que exponga a Internet; muchas cargas de trabajo internas migradas no necesitan ninguna.
  • Mantenga el diseño de entrega simple y de una sola región durante el rehospedaje inicial.
  • Encamine todo el tráfico entrante de Internet a través del cortafuegos central antes de que llegue a la carga de trabajo.

Modernización del enfoque de diseño de entrega de aplicaciones

  • Elija por tipo de aplicación: Azure Front Door para aplicaciones web globales (terminación perimetral, WAF) y Azure Traffic Manager para aplicaciones que no son web que necesitan distribución regional basada en DNS.
  • Implemente una configuración activo-activo entre regiones y distribuya el tráfico entre el extremo público de cada región situado detrás del firewall del hub, que actúa como SNAT y DNAT.
  • Usa Application Gateway para el enrutamiento regional de capa 7 y la terminación de TLS, detrás de Front Door cuando necesites distribución global.
  • No implemente Tanto Front Door como Traffic Manager para el mismo flujo; elija uno en función de si la aplicación es web o no web.

Enfoque de diseño de entrega de aplicaciones entre nubes

  • Asignar servicios de entrega de otras nubes a Azure: el Load Balancer de aplicaciones de AWS o el Load Balancer de aplicaciones de Google Cloud a Azure Application Gateway, y los equilibradores de carga de red a Azure Load Balancer.
  • Aloja la entrega de capa 7 (Application Gateway, con WAF) en el spoke y evita asignar direcciones IP públicas directamente a las máquinas virtuales.
  • Dirige el tráfico de entrada público a través del firewall del hub protegido antes de que llegue a las cargas de trabajo migradas.
  • Use Front Door o Traffic Manager para la entrega en varias regiones una vez que las cargas de trabajo se ejecuten en más de una región de Azure.

Prerequisites

Antes de implementar los servicios de entrega de aplicaciones:

  • Red virtual implementada: Necesita al menos una red virtual con subredes. Consulte Diseño de red virtual y subred para obtener instrucciones de planeamiento de subredes.
  • Tipo de tráfico de carga de trabajo identificado: Saber si la carga de trabajo usa HTTP/HTTPS (nivel 7) o TCP/UDP (nivel 4). Este tipo de tráfico determina tu elección principal de balanceador de carga.
  • Ámbito geográfico definido: Determine si los usuarios están en una sola región o distribuida globalmente. Las bases de usuarios globales se benefician de la aceleración anycast de Front Door.
  • Capacidad de subred para Application Gateway: Application Gateway requiere una subred dedicada sin ningún otro recurso. Una subred /24 soporta hasta 125 instancias más cinco direcciones reservadas en Azure.

Consideraciones de seguridad

Los servicios de equilibrio de carga forman parte del perímetro de seguridad. Son los primeros componentes para procesar el tráfico entrante, lo que hace que su configuración de seguridad sea fundamental. Siga estos procedimientos para proteger el nivel de entrega de la aplicación.

Firewall de aplicaciones web (WAF)

Habilite WAF en modo de prevención en Application Gateway o Front Door para todas las cargas de trabajo web de producción. El modo de detección solo registra amenazas sin bloquearlas. Úselo durante el ajuste inicial para identificar falsos positivos y, a continuación, cambie al modo de prevención antes de que fluya el tráfico de producción.

WAF protege contra vulnerabilidades de seguridad web comunes, entre las que se incluyen:

  • Inyección SQL y scripts entre sitios (XSS)
  • Anomalías en el protocolo y el contrabandamiento de solicitudes
  • Bots y rastreadores (con reglas de protección de bots)
  • Las 10 principales vulnerabilidades de OWASP mediante conjuntos de reglas administradas

Tanto el WAF de Application Gateway como el WAF de Front Door usan el mismo motor de reglas, pero difieren en su alcance. Application Gateway WAF protege una implementación regional, mientras que Front Door WAF aplica directivas en el perímetro global antes de que el tráfico llegue a cualquier origen. Para obtener información detallada sobre la configuración del conjunto de reglas y el ajuste de WAF, consulte Web Application Firewall.

Protección frente a DDOS

Activa la protección DDoS de Azure en todas las direcciones IP públicas asociadas a tus servicios de balanceo de carga. Las direcciones IP públicas de front-end de Standard Load Balancer y las direcciones IP públicas de Application Gateway son objetivos principales de ataques volumétricos. Estas direcciones IP representan los puntos de entrada de la aplicación.

Azure DDoS Protection proporciona:

  • Monitorización continua del tráfico con ajuste adaptativo.
  • Mitigación automática de ataques cuando el tráfico supera un umbral.
  • Telemetría de ataque y alertas a través de Azure Monitor.
  • Protección ante costos (crédito de servicio) por el escalado de recursos desencadenado por ataques DDoS.

Para la planeación y configuración de la protección contra DDoS, consulte Protección contra DDoS.

Azure Front Door Premium admite la conectividad Private Link con los orígenes. Esta funcionalidad elimina la necesidad de servidores back-end accesibles públicamente. Front Door se conecta con su origen a través de la red troncal de Azure en lugar de Internet pública. Utilice orígenes con Private Link cuando:

  • Los back-end son servicios internos que no deben tener direcciones IP públicas.
  • Necesite restringir el acceso al origen únicamente al tráfico de Front Door.
  • Los requisitos de cumplimiento prohíben los puntos de conexión públicos en los servidores de aplicaciones.
  • Desee eliminar la superficie de ataque de un origen expuesto públicamente.

Los orígenes compatibles con Private Link incluyen App Service, Azure Storage, Application Gateway, equilibradores de carga estándar internos y orígenes personalizados con servicio Private Link.

Para consultar los patrones de arquitectura de Private Link, consulte Acceso privado a los servicios PaaS de Azure.

Importante

El nivel Front Door Estándar no admite Private Link a los orígenes. Solo Front Door Premium proporciona esta funcionalidad.

TLS mutuo (mTLS)

Application Gateway v2 admite TLS mutuo para la autenticación de back-end. Use mTLS cuando los servidores back-end requieran autenticación de cliente basada en certificados desde la puerta de enlace. Esta autenticación agrega una capa de comprobación de confianza. El servidor back-end puede confirmar que el tráfico procede de la instancia legítima de Application Gateway, y no de un actor malicioso que haya eludido Application Gateway.

Aprende más

Pasos siguientes

Sugerencia

¿Explorando por su cuenta? Vuelva al navegador de información general para encontrar el siguiente artículo por funcionalidad.

A continuación, en el itinerario de lift-and-shift:

Controlar el tráfico saliente de Internet: centralice el acceso saliente a través del firewall del centro y desactive la salida predeterminada.

A continuación en su proceso de modernización:

Configure la conectividad privada a servicios PaaS: cree subredes de Private Link en cada VNet spoke para sus cargas de trabajo de AKS, ASE y bases de datos administradas.

A continuación, en el itinerario entre nubes:

Proteja su ruta de tránsito entre nubes: implemente Azure Firewall en su centro virtual seguro para inspeccionar todo el tráfico entre nubes y con destino a Internet.

  • Last updated on