# Prácticas recomendadas para redes de Amazon ECS
Por lo general, las aplicaciones modernas se crean a partir de varios componentes distribuidos que se comunican entre sí. Por ejemplo, una aplicación móvil o web puede comunicarse con un punto de conexión de la API, y la API puede interactuar con varios microservicios que se comunican a través de Internet.
Para obtener información sobre las prácticas recomendadas para conectar las aplicaciones a Internet, consulte [Conexión de las aplicaciones de Amazon ECS a Internet](networking-outbound.md).
Para obtener información sobre las prácticas recomendadas para recibir conexiones entrantes a Amazon ECS desde Internet, consulte [Prácticas recomendadas para recibir conexiones entrantes a Amazon ECS desde Internet](networking-inbound.md).
Para obtener información sobre las prácticas recomendadas para conectar Amazon ECS a otros servicios de AWS, consulte [Prácticas recomendadas para conectar Amazon ECS a los servicios de AWS desde su VPC](networking-connecting-vpc.md).
Para obtener más información sobre las prácticas recomendadas para conectar servicios dentro de la VPC, consulte [Prácticas recomendadas para conectar los servicios de Amazon ECS en una VPC](networking-connecting-services.md).
Para obtener información sobre las prácticas recomendadas para los servicios de red entre las Cuentas de AWS y las VPC, consulte [Prácticas recomendadas para conectar en red los servicios de Amazon ECS entre Cuentas de AWS y las VPC](networking-connecting-services-crossaccount.md).
Para obtener información sobre las prácticas recomendadas para los servicios de solución de problemas de las redes, consulte [Servicios de AWS para la solución de problemas de redes de Amazon ECS](networking-troubleshooting.md).
# Conexión de las aplicaciones de Amazon ECS a Internet
La mayoría de las aplicaciones en contenedores tienen al menos algunos componentes que necesitan acceso de salida a Internet. Por ejemplo, el backend de una aplicación móvil requiere acceso de salida a las notificaciones push.
Amazon Virtual Private Cloud cuenta con dos métodos principales para facilitar la comunicación entre su VPC e Internet.
## Subred pública y puerta de enlace de Internet
![\[Diagrama que muestra la arquitectura de una subred pública conectada a una puerta de enlace de Internet.\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/images/public-network.png)
Cuando usa una subred pública que tiene una ruta a una puerta de enlace de Internet, la aplicación en contenedores se puede ejecutar en un host dentro de una VPC en una subred pública. Al host que ejecuta el contenedor se le asigna una dirección IP pública. Esta dirección IP pública se puede enrutar desde Internet. Para obtener más información, consulte [Puertas de enlace de Internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html) en la *Guía del usuario de Amazon VPC*.
Esta arquitectura de red facilita la comunicación directa entre el host que ejecuta la aplicación y otros hosts de Internet. La comunicación es bidireccional. Esto significa que no solo puede establecer una conexión de salida con cualquier otro host de Internet, sino que otros hosts de Internet también podrían intentar conectarse al suyo. Por lo tanto, debe prestar mucha atención a las reglas de firewall y grupos de seguridad. Esto garantiza que otros hosts de Internet no puedan abrir ninguna conexión que no quiera que se abra.
Por ejemplo, si la aplicación se ejecuta en Amazon EC2, asegúrese de que el puerto 22 para el acceso mediante SSH no esté abierto. De lo contrario, su instancia podría recibir intentos constantes de conexión SSH por parte de bots malintencionados de Internet. Estos bots rastrean direcciones IP públicas. Cuando encuentran un puerto SSH abierto, intentan utilizar contraseñas a la fuerza para acceder a la instancia. Por este motivo, muchas organizaciones limitan el uso de las subredes públicas y prefieren tener la mayoría de sus recursos, si no todos, dentro de subredes privadas.
Optar por subredes públicas para las redes es adecuado cuando se trata de aplicaciones públicas que requieran grandes cantidades de ancho de banda o una latencia mínima. Entre los casos de uso aplicables se encuentran los servicios de streaming de vídeo y juegos.
Este enfoque con respecto a las redes se admite tanto cuando se utiliza Amazon ECS en Amazon EC2 y cuando se utiliza en AWS Fargate.
+ Amazon EC2: puede lanzar instancias de EC2 en una subred pública. Amazon ECS usa estas instancias de EC2 como capacidad del clúster y cualquier contenedor que se ejecute en las instancias puede usar la dirección IP pública subyacente del host para las redes salientes. Esto se aplica a los modos de red de `host` y `bridge`. Sin embargo, el modo de red `awsvpc` no proporciona las ENI de tarea con direcciones IP públicas. Por lo tanto, no pueden utilizar directamente una puerta de enlace de Internet.
+ Fargate: cuando cree su servicio de Amazon ECS, especifique las subredes públicas para la configuración de red de su servicio y utilice la opción **Asignar dirección IP pública**. Cada tarea de Fargate está conectada a la subred pública y tiene su propia dirección IP pública para la comunicación directa con Internet.
## Subred privada y puerta de enlace NAT
![\[Diagrama que muestra la arquitectura de una subred privada conectada a una puerta de enlace NAT.\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/images/private-network.png)
Cuando usa una subred privada y una puerta de enlace NAT, puede ejecutar la aplicación en contenedores en un host que se encuentre en una subred privada. Por lo tanto, este host tiene una dirección IP privada que se puede enrutar dentro de la VPC, pero no se puede enrutar desde Internet. Esto significa que otros hosts de la VPC pueden conectarse al host mediante su dirección IP privada, pero los hosts de Internet no pueden establecer ninguna comunicación entrante con el host.
Con una subred privada, puede utilizar una puerta de enlace de traducción de direcciones de red (NAT) para permitir que un host dentro de una subred privada se conecte a Internet. Los hosts de Internet reciben una conexión entrante que parece provenir de la dirección IP pública de la puerta de enlace NAT que se encuentra dentro de una subred pública. La puerta de enlace de NAT es responsable de actuar como puente entre Internet y la subred privada. Esta configuración suele preferirse por motivos de seguridad, ya que significa que su VPC está protegida del acceso directo de los atacantes de Internet. Para obtener información, consulte [Gateways NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) en la *Guía del usuario de Amazon VPC*.
Este enfoque respecto a las redes privadas es adecuado para situaciones en las que desee proteger los contenedores frente al acceso externo directo. Entre los escenarios aplicables se encuentran los sistemas de procesamiento de pagos o los contenedores que almacenan datos de usuario y contraseñas. Se le cobrará por la creación y el uso de una gateway NAT en su cuenta. Además, se aplican tarifas de procesamiento de datos y uso por horas de la puerta de enlace NAT. Para obtener redundancia, debe tener una puerta de enlace NAT en cada zona de disponibilidad. De esta forma, la pérdida de disponibilidad de una única zona de disponibilidad no pone en peligro su conectividad de salida. Por ello, si tiene una carga de trabajo pequeña, podría resultar más rentable utilizar subredes privadas y puertas de enlace NAT.
Este enfoque con respecto a las redes se admite tanto cuando se utiliza Amazon ECS en Amazon EC2 y cuando se utiliza en AWS Fargate.
+ Amazon EC2: puede lanzar instancias de EC2 en una subred privada. Los contenedores que se ejecutan en estos hosts de EC2 utilizan las redes de los hosts subyacentes y las solicitudes de salida atraviesan la puerta de enlace NAT.
+ Fargate: cuando cree su servicio de Amazon ECS, especifique las subredes privadas para la configuración de red de su servicio y no utilice la opción **Asignar dirección IP pública**. Cada tarea de Fargate está alojada en una subred privada. Su tráfico de salida se enruta a través de cualquier puerta de enlace NAT que haya asociado a esa subred privada.
# 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?](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) 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.\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/images/alb-ingress.png)
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?](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) 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.\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/images/nlbingress.png)
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 de destino del equilibrador de carga de red en la [documentación del equilibrador de carga de red](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#deregistration-delay).
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í ](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter).
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.](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-target-groups.html#deregistration-delay)
## 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?](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) en la *Guía para desarrolladores de API Gateway*.
![\[Diagrama que muestra la arquitectura de una red que utiliza API Gateway.\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/images/apigateway-ingress.png)
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](https://aws.amazon.com//api-gateway/features/).
+ 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](https://aws.amazon.com/blogs/architecture/field-notes-serverless-container-based-apis-with-amazon-ecs-and-amazon-api-gateway/).
# Prácticas recomendadas para conectar Amazon ECS a los servicios de AWS desde su VPC
Para que Amazon ECS funcione correctamente, el agente de contenedor de Amazon ECS, que se ejecuta en cada host, debe comunicarse con el plano de control de Amazon ECS. Si va a almacenar las imágenes del contenedor en Amazon ECR, los hosts de Amazon EC2 deben comunicarse con el punto de conexión del servicio de Amazon ECR y con Amazon S3, donde se almacenan las capas de las imágenes. Si utiliza otros servicios de AWS para la aplicación en contenedores, como los datos persistentes almacenados en DynamoDB, compruebe que estos servicios también cuenten con el soporte de red necesario.
## Puerta de enlace de NAT
El uso de una puerta de enlace NAT es la forma más sencilla de garantizar que sus tareas de Amazon ECS puedan acceder a otros servicios de AWS. Para obtener más información acerca de este enfoque, consulte [Subred privada y puerta de enlace NAT](networking-outbound.md#networking-private-subnet).
![\[Diagrama que muestra la arquitectura de una red que utiliza una puerta de enlace NAT.\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/images/natgateway.png)
A continuación, se muestran las desventajas de utilizar este enfoque:
+ No se pueden limitar los destinos con los que puede comunicarse la puerta de enlace NAT. Tampoco se pueden limitar los destinos con los que puede comunicarse su nivel de backend sin interrumpir todas las comunicaciones salientes de su VPC.
+ Las puertas de enlace NAT cobran por cada GB de datos que pasan por ellas. Si utiliza la puerta de enlace NAT para alguna de las siguientes operaciones, se le cobrará por cada GB de ancho de banda utilizado:
+ Descarga de archivos grandes desde Amazon S3
+ Realización de consultas extensivas sobre bases de datos en DynamoDB
+ Extracción de imágenes desde Amazon ECR
Además, las puertas de enlace NAT admiten 5 Gbps de ancho de banda y escalan automáticamente hasta 45 Gbps. Si el enrutamiento se realiza a través de una única puerta de enlace NAT, las aplicaciones que requieren conexiones de ancho de banda muy elevado pueden experimentar limitaciones de red. Como solución alternativa, puede dividir la carga de trabajo en varias subredes y asignar a cada subred su propia puerta de enlace NAT.
## AWS PrivateLink
AWS PrivateLink proporciona conectividad privada entre las VPC, los servicios de AWS y las redes en las instalaciones sin exponer el tráfico a la Internet pública.
Un punto de conexión de VPC habilita conexiones privadas entre la VPC y los servicios de AWS, así como los servicios de punto de conexión de VPC admitidos. El tráfico entre su VPC y el servicio no sale de la red de Amazon. Un punto de conexión de VPC no requiere una puerta de enlace de Internet, una puerta de enlace privada virtual, un dispositivo NAT, una conexión de VPN ni una conexión de Direct Connect. Las instancias de Amazon EC2 en su VPC no necesitan direcciones IP públicas para comunicarse con los recursos del servicio.
El siguiente diagrama muestra cómo funciona la comunicación con los servicios de AWS cuando se utilizan puntos de conexión de VPC en lugar de una puerta de enlace de Internet. AWS PrivateLink proporciona interfaces de red elásticas (ENI) dentro de la subred y las reglas de enrutamiento de VPC se utilizan para enviar cualquier comunicación al nombre de host del servicio a través de la ENI, directamente al servicio de destino de AWS. Este tráfico ya no necesita usar la puerta de enlace NAT ni la puerta de enlace de Internet.
![\[Diagrama que muestra la arquitectura de una red que utiliza AWS PrivateLink\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/images/endpointaccess-multiple.png)
A continuación, se enumeran algunos de los puntos de conexión de VPC comunes que se utilizan con el servicio de Amazon ECS.
+ [Puntos de conexión de puerta de enlace para Amazon S3](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html)
+ [Punto de conexión de VPC de DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/vpc-endpoints-dynamodb.html)
+ [Punto de conexión de VPC de Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/vpc-endpoints.html)
+ [Punto de conexión de VPC de Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html)
Otros servicios de AWS son compatibles con puntos de conexión de VPC. Si hace un uso intensivo de algún servicio de AWS, debe consultar la documentación específica de ese servicio y saber cómo crear un punto de conexión de VPC para ese tráfico.
# Prácticas recomendadas para conectar los servicios de Amazon ECS en una VPC
Al utilizar las tareas de Amazon ECS en una VPC, puede dividir las aplicaciones monolíticas en partes independientes que se pueden implementar y escalar de forma independiente en un entorno seguro. Esta arquitectura se conoce como arquitectura orientada a servicios (SOA) o microservicios. Sin embargo, puede resultar difícil garantizar que todas estas partes, tanto dentro como fuera de una VPC, puedan comunicarse entre sí. Existen diversos enfoques para facilitar la comunicación, cada uno con sus respectivas ventajas y desventajas.
## Uso de Service Connect
Recomendamos Service Connect, que proporciona la configuración de Amazon ECS para la detección de servicios, la conectividad y la supervisión del tráfico. Con Service Connect, sus aplicaciones pueden utilizar nombres abreviados y puertos estándar para conectarse a los servicios del mismo clúster o a otros clústeres, incluso a través de VPC dentro de la misma región. Para obtener más información, consulte [Amazon ECS Service Connect](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-connect.html).
Cuando utiliza Service Connect, Amazon ECS administra todas las partes de la detección de servicios: crea los nombres que se pueden descubrir, administra dinámicamente las entradas de cada tarea a medida que se inician y se detienen las tareas y ejecuta un agente en cada tarea que está configurado para descubrir los nombres. La aplicación puede buscar los nombres mediante la funcionalidad estándar para los nombres de DNS y establecer conexiones. Si su aplicación ya lo hace, no tendrá que modificarla para usar Service Connect.
![\[Diagrama que muestra la arquitectura de una red que utiliza Service Connect.\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/images/serviceconnect.png)
**Los cambios solo se realizan durante las implementaciones.**
Usted proporciona la configuración completa dentro de cada definición de servicio y tarea. Amazon ECS administra los cambios en esta configuración en cada implementación de servicio para garantizar que todas las tareas de una implementación se comporten de la misma manera. Por ejemplo, un problema común con el DNS en la detección de servicios es el control de una migración. Si cambia un nombre de DNS para que apunte a las nuevas direcciones IP de reemplazo, es posible que pase el tiempo máximo de TTL antes de que todos los clientes comiencen a usar el nuevo servicio. Con Service Connect, la implementación del cliente actualiza la configuración sustituyendo las tareas del cliente. Puede configurar el disyuntor de implementación y otras configuraciones de implementación para que afecten a los cambios de Service Connect de la misma manera que cualquier otra implementación.
## Uso de la detección de servicios
Otro enfoque para la comunicación de servicio a servicio es la comunicación directa mediante la detección de servicios. En este enfoque, puede utilizar la integración de detección de servicios AWS Cloud Map con Amazon ECS. Mediante la detección de servicios, Amazon ECS sincroniza la lista de tareas iniciadas en AWS Cloud Map, que mantiene un nombre de host DNS que se resuelve en las direcciones IP internas de una o más tareas de ese servicio en particular. Otros servicios de Amazon VPC pueden usar este nombre de host DNS para enviar tráfico directamente a otro contenedor mediante su dirección IP interna. Para obtener más información, consulte [Detección de servicios](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html).
![\[Diagrama que muestra la arquitectura de una red que utiliza una detección de servicios.\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/images/servicediscovery.png)
En el diagrama anterior, hay tres servicios. El `service-a-local` tiene un contenedor y se comunica con el `service-b-local`, que tiene dos contenedores. El `service-b-local` también debe comunicarse con el `service-c-local`, que tiene un contenedor. Cada contenedor de estos tres servicios puede usar los nombres DNS internos desde AWS Cloud Map para buscar las direcciones IP internas de un contenedor del servicio descendente con el que necesita comunicarse.
Este enfoque de comunicación de servicio a servicio proporciona una baja latencia. A primera vista, este enfoque es sencillo porque no hay componentes adicionales entre los contenedores. El tráfico viaja directamente de un contenedor al otro.
Este enfoque es adecuado cuando se utiliza el modo de red `awsvpc`, en el que cada tarea tiene su propia dirección IP única. La mayoría de los programas solo admiten el uso de registros `A` de DNS, que se resuelven directamente en las direcciones IP. Cuando se utiliza el modo de red `awsvpc`, la dirección IP de cada tarea es un registro `A`. Sin embargo, si utiliza el modo de red `bridge`, es posible que varios contenedores compartan la misma dirección IP. Además, las asignaciones dinámicas de puertos hacen que a los contenedores se les asignen números de puerto de forma aleatoria en esa única dirección IP. En este punto, un registro `A` ya no es suficiente para la detección de servicios. También debe usar un registro `SRV`. Este tipo de registro puede hacer un seguimiento de las direcciones IP y los números de puerto, pero requiere que configure las aplicaciones de forma adecuada. Es posible que algunas aplicaciones prediseñadas que utilice no admitan registros `SRV`.
Otra ventaja del modo de red `awsvpc` es que tiene un grupo de seguridad único para cada servicio. Puede configurar este grupo de seguridad para permitir las conexiones entrantes únicamente desde los servicios ascendentes específicos que necesitan comunicarse con ese servicio.
La principal desventaja de la comunicación directa entre servicios mediante la detección de servicios es que se debe implementar una lógica adicional para llevar a cabo reintentos y solucionar los errores de conexión. Los registros de DNS tienen un período de vida (TTL) que controla el periodo durante el que se almacenan en caché. El registro DNS tarda algún tiempo en actualizarse y la caché en caducar para que las aplicaciones puedan recoger la última versión del registro DNS. Por lo tanto, su aplicación podría terminar resolviendo el registro DNS para que apunte a otro contenedor que ya no está allí. Su aplicación debe gestionar los reintentos y tener una lógica para ignorar los backends defectuosos.
## Uso de un equilibrador de carga interno
Otro enfoque para la comunicación entre servicios es utilizar un equilibrador de carga interno. El equilibrador de carga interno reside completamente dentro de la VPC y solo los servicios dentro de la VPC pueden acceder a él.
![\[Diagrama que muestra la arquitectura de una red que utiliza un equilibrador de carga interno.\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/images/loadbalancer-internal.png)
El equilibrador de carga mantiene una alta disponibilidad mediante la implementación de recursos redundantes en cada subred. Cuando un contenedor de `serviceA` necesita comunicarse con un contenedor de `serviceB`, abre una conexión con el equilibrador de carga. Luego, el equilibrador de carga abre una conexión a un contenedor del `service B`. El equilibrador de carga actúa como un punto centralizado para gestionar todas las conexiones entre los servicios.
Si un contenedor del `serviceB` se detiene, el equilibrador de carga puede retirar ese contenedor del grupo. El equilibrador de carga también lleva a cabo comprobaciones de estado de cada uno de los destinos intermedios de su grupo y puede eliminar automáticamente los destinos defectuosos del grupo hasta que vuelvan a estar en buen estado. Las aplicaciones ya no necesitan conocer la cantidad de contenedores descendentes. Solo abren sus conexiones a través del equilibrador de carga.
Este enfoque es ventajoso para todos los modos de red. El equilibrador de carga puede realizar un seguimiento de las direcciones IP cuando se usa el modo de red de `awsvpc`, así como de las combinaciones más avanzadas de direcciones IP y puertos cuando se usa el modo de red de `bridge`. Distribuye el tráfico de manera uniforme entre todas las combinaciones de direcciones IP y puertos, incluso si varios contenedores están alojados en la misma instancia de Amazon EC2, pero en puertos diferentes.
La única desventaja de este enfoque es el costo. Para garantizar una alta disponibilidad, el equilibrador de carga debe tener recursos en cada zona de disponibilidad. Esto implica un costo adicional debido a la sobrecarga de pagar por el equilibrador de carga y por la cantidad de tráfico que maneja.
Sin embargo, puede reducir los costos generales si varios servicios comparten un equilibrador de carga. Esto es particularmente útil para los servicios de REST que utilizan un equilibrador de carga de aplicación. Puede crear reglas de enrutamiento basadas en rutas que dirijan el tráfico a diferentes servicios. Por ejemplo, `/api/user/*` podría dirigir el tráfico a un contenedor que forma parte del servicio de `user`, mientras que `/api/order/*` podría dirigir el tráfico al servicio de `order` asociado. Con este enfoque, solo paga por un equilibrador de carga de aplicación y dispone de una URL coherente para su API. Sin embargo, puede dividir el tráfico en varios microservicios del backend.
# Prácticas recomendadas para conectar en red los servicios de Amazon ECS entre Cuentas de AWS y las VPC
Si forma parte de una organización con varios equipos y divisiones, probablemente implemente los servicios de forma independiente en VPC separadas dentro de una Cuenta de AWS compartida o en las VPC asociadas a varias Cuentas de AWS individuales. Independientemente de la forma en que implemente sus servicios, le recomendamos que complemente los componentes de red para ayudar a enrutar el tráfico entre las VPC. Para ello, se pueden utilizar varios servicios de AWS para complementar los componentes de red existentes.
+ AWS Transit Gateway: primero debe considerar este servicio de red. Este servicio actúa como un centro para enrutar las conexiones entre las VPC de Amazon, las Cuentas de AWS y las redes en las instalaciones. Para obtener más información, consulte [¿Qué es una puerta de enlace de tránsito?](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) en la *Guía de puertas de enlace de tránsito de VPC de Amazon*.
+ Compatibilidad con Amazon VPC y VPN: puede utilizar este servicio para crear conexiones VPN de sitio a sitio y conectar redes en las instalaciones a su VPC. Para obtener más información, consulte [¿Qué es AWS Site-to-Site VPN?](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) en la *Guía del usuario de AWS Site-to-Site VPN*.
+ Amazon VPC: puede utilizar el emparejamiento de Amazon VPC para conectar varias VPC, ya sea en la misma cuenta o entre cuentas. Para obtener más información, consulte [¿Qué es una conexión de emparejamiento de VPC?](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html) en la *Amazon VPC Peering Guide*.
+ VPC compartidas: puede usar una VPC y subredes de VPC en varias cuentas de AWS. Para obtener más información, consulte [Uso de VPC compartidas](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html) en la *Guía del usuario de Amazon VPC*.
# Servicios de AWS para la solución de problemas de redes de Amazon ECS
Los siguientes servicios y características pueden ayudarlo a obtener información sobre las configuraciones de su red y sus servicios. Puede utilizar esta información para solucionar problemas de red y optimizar sus servicios.
## CloudWatch Container Insights
CloudWatch Container Insights recopila, agrega y resume métricas y registros de las aplicaciones y microservicios en contenedores. Las métricas incluyen la utilización de recursos como CPU, memoria, disco y red. Las métricas están disponibles en los paneles automáticos de CloudWatch. Para obtener más información, consulte [Configuración de la información de contenedores en Amazon ECS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-ECS.html) en la *Guía del usuario de Amazon CloudWatch*.
## AWS X-Ray
AWS X-Ray es un servicio de rastreo que puede utilizar para recopilar información sobre las solicitudes de red que realiza su aplicación. Puede usar el SDK para instrumentar su aplicación y capturar los tiempos y los códigos de respuesta del tráfico entre sus servicios, así como entre sus servicios y los puntos de conexión de los servicios de AWS. Para obtener más información, consulte [¿Qué es AWS X-Ray?](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) en la *Guía para desarrolladores de AWS X-Ray*.
También puede explorar los gráficos de AWS X-Ray que muestran la forma en que sus servicios se conectan entre sí. O utilícelos para explorar estadísticas agregadas sobre el rendimiento de cada enlace de servicio a servicio. Por último, puede profundizar en cualquier transacción específica para ver cómo se asocian los segmentos que representan las llamadas de red a esa transacción en particular.
Puede utilizar estas características para identificar si hay un cuello de botella en la red o si un servicio específico de su red no funciona según lo esperado.
## Logs de flujo de VPC
Puede utilizar los registros de flujo de Amazon VPC para analizar el rendimiento de la red y solucionar problemas de conectividad. Con los registros de flujo de la VPC habilitados, puede capturar un registro de todas las conexiones de la VPC. Entre estas conexiones se incluyen las interfaces de red asociadas a Elastic Load Balancing, Amazon RDS, las puertas de enlace NAT y otros servicios clave de AWS que pueda estar utilizando. Para obtener más información, consulte [Registros de flujo de VPC](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) en la *Guía del usuario de Amazon VPC*.
## Consejos de ajuste de red
Existen varias configuraciones que puede ajustar para mejorar el rendimiento de su red.
### Nofile ulimit
Si espera que su aplicación tenga mucho tráfico y maneje muchas conexiones simultáneas, debe tener en cuenta la cuota del sistema respecto al número de archivos permitidos. Cuando hay muchos sockets de red abiertos, cada uno debe estar representado por un descriptor de archivo. Si la cuota de descriptores de archivos es demasiado baja, se limitará el número de sockets de red. Esto provocará errores o conexiones fallidas. Puede actualizar la cuota específica del contenedor para el número de archivos en la definición de tareas de Amazon ECS. Si utiliza Amazon EC2 (en lugar de AWS Fargate), es posible que también tenga que ajustar estas cuotas en su instancia de Amazon EC2 subyacente.
### Red sysctl
Otra categoría de configuración ajustable es la configuración de red de `sysctl`. Debe consultar la configuración específica de la distribución de Linux que prefiera. Muchas de estas configuraciones ajustan el tamaño de los búferes de lectura y escritura. Esto puede ser útil en situaciones donde se ejecutan instancias de Amazon EC2 a gran escala que contienen muchos contenedores.