Redes y conectividad para cargas de trabajo críticas en Azure

Las redes son un área fundamental para una aplicación crítica, dado el enfoque de diseño activo-activo distribuido globalmente recomendado.

En este área de diseño se exploran varios temas de topología de red en un nivel de aplicación, teniendo en cuenta la conectividad necesaria y la administración redundante del tráfico. Más concretamente, resalta las consideraciones críticas y las recomendaciones destinadas a informar al diseño de una topología de red global segura y escalable para una aplicación crítica.

Enrutamiento de tráfico global

El uso de varias marcas de implementación regionales activas requiere un servicio de enrutamiento global para distribuir el tráfico a cada etiqueta activa.

Azure Front Door, Azure Traffic Manager y Azure Standard Load Balancer proporcionan las funcionalidades de enrutamiento necesarias para administrar el tráfico global en una aplicación de varias regiones.

Como alternativa, se pueden considerar tecnologías de enrutamiento global de terceros. Estas opciones se pueden intercambiar casi sin problemas en para reemplazar o ampliar el uso de servicios de enrutamiento global nativos de Azure. Entre las opciones más populares se incluyen las tecnologías de enrutamiento por parte de los proveedores de CDN.

En esta sección se exploran las diferencias clave de los servicios de enrutamiento de Azure para definir cómo se puede usar cada uno para optimizar diferentes escenarios.

Consideraciones de diseño

• Un servicio de enrutamiento enlazado a una sola región representa un único punto de error y un riesgo significativo para las interrupciones regionales.

• Si la carga de trabajo de la aplicación abarca el control de cliente, como con aplicaciones cliente móviles o de escritorio, es posible proporcionar redundancia del servicio dentro de la lógica de enrutamiento de cliente.

  • Varias tecnologías de enrutamiento global, como Azure Front Door y Azure Traffic Manager, se pueden considerar en paralelo para garantizar la redundancia. Los clientes están configurados para hacer failover a una tecnología alternativa cuando se cumplen ciertas condiciones de fallo. La introducción de varios servicios de enrutamiento global presenta complejidades significativas en torno al almacenamiento en caché perimetral y las funcionalidades de firewall de aplicaciones web, y la administración de certificados para la descarga SSL y la validación de aplicaciones para las rutas de acceso de entrada.
  • También se pueden considerar tecnologías de terceros, proporcionando resistencia de enrutamiento global a todos los niveles de fallos de la plataforma de Azure.

• Si Azure Front Door y Traffic Manager se usan conjuntamente para la redundancia, se requerirían cambios de diseño o ruta de acceso de entrada diferentes para garantizar un nivel de servicio coherente y aceptable.

• Azure Front Door y Azure Traffic Manager son servicios distribuidos globalmente con redundancia y disponibilidad integradas en varias regiones.

  • Los escenarios hipotéticos de error de una escala lo suficientemente grande como para amenazar la disponibilidad global de estos servicios de enrutamiento resistente presentan un riesgo más amplio para la aplicación en términos de errores en cascada y correlacionados.
    • Los escenarios de error de esta escala solo se deben a servicios fundamentales compartidos, como Azure DNS o microsoft Entra ID, que sirven como dependencias de plataforma global para casi todos los servicios de Azure. Si se aplica una tecnología redundante de Azure, es probable que el servicio secundario también esté experimentando una falta de disponibilidad o un servicio degradado.
    • Es muy probable que los escenarios de error del servicio de enrutamiento global afecten significativamente a muchos otros servicios que se usan para los componentes clave de la aplicación a través de dependencias entre servicios. Incluso si se usa una tecnología de terceros, es probable que la aplicación esté en estado incorrecto debido al impacto más amplio del problema subyacente, lo que significa que el enrutamiento a los puntos de conexión de la aplicación en Azure proporciona poco valor.

• La redundancia del servicio de enrutamiento global proporciona mitigación para un número extremadamente pequeño de escenarios de error hipotéticos, donde el impacto de una interrupción global está restringido al propio servicio de enrutamiento.

  Para proporcionar una mayor redundancia en escenarios de interrupciones globales, se puede considerar un enfoque de despliegue multinube activo-activo. Un enfoque de implementación activo-activo multinube presenta complejidades operativas significativas, que suponen riesgos de resiliencia significativos, probablemente superando con creces los riesgos hipotéticos de una interrupción global.

• En escenarios en los que no es posible el control de cliente, se debe tomar una dependencia en un único servicio de enrutamiento global para proporcionar un punto de entrada unificado para todas las regiones de implementación activas.

  • Cuando se usa de forma aislada, representan un único punto de error en un nivel de servicio debido a dependencias globales, aunque se proporcionen redundancia y disponibilidad integradas en varias regiones.
  • El Acuerdo de Nivel de Servicio proporcionado por el servicio de enrutamiento global seleccionado representa el SLO compuesto máximo alcanzable, independientemente del número de regiones de implementación que se consideren.

• Cuando el control de cliente no es posible, las mitigaciones operativas se pueden considerar para definir un proceso para migrar a un servicio de enrutamiento global secundario si una interrupción global deshabilita el servicio principal. La migración de un servicio de enrutamiento global a otro suele ser un proceso largo que dura varias horas, especialmente cuando se considera la propagación de DNS.

• Algunos servicios de enrutamiento global de terceros proporcionan un Acuerdo de Nivel de Servicio de 100%. Sin embargo, el Acuerdo de Nivel de Servicio histórico y alcanzable proporcionado por estos servicios suele ser inferior a 100%.

  • Aunque estos servicios proporcionan reparaciones financieras por falta de disponibilidad, resulta poco importante cuando el impacto de la falta de disponibilidad es significativo, como con escenarios críticos para la seguridad en los que la vida humana está en juego en última instancia. Por lo tanto, la redundancia tecnológica o las mitigaciones operativas suficientes deben considerarse incluso cuando el Acuerdo de Nivel de Servicio legal anunciado es de 100%.

Azure Front Door

Para obtener instrucciones de configuración detalladas, consulte la guía del servicio Azure Front Door.

Azure Front Door proporciona equilibrio de carga HTTP/S global mediante el protocolo Anycast con TCP dividido en la red troncal global de Microsoft. En el caso de las cargas de trabajo críticas, las funcionalidades clave incluyen:

• Caché integrada en el perímetro, WAF y protección contra DDoS en el perímetro de la red.
• Azure Front Door Premium admite puntos de conexión privados, lo que permite que el tráfico fluya desde Internet directamente a Azure redes virtuales sin direcciones IP públicas.
• Comprobaciones de estado que eliminan de forma transparente del tráfico los servidores backend no saludables de inmediato.
• Varias configuraciones de balanceo de carga, incluidas las de enrutamiento basado en latencia, prioridad y ponderación para implementaciones canary.
• Un servicio de certificado totalmente administrado que elimina la necesidad de administrar el ciclo de vida del certificado TLS.

Azure Traffic Manager

Para obtener instrucciones de configuración detalladas, consulte la guía del servicio Azure Traffic Manager.

Azure Traffic Manager es un servicio de enrutamiento basado en DNS. A diferencia de Azure Front Door, Traffic Manager no procesa las cargas de solicitud. En su lugar, devuelve un nombre DNS que el cliente resuelve y al que se conecta directamente. Esto admite cualquier protocolo, pero significa que la retirada de los backends no saludables depende de la expiración del TTL de DNS, lo que puede provocar retrasos.

Equilibrador de carga estándar de Azure

Para obtener instrucciones de configuración detalladas, consulte la guía del servicio Azure Load Balancer.

Recomendaciones de diseño

• Use Azure Front Door como servicio de enrutamiento de tráfico global principal para escenarios HTTP/S. Azure Front Door es muy recomendable para las cargas de trabajo HTTP/S, ya que proporciona enrutamiento de tráfico optimizado, conmutación por error transparente, puntos de conexión back-end privados (con la SKU Premium), almacenamiento en caché perimetral e integración con Web Application Firewall (WAF).

• En escenarios de aplicación en los que es posible el control de cliente, aplique la lógica de enrutamiento del lado cliente para tener en cuenta los escenarios de conmutación por error en los que se produce un error en la tecnología de enrutamiento global principal. Dos o más tecnologías de enrutamiento global deben colocarse en paralelo para la redundancia agregada, si el Acuerdo de Nivel de Servicio único no es suficiente. La lógica de cliente es necesaria para enrutar a la tecnología redundante si se produce un error de servicio global.

  • Se deben usar dos direcciones URL distintas, con una aplicada a cada uno de los diferentes servicios de enrutamiento global para simplificar la experiencia general de administración de certificados y la lógica de enrutamiento para una conmutación por error.
  • Dé prioridad al uso de tecnologías de enrutamiento de terceros como servicio de conmutación por error secundario, ya que esto mitigará el mayor número de escenarios de error globales y las funcionalidades que ofrecen los proveedores líderes de la red CDN del sector permitirán un enfoque de diseño coherente.
  • También se debe considerar la opción de enrutar directamente a un solo sello regional, en lugar de utilizar un servicio de enrutamiento independiente. Aunque esto dará lugar a un nivel degradado de servicio, representa un enfoque de diseño mucho más sencillo.

En esta imagen se muestra una configuración redundante del balanceador de carga global con conmutación por error del cliente mediante Azure Front Door como balanceador de carga global principal.

• Aunque no se recomienda, en el caso de las cargas de trabajo HTTP(s) que utilizan Azure Traffic Manager para la redundancia de enrutamiento global a Azure Front Door, considere la posibilidad de delegar el Web Application Firewall (WAF) a Application Gateway para el tráfico que se considera aceptable que fluye a través de Azure Front Door.
  • Esto introduce un punto de error adicional a la ruta de acceso de entrada estándar, un componente de ruta crítica adicional para administrar y escalar, y también conlleva costos adicionales para garantizar la alta disponibilidad global. Sin embargo, simplifica considerablemente el escenario de error al proporcionar coherencia entre las rutas de acceso de entrada aceptables y no aceptables a través de Azure Front Door y Azure Traffic Manager, tanto en términos de ejecución de WAF como en puntos de conexión de aplicación privados.
  • La pérdida de la caché perimetral en un escenario de fallo afecta al rendimiento general, y este impacto debe ser compatible con un nivel de servicio aceptable o con un enfoque de diseño de mitigación. Para garantizar un nivel de servicio coherente, considere la posibilidad de delegar el almacenamiento en caché perimetral a un proveedor CDN de terceros para ambas rutas.

Se recomienda tener en cuenta un servicio de enrutamiento global de terceros en lugar de dos servicios de enrutamiento global de Azure. Esto proporciona el nivel máximo de mitigación de errores y un enfoque de diseño más sencillo, ya que la mayoría de los proveedores de CDN líderes del sector ofrecen funcionalidades perimetrales en gran medida coherentes con las que ofrece Azure Front Door.

Azure Front Door

• Use el servicio de certificados administrados de Azure Front Door para habilitar las conexiones TLS y quite la necesidad de administrar los ciclos de vida de los certificados.

• Utilice el firewall de aplicaciones web (WAF) de Azure Front Door para proporcionar protección en el perímetro frente a exploits y vulnerabilidades web comunes, como la inyección SQL.

• Use la caché integrada de Azure Front Door para proporcionar contenido estático desde nodos perimetrales.

  • En la mayoría de los casos, esto también elimina la necesidad de una red de entrega de contenido (CDN) dedicada.

• Configure los puntos de entrada de la plataforma de aplicaciones para validar las solicitudes entrantes mediante el filtrado basado en encabezados mediante X-Azure-IDFD para asegurarse de que todo el tráfico fluye a través de la instancia de Front Door configurada. Considere también la posibilidad de configurar el ACL de IP mediante etiquetas de servicio de Front Door para validar que el tráfico se origina desde el espacio de direcciones IP de back-end de Azure Front Door y los servicios de infraestructura de Azure. Esto garantizará que el tráfico fluya a través de Azure Front Door en un nivel de servicio, pero el filtrado basado en encabezados seguirá siendo necesario para garantizar el uso de una instancia de Front Door configurada.

• Defina un extremo de comprobación de estado TCP personalizado para validar las dependencias críticas de servicios posteriores dentro de un sello de implementación regional, incluidas las réplicas de la plataforma de datos, como Azure Cosmos DB en el ejemplo proporcionado por la implementación de referencia fundacional. Si una o varias dependencias son incorrectas, el sondeo de estado debe reflejarlo en la respuesta devuelta para que toda la marca regional se pueda sacar de la circulación.

• Asegúrese de que las respuestas de sondeo de estado se registren y que todos los datos operativos expuestos por Azure Front Door se ingieran en el área de trabajo global de Log Analytics para facilitar un repositorio de datos unificado y una vista operativa unificada en toda la aplicación. Para obtener más información sobre la configuración, consulte la guía del servicio Azure Front Door.

• A menos que la carga de trabajo sea extremadamente sensible a la latencia, distribuya el tráfico de manera uniforme entre todas las zonas regionales consideradas para aprovechar los recursos desplegados de forma más eficaz.

  • Para ello, establezca el parámetro "Sensibilidad a la latencia (latencia adicional)" en un valor lo suficientemente alto como para compensar las diferencias de latencia entre las distintas regiones de los backends. Asegúrese de una tolerancia aceptable para la carga de trabajo de la aplicación con respecto a la latencia general de solicitudes de cliente.

• No habilite la afinidad de sesión a menos que la aplicación lo requiera, ya que puede tener un impacto negativo en el equilibrio de distribución del tráfico. Con una aplicación completamente sin estado, si se sigue el enfoque recomendado para el diseño de aplicaciones de misión crítica, cualquier solicitud podría ser gestionada por cualquiera de las implementaciones regionales.

Azure Traffic Manager

• Use Traffic Manager para escenarios que no son HTTP/S como reemplazo de Azure Front Door. Las diferencias de funcionalidad impulsan diferentes decisiones de diseño para las funcionalidades de caché y WAF, y la administración de certificados TLS.

• Las funcionalidades de WAF deben tenerse en cuenta dentro de cada región para la ruta de acceso de entrada de Traffic Manager mediante Azure Application Gateway.

• Configure un valor TTL adecuadamente bajo para optimizar el tiempo necesario para quitar un punto de conexión back-end no saludable de la circulación en caso de que el back-end se vuelva no saludable.

• Al igual que ocurre con Azure Front Door, se debe definir un extremo de estado TCP personalizado para validar las dependencias críticas posteriores dentro de un sello de implementación regional, lo cual debe reflejarse en la respuesta proporcionada por los extremos de estado.

  Sin embargo, en el caso de Traffic Manager, debe prestarse especial consideración a la conmutación por error regional en el nivel de servicio. por ejemplo, "dog legging", para mitigar el posible retraso asociado a la eliminación de un backend defectuoso debido a fallos en las dependencias, especialmente si no es posible asignar un TTL bajo para los registros DNS.

• Se debe tener en cuenta a los proveedores de CDN de terceros para lograr el almacenamiento en caché perimetral al usar Azure Traffic Manager como servicio de enrutamiento global principal. Cuando el servicio de terceros también ofrece funcionalidades de WAF perimetrales, debe tenerse en cuenta para simplificar la ruta de acceso de entrada y eliminar potencialmente la necesidad de Application Gateway.

Servicios de entrega de aplicaciones

La ruta de acceso de entrada de red para una aplicación crítica también debe tener en cuenta los servicios de entrega de aplicaciones para garantizar el tráfico de entrada seguro, confiable y escalable.

Esta sección se basa en recomendaciones de enrutamiento global mediante la exploración de las funcionalidades clave de entrega de aplicaciones, teniendo en cuenta los servicios pertinentes, como Azure Standard Load Balancer, Azure Application Gateway y Azure API Management.

Consideraciones de diseño

• El cifrado TLS es fundamental para garantizar la integridad del tráfico de usuarios entrante a una aplicación crítica, con TLS Offloading aplicado solo en el punto de ingreso de un sello para descifrar el tráfico entrante. La descarga de TLS requiere la clave privada del certificado TLS para descifrar el tráfico.

• Un firewall de aplicaciones web proporciona protección contra vulnerabilidades de seguridad y vulnerabilidades web comunes, como inyección de código SQL o scripting entre sitios, y es esencial para lograr las aspiraciones de confiabilidad máxima de una aplicación crítica.

• Azure WAF se puede habilitar en Azure Front Door o Azure Application Gateway. Para obtener funcionalidades detalladas de WAF, DDoS, TLS y administración de certificados, consulte las guías de servicio correspondientes y las instrucciones de seguridad de redes.

• También se pueden considerar las tecnologías WAF de terceros, como las NVA y los controladores de entrada avanzados en Kubernetes, para proporcionar la protección de vulnerabilidades necesaria.

• La configuración óptima de WAF normalmente requiere un ajuste preciso, independientemente de la tecnología utilizada.

Recomendaciones de diseño

• Realice la terminación de TLS en el menor número de lugares posible para mantener la seguridad y simplificar el ciclo de vida de la gestión de certificados.

• Use conexiones cifradas (por ejemplo, HTTPS) desde el punto donde se produce la descarga de TLS en los back-end de aplicaciones reales. Los puntos de conexión de aplicación no serán visibles para los usuarios finales, por lo que los dominios administrados por Azure, como azurewebsites.net o cloudapp.net, se pueden usar con certificados administrados.

• Para el tráfico HTTP(S), asegúrese de que las funcionalidades de WAF se aplican dentro de la ruta de acceso de entrada para todos los puntos de conexión expuestos públicamente.

• Habilite las funcionalidades de WAF en una sola ubicación de servicio, ya sea globalmente con Azure Front Door o regionalmente con Azure Application Gateway, ya que esto simplifica la configuración y optimiza el rendimiento y el costo.

  Configure WAF en modo de prevención para bloquear directamente los ataques. Use solo WAF en modo de detección (es decir, solo registrar pero no bloquear solicitudes sospechosas) cuando la penalización de rendimiento del modo de prevención es demasiado alta. El riesgo adicional implícito debe entenderse completamente y alinearse con los requisitos específicos del escenario de carga de trabajo.

• Priorice el uso de WAF de Azure Front Door, ya que proporciona el conjunto más rico de características nativas de Azure y aplica protecciones en el perímetro global, lo que simplifica el diseño general e impulsa aún más eficiencias.

• Use Azure API Management solo al exponer un gran número de API a clientes externos o a diferentes equipos de aplicaciones.

• Utilice la SKU de Load Balancer Estándar de Azure para cualquier escenario de distribución de tráfico interno dentro de cargas de trabajo de microservicios.

  • Proporciona un Acuerdo de Nivel de Servicio de 99.99% cuando se implementa en Availability Zones.
  • Proporciona funcionalidades críticas, como diagnósticos o reglas de salida.

• Use Azure DDoS Network Protection para ayudar a proteger los puntos de conexión públicos hospedados dentro de cada red virtual de aplicación.

Almacenamiento en caché y entrega de contenido estático

El tratamiento especial del contenido estático, como imágenes, JavaScript, CSS y otros archivos, puede tener un impacto significativo en la experiencia general del usuario y en el costo general de la solución. El almacenamiento en caché de contenido estático en el perímetro puede acelerar los tiempos de carga del cliente, lo que da como resultado una mejor experiencia de usuario y también puede reducir el costo del tráfico, las operaciones de lectura y la potencia informática de los servicios back-end implicados.

Consideraciones de diseño

• No todo el contenido que una solución pone a disposición a través de Internet se genera dinámicamente. Las aplicaciones sirven tanto a recursos estáticos (imágenes, JavaScript, CSS, archivos de localización, etc.) como a contenido dinámico.
• Las cargas de trabajo con contenido estático al que se accede con frecuencia se benefician considerablemente del almacenamiento en caché, ya que reduce la carga en los servicios back-end y reduce la latencia de acceso al contenido para los usuarios finales.
• El almacenamiento en caché se puede implementar de forma nativa en Azure mediante Azure Front Door o Azure Content Delivery Network (CDN).
  • Azure Front Door proporciona funcionalidades de almacenamiento en caché perimetrales nativas de Azure y características de enrutamiento para dividir el contenido estático y dinámico.
    • Al crear las reglas de enrutamiento adecuadas en Azure Front Door, /static/* el tráfico se puede redirigir de forma transparente al contenido estático.
  • Los escenarios de almacenamiento en caché más complejos se pueden implementar mediante el servicio Azure CDN para establecer una red de entrega de contenido completa para volúmenes de contenido estáticos significativos.
    • Es probable que el servicio Azure CDN sea más rentable, pero no proporciona las mismas funcionalidades avanzadas de enrutamiento y firewall de aplicaciones web (WAF) que se recomiendan para otras áreas de un diseño de aplicación. Sin embargo, ofrece mayor flexibilidad para integrarse con servicios similares de soluciones de terceros, como Akamai y Verizon.
  • Al comparar los servicios de Azure Front Door y Azure CDN, se deben explorar los siguientes factores de decisión:
    • ¿Se pueden realizar reglas de almacenamiento en caché necesarias mediante el motor de reglas?
    • Tamaño del contenido almacenado y el costo asociado.
    • Precio al mes para la ejecución del motor de reglas (se cobra por solicitud en Azure Front Door).
    • Requisitos de tráfico saliente (el precio difiere según el destino).

Recomendaciones de diseño

• Contenido estático generado, como copias en diferentes tamaños de archivos de imagen que nunca o rara vez cambian, también pueden beneficiarse del caché. El almacenamiento en caché se puede configurar en función de los parámetros de dirección URL y con una duración de almacenamiento en caché variable.
• Separe la entrega de contenido estático y dinámico a los usuarios y entregue contenido relevante de una memoria caché para reducir la carga en los servicios back-end, optimizar el rendimiento de los usuarios finales.
• Dada la fuerte recomendación (área de diseño de red y conectividad) de utilizar Azure Front Door para propósitos de enrutamiento global y firewall de aplicaciones web (WAF), se recomienda priorizar el uso de las capacidades de caché de Azure Front Door a menos que existan brechas.

Integración de red virtual

Para obtener instrucciones generales de virtual network, consulte la guía del servicio Virtual Network y la guía de seguridad de redes.

Normalmente, una aplicación crítica requiere integración con otras aplicaciones o sistemas dependientes. El método por el que se logra la integración de aplicaciones tiene un impacto significativo en la seguridad, el rendimiento y la confiabilidad de la solución.

Las cargas de trabajo críticas deben implementarse en Azure redes virtuales siempre que sea posible para quitar puntos de conexión públicos innecesarios y limitar la superficie expuesta a ataques. Use puntos de conexión privados para la conectividad con los servicios de la plataforma Azure.

Consideraciones de diseño

• Al implementar dentro de una zona de aterrizaje de Azure, las aplicaciones públicas sin conectividad corporativa deben usar una Online Landing Zone, mientras que las aplicaciones con conectividad corporativa deben usar una Corp. Connected Landing Zone.

• El uso de redes virtuales de aplicaciones presenta complejidades de implementación en canalizaciones de CI/CD, ya que se requiere tanto el acceso al plano de datos como al plano de control a los recursos de las redes privadas. Los agentes de compilación privados se pueden implementar dentro de las redes virtuales de la aplicación para el acceso proxy.

• En escenarios con requisitos de integración de red externa, las redes virtuales de aplicaciones se pueden conectar a otras redes mediante ExpressRoute (hasta 100 Gbps) o VPN (hasta 20 Gbps en Azure Virtual WAN). El diseño de red de aplicaciones debe alinearse con la arquitectura de red más amplia, especialmente en lo que respecta al direccionamiento y el enrutamiento.

• La inclusión de rutas de acceso y recursos de red adicionales introduce consideraciones de confiabilidad y operativas adicionales para la aplicación, asegurando que se mantenga la salud. Para más información sobre la configuración, consulte la guía del servicio ExpressRoute.

Recomendaciones de diseño

• Se recomienda implementar soluciones críticas en redes virtuales de Azure siempre que sea posible para quitar puntos de conexión públicos innecesarios, lo que limita la superficie expuesta a ataques de aplicaciones para maximizar la seguridad y la confiabilidad.

  • Use puntos de conexión privados para la conectividad con los servicios de la plataforma Azure. Los puntos de conexión de servicio se pueden considerar para los servicios que no admiten "Private Link", siempre que los riesgos de exfiltración de datos sean aceptables o se mitiguen a través de controles alternativos.

• En escenarios de aplicación que no requieren conectividad de red corporativa, trate todas las redes virtuales como recursos efímeros que se reemplazan cuando se realiza una nueva implementación regional.

• Al conectarse a otras redes de Azure o locales, las redes virtuales de aplicaciones no deben tratarse como efímeras, ya que esto crea complicaciones significativas en las que están involucrados el emparejamiento de redes virtuales y los recursos de puerta de enlace de red virtual. Todos los recursos de aplicación pertinentes dentro de la red virtual deben seguir siendo efímeros, con subredes paralelas que se usan para facilitar las implementaciones azul-verde de las marcas de implementación regionales actualizadas.

• En escenarios en los que se requiere conectividad de red corporativa para facilitar la integración de aplicaciones a través de redes privadas, asegúrese de que el espacio de direcciones IPv4 usado para las redes virtuales de aplicaciones regionales no se superpone con otras redes conectadas y tenga el tamaño adecuado para facilitar la escala necesaria sin necesidad de actualizar el recurso de red virtual e incurrir en tiempo de inactividad.

  • Se recomienda encarecidamente usar solo direcciones IP de la asignación de direcciones para Internet privado (RFC 1918).
    • Para entornos con una disponibilidad limitada de direcciones IP privadas (RFC 1918), considere la posibilidad de usar IPv6.
    • Si se requiere el uso de la dirección IP pública, asegúrese de que solo se usen bloques de direcciones propiedad.
  • Alinee con los planes de organización para el direccionamiento IP en Azure para asegurarse de que el espacio de direcciones IP de la red de aplicaciones no se superponga con otras redes entre ubicaciones locales o regiones de Azure.
  • No cree redes virtuales de aplicaciones innecesariamente grandes para asegurarse de que no se ha desperdiciado el espacio de direcciones IP.

• Priorice el uso de Azure CNI para la integración de red de AKS, ya que admite un conjunto de características más completo.

  • Considere Kubenet para escenarios con un rango limitado de direcciones IP disponibles para ajustarse a las necesidades de la aplicación dentro de un espacio restringido de direcciones. Consulte Microsegmentación y directivas de red de Kubernetes para obtener más detalles.

• En escenarios que requieren integración de red local, priorice el uso de ExpressRoute para garantizar una conectividad segura y escalable.

  • Asegúrese de que el nivel de confiabilidad aplicado a ExpressRoute o VPN cumple totalmente los requisitos de la aplicación.
  • Se deben tener en cuenta varias rutas de acceso de red para proporcionar redundancia adicional cuando sea necesario, como circuitos ExpressRoute interconectados o el uso de VPN como mecanismo de conmutación por error para la conectividad.

• Asegúrese de que todos los componentes de las rutas de acceso de red críticas están en línea con los requisitos de confiabilidad y disponibilidad de los flujos de usuario asociados, independientemente de si el equipo de aplicaciones de ti central entrega la administración de estas rutas de acceso y el componente asociado.

  Nota:

  Al implementar dentro de una zona de aterrizaje de Azure e integrarla con una topología de red organizativa más amplia, tenga en cuenta las instrucciones de red para asegurarse de que la red fundamental está alineada con los procedimientos recomendados de Microsoft.

• Use Azure Bastion o conexiones privadas proxy para acceder al plano de datos de los recursos de Azure o realizar operaciones de administración.

Salida de Internet

La salida a Internet es un requisito de red fundamental para una aplicación crítica. Para las cargas de trabajo de misión crítica, las principales preocupaciones son el agotamiento de puertos SNAT en entornos a gran escala y la fiabilidad de la propia ruta de salida.

Consideraciones de diseño

• A escala crítica, el agotamiento de puertos SNAT es un riesgo clave. Cuando se produce un gran número de solicitudes salientes, el "agotamiento de puertos de NAT de origen (o SNAT)" puede impedir nuevas conexiones salientes. Use una solución NAT escalable como Azure NAT Gateway para mitigar este riesgo.

• Además de las limitaciones de NAT, el tráfico saliente también puede estar sujeto a las inspecciones de seguridad necesarias.

  • Azure Firewall proporciona funcionalidades de seguridad adecuadas para proteger la salida de red.

  • Azure Firewall (o una aplicación virtual virtual de red equivalente) se puede usar para proteger los requisitos de salida de Kubernetes proporcionando un control pormenorizado sobre los flujos de tráfico salientes.

• Los grandes volúmenes de salida de Internet incurrirán en cargos de transferencia de datos.

Recomendaciones de diseño

• Minimice el número de conexiones salientes de Internet, ya que esto afectará al rendimiento de NAT.

  • Si se requieren grandes cantidades de conexiones enlazadas a Internet, considere la posibilidad de usar Azure NAT Gateway para abstraer los flujos de tráfico saliente.

• Use Azure Firewall en el que existen requisitos para controlar e inspeccionar el tráfico saliente de Internet.

  • Asegúrese de que Azure Firewall no se usa para inspeccionar el tráfico entre los servicios de Azure.

Si hay requisitos a gran escala asociados con el tráfico saliente, se debe tener en cuenta un recurso dedicado de Azure Firewall para una aplicación crítica, para mitigar los riesgos asociados con el uso de un recurso compartido centralmente, como escenarios ruidosos vecinos.

• Cuando se implementa dentro de un entorno de Virtual WAN, se debe tener en cuenta Firewall Manager para proporcionar una administración centralizada de las instancias dedicadas de Azure Firewall para aplicaciones y garantizar que las posturas de seguridad de la organización se mantengan a través de directivas de firewall globales.
• Asegúrese de que las directivas de firewall incrementales se deleguen a los equipos de seguridad de aplicaciones a través del control de acceso basado en rol para permitir la autonomía de la directiva de aplicación.

Conectividad entre zonas y regiones

Aunque el diseño de aplicaciones defiende fuertemente las marcas de implementación regionales independientes, muchos escenarios de aplicación pueden requerir la integración de red entre los componentes de la aplicación implementados en diferentes zonas o regiones de Azure, incluso si solo en circunstancias de servicio degradadas. El método por el que se logra la comunicación entre zonas y entre regiones tiene un impacto significativo en el rendimiento general y la confiabilidad, que se explorarán a través de las consideraciones y recomendaciones de esta sección.

Consideraciones de diseño

• El enfoque de diseño de aplicaciones para una aplicación crítica aprueba el uso de implementaciones regionales independientes con redundancia de zona aplicada en todos los niveles de componente dentro de una sola región.

• Una zona de disponibilidad (AZ) es una ubicación físicamente independiente del centro de datos dentro de una región de Azure, lo que proporciona aislamiento de errores físicos y lógicos hasta el nivel de un único centro de datos.

  Una latencia de ida y vuelta de menos de 2 ms es un objetivo de diseño para la comunicación entre zonas. Las zonas tendrán una pequeña varianza de latencia dadas distancias variadas y rutas de fibra entre zonas.

• La conectividad de zona de disponibilidad depende de las características regionales y, por tanto, el tráfico que entra en una región a través de una ubicación perimetral debe enrutarse entre zonas para llegar a su destino. Esto agregará una latencia de ~1ms-2ms dadas las restricciones de enrutamiento interzonas y limitaciones de "velocidad de la luz", pero esto solo debe tener relevancia para cargas de trabajo hipersensibles.

• Las zonas de disponibilidad se tratan como entidades lógicas dentro del contexto de una sola suscripción, por lo que es posible que las distintas suscripciones tengan una asignación de zona diferente para la misma región. Por ejemplo, la zona 1 de la suscripción A podría corresponder al mismo centro de datos físico que la zona 2 de la suscripción B.

• Con escenarios de aplicación con componentes altamente comunicativos, la distribución de las capas de la aplicación entre zonas puede introducir una latencia significativa y un aumento de los costos. Es posible mitigar esto dentro del diseño limitando un sello de implementación a una sola zona e implementando varios sellos en las distintas zonas.

• La comunicación entre diferentes regiones de Azure conlleva un cargo de transferencia de datos mayor por GB de ancho de banda.

  • La velocidad de transferencia de datos aplicable depende del continente de las regiones de Azure consideradas.
  • Los datos que atraviesan continentes se cobran a una tasa considerablemente mayor.

• Los métodos de conectividad expressRoute y VPN también se pueden usar para conectar directamente diferentes regiones de Azure juntas para determinados escenarios o incluso plataformas en la nube diferentes.

• Para la comunicación directa entre servicios, se puede usar Private Link mediante puntos de conexión privados.

• El tráfico se puede redirigir a través de circuitos de ExpressRoute que se usan para la conectividad en las instalaciones con el fin de facilitar el enrutamiento entre redes virtuales dentro de una región de Azure y entre diferentes regiones de Azure dentro de la misma geografía.

  • El tráfico en horquilla a través de ExpressRoute evita los costes de transferencia de datos asociados con el emparejamiento entre redes virtuales, por lo que puede utilizarse como una forma de optimizar los costes.
  • Este enfoque requiere más saltos de red para la integración de aplicaciones dentro de Azure, lo que introduce riesgos de latencia y confiabilidad. Amplía el rol de ExpressRoute y los componentes de gateway asociados desde Azure/en las instalaciones para también abarcar la conectividad entre Azure y Azure.

• Cuando se requiere una latencia de submilisegundos entre servicios, se pueden usar los Grupos de Colocación por Proximidad, cuando los servicios utilizados los admiten.

Recomendaciones de diseño

• Use el emparejamiento de redes virtuales para conectar redes dentro de una región y entre diferentes regiones. Se recomienda encarecidamente evitar el anclaje del cabello dentro de ExpressRoute.

• Use Private Link para establecer la comunicación directamente entre los servicios de la misma región o entre regiones (servicio en la región A que se comunica con el servicio en la región B.

• En el caso de las cargas de trabajo de aplicaciones que interactúan mucho entre componentes, considere restringir un sello de implementación a una sola zona e implementar varios sellos en las distintas zonas. Esto garantiza que la redundancia de zona se mantenga en el nivel de una marca de implementación encapsulada en lugar de un único componente de aplicación.

• Siempre que sea posible, trate cada sello de implementación como independiente y desconectado de otros sellos.

  • Utilice tecnologías de plataforma de datos para sincronizar el estado entre regiones en lugar de lograr la consistencia a nivel de aplicación con rutas de red directas.
  • Evite el redireccionamiento de tráfico entre diferentes regiones, a menos que sea necesario, incluso en un escenario de fallo. Use los servicios de enrutamiento global y los sondeos de estado de un extremo a otro para quitar toda la circulación en caso de que se produzca un error en un único nivel de componente crítico, en lugar de enrutar el tráfico en ese nivel de componente defectuoso a otra región.

• Para escenarios de aplicaciones sensibles a la hiper latencia, priorice el uso de zonas con puertas de enlace de red regionales para optimizar la latencia de red para las rutas de acceso de entrada.

Microsegmentación y directivas de red de Kubernetes

La microsegmentación es un patrón de diseño de seguridad de red que se usa para aislar y proteger cargas de trabajo de aplicaciones individuales, con directivas aplicadas para limitar el tráfico de red entre cargas de trabajo basadas en un modelo de confianza cero. Normalmente se aplica para reducir la superficie expuesta a ataques de red, mejorar la contención de infracciones y reforzar la seguridad a través de controles de red de nivel de aplicación controlados por directivas.

Una aplicación crítica puede aplicar la seguridad de red de nivel de aplicación mediante grupos de seguridad de red (NSG) en una subred o nivel de interfaz de red, listas de control de acceso de servicio (ACL) y directivas de red al usar Azure Kubernetes Service (AKS).

En esta sección se explora el uso óptimo de estas funcionalidades, lo que proporciona consideraciones y recomendaciones clave para lograr la microsegmentación de nivel de aplicación.

Consideraciones de diseño

• AKS se puede implementar en dos modelos de red diferentes:

  • Redes de Kubenet: Los nodos de AKS se integran dentro de una red virtual existente, pero los pods existen dentro de una red de superposición virtual en cada nodo. El tráfico entre pods en distintos nodos se enruta a través de kube-proxy.
  • Redes de Azure Container Networking Interface (CNI): El clúster AKS se integra dentro de una red virtual existente y sus nodos, pods y servicios reciben direcciones IP de la misma red virtual a la que están conectados los nodos del clúster. Esto es relevante para varios escenarios de red que requieren conectividad directa desde y hacia pods. Los distintos grupos de nodos se pueden implementar en subredes diferentes.

  Nota:

  Azure CNI requiere más espacio de direcciones IP en comparación con Kubenet. Se requiere un planeamiento inicial adecuado y el ajuste de tamaño de la red. Para más información, consulte la documentación de Azure CNI.

• De forma predeterminada, los pods aceptan tráfico de cualquier origen y pueden enviar tráfico a cualquier destino. Un pod puede comunicarse con todos los demás pods de un clúster de Kubernetes determinado. Kubernetes no garantiza ningún aislamiento de nivel de red y no aísla los espacios de nombres en el nivel de clúster.

• La comunicación entre Pods y Namespaces se puede aislar mediante Network Policies. La directiva de red es una especificación de Kubernetes que define las directivas de acceso para la comunicación entre pods. Con las directivas de red, se puede definir un conjunto ordenado de reglas para controlar cómo se envía o recibe el tráfico y se aplica a una colección de pods que coinciden con uno o varios selectores de etiquetas.

  • AKS admite varios motores de directivas de red, pero Cilium es las opciones recomendadas. Consulte Diferencias entre los motores de directivas de red para obtener más detalles.
  • Las directivas de red son sumas y no entran en conflicto.
  • AKS admite la creación de grupos de nodos diferentes para separar diferentes cargas de trabajo mediante nodos con características de hardware y software diferentes, como nodos con y sin funcionalidades de GPU.
  • El uso de grupos de nodos no proporciona ningún aislamiento de nivel de red.
  • Los grupos de nodos pueden usar subredes diferentes dentro de la misma red virtual. Los grupos de seguridad de red se pueden aplicar en el nivel de subred para implementar la microsegmentación entre grupos de nodos.

Recomendaciones de diseño

• Configure un grupo de seguridad de red en todas las subredes consideradas para proporcionar una ACL de IP para proteger las rutas de acceso de entrada y aislar los componentes de la aplicación en función de un modelo de confianza cero.

  • Use etiquetas de servicio de Front Door dentro de NSGs en todas las subredes que contienen backends de aplicaciones definidas en Azure Front Door, ya que esto validará que el tráfico se origina desde un espacio de direcciones IP de backends de Azure Front Door legítimo. Esto garantizará que el tráfico fluya a través de Azure Front Door en un nivel de servicio, pero el filtrado basado en encabezados seguirá siendo necesario para garantizar el uso de una instancia de Front Door determinada y para mitigar también los riesgos de seguridad de "suplantación de ip".
  • El tráfico de Internet público debe deshabilitarse en los puertos RDP y SSH en todos los NSG aplicables.

• Dé prioridad al uso del complemento de red de Azure CNI y considere Kubenet para escenarios con un intervalo limitado de direcciones IP disponibles para ajustarse a la aplicación dentro de un espacio de direcciones restringido.

  • AKS admite el uso de Azure CNI y Kubenet. Esta opción de red se selecciona en el momento de la implementación.
  • El complemento de red de Azure CNI es un complemento de red más sólido y escalable y se recomienda para la mayoría de los escenarios.
  • Kubenet es un complemento de red más ligero y se recomienda para escenarios con un intervalo limitado de direcciones IP disponibles.
  • Consulte Azure CNI para más información.

• La característica Directiva de red de Kubernetes debe usarse para definir reglas para el tráfico de entrada y salida entre pods de un clúster. Defina directivas de red específicas para restringir y limitar la comunicación entre diferentes pods. Para obtener instrucciones más amplias sobre la configuración de AKS, consulte la guía del servicio Azure Kubernetes Service.

  • Habilite la directiva de red para Azure Kubernetes Service en el momento de la implementación.

Paso siguiente

Revise las consideraciones para cuantificar y observar el estado de la aplicación.