Prácticas recomendadas para recibir conexiones entrantes a Amazon ECS desde Internet - Amazon Elastic Container Service

Prácticas recomendadas para recibir conexiones entrantes a Amazon ECS desde Internet

Si ejecuta un servicio público, debe aceptar el tráfico entrante de Internet. Por ejemplo, su sitio web público debe aceptar las solicitudes HTTP entrantes de los navegadores. En tal caso, otros hosts de Internet también tienen que iniciar una conexión entrante con el host de su aplicación.

Una forma de solucionar este problema consiste en lanzar los contenedores en los hosts que se encuentren en una subred pública con una dirección IP pública. Sin embargo, no recomendamos esta opción para aplicaciones a gran escala. Para ello, un mejor enfoque consiste en disponer de una capa de entrada escalable que se encuentre entre Internet y la aplicación. Para este enfoque, puede utilizar como entrada cualquiera de los servicios de AWS que se enumeran en esta sección.

Equilibrador de carga de aplicación

En la capa de la aplicación funciona un equilibrador de carga de aplicación. Es la séptima capa del modelo de interconexión de sistemas abiertos (OSI). Esto hace que el equilibrador de carga de aplicación sea adecuado para los servicios HTTP públicos. Si tiene un sitio web o una API de REST HTTP, entonces el equilibrador de carga de aplicación es el equilibrador de carga adecuado para esta carga de trabajo. Para obtener más información, consulte ¿Qué es un equilibrador de carga de aplicación? en la Guía del usuario de equilibradores de carga de aplicaciones.

Diagrama que muestra la arquitectura de una red que utiliza un equilibrador de carga de aplicación.

Con esta arquitectura, se crea un equilibrador de carga de aplicación en una subred pública para que tenga una dirección IP pública y pueda recibir conexiones entrantes de Internet. Cuando el equilibrador de carga de aplicación recibe una conexión entrante o, más específicamente, una solicitud HTTP, abre una conexión con la aplicación mediante su dirección IP privada. A continuación, reenvía la solicitud a través de la conexión interna.

El equilibrador de carga de aplicación tiene las siguientes ventajas.

  • Terminación SSL/TLS: el equilibrador de carga de aplicación puede mantener una comunicación HTTPS segura y los certificados para las comunicaciones con los clientes. Opcionalmente, se puede finalizar la conexión SSL del equilibrador de carga para que no tenga que gestionar los certificados en su propia aplicación.

  • Enrutamiento avanzado: un equilibrador de carga de aplicación puede tener varios nombres de host DNS. También cuenta con capacidades de enrutamiento avanzadas para enviar solicitudes HTTP entrantes a diferentes destinos en función de métricas como el nombre de host o la ruta de la solicitud. Esto significa que puede usar un único equilibrador de carga de aplicación como entrada para muchos servicios internos diferentes, o incluso microservicios en diferentes rutas de una API de REST.

  • Compatibilidad con gRPC y websockets: un equilibrador de carga de aplicación puede gestionar más que HTTP. También puede equilibrar la carga de servicios basados en gRPC y websocket, con compatibilidad con HTTP/2.

  • Seguridad: un equilibrador de carga de aplicación ayuda a proteger su aplicación del tráfico malicioso. Incluye características como las mitigaciones de desincronización de HTTP y está integrado con el firewall de aplicaciones web de AWS (AWS WAF). AWS WAF puede filtrar más aún el tráfico malicioso que podría contener patrones de ataque, como inyección de código SQL o scripting entre sitios.

Equilibrador de carga de red

Un equilibrador de carga de red actúa como la cuarta capa del modelo de interconexión de sistemas abiertos (OSI). Es adecuado para protocolos que no son HTTP o escenarios en los que se necesita cifrado de extremo a extremo, pero no tiene las mismas características específicas de HTTP que un equilibrador de carga de aplicación. Por lo tanto, el equilibrador de carga de red es la opción más adecuada para las aplicaciones que no utilizan HTTP. Para obtener más información, consulte ¿Qué es un equilibrador de carga de red? en la Guía del usuario de equilibradores de carga de red.

Diagrama que muestra la arquitectura de una red que utiliza un equilibrador de carga de red.

Cuando se utiliza un equilibrador de carga de red como entrada, este actúa de manera similar a un equilibrador de carga de aplicación. Esto se debe a que se crea en una subred pública y tiene una dirección IP pública a la que se puede acceder en Internet. A continuación, el equilibrador de carga de red abre una conexión con la dirección IP privada del host que ejecuta el contenedor y envía los paquetes del lado público al lado privado.

Características del equilibrador de carga de red

Como el equilibrador de carga de red funciona en un nivel inferior de la pila de redes, no tiene el mismo conjunto de funciones que el equilibrador de carga de aplicación. Sin embargo, tiene las siguientes características importantes.

  • Cifrado de extremo a extremo: dado que el equilibrador de carga de red funciona en la cuarta capa del modelo OSI, no lee el contenido de los paquetes. Esto lo hace adecuado para equilibrar la carga de comunicaciones que requieren cifrado de extremo a extremo.

  • Cifrado TLS: además del cifrado de extremo a extremo, el equilibrador de carga de red también puede finalizar las conexiones TLS. De esta forma, las aplicaciones de backend no tienen que implementar su propio TLS.

  • Compatibilidad con UDP: dado que el equilibrador de carga de red funciona en la cuarta capa del modelo OSI, es adecuado para cargas de trabajo que no sean HTTP y protocolos distintos de TCP.

Cierre de conexiones

Como el equilibrador de carga de red no observa el protocolo de aplicación en las capas superiores del modelo OSI, no puede enviar mensajes de cierre a los clientes de esos protocolos. A diferencia del equilibrador de carga de aplicación, la aplicación debe cerrar esas conexiones o puede configurar el equilibrador de carga de red para las conexiones de la cuarta capa se cierren cuando se detenga o se reemplace una tarea. Consulte la configuración de finalización de la conexión para los grupos objetivo del equilibrador de carga de red en la documentación del equilibrador de carga de red.

Permitir que el equilibrador de carga de red cierre las conexiones en la cuarta capa puede provocar que los clientes muestren mensajes de error no deseados si el cliente no los gestiona. Consulte la Biblioteca de Constructores para obtener más información sobre la configuración de cliente recomendada aquí .

Los métodos para cerrar las conexiones varían según la aplicación; sin embargo, una forma consiste en garantizar que el retraso de anulación del registro de destino del equilibrador de carga de red sea superior al tiempo de espera de la conexión del cliente. De este modo, primero el cliente agota el tiempo de espera y se vuelve a conectar correctamente a la siguiente tarea a través del equilibrador de carga de red, mientras que la tarea anterior vacía lentamente todos sus clientes. Para obtener más información sobre el retraso de anulación del registro de destino del equilibrador de carga de red, consulte la documentación del equilibrador de carga de red.

API HTTP de Amazon API Gateway

Amazon API Gateway es adecuado para aplicaciones HTTP con ráfagas repentinas en los volúmenes de solicitudes o volúmenes de solicitudes bajos. Para obtener más información consulte ¿Qué es Amazon API Gateway? en la Guía para desarrolladores de API Gateway.

Diagrama que muestra la arquitectura de una red que utiliza API Gateway.

El modelo de precios tanto del equilibrador de carga de aplicación como del equilibrador de carga de red incluye un precio por hora para mantener los equilibradores de carga disponibles para aceptar conexiones entrantes en todo momento. Por el contrario, API Gateway cobra por cada solicitud por separado. Esto tiene como consecuencia que, si no se recibe ninguna solicitud, no hay cargos. En condiciones de mucho tráfico, un equilibrador de carga de aplicación o equilibrador de carga de red puede gestionar un mayor volumen de solicitudes a un precio por solicitud más económico que API Gateway. Sin embargo, si tiene un número reducido de solicitudes en general o tiene periodos de poco tráfico, el precio acumulado por usar API Gateway debería ser más rentable que pagar una tarifa por hora para mantener un equilibrador de carga que se está infrautilizando. Además, API Gateway puede almacenar en la caché las respuestas de la API, lo que podría dar lugar a tasas de solicitudes de backend más bajas.

Las funciones de API Gateway utilizan un enlace de VPC que permite que el servicio administrado de AWS se conecte a los hosts de la subred privada de la VPC mediante su dirección IP privada. Puede detectar estas direcciones IP privadas consultando los registros de detección de servicios de AWS Cloud Map administrados por Detección de servicios de Amazon ECS.

API Gateway admite las siguientes características.

  • El funcionamiento de API Gateway es similar al de un equilibrador de carga, pero tiene capacidades adicionales exclusivas para la administración de API

  • API Gateway ofrece capacidades adicionales en torno a la autorización del cliente, los niveles de uso y la modificación de solicitudes/respuestas. Para obtener más información, consulte Características de Amazon API Gateway.

  • API Gateway puede admitir puntos de conexión para puertas de enlace de API privadas, regionales y periféricas. Los puntos de conexión periféricos están disponibles a través de una distribución administrada de CloudFront. Tanto los puntos de conexión regionales como los privados son locales de una región.

  • Finalización de SSL/TLS

  • Direccionamiento de distintas rutas HTTP a diferentes microservicios de backend

Además de las características anteriores, API Gateway también admite el uso de autorizadores de Lambda personalizados que puede utilizar para proteger su API de usos no autorizados. Para obtener más información, consulte Notas de campo: API basadas en contenedores sin servidor con Amazon ECS y Amazon API Gateway.