Topología de red y conectividad para el acelerador de zona de aterrizaje de Azure Spring Apps

En este artículo se describen las consideraciones de diseño y recomendaciones para la red en la que se coloca la carga de trabajo de Spring Boot. El diseño de destino depende de los requisitos de la carga de trabajo y de los requisitos de seguridad y cumplimiento de su organización.

El equipo de plataforma centralizada y el equipo de aplicaciones comparten la responsabilidad del área de diseño de redes. El equipo de la plataforma selecciona la topología de red, que puede ser una topología de red de modelo tradicional de centro-radio o Virtual WAN (administrada por Microsoft). El equipo de la aplicación es responsable de las opciones de diseño de la red de radio. Se espera que la carga de trabajo dependa de los servicios compartidos que gestiona la plataforma. El equipo de aplicaciones debe comprender las implicaciones de esas dependencias y comunicar sus requisitos para que se cumplan los objetivos generales de la carga de trabajo.

Para obtener más información sobre el diseño de la plataforma, consulte Topología de red y conectividad.

Siga estas consideraciones y recomendaciones de diseño como procedimientos recomendados en materia de controles de subred, entrada y salida.

Consideraciones de diseño

• Aislamiento. El equipo central puede proporcionar una red virtual para que el equipo de la aplicación ejecute sus cargas de trabajo. Si la carga de trabajo de Spring Boot tiene una separación de preocupaciones de otras cargas de trabajo, considere el aprovisionamiento de su propia red virtual para el runtime de servicio de Spring App y la aplicación.

• Subred. Considere la escalabilidad de la aplicación cuando elija el tamaño de la subred y el número de aplicaciones.

  Si usa subredes existentes o aporta sus propias tablas de rutas, disponga de políticas para garantizar que las reglas agregadas por Azure Spring Apps no se actualicen o eliminen.

  Otro aspecto es la seguridad. Tenga en cuenta las reglas que permiten o deniegan el tráfico en la subred.

• Tráfico de salida (saliente). El tráfico que sale de la red virtual debe enrutarse a través de Azure Firewall o Network Virtual Appliance (NVA).

  Tenga en cuenta las limitaciones del equilibrador de carga integrado proporcionado por Azure Spring Apps. En función de sus requisitos, es posible que tenga que personalizar las rutas de acceso de salida mediante enrutamiento definido por el usuario (UDR), por ejemplo para enrutar todo el tráfico a través de una NVA.

• Tráfico de entrada (entrante). Considere la posibilidad de usar un proxy inverso para el tráfico que va a Azure Spring Apps. En función de sus requisitos, elija opciones nativas, como Azure Application Gateway y Front Door, o servicios regionales, como API Management (APIM). Si esas opciones no satisfacen las necesidades de la carga de trabajo, se pueden considerar servicios que no son de Azure.

Recomendaciones de diseño

Estas recomendaciones proporcionan orientación prescriptiva para el conjunto de consideraciones anterior.

Red virtual y subredes

• Azure Spring Apps requiere permiso de propietario para su red virtual. Este rol es necesario para conceder una entidad de servicio dedicada y dinámica para la implementación y el mantenimiento. Para obtener más información, consulte Implementación de Azure Spring Apps en una red virtual.

• Azure Spring Apps implementado en una red privada proporciona un nombre de dominio completo (FQDN) al que solo se puede acceder dentro de la red privada. Cree una zona DNS privada Azure para la dirección IP de su aplicación Spring. Vincule el DNS privado a su red virtual asignando un FQDN privado dentro de Azure Spring Apps. Para obtener instrucciones paso a paso, consulte Acceso a su aplicación en una red privada.

• Azure Spring Apps requiere dos subredes dedicadas. Una subred tiene el runtime de servicio, y la otra subred es para las aplicaciones Spring Boot.

  El tamaño mínimo de bloque CIDR de cada una de estas subredes es /28. La subred en runtime y la subred de la aplicación necesitan un espacio de direcciones mínimo de /28. Pero el número de aplicaciones Spring que puede desplegar influye en el tamaño de la subred. Para obtener información sobre el número máximo de instancias de aplicación por intervalo de subred, consulte Uso de intervalos de subredes más pequeños.

• Si usa Azure Application Gateway como proxy inverso delante de Azure Spring Apps, necesita otra subred para esa instancia. Para más información, consulte Uso de Application Gateway como proxy inverso.

• Use los grupos de seguridad de red (NSG) en subredes para filtrar el tráfico de este a oeste para restringir el tráfico a su subred de runtime de servicio.

• Los grupos de recursos y subredes que gestiona el despliegue de Azure Spring Apps no deben modificarse.

Tráfico de salida

• De forma predeterminada, Azure Spring Apps tiene acceso a Internet saliente sin restricciones. Use una aplicación virtual de red como Azure Firewall para filtrar el tráfico norte-sur. Aproveche las ventajas de Azure Firewall en la red de centro de conectividad centralizada para reducir la sobrecarga de administración.

  Nota

  El tráfico de salida a los componentes de Azure Spring es necesario para admitir las instancias de servicio. Para más información sobre puntos de conexión y puertos específicos, consulte Requisitos de red de Azure Spring Apps.

• Azure Spring Apps proporciona un tipo de salida de ruta definida por el usuario (UDR) para controlar completamente la ruta del tráfico de salida. OutboundType debe definirse cuando se crea una nueva instancia de servicio de Azure Spring Apps. No se puede actualizar después. OutboundType solo se puede configurar con una red virtual. Para más información, consulte Personalización de la salida de Azure Spring Apps con una ruta definida por el usuario.

• La aplicación necesita comunicarse con otros servicios Azure en la solución. Use Azure Private Link para los servicios admitidos si las aplicaciones requieren conectividad privada.

Tráfico de entrada

• Use un proxy inverso para evitar que los usuarios malintencionados burlen el firewall de aplicaciones web (WAF) o eludan los límites de estrangulamiento. Se recomienda Azure Application Gateway con WAF integrado.

  Si usa el nivel Enterprise, use el punto de conexión asignado de la aplicación Spring Cloud Gateway como el grupo de back-end de Application Gateway. Este punto de conexión se resuelve en una dirección IP privada en la subred del runtime del servicio Azure Spring Apps.

  Agregue un grupo de seguridad de red en la subred del runtime de servicio que permita el tráfico solo desde la subred de Application Gateway, la subred de Azure Spring Apps y Azure Load Balancer.

  Nota

  Puede elegir una alternativa para el proxy inverso, como Azure Front Door o servicios que no sean de Azure. Para más información sobre las opciones de configuración, consulte Exposición de Azure Spring Apps a través de un proxy inverso.

• Azure Spring Apps se puede implementar en una red virtual mediante inyección de red virtual o fuera de la red. Para obtener más información, consulte Resumen de configuración.

Pasos siguientes

Consideraciones de seguridad para el acelerador de zona de aterrizaje de Azure Spring Apps