¿Aún se requiere proxy inverso entre AWS ALB y el servidor de aplicaciones?

¿Aún se requiere proxy inverso entre AWS ALB y el servidor de aplicaciones?

Contexto

Aplicación web con servidor de aplicaciones, es decir Ruby on Rails con puma. Ejecutándose dentro de un contenedor en AWS ECS con Fargate. AWS Application Load Balancer enruta el tráfico directamente al servidor de aplicaciones que se ejecuta dentro del contenedor.

Pregunta

¿Aún se requiere un proxy inverso entre ALB y la aplicación misma, es decir, como contenedor complementario? ¿Cuál sería el beneficio?

Respuesta1

No se requiere un proxy inverso, pero los servidores web que se incluyen con Rails tienen una funcionalidad mínima, por lo que para cualquier aplicación pública y que potencialmente pueda crecer, es una buena idea integrar un proxy inverso (por ejemplo, Nginx) desde el principio.

Por ejemplo, esto le brindaría capacidad avanzada de limitación de velocidad, almacenamiento en caché y la capacidad de realizar terminaciones SSL de extremo a extremo con mucha menos molestia que otras implementaciones de servidores web. El registro también se vuelve mucho más fácil, y cosas como los reintentos de TCP pueden salvarle la vida si su aplicación está bajo carga.

No necesitas un sidecar. Puede instalar Nginx en el mismo cuadro que su aplicación. Es súper eficiente y no afectará el rendimiento de su aplicación.

Usamos múltiples servidores proxy Nginx frente a Rails y atendemos miles de millones de solicitudes http por día.

Implementaciones masivas de proxy inverso, como Cloudflare, también se basan en Nginx.

Respuesta2

Un equilibrador de carga es un tipo de proxy inverso. Sus beneficios incluyen aceptar tráfico en puertos específicos, actuar como un tipo de firewall y evitar que algunos tipos de ataques lleguen al servidor.

Para el caso común de una aplicación web, no veo ningún beneficio significativo de tener un equilibrador de carga y un segundo proxy inverso.

información relacionada