

# Clústeres de Amazon ECS
<a name="clusters"></a>

Un clúster de Amazon ECS es una agrupación lógica de tareas o servicios que proporciona la capacidad de infraestructura para las aplicaciones alojadas en contenedores. Al crear un clúster, puede elegir entre los tres tipos de infraestructura principales, cada uno optimizado para distintos casos de uso y requisitos operativos.

## Elección del tipo de clúster correcto
<a name="cluster-types-overview"></a>

Amazon ECS ofrece tres tipos de infraestructura para los clústeres. Elija el tipo que mejor se adapte a sus requisitos de carga de trabajo, preferencias operativas y objetivos de optimización de costos:

Instancias administradas de Amazon ECS (recomendadas)  
**La mejor opción para la mayoría de las cargas de trabajo**: AWS administra en su totalidad las instancias de Amazon EC2 subyacentes, lo que incluye el aprovisionamiento, la aplicación de parches y el escalado. Esta opción proporciona el equilibrio óptimo entre rendimiento, rentabilidad y simplicidad operativa.  
**Usar cuando:**  
+ Desea que AWS gestione la administración de infraestructuras
+ Necesita una computación rentable con optimización automática
+ Desea centrarse en las aplicaciones en lugar de en la infraestructura
+ Necesita un rendimiento predecible con un escalado flexible

Fargate  
**Computación sin servidor**: pague solo por los recursos que utilicen las tareas sin administrar ninguna infraestructura. Ideal para cargas de trabajo variables y para empezar rápidamente.  
**Usar cuando:**  
+ Desea operaciones completamente sin servidor
+ Tiene cargas de trabajo impredecibles o variables
+ Desea minimizar la sobrecarga operativa
+ Necesita una implementación y un escalado rápidos

Instancias de Amazon EC2  
**Control total**: usted administra directamente las instancias de Amazon EC2 subyacentes, incluida la selección, la configuración y el mantenimiento de las instancias.  
**Usar cuando:**  
+ Necesita configuraciones o tipos de instancias específicos
+ Tiene una infraestructura de Amazon EC2 existente que puede aprovechar
+ Necesita AMI personalizadas o software especializado
+ Necesita el máximo control sobre la infraestructura subyacente

**nota**  
Instancias administradas de Amazon ECS es la opción recomendada para la mayoría de las cargas de trabajo nuevas, ya que ofrece la mejor combinación de rendimiento, optimización de costos y simplicidad operativa, a la vez que permite que AWS gestione las tareas de administración de la infraestructura.

## Componentes del clúster
<a name="cluster-components"></a>

Además de la capacidad de la infraestructura, un clúster consta de los siguientes recursos:
+ La red (VPC y subred) en la que se ejecutan sus tareas y servicios

  Cuando utiliza instancias administradas de Amazon ECS o instancias de Amazon EC2 para la capacidad, la subred puede estar en zonas de disponibilidad, zonas locales, zonas de Wavelength o AWS Outposts.
+ Un espacio de nombres opcional

  Un espacio de nombres se utiliza para la comunicación de servicio a servicio con Service Connect.
+ Una opción de monitoreo

  CloudWatch Container Insights tiene un coste adicional y es un servicio totalmente administrado. Recopila, agrega y resume automáticamente métricas y registros de Amazon ECS. 

## Conceptos de clústeres
<a name="cluster-concepts"></a>

A continuación, se muestran los conceptos generales sobre los clústeres de Amazon ECS.
+ Se crean clústeres para separar los recursos.
+ Los clústeres son específicos de la Región de AWS.
+ Los clústeres pueden tener alguno de los estados que se indican a continuación.  
ACTIVE  
El clúster está listo para aceptar tareas y, si procede, puede registrar instancias de contenedor con él.  
PROVISIONING  
El clúster tiene proveedores de capacidad asociados y se están creando los recursos necesarios para el proveedor de capacidad.  
DEPROVISIONING  
El clúster tiene proveedores de capacidad asociados y se están eliminando los recursos necesarios para el proveedor de capacidad.  
ERROR  
El clúster tiene proveedores de capacidad asociados y no se han podido crear los recursos necesarios para el proveedor de capacidad.  
INACTIVE  
El clúster se ha eliminado. Es posible que los clústeres con estado `INACTIVE` permanezcan detectables en la cuenta durante un período de tiempo. Este comportamiento está sujeto a cambios en el futuro, por lo que asegúrese de no contar con la permanencia de los clústeres `INACTIVE`.
+ Un clúster puede contener una combinación de tareas alojadas en instancias administradas de Amazon ECS, AWS Fargate, instancias de Amazon EC2 o instancias externas. Las tareas se pueden poner en marcha en una infraestructura de instancias administradas de Amazon ECS, Fargate o EC2 como un tipo de lanzamiento o una estrategia de proveedor de capacidad. Si utiliza proveedores de capacidad de EC2, Amazon ECS no rastrea ni escala la capacidad de los grupos de Amazon EC2 Auto Scaling.
+ Un clúster puede contener una combinación de proveedores de capacidad de instancias administradas de Amazon ECS, proveedores de capacidad de grupo de escalado automático y proveedores de capacidad de Fargate. Una estrategia de proveedores de capacidad solo puede contener proveedores de capacidad de instancias administradas de Amazon ECS, proveedores de capacidad de grupo de escalado automático o proveedores de capacidad de Fargate.
+ Puede utilizar diferentes tipos de instancias para las instancias administradas de Amazon ECS y EC2, o proveedores de capacidad de grupo de escalado automático. Una instancia solo se puede registrar en un clúster a la vez.
+ Puede restringir el acceso a clústeres mediante la creación de políticas de IAM personalizadas. Para obtener más información, consulte la sección [Ejemplos de clústeres de Amazon ECS](security_iam_id-based-policy-examples.md#IAM_cluster_policies) en [Ejemplos de políticas basadas en identidades de Amazon Elastic Container Service](security_iam_id-based-policy-examples.md).
+ Puede utilizar el escalado automático de servicios para escalar las tareas de Fargate. Para obtener más información, consulte [Escalado automático de su servicio de Amazon ECS](service-auto-scaling.md).
+ Puede configurar un espacio de nombres de Service Connect predeterminado para un clúster. Después de configurar un espacio de nombres de Service Connect predeterminado, todos los servicios nuevos que se creen en el clúster se pueden agregar como servicios de cliente al espacio de nombres al activar Service Connect. No se necesita configuración adicional. Para obtener más información, consulte [Uso de Service Connect para conectar los servicios de Amazon ECS con nombres abreviados](service-connect.md).

## Proveedores de capacidad
<a name="capacity-providers"></a>

Los proveedores de capacidad de Amazon ECS administran el escalado de la infraestructura para las tareas de los clústeres. Cada clúster puede tener uno o más proveedores de capacidad y, opcionalmente, una estrategia de proveedor de capacidad. Puede asignar una estrategia de proveedor de capacidad predeterminada al clúster. La estrategia de proveedor de capacidad determina cómo se distribuyen las tareas entre los proveedores de capacidad del clúster. Cuando pone en marcha una tarea individual o crea un servicio, utiliza la estrategia de proveedores de capacidad predeterminada del clúster o una estrategia de proveedores de capacidad que anule la estrategia predeterminada. La estrategia de proveedor de capacidad predeterminada del clúster solo se aplica cuando no especifica un tipo de lanzamiento o una estrategia de proveedor de capacidad para la tarea o servicio. Si proporciona alguno de estos parámetros, no se utilizará la estrategia predeterminada. 

Amazon ECS ofrece tres tipos de proveedores de capacidad para sus clústeres:

Proveedores de capacidad de instancias administradas de Amazon ECS  
AWS administra en su totalidad las instancias de Amazon EC2 subyacentes, lo que incluye el aprovisionamiento, la aplicación de parches, el escalado y la administración del ciclo de vida. Esta opción proporciona el equilibrio óptimo entre rendimiento, rentabilidad y simplicidad operativa. Los proveedores de capacidad de instancias administradas de Amazon ECS optimizan automáticamente la selección y el escalado de las instancias en función de sus requisitos de carga de trabajo.  
Con instancias administradas de Amazon ECS, tiene las siguientes ventajas:  
+ Aprovisionamiento y escalado automáticos de instancias
+ Aplicación de parches y actualizaciones de seguridad administradas
+ Optimización de costos mediante la selección inteligente de instancias
+ Sobrecarga operativa reducida

Proveedores de capacidad de Fargate  
Computación sin servidor en la que solo paga por los recursos que utilicen las tareas sin administrar ninguna infraestructura. Solo tiene que asociar los proveedores de capacidad predefinidos (Fargate y Fargate Spot) al clúster.

Proveedores de capacidad de grupos de Auto Scaling  
Cuando utiliza instancias de Amazon EC2 para su capacidad, utiliza el grupo de escalado automático para administrar las instancias de Amazon EC2. El escalado automático lo ayuda a garantizar que cuenta con la cantidad correcta de instancias de Amazon EC2 disponibles para gestionar la carga de su aplicación. Tiene control total sobre la infraestructura subyacente.

Un clúster puede contener una combinación de tareas alojadas en instancias administradas de Amazon ECS, AWS Fargate, instancias de Amazon EC2 o instancias externas. Las tareas se pueden poner en marcha en una infraestructura de instancias administradas de Amazon ECS, Fargate o EC2 como un tipo de lanzamiento o una estrategia de proveedor de capacidad. Si utiliza EC2 como tipo de lanzamiento, Amazon ECS no rastrea ni escala la capacidad de los grupos de Amazon EC2 Auto Scaling. 

Un clúster puede contener una combinación de proveedores de capacidad de instancias administradas de Amazon ECS, proveedores de capacidad de grupo de escalado automático y proveedores de capacidad de Fargate. Una estrategia de proveedores de capacidad solo puede contener proveedores de capacidad de instancias administradas de Amazon ECS, proveedores de capacidad de grupo de escalado automático o proveedores de capacidad de Fargate.

# Clústeres para instancias administradas de Amazon ECS
<a name="managed-instance-clusters"></a>

Los proveedores de capacidad de Amazon ECS administran el escalado de la infraestructura para las tareas de los clústeres. Una vez creado el clúster, debe crear uno o más proveedores de capacidad y, opcionalmente, una estrategia de proveedor de capacidad para el clúster. La estrategia de proveedor de capacidad determina cómo se distribuyen las tareas entre los proveedores de capacidad del clúster. Cuando pone en marcha una tarea individual o crea un servicio, utiliza la estrategia de proveedores de capacidad predeterminada del clúster o una estrategia de proveedores de capacidad que anule la estrategia predeterminada.

Instancias administradas de Amazon ECS tiene los siguientes proveedores de capacidad.


| Tipo | Criterios utilizados para elegir las instancias | 
| --- | --- | 
| Predeterminado | Las instancias más rentables que cumplen los siguientes requisitos de definición de tareas y parámetros de servicio: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/managed-instance-clusters.html) | 
| Personalizado | Las instancias que cumplen los requisitos de atributo y tipo que se especifican al crear el clúster. Para obtener información sobre los atributos, consulte [Atributos de instancias de contenedor de Amazon ECS](task-placement-constraints.md#attributes). Para obtener información sobre los tipos de instancias, consulte [Especificaciones de los tipos de instancias de Amazon EC2](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-instance-type-specifications.html) en Tipos de instancias de Amazon EC2. | 

Amazon ECS lanza las instancias y las asocia al proveedor de capacidad de instancias administradas de Amazon ECS. Para el proveedor de capacidad personalizado, Amazon ECS también crea el proveedor de capacidad.

# Creación de un clúster para instancias administradas de Amazon ECS
<a name="create-cluster-managed-instances"></a>

Cree un clúster para definir la infraestructura en la que se ponen en marcha sus tareas y servicios. 

Al crear un clúster para instancias administradas de Amazon ECS, obtiene acceso al proveedor de capacidad `FARGATE_MANAGED_INSTANCE` de forma predeterminada. Este proveedor de capacidad selecciona automáticamente los tipos de instancias más rentables para sus cargas de trabajo. También puede crear proveedores de capacidad personalizados si necesita atributos o tipos de instancias específicos.

Para que el proceso de creación del clúster sea lo más sencillo posible, la consola tiene selecciones predeterminadas para muchas opciones.
+ El espacio de nombres predeterminado de AWS Cloud Map es el mismo nombre que el del clúster. Un espacio de nombres permite que los servicios que cree en el clúster se conecten a los demás servicios del espacio de nombres sin configuración adicional. 

  Para obtener más información, consulte [Interconexión de los servicios de Amazon ECS](interconnecting-services.md).

Puede modificar las siguientes opciones:
+ Cambie el espacio de nombres predeterminado asociado al clúster. 

  Un espacio de nombres permite que los servicios que cree en el clúster se conecten a los demás servicios del espacio de nombres sin configuración adicional. El espacio de nombres predeterminado es el mismo que el nombre del clúster. Para obtener más información, consulte [Interconexión de los servicios de Amazon ECS](interconnecting-services.md).
+ Asigne una clave AWS KMS para el almacenamiento administrado. Para obtener información acerca de la creación de una clave, consulte [Creación de una clave KMS](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) en la *Guía del usuario de AWS Key Management Service*.
+ Agregue etiquetas que le permitan identificar el clúster.

## Requisitos previos
<a name="create-cluster-managed-instances-prerequisites"></a>

Antes de comenzar, asegúrese de haber seguido los pasos que se detallan en [Configuración para utilizar Amazon ECS](get-set-up-for-amazon-ecs.md) y de asignar el permiso de IAM adecuado. Para obtener más información, consulte [Ejemplos de clústeres de Amazon ECS](security_iam_id-based-policy-examples.md#IAM_cluster_policies).

El usuario que crea el clúster debe tener un permiso adicional: `iam:CreateServiceLinkedRole`.

De forma predeterminada, Amazon ECS elige los tipos de instancias en función de los requisitos que especifica en la definición de la tarea. Este es el proveedor de capacidad predeterminado. Si necesita atributos o tipos de instancias específicos, tome nota de todos los requisitos. Deberá usar un proveedor de capacidad personalizado y, a continuación, especificar los requisitos de la instancia.

Comprenda cómo elegir sus instancias. Para obtener más información, consulte [Prácticas recomendadas para la selección de instancias en instancias administradas de Amazon ECS](managed-instances-instance-selection-best-practices.md).

Dispone de los roles de IAM necesarios para instancias administradas de Amazon ECS. Esto incluye:
+ **Rol de infraestructura**: permite a Amazon ECS realizar llamadas a los servicios de AWS en su nombre para administrar la infraestructura de instancias administradas de Amazon ECS.

  Para obtener más información, consulte [Rol de IAM de infraestructura de Amazon ECS](infrastructure_IAM_role.md).
+ **Perfil de instancia**: proporciona permisos para el agente de contenedor de Amazon ECS y el daemon de Docker que se ponen en marcha en instancias administradas.

  Para obtener más información, consulte [Perfil de instancia de instancias administradas de Amazon ECS](managed-instances-instance-profile.md).

## Procedimientos de la consola
<a name="create-cluster-managed-instances-console"></a>

**Para crear un nuevo clúster (consola de Amazon ECS)**

1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. En la barra de navegación, seleccione la región a utilizar.

1. En el panel de navegación, seleccione **Clusters (Clústeres)**.

1. En la página **Clusters** (Clústeres), elija **Create Cluster** (Crear clúster).

1. En **Configuraciones del clúster**, configure lo siguiente:
   + En **Nombre del clúster**, escriba un nombre único.

     El nombre puede contener hasta 255 letras (minúsculas y mayúsculas), números y guiones.
   + (Opcional) Para que el espacio de nombre utilizado en Service Connect sea diferente del nombre del clúster, en **Espacio de nombre**, escriba un nombre único.

1. Para **Proveedor de capacidad personalizado**, haga lo siguiente:
   + En **Seleccione un método para obtener la capacidad de EC2**, elija **Instancias administradas de Amazon ECS**.
   + En Perfil de instancia, elija el rol del perfil de instancia.
   + En Rol de infraestructura, elija el rol de infraestructura.
   + Para usar un proveedor de capacidad personalizado, en la **selección de instancias**, elija **Usar personalizado**. A continuación, introduzca el **valor del atributo** para cada atributo.

1. (Opcional) Utilice Información de contenedores, amplíe **Supervisión** y, a continuación, seleccione una de las siguientes opciones:
   + Para usar Información de contenedores con observabilidad mejorada, como se recomienda, elija **Información de contenedores con observabilidad mejorada**.
   + Para usar Información de contenedores, seleccione **Información de contenedores**.

1. (Opcional) Cifre los datos en el almacenamiento administrado. En **Cifrado**, para **Almacenamiento administrado**, introduzca el ARN de la clave AWS KMS que desea utilizar para cifrar los datos del almacenamiento administrado.

1. (Opcional) Para ayudar a identificar el clúster, expanda **Tags** (Etiquetas) y, a continuación, configure sus etiquetas.

   [Agregar una etiqueta] Elija **Agregar etiqueta** y haga lo siguiente:
   + En **Key (Clave)**, escriba el nombre de la clave.
   + En **Valor**, escriba el valor de la clave.

1. Seleccione **Crear**.

## Procedimiento de AWS CLI
<a name="create-cluster-managed-instances-cli"></a>

Puede crear un clúster para instancias administradas de Amazon ECS mediante la AWS CLI. Utilice la versión más reciente de la AWS CLI. Para obtener más información acerca de cómo actualizar a la versión más reciente, consulte [Instalación o actualización de la versión más reciente de la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).

**nota**  
Puede utilizar puntos de conexión de servicio de doble pila para interactuar con Amazon ECS desde la AWS AWS CLI, los SDK y la API de Amazon ECS a través de IPv4 e IPv6. Para obtener más información, consulte [Uso de puntos de conexión de doble pila en Amazon ECS](dual-stack-endpoint.md).

**Creación de un nuevo clúster (AWS CLI)**

1. Cree su propio clúster con un nombre único con el comando siguiente:

   ```
   aws ecs create-cluster --cluster-name managed-instances-cluster
   ```

   Salida:

   ```
   {
       "cluster": {
           "status": "ACTIVE", 
           "defaultCapacityProviderStrategy": [], 
           "statistics": [], 
           "capacityProviders": [], 
           "tags": [], 
           "clusterName": "managed-instances-cluster", 
           "settings": [
               {
                   "name": "containerInsights", 
                   "value": "disabled"
               }
           ], 
           "registeredContainerInstancesCount": 0, 
           "pendingTasksCount": 0, 
           "runningTasksCount": 0, 
           "activeServicesCount": 0, 
           "clusterArn": "arn:aws:ecs:region:aws_account_id:cluster/managed-instances-cluster"
       }
   }
   ```

1. (Opcional) Para habilitar Container Insights con una observabilidad mejorada para su clúster, utilice el siguiente comando:

   ```
   aws ecs put-account-setting --name containerInsights --value enhanced
   ```

1. (Opcional) Para agregar etiquetas a su clúster, utilice el siguiente comando:

   ```
   aws ecs tag-resource --resource-arn arn:aws:ecs:region:aws_account_id:cluster/managed-instances-cluster --tags key=Environment,value=Production
   ```

## Siguientes pasos
<a name="cluster-next-steps-managed-instances"></a>

Cree una definición de tarea para instancias administradas de Amazon ECS. Para obtener más información, consulte [Creación de una definición de tareas de Amazon ECS mediante la consola](create-task-definition.md).

Ponga en marcha sus aplicaciones como tareas independientes o como parte de un servicio. Para obtener más información, consulte los siguientes temas:
+ [Ejecución de una aplicación como tarea de Amazon ECS](standalone-task-create.md)
+ [Creación de una implementación de actualización continua de Amazon ECS](create-service-console-v2.md)

# Actualización de un clúster para usar instancias administradas de Amazon ECS
<a name="update-cluster-managed-instances"></a>

Puede actualizar un clúster existente para usar instancias administradas de Amazon ECS.

Al agregar instancias de instancias administradas de Amazon ECS al clúster, obtiene acceso al proveedor de capacidad `FARGATE_MANAGED_INSTANCE` de forma predeterminada. Este proveedor de capacidad selecciona automáticamente los tipos de instancias de uso general más rentables para sus cargas de trabajo. También puede crear proveedores de capacidad personalizados si necesita atributos o tipos de instancias específicos.

## Requisitos previos
<a name="update-cluster-managed-instances-prerequisites"></a>

De forma predeterminada, Amazon ECS elige los tipos de instancias en función de los requisitos que especifica en la definición de la tarea. Este es el proveedor de capacidad predeterminado. Si necesita atributos o tipos de instancias específicos, tome nota de todos los requisitos. Deberá usar un proveedor de capacidad personalizado y, a continuación, especificar los requisitos de la instancia.

Dispone de los roles de IAM necesarios para instancias administradas de Amazon ECS. Esto incluye:
+ **Rol de infraestructura**: permite a Amazon ECS realizar llamadas a los servicios de AWS en su nombre para administrar la infraestructura de instancias administradas de Amazon ECS.

  Para obtener más información, consulte [Rol de IAM de infraestructura de Amazon ECS](infrastructure_IAM_role.md).
+ **Perfil de instancia**: proporciona permisos para el agente de contenedor de Amazon ECS y el daemon de Docker que se ponen en marcha en instancias administradas.

  Para obtener más información, consulte [Perfil de instancia de instancias administradas de Amazon ECS](managed-instances-instance-profile.md).

## Consideraciones sobre la actualización
<a name="cluster-update-considerations-managed-instances"></a>

Cuando actualice un clúster para instancias administradas de Amazon ECS, tenga en cuenta lo siguiente:
+ Tareas en marcha: la actualización de la configuración del clúster no afecta a las tareas que estén en marcha actualmente. Los cambios se aplicarán a las nuevas tareas iniciadas después de la actualización.
+ Cambios en el proveedor de capacidad: si modifica la configuración del proveedor de capacidad, las instancias administradas existentes seguirán en marcha, pero las nuevas utilizarán la configuración actualizada.
+ Supervisión de los cambios: la habilitación o deshabilitación de Container Insights afectará a la recopilación de métricas de todo el clúster.

## Procedimientos de la consola
<a name="update-cluster-managed-instances-console"></a>

**Actualización de un clúster (consola de Amazon ECS)**

1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. En la barra de navegación, seleccione la región a utilizar.

1. En el panel de navegación, seleccione **Clusters (Clústeres)**.

1. En la página **Clústeres**, seleccione el clúster que desee actualizar.

1. Seleccione **Actualizar clúster**.

1. (Opcional) Para modificar la configuración del proveedor de capacidad, en **Proveedor de capacidad personalizado**, actualice lo siguiente según sea necesario:
   + En **Perfil de instancia**, elija otro rol del perfil de instancia si es necesario.
   + Para **Rol de infraestructura**, elija otro rol de infraestructura si es necesario.
   + Para usar un proveedor de capacidad personalizado, para **Selección de instancias**, actualice la configuración de **Valor del atributo**.

1. Elija **Actualizar**.

## Procedimiento de AWS CLI
<a name="update-cluster-managed-instances-cli"></a>

Puede actualizar un clúster para instancias administradas de Amazon ECS mediante la AWS CLI. Utilice la versión más reciente de la AWS CLI. Para obtener más información acerca de cómo actualizar a la versión más reciente, consulte [Instalación o actualización de la versión más reciente de la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).

**nota**  
Puede utilizar puntos de conexión de servicio de doble pila para interactuar con Amazon ECS desde la AWS AWS CLI, los SDK y la API de Amazon ECS a través de IPv4 e IPv6. Para obtener más información, consulte [Uso de puntos de conexión de doble pila en Amazon ECS](dual-stack-endpoint.md).

**Actualización de un clúster (AWS CLI)**

1. Cree un proveedor de capacidad para . Use el siguiente comando:

   Sustituya las *entradas del usuario* por sus valores.

   ```
   aws ecs create-capacity-provider \
       --name my-managed-instances-provider \
       --managed-instances-provider \
       --instance-profile arn:aws:iam::123456789012:instance-profile/ecsInstanceProfile \
       --infrastructure-role-arn arn:aws:iam::123456789012:role/ecsInfrastructureRole \
       --instance-requirements '{
           "vCpuCount": {"min": 2, "max": 8},
           "memoryMiB": {"min": 4096, "max": 16384}
       }
   ```

1. Para agregar el proveedor de capacidad al clúster, utilice el siguiente comando:

   Sustituya las *entradas del usuario* por sus valores.

   ```
   aws ecs put-cluster-capacity-providers --cluster managed-instances-cluster --capacity-providers my-managed-instances-provider --default-capacity-provider-strategy capacityProvider=my-managed-instances-provider,weight=1
   ```

# Proveedores de capacidad de instancias administradas de Amazon ECS
<a name="managed-instances-capacity-providers-concept"></a>

Los proveedores de capacidad de instancias administradas de Amazon ECS proporcionan un modelo de computación en contenedores que le da acceso a toda la gama de capacidades de AWS y a las ofertas de Amazon EC2, a la vez que AWS administra las responsabilidades operativas y de seguridad. AWS gestiona la aplicación de parches de software y sistema operativo, el escalado de instancias y el mantenimiento, lo que le brinda las ventajas operativas de Fargate y, al mismo tiempo, mantiene el acceso a todas las capacidades e integraciones de AWS.

Amazon ECS crea plantillas de lanzamiento para sus instancias administradas de Amazon ECS. Esto define cómo Amazon ECS lanza instancias administradas de Amazon ECS, incluido el perfil de instancia para sus tareas, la configuración de red y almacenamiento, las opciones de capacidad y los requisitos de instancia para una selección flexible del tipo de instancia.

## Cuándo utilizar proveedores de capacidad personalizados
<a name="when-to-use-managed-instances"></a>

Considere la posibilidad de utilizar proveedores de capacidad personalizados cuando sus cargas de trabajo requieran:
+ Requisitos de procesamiento específicos: aplicaciones que requieren computación acelerada, conjuntos de instrucciones de CPU específicos, alto rendimiento de red o configuraciones de memoria de gran tamaño que no están disponibles con las opciones estándar de Fargate.
+ Cargas de trabajo de GPU: inferencia de machine learning, renderización de imágenes en tiempo real, codificación de video u otras aplicaciones aceleradas por la GPU que necesiten acceder a las GPU NVIDIA o AMD.
+ Reservas de capacidad: cargas de trabajo esenciales que requieren una disponibilidad de capacidad predecible.
+ Observabilidad avanzada: herramientas de seguridad y supervisión que requieren acceso privilegiado al sistema operativo subyacente, como herramientas de análisis de red o soluciones de supervisión basadas en eBPF.
+ Optimización de costos: cargas de trabajo que pueden beneficiarse de la ubicación de múltiples tareas, de componentes de infraestructura compartidos o que necesitan maximizar el uso de tipos de instancias más grandes.

## Opciones de monitoreo
<a name="monitoring-options-managed-instances"></a>

Instancias administradas de Amazon ECS ofrece capacidades de supervisión integrales para que pueda realizar un seguimiento del rendimiento, el estado y el uso de los recursos de sus cargas de trabajo en contenedores. Puede elegir entre diferentes niveles de supervisión en función de sus requisitos operativos.
+ **Supervisión básica**: proporciona las métricas esenciales en intervalos de 5 minutos para la mayoría de las métricas y en intervalos de 1 minuto para las comprobaciones de estado. Esta característica está habilitada de forma predeterminada y no conlleva cargos adicionales.
+ **Supervisión detallada**: ofrece una visibilidad mejorada con todas las métricas disponibles en intervalos de 1 minuto, lo que permite detectar más rápidamente los problemas operativos y responder a ellos. Para obtener más información, consulte [Supervisión detallada para instancias administradas de Amazon ECS](monitoring-managed-instances.md#detailed-monitoring-managed-instances).

Ambas opciones de supervisión se integran perfectamente con CloudWatch para proporcionar paneles, alarmas y respuestas automatizadas que ayudan a mantener un rendimiento y una disponibilidad óptimos de las aplicaciones.

## Consideraciones sobre proveedores de capacidad
<a name="capacity-provider-considerations-managed-instances"></a>

Un clúster puede contener una combinación de proveedores de capacidad de instancias administradas de Amazon ECS, proveedores de capacidad de grupo de escalado automático y proveedores de capacidad de Fargate. Una estrategia de proveedores de capacidad solo puede contener proveedores de capacidad de instancias administradas de Amazon ECS, proveedores de capacidad de grupo de escalado automático o proveedores de capacidad de Fargate.

## Propagación de etiquetas
<a name="tag-propagation-managed-instances"></a>

Los proveedores de capacidad para instancias administradas de Amazon ECS admiten la propagación de etiquetas. Con la propagación de etiquetas, todos los recursos administrados por el proveedor de capacidad (la instancia administrada, la instancia de contenedor de Amazon ECS, la plantilla de lanzamiento, los volúmenes o las interfaces de red elásticas) se etiquetan con las mismas etiquetas especificadas en el nivel del proveedor de capacidad. Para especificar etiquetas durante la creación del proveedor de capacidad y habilitar la propagación de etiquetas, especifique el parámetro `propagateTags` como `CAPACITY_PROVIDER`.

Para obtener más información sobre el etiquetado de instancias administradas de Amazon ECS, consulte [Etiquetas para instancias administradas de Amazon ECS](instance-details-tags-managed-instances.md).

# Prácticas recomendadas para actualizar los proveedores de capacidad para instancias administradas de Amazon ECS
<a name="capacity-provider-managed-instances-best-practices"></a>

Para obtener el máximo nivel de seguridad y soporte de reversión, recomendamos tratar los proveedores de capacidad como recursos inmutables. Cuando necesite actualizar la configuración de un proveedor de capacidad, siga este flujo de trabajo recomendado:

1. **Cree un nuevo proveedor de capacidad** con la configuración actualizada en lugar de modificar la existente.

1. **Actualice cada servicio** para utilizar el nuevo proveedor de capacidad y permitir que se completen las implementaciones.

1. **Elimine el proveedor de capacidad anterior** tras confirmar que la nueva configuración funciona según lo previsto.

Este enfoque aporta varias ventajas:
+ **Implementación controlada**: puede actualizar los servicios de uno en uno y supervisar el impacto.
+ **Reversión sencilla**: si se producen problemas, puede revertir rápidamente los servicios para utilizar el proveedor de capacidad anterior.
+ **Radio de alcance reducido**: los problemas con la nueva configuración no afectan inmediatamente a todas las cargas de trabajo.

**nota**  
Si está utilizando CloudFormation, considere la posibilidad de conservar el antiguo proveedor de capacidad para una implementación posterior a fin de conservar la capacidad de revertir los cambios en la pila.

Si bien puede actualizar los proveedores de capacidad instalados, este enfoque crea un radio de alcance mayor e incontrolado. Las actualizaciones in situ aplican nuevos ajustes a toda la nueva capacidad aprovisionada en el futuro, pero no desencadenan implementaciones en el servicio. Esto significa que es posible que no descubra los problemas de configuración hasta mucho más tarde, cuando sus servicios necesiten escalarse.

# Creación de un proveedor de capacidad de instancias administradas de Amazon ECS
<a name="create-capacity-provider-managed-instances"></a>

Instancias administradas de Amazon ECS usa los proveedores de capacidad para administrar la capacidad de computación de las cargas de trabajo. De forma predeterminada, Amazon ECS proporciona un proveedor de capacidad predeterminado que selecciona automáticamente los tipos de instancias de uso general con los costos más optimizados. Sin embargo, puede crear proveedores de capacidad personalizados para especificar los atributos de las instancias, como los tipos de instancias, los fabricantes de CPU, los tipos de aceleradores y otros requisitos.

Los proveedores de capacidad personalizados utilizan la selección del tipo de instancia basada en atributos, lo que permite expresar los requisitos de la instancia como un conjunto de atributos. Estos requisitos se traducen automáticamente a todos los tipos de instancias de Amazon EC2 coincidentes, lo que simplifica la creación y el mantenimiento de las configuraciones de los tipos de instancia. Para obtener más información sobre los requisitos de instancia y la selección basada en atributos, consulte la documentación de [selección del tipo de instancia basada en atributos de Flota de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html) en la *Guía del usuario de Amazon EC2*.

## Requisitos previos
<a name="create-capacity-provider-managed-instances-prerequisites"></a>

Antes de comenzar, asegúrese de haber completado lo siguiente:
+ Determine qué tipo de supervisión debe usar. Para obtener más información, consulte [Supervisión detallada para instancias administradas de Amazon ECS](monitoring-managed-instances.md#detailed-monitoring-managed-instances).
+ Tenga un clúster existente o planee crear uno. Para obtener más información, consulte [Creación de un clúster para instancias administradas de Amazon ECS](create-cluster-managed-instances.md).
+ Dispone de los roles de IAM necesarios para instancias administradas de Amazon ECS. Esto incluye:
  + **Rol de infraestructura**: permite a Amazon ECS realizar llamadas a los servicios de AWS en su nombre para administrar la infraestructura de instancias administradas de Amazon ECS.

    Para obtener más información, consulte [Rol de IAM de infraestructura de Amazon ECS](infrastructure_IAM_role.md).
  + **Perfil de instancia**: proporciona permisos para el agente de contenedor de Amazon ECS y el daemon de Docker que se ponen en marcha en instancias administradas.

    Para obtener más información, consulte [Perfil de instancia de instancias administradas de Amazon ECS](managed-instances-instance-profile.md).

Comprenda cómo elegir sus instancias. Para obtener más información, consulte [Prácticas recomendadas para la selección de instancias en instancias administradas de Amazon ECS](managed-instances-instance-selection-best-practices.md).

## Procedimientos de la consola
<a name="create-capacity-provider-managed-instances-console"></a>

**Creación de un proveedor de capacidad para instancias administradas de Amazon ECS (consola de Amazon ECS)**

1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. En la barra de navegación, seleccione la región a utilizar.

1. En el panel de navegación, seleccione **Clusters (Clústeres)**.

1. En la página **Clústeres**, elija el nombre del clúster.

1. En la página del clúster: elija la pestaña **Infraestructura**.

1. En **Proveedores de capacidad**, elija **Crear proveedor de capacidad**.

1. En **Configuración del proveedor de capacidad**, configure lo siguiente:
   + En **Nombre de proveedor de capacidad**, especifique un nombre único para el proveedor de capacidad.
   + En **Tipo de proveedor de capacidad**, elija **Instancias administradas de Amazon ECS**.

1. En **Configuración de la instancia**, configure lo siguiente:
   + En **Perfil de instancia**, elija el rol de perfil de instancia creado para instancias administradas de Amazon ECS.
   + En **Rol de infraestructura**, seleccione el rol de infraestructura que creó para instancias administradas de Amazon ECS.

1. En **Requisitos de la instancia**, especifique los atributos de las instancias. Puede configurar cualquier combinación de lo siguiente:
   + **Recuento de vCPU**: especifique la cantidad de vCPU (por ejemplo, `4` o `8-16` para un rango).
   + **Memoria (MiB)**: especifique la cantidad de memoria en MiB (por ejemplo, `8192` o `16384-32768` para un rango).
   + **Tipos de instancia**: especifique tipos de instancia específicos (por ejemplo, `m5.large,m5.xlarge,c5.large`).
   + **Fabricantes de CPU**: elija entre `intel`, `amd` o `amazon-web-services`.
   + **Tipos de aceleradores**: especifique tipos de aceleradores como `gpu`, `fpga` o `inference`.
   + **Recuento de aceleradores**: especifique el número de aceleradores (por ejemplo, `1` o `2-4` para un rango).

1. En **Configuración avanzada**, elija una de las siguientes opciones de supervisión:
   + Para que CloudWatch envíe métricas de comprobación nde estado, elija **Básica**.
   + Para que CloudWatch envíe todas las métricas, seleccione **Detallada**.

1. (Opcional) Para ayudar a identificar el proveedor de capacidad, expanda **Etiquetas** y, a continuación, configure sus etiquetas.

   Para habilitar la propagación de etiquetas del proveedor de capacidad a los recursos administrados, como las instancias lanzadas desde el proveedor de capacidad, en **Propagar etiquetas desde**, elija **Proveedor de capacidad**.

   [Agregar una etiqueta] Elija **Agregar etiqueta** y haga lo siguiente:
   + En **Key (Clave)**, escriba el nombre de la clave.
   + En **Valor**, escriba el valor de la clave.

1. Seleccione **Crear**.

## Procedimiento de AWS CLI
<a name="create-capacity-provider-managed-instances-cli"></a>

Puede crear un proveedor de capacidad para instancias administradas de Amazon ECS mediante la AWS CLI. Utilice la versión más reciente de la AWS CLI. Para obtener más información acerca de cómo actualizar a la versión más reciente, consulte [Instalación o actualización de la versión más reciente de la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).

**Creación de un proveedor de capacidad de instancias administradas de Amazon ECS (AWS CLI)**

1. Use el siguiente comando:

   ```
   aws ecs create-capacity-provider --cli-input-json file://capacity-provider-definition.json
   ```

   Se puede utilizar el siguiente `capacity-provider-definition.json` para especificar los requisitos básicos de la instancia, el tamaño de almacenamiento de la instancia y permitir la propagación de etiquetas:

   ```
   {
       "name": "my-managed-instances-provider",
       "cluster": "my-cluster",
       "tags": [ 
           { 
               "key": "version",
               "value": "test"
           }
       ],    
       "managedInstancesProvider": {
           "infrastructureRoleArn": "arn:aws:iam::123456789012:role/ecsInfrastructureRole",
           "instanceLaunchTemplate": {
               "ec2InstanceProfileArn": "arn:aws:iam::123456789012:instance-profile/ecsInstanceRole",
               "instanceRequirements": {
                   "vCpuCount": {
                       "min": 4,
                       "max": 8
                   },
                   "memoryMiB": {
                       "min": 8192,
                       "max": 16384
                   }
               },
               "networkConfiguration": {
                   "subnets": [
                       "subnet-abcdef01234567",
                       "subnet-bcdefa98765432"
                   ],
                   "securityGroups": [
                       "sg-0123456789abcdef"
                   ]
               },
               "storageConfiguration": {
                   "storageSizeGiB": 100
               },
               "monitoring": "basic"
           },
           "propagateTags": "CAPACITY_PROVIDER"
       }
   }
   ```

1. Compruebe que el proveedor de capacidad se haya creado correctamente:

   ```
   aws ecs describe-capacity-providers \
       --capacity-providers my-managed-instances-provider
   ```

## Siguientes pasos
<a name="capacity-provider-managed-instances-next-steps"></a>

Después de crear su proveedor de capacidad, puede usarlo para crear servicios o poner en marcha tareas:
+ Para usar el proveedor de capacidad con un servicio, consulte [Creación de una implementación de actualización continua de Amazon ECS](create-service-console-v2.md).
+ Para usar el proveedor de capacidad con tareas independientes, consulte [Ejecución de una aplicación como tarea de Amazon ECS](standalone-task-create.md).

# Actualización de la supervisión de instancias administradas de Amazon ECS
<a name="update-capacity-provider-managed-instances"></a>

Puede modificar la opción de supervisión de su proveedor de capacidad de instancias administradas de Amazon ECS para cambiar entre la supervisión básica y la detallada. Esto le permite ajustar el nivel de los datos de supervisión recopilados sin tener que volver a crear el proveedor de capacidad.

Para obtener más información sobre las opciones de supervisión, consulte [Supervisión de instancias administradas de Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/monitoring-managed-instances.html).

## Procedimientos de la consola
<a name="update-capacity-provider-managed-instances-console"></a>

**Actualización de la supervisión de instancias administradas de Amazon ECS (consola de Amazon ECS)**

1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. En la barra de navegación, seleccione la región a utilizar.

1. En el panel de navegación, seleccione **Clusters (Clústeres)**.

1. En la página **Clústeres**, elija el nombre del clúster.

1. En la página del clúster: elija la pestaña **Infraestructura**.

1. En **Configuración avanzada**, elija una de las siguientes opciones de supervisión:
   + Para que CloudWatch envíe métricas de comprobación nde estado, elija **Básica**.
   + Para que CloudWatch envíe todas las métricas, seleccione **Detallada**.

1. Elija **Actualizar**.

Para actualizar las etiquetas asociadas a un proveedor de capacidad de instancias administradas de Amazon ECS existente, siga estos pasos:

1. En el panel de navegación, seleccione **Clusters (Clústeres)**.

1. En la página de clústeres, elija **Infraestructura**.

1. En la página de infraestructura, elija el proveedor de capacidad que creó.

1. En la página del proveedor de capacidad, elija **Etiquetas**.

1. En **Etiquetas**, elija **Administrar etiquetas**.

1. Para agregar una etiqueta, especifique la clave y el valor de la etiqueta que desee agregar y, a continuación, elija **Guardar**. Para agregar varias etiquetas a la vez, elija **Agregar etiqueta** para cada etiqueta que desee agregar. Puede agregar un máximo de 50 etiquetas.

   Para eliminar una etiqueta, elija **Eliminar**.
**nota**  
Si la propagación de etiquetas está habilitada, las etiquetas añadidas o eliminadas después de la creación del proveedor de capacidad no se aplican a los recursos creados anteriormente por el proveedor de capacidad.

## Procedimiento de AWS CLI
<a name="update-capacity-provider-managed-instances-cli"></a>

Puede actualizar un proveedor de capacidad para instancias administradas de Amazon ECS mediante la AWS CLI. Utilice la versión más reciente de la AWS CLI. Para obtener más información acerca de cómo actualizar a la versión más reciente, consulte [Instalación o actualización de la versión más reciente de la AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).

**Actualización de la supervisión de instancias administradas de Amazon ECS (AWS CLI)**

1. Para habilitar la supervisión detallada, utilice el siguiente comando:

   ```
   aws ecs update-capacity-provider \
       --name my-managed-instances-provider \
       --managed-instances-provider '{
           "instanceLaunchTemplateUpdate": {
               "monitoring": "DETAILED"
           }
       }'
   ```

1. Para habilitar la supervisión básica, utilice el siguiente comando:

   ```
   aws ecs update-capacity-provider \
       --name my-managed-instances-provider \
       --managed-instances-provider '{
           "instanceLaunchTemplateUpdate": {
               "monitoring": "BASIC"
           }
       }'
   ```

# Eliminación de un proveedor de capacidad de instancias administradas de Amazon ECS
<a name="delete-capacity-provider-managed-instances-console-v2"></a>

Si ha terminado de utilizar un proveedor de capacidad de instancias administradas de Amazon ECS, puede eliminarlo. Una vez eliminado el grupo, el proveedor de capacidad de instancias administradas de Amazon ECS pasa al estado `INACTIVE`. Es posible que los proveedores de capacidad con estado `INACTIVE` permanezcan detectables en la cuenta durante un período de tiempo. Sin embargo, este comportamiento está sujeto a cambios en el futuro, por lo que no debe contar con la permanencia de los proveedores de capacidad `INACTIVE`. Antes de eliminar un proveedor de capacidad de instancias administradas de Amazon ECS, se debe eliminar el proveedor de capacidad de la estrategia de proveedor de capacidad de todos los servicios. Puede usar la API `UpdateService` o el flujo de trabajo del servicio de actualización de la consola de Amazon ECS para eliminar un proveedor de capacidad de la estrategia de proveedores de capacidad de un servicio. Utilice la opción **Forzar una nueva implementación** a fin de garantizar que cualquier tarea que utilice la capacidad de instancias administradas de Amazon ECS proporcionada por el proveedor de capacidad pase a utilizar la capacidad de los proveedores de capacidad restantes.

**Para eliminar un proveedor de capacidad para el clúster (consola de Amazon ECS)**

1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. En el panel de navegación, seleccione **Clusters (Clústeres)**.

1. En la página **Clusters** (Clústeres), elija el clúster.

1. En la página **Clúster: *nombre***, elija **Infraestructura**, el proveedor de capacidad de instancias administradas de Amazon ECS y, a continuación, elija **Eliminar**.

1. En el cuadro de confirmación, escriba **eliminar *nombre del proveedor de capacidad de instancias administradas de Amazon ECS***.

1. Elija **Eliminar**.

# Detención segura de las cargas de trabajo de Amazon ECS que se ponen en marcha en instancias administradas de Amazon ECS
<a name="managed-instance-task-scale-in-protect"></a>

Puede usar la protección de reducción horizontal de tareas de Amazon ECS para proteger sus tareas y evitar que se terminen debido a eventos de reducción horizontal derivados del escalado automático o las implementaciones de un servicio.

Algunas aplicaciones requieren un mecanismo para evitar que las tareas de misión crítica finalicen por eventos de reducción horizontal en momentos de baja utilización o durante las implementaciones de servicios. Por ejemplo:
+ Tiene una aplicación asíncrona de procesamiento de colas, como un trabajo de transcodificación de video, en el que algunas tareas deben ejecutarse durante horas, incluso cuando la utilización acumulada del servicio es baja.
+ Tiene una aplicación de juegos que pone en marcha servidores de juegos como tareas que deben seguir en marcha incluso si todos los usuarios han cerrado sesión para reducir la latencia de inicio del reinicio del servidor.
+ Al implementar una nueva versión de código, es necesario que las tareas sigan ejecutándose, ya que volver a procesarlas sería costoso.

Para proteger las tareas que pertenecen a su servicio y evitar que se terminen en un evento de reducción horizontal, establezca el atributo `ProtectionEnabled` en `true`. Si se establece `ProtectionEnabled` como verdadero, las tareas quedan protegidas durante 2 horas de forma predeterminada. Puede personalizar el periodo de protección mediante el atributo `ExpiresInMinutes`. Puede proteger sus tareas durante un mínimo de 1 minuto y hasta un máximo de 2880 minutos (48 horas). Si utiliza la AWS CLI, puede especificar la opción `--protection-enabled`.

Cuando una tarea termine su trabajo requerido, puede establecer el atributo `ProtectionEnabled` en `false`, lo que permite que la tarea finalice mediante eventos de reducción horizontal posteriores. Si utiliza la AWS CLI, puede especificar la opción `--no-protection-enabled`.

## Mecanismos de protección de reducción horizontal de tareas
<a name="managed-instance-task-scale-in-protection-mechanisms"></a>

Puede configurar y obtener una protección de reducción horizontal de tareas mediante el punto de conexión del agente de contenedores de Amazon ECS o la API de Amazon ECS.
+ **Punto de conexión del agente de contenedor de Amazon ECS**

  Recomendamos utilizar el punto de conexión del agente de contenedores de Amazon ECS para tareas que puedan determinar por sí mismas la necesidad de protección. Utilice este enfoque para cargas de trabajo basadas en colas o de procesamiento de trabajos.

  Cuando un contenedor comienza a procesar el trabajo, por ejemplo, al consumir un mensaje SQS, puede configurar el atributo `ProtectionEnabled` a través de la ruta del punto de conexión de protección de reducción horizontal de tareas `$ECS_AGENT_URI/task-protection/v1/state` desde el contenedor. Amazon ECS no finalizará esta tarea durante los eventos de reducción horizontal. Cuando la tarea termine su trabajo, puede borrar el atributo `ProtectionEnabled` con el mismo punto de conexión, lo que permite que la tarea pueda finalizarse durante eventos de reducción horizontal posteriores.

  Para obtener más información sobre cómo usar el punto de conexión del agente de contenedores de Amazon ECS, consulte [Punto de conexión de protección de reducción horizontal de tareas de Amazon ECS](managed-instance-task-scale-in-protection-endpoint.md).
+ **API de Amazon ECS**

  Puede usar la API de Amazon ECS para configurar y recuperar la protección de reducción horizontal de tareas si su aplicación tiene un componente que rastrea el estado de las tareas activas. Utilice `UpdateTaskProtection` para marcar una o más tareas como protegidas. Use `GetTaskProtection` para recuperar el estado de protección.

  Un ejemplo de este enfoque sería si su aplicación aloja sesiones de servidor de juegos como tareas de Amazon ECS. Cuando un usuario inicia sesión en el servidor (tarea), puede marcar la tarea como protegida. Cuando el usuario cierre la sesión, puede desactivar la protección específicamente para esta tarea o desactivar de forma periódica la protección para tareas similares que ya no tengan sesiones activas, según sus necesidades de mantener los servidores inactivos.

  Para obtener más información, consulte [UpdateTaskProtection](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateTaskProtection.html) y [GetTaskProtection](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_GetTaskProtection.html) en la *Referencia de la API de Amazon Elastic Container Service*.

Puede combinar ambos enfoques. Por ejemplo, utilice el punto de conexión del agente de Amazon ECS para configurar la protección de tareas desde un contenedor y utilice la API de Amazon ECS para quitar la protección de tareas de su servicio de controlador externo.

## Consideraciones
<a name="managed-instance-task-scale-in-protection-considerations"></a>

Tenga en cuenta los siguientes puntos antes de utilizar la protección de reducción horizontal de tareas:
+ La protección de tareas frente a la reducción horizontal solo se admite con las tareas implementadas desde un servicio.
+ La protección de tareas frente a la reducción horizontal es compatible con las tareas implementadas desde un servicio que se ponga en marcha en instancias administradas de Amazon ECS.
+ Recomendamos utilizar el punto de conexión del agente de contenedor de Amazon ECS porque el agente de Amazon ECS tiene mecanismos de reintento incorporados y una interfaz más sencilla.
+ Para restablecer el periodo de caducidad de la protección de reducción horizontal de tareas, invoque `UpdateTaskProtection` en una tarea que ya tenga activada la protección.
+ Determine cuánto tiempo necesitaría una tarea para completar el trabajo requerido y configure la propiedad `expiresInMinutes` en consecuencia. Si establece que la caducidad de la protección sea más larga de lo necesario, incurrirá en costos y se retrasará la implementación de nuevas tareas.
+ Consideraciones sobre la implementación:
  + Si el servicio utiliza una actualización continua, se crearán nuevas tareas, pero las tareas que ejecuten una versión anterior no se terminarán hasta que `protectionEnabled` se desactive o caduque. Puede ajustar el parámetro `maximumPercentage` en la configuración de implementación a un valor que permita crear nuevas tareas cuando las tareas antiguas estén protegidas.
  + Si usa CloudFormation, la pila de actualizaciones tiene un tiempo de espera de 3 horas. Por lo tanto, si configura la protección de sus tareas durante más de 3 horas, la implementación de CloudFormation puede provocar un error y una restauración.

    Durante el tiempo en que sus tareas antiguas están protegidas, en la pila de CloudFormation se muestra `UPDATE_IN_PROGRESS`. Si se elimina la protección de reducción horizontal de tareas o esta caduca dentro del período de 3 horas, su implementación se realizará correctamente y pasará al estado `UPDATE_COMPLETE`. Si la implementación se detiene en `UPDATE_IN_PROGRESS` durante más de 3 horas, se producirá un error, se mostrará el estado `UPDATE_FAILED` y, a continuación, se llevará a cabo una restauración al conjunto de tareas anterior.
  + Amazon ECS vende eventos de servicio cuando las tareas protegidas impiden que una implementación (continua o azul/verde) alcance un estado estable, para que pueda tomar medidas correctivas. Al intentar actualizar el estado de protección de una tarea, si recibe un mensaje de error `DEPLOYMENT_BLOCKED`, significa que el servicio tiene más tareas protegidas que el recuento deseado de tareas para el servicio. Para corregir este error, realice alguna de las siguientes acciones:
    + Espere a que caduque la protección de tareas actual. A continuación, establezca la protección de tareas.
    + Determine qué tareas se pueden detener. A continuación, utilice `UpdateTaskProtection` con la opción `protectionEnabled` configurada en `false` para estas tareas.
    + Aumente el recuento de tareas deseado del servicio a un número mayor al de tareas protegidas.

## Permisos de IAM requeridos para la protección de reducción horizontal de tareas
<a name="managed-instance-task-scale-in-protection-iam"></a>

La tarea debe tener el rol de tarea de Amazon ECS con los siguientes permisos:
+ `ecs:GetTaskProtection`: permite que el agente de contenedor de Amazon ECS llame a `GetTaskProtection`.
+ `ecs:UpdateTaskProtection`: permite que el agente de contenedor de Amazon ECS llame a `UpdateTaskProtection`.

# Punto de conexión de protección de reducción horizontal de tareas de Amazon ECS
<a name="managed-instance-task-scale-in-protection-endpoint"></a>

El agente del contenedor de Amazon ECS inyecta automáticamente la variable de entorno `ECS_AGENT_URI` en los contenedores de las tareas de Amazon ECS para proporcionar un método que permita interactuar con el punto de conexión de la API del agente de contenedor.

Recomendamos utilizar el punto de conexión del agente de contenedores de Amazon ECS para tareas que puedan determinar por sí mismas la necesidad de protección. 

Cuando un contenedor comienza a procesar el trabajo, puede configurar el atributo `protectionEnabled` a través de la ruta del punto de conexión de protección de reducción horizontal de tareas `$ECS_AGENT_URI/task-protection/v1/state` desde el contenedor. 

Utilice una solicitud PUT a este URI desde dentro de un contenedor para establecer la protección de reducción horizontal. Una solicitud GET a este URI devolverá el estado de protección actual de una tarea.

## Parámetros de respuesta de protección de la reducción horizontal de tareas
<a name="managed-instance-task-scale-in-protection-request"></a>

Puede configurar la protección de reducción horizontal de tareas mediante el punto de conexión `${ECS_AGENT_URI}/task-protection/v1/state` con los siguientes parámetros de solicitud.

`ProtectionEnabled`  
Especifique `true` para marcar una tarea para su protección. Especifique `false` si desea eliminar la protección y hacer que la tarea pueda cancelarse.  
Tipo: booleano  
Obligatorio: sí

`ExpiresInMinutes`  
Número de minutos que debe transcurrir para proteger la tarea. Puede especificar un mínimo de 1 minuto y un máximo de 2880 minutos (48 horas). Durante este periodo, la tarea no finalizará con eventos de reducción horizontal del escalado automático del servicio o implementaciones. Una vez transcurrido este período, el parámetro `protectionEnabled` se restablecerá a `false`.  
Si no especifica el tiempo, la tarea se protege automáticamente durante 120 minutos (2 horas).  
Tipo: entero  
Obligatorio: no

En los siguientes ejemplos se muestra cómo configurar la protección de tareas con diferentes duraciones.

**Ejemplo de cómo proteger una tarea con el periodo predeterminado**

En este ejemplo se muestra cómo proteger una tarea con el periodo de tiempo predeterminado de 2 horas.

```
curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true}'
```

**Ejemplo de cómo proteger una tarea durante 60 minutos**

En este ejemplo se muestra cómo proteger una tarea durante 60 minutos mediante el parámetro `expiresInMinutes`.

```
curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true,"ExpiresInMinutes":60}'      
```

**Ejemplo de cómo proteger una tarea durante 24 horas**

En este ejemplo se muestra cómo proteger una tarea durante 24 horas mediante el parámetro `expiresInMinutes`.

```
curl --request PUT --header 'Content-Type: application/json' ${ECS_AGENT_URI}/task-protection/v1/state --data '{"ProtectionEnabled":true,"ExpiresInMinutes":1440}'      
```

La solicitud PUT devolverá la siguiente respuesta.

```
{
  "protection": {
    "ExpirationDate": "2023-12-20T21:57:44.837Z",
    "ProtectionEnabled": true,
    "TaskArn": "arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0"
  }
}
```

## Parámetros de respuesta de task scale-in protection
<a name="managed-instance-task-scale-in-protection-response"></a>

La siguiente información se devuelve desde el punto de conexión de reducción horizontal de tareas `${ECS_AGENT_URI}/task-protection/v1/state` en la respuesta de JSON.

`ExpirationDate`  
La época en la que caducará la protección de la tarea. Si la tarea no está protegida, este valor será nulo.

`ProtectionEnabled`  
El estado de protección de la tarea. Si la protección de reducción horizontal está habilitada para una tarea, el valor es `true`. De lo contrario, es `false`.

`TaskArn`  
Nombre de recurso de Amazon (ARN) de la tarea a la que pertenece el contenedor.

En el ejemplo siguiente se muestran los detalles que se devuelven de una tarea protegida.

```
curl --request GET ${ECS_AGENT_URI}/task-protection/v1/state
```

```
{
    "protection":{
        "ExpirationDate":"2023-12-20T21:57:44Z",
        "ProtectionEnabled":true,
        "TaskArn":"arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0"
    }
}
```

Cuando se produce un error, se devuelve la siguiente información.

`Arn`  
El nombre de recurso de Amazon (ARN) de la tarea.

`Detail`  
Los detalles relacionados con el error.

`Reason`  
El motivo del error.

En el ejemplo siguiente se muestran los detalles que se devuelven de una tarea que no está protegida.

```
{
    "failure":{
        "Arn":"arn:aws:ecs:us-west-2:111122223333:task/1234567890abcdef0",
        "Detail":null,
        "Reason":"TASK_NOT_VALID"
    }
}
```

Cuando se produce una excepción, se devuelve la siguiente información.

`requestID`  
El ID de solicitud de AWS para la llamada a la API de Amazon ECS que produce una excepción.

`Arn`  
El nombre de recurso de Amazon (ARN) completo del servicio o la tarea.

`Code`  
Código de error.

`Message`  
Mensaje de error.  
Si aparece un error `RequestError` o `RequestTimeout`, es probable que se trate de un problema de red. Intente utilizar puntos de conexión de VPC para Amazon ECS.

En el ejemplo siguiente se muestran los detalles que se devuelven cuando se produce un error.

```
{
    "requestID":"12345-abc-6789-0123-abc",
    "error":{
        "Arn":"arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0",
        "Code":"AccessDeniedException",
        "Message":"User: arn:aws:sts::444455556666:assumed-role/my-ecs-task-role/1234567890abcdef0 is not authorized to perform: ecs:GetTaskProtection on resource: arn:aws:ecs:us-west-2:555555555555:task/test/1234567890abcdef0 because no identity-based policy allows the ecs:GetTaskProtection action"
    }    
}
```

El siguiente error aparece si el agente de Amazon ECS no puede obtener una respuesta del punto de conexión de Amazon ECS por motivos como problemas de red o si el plano de control de Amazon ECS no funciona.

```
{
  "error": {
    "Arn": "arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0",
    "Code": "RequestCanceled",
    "Message": "Timed out calling Amazon ECS Task Protection API"
  }
}
```

El siguiente error aparece cuando el agente de Amazon ECS recibe una excepción de limitación de Amazon ECS.

```
{
  "requestID": "12345-abc-6789-0123-abc",
  "error": {
    "Arn": "arn:aws:ecs:us-west-2:555555555555:task/my-cluster-name/1234567890abcdef0",
    "Code": "ThrottlingException",
    "Message": "Rate exceeded"
  }
}
```

# Clústeres de Amazon ECS para Fargate
<a name="fargate-capacity-providers"></a>

Los proveedores de capacidad de Amazon ECS en AWS Fargate le permiten utilizar la capacidad de Fargate y de Fargate Spot para las tareas de Amazon ECS. 

Con Fargate Spot, puede ejecutar tareas de Amazon ECS tolerantes a interrupciones con un descuento respecto al precio de Fargate. Fargate Spot ejecuta las tareas en la capacidad de cómputo adicional. Cuando AWS necesita recuperar esa capacidad, las tareas se interrumpen previa advertencia con dos minutos de antelación.

Cuando se detienen las tareas que utilizan los proveedores de capacidad de Fargate y Fargate Spot, se envía un evento de cambio de estado de la tarea a Amazon EventBridge. En el motivo de la parada se describe la causa. Para obtener más información, consulte [Eventos de cambio de estado de tarea de Amazon ECS](ecs_task_events.md).

Un clúster puede contener una combinación de proveedores de capacidad del grupo de escalado automático y Fargate. Sin embargo, una estrategia de proveedores de capacidad solo puede contener proveedores de capacidad de grupos de escalado automático o Fargate, pero no ambos. Para obtener más información, consulte [Proveedores de capacidad de grupos de escalado automático](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-auto-scaling.html#asg-capacity-providers).

Cuando utilice proveedores de capacidad, tenga en cuenta lo siguiente:
+ Debe asociar un proveedor de capacidad con un clúster para poder asociarlo con la estrategia de proveedores de capacidad.
+ Puede especificar un máximo de 20 proveedores de capacidad para una estrategia de proveedores de capacidad.
+ No puede actualizar un servicio que utiliza un proveedor de capacidad de grupos de escalado automático para que utilice un proveedor de capacidad de Fargate. En caso de que sea lo contrario, tampoco puede hacerlo.
+ En una estrategia de proveedores de capacidad, si no se especifica ningún valor `weight` para un proveedor de capacidad en la consola, entonces se utiliza el valor predeterminado `1`. Si utiliza la API o la AWS CLI, se utiliza el valor predeterminado `0`.
+ Cuando se especifican varios proveedores de capacidad dentro de una estrategia de proveedores de capacidad, al menos uno de los proveedores de capacidad deberá tener un valor de peso superior a cero. Los proveedores de capacidad con un peso de cero no se usan para realizar tareas. Si especifica varios proveedores de capacidad en una estrategia en la que todos tienen el mismo peso de 0, se producirá un error en cualquiera de las acciones `RunTask` o `CreateService` que utilicen la estrategia de proveedores de capacidad.
+ En una estrategia de proveedores de capacidad, solo un proveedor de capacidad puede tener un valor *base* definido. Si no se especifica ningún valor base, se utiliza el valor predeterminado 0.
+ Un clúster puede contener una combinación de proveedores de capacidad del grupo de escalado automático y proveedores de capacidad de Fargate. Sin embargo, una estrategia de proveedores de capacidad solo puede incluir proveedores de capacidad de grupo de escalado automático o de Fargate, pero no ambos.
+ Un clúster puede contener una combinación de servicios y tareas independientes que utilicen ambos proveedores de capacidad. Un servicio se puede actualizar para que utilice una estrategia de proveedores de capacidad en lugar de un tipo de lanzamiento. Sin embargo, al hacerlo, debe forzar una nueva implementación.

## Avisos de terminación de Fargate Spot
<a name="fargate-capacity-providers-termination"></a>

Durante los períodos de demanda extremadamente alta, es posible que la capacidad de Fargate Spot no esté disponible. Esto puede provocar que las tareas de Fargate Spot se retrasen. Cuando sucede esto, los servicios de Amazon ECS vuelven a intentar iniciar las tareas hasta que se disponga de la capacidad necesaria. Fargate no sustituye la capacidad de Spot por la capacidad bajo demanda. 

Cuando se detienen tareas que utilizan capacidad de Fargate Spot debido a una interrupción de spot, se envía una advertencia dos minutos antes de la detención de la tarea. La advertencia se envía como un evento de cambio de estado de tarea a Amazon EventBridge y como una señal SIGTERM a la tarea en ejecución. Si utiliza Fargate Spot como parte de un servicio, en esta situación, el programador de servicio recibe la señal de interrupción e intenta lanzar tareas adicionales en Fargate Spot si hay capacidad disponible. Un servicio con una sola tarea se interrumpirá hasta que haya capacidad disponible. Para obtener más información sobre un cierre correcto, consulte [Cierres correctos con ECS](https://aws.amazon.com/blogs/containers/graceful-shutdowns-with-ecs/).

Para asegurarse de que los contenedores realicen una salida correcta antes de que se detenga la tarea, puede configurar lo siguiente:
+ Se puede especificar un valor de `stopTimeout` de `120` segundos o menos en la definición del contenedor que la tarea utiliza. El valor de `stopTimeout` predeterminado es de 30 segundos. Puede especificar un valor de `stopTimeout` mayor para disponer de más tiempo desde el momento en que se recibe el evento de cambio de estado de tarea hasta el punto en el que se detiene forzosamente el contenedor. Para obtener más información, consulte [Tiempos de espera de contenedor](task_definition_parameters.md#container_definition_timeout).
+ La señal SIGTERM debe recibirse desde dentro del contenedor para realizar cualquier acción de limpieza. Si no se procesa esta señal, la tarea recibirá una señal SIGKILL una vez transcurrido el `stopTimeout` configurado, lo que puede provocar pérdida o corrupción de datos.

A continuación, se ofrece un fragmento de un evento de cambio de estado de tarea. Este fragmento muestra el motivo y el código de detención de una interrupción de Fargate Spot.

```
{
  "version": "0",
  "id": "9bcdac79-b31f-4d3d-9410-fbd727c29fab",
  "detail-type": "ECS Task State Change",
  "source": "aws.ecs",
  "account": "111122223333",
  "resources": [
    "arn:aws:ecs:us-east-1:111122223333:task/b99d40b3-5176-4f71-9a52-9dbd6f1cebef"
  ],
  "detail": {
    "clusterArn": "arn:aws:ecs:us-east-1:111122223333:cluster/default",
    "createdAt": "2016-12-06T16:41:05.702Z",
    "desiredStatus": "STOPPED",
    "lastStatus": "RUNNING",
    "stoppedReason": "Your Spot Task was interrupted.",
    "stopCode": "SpotInterruption",
    "taskArn": "arn:aws:ecs:us-east-1:111122223333:task/b99d40b3-5176-4f71-9a52-9dbd6fEXAMPLE",
    ...
  }
}
```

El siguiente patrón de eventos se utiliza para crear una regla de EventBridge para los eventos de cambio de estado de tarea de Amazon ECS. Si lo desea, puede especificar un clúster en el campo `detail`. Al hacerlo, recibirá eventos de cambio de estado de la tarea para ese clúster. Para obtener más información acerca de la creación de una regla de EventBridge, consulte [Introducción a Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html) en la *Guía del usuario de Amazon EventBridge*.

```
{
    "source": [
        "aws.ecs"
    ],
    "detail-type": [
        "ECS Task State Change"
    ],
    "detail": {
        "clusterArn": [
            "arn:aws:ecs:us-west-2:111122223333:cluster/default"
        ]
    }
}
```

# Creación de un clúster de Amazon ECS para cargas de trabajo de Fargate
<a name="create-cluster-console-v2"></a>

Cree un clúster para definir la infraestructura en la que se ponen en marcha sus tareas y servicios.

Antes de comenzar, asegúrese de haber seguido los pasos que se detallan en [Configuración para utilizar Amazon ECS](get-set-up-for-amazon-ecs.md) y de asignar el permiso de IAM adecuado. Para obtener más información, consulte [Ejemplos de clústeres de Amazon ECS](security_iam_id-based-policy-examples.md#IAM_cluster_policies). La consola de Amazon ECS crea los recursos que necesita un clúster de Amazon ECS mediante la creación de una pila de CloudFormation. 

La consola asocia automáticamente los proveedores de capacidad de Fargate y Fargate Spot al clúster.

Puede modificar las siguientes opciones:
+ Agregue un espacio de nombres al clúster.

  Un espacio de nombres permite que los servicios que cree en el clúster puedan conectarse a los demás servicios del espacio de nombres sin configuración adicional. Para obtener más información, consulte [Interconexión de los servicios de Amazon ECS](interconnecting-services.md).
+ Habilite los eventos de tareas para recibir notificaciones de EventBridge sobre los cambios en el estado de las tareas.
+ Agregue etiquetas que le permitan identificar el clúster.
+ Asigne una clave AWS KMS para el almacenamiento administrado. Para obtener información acerca de la creación de una clave, consulte [Creación de una clave KMS](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) en la *Guía del usuario de AWS Key Management Service*.
+ Asigne una clave AWS KMS para el almacenamiento efímero de Fargate. Para obtener información acerca de la creación de una clave, consulte [Creación de una clave KMS](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) en la *Guía del usuario de AWS Key Management Service*.
+ Configure la clave AWS KMS y el registro para ECS Exec.

## Procedimiento
<a name="create-cluster-console-v2-procedure"></a>

**Para crear un nuevo clúster (consola de Amazon ECS)**

1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. En la barra de navegación, seleccione la región a utilizar.

1. En el panel de navegación, seleccione **Clusters (Clústeres)**.

1. En la página **Clusters** (Clústeres), elija **Create Cluster** (Crear clúster).

1. En **Configuraciones del clúster**, configure lo siguiente:
   + En **Nombre del clúster**, escriba un nombre único.

     El nombre puede contener hasta 255 letras (minúsculas y mayúsculas), números y guiones.
   + (Opcional) Para que el espacio de nombres utilizado en Service Connect sea diferente del nombre del clúster, en **Valores predeterminados de Service Connect**, para **Espacio de nombres predeterminado**, elija o introduzca un espacio de nombres único. Para usar un espacio de nombres compartido, elija o introduzca un ARN de espacio de nombres. Para obtener más información acerca del uso de espacios de nombres compartidos, consulte [Amazon ECS Service Connect con espacios de nombres de AWS Cloud Map compartidos](service-connect-shared-namespaces.md).

1. (Opcional) Utilice Información de contenedores, amplíe **Supervisión** y, a continuación, seleccione una de las siguientes opciones:
   + Para usar Información de contenedores con observabilidad mejorada, como se recomienda, elija **Información de contenedores con observabilidad mejorada**.
   + Para usar Información de contenedores, seleccione **Información de contenedores**.

1. (Opcional) Para habilitar los eventos de tareas, expanda **Eventos de tareas** y, a continuación, active **Habilitar eventos de tareas**.

   Cuando habilita los eventos de tareas, Amazon ECS envía eventos de cambio de estado de la tarea a EventBridge. Esto le permite supervisar y responder a los cambios en el ciclo de vida de las tareas automáticamente.

1. (Opcional) Para usar ECS Exec para depurar tareas en el clúster, amplíe la **configuración de solución de problemas** y, a continuación, configure lo siguiente:
   + (Opcional) En el caso de **la clave AWS KMS de ECS Exec**, introduzca el ARN de la clave AWS KMS que desee utilizar para cifrar los datos de la sesión de ECS Exec.
   + (Opcional) Para el **registro de ECS Exec**, elija el destino del registro:
     + Para enviar registros a CloudWatch Logs, elija **Amazon CloudWatch**.
     + Para enviar registros a Amazon S3, elija **Amazon S3**.
     + Para deshabilitar el registro, elija **Ninguno**.

1. (Opcional) En **Cifrado**, puede configurar lo siguiente:
   + Cifre sus datos en el almacenamiento efímero de Fargate. En **Cifrado**, para **Almacenamiento efímero de Fargate**, introduzca el ARN de la clave AWS KMS que desea utilizar para cifrar los datos del almacenamiento efímero de Fargate.
   + Cifre los datos en el almacenamiento administrado. En **Cifrado**, para **Almacenamiento administrado**, introduzca el ARN de la clave AWS KMS que desea utilizar para cifrar los datos del almacenamiento administrado.

1. (Opcional) Para ayudar a identificar el clúster, expanda **Tags** (Etiquetas) y, a continuación, configure sus etiquetas.

   [Agregar una etiqueta] Elija **Agregar etiqueta** y haga lo siguiente:
   + En **Key (Clave)**, escriba el nombre de la clave.
   + En **Valor**, escriba el valor de la clave.

   [Eliminar una etiqueta] Elija **Eliminar** a la derecha de la clave y el valor de la etiqueta.

1. Seleccione **Create (Crear)**.

## Siguientes pasos
<a name="fargate-cluster-next-steps"></a>

Tras crear el clúster, puede crear definiciones de tareas para sus aplicaciones y, a continuación, ejecutarlas como tareas independientes o como parte de un servicio. Para obtener más información, consulte los siguientes temas:
+ [Definiciones de tareas de Amazon ECS](task_definitions.md)
+ [Ejecución de una aplicación como tarea de Amazon ECS](standalone-task-create.md)
+ [Creación de una implementación de actualización continua de Amazon ECS](create-service-console-v2.md)

# Proveedores de capacidad de Amazon ECS para cargas de trabajo de EC2
<a name="asg-capacity-providers"></a>

Cuando utiliza instancias de Amazon EC2 para su capacidad, utiliza grupos de escalado automático para administrar las instancias de Amazon EC2 registradas en sus clústeres. El escalado automático lo ayuda a garantizar que cuenta con la cantidad correcta de instancias de Amazon EC2 disponibles para gestionar la carga de su aplicación. 

Puede utilizar la característica de escalado administrado para que Amazon ECS administre las acciones de reducción o escalado horizontal del grupo de escalado automático o puede administrar las acciones de escalado usted mismo. Para obtener más información, consulte [Administración automática de la capacidad de Amazon ECS con el escalado automático de clústeres](cluster-auto-scaling.md).

Se recomienda crear un nuevo grupo de escalado automático vacío. Si utiliza un grupo de escalado automático existente, es posible que en el proveedor de capacidad no se registren correctamente las instancias de Amazon EC2 asociadas al grupo que ya se estaban ejecutando y se habían registrado en un clúster de Amazon ECS antes de utilizar el grupo de escalado automático para crear un proveedor de capacidad. Esto puede causar problemas al usar el proveedor de capacidad en una estrategia de proveedores de capacidad. Utilice `DescribeContainerInstances` para confirmar si una instancia de contenedor está asociada a un proveedor de capacidad o no.

**nota**  
Para crear un grupo de Auto Scaling vacío, establezca el recuento deseado en cero. Después de crear el proveedor de capacidad y asociarlo a un clúster, puede escalarlo horizontalmente.  
Cuando utiliza la consola de Amazon ECS, el servicio crea una plantilla de lanzamiento de Amazon EC2 y un grupo de escalado automático en su nombre como parte de la pila de CloudFormation. Llevan el prefijo `EC2ContainerService-<ClusterName>`. Puede utilizar el grupo de escalado automático como proveedor de capacidad para ese clúster.

Le recomendamos que utilice el drenaje de instancias administradas para permitir la finalización correcta de las instancias de Amazon EC2 sin interrumpir sus cargas de trabajo. Esta característica está activada de forma predeterminada. Para obtener más información, consulte [Detención segura de las cargas de trabajo de Amazon ECS que se ejecutan en instancias de EC2](managed-instance-draining.md)

Tenga en cuenta lo siguiente cuando utilice los proveedores de capacidad de grupos de escalado automático en la consola:
+ Un grupo de Auto Scaling debe tener un `MaxSize` mayor que cero para poder realizar un escalado horizontal.
+ El grupo de Auto Scaling no puede tener configuración de ponderación de instancias.
+ Si el grupo de escalado automático no se puede escalar horizontalmente para incorporar la cantidad de tareas ejecutadas, las tareas no pueden realizar la transición más allá del estado `PROVISIONING`.
+ No modifique el recurso de política de escalado asociado a los grupos de escalado automático administrados por los proveedores de capacidad. 
+ Si el escalado administrado está activado al crear un proveedor de capacidad, el recuento deseado del grupo de escalado automático se puede establecer en `0`. Cuando se activa el escalado administrado, Amazon ECS administra las acciones de reducción horizontal y escalado horizontal del grupo de escalado automático.
+ Debe asociar un proveedor de capacidad a un clúster para poder asociarlo a la estrategia de proveedores de capacidad.
+ Puede especificar un máximo de 20 proveedores de capacidad para una estrategia de proveedores de capacidad.
+ No puede actualizar un servicio que utiliza un proveedor de capacidad de grupos de escalado automático para que utilice un proveedor de capacidad de Fargate. En caso de que sea lo contrario, tampoco puede hacerlo.
+ En una estrategia de proveedores de capacidad, si no se especifica ningún valor `weight` para un proveedor de capacidad en la consola, entonces se utiliza el valor predeterminado `1`. Si utiliza la API o la AWS CLI, se utiliza el valor predeterminado `0`.
+ Cuando se especifican varios proveedores de capacidad dentro de una estrategia de proveedores de capacidad, al menos uno de los proveedores de capacidad deberá tener un valor de peso superior a cero. Los proveedores de capacidad con un peso de cero no se usan para realizar tareas. Si especifica varios proveedores de capacidad en una estrategia en la que todos tienen el mismo peso de 0, se producirá un error en cualquiera de las acciones `RunTask` o `CreateService` que utilicen la estrategia de proveedores de capacidad.
+ En una estrategia de proveedores de capacidad, solo un proveedor de capacidad puede tener un valor *base* definido. Si no se especifica ningún valor base, se utiliza el valor predeterminado 0.
+ Un clúster puede contener una combinación de proveedores de capacidad del grupo de escalado automático y proveedores de capacidad de Fargate. Sin embargo, una estrategia de proveedores de capacidad solo puede incluir proveedores de capacidad de grupo de escalado automático o de Fargate, pero no ambos.
+ Un clúster puede contener una combinación de servicios y tareas independientes que utilicen proveedores de capacidad y tipos de lanzamiento. Un servicio se puede actualizar para que utilice una estrategia de proveedores de capacidad en lugar de un tipo de lanzamiento. Sin embargo, al hacerlo, debe forzar una nueva implementación.
+ Amazon ECS admite grupos de calentamiento de Amazon EC2 Auto Scaling. Un grupo de calentamiento es un grupo de instancias de Amazon EC2 inicializadas previamente listas para ponerse en servicio. Siempre que su aplicación necesita escalar horizontalmente, Amazon EC2 Auto Scaling utiliza las instancias preinicializadas del grupo de calentamiento en lugar de lanzar instancias en frío. Esto permite ejecutar cualquier proceso de inicialización final antes de que la instancia entre en servicio. Para obtener más información, consulte [Configuración de instancias preinicializadas para el grupo de escalado automático de Amazon ECS](using-warm-pool.md).

Para obtener más información acerca de cómo crear plantillas de lanzamiento para Amazon EC2 Auto Scaling, consulte [Plantillas de lanzamiento de escalado automático](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-templates.html) en la *Guía del usuario de Amazon EC2 Auto Scaling*. Para obtener más información acerca de cómo crear un grupo de Amazon EC2 Auto Scaling, consulte [Grupos de escalado automático](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html) en la *Guía del usuario de Amazon EC2 Auto Scaling*.

# Consideraciones de seguridad en instancias de contenedor de Amazon EC2 para Amazon ECS
<a name="ec2-security-considerations"></a>

Debe tener en cuenta una única instancia de contenedor y su acceso dentro de su modelo de amenazas. Por ejemplo, es posible que una sola tarea afectada aproveche los permisos de IAM de una tarea no infectada en la misma instancia.

Le recomendamos que utilice el siguiente procedimiento para evitarlo:
+ No utilice los privilegios de administrador al ejecutar sus tareas. 
+ Asigne un rol de tarea con acceso de privilegio mínimo a sus tareas. 

  El agente de contenedor crea automáticamente un token con un ID de credencial único que se utiliza para acceder a los recursos de Amazon ECS.
+ Para impedir que los contenedores de las tareas que usan el modo de red `awsvpc` obtengan acceso a la información sobre credenciales proporcionada al perfil de instancia de Amazon EC2, pero dejar los permisos proporcionados por el rol de tarea, establezca la variable de configuración del agente `ECS_AWSVPC_BLOCK_IMDS` en verdadero en el archivo de configuración del agente y reinícielo.
+ Utilice la supervisión en tiempo de ejecución de Amazon GuardDuty para detectar amenazas para los clústeres y contenedores de su entorno de AWS. La supervisión en tiempo de ejecución utiliza un agente de seguridad de GuardDuty que agrega visibilidad en tiempo de ejecución a las cargas de trabajo individuales de Amazon ECS (por ejemplo, el acceso a los archivos, la ejecución de procesos y las conexiones de red). Para obtener más información, consulte [GuardDuty Runtime Monitoring](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring.html) en la *Guía del usuario de GuardDuty*.

# Creación de un clúster de Amazon ECS para cargas de trabajo de Amazon EC2
<a name="create-ec2-cluster-console-v2"></a>

Cree un clúster para definir la infraestructura en la que se ejecutan sus tareas y servicios.

Antes de comenzar, asegúrese de haber seguido los pasos que se detallan en [Configuración para utilizar Amazon ECS](get-set-up-for-amazon-ecs.md) y de asignar el permiso de IAM adecuado. Para obtener más información, consulte [Ejemplos de clústeres de Amazon ECS](security_iam_id-based-policy-examples.md#IAM_cluster_policies). La consola de Amazon ECS ofrece una forma sencilla de crear los recursos que necesita un clúster de Amazon ECS mediante la creación de una pila de CloudFormation. 

Para simplificar al máximo el proceso de creación del clúster, la consola cuenta con selecciones predeterminadas para muchas de las opciones que describimos a continuación. También hay paneles de ayuda disponibles para la mayoría de las secciones de la consola, que proporcionan más contexto. 

Puede registrar instancias de Amazon EC2 durante la creación del clúster o registrar instancias adicionales en el clúster después de crearlo.

Puede modificar las siguientes opciones predeterminadas:
+ Cambie las subredes en las que se lanzan las instancias.
+ Cambie los grupos de seguridad que se utilizan para controlar el tráfico a las instancias de contenedor.
+ Agregue un espacio de nombres al clúster.

  Un espacio de nombres permite que los servicios que cree en el clúster puedan conectarse a los demás servicios del espacio de nombres sin configuración adicional. Para obtener más información, consulte [Interconexión de los servicios de Amazon ECS](interconnecting-services.md).
+ Habilite los eventos de tareas para recibir notificaciones de EventBridge sobre los cambios en el estado de las tareas.
+ Asigne una clave AWS KMS para el almacenamiento administrado. Para obtener información acerca de la creación de una clave, consulte [Creación de una clave KMS](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) en la *Guía del usuario de AWS Key Management Service*.
+ Asigne una clave AWS KMS para su almacenamiento efímero de Fargate. Para obtener información acerca de la creación de una clave, consulte [Creación de una clave KMS](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) en la *Guía del usuario de AWS Key Management Service*.
+ Configure la clave AWS KMS y el registro para ECS Exec.
+ Agregue etiquetas que le ayuden a identificar el clúster.

## Opciones de grupo de Auto Scaling
<a name="capacity-providers"></a>

Cuando utiliza Amazon EC2 instances (Instancias de Amazon EC2), debe especificar un grupo de Auto Scaling para administrar la infraestructura en la que se ejecutan sus tareas y servicios. 

Cuando elige crear un nuevo grupo de Auto Scaling, se configura automáticamente para el siguiente comportamiento:
+ Amazon ECS administra las acciones de reducción y escalado horizontal del grupo de Auto Scaling.
+ Amazon ECS impide que las instancias de Amazon EC2 que contiene tareas en un grupo de Auto Scaling se terminen durante una acción de reducción horizontal. Para obtener más información, consulte [Protección de instancias](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-termination.html#instance-protection) en la *Guía del usuario de AWS Auto Scaling*.

Puede configurar las siguientes propiedades de grupo de Auto Scaling que determinan el tipo y el número de instancias que se van a lanzar para el grupo:
+ La AMI optimizada para Amazon ECS. 
+ El tipo de instancia.
+ El par de claves de SSH que demuestra su identidad cuando se conecta a la instancia. Para obtener información acerca cómo crear claves de SSH, consulte [Pares de claves de Amazon EC2 e instancias de Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) en la *Guía del usuario de Amazon EC2*.
+ Número mínimo de instancias para lanzar en el grupo de Auto Scaling. 
+ El número máximo de instancias que se inician para el grupo de Auto Scaling. 

  Para que el grupo se escale horizontalmente, el máximo debe ser superior a 0.

Amazon ECS crea una plantilla de lanzamiento de Amazon EC2 Auto Scaling y un grupo de Auto Scaling en su nombre como parte de la pila CloudFormation. Los valores especificados para la AMI, los tipos de instancias y el par de claves de SSH forman parte de la plantilla de lanzamiento. Las plantillas tienen el prefijo `EC2ContainerService-<ClusterName>`, por lo que son fáciles de identificar. Los grupos de Auto Scaling llevan el prefijo `<ClusterName>-ECS-Infra-ECSAutoScalingGroup`.

Las instancias lanzadas para el grupo de Auto Scaling utilizan la plantilla de lanzamiento.

## Opciones de red
<a name="networking-options"></a>

De forma predeterminada, las instancias se lanzan en las subredes predeterminadas de la región. Se utilizan los grupos de seguridad, que controlan el tráfico hacia las instancias de contenedor, actualmente asociados a las subredes. Puede cambiar las subredes y los grupos de seguridad de las instancias.

Puede elegir una subred existente. Puede usar un grupo de seguridad existente o crear uno nuevo. Para crear tareas en una configuración de solo IPv6, utilice subredes que incluyan solo un bloque de CIDR IPv6.

Cuando crea un nuevo grupo de seguridad, debe especificar al menos una regla de entrada. 

Las reglas de entrada determinan qué tráfico puede llegar a las instancias de contenedor e incluyen las siguientes propiedades: 
+ El protocolo por permitir
+ El rango de puertos por permitir
+ El tráfico entrante (origen)

Para permitir el tráfico entrante desde una dirección o bloque de CIDR específicos, utilice **Personalizado** en **Origen** con el CIDR permitido. 

Para permitir el tráfico entrante desde todos los destinos, utilice **Anywhere** en **Origen**. Esta opción agrega automáticamente el bloque IPv4 0.0.0.0/0 de CIDR y el bloque IPv6 ::/0 de CIDR.

Para permitir el tráfico entrante desde su equipo local, utilice **Grupo de origen** en **Origen.** Esto agrega automáticamente la dirección IP actual de la computadora local como el origen permitido.

**Para crear un nuevo clúster (consola de Amazon ECS)**

Antes de empezar, asigne el permiso de IAM correspondiente. Para obtener más información, consulte [Ejemplos de clústeres de Amazon ECS](security_iam_id-based-policy-examples.md#IAM_cluster_policies).

1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. En la barra de navegación, seleccione la región a utilizar.

1. En el panel de navegación, seleccione **Clusters (Clústeres)**.

1. En la página **Clusters** (Clústeres), elija **Create Cluster** (Crear clúster).

1. En **Configuraciones del clúster**, configure lo siguiente:
   + En **Nombre del clúster**, escriba un nombre único.

     El nombre puede contener hasta 255 letras (minúsculas y mayúsculas), números y guiones.
   + (Opcional) Para que el espacio de nombres utilizado en Service Connect sea diferente del nombre del clúster, en **Valores predeterminados de Service Connect**, para **Espacio de nombres predeterminado**, elija o introduzca un espacio de nombres único. Para usar un espacio de nombres compartido, elija o introduzca un ARN de espacio de nombres. Para obtener más información acerca del uso de espacios de nombres compartidos, consulte [Amazon ECS Service Connect con espacios de nombres de AWS Cloud Map compartidos](service-connect-shared-namespaces.md).

1. Para agregar instancias de Amazon EC2 al clúster, expanda **Infraestructura** y, a continuación, seleccione **Instancias de Fargate y autoadministradas**. 

   A continuación, configure el grupo de Auto Scaling que actúa como proveedor de capacidad:

   1. Para utilizar un grupo de Auto Scaling existente, desde **Auto Scaling group (ASG)** (Grupo de Auto Scaling), seleccione el grupo.

   1. Para crear un grupo de Auto Scaling, desde **Auto Scaling group (ASG)** (Grupo de Auto Scaling), seleccione **Create new group** (Crear nuevo grupo) y, a continuación, proporcione los siguientes detalles sobre el grupo:
      + En **Modelo de aprovisionamiento**, seleccione si quiere utilizar instancias **bajo demanda** o instancias de **spot**.
      + Si decide utilizar instancias de spot, en **Estrategia de asignación**, elija qué grupos de capacidad de spot (tipos de instancias y zonas de disponibilidad) se utilizan para las instancias.

        Para la mayoría de las cargas de trabajo, puede elegir **Capacidad de precio optimizada**.

        Para obtener más información, consulte [Estrategias de asignación de instancias de spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-allocation-strategy.html) en la *Guía del usuario de Amazon EC2*
      + Para la **Imagen de máquina de Amazon (AMI) de la instancia de contenedor**, elija la AMI optimizada para Amazon ECS para las instancias de grupo de escalado automático.
      + Para **EC2 instance type** (Tipo de instancia EC2), elija el tipo de instancia para sus cargas de trabajo.

         El escalado administrado funciona mejor si el grupo de Auto Scaling utiliza los mismos tipos de instancia o similares. 
      + En **Rol de instancia de EC2**, elija un rol de instancia de contenedor existente o puede crear uno nuevo.

        Para obtener más información, consulte [Rol de IAM de instancia de contenedor de Amazon ECS](instance_IAM_role.md).
      + Para **Capacity** (Capacidad), introduzca el número mínimo y el número máximo de instancias que va a lanzar en el grupo de Auto Scaling. 
      + Para **Par de clave de SSH**, elija el par que demuestre su identidad cuando se conecta a la instancia.
      + Para permitir una imagen y un almacenamiento más grandes, en **Tamaño del volumen de EBS raíz**, ingrese el valor en GIB. 

1. (Opcional) Para cambiar la VPC y las subredes, en **Redes para instancias de Amazon EC2**, realice cualquiera de las siguientes operaciones:
   + Para eliminar una subred, en **Subnets** (Subredes), elija **X**para cada subred que desea eliminar.
   + Para cambiar a una VPC distinta de la VPC **predeterminada**, en **VPC**, elija una **VPC** existente y, a continuación, en **Subredes**, seleccione las subredes. Para una configuración de solo IPv6, elija una VPC que tenga un bloque de CIDR IPv6 y subredes que tengan únicamente un bloque de CIDR IPv6.
   + Elija los grupos de seguridad. En **Grupo de seguridad**, elija una de las siguientes opciones:
     + Para utilizar un grupo de seguridad existente, elija **Utilizar un grupo de seguridad existente** y, a continuación, elija el grupo de seguridad.
     + Para crear un grupo de seguridad, elija **Crear un nuevo grupo de seguridad**. A continuación, elija **Agregar regla** para cada regla de entrada).

       Para obtener información sobre las reglas de entrada, consulte [Opciones de red](#networking-options). 
   + Para asignar automáticamente direcciones IP públicas a sus instancias de contenedor de Amazon EC2, en **Asignación automática de IP pública**, elija una de las siguientes opciones:
     + **Utilizar la configuración de subred**: asigne una dirección IP pública a las instancias cuando la subred en la que se lanzan las instancias sea una subred pública.
     + **Activar**: asigna una dirección IP pública a las instancias.

1. (Opcional) Utilice Información de contenedores, amplíe **Supervisión** y, a continuación, seleccione una de las siguientes opciones:
   + Para usar Información de contenedores con observabilidad mejorada, como se recomienda, elija **Información de contenedores con observabilidad mejorada**.
   + Para usar Información de contenedores, seleccione **Información de contenedores**.

1. (Opcional) Para habilitar los eventos de tareas, expanda **Eventos de tareas** y, a continuación, active **Habilitar eventos de tareas**.

   Cuando habilita los eventos de tareas, Amazon ECS envía eventos de cambio de estado de la tarea a EventBridge. Esto le permite supervisar y responder a los cambios en el ciclo de vida de las tareas automáticamente.

1. (Opcional) Para usar ECS Exec para depurar tareas en el clúster, amplíe la **configuración de solución de problemas** y, a continuación, configure lo siguiente:
   + (Opcional) En el caso de **la clave AWS KMS de ECS Exec**, introduzca el ARN de la clave AWS KMS que desee utilizar para cifrar los datos de la sesión de ECS Exec.
   + (Opcional) Para el **registro de ECS Exec**, elija el destino del registro:
     + Para enviar registros a CloudWatch Logs, elija **Amazon CloudWatch**.
     + Para enviar registros a Amazon S3, elija **Amazon S3**.
     + Para deshabilitar el registro, elija **Ninguno**.

1. (Opcional)

   Si utiliza la supervisión de tiempo de ejecución con la opción manual y quiere que GuardDuty supervise este clúster, seleccione **Agregar etiqueta** y haga lo siguiente:
   + En **Clave**, ingrese **guardDutyRuntimeMonitoringManaged**.
   + En **Valor**, introduzca **true**.

1. (Opcional) Cifre los datos del almacenamiento administrado. En **Cifrado**, para **Almacenamiento administrado**, introduzca el ARN de la clave AWS KMS que desea utilizar para cifrar los datos del almacenamiento administrado.

1. (Opcional) Para administrar las etiquetas de clúster, expanda **Tags** (Etiquetas) y, a continuación, realice una de las siguientes operaciones:

   [Agregar una etiqueta] Elija **Agregar etiqueta** y haga lo siguiente:
   + En **Key (Clave)**, escriba el nombre de la clave.
   + En **Valor**, escriba el valor de la clave.

   [Eliminar una etiqueta] Elija **Eliminar** a la derecha de la clave y el valor de la etiqueta.

1. Seleccione **Create (Crear)**.

## Siguientes pasos
<a name="ec2-cluster-next-steps"></a>

Tras crear el clúster, puede crear definiciones de tareas para sus aplicaciones y, a continuación, ejecutarlas como tareas independientes o como parte de un servicio. Para obtener más información, consulte los siguientes temas:
+ [Definiciones de tareas de Amazon ECS](task_definitions.md)
+ [Ejecución de una aplicación como tarea de Amazon ECS](standalone-task-create.md)
+ [Creación de una implementación de actualización continua de Amazon ECS](create-service-console-v2.md)

# Administración automática de la capacidad de Amazon ECS con el escalado automático de clústeres
<a name="cluster-auto-scaling"></a>

Amazon ECS puede administrar el escalado de las instancias de Amazon EC2 registradas en el clúster. A esto se lo conoce como *escalado automático de clústeres* de Amazon ECS. Activa el escalado administrado al crear el proveedor de capacidad del grupo de escalado automático de Amazon ECS. A continuación, establece un porcentaje objetivo (`targetCapacity`) para la utilización de instancias en este grupo de escalado automático. Amazon ECS crea dos métricas personalizadas de CloudWatch y una política de escalado de seguimiento de destino para el grupo de escalado automático. A continuación, Amazon ECS administra las acciones de escalado y reducción horizontal en función de la utilización de recursos que usan las tareas.

Para cada proveedor de capacidad de grupo de escalado automático asociado a un clúster, Amazon ECS crea y administra los siguientes recursos:
+ Una alarma CloudWatch de bajo valor métrico
+ Una alarma CloudWatch de alto valor métrico
+ Una política de escalado de seguimiento de destino
**nota**  
Amazon ECS crea la política de escalado de seguimiento de destino y la asocia al grupo de escalado automático. Para actualizar la política de escalado de seguimiento de destino, debe actualizar la configuración de escalado administrada por el proveedor de capacidad en lugar de actualizar la política de escalado directamente.

Cuando se desactiva el escalado administrado o se desasocia el proveedor de capacidad de un clúster, Amazon ECS elimina tanto las métricas de CloudWatch como los recursos de política de escalado de seguimiento de destino.

Amazon ECS utiliza las siguientes métricas para determinar qué acciones se deben llevar a cabo:

`CapacityProviderReservation`  
El porcentaje de instancias de contenedores que se utilizan para un proveedor de capacidad específico. Amazon ECS genera esta métrica.  
Amazon ECS establece el valor `CapacityProviderReservation` en un número entre 0 y 100. Amazon ECS utiliza la siguiente fórmula para representar la proporción de la capacidad que queda en el grupo de escalado automático. A continuación, Amazon ECS publica la métrica en CloudWatch. Para obtener más información sobre cómo se calcula la métrica, consulte [Deep Dive on Amazon ECS Cluster Auto Scaling](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/).  

```
CapacityProviderReservation = (number of instances needed) / (number of running instances) x 100
```

`DesiredCapacity`  
La cantidad de capacidad del grupo de escalado automático. Esta métrica no se publica en CloudWatch.

Amazon ECS publica la métrica `CapacityProviderReservation` en CloudWatch en el espacio de nombres `AWS/ECS/ManagedScaling`. La métrica `CapacityProviderReservation` hace que se produzca una de las siguientes acciones:

**El valor `CapacityProviderReservation` es igual a `targetCapacity`**  
El grupo de escalado automático no necesita escalar ni reducirse horizontalmente. Se alcanzó el porcentaje de utilización objetivo.

**El valor `CapacityProviderReservation` es superior a `targetCapacity`**  
Hay más tareas que utilizan un porcentaje de capacidad superior a su porcentaje de `targetCapacity`. El aumento del valor de la métrica `CapacityProviderReservation` hace que la alarma de CloudWatch asociada se active. Esta alarma actualiza el valor `DesiredCapacity` del grupo de Auto Scaling. El grupo de Auto Scaling utiliza este valor para lanzar instancias EC2 y, a continuación, registrarlas en el clúster.  
Cuando la `targetCapacity` es el valor predeterminado del 100 %, las nuevas tareas permanecen en el estado `PENDING` durante el escalado horizontal porque no hay capacidad disponible en las instancias para ejecutarlas. Una vez que las nuevas instancias se registren en ECS, estas tareas comenzarán en las nuevas instancias.

**El valor `CapacityProviderReservation` es inferior a `targetCapacity`**  
Hay menos tareas que utilizan un porcentaje de la capacidad inferior al porcentaje de `targetCapacity` y hay, al menos, una instancia que se puede terminar. El aumento del valor de la métrica de `CapacityProviderReservation` hace que la alarma de CloudWatch asociada se active. Esta alarma actualiza el valor `DesiredCapacity` del grupo de Auto Scaling. El grupo de Auto Scaling utiliza este valor para terminar las instancias de contenedor de EC2 y, a continuación, anularlas del registro del clúster.  
El grupo de escalado automático utiliza políticas de terminación de grupos para determinar qué instancias termina primero durante los eventos de reducción horizontal. Además, evita las instancias con la configuración de protección de reducción horizontal de instancias activada. El escalado automático de clústeres puede administrar qué instancias tienen la configuración de protección de escalado horizontal si activa la protección de terminación administrada. Para obtener más información sobre la protección de terminación administrada, consulte [Control de las instancias que Amazon ECS termina](managed-termination-protection.md). Para obtener más información sobre cómo los grupos de escalado automático terminan instancias, consulte [Controlar qué instancias de escalado automático terminan durante el escalado horizontal](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-instance-protection.html) en la *guía del usuario de Amazon EC2 Auto Scaling*.

Cuando se utiliza el escalado automático de clústeres, se debe tener en cuenta lo siguiente:
+ No cambie ni administre la capacidad deseada para el grupo de escalado automático asociado a un proveedor de capacidad con una política de escalado que no sea la que Amazon ECS administra.
+ Cuando Amazon ECS se escala horizontalmente desde 0 instancias, lanza automáticamente 2 instancias.
+ Amazon ECS utiliza el rol de IAM vinculado al servicio `AWSServiceRoleForECS` para los permisos que necesita para llamar a AWS Auto Scaling en su nombre. Para obtener más información, consulte [Uso de roles vinculados al servicio para Amazon ECS](using-service-linked-roles.md).
+ Cuando se utilizan proveedores de capacidad con grupos de escalado automático, el usuario, grupo o rol que crea el proveedor de capacidad necesita el permiso `autoscaling:CreateOrUpdateTags`. Esto se debe a que Amazon ECS agrega una etiqueta al grupo de Auto Scaling cuando lo asocia al proveedor de capacidad.
**importante**  
Asegúrese de que las herramientas que utilice no eliminen la etiqueta `AmazonECSManaged` del grupo de escalado automático. Si se elimina esta etiqueta, Amazon ECS no podrá administrar el escalado.
+ El escalado automático de clústeres no modifica **MinimumCapacity** ni **MaximumCapacity** para el grupo. Para que el grupo escale horizontalmente, el valor de **MaximumCapacity** (Capacidad máxima) debe ser mayor o igual que 0.
+ Un proveedor de capacidad solo se puede conectar a un clúster al mismo tiempo cuando el escalado automático (escalado administrado) está activado. Si el proveedor de capacidad ha desactivado el escalado administrado, puede asociarlo a varios clústeres.
+ Cuando se desactiva el escalado administrado, el proveedor de capacidad no realiza operaciones de reducción horizontal ni escalado horizontal. Puede utilizar una estrategia de proveedores de capacidad para equilibrar las tareas entre los proveedores de capacidad.
+ La estrategia de `binpack` es la más eficiente en términos de capacidad.
+ Cuando la capacidad de destino es inferior al 100 %, dentro de la estrategia de colocación, la estrategia de `binpack` debe tener un orden superior que la estrategia de `spread`. Esto evita que el proveedor de capacidad se escale horizontalmente hasta que cada tarea tenga una instancia dedicada o se alcance el límite.

## Active el escalado automático de clústeres
<a name="cluster-auto-scale-use"></a>

Puede activar el escalado automático de clústeres con la consola o la AWS CLI.

Cuando crea un clúster que usa proveedores de capacidad de EC2 que utilizan la consola, Amazon ECS crea un grupo de escalado automático en su nombre y establece la capacidad de destino. Para obtener más información, consulte [Creación de un clúster de Amazon ECS para cargas de trabajo de Amazon EC2](create-ec2-cluster-console-v2.md).

También puede crear un grupo de escalado automático y, luego, asignarlo a un clúster. Para obtener más información, consulte [Actualización de un proveedor de capacidad de Amazon ECS](update-capacity-provider-console-v2.md).

Al utilizar la AWS CLI, después de crear el clúster

1. Antes de crear el proveedor de capacidad, debe crear un grupo de escalado automático. Para obtener más información, consulte [Grupos de escalado automático](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html) en la *Guía del usuario de Amazon EC2 Auto Scaling*.

1. Utilice `put-cluster-capacity-providers` para modificar el proveedor de capacidad del clúster. Para obtener más información, consulte [Activación del escalado automático de clústeres de Amazon ECS](turn-on-cluster-auto-scaling.md).

# Optimización del escalado automático de clústeres de Amazon ECS
<a name="capacity-cluster-speed-up-ec2"></a>

Los clientes que ejecutan Amazon ECS en Amazon EC2 pueden aprovechar el escalado automático de clústeres para administrar el escalado de los grupos de Amazon EC2 Auto Scaling. Con el escalado automático de clústeres, puede configurar Amazon ECS para escalar automáticamente el grupo de escalado automático y centrarse únicamente en ejecutar las tareas. Amazon ECS garantizará que el grupo de escalado automático escale en forma ascendente y descendente según sea necesario, sin necesidad de ninguna otra intervención. Los proveedores de capacidad de Amazon ECS están acostumbrados a administrar la infraestructura del clúster al garantizar que haya instancias de contenedor suficientes para satisfacer las exigencias de la aplicación. Para obtener información sobre cómo funciona el escalado automático de clústeres, consulte [Deep Dive on Amazon ECS Cluster Auto Scaling](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/).

El escalado automático de clústeres se basa en una integración que se respalda en CloudWatch con el grupo de escalado automático para ajustar la capacidad del clúster. Por lo tanto, cuenta con una latencia inherente asociada. 
+ Publicación de las métricas de CloudWatch 
+ El tiempo que tardó la métrica `CapacityProviderReservation` en vulnerar las alarmas de CloudWatch (tanto altas como bajas).
+ El tiempo que tardó una instancia de Amazon EC2 recién lanzada en calentarse. Puede realizar las siguientes acciones para que el escalado automático de clústeres responda mejor y, de este modo, las implementaciones sean más rápidas:

## Tamaños de escalado por pasos del proveedor de capacidad
<a name="cas-step-size"></a>

Los proveedores de capacidad de Amazon ECS aumentarán o reducirán las instancias de contenedor para satisfacer las demandas de la aplicación. La cantidad mínima de instancias que Amazon ECS lanzará se establece en 1 de forma predeterminada. Esto puede agregar tiempo adicional a las implementaciones si se necesitan varias instancias para realizar las tareas pendientes. Puede aumentar el valor de [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html) a través de la API de Amazon ECS para aumentar el número mínimo de instancias que Amazon ECS escala o reduce horizontalmente cada vez. Un valor de [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html) demasiado bajo puede limitar el número de instancias de contenedor que se escalan o reducen horizontalmente cada vez, lo que puede ralentizar las implementaciones.

**nota**  
Actualmente, esta configuración solo está disponible a través de las API [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html) o [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html).

## Periodo de preparación de instancias
<a name="instance-warmup-period"></a>

El periodo de preparación de instancias es el periodo de tiempo después del que una instancia de Amazon EC2 recién lanzada puede contribuir a las métricas de CloudWatch para el grupo de escalado automático. Después de que finaliza el periodo de preparación especificado, la instancia se contabiliza para las métricas agregadas del grupo de escalado automático, y el escalado automático de clústeres continúa con su siguiente iteración de cálculos para estimar la cantidad de instancias necesarias.

El valor predeterminado de [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html#ECS-Type-ManagedScaling-instanceWarmupPeriod](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ManagedScaling.html#ECS-Type-ManagedScaling-instanceWarmupPeriod) es de 300 segundos, que puede configurar con un valor inferior a través de las API [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateCapacityProvider.html) o [https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateCapacityProvider.html) para lograr un escalado con mayor capacidad de respuesta. Le recomendamos que establezca el valor en más de 60 segundos para evitar aprovisionar en exceso.

## Capacidad sobrante
<a name="spare-capacity"></a>

Si su proveedor de capacidad no tiene instancias de contenedor disponibles para colocar tareas, debe aumentar (escalar horizontalmente) la capacidad del clúster mediante el lanzamiento de instancias de Amazon EC2 sobre la marcha y esperar a que se inicien antes de poder lanzar contenedores en ellas. Esto puede reducir considerablemente la frecuencia de lanzamiento de las tareas. Dispone de dos opciones aquí.

 En este caso, disponer de capacidad sobrante de Amazon EC2 ya lanzada y lista para ejecutar tareas aumentará la frecuencia efectiva de lanzamiento de tareas. Puede usar la configuración `Target Capacity` para indicar que desea mantener la capacidad sobrante en sus clústeres. Por ejemplo, si se establece el valor de `Target Capacity` en un 80 %, indica que el clúster necesita un 20 % de capacidad sobrante en todo momento. Esta capacidad sobrante puede permitir que cualquier tarea independiente se inicie inmediatamente, lo que garantiza que el lanzamiento de las tareas no se limite. La desventaja de este enfoque es el posible aumento de los costos derivados de mantener la capacidad sobrante de los clústeres. 

Un enfoque alternativo que puede considerar es agregar margen de maniobra a su servicio, no al proveedor de capacidad. Esto significa que, en lugar de reducir la configuración `Target Capacity` para lanzar la capacidad sobrante, puede aumentar la cantidad de réplicas de su servicio al modificar la métrica de escalado de seguimiento de destino o los umbrales de escalado por pasos del escalado automático del servicio. Tenga en cuenta que este enfoque solo será útil para cargas de trabajo con picos de actividad, pero no tendrá ningún efecto cuando implemente nuevos servicios y pase de 0 a N tareas por primera vez. Para obtener más información sobre las políticas de escalado relacionadas, consulte [Políticas de escalado de seguimiento de destino](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-autoscaling-targettracking.html) o [Políticas de escalado por pasos](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-autoscaling-stepscaling.html) en la *Guía para desarrolladores de Amazon Elastic Container Service*.

# Comportamiento de escalado administrado de Amazon ECS
<a name="managed-scaling-behavior"></a>

Cuando tiene proveedores de capacidad de grupos de escalado automático que usan escalado administrado, Amazon ECS calcula la cantidad óptima de instancias que se van a agregar al clúster y utiliza este valor para determinar cuántas instancias se deben solicitar o liberar.

## Comportamiento de escalado horizontal administrado
<a name="managed-scaling-scaleout"></a>

Amazon ECS selecciona un proveedor de capacidad para cada tarea siguiendo la estrategia del proveedor de capacidad desde el servicio, la tarea independiente o el clúster predeterminado. Amazon ECS sigue el resto de estos pasos para un único proveedor de capacidad.

Los proveedores de capacidad ignoran las tareas que no tienen una estrategia de proveedor de capacidad. Una tarea pendiente que no tenga una estrategia de proveedor de capacidad no hará que ningún proveedor de capacidad escale horizontalmente. Las tareas o los servicios no pueden establecer una estrategia de proveedor de capacidad sin establecer un tipo de lanzamiento.

A continuación, se describe el comportamiento de escalado horizontal en más detalle.
+ Agrupe todas las tareas de aprovisionamiento para este proveedor de capacidad de tal modo que cada grupo tenga exactamente los mismos requisitos de recursos.
+ Cuando se utilizan varios tipos de instancias en un grupo de escalado automático, los tipos de instancias del grupo de escalado automático se ordenan por sus parámetros. Estos parámetros incluyen vCPU, memoria, interfaces de red elásticas (ENI), puertos y GPU. Se seleccionan los tipos de instancias más pequeños y más grandes para cada parámetro. Para obtener más información sobre cómo elegir un tipo de instancia, consulte [Instancias de contenedor de Amazon EC2 para Amazon ECS](create-capacity.md).
**importante**  
Si un grupo de tareas tiene requisitos de recursos superiores a los del tipo de instancia más pequeño del grupo de escalado automático, ese grupo de tareas no se puede ejecutar con este proveedor de capacidad. El proveedor de capacidad no escala el grupo de escalado automático. Las tareas permanecen en el estado `PROVISIONING`.  
Para evitar que las tareas permanezcan en el estado `PROVISIONING`, le recomendamos que cree grupos de escalado automático y proveedores de capacidad independientes para diferentes requisitos de recursos mínimos. Cuando ejecute tareas o cree servicios, agregue únicamente proveedores de capacidad a la estrategia del proveedor de capacidad que puedan ejecutar la tarea en el tipo de instancia más pequeño del grupo de escalado automático. Para otros parámetros, puede utilizar restricciones de ubicación.
+ Para cada grupo de tareas, Amazon ECS calcula el número de instancias requeridas para ejecutar las tareas no colocadas. Este cálculo utiliza una estrategia `binpack`. Esta estrategia tiene en cuenta los requisitos de vCPU, memoria, interfaces de red elásticas (ENI), puertos y GPU de las tareas. También tiene en cuenta la disponibilidad de recursos de las instancias de Amazon EC2. Los valores de los tipos de instancias más grandes se consideran como el recuento máximo de instancias calculado. Los valores del tipo de instancia más pequeño se utilizan como protección. Si el tipo de instancia más pequeño no puede ejecutar al menos una instancia de la tarea, el cálculo considera que la tarea no es compatible. Como resultado, se excluye del cálculo de escalado horizontal. Cuando ninguna tarea es compatible con el tipo de instancia más pequeño, el escalado automático de clústeres se detiene y el valor `CapacityProviderReservation` se mantiene en el valor `targetCapacity`.
+ Amazon ECS publica la métrica `CapacityProviderReservation` a CloudWatch con respecto al `minimumScalingStepSize` si se da alguna de las siguientes circunstancias. 
  + El recuento máximo de instancias calculado es inferior al tamaño mínimo del paso de escalado.
  + El valor más bajo de `maximumScalingStepSize` o el recuento máximo de instancias calculado.
+ Las alarmas de CloudWatch utilizan la métrica `CapacityProviderReservation` para los proveedores de capacidad. Cuando la métrica `CapacityProviderReservation` es mayor que el valor de `targetCapacity`, las alarmas también aumentan la `DesiredCapacity` del grupo de escalado automático. El valor `targetCapacity` es una configuración de proveedor de capacidad que se envía a la alarma de CloudWatch durante la fase en que se activa el escalado automático del clúster. 

  El valor de `targetCapacity` predeterminado es el 100 %.
+ El grupo de Auto Scaling lanza instancias de EC2 adicionales. Para evitar el sobreaprovisionamiento, el escalado automático se asegura de que la capacidad de la instancia de EC2 iniciada recientemente se estabilice antes de iniciar nuevas instancias. El escalado automático comprueba si todas las instancias existentes han superado el `instanceWarmupPeriod` (ahora menos el tiempo de lanzamiento de la instancia). El escalado horizontal está bloqueado para las instancias que se encuentran dentro del `instanceWarmupPeriod`.

  El número predeterminado de segundos para que se caliente una instancia recién lanzada es de 300.

Para obtener más información, consulte [Análisis detallado del escalado automático de clústeres de Amazon ECS](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/).

### Consideraciones de escalado horizontal
<a name="scale-out-considerations"></a>

 Tenga en cuenta lo siguiente para el proceso de escalado horizontal:
+ Aunque existen varias restricciones de ubicación, le recomendamos que solo use la restricción de ubicación de tareas `distinctInstance`. Esto evita que el proceso de escalado horizontal se detenga porque está utilizando una restricción de ubicación que no es compatible con las instancias de muestra.
+ El escalado administrado funciona mejor si el grupo de Auto Scaling utiliza los mismos tipos de instancia o similares. 
+ Cuando se requiere un proceso de escalado horizontal y no hay instancias de contenedores en ejecución actualmente, Amazon ECS siempre se escala horizontalmente a dos instancias al principio y, a continuación, realiza procesos de escalado o reducción horizontal adicionales. Cualquier escalado horizontal adicional espera al período de preparación de la instancia. En el caso de los procesos de reducción horizontal, Amazon ECS espera 15 minutos después de un proceso de escalado horizontal, antes de iniciar los procesos de reducción horizontal en todo momento.
+ El segundo paso de escalado horizontal debe esperar hasta que `instanceWarmupPeriod` venza, lo cual podría afectar el límite de escalado general. Si necesita reducir este tiempo, asegúrese de que `instanceWarmupPeriod` sea lo suficientemente grande como para que la instancia de EC2 inicie el agente de Amazon ECS (lo que evita el sobreaprovisionamiento).
+ El escalado automático de clústeres admite la configuración de lanzamiento, plantillas de lanzamiento y varios tipos de instancias en el grupo de escalado automático del proveedor de capacidad. También puede utilizar la selección del tipo de instancia basada en atributos sin tener varios tipos de instancias.
+ Cuando utilice un grupo de Auto Scaling con tipos de instancias bajo demanda e instancias múltiples o instancias de spot, coloque los tipos de instancias más grandes en la lista de prioridades y no especifique ninguna ponderación. En este momento, no se admite la especificación de ponderaciones. Para obtener más información, consulte [Grupos de Auto Scaling con varios tipos de instancias](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-mixed-instances-groups.html) en la *Guía del usuario de AWS Auto Scaling*.
+ A continuación, Amazon ECS lanzará el `minimumScalingStepSize` si el recuento máximo de instancias calculado es menor que el tamaño mínimo del paso de escalado o el `maximumScalingStepSize` o el valor del recuento máximo de instancias calculado, de ambas opciones, la que sea menor.
+ Si un servicio de Amazon ECS o `run-task` lanza una tarea y las instancias de contenedor del proveedor de capacidad no tienen recursos suficientes para iniciar la tarea, Amazon ECS limita el número de tareas con este estado para cada clúster e impide que cualquier tarea supere este límite. Para obtener más información, consulte [Cuotas de servicio de Amazon ECS](service-quotas.md).

## Comportamiento de reducción horizontal administrada
<a name="managed-scaling-scalein"></a>

Amazon ECS supervisa las instancias de contenedor de cada proveedor de capacidad dentro del clúster. Cuando una instancia de contenedor no ejecuta ninguna tarea, la instancia de contenedor se considera vacía y Amazon ECS inicia el proceso de reducción horizontal. 

Las alarmas de reducción horizontal de CloudWatch requieren 15 puntos de datos (15 minutos) antes de que comience el proceso de reducción horizontal del grupo de Auto Scaling. Una vez que se inicia el proceso de reducción horizontal hasta que Amazon ECS necesite reducir el número de instancias de contenedores registradas, el grupo de escalado automático establece el valor `DesireCapacity` para que sea superior a una instancia e inferior al 50 % por minuto.

Cuando Amazon ECS solicita un escalado horizontal (cuando `CapacityProviderReservation` es superior a 100) mientras un proceso de reducción horizontal está en curso, el proceso de reducción se detiene y comenzará desde el principio si es necesario.

A continuación, se describe el comportamiento de reducción horizontal con más detalle:

1. Amazon ECS calcula el número de instancias de contenedores que están vacías. Una instancia de contenedor se considera vacía incluso cuando se están ejecutando tareas de daemon.

1. Amazon ECS establece el valor `CapacityProviderReservation` en un número entre 0 y 100 que utiliza la siguiente fórmula para representar la relación entre el tamaño que debe tener el grupo de escalado automático y su tamaño real, expresado en porcentaje. A continuación, Amazon ECS publica la métrica en CloudWatch. Para obtener más información sobre cómo se calcula la métrica, consulte [Profundización en el escalado automático de clústeres de Amazon ECS](https://aws.amazon.com/blogs/containers/deep-dive-on-amazon-ecs-cluster-auto-scaling/). 

   ```
   CapacityProviderReservation = (number of instances needed) / (number of running instances) x 100
   ```

1. La métrica `CapacityProviderReservation` genera una alarma de CloudWatch. Esta alarma actualiza el valor `DesiredCapacity` del grupo de Auto Scaling. A continuación, se lleva a cabo una de las siguientes acciones:
   + Si no utiliza la terminación administrada del proveedor de capacidad, el grupo de escalado automático selecciona las instancias de EC2 mediante la política de terminación de grupos de escalado automático y las termina hasta que el número de instancias de EC2 llegue a la `DesiredCapacity`. A continuación, las instancias de contenedor se anulan del registro del clúster.
   + Si todas las instancias de contenedor utilizan la protección contra terminación administrada, Amazon ECS elimina la protección para la reducción horizontal de las instancias de contenedor que están vacías. El grupo de Auto Scaling podrá terminar las instancias de EC2. A continuación, las instancias de contenedor se anulan del registro del clúster.

# Control de las instancias que Amazon ECS termina
<a name="managed-termination-protection"></a>

**importante**  
Debe activar la *protección para la reducción horizontal de instancias* de Auto Scaling en el grupo de escalado automático para usar la característica de protección de terminación administrada del escalado automático de clústeres.

La protección contra la terminación administrada permite que el escalado automático de clústeres controle qué instancias se terminan. Cuando utiliza la protección contra la terminación administrada, Amazon ECS solo termina las instancias de EC2 que no tienen ninguna tarea de Amazon ECS en ejecución. Las tareas que ejecuta un servicio que utiliza la estrategia de programación de `DAEMON` se ignoran y una instancia se puede terminar mediante el escalado automático del clúster, incluso cuando la instancia ejecuta estas tareas. Esto se debe a que todas las instancias del clúster ejecutan estas tareas.

Amazon ECS activa primero la opción de *protección contra la reducción horizontal* para las instancias de EC2 del grupo de escalado automático. A continuación, Amazon ECS coloca las tareas en las instancias. Cuando se detienen todas las tareas que no son daemon en una instancia, Amazon ECS inicia el proceso de reducción horizontal y desactiva la protección de reducción horizontal de la instancia de EC2. El grupo de Auto Scaling puede terminar la instancia.

La *protección para la reducción horizontal en instancias* de Auto Scaling controla qué instancias de EC2 se pueden terminar en Auto Scaling. Las instancias con la característica de reducción horizontal activada no se pueden finalizar durante el proceso de reducción horizontal. Para obtener más información sobre la protección para la reducción horizontal en instancias de Auto Scaling, consulte [Uso de la protección para la reducción horizontal de instancias](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-instance-protection.html) en la *Guía del usuario de Amazon EC2 Auto Scaling*.

Puede establecer el porcentaje de `targetCapacity` para disponer de capacidad sobrante. De este modo, las tareas futuras se inician de forma más rápida porque el grupo de escalado automático no tiene que iniciar más instancias. Amazon ECS utiliza el valor de capacidad de destino para administrar la métrica de CloudWatch que crea el servicio. Amazon ECS administra la métrica de CloudWatch. El grupo de escalado automático se considera un estado estable para que no se requiera ninguna acción de escalado. Los valores pueden ser del 0 al 100 %. Por ejemplo, para configurar Amazon ECS para que 10 % de la capacidad se mantenga libre además de la utilizada por las tareas de Amazon ECS, establezca el valor de capacidad de destino en 90 %. Al establecer el valor `targetCapacity` para un proveedor de capacidad, debe tener en cuenta lo siguiente.
+ Un valor `targetCapacity` inferior al 100 % representa la cantidad de capacidad libre (instancias de Amazon EC2) que debe estar presente en el clúster. Capacidad libre significa que no hay tareas en ejecución.
+ Restricciones de ubicación, tales como zonas de disponibilidad, sin `binpack` adicional, obliga a Amazon ECS a ejecutar finalmente una tarea por instancia, lo que podría no ser el comportamiento deseado.

Debe activar la protección para la reducción horizontal de instancias de Auto Scaling en el grupo de escalado automático para usar la protección contra terminación administrada. Si no activas la protección para la reducción horizontal, activar la protección contra terminación administrada puede provocar un comportamiento no deseado. Por ejemplo, es posible que algunas instancias se estanquen en estado de vaciado. Para obtener más información, consulte [Uso de la protección para la reducción horizontal de instancias](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-instance-protection.html) en la *Guía del usuario de Amazon EC2 Auto Scaling*.

Cuando utilice la protección contra terminación con un proveedor de capacidad, no realice ninguna acción manual, como separar la instancia, en el grupo de escalado automático asociado al proveedor de capacidad. Las acciones manuales pueden interrumpir la operación de reducción horizontal del proveedor de capacidad. Si separa una instancia del grupo de escalado automático, también debe [anular el registro de la instancia separada](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deregister_container_instance.html) del clúster de Amazon ECS.

# Actualización de la protección contra la finalización administrada para los proveedores de capacidad de Amazon ECS
<a name="update-managed-termination-protection"></a>

Cuando use la protección contra la finalización administrada, debe actualizar la configuración de los proveedores de capacidad existentes.

## Consola
<a name="update-managed-termination-protection-console"></a>

1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. En la página **Clusters** (Clústeres), elija el clúster.

1. En la página del clúster: elija la pestaña **Infraestructura**.

1. Elija el proveedor de capacidad.

1. Elija **Actualizar** para modificar la configuración del proveedor de capacidad.

1. En **Configuración del grupo de escalado automático**, active o desactive **Protección contra la finalización administrada** para activar o desactivar la característica.

1. Elija **Actualizar**.

## AWS CLI
<a name="update-managed-termination-protection-cli"></a>

Puede actualizar la configuración de protección contra la finalización administrada de un proveedor de capacidad mediante el comando `update-capacity-provider`:

Para activar la protección contra la finalización administrada:

```
aws ecs update-capacity-provider \
  --name CapacityProviderName \
  --auto-scaling-group-provider "managedScaling={status=ENABLED,targetCapacity=70,minimumScalingStepSize=1,maximumScalingStepSize=10},managedTerminationProtection=ENABLED"
```

Para desactivar la protección contra la finalización administrada:

```
aws ecs update-capacity-provider \
  --name CapacityProviderName \
  --auto-scaling-group-provider "managedScaling={status=ENABLED,targetCapacity=70,minimumScalingStepSize=1,maximumScalingStepSize=10},managedTerminationProtection=DISABLED"
```

**nota**  
Es posible que los cambios tarden unos minutos en aplicarse en todo el clúster. Al activar la protección contra la finalización administrada, las instancias que ya estén ejecutando tareas se protegerán de los eventos de reducción horizontal. Al desactivar la protección de finalización administrada, el indicador de protección se eliminará de las instancias durante el siguiente ciclo de administración del proveedor de capacidad de ECS.

## Consola para ejecutar tareas
<a name="update-managed-termination-protection-console"></a>

1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. En la página **Clusters** (Clústeres), elija el clúster.

1. En la página del clúster, elija la pestaña **Tareas**.

1. Elija la tarea.

1. En **Configuración**, active o desactive **Protección de terminación administrada** para activar o desactivar la característica.

1. Elija **Configurar la protección de reducción horizontal de tareas**.

   Se muestra el cuadro de diálogo **Configurar la protección de reducción horizontal de tareas**.

   1. En la sección **Protección de reducción horizontal de tareas**, active la opción **Activar**.

   1. En **Caduca en minutos**, introduzca el número de minutos que faltan para que finalice la protección de reducción horizontal de tareas.

   1. Elija **Update (Actualizar)**.

# Activación del escalado automático de clústeres de Amazon ECS
<a name="turn-on-cluster-auto-scaling"></a>

Active el escalado automático del clúster para que Amazon ECS administre el escalado de las instancias de Amazon EC2 registradas en su clúster.

Si quiere utilizar la consola para activar el escalado automático de clústeres, consulte [Creación de un proveedor de capacidad de Amazon ECS](create-capacity-provider-console-v2.md).

Antes de comenzar, cree un grupo de escalado automático y un proveedor de capacidad. Para obtener más información, consulte [Proveedores de capacidad de Amazon ECS para cargas de trabajo de EC2](asg-capacity-providers.md).

Para activar el escalado automático de clústeres, asocie el proveedor de capacidad al clúster y, a continuación, active el escalado automático de clústeres.

1. Utilice el comando `put-cluster-capacity-providers` para asociar uno o más proveedores de capacidad con el clúster. 

   Para agregar proveedores de capacidad de AWS Fargate, incluya los proveedores de capacidad de `FARGATE` y `FARGATE_SPOT` en la solicitud. Para obtener más información, consulte `[put-cluster-capacity-providers](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-cluster-capacity-providers.html)` en la *Referencia de los comandos de AWS CLI*.

   ```
   aws ecs put-cluster-capacity-providers \
     --cluster ClusterName \
     --capacity-providers CapacityProviderName FARGATE FARGATE_SPOT \
     --default-capacity-provider-strategy capacityProvider=CapacityProvider,weight=1
   ```

   Si desea agregar un grupo de escalado automático para EC2, incluya el nombre del grupo de escalado automático en la solicitud. Para obtener más información, consulte `[put-cluster-capacity-providers](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-cluster-capacity-providers.html)` en la *Referencia de los comandos de AWS CLI*.

   ```
   aws ecs put-cluster-capacity-providers \
     --cluster ClusterName \
     --capacity-providers CapacityProviderName \
     --default-capacity-provider-strategy capacityProvider=CapacityProvider,weight=1
   ```

1. Utilice el comando `describe-clusters` para verificar que la asociación se haya realizado correctamente. Para obtener más información, consulte `[describe-clusters](https://docs.aws.amazon.com/cli/latest/reference/ecs/describe-clusters.html)` en la *Referencia de los comandos de AWS CLI*.

   ```
   aws ecs describe-clusters \
     --cluster ClusterName \
     --include ATTACHMENTS
   ```

1. Utilice el comando `update-capacity-provider` para activar el escalado automático administrado para el proveedor de capacidad. Para obtener más información, consulte `[update-capacity-provider](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-capacity-provider.html)` en la *Referencia de los comandos de AWS CLI*.

   ```
   aws ecs update-capacity-provider \
     --name CapacityProviderName \
     --auto-scaling-group-provider "managedScaling={status=ENABLED}"
   ```

# Desactivación del escalado automático de clústeres de Amazon ECS
<a name="turn-off-cluster-auto-scaling"></a>

Desactive el escalado automático del clúster cuando necesite un control más granular de las instancias EC2 registradas en su clúster,

Para desactivar el escalado automático de clústeres para un clúster, puede desasociar el proveedor de capacidad con el escalado administrado activado desde el clúster o actualizar el proveedor de capacidad para desactivar el escalado administrado.

## Desasociación del proveedor de capacidad
<a name="disassociate-capacity-provider"></a>

Siga estos pasos para desasociar un proveedor de capacidad de un clúster.

1. Utilice el comando `put-cluster-capacity-providers` para desasociar el proveedor de capacidad de grupo de escalado automático con el clúster. El clúster puede mantener la asociación con los proveedores de capacidad de AWS Fargate. Para obtener más información, consulte `[put-cluster-capacity-providers](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-cluster-capacity-providers.html)` en la *Referencia de los comandos de AWS CLI*.

   ```
   aws ecs put-cluster-capacity-providers \
     --cluster ClusterName \
     --capacity-providers FARGATE FARGATE_SPOT \
     --default-capacity-provider-strategy '[]'
   ```

   Utilice el comando `put-cluster-capacity-providers` para desasociar el proveedor de capacidad de grupo de escalado automático con el clúster. Para obtener más información, consulte `[put-cluster-capacity-providers](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-cluster-capacity-providers.html)` en la *Referencia de los comandos de AWS CLI*.

   ```
   aws ecs put-cluster-capacity-providers \
     --cluster ClusterName \
     --capacity-providers [] \
     --default-capacity-provider-strategy '[]'
   ```

1. Utilice el comando `describe-clusters` para verificar que la disociación se haya realizado correctamente. Para obtener más información, consulte `[describe-clusters](https://docs.aws.amazon.com/cli/latest/reference/ecs/describe-clusters.html)` en la *Referencia de los comandos de AWS CLI*.

   ```
   aws ecs describe-clusters \
     --cluster ClusterName \
     --include ATTACHMENTS
   ```

## Desactive el escalado administrado para el proveedor de capacidad
<a name="turn-off-managed-scaling"></a>

Siga estos pasos para desactivar el escalado administrado para el proveedor de capacidad.
+ Utilice el comando `update-capacity-provider` para desactivar el escalado automático administrado para el proveedor de capacidad. Para obtener más información, consulte `[update-capacity-provider](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-capacity-provider.html)` en la *Referencia de los comandos de AWS CLI*.

  ```
  aws ecs update-capacity-provider \
    --name CapacityProviderName \
    --auto-scaling-group-provider "managedScaling={status=DISABLED}"
  ```

# Creación de un proveedor de capacidad de Amazon ECS
<a name="create-capacity-provider-console-v2"></a>

Una vez finalizada la creación del clúster, puede crear un nuevo proveedor de capacidad (grupo de escalado automático) para EC2. Los proveedores de capacidad ayudan a administrar y escalar la infraestructura para sus aplicaciones.

Antes de crear el proveedor de capacidad, debe crear un grupo de escalado automático. Para obtener más información, consulte [Grupos de escalado automático](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html) en la *Guía del usuario de Amazon EC2 Auto Scaling*.

**Para crear un proveedor de capacidad para el clúster (consola de Amazon ECS)**

1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. En el panel de navegación, seleccione **Clusters (Clústeres)**.

1. En la página **Clusters** (Clústeres), elija el clúster.

1. En la página **Cluster: *name*** (Clúster: nombre), elija **Infrastructure** (Infraestructura) y, a continuación, elija **Create** (Crear).

1. En la página **Create capacity providers** (Crear proveedores de capacidad), configure las siguientes opciones.

   1. En **Basic details** (Detalles básicos), ingrese un nombre de proveedor de capacidad único en **Capacity provider name** (Nombre de proveedor de capacidad).

   1. En **Auto Scaling group** (Grupo de escalado automático), para **Use an existing Auto Scaling group** (Usar un grupo de escalado automático existente), elija el grupo de escalado automático.

   1. (Opcional) Para configurar una política de escalado, en **Scaling policies** (Políticas de escalado), configure las siguientes opciones.
      + Para que Amazon ECS administre las acciones de reducción y escalado horizontales, seleccione **Activar el escalado administrado**.
      + Para evitar que finalice la instancia de EC2 con tareas de Amazon ECS en ejecución, seleccione **Turn on scaling protection** (Activar la protección de escalado).
      + En **Set target capacity** (Definir capacidad de destino), ingrese el valor de destino para la métrica de CloudWatch utilizada en la política de escalado de seguimiento de destino administrada por Amazon ECS.

1. Seleccione **Crear**.

# Actualización de un proveedor de capacidad de Amazon ECS
<a name="update-capacity-provider-console-v2"></a>

Al utilizar un grupo de escalado automático como proveedor de capacidad, puede modificar la política de escalado del grupo.

**Actualización de un proveedor de capacidad del clúster (consola de Amazon ECS)**

1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. En el panel de navegación, seleccione **Clusters (Clústeres)**.

1. En la página **Clusters** (Clústeres), elija el clúster.

1. En la página **Cluster: *name*** (Clúster: nombre), elija **Infrastructure** (Infraestructura) y, a continuación, elija **Update** (Actualizar).

1. En la página **Create capacity providers** (Crear proveedores de capacidad), configure las siguientes opciones.

   1. En **Grupo de escalado automático**, en **Políticas de escalado**, configure las siguientes opciones.
     + Para que Amazon ECS administre las acciones de reducción y escalado horizontales, seleccione **Activar el escalado administrado**.
     + Para evitar que las instancias de EC2 con tareas de Amazon ECS en ejecución terminen, seleccione **Activar la protección de escalado**.
     + En **Set target capacity** (Definir capacidad de destino), ingrese el valor de destino para la métrica de CloudWatch utilizada en la política de escalado de seguimiento de destino administrada por Amazon ECS.

1. Elija **Actualizar**.

# Eliminación de un proveedor de capacidad de Amazon ECS
<a name="delete-capacity-provider-console-v2"></a>

Si ha terminado de utilizar un proveedor de capacidad de grupos de Auto Scaling, puede eliminarlo. Una vez eliminado el grupo, el proveedor de capacidad del grupo de escalado automático pasa al estado `INACTIVE`. Es posible que los proveedores de capacidad con estado `INACTIVE` permanezcan detectables en la cuenta durante un período de tiempo. Sin embargo, este comportamiento está sujeto a cambios en el futuro, por lo que no debe contar con la permanencia de los proveedores de capacidad `INACTIVE`. Antes de eliminar un proveedor de capacidad del grupo de escalado automático, se debe eliminar el proveedor de capacidad de la estrategia de proveedores de capacidad de todos los servicios. Puede usar la API `UpdateService` o el flujo de trabajo del servicio de actualización de la consola de Amazon ECS para eliminar un proveedor de capacidad de la estrategia de proveedores de capacidad de un servicio. Utilice la opción **Forzar una nueva implementación** a fin de garantizar que cualquier tarea que utilice la capacidad de la instancia de Amazon EC2 proporcionada por el proveedor de capacidad pase a utilizar la capacidad de los proveedores de capacidad restantes.

**Para eliminar un proveedor de capacidad para el clúster (consola de Amazon ECS)**

1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. En el panel de navegación, seleccione **Clusters (Clústeres)**.

1. En la página **Clusters** (Clústeres), elija el clúster.

1. En la página **Cluster: *name*** (Clúster: nombre), elija **Infrastructure** (Infraestructura), el grupo de escalado automático y, a continuación, elija **Delete** (Eliminar).

1. En el cuadro de confirmación, ingrese **eliminar *nombre del grupo de escalado automático***.

1. Elija **Eliminar**.

# Detención segura de las cargas de trabajo de Amazon ECS que se ejecutan en instancias de EC2
<a name="managed-instance-draining"></a>

El vaciado de instancias administradas facilita la terminación gradual de instancias de Amazon EC2. Esto permite que sus cargas de trabajo se detengan de forma segura y se reprogramen para convertirlas en instancias que no terminan. El mantenimiento y las actualizaciones de la infraestructura se llevan a cabo sin preocuparse por la interrupción de las cargas de trabajo. Al utilizar el drenaje de instancias administradas, simplifica los flujos de trabajo de administración de la infraestructura que requieren el reemplazo de las instancias de Amazon EC2 y, al mismo tiempo, garantiza la resiliencia y la disponibilidad de sus aplicaciones.

El drenaje de instancias administradas por Amazon ECS funciona con los reemplazos de instancias de grupos de escalado automático. En función de la actualización de las instancias y de su vida útil máxima, los clientes pueden asegurarse de cumplir con las normas de seguridad y sistema operativo más recientes en lo que respecta a su capacidad.

El drenaje de instancias administradas solo se puede utilizar con los proveedores de capacidad de Amazon ECS. Puede activar el drenaje de instancias administradas al crear o actualizar los proveedores de capacidad del grupo de escalado automático mediante la consola de Amazon ECS, la AWS CLI o el SDK.

El drenaje de instancias administradas por Amazon ECS cubre los siguientes eventos.
+ [Actualización de instancias de grupos de escalado automático](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-instance-refresh.html): utilice la actualización de instancias para reemplazar de forma continua las instancias de Amazon EC2 del grupo de escalado automático, en lugar de hacerlo manualmente por lotes. Esto es útil cuando necesita reemplazar un gran número de instancias. La actualización de instancias se inicia a través de la consola de Amazon EC2 o la API `StartInstanceRefresh`. Asegúrese de seleccionar `Replace` para la protección de la reducción horizontal cuando llame a `StartInstanceRefresh` si utiliza la protección contra terminación administrada.
+ [Duración máxima de la instancia](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-max-instance-lifetime.html): puede definir una vida útil máxima cuando se trata de reemplazar las instancias del grupo de escalado automático. Esto resulta útil para programar las instancias de reemplazo en función de las políticas de seguridad internas o el cumplimiento.
+ Reducción horizontal de grupos de escalado automático: en función de las políticas de escalado y las acciones de escalado programadas, el grupo de escalado automático admite el escalado automático de instancias. Al utilizar un grupo de escalado automático como proveedor de capacidad de Amazon ECS, puede reducir horizontalmente las instancias de grupo de escalado automático cuando no se esté ejecutando ninguna tarea en ellas.
+ [Comprobaciones de estado de grupos de escalado automático](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-health-checks.html): el grupo de escalado automático admite muchas comprobaciones de estado para administrar la terminación de instancias en mal estado.
+ [Actualizaciones de pila de CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-direct.html): puede agregar un atributo `UpdatePolicy` a su pila de CloudFormation para llevar a cabo actualizaciones continuas cuando el grupo cambie.
+ [Reequilibrio de la capacidad de spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html): el grupo de escalado automático intenta reemplazar de forma proactiva las instancias de spot que tienen un mayor riesgo de interrupción en función del aviso de reequilibrio de capacidad de Amazon EC2. El grupo de escalado automático finaliza la instancia anterior cuando se inicia la instancia de reemplazo y está en buen estado. El drenaje de instancias administradas por Amazon ECS drena la instancia de spot del mismo modo que drena una instancia que no es de spot.
+ [Interrupción de spot](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-capacity-rebalancing.html): las instancias de spot se finalizan con dos minutos de antelación. El drenaje de instancias administradas por Amazon ECS pone a la instancia en estado de drenaje como respuesta.

**Enlaces de ciclo de vida de Amazon EC2 Auto Scaling con el drenaje de instancias administradas**  
Los enlaces de ciclo de vida de los grupos de escalado automático permiten al cliente crear soluciones que se activan mediante ciertos eventos del ciclo de vida de la instancia, así como llevar a cabo una acción personalizada cuando se produce ese evento determinado. Un grupo de escalado automático permite hasta 50 enlaces. Pueden existir varios enlaces de terminación y se ejecutan en paralelo, y el grupo de escalado automático espera a que todos los enlaces terminen antes de terminar una instancia.

Además de la terminación de enlace administrada por Amazon ECS, también puede configurar sus propios enlaces de terminación del ciclo de vida. Los enlaces de ciclo de vida tienen una `default action` y recomendamos configurar `continue` como valor predeterminado para garantizar que otros enlaces, como el enlace administrado por Amazon ECS, no se vean afectados por ningún error de los enlaces personalizados.

Si ya configuró un enlace de ciclo de vida de terminación de un grupo de escalado automático y también habilitó el drenaje de instancias administradas por Amazon ECS, se ejecutarán ambos enlaces de ciclo de vida. Sin embargo, los tiempos relativos no están garantizados. Los enlaces de ciclo de vida tienen una configuración de `default action` para especificar la acción que se debe llevar a cabo cuando se agota el tiempo de espera. En caso de errores, le recomendamos el uso de `continue` como resultado predeterminado en su enlace personalizado. Esto garantiza que otros enlaces, especialmente los administrados por Amazon ECS, no se vean afectados por ningún error en su enlace de ciclo de vida personalizado. El resultado alternativo de `abandon` provoca que se omitan los demás ganchos y debe evitarse. Para obtener más información sobre los enlaces de ciclo de vida del grupo de escalado automático, consulte [Amazon EC2 Auto Scaling lifecycle hooks](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html) en la Guía del usuario de *Amazon EC2* Auto Scaling.

**Drenaje de instancias administradas y tareas**  
El drenaje de instancias administradas por Amazon ECS utiliza la característica de drenaje existente que se encuentra en las instancias de contenedor. La característica de [drenaje de instancias de contenedor](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/container-instance-draining.html) reemplaza y detiene las tareas de réplica que pertenecen a un servicio de Amazon ECS. Una tarea independiente, como una invocada por `RunTask`, que esté en estado `PENDING` o `RUNNING` no se ve afectada. Tiene que esperar a que se completen o detenerlas manualmente. La instancia de contenedor permanece en ese estado `DRAINING` hasta que se detienen todas las tareas o hasta que hayan transcurrido 48 horas. Las tareas de daemon son las últimas en detenerse una vez que se hayan detenido todas las tareas de réplica.

**Drenaje de instancias administradas y protección contra terminación administrada**  
El drenaje de instancias administradas funciona incluso si la terminación administrada está deshabilitada. Para obtener más información sobre la protección contra la terminación administrada, consulte [Control de las instancias que Amazon ECS termina](managed-termination-protection.md). 

En la siguiente tabla se resume el comportamiento de las diferentes combinaciones de terminación administrada y drenaje administrado.


|  Terminación administrada  |  Drenaje administrado  |  Resultado  | 
| --- | --- | --- | 
|  Habilitado  | Habilitado | Amazon ECS protege las instancias de Amazon EC2 que ejecutan tareas para que no se terminen debido a eventos de reducción horizontal. Todas las instancias en proceso de terminación, como las que no tienen configurada la protección contra terminación, las que han recibido una interrupción de spot o las que se ven forzadas por una actualización de la instancia, se drenan sin problemas. | 
|  Deshabilitado  | Habilitado | Amazon ECS no protege las instancias de Amazon EC2 que ejecutan tareas para que no se reduzcan horizontalmente. Sin embargo, cualquier instancia que se termine se drena sin problemas. | 
|  Habilitado  | Deshabilitado | Amazon ECS protege las instancias de Amazon EC2 que ejecutan tareas para que no se terminen debido a eventos de reducción horizontal. Sin embargo, las instancias aún se pueden terminar si se produce una interrupción de spot o se fuerza una actualización de la instancia, o si no se está ejecutando ninguna tarea. Amazon ECS no lleva a cabo correctamente el drenaje de estas instancias e inicia tareas de servicio de reemplazo una vez que se detienen. | 
|  Deshabilitad  | Deshabilitado | Las instancias de Amazon EC2 se pueden reducir horizontalmente o terminar en cualquier momento, incluso si ejecutan tareas de Amazon ECS. Amazon ECS iniciará las tareas de servicio de reemplazo una vez que se detengan. | 

**Drenaje de instancias administradas y drenaje de instancias de spot**  
Con el drenaje de instancias de spot, puede configurar una variable de entorno `ECS_ENABLE_SPOT_INSTANCE_DRAINING` en el agente de Amazon ECS que permita a Amazon ECS colocar una instancia en estado de drenaje en respuesta a la interrupción de spot de dos minutos. El drenaje de instancias administradas por Amazon ECS facilita el cierre correcto de las instancias de Amazon EC2 que se están terminando por muchos motivos, no solo por una interrupción de spot. Por ejemplo, puede utilizar el reequilibrio de capacidad de Amazon EC2 Auto Scaling para reemplazar de forma proactiva la instancia de spot con un riesgo elevado de interrupción, y el drenaje de instancias administradas cierra sin problemas la instancia de spot que se está reemplazando. Cuando utiliza el drenaje de instancias administradas, no necesita habilitar el drenaje de instancias de spot por separado, por lo que `ECS_ENABLE_SPOT_INSTANCE_DRAINING` en los datos de usuario del grupo de escalado automático es redundante. Para obtener más información sobre el drenaje de instancias de spot, consulte [Spot Instances](create-capacity.md#container-instance-spot).

## Funcionamiento del drenaje de instancias administradas con EventBridge
<a name="managed-instance-draining-eventbridge"></a>

Los eventos de drenaje de instancias administradas por Amazon ECS se publican en Amazon EventBridge, y Amazon ECS crea una regla administrada de EventBridge en el bus predeterminado de su cuenta para admitir el drenaje de instancias administradas. Puede filtrar estos eventos a otros servicios de AWS, como Lambda, Amazon SNS y Amazon SQS, para supervisar y solucionar problemas.
+ Amazon EC2 Auto Scaling envía un evento a EventBridge cuando se invoca un enlace de ciclo de vida.
+ Los avisos de interrupción de spot se publican en EventBridge.
+ Amazon ECS genera mensajes de error que puede recuperar a través de la consola y las API de Amazon ECS.
+ EventBridge cuenta con mecanismos de reintento integrados para mitigar los errores temporales.

# Configuración de los proveedores de capacidad de Amazon ECS para cerrar las instancias de forma segura
<a name="enable-managed-instance-draining"></a>

Puede habilitar el drenaje de instancias administradas al crear o actualizar los proveedores de capacidad del grupo de escalado automático mediante la consola de Amazon ECS y la AWS CLI.

**nota**  
El drenaje de instancias administradas está activado de manera predeterminada al crear un proveedor de capacidad.

A continuación, se muestran ejemplos en los que se usa la AWS CLI para crear un proveedor de capacidad con el drenaje de instancias administradas habilitado y para habilitar el drenaje de instancias administradas para el proveedor de capacidad existente de un clúster.

**Creación de un proveedor de capacidad con el drenaje de instancias administradas habilitado**  
Para crear un proveedor de capacidad con el drenaje de instancias administradas habilitado, utilice el comando `create-capacity-provider`. Establezca el parámetro `managedDraining` como `ENABLED`.

```
aws ecs create-capacity-provider \
--name capacity-provider \
--auto-scaling-group-provider '{
  "autoScalingGroupArn": "asg-arn",
  "managedScaling": {
    "status": "ENABLED",
    "targetCapacity": 100,
    "minimumScalingStepSize": 1,
    "maximumScalingStepSize": 1
  },
  "managedDraining": "ENABLED",
  "managedTerminationProtection": "ENABLED",
}'
```

Respuesta:

```
{
    "capacityProvider": {
        "capacityProviderArn": "capacity-provider-arn",
        "name": "capacity-provider",
        "status": "ACTIVE",
        "autoScalingGroupProvider": {
            "autoScalingGroupArn": "asg-arn",
            "managedScaling": {
                "status": "ENABLED",
                "targetCapacity": 100,
                "minimumScalingStepSize": 1,
                "maximumScalingStepSize": 1
            },
            "managedTerminationProtection": "ENABLED"
            "managedDraining": "ENABLED"
        }
    }
}
```

**Habilitación del drenaje de instancias administradas para el proveedor de capacidad existente de un clúster**  
Para habilitar el drenaje de instancias administradas para el proveedor de capacidad existente de un clúster, utilice el comando `update-capacity-provider`. Verá que `managedDraining` actualmente indica `DISABLED` y `updateStatus` indica `UPDATE_IN_PROGRESS`.

```
aws ecs update-capacity-provider \
--name cp-draining \
--auto-scaling-group-provider '{
  "managedDraining": "ENABLED"
}
```

Respuesta:

```
{
    "capacityProvider": {
        "capacityProviderArn": "cp-draining-arn",
        "name": "cp-draining",
        "status": "ACTIVE",
        "autoScalingGroupProvider": {
            "autoScalingGroupArn": "asg-draining-arn",
            "managedScaling": {
                "status": "ENABLED",
                "targetCapacity": 100,
                "minimumScalingStepSize": 1,
                "maximumScalingStepSize": 1,
                "instanceWarmupPeriod": 300
            },
            "managedTerminationProtection": "DISABLED",
            "managedDraining": "DISABLED" // before update
        },
        "updateStatus": "UPDATE_IN_PROGRESS", // in progress and need describe again to find out the result
        "tags": [
        ]
    }
}
```



Use el comando `describe-clusters` e incluya `ATTACHMENTS`. El `status` del archivo adjunto de drenaje de instancias administradas es `PRECREATED`, y el `attachmentsStatus` general es `UPDATING`.

```
aws ecs describe-clusters --clusters cluster-name --include ATTACHMENTS
```

Respuesta:

```
{
    "clusters": [
        {
            ...

            "capacityProviders": [
                "cp-draining"
            ],
            "defaultCapacityProviderStrategy": [],
            "attachments": [
                # new precreated managed draining attachment
                {
                    "id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
                    "type": "managed_draining",
                    "status": "PRECREATED",
                    "details": [
                        {
                            "name": "capacityProviderName",
                            "value": "cp-draining"
                        },
                        {
                            "name": "autoScalingLifecycleHookName",
                            "value": "ecs-managed-draining-termination-hook"
                        }
                    ]
                },

                ...

            ],
            "attachmentsStatus": "UPDATING"
        }
    ],
    "failures": []
}
```

Cuando finalice la actualización, use `describe-capacity-providers` y verá que `managedDraining` ahora está en estado `ENABLED`.

```
aws ecs describe-capacity-providers --capacity-providers cp-draining
```

Respuesta:

```
{
    "capacityProviders": [
        {
            "capacityProviderArn": "cp-draining-arn",
            "name": "cp-draining",
            "status": "ACTIVE",
            "autoScalingGroupProvider": {
                "autoScalingGroupArn": "asg-draning-arn",
                "managedScaling": {
                    "status": "ENABLED",
                    "targetCapacity": 100,
                    "minimumScalingStepSize": 1,
                    "maximumScalingStepSize": 1,
                    "instanceWarmupPeriod": 300
                },
                "managedTerminationProtection": "DISABLED",
                "managedDraining": "ENABLED" // successfully update
            },
            "updateStatus": "UPDATE_COMPLETE",
            "tags": []
        }
    ]
}
```

## Solución de problemas de drenaje de instancias administradas por Amazon ECS
<a name="managed-instance-troubleshooting"></a>

Es posible que tenga que solucionar problemas relacionados con el drenaje de instancias administradas. A continuación, se incluye un ejemplo de un problema y de una solución que puede encontrar al usarlo.

**Las instancias no se terminan después de superar la vida útil máxima de las instancias cuando se usa el escalado automático.**  
Si sus instancias no se terminan incluso después de alcanzar y superar la vida útil máxima de las instancias mientras usa un grupo de escalado automático, es posible que se deba a que están protegidas contra la reducción horizontal. Puede desactivar la terminación administrada y permitir que el drenaje administrado se encargue del reciclaje de instancias. 

## Comportamiento de vaciado de instancias administradas de Amazon ECS
<a name="managed-instances-draining-behavior"></a>

La terminación de Instancias administradas de Amazon ECS garantiza transiciones de carga de trabajo eficientes y, al mismo tiempo, optimiza los costos y mantiene el sistema en buen estado. El sistema de terminación ofrece tres vías de decisión distintas para la terminación de instancias, cada una con características temporales y perfiles de impacto en los clientes diferentes.

### Rutas de decisión de terminación
<a name="managed-instances-termination-paths"></a>

Terminación iniciada por el cliente  
Proporciona un control directo sobre la eliminación de instancias cuando es necesario eliminar inmediatamente las instancias de contenedor del servicio. Se invoca la API DeregisterContainerInstance con el indicador de fuerza establecido en true, lo que indica que es necesaria la terminación inmediata a pesar de que haya cargas de trabajo en marcha.

Terminación de inactividad iniciada por el sistema  
Instancias administradas de Amazon ECS supervisa de forma continua y optimiza los costos de forma proactiva al terminar las instancias de contenedor de Amazon ECS inactivas que no ejecutan ninguna tarea. ECS utiliza un retraso heurístico para dar a las instancias de contenedor la oportunidad de adquirir las tareas recién lanzadas antes de su terminación. Esto se puede personalizar con el parámetro de configuración del proveedor de capacidad de Instancias administradas de Amazon ECS `scaleInAfter`.

Terminación de actualización de la infraestructura  
Instancias administradas de Amazon ECS administra y actualiza automáticamente el software de las instancias de contenedores administradas para garantizar la seguridad y el cumplimiento y, al mismo tiempo, mantener la disponibilidad de la carga de trabajo mediante un proceso controlado y configurable. Para obtener más información, consulte la [aplicación de revisiones en Instancias administradas de Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/managed-instances-patching.html).

### Migración gradual de cargas de trabajo y vaciado
<a name="managed-instances-draining-coordination"></a>

El sistema de vaciado gradual implementa una coordinación sofisticada con la administración de servicios de Amazon ECS para garantizar que las tareas administradas por el servicio se migren correctamente de las instancias cuya terminación está programada.

**Coordinación del vaciado de las tareas de servicio**  
Cuando una instancia pasa al estado VACIANDO, el programador de Amazon ECS deja de colocar automáticamente nuevas tareas en la instancia y, al mismo tiempo, implementa procedimientos de cierre eficientes para las tareas de servicio existentes. El vaciado de las tareas de servicio incluye la coordinación con las estrategias de implementación del servicio, los requisitos de comprobación de estado y sus preferencias de vaciado para garantizar un tiempo de migración y unos índices de éxito óptimos.

**Administración de tareas independientes**  
Las tareas independientes requieren una gestión diferente porque no se benefician de la administración automática del servicio. El sistema evalúa las características de las tareas independientes, incluidas las estimaciones de la duración de las tareas, el análisis de la probabilidad de finalización y la evaluación del impacto en el cliente. La eficiente estrategia de finalización permite que las tareas independientes se completen de forma natural durante un periodo de gracia prolongado, mientras que la terminación forzada garantiza que la actualización de la infraestructura se lleve a cabo en plazos aceptables cuando las tareas no se hayan completado de forma natural.

### Estrategia de finalización de dos fases
<a name="managed-instances-two-phase-completion"></a>

El sistema de terminación implementa un enfoque de dos fases que equilibra la continuidad de la carga de trabajo con los requisitos de administración de la infraestructura.

**Fase 1: periodo de finalización eficiente**  
Durante esta fase, el sistema implementa estrategias de vaciado gradual que priorizan la continuidad de la carga de trabajo. Las tareas de servicio se vacían gradualmente gracias a los procesos de programación normales de Amazon ECS, las tareas independientes continúan en marcha y pueden completarse de forma natural, y el sistema supervisa que todas las tareas lleguen al estado de parada mediante procesos de finalización natural.

**Fase 2: cumplimiento de plazos estrictos**  
Cuando la finalización eficiente no permite alcanzar los objetivos de terminaci´n dentro de los plazos aceptables, el sistema implementa un estricto cumplimiento de los plazos. Por lo general, el plazo fijo consiste en vaciar el tiempo de iniciación más siete días, lo que proporciona un tiempo considerable para completarlo de forma gradual y, al mismo tiempo, mantener los requisitos operativos. El cumplimiento incluye la invocación automática de los procedimientos de terminación del registro forzoso y la terminación inmediata de todas las tareas pendientes, independientemente del estado en que estén terminadas.

# Creación de recursos para el escalado automático de clústeres de Amazon ECS mediante la Consola de administración de AWS
<a name="tutorial-cluster-auto-scaling-console"></a>

Obtenga información sobre cómo crear los recursos para el escalado automático de clústeres mediante la Consola de administración de AWS. Cuando los recursos requieren un nombre, utilizamos el prefijo `ConsoleTutorial` para asegurarnos de que todos tengan nombres únicos y sean fáciles de localizar.

**Topics**
+ [Requisitos previos](#console-tutorial-prereqs)
+ [Paso 1: Crear un clúster de Amazon ECS](#console-tutorial-cluster)
+ [Paso 2: Registrar una definición de tareas](#console-tutorial-register-task-definition)
+ [Paso 3: Ejecutar una tarea](#console-tutorial-run-task)
+ [Paso 4: Verificar](#console-tutorial-verify)
+ [Paso 5: Eliminar](#console-tutorial-cleanup)

## Requisitos previos
<a name="console-tutorial-prereqs"></a>

En este tutorial se supone que los siguientes requisitos previos se han completado:
+ Se han completado los pasos que se indican en [Configuración para utilizar Amazon ECS](get-set-up-for-amazon-ecs.md).
+ Su usuario de IAM dispone de los permisos requeridos que se especifican en la política de IAM [AmazonECS\$1FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECS_FullAccess) de ejemplo.
+ Se crea el rol de IAM de la instancia de contenedor de Amazon ECS. Para obtener más información, consulte [Rol de IAM de instancia de contenedor de Amazon ECS](instance_IAM_role.md).
+ Se crea el rol de IAM vinculado al servicio de Amazon ECS. Para obtener más información, consulte [Uso de roles vinculados al servicio para Amazon ECS](using-service-linked-roles.md).
+ Se crea el rol de IAM vinculado al servicio de Auto Scaling. Para obtener más información, consulte [Roles vinculados al servicio para Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-service-linked-role.html) en la *Guía del usuario de Amazon EC2 Auto Scaling*.
+ Tiene una VPC y un grupo de seguridad creados para utilizarlos. Para obtener más información, consulte [Creación de una nube virtual privada](get-set-up-for-amazon-ecs.md#create-a-vpc).

## Paso 1: Crear un clúster de Amazon ECS
<a name="console-tutorial-cluster"></a>

Siga estos pasos para crear un clúster de Amazon ECS. 

Amazon ECS crea una plantilla de lanzamiento de Amazon EC2 Auto Scaling y un grupo de Auto Scaling en su nombre como parte de la pila CloudFormation. 

1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. En el panel de navegación, elija **Clústeres** y, a continuación, elija **Crear un clúster**.

1. En **Configuración de clúster**, para **Nombre del clúster**, ingrese `ConsoleTutorial-cluster`.

1. En **Infraestructura**, desactive AWS Fargate (sin servidor) y, a continuación, seleccione **Instancias de Amazon EC2**. A continuación, configure el grupo de escalado automático que actúa como proveedor de capacidad.

   1. En **Grupo de escalado automático (ASG)**. Seleccione **Crear nuevo ASG** y, a continuación, proporcione los siguientes detalles sobre el grupo:
     + En **Sistema operativo/arquitectura**, elija **Amazon Linux 2**.
     + Para **tipo de instancia EC2**, seleccione **t3.nano**.
     + Para **Capacity** (Capacidad), introduzca el número mínimo y el número máximo de instancias que va a lanzar en el grupo de Auto Scaling. 

1. (Opcional) Para administrar las etiquetas de clúster, expanda **Tags** (Etiquetas) y, a continuación, realice una de las siguientes operaciones:

   [Agregar una etiqueta] Elija **Agregar etiqueta** y haga lo siguiente:
   + En **Key (Clave)**, escriba el nombre de la clave.
   + En **Valor**, escriba el valor de la clave.

   [Eliminar una etiqueta] Elija **Eliminar** a la derecha de la clave y el valor de la etiqueta.

1. Seleccione **Create (Crear)**.

## Paso 2: Registrar una definición de tareas
<a name="console-tutorial-register-task-definition"></a>

Antes de poder poner en marcha una tarea en su clúster, debe registrar una definición de tareas. Las definiciones de tareas son listas de contenedores agrupadas. El ejemplo siguiente es una definición de tareas sencilla que utiliza una imagen `amazonlinux` de Docker Hub y se limita a permanecer inactiva. Para obtener más información acerca de los parámetros de definición de tareas disponibles, consulte [Definiciones de tareas de Amazon ECS](task_definitions.md).

1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. En el panel de navegación, elija **Task Definitions** (Definiciones de tareas).

1. Elija **Create new task definition** (Crear nueva definición de tarea) y **Create new task definition with JSON** (Crear nueva definición de tarea con JSON).

1. En el cuadro del **Editor JSON**, copie y pegue el siguiente contenido.

   ```
   {
       "family": "ConsoleTutorial-taskdef",
       "containerDefinitions": [
           {
               "name": "sleep",
               "image": "public.ecr.aws/amazonlinux/amazonlinux:latest",
               "memory": 20,
               "essential": true,
               "command": [
                   "sh",
                   "-c",
                   "sleep infinity"
               ]
           }
       ],
       "requiresCompatibilities": [
           "EC2"
       ]
   }
   ```

1. Seleccione **Crear**.

## Paso 3: Ejecutar una tarea
<a name="console-tutorial-run-task"></a>

Después de registrar una definición de tareas para su cuenta, puede ejecutar una tarea en el clúster. En este tutorial, se ejecutan cinco instancias de la definición de tareas `ConsoleTutorial-taskdef` en el clúster `ConsoleTutorial-cluster`.

1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. En la página **Clústeres**, elija **ConsoleTutorial-cluster**.

1. En **Tareas**, elija **Ejecutar una nueva tarea**.

1. En la sección **Entorno**, en **Opciones de cálculo**, elija **Estrategia de proveedor de capacidad**.

1. En **Configuración de implementación**, en **Tipo de aplicación**, elija **Tarea**.

1.  Seleccione **ConsoleTutorial-taskdef** en la lista desplegable **Familia**.

1. En **Tareas deseadas**, introduzca 5.

1. Seleccione **Crear**.

## Paso 4: Verificar
<a name="console-tutorial-verify"></a>

En este punto del tutorial, debe tener un clúster con cinco tareas en ejecución y un grupo de escalado automático con un proveedor de capacidad. El proveedor de capacidad tiene el escalado administrado por Amazon ECS habilitado.

Para comprobar que todo funcione correctamente, consulte las métricas de CloudWatch, la configuración del grupo de Auto Scaling y, por último, el recuento de tareas del clúster de Amazon ECS.

**Para consultar las métricas de CloudWatch del clúster**

1. Abra la consola de CloudWatch en [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).

1. En la barra de navegación de la parte superior de la pantalla, seleccione la región .

1. En el panel de navegación, en **Métricas**, elija **Todas las métricas**.

1. En la página **Todas las métricas**, en la pestaña **Examinar**, elija `AWS/ECS/ManagedScaling`.

1. Elija **CapacityProviderName, ClusterName**.

1. Seleccione la casilla de verificación correspondiente al `ConsoleTutorial-cluster` **ClusterName**.

1. En la pestaña **Métricas gráficas**, cambie **Período** a **30 segundos** y **Estadística** a **Máximo**.

   El valor que aparece en el gráfico muestra el valor de capacidad de destino del proveedor de capacidad. Debería comenzar en `100`, que es el porcentaje de capacidad de destino que hemos establecido. Debería observar cómo se escala hasta `200`, lo que desencadenará una alarma para la política de escalado de seguimiento de destino. La alarma desencadenará la reducción horizontal del grupo de Auto Scaling.

Siga estos pasos para consultar los detalles del grupo de Auto Scaling y confirmar que se ha producido la acción de escalado horizontal.

**Para comprobar el escalado horizontal del grupo de Auto Scaling**

1. Abra la consola de Amazon EC2 en [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. En la barra de navegación de la parte superior de la pantalla, seleccione la región .

1. En el panel de navegación, seleccione **Auto Scaling** y elija **Auto Scaling Groups (Grupos de Auto Scaling)**.

1. Elija el grupo de escalado automático `ConsoleTutorial-cluster` creado en este tutorial. Consulte el valor en **Capacidad deseada** y consulte las instancias en la pestaña **Administración de instancias** para confirmar que su grupo se ha escalado horizontalmente a dos instancias.

Siga estos pasos para consultar el clúster de Amazon ECS y confirmar que las instancias de Amazon EC2 se hayan registrado en el clúster y las tareas hayan pasado al estado `RUNNING`.

**Para comprobar las instancias del grupo de Auto Scaling**

1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. En el panel de navegación, seleccione **Clusters (Clústeres)**.

1. En la página **Clusters** (Clústeres), elija el clúster `ConsoleTutorial-cluster`.

1. En la pestaña **Tareas**, confirme que observa cinco tareas en el estado `RUNNING`.

## Paso 5: Eliminar
<a name="console-tutorial-cleanup"></a>

Cuando termine este tutorial, debe limpiar los recursos asociados para evitar incurrir en cargos por recursos que no está utilizando. No se admite la eliminación de proveedores de capacidad y definiciones de tareas, pero no hay ningún costo asociado con estos recursos.

**Para borrar los recursos del tutorial, realice el siguiente procedimiento:**

1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. En el panel de navegación, seleccione **Clusters (Clústeres)**.

1. En la página **Clústeres**, elija **ConsoleTutorial-cluster**.

1. En la página **ConsoleTutorial-Cluster**, seleccione la pestaña **Tareas** y, a continuación, seleccione **Detener** y **Detener todo**.

1. En el panel de navegación, seleccione **Clusters (Clústeres)**.

1. En la página **Clústeres**, elija **ConsoleTutorial-cluster**.

1. En la parte superior derecha de la página, seleccione **Eliminar clúster**. 

1. En el cuadro de confirmación, ingrese **delete **ConsoleTutorial-cluster**** y, a continuación, seleccione **Eliminar**.

1. Siga estos pasos para eliminar los grupos de Auto Scaling.

   1. Abra la consola de Amazon EC2 en [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

   1. En la barra de navegación de la parte superior de la pantalla, seleccione la región .

   1. En el panel de navegación, seleccione **Auto Scaling** y elija **Auto Scaling Groups (Grupos de Auto Scaling)**.

   1. Seleccione el grupo de escalado automático de `ConsoleTutorial-cluster` y, a continuación, elija **Acciones**.

   1.  En el menú **Actions (Acciones)**, elija **Delete (Eliminar)**. En el cuadro de confirmación, ingrese **Eliminar** y, a continuación, elija **Eliminar**.

# Instancias de contenedor de Amazon EC2 para Amazon ECS
<a name="create-capacity"></a>

Una instancia de contenedor de Amazon ECS es una instancia de Amazon EC2 que ejecuta el agente de contenedor de Amazon ECS y se ha registrado en un clúster. Cuando se ponen en marcha tareas con Amazon ECS mediante el proveedor de capacidad, el proveedor de capacidad externo o un proveedor de capacidad de grupo de escalado automático, las tareas se colocan en las instancias de contenedor activas. Usted es responsable de la administración y el mantenimiento de las instancias de contenedor.

Aunque puede crear su propia AMI de instancia de Amazon EC2 que cumpla con las especificaciones básicas necesarias para ejecutar las cargas de trabajo en contenedores en Amazon ECS, los ingenieros de AWS preconfiguran y prueban las AMI optimizadas para Amazon ECS en Amazon ECS. Es la forma más sencilla para empezar y para conseguir que los contenedores funcionen en AWS rápidamente.

Al crear un clúster mediante la consola, Amazon ECS crea una plantilla de lanzamiento para las instancias con la AMI más reciente asociada al sistema operativo seleccionado. 

Cuando se utiliza CloudFormation para crear un clúster, el parámetro de SSM forma parte de la plantilla de lanzamiento de Amazon EC2 para las instancias del grupo de escalado automático. Puede configurar la plantilla para que utilice un parámetro dinámico de Systems Manager a fin de determinar qué AMI optimizada de Amazon ECS debe implementar. Este parámetro garantiza que, cada vez que implemente la pila, se compruebe si hay alguna actualización disponible que deba aplicarse a las instancias de EC2. Para ver un ejemplo de cómo utilizar el parámetro de Systems Manager, consulte [Crear un clúster de Amazon ECS con la AMI de Amazon Linux 2023 optimizada para Amazon ECS](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-cluster.html#aws-resource-ecs-cluster--examples--Create_an_cluster_with_the_Amazon_Linux_2023_ECS-Optimized-AMI) en la *Guía del usuario AWS CloudFormation*.
+ [Recuperación de metadatos de las AMI de Linux optimizadas para Amazon ECS](retrieve-ecs-optimized_AMI.md)
+ [Recuperación de metadatos de la AMI de Bottlerocket optimizada para Amazon ECS](ecs-bottlerocket-retrieve-ami.md)
+ [Recuperación de metadatos de las AMI de Windows optimizadas para Amazon ECS](retrieve-ecs-optimized_windows_AMI.md)

Puede elegir entre los tipos de instancias que sean compatibles con su aplicación. Con instancias más grandes, puede lanzar más tareas al mismo tiempo. Con instancias más pequeñas, puede escalar horizontalmente de forma más detallada para ahorrar costos. No necesita elegir un único tipo de instancia de Amazon EC2 que se adapte a todas las aplicaciones del clúster. En su lugar, puede crear varios grupos de escalado automático, donde cada grupo tenga un tipo de instancia diferente. A continuación, puede crear un proveedor de capacidad de Amazon EC2 para cada uno de estos grupos.

Utilice las siguientes directrices para determinar los tipos de familia de instancias y el tipo de instancias que debe utilizar:
+ Elimine los tipos o familias de instancias que no cumplan con los requisitos específicos de su aplicación. Por ejemplo, si tu aplicación requiere una GPU, puede excluir cualquier tipo de instancia que no tenga una GPU.
+ Tenga en cuenta los requisitos, como el almacenamiento y el rendimiento de la red.
+ Tenga en cuenta la CPU y la memoria. Como regla general, la CPU y la memoria deben ser lo suficientemente grandes como para contener, al menos, una réplica de la tarea que quiere ejecutar. 

## Spot Instances
<a name="container-instance-spot"></a>

La capacidad de spot puede proporcionar importantes ahorros de costos en comparación con las instancias bajo demanda. La capacidad de spot es un exceso de capacidad cuyo precio es considerablemente inferior al de la capacidad reservada o bajo demanda. La capacidad de spot es adecuada para cargas de trabajo de procesamiento por lotes y machine learning, así como para entornos de desarrollo y ensayo. En términos más generales, es adecuada para cualquier carga de trabajo que tolere tiempos de inactividad temporales. 

Tenga en cuenta las siguientes consecuencias, ya que es posible que la capacidad de Spot no esté disponible todo el tiempo.
+ Durante los períodos de demanda extremadamente alta, es posible que la capacidad de spot no esté disponible. Esto puede provocar que se retrase el lanzamiento de las instancias de spot de Amazon EC2. En estos casos, los servicios de Amazon ECS vuelven a intentar lanzar las tareas y los grupos de Amazon EC2 Auto Scaling también vuelven a intentar lanzar instancias, hasta que se disponga de la capacidad necesaria. Amazon EC2 no sustituye la capacidad de spot por la capacidad bajo demanda. 
+ Cuando la demanda general de capacidad aumenta, es posible que las instancias y tareas de spot se terminen con solo dos minutos de aviso. Tras enviar la advertencia, las tareas deben iniciar un cierre ordenado, si fuera necesario, antes de que la instancia termine por completo. Esto ayuda a minimizar la posibilidad de errores. Para obtener más información sobre un cierre correcto, consulte [Graceful shutdowns with ECS](https://aws.amazon.com/blogs/containers/graceful-shutdowns-with-ecs/).

Para ayudar a minimizar la escasez de capacidad de spot, tenga en cuenta las siguientes recomendaciones: 
+ Utilice varias regiones y zonas de disponibilidad: la capacidad de spot varía según la región y la zona de disponibilidad. Puede mejorar la disponibilidad de spot ejecutando sus cargas de trabajo en varias regiones y zonas de disponibilidad. Si es posible, especifique subredes en todas las zonas de disponibilidad de las regiones en las que ejecuta sus tareas e instancias. 
+ Utilice varios tipos de instancias de Amazon EC2: cuando utiliza políticas de instancias mixtas con Amazon EC2 Auto Scaling, se lanzan varios tipos de instancias en su grupo de escalado automático. Esto garantiza que se pueda tramitar una solicitud de capacidad de spot cuando sea necesario. Para maximizar la fiabilidad y minimizar la complejidad, utilice tipos de instancias con aproximadamente la misma cantidad de CPU y memoria en la política de instancias mixtas. Estas instancias pueden ser de una generación diferente o ser variantes del mismo tipo de instancia base. Tenga en cuenta que es posible que incluyan características adicionales que no necesite. Un ejemplo de esta lista podría incluir m4.large, m5.large, m5a.large, m5d.large, m5n.large, m5dn.large y m5ad.large. Para obtener más información, consulte la sección sobre [Grupos de escalado automático con varios tipos de instancia y opciones de compra](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-mixed-instances-groups.html) en la *guía del usuario de Amazon EC2 Auto Scaling*.
+ Utilice la estrategia de asignación de spot con capacidad optimizada: con Amazon EC2 Spot, puede elegir entre estrategias de asignación optimizadas en función de la capacidad y de los costos. Si elige la estrategia de capacidad optimizada al lanzar una nueva instancia, Amazon EC2 Spot selecciona el tipo de instancia con mayor disponibilidad en la zona de disponibilidad seleccionada. Esto ayuda a reducir la posibilidad de que la instancia termine poco después de su lanzamiento. 

Para obtener información sobre cómo configurar los avisos de terminación de spot en instancias de contenedor, consulte los siguientes recursos:
+ [Configuración de instancias de contenedor de Linux de Amazon ECS para recibir avisos de instancias de spot](spot-instance-draining-linux-container.md)
+ [Configuración de instancias de contenedor de Windows de Amazon ECS para recibir avisos de instancias de spot](windows-spot-instance-draining-container.md)

# AMI de Linux optimizadas para Amazon ECS
<a name="ecs-optimized_AMI"></a>

**importante**  
La AMI de Amazon Linux 2 optimizada para Amazon ECS finaliza su vida útil el 30 de junio de 2026 y refleja la misma fecha de fin de vida del sistema operativo original Amazon Linux 2 (para más información, consulte las [preguntas frecuentes de Amazon Linux 2](https://aws.amazon.com/amazon-linux-2/faqs/)). Recomendamos a los clientes que actualicen las aplicaciones para utilizar Amazon Linux 2023, que incluye soporte a largo plazo hasta 2028. Para obtener información sobre la migración de Amazon Linux 2 a Amazon Linux 2023, consulte [Migrating from the Amazon Linux 2 Amazon ECS-optimized AMI to the Amazon Linux 2023 Amazon ECS-optimized AMI](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/al2-to-al2023-ami-transition.html).

De forma predeterminada, la fecha de obsolescencia de todas las AMI optimizadas para Amazon ECS se establece en dos años a partir de la fecha de creación de la AMI. Puede utilizar la API `DescribeImages` de Amazon EC2 para comprobar el estado y la fecha de obsolescencia de una AMI. Para obtener más información, consulte [DescribeImages](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeImages.html) en la *Referencia de la API de Amazon Elastic Compute Cloud*.

Amazon ECS proporciona AMI optimizadas para Amazon ECS que están preconfiguradas con estos requisitos y recomendaciones para ejecutar sus cargas de trabajo de contenedor. Le recomendamos que utilice la AMI de Amazon Linux 2023 optimizada para Amazon ECS para las instancias de Amazon EC2. Si lanza las instancias de contenedor desde la AMI optimizada para Amazon ECS más reciente, se asegurará de que reciba las actualizaciones de seguridad y la versión del agente de contenedor actuales. Para obtener más información acerca de cómo lanzar una instancia, consulte [Lanzamiento de una instancia de contenedor de Linux de Amazon ECS](launch_container_instance.md).

Al crear un clúster mediante la consola, Amazon ECS crea una plantilla de lanzamiento para las instancias con la AMI más reciente asociada al sistema operativo seleccionado. 

Cuando se utiliza CloudFormation para crear un clúster, el parámetro de SSM forma parte de la plantilla de lanzamiento de Amazon EC2 para las instancias del grupo de escalado automático. Puede configurar la plantilla para que utilice un parámetro dinámico de Systems Manager a fin de determinar qué AMI optimizada de Amazon ECS debe implementar. Este parámetro garantiza que, cada vez que implemente la pila, se compruebe si hay alguna actualización disponible que deba aplicarse a las instancias de EC2. Para ver un ejemplo de cómo utilizar el parámetro de Systems Manager, consulte [Crear un clúster de Amazon ECS con la AMI de Amazon Linux 2023 optimizada para Amazon ECS](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-cluster.html#aws-resource-ecs-cluster--examples--Create_an_cluster_with_the_Amazon_Linux_2023_ECS-Optimized-AMI) en la *Guía del usuario AWS CloudFormation*.

Si necesita personalizar la AMI optimizada para Amazon ECS, consulte [Amazon ECS Optimized AMI Build Recipies](https://github.com/aws/amazon-ecs-ami) en GitHub.

Están disponibles las siguientes variantes de la AMI optimizada para Amazon ECS para sus instancias de Amazon EC2 con el sistema operativo de Amazon Linux 2023.


| Sistema operativo | AMI | Descripción | Configuración de almacenamiento | 
| --- | --- | --- | --- | 
| Amazon Linux 2023 |  AMI de Amazon Linux 2023 optimizada para Amazon ECS |  Amazon Linux 2023 es la próxima generación de Amazon Linux de AWS. En la mayoría de los casos, se recomienda para lanzar instancias de Amazon EC2 para las cargas de trabajo de Amazon ECS. Para obtener más información, consulte [Qué es Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/what-is-amazon-linux.html) en la *Guía del usuario de Amazon Linux 2023*.  | De forma predeterminada, la AMI de Amazon Linux 2023 optimizada para Amazon ECS se envía con un volumen raíz único de 30 GiB. Puede modificar el tamaño del volumen de raíz de 30 GiB en el momento del lanzamiento para aumentar el almacenamiento disponible en su instancia de contenedor. Este almacenamiento se utiliza para el sistema operativo y para imágenes de Docker y metadatos. El sistema de archivos predeterminado para la AMI de Amazon Linux 2023 optimizada para Amazon ECS es `xfs`, y Docker utiliza el controlador de almacenamiento `overlay2`. Para obtener más información, consulte la sección [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) en la documentación de Docker. | 
| Amazon Linux 2023 (arm64) |  AMI de Amazon Linux 2023 (arm64) optimizada para Amazon ECS |  Basada en Amazon Linux 2023, se recomienda utilizar esta AMI al inicializar las instancias de Amazon EC2, que cuentan con procesadores AWS Graviton/Graviton 2/Graviton 3/Graviton 4 basados en Arm, para las cargas de trabajo de Amazon ECS. Para obtener más información, consulte [Specifications for the Amazon EC2 general purpose instances](https://docs.aws.amazon.com/ec2/latest/instancetypes/gp.html) en la *Guía de tipos de instancias de Amazon EC2*.  | De forma predeterminada, la AMI de Amazon Linux 2023 optimizada para Amazon ECS se envía con un volumen raíz único de 30 GiB. Puede modificar el tamaño del volumen de raíz de 30 GiB en el momento del lanzamiento para aumentar el almacenamiento disponible en su instancia de contenedor. Este almacenamiento se utiliza para el sistema operativo y para imágenes de Docker y metadatos. El sistema de archivos predeterminado para la AMI de Amazon Linux 2023 optimizada para Amazon ECS es `xfs`, y Docker utiliza el controlador de almacenamiento `overlay2`. Para obtener más información, consulte la sección [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) en la documentación de Docker. | 
| Amazon Linux 2023 (Neuron) |  AMI de Amazon Linux 2023 optimizada para Amazon ECS  |  Esta AMI, que se basa en Amazon Linux 2023, es para las instancias Inf1, Trn1 o Inf2 de Amazon EC2. Viene preconfigurada con controladores de AWS Inferentia y AWS Trainium y el tiempo de ejecución de AWS Neuron para Docker, que facilita la puesta en marcha de cargas de trabajo de inferencia de machine learning en Amazon ECS. Para obtener más información, consulte [Definiciones de tareas de Amazon ECS para cargas de trabajo de machine learning de AWS Neuron](ecs-inference.md).  La AMI de Amazon Linux 2023 (Neuron) optimizada para Amazon ECS no incluye la AWS CLI preinstalada.  | De forma predeterminada, la AMI de Amazon Linux 2023 optimizada para Amazon ECS se envía con un volumen raíz único de 30 GiB. Puede modificar el tamaño del volumen de raíz de 30 GiB en el momento del lanzamiento para aumentar el almacenamiento disponible en su instancia de contenedor. Este almacenamiento se utiliza para el sistema operativo y para imágenes de Docker y metadatos. El sistema de archivos predeterminado para la AMI de Amazon Linux 2023 optimizada para Amazon ECS es `xfs`, y Docker utiliza el controlador de almacenamiento `overlay2`. Para obtener más información, consulte la sección [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) en la documentación de Docker. | 
| GPU de Amazon Linux 2023 | AMI de GPU de Amazon Linux 2023 optimizada para Amazon ECS |  Se recomienda utilizar esta AMI basada en Amazon Linux 2023 al inicializar las instancias basadas en GPU de Amazon EC2 para las cargas de trabajo de Amazon ECS. Viene preconfigurada con controladores de kernel de NVIDIA y un tiempo de ejecución de GPU de Docker que permite poner en marcha cargas de trabajo que aprovechan las GPU de Amazon ECS. Para obtener más información, consulte [Definiciones de tareas de Amazon ECS para cargas de trabajo de GPU](ecs-gpu.md).  | De forma predeterminada, la AMI de Amazon Linux 2023 optimizada para Amazon ECS se envía con un volumen raíz único de 30 GiB. Puede modificar el tamaño del volumen de raíz de 30 GiB en el momento del lanzamiento para aumentar el almacenamiento disponible en su instancia de contenedor. Este almacenamiento se utiliza para el sistema operativo y para imágenes de Docker y metadatos. El sistema de archivos predeterminado para la AMI de Amazon Linux 2023 optimizada para Amazon ECS es `xfs`, y Docker utiliza el controlador de almacenamiento `overlay2`. Para obtener más información, consulte la sección [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) en la documentación de Docker. | 

Las siguientes son las variantes de la AMI optimizada para Amazon ECS que están disponibles para sus instancias de Amazon EC2 con el sistema operativo de Amazon Linux 2.


| Sistema operativo | AMI | Descripción | Configuración de almacenamiento | 
| --- | --- | --- | --- | 
|  **Amazon Linux 2**   |  AMI de Amazon Linux 2 con kernel 5.10 optimizada para Amazon ECS | Se debe utilizar esta AMI basada en Amazon Linux 2 cuando lanza las instancias de Amazon EC2 y desea usar Linux con kernel 5.10 en lugar de kernel 4.14 para las cargas de trabajo de Amazon ECS. La AMI de Amazon Linux 2 con kernel 5.10 optimizada para Amazon ECS no incluye la AWS CLI preinstalada. | De forma predeterminada, las AMI basadas en Amazon Linux 2 optimizadas para Amazon ECS (AMI de Amazon Linux 2 optimizada para Amazon ECS, AMI de Amazon Linux 2 (arm64) optimizada para Amazon ECS y AMI optimizada para GPU de Amazon ECS) se envían con un único volumen raíz de 30 GiB. Puede modificar el tamaño del volumen de raíz de 30 GiB en el momento del lanzamiento para aumentar el almacenamiento disponible en su instancia de contenedor. Este almacenamiento se utiliza para el sistema operativo y para imágenes de Docker y metadatos. El sistema de archivos predeterminado para la AMI de Amazon Linux 2 optimizada para Amazon ECS es`xfs`, y Docker utiliza el controlador de almacenamiento `overlay2`. Para obtener más información, consulte la sección [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) en la documentación de Docker. | 
|  **Amazon Linux 2**  |  AMI de Amazon Linux 2 optimizada para Amazon ECS | Se trata de las cargas de trabajo de Amazon ECS. La AMI de Amazon Linux 2 optimizada para Amazon ECS no incluye la AWS CLI preinstalada. | De forma predeterminada, las AMI basadas en Amazon Linux 2 optimizadas para Amazon ECS (AMI de Amazon Linux 2 optimizada para Amazon ECS, AMI de Amazon Linux 2 (arm64) optimizada para Amazon ECS y AMI optimizada para GPU de Amazon ECS) se envían con un único volumen raíz de 30 GiB. Puede modificar el tamaño del volumen de raíz de 30 GiB en el momento del lanzamiento para aumentar el almacenamiento disponible en su instancia de contenedor. Este almacenamiento se utiliza para el sistema operativo y para imágenes de Docker y metadatos. El sistema de archivos predeterminado para la AMI de Amazon Linux 2 optimizada para Amazon ECS es`xfs`, y Docker utiliza el controlador de almacenamiento `overlay2`. Para obtener más información, consulte la sección [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) en la documentación de Docker. | 
|  **Amazon Linux 2 (arm64)**  |  AMI de Amazon Linux 2 con kernel 5.10 (arm64) optimizada para Amazon ECS |  Basada en Amazon Linux 2, esta AMI se usa para las instancias de Amazon EC2, que cuentan con procesadores AWS Graviton/Graviton 2/Graviton 3/Graviton 4 basados en Arm, y se recomienda usar Linux con kernel 5.10 en lugar de Linux con kernel 4.14 para las cargas de trabajo de Amazon ECS. Para obtener más información, consulte [Specifications for Amazon EC2 general purpose instances](https://docs.aws.amazon.com/ec2/latest/instancetypes/gp.html) en la *Guía de tipos de instancias de Amazon EC2*. La AMI de Amazon Linux 2 (arm64) optimizada para Amazon ECS no incluye la AWS CLI preinstalada.  | De forma predeterminada, las AMI basadas en Amazon Linux 2 optimizadas para Amazon ECS (AMI de Amazon Linux 2 optimizada para Amazon ECS, AMI de Amazon Linux 2 (arm64) optimizada para Amazon ECS y AMI optimizada para GPU de Amazon ECS) se envían con un único volumen raíz de 30 GiB. Puede modificar el tamaño del volumen de raíz de 30 GiB en el momento del lanzamiento para aumentar el almacenamiento disponible en su instancia de contenedor. Este almacenamiento se utiliza para el sistema operativo y para imágenes de Docker y metadatos. El sistema de archivos predeterminado para la AMI de Amazon Linux 2 optimizada para Amazon ECS es`xfs`, y Docker utiliza el controlador de almacenamiento `overlay2`. Para obtener más información, consulte la sección [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) en la documentación de Docker. | 
| Amazon Linux 2 (arm64) | AMI de Amazon Linux 2 (arm64) optimizada para Amazon ECS |  Basada en Amazon Linux 2, esta AMI se usa cuando se lanzan las instancias de Amazon EC2, que cuentan con procesadores AWS Graviton/Graviton 2/Graviton 3/Graviton 4 basados en Arm, para las cargas de trabajo de Amazon ECS. La AMI de Amazon Linux 2 (arm64) optimizada para Amazon ECS no incluye la AWS CLI preinstalada.  | De forma predeterminada, las AMI basadas en Amazon Linux 2 optimizadas para Amazon ECS (AMI de Amazon Linux 2 optimizada para Amazon ECS, AMI de Amazon Linux 2 (arm64) optimizada para Amazon ECS y AMI optimizada para GPU de Amazon ECS) se envían con un único volumen raíz de 30 GiB. Puede modificar el tamaño del volumen de raíz de 30 GiB en el momento del lanzamiento para aumentar el almacenamiento disponible en su instancia de contenedor. Este almacenamiento se utiliza para el sistema operativo y para imágenes de Docker y metadatos. El sistema de archivos predeterminado para la AMI de Amazon Linux 2 optimizada para Amazon ECS es`xfs`, y Docker utiliza el controlador de almacenamiento `overlay2`. Para obtener más información, consulte la sección [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) en la documentación de Docker. | 
|  **Amazon Linux 2 (GPU)**  | AMI de kernel 5.10 optimizada para GPU de Amazon ECS | Basada en Amazon Linux 2, se recomienda utilizar esta AMI cuando inicia las instancias basadas en GPU de Amazon EC2 con el kernel 5.10 de Linux para las cargas de trabajo de Amazon ECS. Viene preconfigurada con controladores de kernel de NVIDIA y un tiempo de ejecución de GPU de Docker que permite poner en marcha cargas de trabajo que aprovechan las GPU de Amazon ECS. Para obtener más información, consulte [Definiciones de tareas de Amazon ECS para cargas de trabajo de GPU](ecs-gpu.md). | De forma predeterminada, las AMI basadas en Amazon Linux 2 optimizadas para Amazon ECS (AMI de Amazon Linux 2 optimizada para Amazon ECS, AMI de Amazon Linux 2 (arm64) optimizada para Amazon ECS y AMI optimizada para GPU de Amazon ECS) se envían con un único volumen raíz de 30 GiB. Puede modificar el tamaño del volumen de raíz de 30 GiB en el momento del lanzamiento para aumentar el almacenamiento disponible en su instancia de contenedor. Este almacenamiento se utiliza para el sistema operativo y para imágenes de Docker y metadatos. El sistema de archivos predeterminado para la AMI de Amazon Linux 2 optimizada para Amazon ECS es`xfs`, y Docker utiliza el controlador de almacenamiento `overlay2`. Para obtener más información, consulte la sección [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) en la documentación de Docker. | 
| Amazon Linux 2 (GPU) | AMI optimizada para GPU de Amazon ECS | Basada en Amazon Linux 2, se recomienda utilizar esta AMI cuando inicia las instancias basadas en GPU de Amazon EC2 con el kernel 4.14 de Linux para las cargas de trabajo de Amazon ECS. Viene preconfigurada con controladores de kernel de NVIDIA y un tiempo de ejecución de GPU de Docker que permite poner en marcha cargas de trabajo que aprovechan las GPU de Amazon ECS. Para obtener más información, consulte [Definiciones de tareas de Amazon ECS para cargas de trabajo de GPU](ecs-gpu.md). | De forma predeterminada, las AMI basadas en Amazon Linux 2 optimizadas para Amazon ECS (AMI de Amazon Linux 2 optimizada para Amazon ECS, AMI de Amazon Linux 2 (arm64) optimizada para Amazon ECS y AMI optimizada para GPU de Amazon ECS) se envían con un único volumen raíz de 30 GiB. Puede modificar el tamaño del volumen de raíz de 30 GiB en el momento del lanzamiento para aumentar el almacenamiento disponible en su instancia de contenedor. Este almacenamiento se utiliza para el sistema operativo y para imágenes de Docker y metadatos. El sistema de archivos predeterminado para la AMI de Amazon Linux 2 optimizada para Amazon ECS es`xfs`, y Docker utiliza el controlador de almacenamiento `overlay2`. Para obtener más información, consulte la sección [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) en la documentación de Docker. | 
| Amazon Linux 2 (Neuron)  | AMI de kernel 5.10 de Amazon Linux 2 (Neuron) optimizada para Amazon ECS  | Esta AMI basada en Amazon Linux 2 es para las instancias Inf1, Trn1 o Inf2 de Amazon EC2. Viene preconfigurada con controladores de AWS Inferentia con kernel 5.10 de Linux y AWS Trainium y el tiempo de ejecución de AWS Neuron para Docker, que facilita la ejecución de cargas de trabajo de inferencia de machine learning en Amazon ECS. Para obtener más información, consulte [Definiciones de tareas de Amazon ECS para cargas de trabajo de machine learning de AWS Neuron](ecs-inference.md). La AMI de Amazon Linux 2 (Neuron) optimizada para Amazon ECS no incluye la AWS CLI preinstalada. | De forma predeterminada, las AMI basadas en Amazon Linux 2 optimizadas para Amazon ECS (AMI de Amazon Linux 2 optimizada para Amazon ECS, AMI de Amazon Linux 2 (arm64) optimizada para Amazon ECS y AMI optimizada para GPU de Amazon ECS) se envían con un único volumen raíz de 30 GiB. Puede modificar el tamaño del volumen de raíz de 30 GiB en el momento del lanzamiento para aumentar el almacenamiento disponible en su instancia de contenedor. Este almacenamiento se utiliza para el sistema operativo y para imágenes de Docker y metadatos. El sistema de archivos predeterminado para la AMI de Amazon Linux 2 optimizada para Amazon ECS es`xfs`, y Docker utiliza el controlador de almacenamiento `overlay2`. Para obtener más información, consulte la sección [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) en la documentación de Docker. | 
| Amazon Linux 2 (Neuron)  | AMI de Amazon Linux 2 (Neuron) optimizada para Amazon ECS | Esta AMI basada en Amazon Linux 2 es para las instancias Inf1, Trn1 o Inf2 de Amazon EC2. Viene preconfigurada con controladores de AWS Inferentia y AWS Trainium y el tiempo de ejecución de AWS Neuron para Docker, que facilita la puesta en marcha de cargas de trabajo de inferencia de machine learning en Amazon ECS. Para obtener más información, consulte [Definiciones de tareas de Amazon ECS para cargas de trabajo de machine learning de AWS Neuron](ecs-inference.md). La AMI de Amazon Linux 2 (Neuron) optimizada para Amazon ECS no incluye la AWS CLI preinstalada. | De forma predeterminada, las AMI basadas en Amazon Linux 2 optimizadas para Amazon ECS (AMI de Amazon Linux 2 optimizada para Amazon ECS, AMI de Amazon Linux 2 (arm64) optimizada para Amazon ECS y AMI optimizada para GPU de Amazon ECS) se envían con un único volumen raíz de 30 GiB. Puede modificar el tamaño del volumen de raíz de 30 GiB en el momento del lanzamiento para aumentar el almacenamiento disponible en su instancia de contenedor. Este almacenamiento se utiliza para el sistema operativo y para imágenes de Docker y metadatos. El sistema de archivos predeterminado para la AMI de Amazon Linux 2 optimizada para Amazon ECS es`xfs`, y Docker utiliza el controlador de almacenamiento `overlay2`. Para obtener más información, consulte la sección [Use the OverlayFS storage driver](https://docs.docker.com/engine/storage/drivers/overlayfs-driver/) en la documentación de Docker. | 

Amazon ECS proporciona un registro de cambios para la variante Linux de la AMI optimizada para Amazon ECS en GitHub. Para obtener más información, consulte [Changelog](https://github.com/aws/amazon-ecs-ami/blob/main/CHANGELOG.md) (Registro de cambios).

Las variantes de Linux de la AMI optimizada para Amazon ECS utilizan la AMI de Amazon Linux 2 o la AMI de Linux 2023 como base. Puede recuperar el nombre de la AMI para cada variante consultando la API del Almacén de parámetros de Systems Manager. Para obtener más información, consulte [Recuperación de metadatos de las AMI de Linux optimizadas para Amazon ECS](retrieve-ecs-optimized_AMI.md). También están disponibles las notas de la versión de la AMI de Amazon Linux 2. Para obtener más información, consulte las [notas de la versión de Amazon Linux 2](https://docs.aws.amazon.com/AL2/latest/relnotes/relnotes-al2.html). También están disponibles las notas de la versión de Amazon Linux 2023. Para obtener más información, consulte las [notas de la versión de Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/release-notes/relnotes.html).

En las páginas siguientes se proporciona información adicional acerca de los cambios:
+ Notas de la [versión de la AMI de origen](https://github.com/aws/amazon-ecs-ami/releases) en GitHub
+ [Notas de la versión de Docker Engine](https://docs.docker.com/engine/release-notes/) en la documentación de Docker
+ [Documentación de controlador NVIDIA](https://docs.nvidia.com/datacenter/tesla/index.html) en la documentación de NVIDIA
+ [Registro de cambios del agente de Amazon ECS](https://github.com/aws/amazon-ecs-agent/blob/master/CHANGELOG.md) en GitHub

  El código de origen de la aplicación `ecs-init` y los scripts y la configuración para empaquetar el agente ahora forman parte del repositorio de agentes. Para ver versiones anteriores de `ecs-init` y paquetes, consulte el [registro de cambios de Amazon ecs-init](https://github.com/aws/amazon-ecs-init/blob/master/CHANGELOG.md) en GitHub.

## Aplicación de actualizaciones de seguridad a la AMI optimizada para Amazon ECS
<a name="ecs-optimized-AMI-security-changes"></a>

Las AMI optimizadas para Amazon ECS basadas en Amazon Linux contienen una versión personalizada de cloud-init. Cloud-init es un paquete que se utiliza para arrancar imágenes de Linux en un entorno de computación en la nube y llevar a cabo las acciones deseadas al iniciar una instancia. De manera predeterminada, todas las AMI optimizadas para Amazon ECS basadas en Amazon Linux publicadas antes del 12 de junio de 2024 tienen todas las actualizaciones de seguridad “críticas” e “importantes” aplicadas al lanzar la instancia.

A partir de las versiones del 12 de junio de 2024 de las AMI optimizadas para Amazon ECS basadas en Amazon Linux 2, el comportamiento predeterminado ya no incluirá la actualización de paquetes en el momento del lanzamiento. En su lugar, le recomendamos que actualice a una nueva AMI optimizada para Amazon ECS a medida que haya versiones disponibles. Las AMI optimizadas para Amazon ECS se publican cuando hay actualizaciones de seguridad disponibles o cambios en la AMI base. Esto garantizará que reciba las últimas versiones del paquete y las actualizaciones de seguridad más recientes y que las versiones del paquete sean inmutables durante el inicio de las instancias. Para obtener más información acerca de cómo recuperar las AMI optimizadas para Amazon ECS más recientes, consulte [Recuperación de metadatos de las AMI de Linux optimizadas para Amazon ECS](retrieve-ecs-optimized_AMI.md).

Recomendamos automatizar el entorno para actualizarlo a una nueva AMI a medida que estén disponibles. Para obtener información sobre las opciones disponibles, consulte [Amazon ECS enables easier EC2 capacity management, with managed instance draining](https://aws.amazon.com/blogs/containers/amazon-ecs-enables-easier-ec2-capacity-management-with-managed-instance-draining/).

Para seguir aplicando manualmente las actualizaciones de seguridad “críticas” e “importantes” en una versión de la AMI, puede ejecutar el siguiente comando en su instancia de Amazon EC2.

```
yum update --security
```

**aviso**  
 La actualización de los paquetes de Docker o containerd detendrá todos los contenedores en ejecución en el host, lo que significa que se detendrán todas las tareas de Amazon ECS en ejecución. Planifique en consecuencia para minimizar las interrupciones del servicio. 

Si desea volver a habilitar las actualizaciones de seguridad en el momento del inicio, puede agregar la siguiente línea a la sección `#cloud-config` de datos de usuario de cloud-init al iniciar la instancia de Amazon EC2. Para obtener más información, consulte [Uso de cloud-init en Amazon Linux 2](https://docs.aws.amazon.com/linux/al2/ug/amazon-linux-cloud-init.html) en la *Guía del usuario de Amazon Linux*.

```
#cloud-config
repo_upgrade: security
```

## Paquetes con versiones bloqueadas en AMI de AL2023 optimizadas para Amazon ECS con GPU
<a name="ecs-optimized-ami-version-locked-packages"></a>

Algunos paquetes son fundamentales para un comportamiento correcto y eficiente de la funcionalidad de la GPU en las AMI de AL2023 optimizadas para Amazon ECS con GPU. Entre ellos se incluyen:
+ Controladores NVIDIA (`nvidia*`)
+ Módulos de kernel (`kmod*`)
+ Bibliotecas NVIDIA (`libnvidia*`)
+ Paquetes de kernel (`kernel*`)

**nota**  
No es una lista exhaustiva. La lista completa de paquetes bloqueados está disponible mediante `dnf versionlock list`

Estos paquetes tienen versiones bloqueadas para garantizar la estabilidad y evitar cambios involuntarios que podrían interrumpir las cargas de trabajo de la GPU. Por lo tanto, estos paquetes deben modificarse dentro de los límites de un proceso gestionado que maneje correctamente los posibles problemas y mantenga la funcionalidad de la GPU.

Para evitar modificaciones no deseadas, se utiliza el complemento `dnf versionlock` en estos paquetes.

Si desea modificar un paquete bloqueado, puede hacer lo siguiente:

```
# unlock a single package
sudo dnf versionlock delete $PACKAGE_NAME

# unlock all packages
sudo dnf versionlock clear
```

**importante**  
Cuando sea necesario actualizar estos paquetes, los clientes deberían considerar la posibilidad de utilizar la última versión de la AMI que incluya las actualizaciones necesarias. Si es necesario actualizar las instancias existentes, se debe emplear un enfoque cuidadoso que implique desbloquear, actualizar y volver a bloquear los paquetes, para garantizar siempre que la funcionalidad de la GPU se mantenga durante todo el proceso.

# Recuperación de metadatos de las AMI de Linux optimizadas para Amazon ECS
<a name="retrieve-ecs-optimized_AMI"></a>

Puede recuperar mediante programación los metadatos de la AMI optimizada para Amazon ECS. Los metadatos incluyen el nombre de la AMI, la versión del agente de contenedor de Amazon ECS y la versión del tiempo de ejecución de ECS que incluye la versión de Docker. 

Al crear un clúster mediante la consola, Amazon ECS crea una plantilla de lanzamiento para las instancias con la AMI más reciente asociada al sistema operativo seleccionado. 

Cuando se utiliza CloudFormation para crear un clúster, el parámetro de SSM forma parte de la plantilla de lanzamiento de Amazon EC2 para las instancias del grupo de escalado automático. Puede configurar la plantilla para que utilice un parámetro dinámico de Systems Manager a fin de determinar qué AMI optimizada de Amazon ECS debe implementar. Este parámetro garantiza que, cada vez que implemente la pila, se compruebe si hay alguna actualización disponible que deba aplicarse a las instancias de EC2. Para ver un ejemplo de cómo utilizar el parámetro de Systems Manager, consulte [Crear un clúster de Amazon ECS con la AMI de Amazon Linux 2023 optimizada para Amazon ECS](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-cluster.html#aws-resource-ecs-cluster--examples--Create_an_cluster_with_the_Amazon_Linux_2023_ECS-Optimized-AMI) en la *Guía del usuario AWS CloudFormation*.

Para recuperar el ID de la AMI, el nombre de la imagen, el sistema operativo, la versión del agente de contenedor, el nombre de la imagen de origen y la versión del tiempo de ejecución de las AMI optimizada para Amazon ECS mediante programación, consulte la API del Parameter Store de Systems Manager. Para obtener más información acerca de la API del Parameter Store de Systems Manager, consulte [GetParameters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameters.html) y [GetParametersByPath](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParametersByPath.html).

**nota**  
La cuenta administrativa debe tener los siguientes permisos de IAM para recuperar los metadatos de la AMI optimizada para Amazon ECS. Estos permisos se agregaron a la política de IAM `AmazonECS_FullAccess`.  
ssm:GetParameters
ssm:GetParameter
ssm:GetParametersByPath

## Formato de los parámetros de Parameter Store de Systems Manager
<a name="ecs-optimized-ami-parameter-format"></a>

A continuación, se muestra el formato del nombre del parámetro para cada variante de AMI optimizada para Amazon ECS.

**AMI de Linux optimizadas para Amazon ECS**
+ Metadatos de AMI de Amazon Linux 2023:

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2023/<version>
  ```
+ Metadatos de AMI de Amazon Linux 2023 (arm64):

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2023/arm64/<version>
  ```
+ Metadatos de AMI de Amazon Linux 2023 (Neuron):

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2023/neuron/<version>
  ```
+ Metadatos de AMI de Amazon Linux 2023 (GPU):

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2023/gpu/<version>
  ```

  Metadatos de AMI de Amazon Linux 2:

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2/<version>
  ```
+ Metadatos de AMI de Amazon Linux 2 con kernel 5.10:

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/<version>
  ```
+ Metadatos de AMI de Amazon Linux 2 (arm64):

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2/arm64/<version>
  ```
+ Metadatos de AMI de Amazon Linux 2 con kernel 5.10 (arm64):

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/arm64/<version>
  ```
+ Metadatos de la AMI de kernel 5.10 optimizada para GPU de Amazon ECS:

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/gpu/<version>
  ```
+ Metadatos de AMI de Amazon Linux 2 (GPU):

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/<version>
  ```
+ Metadatos de la AMI de kernel 5.10 de Amazon Linux 2 (Neuron) optimizada para Amazon ECS:

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/inf/<version>
  ```
+ Metadatos de AMI de Amazon Linux 2 (Neuron):

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2/inf/<version>
  ```

El siguiente formato de nombre de parámetro recupera el ID de imagen de la última versión recomendada de la AMI de Amazon Linux 2 optimizada para Amazon ECS mediante el parámetro secundario `image_id`.

```
/aws/service/ecs/optimized-ami/amazon-linux-2/recommended/image_id
```

El siguiente formato de nombre de parámetro recupera los metadatos de una versión específica de la AMI optimizada para Amazon ECS mediante la especificación del nombre de la AMI.
+ Metadatos de AMI de Amazon Linux 2 optimizada para Amazon ECS:

  ```
  /aws/service/ecs/optimized-ami/amazon-linux-2/amzn2-ami-ecs-hvm-2.0.20181112-x86_64-ebs
  ```

**nota**  
Todas las versiones de AMI Amazon Linux 2 optimizadas para Amazon ECS están disponibles para su recuperación. Solo se pueden recuperar las versiones `amzn-ami-2017.09.l-amazon-ecs-optimized` de AMI (Linux) optimizadas para Amazon ECS y versiones posteriores. 

## Ejemplos
<a name="ecs-optimized-ami-parameter-examples"></a>

Los siguientes ejemplos muestran formas en las que pueden recuperar los metadatos de cada variante de AMI optimizada para Amazon ECS.

### Recuperación de los metadatos de la última versión recomendada de la AMI optimizada para Amazon ECS
<a name="ecs-optimized-ami-parameter-examples-1"></a>

Utilice los siguientes comandos de la AWS CLI para recuperar la última versión recomendada de la AMI optimizada para Amazon ECS mediante la AWS CLI.

**AMI de Linux optimizadas para Amazon ECS**
+ **Para las AMI de Amazon Linux 2023 optimizadas para Amazon ECS:**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/recommended --region us-east-1
  ```
+ **Para las AMI de Amazon Linux 2023 (arm64) optimizadas para Amazon ECS:**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/arm64/recommended --region us-east-1
  ```
+ **Para las AMI de Amazon Linux 2023 (Neuron) optimizadas para Amazon ECS:**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/neuron/recommended --region us-east-1
  ```
+ **Para las AMI de Amazon Linux 2023 optimizadas para Amazon ECS:**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/gpu/recommended --region us-east-1
  ```
+ **Para las AMI de Amazon Linux 2 con kernel 5.10 optimizadas para Amazon ECS:**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/recommended --region us-east-1
  ```
+ **Para las AMI de Amazon Linux 2 optimizadas para Amazon ECS:**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/recommended --region us-east-1
  ```
+ **Para las AMI de Amazon Linux 2 con kernel 5.10 (arm64) optimizadas para Amazon ECS:**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/arm64/recommended --region us-east-1
  ```
+ **Para las AMI de Amazon Linux 2 (arm64) optimizadas para Amazon ECS:**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/arm64/recommended --region us-east-1
  ```
+ **Para las AMI de kernel 5.10 optimizadas para GPU de Amazon ECS:**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/gpu/recommended --region us-east-1
  ```
+ **Para las AMI optimizadas para GPU de Amazon ECS:**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/gpu/recommended --region us-east-1
  ```
+ **Para las AMI de kernel 5.10 de Amazon Linux 2 (Neuron) optimizadas para Amazon ECS:**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/inf/recommended --region us-east-1
  ```
+ **Para las AMI de Amazon Linux 2 (Neuron) optimizadas para Amazon ECS:**

  ```
  aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/inf/recommended --region us-east-1
  ```

### Recuperación del ID de imagen de la AMI de Amazon Linux 2023 optimizada para Amazon ECS más reciente recomendada
<a name="ecs-optimized-ami-parameter-examples-6"></a>

Puede recuperar el ID de imagen del ID de la AMI de Amazon Linux 2023 optimizada para Amazon ECS más reciente recomendada mediante el parámetro secundario `image_id`.

```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/recommended/image_id --region us-east-1
```

Para recuperar solo el valor de `image_id`, puede consultar el valor de parámetro específico; por ejemplo:

```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2023/recommended/image_id --region us-east-1 --query "Parameters[0].Value"
```

### Recuperación de los metadatos de una versión específica de AMI de Amazon Linux 2 optimizada para Amazon ECS
<a name="ecs-optimized-ami-parameter-examples-2"></a>

Utilice el siguiente comando de la AWS CLI para recuperar los metadatos de una versión específica de AMI de Amazon Linux optimizada para Amazon ECS mediante la AWS CLI. Sustituya el nombre de la AMI por el nombre de la AMI de Amazon Linux optimizada para Amazon ECS que va a recuperar. 

```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/amzn2-ami-ecs-hvm-2.0.20200928-x86_64-ebs --region us-east-1
```

### Recuperación de los metadatos de la AMI de kernel 5.10 de Amazon Linux 2 optimizada para Amazon ECS mediante la API GetParametersByPath de Systems Manager
<a name="ecs-optimized-ami-parameter-examples-3"></a>

Utilice el siguiente comando de la AWS CLI para recuperar los metadatos de la AMI de Amazon Linux 2 optimizada para Amazon ECS mediante la API GetParametersByPath de Systems Manager.

```
aws ssm get-parameters-by-path --path /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/ --region us-east-1
```

### Recuperación del ID de imagen de la AMI de kernel 5.10 de Amazon Linux 2 optimizada para Amazon ECS más reciente recomendada
<a name="ecs-optimized-ami-parameter-examples-4"></a>

Puede recuperar el ID de imagen del ID de la AMI de kernel 5.10 de Amazon Linux 2 optimizada para Amazon ECS más reciente recomendada mediante el parámetro secundario `image_id`.

```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/recommended/image_id --region us-east-1
```

Para recuperar solo el valor de `image_id`, puede consultar el valor de parámetro específico; por ejemplo:

```
aws ssm get-parameters --names /aws/service/ecs/optimized-ami/amazon-linux-2/recommended/image_id --region us-east-1 --query "Parameters[0].Value"
```

### Utilización de la AMI optimizada para Amazon ECS más reciente recomendada en una plantilla de CloudFormation
<a name="ecs-optimized-ami-parameter-examples-5"></a>

Para hacer referencia a la AMI optimizada para Amazon ECS recomendada en una plantilla de CloudFormation, pude hacer referencia al nombre del almacén de parámetros de Systems Manager.

**Ejemplo de Linux**

```
Parameters:kernel-5.10
  LatestECSOptimizedAMI:
    Description: AMI ID
    Type: AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>
    Default: /aws/service/ecs/optimized-ami/amazon-linux-2/kernel-5.10/recommended/image_id
```

# Migración de una AMI de Amazon Linux 2 a una AMI de Amazon Linux 2023 optimizada para Amazon ECS
<a name="al2-to-al2023-ami-transition"></a>

Después de [Amazon Linux](https://aws.amazon.com/amazon-linux-2/faqs), Amazon ECS finaliza el soporte estándar para las AMI optimizadas para Amazon ECS de Amazon Linux 2 a partir del 30 de junio de 2026. Después de esta fecha, la versión del agente de Amazon ECS queda anclada y las nuevas AMI optimizadas para Amazon ECS de Amazon Linux 2 solo se publicarán cuando se actualice la AMI de Amazon Linux 2 de origen. El fin del ciclo de vida completo (EOL) se produce el 30 de junio de 2026, tras lo cual no se publicarán más AMI de Amazon Linux 2 optimizadas para Amazon ECS, aunque se actualice la AMI de origen.

Amazon Linux 2023 ofrece un enfoque de seguridad desde el diseño con políticas de seguridad previamente configuradas, SELinux en modo permisivo, modo exclusivo de IMDSv2 habilitado de manera predeterminada, tiempos de arranque optimizados y administración de paquetes mejorada para aumentar la seguridad y el rendimiento.

Existe un alto grado de compatibilidad entre las AMI optimizadas para Amazon ECS de Amazon Linux 2 y Amazon Linux 2023, y la mayoría de los clientes verán cambios mínimos o nulos en las cargas de trabajo entre los dos sistemas operativos.

Para más información, consulte [Comparing Amazon Linux 2 and *Amazon Linux 2023*](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html) en la *Guía del usuario de Amazon Linux 2023* y las [Preguntas frecuentes sobre Amazon Linux 2023](https://aws.amazon.com/linux/amazon-linux-2023/faqs).

## Consideraciones sobre compatibilidad
<a name="al2-to-al2023-ami-transition-compatibility"></a>

### Administración de paquetes y actualizaciones del sistema operativo
<a name="al2-to-al2023-ami-transition-compatibility-package-management"></a>

A diferencia de las versiones anteriores de Amazon Linux, las AMI de Amazon Linux 2023 optimizadas para Amazon ECS están bloqueadas en una versión específica del repositorio de Amazon Linux. Esto evita que los usuarios actualicen los paquetes de manera inadvertida, lo que podría provocar cambios no deseados o perjudiciales. Para más información, consulte [Managing repositories and OS updates in Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/managing-repos-os-updates.html) en la *Guía del usuario de Amazon Linux 2023*.

### Versiones del kernel de Linux
<a name="al2-to-al2023-ami-transition-compatibility-kernel"></a>

Las AMI de Amazon Linux 2 se basan en los kerneles de Linux 4.14 y 5.10, mientras que Amazon Linux 2023 utiliza los kerneles 6.1 y 6.12 de Linux. Para más información, consulte [Comparing Amazon Linux 2 and Amazon Linux 2023 kernels](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2-kernel.html) en la *Guía del usuario de Amazon Linux 2023*.

### Cambios en la disponibilidad de los paquetes
<a name="al2-to-al2023-ami-transition-compatibility-packages"></a>

Los siguientes son cambios notables en los paquetes de Amazon Linux 2023:
+ Algunos paquetes binarios de origen disponibles en Amazon Linux 2 ya no lo están en Amazon Linux 2023. Para más información, consulte [Packages removed from Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/release-notes/removed.html) en las *Notas de la versión de Amazon Linux 2023*.
+ Cambios en la forma en que Amazon Linux admite las distintas versiones de paquetes. El sistema `amazon-linux-extras` que se utiliza en Amazon Linux 2 no existe en Amazon Linux 2023. Todos los paquetes simplemente están disponibles en el repositorio “principal”.
+ Los paquetes adicionales para Enterprise Linux (EPEL) no son compatibles con Amazon Linux 2023. Para más información, consulte [EPEL compatibility in Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/epel.html) en la *Guía del usuario de Amazon Linux 2023*.
+ Las aplicaciones de 32 bits no son compatibles con Amazon Linux 2023. Para más información, consulte [precated features from Amazon Linux 2](https://docs.aws.amazon.com/linux/al2023/ug/deprecated-al2.html#deprecated-32bit-rpms) en la *Guía del usuario de Amazon Linux 2023*.

### Cambios en los grupos de control (cgroups)
<a name="al2-to-al2023-ami-transition-compatibility-cgroups"></a>

Un grupo de control (cgroup) es una característica del código kernel de Linux que permite organizar jerárquicamente los procesos y distribuir los recursos del sistema entre ellos. Los grupos de control se utilizan ampliamente para implementar un tiempo de ejecución de contenedores, y mediante `systemd`.

El agente de Amazon ECS, Docker y containerd son compatibles con cgroupv1 y cgroupv2. El agente de Amazon ECS y el tiempo de ejecución del contenedor administran cgroups, por lo que los clientes de Amazon ECS no tienen que hacer ningún cambio en esta actualización de cgroup subyacente.

Para más información sobre cgroupv2, consulte [Control groups v2 in Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/cgroupv2.html) en la *Guía del usuario de Amazon Linux 2023*.

### Cambios en el servicio de metadatos de instancias (IMDS)
<a name="al2-to-al2023-ami-transition-compatibility-imds"></a>

De manera predeterminada, es necesaria la versión 2 del servicio de metadatos de instancias (IMDSv2) para Amazon Linux 2023. IMDSv2 tiene varios beneficios que ayudan a mejorar la postura de seguridad. Utiliza un método de autenticación orientado a la sesión que requiere la creación de un token secreto en una solicitud sencilla de HTTP PUT para iniciar la sesión. El tiempo de validez de un token de sesión puede oscilar entre 1 segundo y 6 horas.

Para más información sobre cómo hacer la transición de IMDSv1 a IMDSv2, consulte [Transición al uso del servicio de metadatos de instancias, versión 2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html) en la *Guía del usuario de Amazon EC2*.

Si desea utilizar IMDSv1, anule de manera manual la configuración mediante las propiedades de inicio de la opción de metadatos de la instancia.

### Cambios en el intercambio de memoria
<a name="al2-to-al2023-ami-transition-compatibility-memory-swappiness"></a>

No se admite el intercambio de memoria por contenedor en Amazon Linux 2023 ni en cgroups v2. Para obtener más información, consulte [Administración del espacio de memoria de intercambio de contenedores en Amazon ECS](container-swap.md).

### Cambios en la validación de FIPS
<a name="al2-to-al2023-ami-transition-compatibility-fips"></a>

Amazon Linux 2 cuenta con la certificación FIPS 140-2 y Amazon Linux 2023 con la certificación FIPS 140-3.

Para habilitar el modo FIPS en Amazon Linux 2023, instale los paquetes necesarios en la instancia de Amazon EC2 y siga las instrucciones de configuración que se indican en [Enable FIPS Mode on Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/fips-mode.html) en la *Guía de usuario de Amazon Linux 2023*.

### Compatibilidad de instancias aceleradas
<a name="al2-to-al2023-ami-transition-compatibility-accelerated"></a>

Las AMI de Amazon Linux 2023 optimizadas para Amazon ECS admiten los tipos de instancias aceleradas por GPU. Para obtener más información, consulte [AMI de Linux optimizadas para Amazon ECS](ecs-optimized_AMI.md).

## Creación de AMI personalizadas
<a name="al2-to-al2023-ami-transition-custom-ami"></a>

Si bien le recomendamos cambiarse a las AMI optimizadas para Amazon ECS publicadas y compatibles oficialmente para Amazon Linux 2023, puede seguir creando AMI personalizadas optimizadas para Amazon ECS de Amazon Linux 2 mediante los scripts de compilación de código abierto que se utilizan para crear las variantes de Linux de la AMI optimizada para Amazon ECS. Para obtener más información, consulte [Script de compilación de la AMI de Linux optimizada para Amazon ECS](ecs-ami-build-scripts.md).

## Estrategias de migración
<a name="al2-to-al2023-ami-transition-migration"></a>

Recomendamos crear e implementar un plan de migración que incluya pruebas exhaustivas de las aplicaciones. En las siguientes secciones se describen las distintas estrategias de migración en función de la forma en que administre la infraestructura de Amazon ECS.

### Migración con proveedores de capacidad de Amazon ECS
<a name="al2-to-al2023-ami-transition-migration-capacity-providers"></a>

1. Cree un nuevo proveedor de capacidad con una plantilla de lanzamiento nueva. Debe hacer referencia a un grupo de escalado automático con una plantilla de lanzamiento similar a la actual, pero en lugar de la AMI optimizada para Amazon ECS de Amazon Linux 2, debe especificar una de las variantes de Amazon Linux 2023. Agregue este nuevo proveedor de capacidad al clúster de Amazon ECS existente.

1. Actualice la estrategia de proveedor de capacidad predeterminado del clúster para incluir el proveedor de capacidad existente de Amazon Linux 2 y el nuevo proveedor de capacidad de Amazon Linux 2023. Comience con una ponderación más alta en el proveedor Amazon Linux 2 y una ponderación más baja en el proveedor Amazon Linux 2023 (por ejemplo, Amazon Linux 2: ponderación, 80; Amazon Linux 2023: ponderación, 20). Esto hace que Amazon ECS comience a aprovisionar instancias de Amazon Linux 2023 a medida que se programan nuevas tareas. Compruebe que las instancias se registren correctamente y que las tareas se puedan ejecutar correctamente en las nuevas instancias.

1. Ajuste gradualmente las ponderaciones de los proveedores de capacidad en la estrategia predeterminada del clúster, aumentando la ponderación del proveedor de Amazon Linux 2023 y disminuyendo la ponderación del proveedor de Amazon Linux 2 con el tiempo (por ejemplo, 60/40, después 40/60 y, por último, 20/80). También puede actualizar las estrategias individuales de los proveedores de capacidad de servicios para priorizar las instancias de Amazon Linux 2023. Supervise la ubicación de las tareas para asegurarse de que se ejecutan correctamente en las instancias de Amazon Linux 2023.

1. De manera opcional, vacíe las instancias de contenedor de Amazon Linux 2 para acelerar la migración de tareas. Si tiene suficiente capacidad de reemplazo de Amazon Linux 2023, puede vaciar manualmente las instancias de contenedor de Amazon Linux 2 a través de la consola de Amazon ECS o la AWS CLI para acelerar la transición de las tareas de Amazon Linux 2 hacia Amazon Linux 2023. Una vez completada la migración, elimine el proveedor de capacidad de Amazon Linux 2 del clúster y elimine el grupo de escalado automático asociado.

### Migración con un grupo de Amazon EC2 Auto Scaling
<a name="al2-to-al2023-ami-transition-migration-asg"></a>

1. Cree un nuevo grupo de Amazon EC2 Auto Scaling con una plantilla de lanzamiento nueva. Debe ser similar a la plantilla de lanzamiento actual, pero en lugar de la AMI optimizada para Amazon ECS de Amazon Linux 2, debe especificar una de las variantes de Amazon Linux 2023. Este nuevo grupo de escalado automático puede lanzar instancias al clúster actual.

1. Escale verticalmente el grupo de escalado automático para que las instancias de Amazon Linux 2023 se registren en el clúster. Compruebe que las instancias se registren correctamente y que las tareas se puedan ejecutar correctamente en las nuevas instancias.

1. Una vez que se haya comprobado que las tareas funcionan en Amazon Linux 2023, escale verticalmente el grupo de escalado automático de Amazon Linux 2023 y, a la vez, reduzca gradualmente el grupo de escalado automático de Amazon Linux 2, hasta que haya sustituido por completo todas las instancias de Amazon Linux 2.

1. Si tiene suficiente capacidad de reemplazo de Amazon Linux 2023, puede que desee vaciar explícitamente las instancias de contenedor para acelerar la transición de las tareas de Amazon Linux 2 hacia Amazon Linux 2023. Para obtener más información, consulte [Drenaje de instancias de contenedor de Amazon ECS](container-instance-draining.md).

### Migración con instancias administradas manualmente
<a name="al2-to-al2023-ami-transition-migration-manual"></a>

1. Lance manualmente (o ajuste los scripts que lanzan) las instancias de Amazon EC2 mediante la AMI de Amazon Linux 2023 optimizada para Amazon ECS en lugar de Amazon Linux 2. Asegúrese de que estas instancias utilizan los mismos grupos de seguridad, subredes, roles de IAM y configuración de clúster que las instancias de Amazon Linux 2 existentes. Las instancias deben registrarse automáticamente en el clúster de Amazon ECS existente en el momento del lanzamiento.

1. Compruebe que las nuevas instancias de Amazon Linux 2023 se registren correctamente en el clúster de Amazon ECS y que se encuentren en el estado `ACTIVE`. Compruebe que las tareas se puedan programar y ejecutar correctamente en estas nuevas instancias, ya sea que espere a que se asignen las tareas de forma natural o que las detenga o las inicie manualmente para activar la reprogramación.

1. Sustituya gradualmente las instancias de Amazon Linux 2; para ello, lance las instancias de Amazon Linux 2023 adicionales según sea necesario y, a continuación, vacíe y finalice manualmente las instancias de Amazon Linux 2 una por una. Puede vaciar las instancias a través de la consola de Amazon ECS; para ello, establezca la instancia en el estado `DRAINING`, lo que dejará de asignarle nuevas tareas y permitirá que las tareas existentes finalicen o se reprogramen en otro lugar.

# Script de compilación de la AMI de Linux optimizada para Amazon ECS
<a name="ecs-ami-build-scripts"></a>

Amazon ECS ha establecido en código abierto los scripts de compilación que se utilizan para crear las variantes de Linux de la AMI optimizada para Amazon ECS. Estos scripts de compilación están ahora disponibles en GitHub. Para obtener más información, consulte [amazon-ecs-ami](https://github.com/aws/amazon-ecs-ami) en GitHub.

Si necesita personalizar la AMI optimizada para Amazon ECS, consulte [Amazon ECS Optimized AMI Build Recipies](https://github.com/aws/amazon-ecs-ami) en GitHub.

El repositorio de scripts de compilación incluye una plantilla [HashiCorp packer](https://developer.hashicorp.com/packer/docs) y crea scripts para generar cada una de las variantes de Linux de las AMI optimizadas para Amazon ECS. Estos scripts son el origen de confianza para las compilaciones de la AMI optimizada para Amazon ECS, de modo que pueda seguir el repositorio de GitHub para monitorear los cambios en nuestras AMI. Por ejemplo, quizás desee su propia AMI para utilizar la misma versión de Docker que el equipo de Amazon ECS utiliza para la AMI oficial.

Para obtener más información, consulte el repositorio de AMI de Amazon ECS en [aws/amazon-ecs-ami](https://github.com/aws/amazon-ecs-ami) en GitHub.

**Para crear una AMI de Linux optimizada para Amazon ECS**

1. Clonar el repositorio `aws/amazon-ecs-ami` GitHub.

   ```
   git clone https://github.com/aws/amazon-ecs-ami.git
   ```

1. Agregue una variable de entorno para la región AWS que se utilizará al crear la AMI. Sustituya el valor `us-west-2` con la región que se va a utilizar.

   ```
   export REGION=us-west-2
   ```

1. Se proporciona un archivo Makefile para crear la AMI. Desde el directorio raíz del repositorio clonado, utilice uno de los siguientes comandos, correspondiente a la variante Linux de la AMI optimizada de Amazon ECS que desea crear.
   + AMI de Amazon Linux 2 optimizada para Amazon ECS

     ```
     make al2
     ```
   + AMI de Amazon Linux 2 (arm64) optimizada para Amazon ECS

     ```
     make al2arm
     ```
   + AMI optimizada para GPU de Amazon ECS

     ```
     make al2gpu
     ```
   + AMI de Amazon Linux 2 (Neuron) optimizada para Amazon ECS

     ```
     make al2inf
     ```
   + AMI de Amazon Linux 2023 optimizada para Amazon ECS

     ```
     make al2023
     ```
   + AMI de Amazon Linux 2023 (arm64) optimizada para Amazon ECS

     ```
     make al2023arm
     ```
   + AMI de GPU de Amazon Linux 2023 optimizada para Amazon ECS

     ```
     make al2023gpu
     ```
   + AMI de Amazon Linux 2023 (Neuron) optimizada por Amazon ECS

     ```
     make al2023neu
     ```

# AMI Bottlerocket optimizadas para Amazon ECS
<a name="ecs-bottlerocket"></a>

Bottlerocket es un sistema operativo de código abierto basado en Linux creado específicamente por AWS para ejecutar contenedores en máquinas virtuales o hosts bare metal. La AMI de Bottlerocket optimizada para Amazon ECS es segura y solo incluye la cantidad mínima de paquetes necesarios para ejecutar contenedores. Esto mejora el uso de los recursos, reduce la superficie expuesta a ataques contra la seguridad y ayuda a reducir los gastos administrativos. La AMI de Bottlerocket también está integrada con Amazon ECS para ayudar a reducir la sobrecarga operativa que implica la actualización de las instancias de contenedores en un clúster. 

Bottlerocket se diferencia de Amazon Linux en los siguientes aspectos:
+ Bottlerocket no incluye un administrador de paquetes y su software solo se puede ejecutar como contenedores. Las actualizaciones de Bottlerocket se aplican y se pueden revertir en un solo paso, lo que reduce la probabilidad de que se produzcan errores de actualización.
+ El mecanismo principal para administrar los hosts de Bottlerocket es mediante un programador de contenedores. A diferencia de Amazon Linux, el inicio de sesión en instancias de Bottlerocket individuales está pensado para ser una operación poco frecuente únicamente con fines avanzados de depuración y solución de problemas.

Para obtener más información acerca de Bottlerocket, consulte la [documentación](https://github.com/bottlerocket-os/bottlerocket/blob/develop/README.md) y las [versiones](https://github.com/bottlerocket-os/bottlerocket/releases) en GitHub.

Existen variantes de la AMI de Bottlerocket optimizada para Amazon ECS para los kernel 6.1 y 5.10.

Las siguientes variantes utilizan el kernel 6.1:
+ `aws-ecs-2`
+ `aws-ecs-2-nvidia`

Las siguientes variantes utilizan kernel 5.10:
+ `aws-ecs-1`
+ `aws-ecs-1-nvidia`

  Para obtener más información acerca de la variante `aws-ecs-1-nvidia`, consulte [Anuncio de la compatibilidad con GPU NVIDIA para Bottlerocket en Amazon ECS](https://aws.amazon.com/blogs/containers/announcing-nvidia-gpu-support-for-bottlerocket-on-amazon-ecs/).

## Consideraciones
<a name="ecs-bottlerocket-considerations"></a>

Tenga en cuenta lo siguiente al utilizar la AMI de Bottlerocket con Amazon ECS.
+ Bottlerocket admite instancias de Amazon EC2 con procesadores `x86_64` y `arm64`. No se recomienda utilizar la AMI Bottlerocket con instancias de Amazon EC2 con un chip Inferentia.
+ Las imágenes de Bottlerocket no incluyen un servidor SSH ni un shell. Sin embargo, puede utilizar herramientas de administración fuera de banda para obtener acceso de administrador SSH y realizar tareas de arranque. 

   Para obtener más información, consulte estas secciones en [bottlerocket README.md](https://github.com/bottlerocket-os/bottlerocket) en GitHub:
  + [Exploration (Exploración](https://github.com/bottlerocket-os/bottlerocket#exploration)
  + [Contenedor de administrador](https://github.com/bottlerocket-os/bottlerocket#admin-container)
+ De forma predeterminada, Bottlerocket tiene un [contenedor de control](https://github.com/bottlerocket-os/bottlerocket-control-container) que está habilitado. Este contenedor ejecuta el [agente de AWS Systems Manager](https://github.com/aws/amazon-ssm-agent) que puede utilizar para ejecutar comandos o iniciar sesiones de shell en instancias Bottlerocket de Amazon EC2. Para obtener más información, consulte [Configuración del administrador de sesiones](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started.html) en la *Guía del usuario de AWS Systems Manager*.
+ Bottlerocket está optimizado para cargas de trabajo de contenedores y se centra en la seguridad. Bottlerocket no incluye un administrador de paquetes y es inmutable. 

  Para obtener más información sobre las características y directrices de seguridad, consulte [Características de seguridad](https://github.com/bottlerocket-os/bottlerocket/blob/develop/SECURITY_FEATURES.md) y [Directrices sobre seguridad](https://github.com/bottlerocket-os/bottlerocket/blob/develop/SECURITY_GUIDANCE.md) en GitHub.
+ Se admite el modo de red `awsvpc` con la versión de AMI de Bottlerocket `1.1.0` o una posterior.
+ App Mesh en una definición de tarea es compatible con la versión AMI `1.15.0` de Bottlerocket o una posterior.
+ El parámetro de definición de tareas `initProcessEnabled` es compatible con la versión `1.19.0` de la AMI de Bottlerocket o una posterior.
+ Las AMI de Bottlerocket tampoco admiten los siguientes servicios y características:
  + ECS Anywhere
  + Service Connect
  + Amazon EFS en modo cifrado
  + Amazon EFS en modo de red `awsvpc`
  + Los volúmenes de Amazon EBS no se pueden montar
  + Acelerador de Elastic Inference

# Recuperación de metadatos de la AMI de Bottlerocket optimizada para Amazon ECS
<a name="ecs-bottlerocket-retrieve-ami"></a>

Puede recuperar el ID de Imagen de máquina de Amazon (AMI) de las AMI optimizadas para Amazon ECS al consultar la API de Parameter Store de AWS Systems Manager. Al utilizar este parámetro, no necesita buscar de manera manual los ID de la AMI optimizada para Amazon ECS. Para obtener más información acerca de la API de Systems Manager Parameter Store, consulte [GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html). El usuario que utiliza debe tener el permiso de IAM `ssm:GetParameter` para recuperar los metadatos de la AMI optimizada para Amazon ECS.

## Variante de AMI de Bottlerocket `aws-ecs-2`
<a name="ecs-bottlerocket-aws-ecs-2-variant"></a>

Puede recuperar la última variante estable de la AMI de `aws-ecs-2` Bottlerocket con Región de AWS y arquitectura mediante la AWS CLI o la Consola de administración de AWS. 
+ **AWS CLI**: puede recuperar el ID de imagen de la última AMI de Bottlerocket optimizada para Amazon ECS recomendada con el siguiente comando de la AWS CLI mediante el parámetro secundario `image_id`. Sustituya `region` con el código de región para el que desee el ID de la AMI. 

  Para obtener información sobre las Regiones de AWS compatibles, consulte [Finding an AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) en GitHub. Para recuperar una versión que no sea la más reciente, sustituya `latest` con el número de versión.
  + Para 64 bits (`x86_64`) de arquitectura:

    ```
    aws ssm get-parameter --region us-east-2 --name "/aws/service/bottlerocket/aws-ecs-2/x86_64/latest/image_id" --query Parameter.Value --output text
    ```
  + Para 64 bits Arm (`arm64`) de arquitectura:

    ```
    aws ssm get-parameter --region us-east-2 --name "/aws/service/bottlerocket/aws-ecs-2/arm64/latest/image_id" --query Parameter.Value --output text
    ```
+ **Consola de administración de AWS** – puede consultar el ID de la AMI optimizada para Amazon ECS recomendada mediante una URL en la Consola de administración de AWS. La URL abre la consola de Amazon EC2 Systems Manager con el valor del ID del parámetro. En la siguiente URL, sustituya `region` con el código de región para el que desee el ID de la AMI. 

   Para obtener información sobre las Regiones de AWS compatibles, consulte [Finding an AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) en GitHub.
  + Para 64 bits (`x86_64`) de arquitectura:

    ```
    https://console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-2/x86_64/latest/image_id/description?region=region#
    ```
  + Para 64 bits Arm (`arm64`) de arquitectura:

    ```
    https://console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-2/arm64/latest/image_id/description?region=region#
    ```

## Variante de AMI de Bottlerocket `aws-ecs-2-nvidia`
<a name="ecs-bottlerocket-aws-ecs-1-nvidia-variants"></a>

Puede recuperar la última variante estable de la AMI de `aws-ecs-2-nvdia` Bottlerocket por región y arquitectura con la AWS CLI o la Consola de administración de AWS. 
+ **AWS CLI**: puede recuperar el ID de imagen de la última AMI de Bottlerocket optimizada para Amazon ECS recomendada con el siguiente comando de la AWS CLI mediante el parámetro secundario `image_id`. Sustituya `region` con el código de región para el que desee el ID de la AMI. 

   Para obtener información sobre las Regiones de AWS compatibles, consulte [Finding an AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) en GitHub. Para recuperar una versión que no sea la más reciente, sustituya `latest` con el número de versión.
  + Para 64 bits (`x86_64`) de arquitectura:

    ```
    aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-2-nvidia/x86_64/latest/image_id" --query Parameter.Value --output text
    ```
  + Para 64 bits Arm (`arm64`) de arquitectura:

    ```
    aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-2-nvidia/arm64/latest/image_id" --query Parameter.Value --output text
    ```
+ **Consola de administración de AWS** – puede consultar el ID de la AMI optimizada para Amazon ECS recomendada mediante una URL en la Consola de administración de AWS. La URL abre la consola de Amazon EC2 Systems Manager con el valor del ID del parámetro. En la siguiente URL, sustituya `region` con el código de región para el que desee el ID de la AMI. 

  Para obtener información sobre las Regiones de AWS compatibles, consulte [Finding an AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) en GitHub.
  + Para 64 bits (`x86_64`) de arquitectura:

    ```
    https://regionconsole.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-2-nvidia/x86_64/latest/image_id/description?region=region#
    ```
  + Para 64 bits Arm (`arm64`) de arquitectura:

    ```
    https://regionconsole.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-2-nvidia/arm64/latest/image_id/description?region=region#
    ```

## Variante de AMI de Bottlerocket `aws-ecs-1`
<a name="ecs-bottlerocket-aws-ecs-1-variant"></a>

Puede recuperar la última variante estable de la AMI de `aws-ecs-1` Bottlerocket con Región de AWS y arquitectura mediante la AWS CLI o la Consola de administración de AWS. 
+ **AWS CLI**: puede recuperar el ID de imagen de la última AMI de Bottlerocket optimizada para Amazon ECS recomendada con el siguiente comando de la AWS CLI mediante el parámetro secundario `image_id`. Sustituya `region` con el código de región para el que desee el ID de la AMI. 

  Para obtener información sobre las Regiones de AWS compatibles, consulte [Finding an AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) en GitHub. Para recuperar una versión que no sea la más reciente, sustituya `latest` con el número de versión.
  + Para 64 bits (`x86_64`) de arquitectura:

    ```
    aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-1/x86_64/latest/image_id" --query Parameter.Value --output text
    ```
  + Para 64 bits Arm (`arm64`) de arquitectura:

    ```
    aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-1/arm64/latest/image_id" --query Parameter.Value --output text
    ```
+ **Consola de administración de AWS** – puede consultar el ID de la AMI optimizada para Amazon ECS recomendada mediante una URL en la Consola de administración de AWS. La URL abre la consola de Amazon EC2 Systems Manager con el valor del ID del parámetro. En la siguiente URL, sustituya `region` con el código de región para el que desee el ID de la AMI.

  Para obtener información sobre las Regiones de AWS compatibles, consulte [Finding an AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) en GitHub.
  + Para 64 bits (`x86_64`) de arquitectura:

    ```
    https://region.console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-1/x86_64/latest/image_id/description
    ```
  + Para 64 bits Arm (`arm64`) de arquitectura:

    ```
    https://region.console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-1/arm64/latest/image_id/description
    ```

## Variante de AMI de Bottlerocket `aws-ecs-1-nvidia`
<a name="ecs-bottlerocket-aws-ecs-1-nvidia-variants"></a>

Puede recuperar la última variante estable de la AMI de `aws-ecs-1-nvdia` Bottlerocket por región y arquitectura con la AWS CLI o la Consola de administración de AWS. 
+ **AWS CLI**: puede recuperar el ID de imagen de la última AMI de Bottlerocket optimizada para Amazon ECS recomendada con el siguiente comando de la AWS CLI mediante el parámetro secundario `image_id`. Sustituya `region` con el código de región para el que desee el ID de la AMI. 

  Para obtener información sobre las Regiones de AWS compatibles, consulte [Finding an AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) en GitHub.
  + Para 64 bits (`x86_64`) de arquitectura:

    ```
    aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-1-nvidia/x86_64/latest/image_id" --query Parameter.Value --output text
    ```
  + Para 64 bits Arm (`arm64`) de arquitectura:

    ```
    aws ssm get-parameter --region us-east-1 --name "/aws/service/bottlerocket/aws-ecs-1-nvidia/arm64/latest/image_id" --query Parameter.Value --output text
    ```
+ **Consola de administración de AWS** – puede consultar el ID de la AMI optimizada para Amazon ECS recomendada mediante una URL en la Consola de administración de AWS. La URL abre la consola de Amazon EC2 Systems Manager con el valor del ID del parámetro. En la siguiente URL, sustituya `region` con el código de región para el que desee el ID de la AMI. 

  Para obtener información sobre las Regiones de AWS compatibles, consulte [Finding an AMI](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md#finding-an-ami) en GitHub.
  + Para 64 bits (`x86_64`) de arquitectura:

    ```
    https://console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-1-nvidia/x86_64/latest/image_id/description?region=region#
    ```
  + Para 64 bits Arm (`arm64`) de arquitectura:

    ```
    https://console.aws.amazon.com/systems-manager/parameters/aws/service/bottlerocket/aws-ecs-1-nvidia/arm64/latest/image_id/description?region=region#
    ```

## Siguientes pasos
<a name="bottlerocket-next-steps"></a>

Para obtener un tutorial detallado sobre cómo empezar a utilizar el sistema operativo Bottlerocket en Amazon ECS, consulte [Uso de una AMI de Bottlerocket con Amazon ECS](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md) en GitHub e [Introducción a Bottlerocket y Amazon ECS](https://aws.amazon.com/blogs/containers/getting-started-with-bottlerocket-and-amazon-ecs/) en el blog de AWS.

Para obtener más información acerca de cómo iniciar una instancia de Bottlerocket, consulte [Lanzamiento de una instancia de Bottlerocket para Amazon ECS](bottlerocket-launch.md).

# Lanzamiento de una instancia de Bottlerocket para Amazon ECS
<a name="bottlerocket-launch"></a>

Puede iniciar una instancia de Bottlerocket para poder ejecutar sus cargas de trabajo de contenedor.

Puede utilizar la AWS CLI para iniciar la instancia de Bottlerocket.

1. Cree un archivo denominado `userdata.toml`. Este archivo se utiliza para los datos de usuario de la instancia. Sustituya *cluster-name* por el nombre de su clúster.

   ```
   [settings.ecs]
   cluster = "cluster-name"
   ```

1. Utilice uno de los comandos que se incluyen en [Recuperación de metadatos de la AMI de Bottlerocket optimizada para Amazon ECS](ecs-bottlerocket-retrieve-ami.md) para obtener el ID de la AMI de Bottlerocket. Utilice esto en el siguiente paso.

1. Ejecute el siguiente comando para lanzar una instancia de Bottlerocket. Recuerde reemplazar los siguientes parámetros:
   + Sustituya la *subred* por el ID de la subred pública o privada en la que se lanzará la instancia.
   + Sustituya *bottlerocket\$1ami* por el ID de la AMI del paso anterior.
   + Sustituya *t3.large* por el tipo de instancia que desee usar.
   + Sustituya *región* por su código de región.

   ```
   aws ec2 run-instances --key-name ecs-bottlerocket-example \
      --subnet-id subnet \
      --image-id bottlerocket_ami \
      --instance-type t3.large \
      --region region \
      --tag-specifications 'ResourceType=instance,Tags=[{Key=bottlerocket,Value=example}]' \
      --user-data file://userdata.toml \
      --iam-instance-profile Name=ecsInstanceRole
   ```

1. Ejecute el siguiente comando para comprobar que la instancia de contenedor está registrada en el clúster. Al ejecutar este comando, recuerde reemplazar los siguientes parámetros:
   + Sustituya *clúster* por el nombre del clúster.
   + Sustituya *región* por el código de región.

   ```
   aws ecs list-container-instances --cluster cluster-name --region region
   ```

Para obtener una explicación detallada sobre cómo empezar a utilizar el sistema operativo Bottlerocket en Amazon ECS, consulte [Uso de una AMI de Bottlerocket con Amazon ECS](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-ECS.md) en GitHub e Introducción a [Bottlerocket y Amazon ECS](https://aws.amazon.com/blogs/containers/getting-started-with-bottlerocket-and-amazon-ecs/) en el blog de AWS.

# Administración de instancias de contenedor de Linux de Amazon ECS
<a name="manage-linux"></a>

Cuando utiliza instancias de EC2 para las cargas de trabajo de Amazon ECS, es responsable del mantenimiento de instancias.

**Topics**
+ [Lanzamiento de una instancia de contenedor](launch_container_instance.md)
+ [Arranque de instancias de contenedor de Linux](bootstrap_container_instance.md)
+ [Configuración de instancias de contenedor para recibir avisos de instancias de spot](spot-instance-draining-linux-container.md)
+ [Ejecución de un script al lanzar una instancia de contenedor](start_task_at_launch.md)
+ [Aumento de las interfaces de red de instancias de contenedor de Linux de Amazon ECS](container-instance-eni.md)
+ [Reserva de la memoria de instancias de contenedor](memory-management.md)
+ [Administración remota de instancias de contenedor](ec2-run-command.md)
+ [Uso de un proxy HTTP para instancias de contenedor de Linux](http_proxy_config.md)
+ [Configuración de instancias preinicializadas para el grupo de escalado automático](using-warm-pool.md)
+ [Actualización del agente de contenedor de Amazon ECS](ecs-agent-update.md)

Cada versión del agente de contenedor de Amazon ECS admite un conjunto de características diferente y proporciona correcciones de errores de versiones anteriores. Cuando sea posible, siempre recomendamos utilizar la versión más reciente del agente de contenedor de Amazon ECS. Para actualizar el agente de contenedor a la versión más reciente, consulte [Actualización del agente de contenedor de Amazon ECS](ecs-agent-update.md).

Para ver las características y mejoras incluidas en cada versión del agente, consulte [https://github.com/aws/amazon-ecs-agent/releases](https://github.com/aws/amazon-ecs-agent/releases).

**importante**  
La versión mínima de Docker para obtener métricas fiables es la versión de Docker `v20.10.13` y versiones posteriores, que se incluyen en la AMI `20220607` optimizada para Amazon ECS y versiones posteriores.  
Los agentes de Amazon ECS versión `1.20.0` y posteriores ya no admiten versiones de Docker anteriores a la `18.01.0`.

# Lanzamiento de una instancia de contenedor de Linux de Amazon ECS
<a name="launch_container_instance"></a>

Puede crear instancias de contenedor de Amazon ECS mediante la consola de Amazon EC2. 

Puede lanzar una instancia con varios métodos, incluidos la consola de Amazon EC2, AWS CLI y SDK. Para obtener información sobre los demás métodos para lanzar una instancia, consulte [Iniciar la instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/LaunchingAndUsingInstances.html) en la *Guía del usuario de Amazon EC2*.

Para obtener más información acerca del asistente de inicialización, consulte [Lance una instancia con el nuevo asistente de inicialización de instancias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html) en la *Guía del usuario de Amazon EC2*. 

Antes de comenzar, complete los pasos de [Configuración para utilizar Amazon ECS](get-set-up-for-amazon-ecs.md).

Puede utilizar el nuevo asistente de Amazon EC2 para lanzar una instancia. El asistente de inicialización de instancias especifica todos los parámetros de inicialización necesarios para iniciar una instancia. 

**Topics**
+ [Procedimiento](#linux-liw-initiate-instance-launch)
+ [Nombre y etiquetas](#linux-liw-name-and-tags)
+ [Imágenes de aplicaciones y sistema operativo (Imagen de máquina de Amazon)](#linux-liw-ami)
+ [Tipo de instancia](#linux-liw-instance-type)
+ [Par de claves (inicio de sesión)](#linux-liw-key-pair)
+ [Configuración de red](#linux-liw-network-settings)
+ [Configurar almacenamiento](#linux-liw-storage)
+ [Detalles avanzados](#linux-liw-advanced-details)

## Procedimiento
<a name="linux-liw-initiate-instance-launch"></a>

Antes de comenzar, complete los pasos de [Configuración para utilizar Amazon ECS](get-set-up-for-amazon-ecs.md).

1. Abra la consola de Amazon EC2 en [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. En la barra de navegación de la parte superior de la pantalla, se muestra la región de AWS actual (por ejemplo, Este de EE. UU. [Ohio]). Seleccione una región en la que se va a iniciar la instancia. 

1. En el panel de la consola de Amazon EC2, elija **Iniciar instancia**.

## Nombre y etiquetas
<a name="linux-liw-name-and-tags"></a>

El nombre de la instancia es una etiqueta, donde la clave es **Name** (Nombre) y el valor es el nombre que especifique. Puede etiquetar la instancia, los volúmenes y los gráficos elásticos. Para las instancias de spot, solo puede etiquetar la solicitud de instancia de spot. 

Especificar un nombre de instancia y etiquetas adicionales es opcional.
+ En **Name** (Nombre), ingrese un nombre descriptivo para la instancia. Si no especifica un nombre, la instancia se puede identificar mediante su ID, que se genera automáticamente al iniciar la instancia.
+ Para agregar otras etiquetas, elija **Add additional tag** (Agregar etiqueta adicional). Elija **Add tag** (Agregar etiqueta) y, a continuación, ingrese una clave y un valor, y seleccione el tipo de recurso que desea etiquetar. Elija **Add tag** (Agregar etiqueta) para cada etiqueta adicional.

## Imágenes de aplicaciones y sistema operativo (Imagen de máquina de Amazon)
<a name="linux-liw-ami"></a>

Una Imagen de máquina de Amazon (AMI) proporciona la información necesaria para crear una instancia. Por ejemplo, una AMI puede contener el software necesario para funcionar como servidor web, como Apache, y su sitio web.

Utilice la barra de **búsqueda** para buscar una AMI optimizada para Amazon ECS adecuada publicada por AWS.

1. Escriba uno de los siguientes términos en la barra de **búsqueda**.
   + **ami-ecs**
   + El **valor** de una AMI optimizada para Amazon ECS.

     Para obtener las AMI optimizadas para Amazon ECS más recientes y sus valores, consulte [Versiones de AMI de Linux optimizadas para Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#ecs-optimized-ami-linux).

1. Pulse **Intro**.

1. En la página **Choose an Amazon Machine Image (AMI)** (Elija una imagen de máquina de Amazon [AMI]), seleccione la categoría **AWSMarketplace AMIs** (AMI de Marketplace).

1. En el panel **Refine results** (Limitar resultados) situado a la izquierda, seleccione **Amazon Web Services** como **publicador**.

1. Elija **Select** (Seleccionar) en la fila de la AMI que desea utilizar.

   De manera alternativa, elija **Cancel** (Cancelar) (en la parte superior derecha) para volver al asistente de instancias de lanzamiento sin elegir una AMI. Se seleccionará una AMI predeterminada. Asegúrese de que la AMI cumpla con los requisitos descritos en las [AMI de Linux optimizadas para Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html).

## Tipo de instancia
<a name="linux-liw-instance-type"></a>

El tipo de instancia define la configuración de hardware y el tamaño de la instancia. Los tipos de instancia más grandes tienen una CPU y memoria superiores. Para obtener más información, consulte [Tipos de instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) en la *Guía del usuario de Amazon EC2*. Si quiere poner en marcha una carga de trabajo de solo IPv6, algunos tipos de instancias no admiten direcciones IPv6. Para obtener más información, consulte [direcciones IPv6](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#ipv6-addressing) en la *Guía del usuario de Amazon EC2*.
+ En **Instance Type** (Tipo de instancia), seleccione el tipo de instancia de la instancia. 

   El tipo de instancia que seleccione determina los recursos disponibles para poner en marcha sus tareas.

## Par de claves (inicio de sesión)
<a name="linux-liw-key-pair"></a>

En **Key pair name** (Nombre de par de claves) seleccione un par de claves existente o seleccione **Create new key pair** (Crear nuevo par de claves) para crear uno nuevo. 

**importante**  
Si elige la opción **Proceed without key pair (Not recommended)** (Continuar sin un par de claves [No recomendado]), no podrá conectarse a la instancia a menos que elija una AMI que esté configurada para ofrecer a los usuarios otra forma de iniciar sesión.

## Configuración de red
<a name="linux-liw-network-settings"></a>

Configure los ajustes de red según sea necesario después de pulsar el botón **Editar** en la sección de **ajustes de red** del formulario.
+ Para **VPC**, elija la VPC en la que desea lanzar su instancia. Para poner en marcha una carga de trabajo de solo IPv6, elija una VPC de pila doble que incluya un bloque de CIDR IPv4 y un bloque de CIDR IPv6.
+ En **Subred**, elija la subred en la que desea lanzar la instancia. Puede lanzar una instancia en una subred asociada con una zona de disponibilidad, zona local, zona de Wavelength u Outpost.

  Para iniciar la instancia en una zona de disponibilidad, seleccione la subred en la que desea iniciar la instancia. Para crear una subred, elija **Crear nueva subred** para ir a la consola de Amazon VPC. Cuando haya terminado, vuelva al asistente de lanzamiento de instancias y elija el ícono Refresh (Actualizar) para cargar la subred en la lista.

  Para iniciar la instancia en una zona local, seleccione una subred que haya creado en la zona local. 

  Para iniciar una instancia en un Outpost, seleccione una subred en una VPC que haya asociado a un Outpost.

  Para poner en marcha una carga de trabajo de solo IPv6, elija una subred que incluya únicamente un bloque de CIDR IPv6.
+ **Auto-assign Public IP** (Asignar automáticamente IP pública): si desea que se pueda acceder a la instancia desde Internet, compruebe que el campo **Auto-assign Public IP** (Asignar automáticamente IP pública) esté configurado como **Enable** (Habilitar). De lo contrario, configure este campo como **Disable** (Deshabilitar).
**nota**  
Las instancias de contenedor deben obtener acceso para comunicarse con el punto de conexión del servicio de Amazon ECS. Esto puede ser a través de un punto de conexión de VPC de la interfaz o a través de las instancias de contenedor con direcciones IP públicas.  
Para obtener más información acerca de los puntos de conexión de VPC, consulte [Puntos de enlace de la VPC de interfaz de Amazon ECS (AWS PrivateLink)](vpc-endpoints.md).  
Si no tiene configurado un punto de conexión de VPC de la interfaz y las instancias de contenedor no tienen direcciones IP públicas, deberán utilizar traducción de direcciones de red (NAT) para proporcionar este acceso. Para obtener más información, consulte [Puertas de enlace NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) en la *Guía del usuario de Amazon VPC* y [Uso de un proxy HTTP para instancias de contenedor de Linux de Amazon ECS](http_proxy_config.md) en esta guía. 
+ Si elige una VPC de doble pila y una subred de solo IPv6, en **Asignar automáticamente una IP de IPv6**, elija **Habilitar**.
+ **Firewall (security groups)** Firewall (grupos de seguridad): utilice un grupo de seguridad para definir reglas de firewall para la instancia de contenedor. Estas reglas especifican qué tráfico procedente de la red se entregará en la instancia de contenedor. El resto del tráfico se ignora. 
  + Para seleccionar un grupo de seguridad existente, elija **Select an existing security group** (Seleccionar un grupo de seguridad existente) y seleccione el grupo de seguridad que creó en [Configuración para utilizar Amazon ECS](get-set-up-for-amazon-ecs.md).
+ Si va a lanzar la instancia para una carga de trabajo de solo IPv6, elija **Configuración de red avanzada** y, a continuación, en **Asignar IP IPv6 principal**, elija **Sí**.
**nota**  
Sin una dirección IPv6 principal, las tareas que se pongan en marcha en la instancia de contenedor en los modos de red host o puente no se registrarán con los equilibradores de carga ni con AWS Cloud Map.

## Configurar almacenamiento
<a name="linux-liw-storage"></a>

La AMI seleccionada incluye uno o más volúmenes de almacenamiento, incluido el volumen de dispositivo raíz. Se pueden especificar volúmenes adicionales para adjuntar a la instancia.

Se puede utilizar la vista **Simple** (Simple).
+ **Storage type** (Tipo de almacenamiento): configure el almacenamiento de la instancia de contenedor.

  Si utiliza la AMI de Amazon Linux 2 optimizada para Amazon ECS, la instancia tiene un único volumen de 30 GiB configurado, que se comparte entre el sistema operativo y Docker.

  Si utiliza la AMI optimizada para Amazon ECS, la instancia tiene configurados dos volúmenes. El volumen **raíz** lo utiliza el sistema operativo y el segundo volumen de Amazon EBS (asociado a `/dev/xvdcz`) lo utiliza Docker.

  Si lo desea, puede aumentar o reducir el tamaño de volumen para su instancia de acuerdo con las necesidades de su aplicación.

## Detalles avanzados
<a name="linux-liw-advanced-details"></a>

En **Detalles avanzados**, expanda la sección para ver los campos y especifique cualquier parámetro adicional para la instancia.
+ **Purchasing option** (Opción de compra): elija **Request Spot instances** (Solicitar instancias de spot) para solicitar una instancia de spot. También debe establecer el resto de los campos relacionados con las instancias de Spot. Para obtener más información, consulte [Spot Instance Requests](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html) (Solicitudes de instancias de Spot).
**nota**  
Si utiliza instancias de Spot y ve un mensaje que indica `Not available`, es posible que deba elegir un tipo de instancia diferente.
+ En **IAM instance profile** (Perfil de instancia de IAM), seleccione el rol de IAM de la instancia de contenedor. Suele llamarse `ecsInstanceRole`.
**importante**  
Si no lanza la instancia de contenedor con los permisos de IAM correspondientes, el agente de Amazon ECS no puede conectarse al clúster. Para obtener más información, consulte [Rol de IAM de instancia de contenedor de Amazon ECS](instance_IAM_role.md).
+ **Datos de usuario**: configure la instancia de contenedor de Amazon ECS con los datos de usuario, por ejemplo, las variables de entorno del agente de [Configuración del agente de contenedor de Amazon ECS](ecs-agent-config.md). Los scripts de datos de usuario de Amazon EC2 se ponen en marcha solo una vez, cuando la instancia se lanza por primera vez. A continuación, se muestran ejemplos comunes del uso de los datos del usuario:
  + De forma predeterminada, su instancia de contenedor se abre en su clúster predeterminado. Para abrirlo en un clúster no predeterminado, seleccione la lista **Advanced Details**. A continuación, pegue el siguiente script en el campo **User data**, reemplazando *your\$1cluster\$1name* con el nombre de su clúster.

    ```
    #!/bin/bash
    echo ECS_CLUSTER=your_cluster_name >> /etc/ecs/ecs.config
    ```
  + Si tiene un archivo `ecs.config` en Amazon S3 y ha habilitado el acceso de solo lectura de Amazon S3 en el rol de instancia de contenedor, elija la lista **Advanced Details** (Detalles avanzados). A continuación, pegue el siguiente script en el campo **User data (Datos de usuario)**, sustituyendo *your\$1bucket\$1name* por el nombre del bucket para instalar la AWS CLI y escriba su archivo de configuración en el momento del lanzamiento. 
**nota**  
Para obtener más información acerca de esta configuración, consulte [Almacenamiento de la configuración de instancia de contenedor de Amazon ECS en Amazon S3](ecs-config-s3.md).

    ```
    #!/bin/bash
    yum install -y aws-cli
    aws s3 cp s3://your_bucket_name/ecs.config /etc/ecs/ecs.config
    ```
  + Especifique las etiquetas para su instancia de contenedor mediante el parámetro de configuración `ECS_CONTAINER_INSTANCE_TAGS`. De esto modo, se crean etiquetas que solo están asociadas a Amazon ECS; no se pueden enumerar mediante la API de Amazon EC2.
**importante**  
Si inicia las instancias de contenedor mediante un grupo de Amazon EC2 Auto Scaling, debe utilizar el parámetro de configuración del agente ECS\$1CONTAINER\$1INSTANCE\$1TAGS para agregar etiquetas. Esto se debe a la forma en que se agregan las etiquetas a las instancias de Amazon EC2 que se lanzan mediante grupos de Auto Scaling.

    ```
    #!/bin/bash
    cat <<'EOF' >> /etc/ecs/ecs.config
    ECS_CLUSTER=your_cluster_name
    ECS_CONTAINER_INSTANCE_TAGS={"tag_key": "tag_value"}
    EOF
    ```
  + Especifique las etiquetas para la instancia de contenedor y, a continuación, utilice el parámetro de configuración `ECS_CONTAINER_INSTANCE_PROPAGATE_TAGS_FROM` para propagarlas de Amazon EC2 a Amazon ECS

    A continuación se muestra un ejemplo de un script de datos de usuario que propaga las etiquetas asociadas a una instancia de contenedor, y registra la instancia de contenedor con un clúster denominado `your_cluster_name`:

    ```
    #!/bin/bash
    cat <<'EOF' >> /etc/ecs/ecs.config
    ECS_CLUSTER=your_cluster_name
    ECS_CONTAINER_INSTANCE_PROPAGATE_TAGS_FROM=ec2_instance
    EOF
    ```
  + De forma predeterminada, el agente de contenedor de Amazon ECS intentará detectar la compatibilidad de la instancia de contenedor con una configuración de solo IPv6 observando las rutas IPv4 e IPv6 predeterminadas de la instancia. Para anular este comportamiento, puede establecer el parámetro ` ECS_INSTANCE_IP_COMPATIBILITY` en `ipv4` o `ipv6` en el archivo `/etc/ecs/ecs.config` de la instancia.

    ```
    #!/bin/bash
    cat <<'EOF' >> /etc/ecs/ecs.config
    ECS_CLUSTER=your_cluster_name
    ECS_INSTANCE_IP_COMPATIBILITY=ipv6
    EOF
    ```

  Para obtener más información, consulte [Arranque de instancias de contenedor de Linux de Amazon ECS para la transferencia de datos](bootstrap_container_instance.md).

# Arranque de instancias de contenedor de Linux de Amazon ECS para la transferencia de datos
<a name="bootstrap_container_instance"></a>

Cuando se lanza una instancia de Amazon EC2, puede transferir los datos de usuario a la instancia de EC2. Los datos se pueden utilizar para llevar a cabo tareas de configuración automatizadas comunes e incluso poner en marcha scripts cuando la instancia arranca. En Amazon ECS, los casos de uso más comunes para los datos de usuario consisten en transferir la información de configuración al daemon de Docker y al agente de contenedor de Amazon ECS.

Puede transferir varios tipos de datos de usuario a Amazon EC2, incluidos cloud boothooks, scripts de shell y directivas `cloud-init`. Para obtener más información acerca de estos u otros tipos de formato, consulte la [documentación de Cloud-Init](https://cloudinit.readthedocs.io/en/latest/explanation/format.html). 

Para transferir los datos de usuario al utilizar el asistente de lanzamiento de Amazon EC2, consulte [Lanzamiento de una instancia de contenedor de Linux de Amazon ECS](launch_container_instance.md).

Puede configurar la instancia de contenedor para transferir los datos en la configuración del agente de contenedor o en la configuración del daemon de Docker.

## Agente de contenedor de Amazon ECS
<a name="bootstrap_container_agent"></a>

Las variantes de Linux de la AMI optimizada para Amazon ECS buscan datos de configuración del agente en el archivo `/etc/ecs/ecs.config` cuando se inicia el agente de contenedor. Puede especificar estos datos de configuración durante el lanzamiento con datos de usuario de Amazon EC2. Para obtener más información acerca de las variables de configuración del agente de contenedor de Amazon ECS disponibles, consulte [Configuración del agente de contenedor de Amazon ECS](ecs-agent-config.md).

Para establecer solo una variable de configuración del agente como, por ejemplo, el nombre del clúster, utilice **echo** para copiar la variable en el archivo de configuración:

```
#!/bin/bash
echo "ECS_CLUSTER=MyCluster" >> /etc/ecs/ecs.config
```

Si tiene varias variables que escribir en `/etc/ecs/ecs.config`, utilice el formato `heredoc` siguiente. Este formato escribe todo entre las líneas que comienzan por **cat** y `EOF` en el archivo de configuración.

```
#!/bin/bash
cat <<'EOF' >> /etc/ecs/ecs.config
ECS_CLUSTER=MyCluster
ECS_ENGINE_AUTH_TYPE=docker
ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"username":"my_name","password":"my_password","email":"email@example.com"}}
ECS_LOGLEVEL=debug
ECS_WARM_POOLS_CHECK=true
EOF
```

Para configurar los atributos de instancia personalizados, defina la variable de entorno `ECS_INSTANCE_ATTRIBUTES`.

```
#!/bin/bash
cat <<'EOF' >> ecs.config
ECS_INSTANCE_ATTRIBUTES={"envtype":"prod"}
EOF
```

## Daemon de Docker
<a name="bootstrap_docker_daemon"></a>

Puede especificar la información de configuración del daemon de Docker con los datos de usuario de Amazon EC2. Para obtener más información sobre las opciones de configuración, consulte [la documentación del daemon de Docker](https://docs.docker.com/reference/cli/dockerd/).

**nota**  
AWS no admite configuraciones personalizadas de Docker, ya que a veces pueden entrar en conflicto con futuros cambios o características de Amazon ECS sin previo aviso.

En el ejemplo siguiente, las opciones personalizadas se agregan al archivo de configuración del daemon de Docker, que es `/etc/docker/daemon.json`, y luego se especifica en los datos del usuario cuando se lanza la instancia.

```
#!/bin/bash
cat <<EOF >/etc/docker/daemon.json
{"debug": true}
EOF
systemctl restart docker --no-block
```

En el ejemplo siguiente, las opciones personalizadas se agregan al archivo de configuración del daemon de Docker, que es `/etc/docker/daemon.json`, y luego se especifica en los datos del usuario cuando se lanza la instancia. En este ejemplo se muestra cómo activar o desactivar el docker-proxy en el archivo de configuración de daemon de Docker.

```
#!/bin/bash
cat <<EOF >/etc/docker/daemon.json
{"userland-proxy": false}
EOF
systemctl restart docker --no-block
```

# Configuración de instancias de contenedor de Linux de Amazon ECS para recibir avisos de instancias de spot
<a name="spot-instance-draining-linux-container"></a>

Amazon EC2 termina, detiene o hiberna la instancia de spot cuando el precio de spot supera el precio máximo de su solicitud o cuando ya no hay más capacidad. Amazon EC2 envía un aviso de interrupción de dos minutos de la instancia de spot para la terminación y la detención de acciones. No proporciona el aviso de dos minutos para la acción de hibernación. Si el drenaje de instancias de spot de Amazon ECS está activado en la instancia, Amazon ECS recibe el aviso de interrupción de la instancia de spot y coloca la instancia en el estado `DRAINING`. 

**importante**  
Amazon ECS no recibe ningún aviso de Amazon EC2 cuando Auto Scaling Capacity Rebalancing elimina las instancias. Para obtener más información, consulte [Reequilibrio de la capacidad de Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-capacity-rebalancing.html).

Cuando se establece una instancia de contenedor en `DRAINING`, Amazon ECS evita que se programen nuevas tareas para su ubicación en la instancia de contenedor. Las tareas de servicio en la instancia de contenedor que se está vaciando que están en el estado `PENDING` se paran de inmediato. Si hay instancias de contenedor en el clúster que están disponibles, las tareas de servicio de sustitución se inician en ellas.

El drenaje de instancias de spot está desactivado de forma predeterminada. 

Puede activar el drenaje de instancias de spot al lanzar una instancia. Agregue el script siguiente en el campo **Datos de usuario**. Reemplace *MyCluster* por el nombre del clúster en el que se va a registrar la instancia de contenedor.

```
#!/bin/bash
cat <<'EOF' >> /etc/ecs/ecs.config
ECS_CLUSTER=MyCluster
ECS_ENABLE_SPOT_INSTANCE_DRAINING=true
EOF
```

Para obtener más información, consulte [Lanzamiento de una instancia de contenedor de Linux de Amazon ECS](launch_container_instance.md).

**Para activar el vaciado de instancias de spot para una instancia de contenedor existente**

1. Conéctese a la instancia de spot a través de SSH.

1. Edite el archivo `/etc/ecs/ecs.config` y añada lo siguiente:

   ```
   ECS_ENABLE_SPOT_INSTANCE_DRAINING=true
   ```

1. Reinicie el servicio `ecs`.
   + Para la AMI de Amazon Linux 2 optimizada para Amazon ECS:

     ```
     sudo systemctl restart ecs
     ```

1. (Opcional) Puede verificar que el agente esté en marcha y ver información acerca de la nueva instancia de contenedor consultando la operación de la API de introspección del agente. Para obtener más información, consulte [Introspección de contenedor de Amazon ECS](ecs-agent-introspection.md).

   ```
   curl http://localhost:51678/v1/metadata
   ```

# Ejecución de un script al lanzar una instancia de contenedor de Linux de Amazon ECS
<a name="start_task_at_launch"></a>

Es posible que tenga que ejecutar un contenedor específico en cada instancia de contenedor para tratar problemas de seguridad o de operaciones tales como la supervisión, seguridad, métricas, detección de servicios o registro.

Para ello, puede configurar sus instancias de contenedor para llamar al comando **docker run** con el script de datos de usuario durante el lanzamiento o en algún sistema de inicio como Upstart o **systemd**. Aunque este método funciona, tiene algunas desventajas ya que Amazon ECS no conoce el contenedor y no puede monitorear la CPU, la memoria, los puertos ni ningún otro recurso utilizado. A fin de garantizar que Amazon ECS pueda contabilizar correctamente todos los recursos de tareas, cree una definición de tareas para que el contenedor las ejecute en las instancias de contenedor. A continuación, utilice Amazon ECS para ubicar la tarea en el momento del lanzamiento con los datos de usuario de Amazon EC2.

En el siguiente procedimiento, el script de datos de usuario de Amazon EC2 utiliza la API de introspección de Amazon ECS para identificar la instancia de contenedor. A continuación, utiliza la AWS CLI y el comando **start-task** para ejecutar una tarea especificada en sí mismo durante el inicio. 

**Para iniciar una tarea en el momento del lanzamiento de una instancia de contenedor**

1. Modifique el rol de IAM `ecsInstanceRole` para añadir permisos para la operación `StartTask` de la API. Para obtener más información, consulte [Actualización de los permisos de un rol](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_update-role-permissions.html) en la *Guía del usuario de AWS Identity and Access Management*.

1. Lance una o más instancias de contenedor mediante la AMI de Amazon Linux 2 optimizada para Amazon ECS. Lance nuevas instancias de contenedor y utilice el siguiente script de ejemplo en Datos de usuario de EC2. Reemplace *your\$1cluster\$1name* por el clúster de la instancia de contenedor en el que desea registrarse y *my\$1task\$1def* por la definición de tarea que desea ejecutar en la instancia en el momento del lanzamiento. 

   Para obtener más información, consulte [Lanzamiento de una instancia de contenedor de Linux de Amazon ECS](launch_container_instance.md).
**nota**  
El contenido multiparte de MIME a continuación utiliza un script de shell para establecer valores de configuración e instalar paquetes. También utiliza un trabajo systemd para iniciar la tarea después de la ejecución del servicio **ecs** y una vez que la API de introspección está disponible.

   ```
   Content-Type: multipart/mixed; boundary="==BOUNDARY=="
   MIME-Version: 1.0
   
   --==BOUNDARY==
   Content-Type: text/x-shellscript; charset="us-ascii"
   
   #!/bin/bash
   # Specify the cluster that the container instance should register into
   cluster=your_cluster_name
   
   # Write the cluster configuration variable to the ecs.config file
   # (add any other configuration variables here also)
   echo ECS_CLUSTER=$cluster >> /etc/ecs/ecs.config
   
   START_TASK_SCRIPT_FILE="/etc/ecs/ecs-start-task.sh"
   cat <<- 'EOF' > ${START_TASK_SCRIPT_FILE}
   	exec 2>>/var/log/ecs/ecs-start-task.log
   	set -x
   	
   	# Install prerequisite tools
   	yum install -y jq aws-cli
   	
   	# Wait for the ECS service to be responsive
   	until curl -s http://localhost:51678/v1/metadata
   	do
   		sleep 1
   	done
   
   	# Grab the container instance ARN and AWS Region from instance metadata
   	instance_arn=$(curl -s http://localhost:51678/v1/metadata | jq -r '. | .ContainerInstanceArn' | awk -F/ '{print $NF}' )
   	cluster=$(curl -s http://localhost:51678/v1/metadata | jq -r '. | .Cluster' | awk -F/ '{print $NF}' )
   	region=$(curl -s http://localhost:51678/v1/metadata | jq -r '. | .ContainerInstanceArn' | awk -F: '{print $4}')
   
   	# Specify the task definition to run at launch
   	task_definition=my_task_def
   
   	# Run the AWS CLI start-task command to start your task on this container instance
   	aws ecs start-task --cluster $cluster --task-definition $task_definition --container-instances $instance_arn --started-by $instance_arn --region $region
   EOF
   
   # Write systemd unit file
   UNIT="ecs-start-task.service"
   cat <<- EOF > /etc/systemd/system/${UNIT}
         [Unit]
         Description=ECS Start Task
         Requires=ecs.service
         After=ecs.service
    
         [Service]
         Restart=on-failure
         RestartSec=30
         ExecStart=/usr/bin/bash ${START_TASK_SCRIPT_FILE}
   
         [Install]
         WantedBy=default.target
   EOF
   
   # Enable our ecs.service dependent service with `--no-block` to prevent systemd deadlock
   # See https://github.com/aws/amazon-ecs-agent/issues/1707
   systemctl enable --now --no-block "${UNIT}"
   --==BOUNDARY==--
   ```

1. Compruebe que sus instancias de contenedor se lancen en el clúster correcto y que sus tareas se hayan iniciado.

   1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

   1. En la barra de navegación, seleccione la región en la que se encuentra el clúster.

   1. En el panel de navegación, seleccione **Clusters** y seleccione el clúster que aloja sus instancias de contenedor.

   1. En la página **Clúster**, elija **Tareas** y, a continuación, elija las tareas.

      Cada instancia de contenedor que lanzó debe tener la tarea ejecutándose en ella.

      Si no ve las tareas, puede iniciar sesión en sus instancias de contenedor con SSH y comprobar la información de depuración del archivo `/var/log/ecs/ecs-start-task.log`.

# Aumento de las interfaces de red de instancias de contenedor de Linux de Amazon ECS
<a name="container-instance-eni"></a>

**nota**  
Esta característica no está disponible en Fargate.

Cada tarea que usa el modo de red `awsvpc` recibe su propia interfaz de red elástica (ENI), que se asocia a la instancia de contenedor que la aloja. Existe un límite predeterminado en cuanto al número de interfaces de red que pueden asociarse a una instancia de Amazon EC2, y la interfaz de red principal cuenta como una. Por ejemplo, de forma predeterminada una instancia de `c5.large` puede tener asociadas hasta tres ENI. La interfaz de red principal para la instancia cuenta como una, por lo que puede asociar a la instancia dos ENI adicionales. Dado que cada tarea que utiliza el modo de red `awsvpc` requiere una ENI, normalmente solo puede ejecutar dos de esas tareas en este tipo de instancia.

Amazon ECS es compatible con el inicio de instancias de contenedor con mayor densidad de ENI al usar tipos de instancias de Amazon EC2 compatibles. Cuando se utilizan estos tipos de instancias y se activa la configuración de cuenta `awsvpcTrunking`, aparecen ENI adicionales disponibles en las instancias de contenedor recién lanzadas. Esta configuración le permite colocar más tareas en cada instancia de contenedor. Para utilizar la consola con el objeto de activar la característica, consulte [Modificación de la configuración de la cuenta de Amazon ECS](ecs-modifying-longer-id-settings.md). Para utilizar la AWS CLI con el objeto de activar la característica, consulte [Administración de la configuración de la cuenta de Amazon ECS mediante la AWS CLI](account-setting-management-cli.md). 

Por ejemplo, una instancia `c5.large` con `awsvpcTrunking` tiene un límite de ENI aumentado de doce. La instancia de contenedor tendrá la interfaz de red principal, y Amazon ECS crea y asocia una interfaz de red “troncal” a la instancia de contenedor. Por lo tanto, esta configuración le permite lanzar diez tareas en la instancia de contenedor, en lugar de las dos tareas actuales.

La interfaz de red troncal está completamente administrada por Amazon ECS y se elimina cuando se termina o se anula el registro de su instancia de contenedor en el clúster. Para obtener más información, consulte [Opciones de red de tareas de Amazon ECS para EC2](task-networking.md).

## Consideraciones
<a name="eni-trunking-considerations"></a>

Tenga en cuenta lo siguiente al utilizar la característica de enlace troncal de ENI.
+ Solo admiten aumento de los límites de ENI las variantes Linux de la AMI optimizada para Amazon ECS u otras variantes de Amazon Linux con la versión `1.28.1` o una posterior del agente de contenedor, y la versión `1.28.1-2` o una posterior del paquete ecs-init. Si utiliza la variante de Linux más reciente de la AMI optimizada para Amazon ECS, deberá cumplir estos requisitos. Los contenedores de Windows no son en este momento compatibles.
+ Solo las nuevas instancias de Amazon EC2 iniciadas después de habilitar `awsvpcTrunking` reciben el aumento de límites de ENI y la interfaz de red troncal. Las instancias lanzadas anteriormente no reciben estas características, independientemente de las acciones realizadas.
+ Las instancias de Amazon EC2 deben tener desactivadas las solicitudes DNS IPv4 basadas en recursos. Para desactivar esta opción, anule la opción **Habilitar solicitudes DNS IPV4 (registro A) basadas en recursos** al crear una nueva instancia mediante la consola de Amazon EC2. Para deshabilitar esta opción mediante el AWS CLI, utilice el siguiente comando.

  ```
  aws ec2 modify-private-dns-name-options --instance-id i-xxxxxxx --no-enable-resource-name-dns-a-record --no-dry-run
  ```
+ No se admiten instancias de Amazon EC2 en subredes compartidas. No se registrarán en un clúster si se utilizan.
+ Las tareas deben utilizar el modo de red `awsvpc` y la EC2. Las tareas que utilizan Fargate siempre han recibido una ENI exclusiva, independientemente de cuántas se lancen, por lo que esta característica no es necesaria.
+ Las tareas se deben lanzar en la misma Amazon VPC que la instancia de contenedor. Las tareas no se iniciarán con un error de atributo si no están dentro de la misma VPC.
+ Al lanzar una nueva instancia de contenedor, la instancia pasa a un estado `REGISTERING` mientras la interfaz de red elástica troncal se aprovisiona para la instancia. Si el registro da error, la instancia pasa a un estado `REGISTRATION_FAILED`. Para solucionar un error de registro, describa la instancia de contenedor para visualizar el campo `statusReason` que describe el motivo del error. A continuación, la instancia de contenedor se puede terminar o anular manualmente su registro. Una vez que se haya anulado el registro de la instancia de contenedor o terminado correctamente, Amazon ECS eliminará la ENI troncal.
**nota**  
Amazon ECS emite eventos de cambio de estado de instancia de contenedor que se pueden monitorear para las instancias que pasan a un estado `REGISTRATION_FAILED`. Para obtener más información, consulte [Eventos de cambio de estado de instancia de contenedor de Amazon ECS](ecs_container_instance_events.md).
+ Una vez terminada la instancia de contenedor, la instancia pasa a un estado `DEREGISTERING` mientras se desaprovisiona la interfaz de red elástica troncal. La instancia después pasa a un estado `INACTIVE`.
+ Si se detiene una instancia de contenedor en una subred pública con el aumento de los límites de ENI y, a continuación, se reinicia, la instancia pierde su dirección IP pública y el agente de contenedor pierde su conexión.
+ Cuando se habilita `awsvpcTrunking`, las instancias de contenedor reciben un ENI adicional que usa el grupo de seguridad predeterminado de la VPC y es administrado por Amazon ECS.

  Una VPC predeterminada incluye una subred pública en cada zona de disponibilidad, una puerta de enlace de Internet y la configuración para habilitar la resolución DNS. La subred es una subred pública, ya que la tabla de enrutamiento principal envía a la puerta de enlace de Internet el tráfico de la subred que está destinado a Internet. Puede convertir una subred predeterminada en una subred privada eliminando la ruta del destino 0.0.0.0/0 al puerto de enlace a Internet. Sin embargo, si hace esto, ninguna instancia de contenedor que se esté ejecutando en esa subred podrá obtener acceso a Internet. Puede agregar o eliminar reglas del grupo de seguridad para controlar el tráfico que entra y sale de sus subredes. Para obtener más información, consulte [Reglas del grupo de seguridad](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) en la *Guía del usuario de Amazon Virtual Private Cloud*.

## Requisitos previos
<a name="eni-trunking-launching"></a>

Antes de iniciar una instancia de contenedor con aumento de límites de ENI, deben completarse los siguientes requisitos previos.
+ Se debe crear el rol vinculado al servicio para Amazon ECS. El rol vinculado al servicio de Amazon ECS proporciona a Amazon ECS los permisos para realizar llamadas a otros servicios de AWS en su nombre. Este rol se crea automáticamente al crear un clúster, o bien al crear o actualizar un servicio en la Consola de administración de AWS. Para obtener más información, consulte [Uso de roles vinculados al servicio para Amazon ECS](using-service-linked-roles.md). También puede crear el rol vinculado a un servicio con el siguiente comando de la AWS CLI:

  ```
  aws iam [create-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-service-linked-role.html) --aws-service-name ecs.amazonaws.com
  ```
+ El rol de IAM de su cuenta o instancia de contenedor debe inscribirse en la configuración de la cuenta `awsvpcTrunking`. Le recomendamos crear dos roles de instancia de contenedor (`ecsInstanceRole`). A continuación, puede habilitar la configuración de la cuenta de `awsvpcTrunking` para un rol y usar ese rol para las tareas que requieren el enlace troncal de ENI. Para obtener más información sobre el rol de instancia de contenedor, consulte [Rol de IAM de instancia de contenedor de Amazon ECS](instance_IAM_role.md).

Una vez que se cumplan los requisitos previos, puede iniciar una nueva instancia de contenedor con uno de los tipos de instancia de Amazon EC2 compatibles, y la instancia tendrá el aumento de límites de ENI. Para ver una lista de los tipos de instancia admitidos, consulte [Instancias admitidas para un aumento de las interfaces de red de contenedores de Amazon ECS](eni-trunking-supported-instance-types.md). La instancia de contenedor debe tener la versión `1.28.1` o posterior del agente de contenedor y la versión `1.28.1-2` o posterior del paquete ecs-init. Si utiliza la variante de Linux más reciente de la AMI optimizada para Amazon ECS, deberá cumplir estos requisitos. Para obtener más información, consulte [Lanzamiento de una instancia de contenedor de Linux de Amazon ECS](launch_container_instance.md).

**importante**  
Las instancias de Amazon EC2 deben tener desactivadas las solicitudes DNS IPv4 basadas en recursos. Para deshabilitar esta opción, asegúrese de que **Habilitar solicitudes DNS IPV4 (registro A) basadas en recursos** se anula la selección de al crear una nueva instancia mediante la consola de Amazon EC2. Para deshabilitar esta opción mediante el AWS CLI, utilice el siguiente comando.  

```
aws ec2 modify-private-dns-name-options --instance-id i-xxxxxxx --no-enable-resource-name-dns-a-record --no-dry-run
```

**Para ver las instancias de contenedor con aumento de los límites de ENI con la AWS CLI**

Cada instancia de contenedor tiene una interfaz de red predeterminada, lo que se denomina interfaz de red troncal. Para utilizar el siguiente comando a fin de ver una lista de las instancias de contenedor con un aumento de los límites de ENI, consulte el atributo `ecs.awsvpc-trunk-id`, que indica que tiene una interfaz de red troncal.
+ [list-attributes](https://docs.aws.amazon.com/cli/latest/reference/ecs/list-attributes.html) (AWS CLI)

  ```
  aws ecs list-attributes \
        --target-type container-instance \
        --attribute-name ecs.awsvpc-trunk-id \
        --cluster cluster_name \
        --region us-east-1
  ```
+ [Get-ECSAttributeList](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-ECSAttributeList.html) (AWS Tools for Windows PowerShell)

  ```
  Get-ECSAttributeList -TargetType container-instance -AttributeName ecs.awsvpc-trunk-id -Region us-east-1
  ```

# Instancias admitidas para un aumento de las interfaces de red de contenedores de Amazon ECS
<a name="eni-trunking-supported-instance-types"></a>

A continuación, se muestran los tipos de instancias de Amazon EC2 que se admiten y la cantidad de tareas que utilizan el modo de red `awsvpc` que se pueden lanzar en cada tipo de instancias antes y después de optar por incluir la configuración de cuenta `awsvpcTrunking`. 

**importante**  
Aunque se admiten otros tipos de instancia en la misma familia de instancias, no se admiten los tipos de instancia `a1.metal`, `c5.metal`, `c5a.8xlarge`, `c5ad.8xlarge`, `c5d.metal`, `m5.metal`, `p3dn.24xlarge`, `r5.metal`, `r5.8xlarge` y `r5d.metal`.  
Las familias de instancias `c5n`, `d3`, `d3en`, `g3`, `g3s`, `g4dn`, `i3`, `i3en`, `inf1`, `m5dn`, `m5n`, `m5zn`, `mac1`, `r5b`, `r5n`, `r5dn`, `u-12tb1`, `u-6tb1`, `u-9tb1` y `z1d` no son compatibles.

**Topics**
+ [Fin general](#eni-branch-gp)
+ [Optimizada para computación](#eni-branch-co)
+ [Optimizada para memoria](#eni-branch-mo)
+ [Optimizada para almacenamiento](#eni-branch-so)
+ [Computación acelerada](#eni-branch-ac)
+ [Computación de alto rendimiento](#eni-branch-hpc)

## Fin general
<a name="eni-branch-gp"></a>


| Tipo de instancia | Límite de tareas sin enlace troncal de ENI | Límite de tareas con enlace troncal de ENI | 
| --- | --- | --- | 
| a1.medium | 1 | 10 | 
| a1.large | 2 | 10 | 
| a1.xlarge | 3 | 20 | 
| a1.2xlarge | 3 | 40 | 
| a1.4xlarge | 7 | 60 | 
| m5.large | 2 | 10 | 
| m5.xlarge | 3 | 20 | 
| m5.2xlarge | 3 | 40 | 
| m5.4xlarge | 7 | 60 | 
| m5.8xlarge | 7 | 60 | 
| m5.12xlarge | 7 | 60 | 
| m5.16xlarge | 14 | 120 | 
| m5.24xlarge | 14 | 120 | 
| m5a.large | 2 | 10 | 
| m5a.xlarge | 3 | 20 | 
| m5a.2xlarge | 3 | 40 | 
| m5a.4xlarge | 7 | 60 | 
| m5a.8xlarge | 7 | 60 | 
| m5a.12xlarge | 7 | 60 | 
| m5a.16xlarge | 14 | 120 | 
| m5a.24xlarge | 14 | 120 | 
| m5ad.large | 2 | 10 | 
| m5ad.xlarge | 3 | 20 | 
| m5ad.2xlarge | 3 | 40 | 
| m5ad.4xlarge | 7 | 60 | 
| m5ad.8xlarge | 7 | 60 | 
| m5ad.12xlarge | 7 | 60 | 
| m5ad.16xlarge | 14 | 120 | 
| m5ad.24xlarge | 14 | 120 | 
| m5d.large | 2 | 10 | 
| m5d.xlarge | 3 | 20 | 
| m5d.2xlarge | 3 | 40 | 
| m5d.4xlarge | 7 | 60 | 
| m5d.8xlarge | 7 | 60 | 
| m5d.12xlarge | 7 | 60 | 
| m5d.16xlarge | 14 | 120 | 
| m5d.24xlarge | 14 | 120 | 
| m5d.metal | 14 | 120 | 
| m6a.large | 2 | 10 | 
| m6a.xlarge | 3 | 20 | 
| m6a.2xlarge | 3 | 40 | 
| m6a.4xlarge | 7 | 60 | 
| m6a.8xlarge | 7 | 90 | 
| m6a.12xlarge | 7 | 120 | 
| m6a.16xlarge | 14 | 120 | 
| m6a.24xlarge | 14 | 120 | 
| m6a.32xlarge | 14 | 120 | 
| m6a.48xlarge | 14 | 120 | 
| m6a.metal | 14 | 120 | 
| m6g.medium | 1 | 4 | 
| m6g.large | 2 | 10 | 
| m6g.xlarge | 3 | 20 | 
| m6g.2xlarge | 3 | 40 | 
| m6g.4xlarge | 7 | 60 | 
| m6g.8xlarge | 7 | 60 | 
| m6g.12xlarge | 7 | 60 | 
| m6g.16xlarge | 14 | 120 | 
| m6g.metal | 14 | 120 | 
| m6gd.medium | 1 | 4 | 
| m6gd.large | 2 | 10 | 
| m6gd.xlarge | 3 | 20 | 
| m6gd.2xlarge | 3 | 40 | 
| m6gd.4xlarge | 7 | 60 | 
| m6gd.8xlarge | 7 | 60 | 
| m6gd.12xlarge | 7 | 60 | 
| m6gd.16xlarge | 14 | 120 | 
| m6gd.metal | 14 | 120 | 
| m6i.large | 2 | 10 | 
| m6i.xlarge | 3 | 20 | 
| m6i.2xlarge | 3 | 40 | 
| m6i.4xlarge | 7 | 60 | 
| m6i.8xlarge | 7 | 90 | 
| m6i.12xlarge | 7 | 120 | 
| m6i.16xlarge | 14 | 120 | 
| m6i.24xlarge | 14 | 120 | 
| m6i.32xlarge | 14 | 120 | 
| m6i.metal | 14 | 120 | 
| m6id.large | 2 | 10 | 
| m6id.xlarge | 3 | 20 | 
| m6id.2xlarge | 3 | 40 | 
| m6id.4xlarge | 7 | 60 | 
| m6id.8xlarge | 7 | 90 | 
| m6id.12xlarge | 7 | 120 | 
| m6id.16xlarge | 14 | 120 | 
| m6id.24xlarge | 14 | 120 | 
| m6id.32xlarge | 14 | 120 | 
| m6id.metal | 14 | 120 | 
| m6idn.large | 2 | 10 | 
| m6idn.xlarge | 3 | 20 | 
| m6idn.2xlarge | 3 | 40 | 
| m6idn.4xlarge | 7 | 60 | 
| m6idn.8xlarge | 7 | 90 | 
| m6idn.12xlarge | 7 | 120 | 
| m6idn.16xlarge | 14 | 120 | 
| m6idn.24xlarge | 14 | 120 | 
| m6idn.32xlarge | 15 | 120 | 
| m6idn.metal | 15 | 120 | 
| m6in.large | 2 | 10 | 
| m6in.xlarge | 3 | 20 | 
| m6in.2xlarge | 3 | 40 | 
| m6in.4xlarge | 7 | 60 | 
| m6in.8xlarge | 7 | 90 | 
| m6in.12xlarge | 7 | 120 | 
| m6in.16xlarge | 14 | 120 | 
| m6in.24xlarge | 14 | 120 | 
| m6in.32xlarge | 15 | 120 | 
| m6in.metal | 15 | 120 | 
| m7a.medium | 1 | 4 | 
| m7a.large | 2 | 10 | 
| m7a.xlarge | 3 | 20 | 
| m7a.2xlarge | 3 | 40 | 
| m7a.4xlarge | 7 | 60 | 
| m7a.8xlarge | 7 | 90 | 
| m7a.12xlarge | 7 | 120 | 
| m7a.16xlarge | 14 | 120 | 
| m7a.24xlarge | 14 | 120 | 
| m7a.32xlarge | 14 | 120 | 
| m7a.48xlarge | 14 | 120 | 
| m7a.metal-48xl | 14 | 120 | 
| m7g.medium | 1 | 4 | 
| m7g.large | 2 | 10 | 
| m7g.xlarge | 3 | 20 | 
| m7g.2xlarge | 3 | 40 | 
| m7g.4xlarge | 7 | 60 | 
| m7g.8xlarge | 7 | 60 | 
| m7g.12xlarge | 7 | 60 | 
| m7g.16xlarge | 14 | 120 | 
| m7g.metal | 14 | 120 | 
| m7gd.medium | 1 | 4 | 
| m7gd.large | 2 | 10 | 
| m7gd.xlarge | 3 | 20 | 
| m7gd.2xlarge | 3 | 40 | 
| m7gd.4xlarge | 7 | 60 | 
| m7gd.8xlarge | 7 | 60 | 
| m7gd.12xlarge | 7 | 60 | 
| m7gd.16xlarge | 14 | 120 | 
| m7gd.metal | 14 | 120 | 
| m7i.large | 2 | 10 | 
| m7i.xlarge | 3 | 20 | 
| m7i.2xlarge | 3 | 40 | 
| m7i.4xlarge | 7 | 60 | 
| m7i.8xlarge | 7 | 90 | 
| m7i.12xlarge | 7 | 120 | 
| m7i.16xlarge | 14 | 120 | 
| m7i.24xlarge | 14 | 120 | 
| m7i.48xlarge | 14 | 120 | 
| m7i.metal-24xl | 14 | 120 | 
| m7i.metal-48xl | 14 | 120 | 
| m7i-flex.large | 2 | 4 | 
| m7i-flex.xlarge | 3 | 10 | 
| m7i-flex.2xlarge | 3 | 20 | 
| m7i-flex.4xlarge | 7 | 40 | 
| m7i-flex.8xlarge | 7 | 60 | 
| m7i-flex.12xlarge | 7 | 120 | 
| m7i-flex.16xlarge | 14 | 120 | 
| m8a.medium | 1 | 4 | 
| m8a.large | 2 | 10 | 
| m8a.xlarge | 3 | 20 | 
| m8a.2xlarge | 3 | 40 | 
| m8a.4xlarge | 7 | 60 | 
| m8a.8xlarge | 9 | 90 | 
| m8a.12xlarge | 11 | 120 | 
| m8a.16xlarge | 15 | 120 | 
| m8a.24xlarge | 15 | 120 | 
| m8a.48xlarge | 23 | 120 | 
| m8a.metal-24xl | 15 | 120 | 
| m8a.metal-48xl | 23 | 120 | 
| m8azn.medium | 2 | 4 | 
| m8azn.large | 3 | 10 | 
| m8azn.xlarge | 3 | 20 | 
| m8azn.3xlarge | 7 | 40 | 
| m8azn.6xlarge | 7 | 60 | 
| m8azn.12xlarge | 15 | 120 | 
| m8azn.24xlarge | 15 | 120 | 
| m8azn.metal-12xl | 15 | 120 | 
| m8azn.metal-24xl | 15 | 120 | 
| m8g.medium | 1 | 4 | 
| m8g.large | 2 | 10 | 
| m8g.xlarge | 3 | 20 | 
| m8g.2xlarge | 3 | 40 | 
| m8g.4xlarge | 7 | 60 | 
| m8g.8xlarge | 7 | 60 | 
| m8g.12xlarge | 7 | 60 | 
| m8g.16xlarge | 14 | 120 | 
| m8g.24xlarge | 14 | 120 | 
| m8g.48xlarge | 14 | 120 | 
| m8g.metal-24xl | 14 | 120 | 
| m8g.metal-48xl | 14 | 120 | 
| m8gb.medium | 1 | 4 | 
| m8gb.large | 2 | 10 | 
| m8gb.xlarge | 3 | 20 | 
| m8gb.2xlarge | 3 | 40 | 
| m8gb.4xlarge | 7 | 60 | 
| m8gb.8xlarge | 9 | 60 | 
| m8gb.12xlarge | 11 | 60 | 
| m8gb.16xlarge | 15 | 120 | 
| m8gb.24xlarge | 23 | 120 | 
| m8gb.48xlarge | 23 | 120 | 
| m8gb.metal-24xl | 23 | 120 | 
| m8gb.metal-48xl | 23 | 120 | 
| m8gd.medium | 1 | 4 | 
| m8gd.large | 2 | 10 | 
| m8gd.xlarge | 3 | 20 | 
| m8gd.2xlarge | 3 | 40 | 
| m8gd.4xlarge | 7 | 60 | 
| m8gd.8xlarge | 7 | 60 | 
| m8gd.12xlarge | 7 | 60 | 
| m8gd.16xlarge | 14 | 120 | 
| m8gd.24xlarge | 14 | 120 | 
| m8gd.48xlarge | 14 | 120 | 
| m8gd.metal-24xl | 14 | 120 | 
| m8gd.metal-48xl | 14 | 120 | 
| m8gn.medium | 1 | 4 | 
| m8gn.large | 2 | 10 | 
| m8gn.xlarge | 3 | 20 | 
| m8gn.2xlarge | 3 | 40 | 
| m8gn.4xlarge | 7 | 60 | 
| m8gn.8xlarge | 9 | 60 | 
| m8gn.12xlarge | 11 | 60 | 
| m8gn.16xlarge | 15 | 120 | 
| m8gn.24xlarge | 23 | 120 | 
| m8gn.48xlarge | 23 | 120 | 
| m8gn.metal-24xl | 23 | 120 | 
| m8gn.metal-48xl | 23 | 120 | 
| m8i.large | 2 | 10 | 
| m8i.xlarge | 3 | 20 | 
| m8i.2xlarge | 3 | 40 | 
| m8i.4xlarge | 7 | 60 | 
| m8i.8xlarge | 9 | 90 | 
| m8i.12xlarge | 11 | 120 | 
| m8i.16xlarge | 15 | 120 | 
| m8i.24xlarge | 15 | 120 | 
| m8i.32xlarge | 23 | 120 | 
| m8i.48xlarge | 23 | 120 | 
| m8i.96xlarge | 23 | 120 | 
| m8i.metal-48xl | 23 | 120 | 
| m8i.metal-96xl | 23 | 120 | 
| m8id.large | 2 | 10 | 
| m8id.xlarge | 3 | 20 | 
| m8id.2xlarge | 3 | 40 | 
| m8id.4xlarge | 7 | 60 | 
| m8id.8xlarge | 9 | 90 | 
| m8id.12xlarge | 11 | 120 | 
| m8id.16xlarge | 15 | 120 | 
| m8id.24xlarge | 15 | 120 | 
| m8id.32xlarge | 23 | 120 | 
| m8id.48xlarge | 23 | 120 | 
| m8id.96xlarge | 23 | 120 | 
| m8id.metal-48xl | 23 | 120 | 
| m8i.metal-96xl | 23 | 120 | 
| m8i-flex.large | 2 | 4 | 
| m8i-flex.xlarge | 3 | 10 | 
| m8i-flex.2xlarge | 3 | 20 | 
| m8i-flex.4xlarge | 7 | 40 | 
| m8i-flex.8xlarge | 9 | 60 | 
| m8i-flex.12xlarge | 11 | 120 | 
| m8i-flex.16xlarge | 15 | 120 | 
| mac2.metal | 7 | 12 | 
| mac2-m1ultra.metal | 7 | 12 | 
| mac2-m2.metal | 7 | 12 | 
| mac2-m2pro.metal | 7 | 12 | 
| mac-m4.metal | 7 | 12 | 
| mac-m4pro.metal | 7 | 12 | 

## Optimizada para computación
<a name="eni-branch-co"></a>


| Tipo de instancia | Límite de tareas sin enlace troncal de ENI | Límite de tareas con enlace troncal de ENI | 
| --- | --- | --- | 
| c5.large | 2 | 10 | 
| c5.xlarge | 3 | 20 | 
| c5.2xlarge | 3 | 40 | 
| c5.4xlarge | 7 | 60 | 
| c5.9xlarge | 7 | 60 | 
| c5.12xlarge | 7 | 60 | 
| c5.18xlarge | 14 | 120 | 
| c5.24xlarge | 14 | 120 | 
| c5a.large | 2 | 10 | 
| c5a.xlarge | 3 | 20 | 
| c5a.2xlarge | 3 | 40 | 
| c5a.4xlarge | 7 | 60 | 
| c5a.12xlarge | 7 | 60 | 
| c5a.16xlarge | 14 | 120 | 
| c5a.24xlarge | 14 | 120 | 
| c5ad.large | 2 | 10 | 
| c5ad.xlarge | 3 | 20 | 
| c5ad.2xlarge | 3 | 40 | 
| c5ad.4xlarge | 7 | 60 | 
| c5ad.12xlarge | 7 | 60 | 
| c5ad.16xlarge | 14 | 120 | 
| c5ad.24xlarge | 14 | 120 | 
| c5d.large | 2 | 10 | 
| c5d.xlarge | 3 | 20 | 
| c5d.2xlarge | 3 | 40 | 
| c5d.4xlarge | 7 | 60 | 
| c5d.9xlarge | 7 | 60 | 
| c5d.12xlarge | 7 | 60 | 
| c5d.18xlarge | 14 | 120 | 
| c5d.24xlarge | 14 | 120 | 
| c6a.large | 2 | 10 | 
| c6a.xlarge | 3 | 20 | 
| c6a.2xlarge | 3 | 40 | 
| c6a.4xlarge | 7 | 60 | 
| c6a.8xlarge | 7 | 90 | 
| c6a.12xlarge | 7 | 120 | 
| c6a.16xlarge | 14 | 120 | 
| c6a.24xlarge | 14 | 120 | 
| c6a.32xlarge | 14 | 120 | 
| c6a.48xlarge | 14 | 120 | 
| c6a.metal | 14 | 120 | 
| c6g.medium | 1 | 4 | 
| c6g.large | 2 | 10 | 
| c6g.xlarge | 3 | 20 | 
| c6g.2xlarge | 3 | 40 | 
| c6g.4xlarge | 7 | 60 | 
| c6g.8xlarge | 7 | 60 | 
| c6g.12xlarge | 7 | 60 | 
| c6g.16xlarge | 14 | 120 | 
| c6g.metal | 14 | 120 | 
| c6gd.medium | 1 | 4 | 
| c6gd.large | 2 | 10 | 
| c6gd.xlarge | 3 | 20 | 
| c6gd.2xlarge | 3 | 40 | 
| c6gd.4xlarge | 7 | 60 | 
| c6gd.8xlarge | 7 | 60 | 
| c6gd.12xlarge | 7 | 60 | 
| c6gd.16xlarge | 14 | 120 | 
| c6gd.metal | 14 | 120 | 
| c6gn.medium | 1 | 4 | 
| c6gn.large | 2 | 10 | 
| c6gn.xlarge | 3 | 20 | 
| c6gn.2xlarge | 3 | 40 | 
| c6gn.4xlarge | 7 | 60 | 
| c6gn.8xlarge | 7 | 60 | 
| c6gn.12xlarge | 7 | 60 | 
| c6gn.16xlarge | 14 | 120 | 
| c6i.large | 2 | 10 | 
| c6i.xlarge | 3 | 20 | 
| c6i.2xlarge | 3 | 40 | 
| c6i.4xlarge | 7 | 60 | 
| c6i.8xlarge | 7 | 90 | 
| c6i.12xlarge | 7 | 120 | 
| c6i.16xlarge | 14 | 120 | 
| c6i.24xlarge | 14 | 120 | 
| c6i.32xlarge | 14 | 120 | 
| c6i.metal | 14 | 120 | 
| c6id.large | 2 | 10 | 
| c6id.xlarge | 3 | 20 | 
| c6id.2xlarge | 3 | 40 | 
| c6id.4xlarge | 7 | 60 | 
| c6id.8xlarge | 7 | 90 | 
| c6id.12xlarge | 7 | 120 | 
| c6id.16xlarge | 14 | 120 | 
| c6id.24xlarge | 14 | 120 | 
| c6id.32xlarge | 14 | 120 | 
| c6id.metal | 14 | 120 | 
| c6in.large | 2 | 10 | 
| c6in.xlarge | 3 | 20 | 
| c6in.2xlarge | 3 | 40 | 
| c6in.4xlarge | 7 | 60 | 
| c6in.8xlarge | 7 | 90 | 
| c6in.12xlarge | 7 | 120 | 
| c6in.16xlarge | 14 | 120 | 
| c6in.24xlarge | 14 | 120 | 
| c6in.32xlarge | 15 | 120 | 
| c6in.metal | 15 | 120 | 
| c7a.medium | 1 | 4 | 
| c7a.large | 2 | 10 | 
| c7a.xlarge | 3 | 20 | 
| c7a.2xlarge | 3 | 40 | 
| c7a.4xlarge | 7 | 60 | 
| c7a.8xlarge | 7 | 90 | 
| c7a.12xlarge | 7 | 120 | 
| c7a.16xlarge | 14 | 120 | 
| c7a.24xlarge | 14 | 120 | 
| c7a.32xlarge | 14 | 120 | 
| c7a.48xlarge | 14 | 120 | 
| c7a.metal-48xl | 14 | 120 | 
| c7g.medium | 1 | 4 | 
| c7g.large | 2 | 10 | 
| c7g.xlarge | 3 | 20 | 
| c7g.2xlarge | 3 | 40 | 
| c7g.4xlarge | 7 | 60 | 
| c7g.8xlarge | 7 | 60 | 
| c7g.12xlarge | 7 | 60 | 
| c7g.16xlarge | 14 | 120 | 
| c7g.metal | 14 | 120 | 
| c7gd.medium | 1 | 4 | 
| c7gd.large | 2 | 10 | 
| c7gd.xlarge | 3 | 20 | 
| c7gd.2xlarge | 3 | 40 | 
| c7gd.4xlarge | 7 | 60 | 
| c7gd.8xlarge | 7 | 60 | 
| c7gd.12xlarge | 7 | 60 | 
| c7gd.16xlarge | 14 | 120 | 
| c7gd.metal | 14 | 120 | 
| c7gn.medium | 1 | 4 | 
| c7gn.large | 2 | 10 | 
| c7gn.xlarge | 3 | 20 | 
| c7gn.2xlarge | 3 | 40 | 
| c7gn.4xlarge | 7 | 60 | 
| c7gn.8xlarge | 7 | 60 | 
| c7gn.12xlarge | 7 | 60 | 
| c7gn.16xlarge | 14 | 120 | 
| c7gn.metal | 14 | 120 | 
| c7i.large | 2 | 10 | 
| c7i.xlarge | 3 | 20 | 
| c7i.2xlarge | 3 | 40 | 
| c7i.4xlarge | 7 | 60 | 
| c7i.8xlarge | 7 | 90 | 
| c7i.12xlarge | 7 | 120 | 
| c7i.16xlarge | 14 | 120 | 
| c7i.24xlarge | 14 | 120 | 
| c7i.48xlarge | 14 | 120 | 
| c7i.metal-24xl | 14 | 120 | 
| c7i.metal-48xl | 14 | 120 | 
| c7i-flex.large | 2 | 4 | 
| c7i-flex.xlarge | 3 | 10 | 
| c7i-flex.2xlarge | 3 | 20 | 
| c7i-flex.4xlarge | 7 | 40 | 
| c7i-flex.8xlarge | 7 | 60 | 
| c7i-flex.12xlarge | 7 | 120 | 
| c7i-flex.16xlarge | 14 | 120 | 
| c8a.medium | 1 | 4 | 
| c8a.large | 2 | 10 | 
| c8a.xlarge | 3 | 20 | 
| c8a.2xlarge | 3 | 40 | 
| c8a.4xlarge | 7 | 60 | 
| c8a.8xlarge | 9 | 90 | 
| c8a.12xlarge | 11 | 120 | 
| c8a.16xlarge | 15 | 120 | 
| c8a.24xlarge | 15 | 120 | 
| c8a.48xlarge | 23 | 120 | 
| c8a.metal-24xl | 15 | 120 | 
| c8a.metal-48xl | 23 | 120 | 
| c8g.medium | 1 | 4 | 
| c8g.large | 2 | 10 | 
| c8g.xlarge | 3 | 20 | 
| c8g.2xlarge | 3 | 40 | 
| c8g.4xlarge | 7 | 60 | 
| c8g.8xlarge | 7 | 60 | 
| c8g.12xlarge | 7 | 60 | 
| c8g.16xlarge | 14 | 120 | 
| c8g.24xlarge | 14 | 120 | 
| c8g.48xlarge | 14 | 120 | 
| c8g.metal-24xl | 14 | 120 | 
| c8g.metal-48xl | 14 | 120 | 
| c8gb.medium | 1 | 4 | 
| c8gb.large | 2 | 10 | 
| c8gb.xlarge | 3 | 20 | 
| c8gb.2xlarge | 3 | 40 | 
| c8gb.4xlarge | 7 | 60 | 
| c8gb.8xlarge | 9 | 60 | 
| c8gb.12xlarge | 11 | 60 | 
| c8gb.16xlarge | 15 | 120 | 
| c8gb.24xlarge | 23 | 120 | 
| c8gb.48xlarge | 23 | 120 | 
| c8gb.metal-24xl | 23 | 120 | 
| c8gb.metal-48xl | 23 | 120 | 
| c8gd.medium | 1 | 4 | 
| c8gd.large | 2 | 10 | 
| c8gd.xlarge | 3 | 20 | 
| c8gd.2xlarge | 3 | 40 | 
| c8gd.4xlarge | 7 | 60 | 
| c8gd.8xlarge | 7 | 60 | 
| c8gd.12xlarge | 7 | 60 | 
| c8gd.16xlarge | 14 | 120 | 
| c8gd.24xlarge | 14 | 120 | 
| c8gd.48xlarge | 14 | 120 | 
| c8gd.metal-24xl | 14 | 120 | 
| c8gd.metal-48xl | 14 | 120 | 
| c8gn.medium | 1 | 4 | 
| c8gn.large | 2 | 10 | 
| c8gn.xlarge | 3 | 20 | 
| c8gn.2xlarge | 3 | 40 | 
| c8gn.4xlarge | 7 | 60 | 
| c8gn.8xlarge | 9 | 60 | 
| c8gn.12xlarge | 11 | 60 | 
| c8gn.16xlarge | 15 | 120 | 
| c8gn.24xlarge | 23 | 120 | 
| c8gn.48xlarge | 23 | 120 | 
| c8gn.metal-24xl | 23 | 120 | 
| c8gn.metal-48xl | 23 | 120 | 
| c8i.large | 2 | 10 | 
| c8i.xlarge | 3 | 20 | 
| c8i.2xlarge | 3 | 40 | 
| c8i.4xlarge | 7 | 60 | 
| c8i.8xlarge | 9 | 90 | 
| c8i.12xlarge | 11 | 120 | 
| c8i.16xlarge | 15 | 120 | 
| c8i.24xlarge | 15 | 120 | 
| c8i.32xlarge | 23 | 120 | 
| c8i.48xlarge | 23 | 120 | 
| c8i.96xlarge | 23 | 120 | 
| c8i.metal-48xl | 23 | 120 | 
| c8i.metal-96xl | 23 | 120 | 
| c8id.large | 2 | 10 | 
| c8id.xlarge | 3 | 20 | 
| c8id.2xlarge | 3 | 40 | 
| c8id.4xlarge | 7 | 60 | 
| c8id.8xlarge | 9 | 90 | 
| c8id.12xlarge | 11 | 120 | 
| c8id.16xlarge | 15 | 120 | 
| c8id.24xlarge | 15 | 120 | 
| c8id.32xlarge | 23 | 120 | 
| c8id.48xlarge | 23 | 120 | 
| c8id.96xlarge | 23 | 120 | 
| c8gb.metal-48xl | 23 | 120 | 
| c8id.metal-96xl | 23 | 120 | 
| c8i-flex.large | 2 | 4 | 
| c8i-flex.xlarge | 3 | 10 | 
| c8i-flex.2xlarge | 3 | 20 | 
| c8i-flex.4xlarge | 7 | 40 | 
| c8i-flex.8xlarge | 9 | 60 | 
| c8i-flex.12xlarge | 11 | 120 | 
| c8i-flex.16xlarge | 15 | 120 | 

## Optimizada para memoria
<a name="eni-branch-mo"></a>


| Tipo de instancia | Límite de tareas sin enlace troncal de ENI | Límite de tareas con enlace troncal de ENI | 
| --- | --- | --- | 
| r5.large | 2 | 10 | 
| r5.xlarge | 3 | 20 | 
| r5.2xlarge | 3 | 40 | 
| r5.4xlarge | 7 | 60 | 
| r5.12xlarge | 7 | 60 | 
| r5.16xlarge | 14 | 120 | 
| r5.24xlarge | 14 | 120 | 
| r5a.large | 2 | 10 | 
| r5a.xlarge | 3 | 20 | 
| r5a.2xlarge | 3 | 40 | 
| r5a.4xlarge | 7 | 60 | 
| r5a.8xlarge | 7 | 60 | 
| r5a.12xlarge | 7 | 60 | 
| r5a.16xlarge | 14 | 120 | 
| r5a.24xlarge | 14 | 120 | 
| r5ad.large | 2 | 10 | 
| r5ad.xlarge | 3 | 20 | 
| r5ad.2xlarge | 3 | 40 | 
| r5ad.4xlarge | 7 | 60 | 
| r5ad.8xlarge | 7 | 60 | 
| r5ad.12xlarge | 7 | 60 | 
| r5ad.16xlarge | 14 | 120 | 
| r5ad.24xlarge | 14 | 120 | 
| r5b.16xlarge | 14 | 120 | 
| r5d.large | 2 | 10 | 
| r5d.xlarge | 3 | 20 | 
| r5d.2xlarge | 3 | 40 | 
| r5d.4xlarge | 7 | 60 | 
| r5d.8xlarge | 7 | 60 | 
| r5d.12xlarge | 7 | 60 | 
| r5d.16xlarge | 14 | 120 | 
| r5d.24xlarge | 14 | 120 | 
| r5dn.16xlarge | 14 | 120 | 
| r6a.large | 2 | 10 | 
| r6a.xlarge | 3 | 20 | 
| r6a.2xlarge | 3 | 40 | 
| r6a.4xlarge | 7 | 60 | 
| r6a.8xlarge | 7 | 90 | 
| r6a.12xlarge | 7 | 120 | 
| r6a.16xlarge | 14 | 120 | 
| r6a.24xlarge | 14 | 120 | 
| r6a.32xlarge | 14 | 120 | 
| r6a.48xlarge | 14 | 120 | 
| r6a.metal | 14 | 120 | 
| r6g.medium | 1 | 4 | 
| r6g.large | 2 | 10 | 
| r6g.xlarge | 3 | 20 | 
| r6g.2xlarge | 3 | 40 | 
| r6g.4xlarge | 7 | 60 | 
| r6g.8xlarge | 7 | 60 | 
| r6g.12xlarge | 7 | 60 | 
| r6g.16xlarge | 14 | 120 | 
| r6g.metal | 14 | 120 | 
| r6gd.medium | 1 | 4 | 
| r6gd.large | 2 | 10 | 
| r6gd.xlarge | 3 | 20 | 
| r6gd.2xlarge | 3 | 40 | 
| r6gd.4xlarge | 7 | 60 | 
| r6gd.8xlarge | 7 | 60 | 
| r6gd.12xlarge | 7 | 60 | 
| r6gd.16xlarge | 14 | 120 | 
| r6gd.metal | 14 | 120 | 
| r6i.large | 2 | 10 | 
| r6i.xlarge | 3 | 20 | 
| r6i.2xlarge | 3 | 40 | 
| r6i.4xlarge | 7 | 60 | 
| r6i.8xlarge | 7 | 90 | 
| r6i.12xlarge | 7 | 120 | 
| r6i.16xlarge | 14 | 120 | 
| r6i.24xlarge | 14 | 120 | 
| r6i.32xlarge | 14 | 120 | 
| r6i.metal | 14 | 120 | 
| r6id.large | 2 | 10 | 
| r6id.xlarge | 3 | 20 | 
| r6id.2xlarge | 3 | 40 | 
| r6id.4xlarge | 7 | 60 | 
| r6id.8xlarge | 7 | 90 | 
| r6id.12xlarge | 7 | 120 | 
| r6id.16xlarge | 14 | 120 | 
| r6id.24xlarge | 14 | 120 | 
| r6id.32xlarge | 14 | 120 | 
| r6id.metal | 14 | 120 | 
| r6idn.large | 2 | 10 | 
| r6idn.xlarge | 3 | 20 | 
| r6idn.2xlarge | 3 | 40 | 
| r6idn.4xlarge | 7 | 60 | 
| r6idn.8xlarge | 7 | 90 | 
| r6idn.12xlarge | 7 | 120 | 
| r6idn.16xlarge | 14 | 120 | 
| r6idn.24xlarge | 14 | 120 | 
| r6idn.32xlarge | 15 | 120 | 
| r6idn.metal | 15 | 120 | 
| r6in.large | 2 | 10 | 
| r6in.xlarge | 3 | 20 | 
| r6in.2xlarge | 3 | 40 | 
| r6in.4xlarge | 7 | 60 | 
| r6in.8xlarge | 7 | 90 | 
| r6in.12xlarge | 7 | 120 | 
| r6in.16xlarge | 14 | 120 | 
| r6in.24xlarge | 14 | 120 | 
| r6in.32xlarge | 15 | 120 | 
| r6in.metal | 15 | 120 | 
| r7a.medium | 1 | 4 | 
| r7a.large | 2 | 10 | 
| r7a.xlarge | 3 | 20 | 
| r7a.2xlarge | 3 | 40 | 
| r7a.4xlarge | 7 | 60 | 
| r7a.8xlarge | 7 | 90 | 
| r7a.12xlarge | 7 | 120 | 
| r7a.16xlarge | 14 | 120 | 
| r7a.24xlarge | 14 | 120 | 
| r7a.32xlarge | 14 | 120 | 
| r7a.48xlarge | 14 | 120 | 
| r7a.metal-48xl | 14 | 120 | 
| r7g.medium | 1 | 4 | 
| r7g.large | 2 | 10 | 
| r7g.xlarge | 3 | 20 | 
| r7g.2xlarge | 3 | 40 | 
| r7g.4xlarge | 7 | 60 | 
| r7g.8xlarge | 7 | 60 | 
| r7g.12xlarge | 7 | 60 | 
| r7g.16xlarge | 14 | 120 | 
| r7g.metal | 14 | 120 | 
| r7gd.medium | 1 | 4 | 
| r7gd.large | 2 | 10 | 
| r7gd.xlarge | 3 | 20 | 
| r7gd.2xlarge | 3 | 40 | 
| r7gd.4xlarge | 7 | 60 | 
| r7gd.8xlarge | 7 | 60 | 
| r7gd.12xlarge | 7 | 60 | 
| r7gd.16xlarge | 14 | 120 | 
| r7gd.metal | 14 | 120 | 
| r7i.large | 2 | 10 | 
| r7i.xlarge | 3 | 20 | 
| r7i.2xlarge | 3 | 40 | 
| r7i.4xlarge | 7 | 60 | 
| r7i.8xlarge | 7 | 90 | 
| r7i.12xlarge | 7 | 120 | 
| r7i.16xlarge | 14 | 120 | 
| r7i.24xlarge | 14 | 120 | 
| r7i.48xlarge | 14 | 120 | 
| r7i.metal-24xl | 14 | 120 | 
| r7i.metal-48xl | 14 | 120 | 
| r7iz.large | 2 | 10 | 
| r7iz.xlarge | 3 | 20 | 
| r7iz.2xlarge | 3 | 40 | 
| r7iz.4xlarge | 7 | 60 | 
| r7iz.8xlarge | 7 | 90 | 
| r7iz.12xlarge | 7 | 120 | 
| r7iz.16xlarge | 14 | 120 | 
| r7iz.32xlarge | 14 | 120 | 
| r7iz.metal-16xl | 14 | 120 | 
| r7iz.metal-32xl | 14 | 120 | 
| r8a.medium | 1 | 4 | 
| r8a.large | 2 | 10 | 
| r8a.xlarge | 3 | 20 | 
| r8a.2xlarge | 3 | 40 | 
| r8a.4xlarge | 7 | 60 | 
| r8a.8xlarge | 9 | 90 | 
| r8a.12xlarge | 11 | 120 | 
| r8a.16xlarge | 15 | 120 | 
| r8a.24xlarge | 15 | 120 | 
| r8a.48xlarge | 23 | 120 | 
| r8a.metal-24xl | 15 | 120 | 
| r8a.metal-48xl | 23 | 120 | 
| r8g.medium | 1 | 4 | 
| r8g.large | 2 | 10 | 
| r8g.xlarge | 3 | 20 | 
| r8g.2xlarge | 3 | 40 | 
| r8g.4xlarge | 7 | 60 | 
| r8g.8xlarge | 7 | 60 | 
| r8g.12xlarge | 7 | 60 | 
| r8g.16xlarge | 14 | 120 | 
| r8g.24xlarge | 14 | 120 | 
| r8g.48xlarge | 14 | 120 | 
| r8g.metal-24xl | 14 | 120 | 
| r8g.metal-48xl | 14 | 120 | 
| r8gb.medium | 1 | 4 | 
| r8gb.large | 2 | 10 | 
| r8gb.xlarge | 3 | 20 | 
| r8gb.2xlarge | 3 | 40 | 
| r8gb.4xlarge | 7 | 60 | 
| r8gb.8xlarge | 9 | 60 | 
| r8gb.12xlarge | 11 | 60 | 
| r8gb.16xlarge | 15 | 120 | 
| r8gb.24xlarge | 23 | 120 | 
| r8gb.48xlarge | 23 | 120 | 
| r8gb.metal-24xl | 23 | 120 | 
| r8gb.metal-48xl | 23 | 120 | 
| r8gd.medium | 1 | 4 | 
| r8gd.large | 2 | 10 | 
| r8gd.xlarge | 3 | 20 | 
| r8gd.2xlarge | 3 | 40 | 
| r8gd.4xlarge | 7 | 60 | 
| r8gd.8xlarge | 7 | 60 | 
| r8gd.12xlarge | 7 | 60 | 
| r8gd.16xlarge | 14 | 120 | 
| r8gd.24xlarge | 14 | 120 | 
| r8gd.48xlarge | 14 | 120 | 
| r8gd.metal-24xl | 14 | 120 | 
| r8gd.metal-48xl | 14 | 120 | 
| r8gn.medium | 1 | 4 | 
| r8gn.large | 2 | 10 | 
| r8gn.xlarge | 3 | 20 | 
| r8gn.2xlarge | 3 | 40 | 
| r8gn.4xlarge | 7 | 60 | 
| r8gn.8xlarge | 9 | 60 | 
| r8gn.12xlarge | 11 | 60 | 
| r8gn.16xlarge | 15 | 120 | 
| r8gn.24xlarge | 23 | 120 | 
| r8gn.48xlarge | 23 | 120 | 
| r8gn.metal-24xl | 23 | 120 | 
| r8gn.metal-48xl | 23 | 120 | 
| r8i.large | 2 | 10 | 
| r8i.xlarge | 3 | 20 | 
| r8i.2xlarge | 3 | 40 | 
| r8i.4xlarge | 7 | 60 | 
| r8i.8xlarge | 9 | 90 | 
| r8i.12xlarge | 11 | 120 | 
| r8i.16xlarge | 15 | 120 | 
| r8i.24xlarge | 15 | 120 | 
| r8i.32xlarge | 23 | 120 | 
| r8i.48xlarge | 23 | 120 | 
| r8i.96xlarge | 23 | 120 | 
| r8i.metal-48xl | 23 | 120 | 
| r8i.metal-96xl | 23 | 120 | 
| r8id.large | 2 | 10 | 
| r8id.xlarge | 3 | 20 | 
| r8id.2xlarge | 3 | 40 | 
| r8id.4xlarge | 7 | 60 | 
| r8id.8xlarge | 9 | 90 | 
| r8id.12xlarge | 11 | 120 | 
| r8id.16xlarge | 15 | 120 | 
| r8id.24xlarge | 15 | 120 | 
| r8id.32xlarge | 23 | 120 | 
| r8id.48xlarge | 23 | 120 | 
| r8id.96xlarge | 23 | 120 | 
| r8id.metal-48xl | 23 | 120 | 
| r8id.metal-96xl | 23 | 120 | 
| r8i-flex.large | 2 | 4 | 
| r8i-flex.xlarge | 3 | 10 | 
| r8i-flex.2xlarge | 3 | 20 | 
| r8i-flex.4xlarge | 7 | 40 | 
| r8i-flex.8xlarge | 9 | 60 | 
| r8i-flex.12xlarge | 11 | 120 | 
| r8i-flex.16xlarge | 15 | 120 | 
| u-3tb1.56xlarge | 7 | 12 | 
| u-6tb1.56xlarge | 14 | 12 | 
| u-18tb1.112xlarge | 14 | 12 | 
| u-18tb1.metal | 14 | 12 | 
| u-24tb1.112xlarge | 14 | 12 | 
| u-24tb1.metal | 14 | 12 | 
| u7i-6tb.112xlarge | 14 | 120 | 
| u7i-8tb.112xlarge | 14 | 120 | 
| u7i-12tb.224xlarge | 14 | 120 | 
| u7in-16tb.224xlarge | 15 | 120 | 
| u7in-24tb.224xlarge | 15 | 120 | 
| u7in-32tb.224xlarge | 15 | 120 | 
| u7inh-32tb.480xlarge | 15 | 120 | 
| x2gd.medium | 1 | 10 | 
| x2gd.large | 2 | 10 | 
| x2gd.xlarge | 3 | 20 | 
| x2gd.2xlarge | 3 | 40 | 
| x2gd.4xlarge | 7 | 60 | 
| x2gd.8xlarge | 7 | 60 | 
| x2gd.12xlarge | 7 | 60 | 
| x2gd.16xlarge | 14 | 120 | 
| x2gd.metal | 14 | 120 | 
| x2idn.16xlarge | 14 | 120 | 
| x2idn.24xlarge | 14 | 120 | 
| x2idn.32xlarge | 14 | 120 | 
| x2idn.metal | 14 | 120 | 
| x2iedn.xlarge | 3 | 13 | 
| x2iedn.2xlarge | 3 | 29 | 
| x2iedn.4xlarge | 7 | 60 | 
| x2iedn.8xlarge | 7 | 120 | 
| x2iedn.16xlarge | 14 | 120 | 
| x2iedn.24xlarge | 14 | 120 | 
| x2iedn.32xlarge | 14 | 120 | 
| x2iedn.metal | 14 | 120 | 
| x2iezn.2xlarge | 3 | 64 | 
| x2iezn.4xlarge | 7 | 120 | 
| x2iezn.6xlarge | 7 | 120 | 
| x2iezn.8xlarge | 7 | 120 | 
| x2iezn.12xlarge | 14 | 120 | 
| x2iezn.metal | 14 | 120 | 
| x8g.medium | 1 | 4 | 
| x8g.large | 2 | 10 | 
| x8g.xlarge | 3 | 20 | 
| x8g.2xlarge | 3 | 40 | 
| x8g.4xlarge | 7 | 60 | 
| x8g.8xlarge | 7 | 60 | 
| x8g.12xlarge | 7 | 60 | 
| x8g.16xlarge | 14 | 120 | 
| x8g.24xlarge | 14 | 120 | 
| x8g.48xlarge | 14 | 120 | 
| x8g.metal-24xl | 14 | 120 | 
| x8g.metal-48xl | 14 | 120 | 
| x8aedz.large | 3 | 10 | 
| x8aedz.xlarge | 3 | 20 | 
| x8aedz.3xlarge | 7 | 40 | 
| x8aedz.6xlarge | 7 | 60 | 
| x8aedz.12xlarge | 15 | 120 | 
| x8aedz.24xlarge | 15 | 120 | 
| x8aedz.metal-12xl | 15 | 120 | 
| x8aedz.metal-24xl | 15 | 120 | 
| x8i.large | 2 | 10 | 
| x8i.xlarge | 3 | 20 | 
| x8i.2xlarge | 3 | 40 | 
| x8i.4xlarge | 7 | 60 | 
| x8i.8xlarge | 9 | 90 | 
| x8i.12xlarge | 11 | 120 | 
| x8i.16xlarge | 15 | 120 | 
| x8i.24xlarge | 15 | 120 | 
| x8i.32xlarge | 23 | 120 | 
| x8i.48xlarge | 23 | 120 | 
| x8i.64xlarge | 23 | 120 | 
| x8i.96xlarge | 23 | 120 | 
| x8i.metal-48xl | 23 | 120 | 
| x8i.metal-96xl | 23 | 120 | 

## Optimizada para almacenamiento
<a name="eni-branch-so"></a>


| Tipo de instancia | Límite de tareas sin enlace troncal de ENI | Límite de tareas con enlace troncal de ENI | 
| --- | --- | --- | 
| i4g.large | 2 | 10 | 
| i4g.xlarge | 3 | 20 | 
| i4g.2xlarge | 3 | 40 | 
| i4g.4xlarge | 7 | 60 | 
| i4g.8xlarge | 7 | 60 | 
| i4g.16xlarge | 14 | 120 | 
| i4i.xlarge | 3 | 8 | 
| i4i.2xlarge | 3 | 28 | 
| i4i.4xlarge | 7 | 58 | 
| i4i.8xlarge | 7 | 118 | 
| i4i.12xlarge | 7 | 118 | 
| i4i.16xlarge | 14 | 248 | 
| i4i.24xlarge | 14 | 118 | 
| i4i.32xlarge | 14 | 498 | 
| i4i.metal | 14 | 498 | 
| i7i.large | 2 | 10 | 
| i7i.xlarge | 3 | 20 | 
| i7i.2xlarge | 3 | 40 | 
| i7i.4xlarge | 7 | 60 | 
| i7i.8xlarge | 7 | 90 | 
| i7i.12xlarge | 7 | 90 | 
| i7i.16xlarge | 14 | 120 | 
| i7i.24xlarge | 14 | 120 | 
| i7i.48xlarge | 14 | 120 | 
| i7i.metal-24xl | 14 | 120 | 
| i7i.metal-48xl | 14 | 120 | 
| i7ie.large | 2 | 20 | 
| i7ie.xlarge | 3 | 29 | 
| i7ie.2xlarge | 3 | 29 | 
| i7ie.3xlarge | 3 | 29 | 
| i7ie.6xlarge | 7 | 60 | 
| i7ie.12xlarge | 7 | 60 | 
| i7ie.18xlarge | 14 | 120 | 
| i7ie.24xlarge | 14 | 120 | 
| i7ie.48xlarge | 14 | 120 | 
| i7ie.metal-24xl | 14 | 120 | 
| i7ie.metal-48xl | 14 | 120 | 
| i8g.large | 2 | 10 | 
| i8g.xlarge | 3 | 20 | 
| i8g.2xlarge | 3 | 40 | 
| i8g.4xlarge | 7 | 60 | 
| i8g.8xlarge | 7 | 60 | 
| i8g.12xlarge | 7 | 60 | 
| i8g.16xlarge | 14 | 120 | 
| i8g.24xlarge | 14 | 120 | 
| i8g.48xlarge | 14 | 120 | 
| i8g.metal-24xl | 14 | 120 | 
| i8g.metal-48xl | 14 | 120 | 
| i8ge.large | 2 | 20 | 
| i8ge.xlarge | 3 | 29 | 
| i8ge.2xlarge | 3 | 29 | 
| i8ge.3xlarge | 5 | 29 | 
| i8ge.6xlarge | 9 | 60 | 
| i8ge.12xlarge | 11 | 60 | 
| i8ge.18xlarge | 15 | 120 | 
| i8ge.24xlarge | 15 | 120 | 
| i8ge.48xlarge | 23 | 120 | 
| i8ge.metal-24xl | 15 | 120 | 
| i8ge.metal-48xl | 23 | 120 | 
| im4gn.large | 2 | 10 | 
| im4gn.xlarge | 3 | 20 | 
| im4gn.2xlarge | 3 | 40 | 
| im4gn.4xlarge | 7 | 60 | 
| im4gn.8xlarge | 7 | 60 | 
| im4gn.16xlarge | 14 | 120 | 
| is4gen.medium | 1 | 4 | 
| is4gen.large | 2 | 10 | 
| is4gen.xlarge | 3 | 20 | 
| is4gen.2xlarge | 3 | 40 | 
| is4gen.4xlarge | 7 | 60 | 
| is4gen.8xlarge | 7 | 60 | 

## Computación acelerada
<a name="eni-branch-ac"></a>


| Tipo de instancia | Límite de tareas sin enlace troncal de ENI | Límite de tareas con enlace troncal de ENI | 
| --- | --- | --- | 
| dl1.24xlarge | 59 | 120 | 
| dl2q.24xlarge | 14 | 120 | 
| f2.6xlarge | 7 | 90 | 
| f2.12xlarge | 7 | 120 | 
| f2.48xlarge | 14 | 120 | 
| g4ad.xlarge | 1 | 12 | 
| g4ad.2xlarge | 1 | 12 | 
| g4ad.4xlarge | 2 | 12 | 
| g4ad.8xlarge | 3 | 12 | 
| g4ad.16xlarge | 7 | 12 | 
| g5.xlarge | 3 | 6 | 
| g5.2xlarge | 3 | 19 | 
| g5.4xlarge | 7 | 40 | 
| g5.8xlarge | 7 | 90 | 
| g5.12xlarge | 14 | 120 | 
| g5.16xlarge | 7 | 120 | 
| g5.24xlarge | 14 | 120 | 
| g5.48xlarge | 6 | 120 | 
| g5g.xlarge | 3 | 20 | 
| g5g.2xlarge | 3 | 40 | 
| g5g.4xlarge | 7 | 60 | 
| g5g.8xlarge | 7 | 60 | 
| g5g.16xlarge | 14 | 120 | 
| g5g.metal | 14 | 120 | 
| g6.xlarge | 3 | 20 | 
| g6.2xlarge | 3 | 40 | 
| g6.4xlarge | 7 | 60 | 
| g6.8xlarge | 7 | 90 | 
| g6.12xlarge | 7 | 120 | 
| g6.16xlarge | 14 | 120 | 
| g6.24xlarge | 14 | 120 | 
| g6.48xlarge | 14 | 120 | 
| g6e.xlarge | 3 | 20 | 
| g6e.2xlarge | 3 | 40 | 
| g6e.4xlarge | 7 | 60 | 
| g6g.8xlarge | 7 | 90 | 
| g6e.12xlarge | 9 | 120 | 
| g6e.16xlarge | 14 | 120 | 
| g6e.24xlarge | 19 | 120 | 
| g6e.48xlarge | 39 | 120 | 
| g6f.large | 1 | 10 | 
| g6f.xlarge | 3 | 20 | 
| g6f.2xlarge | 3 | 40 | 
| g6f.4xlarge | 7 | 60 | 
| gr6.4xlarge | 7 | 60 | 
| gr6.8xlarge | 7 | 90 | 
| gr6f.4xlarge | 7 | 60 | 
| g7e.2xlarge | 3 | 242 | 
| g7e.4xlarge | 7 | 242 | 
| g7g.8xlarge | 7 | 242 | 
| g7e.12xlarge | 9 | 242 | 
| g7e.24xlarge | 19 | 242 | 
| g7e.48xlarge | 39 | 242 | 
| inf2.xlarge | 3 | 20 | 
| inf2.8xlarge | 7 | 90 | 
| inf2.24xlarge | 14 | 120 | 
| inf2.48xlarge | 14 | 120 | 
| p4d.24xlarge | 59 | 120 | 
| p4de.24xlarge | 59 | 120 | 
| p5.4xlarge | 3 | 60 | 
| p5.48xlarge | 63 | 242 | 
| p5e.48xlarge | 63 | 242 | 
| p5en.48xlarge | 63 | 242 | 
| p6-b200.48xlarge | 31 | 242 | 
| p6-b300.48xlarge | 67 | 242 | 
| p6e-gb200.36xlarge | 38 | 120 | 
| trn1.2xlarge | 3 | 19 | 
| trn1.32xlarge | 39 | 120 | 
| trn1n.32xlarge | 79 | 242 | 
| trn2.3xlarge | 1 | 14 | 
| trn2.48xlarge | 31 | 242 | 
| trn2u.48xlarge | 31 | 242 | 
| vt1.3xlarge | 3 | 40 | 
| vt1.6xlarge | 7 | 60 | 
| vt1.24xlarge | 14 | 120 | 

## Computación de alto rendimiento
<a name="eni-branch-hpc"></a>


| Tipo de instancia | Límite de tareas sin enlace troncal de ENI | Límite de tareas con enlace troncal de ENI | 
| --- | --- | --- | 
| hpc6a.48xlarge | 1 | 120 | 
| hpc6id.32xlarge | 1 | 120 | 
| hpc7g.4xlarge | 3 | 120 | 
| hpc7g.8xlarge | 3 | 120 | 
| hpc7g.16xlarge | 3 | 120 | 
| hpc8a.96xlarge | 3 | -2 | 

# Reserva de la memoria de instancias de contenedor de Linux de Amazon ECS
<a name="memory-management"></a>

Cuando el agente de contenedor de Amazon ECS registra una instancia de contenedor en un clúster, el agente debe determinar la cantidad de memoria disponible que puede reservar la instancia de contenedor para las tareas. Debido a la sobrecarga de memoria de la plataforma y a la memoria ocupada por el kernel del sistema, este número difiere de la cantidad de memoria instalada que se anuncia para las instancias de Amazon EC2. Por ejemplo, una instancia `m4.large` tiene 8 GiB de memoria instalada. Sin embargo, esto no siempre significa que haya exactamente 8192 MiB de memoria disponible para las tareas cuando se registra la instancia de contenedor.

## Determinación de recursos de memoria de instancias administradas de ECS
<a name="ecs-mi-memory-calculation"></a>

Instancias administradas de Amazon ECS utiliza un enfoque jerárquico para determinar los requisitos de recursos de memoria para las tareas. A diferencia de ECS en EC2, que se basa en la introspección de memoria de Docker, instancias administradas de ECS calcula los requisitos de memoria directamente a partir de la carga útil de la tarea durante las decisiones de programación.

Cuando el agente de instancias administradas de ECS recibe una tarea, calcula las necesidades de memoria mediante el siguiente orden de prioridad:

1. **Memoria a nivel de tarea (máxima prioridad)**: si se especifica memoria a nivel de tarea en la definición de la tarea, el agente utiliza este valor directamente. Esto tiene prioridad sobre todos los ajustes de memoria a nivel de contenedor.

1. **Suma de memoria a nivel de contenedor (alternativa)**: si no se especifica la memoria a nivel de tarea (o es 0), el agente suma los requisitos de memoria de todos los contenedores de la tarea. Para cada contenedor, utiliza:

   1. *Reserva de memoria (límite flexible)*: si un contenedor especifica `memoryReservation` en su configuración, el agente usa este valor.

   1. *Memoria del contenedor (límite estricto)*: si `memoryReservation` no se especifica, el agente utiliza el campo `memory` del contenedor.

**Example Memoria a nivel de tarea especificada**  
Cuando se especifica la memoria a nivel de tarea, tiene prioridad sobre la configuración a nivel de contenedor:  

```
{
  "family": "my-task",
  "memory": "2048",
  "containerDefinitions": [
    {
      "name": "container1",
      "memory": 1024,
      "memoryReservation": 512
    }
  ]
}
```
El agente reserva 2048 MiB (la memoria a nivel de tarea tiene prioridad).

**Example Memoria a nivel de contenedor con reservas**  
Cuando no se especifica la memoria a nivel de tarea, el agente suma los requisitos de memoria del contenedor:  

```
{
  "family": "my-task",
  "containerDefinitions": [
    {
      "name": "container1",
      "memory": 1024,
      "memoryReservation": 512
    },
    {
      "name": "container2",
      "memory": 512
    }
  ]
}
```
El agente reserva 512 MiB (reserva de contenedor1) \$1 512 MiB (memoria de contenedor2) = 1024 MiB en total.

El agente de instancias administradas de ECS realiza el cálculo de la memoria en tres fases:

1. **Recepción de tareas**: cuando la carga útil de una tarea llega desde el plano de control del ECS, el agente calcula inmediatamente la memoria requerida.

1. **Almacenamiento de recursos**: el requisito de memoria calculado se almacena en el modelo de tareas para su uso posterior en las operaciones de contabilidad de recursos.

1. **Decisión de programación**: antes de aceptar una tarea, el agente comprueba si hay suficiente memoria disponible. Si no hay suficiente memoria disponible, la tarea se rechaza y permanece en la cola de servicios de ECS hasta que haya recursos disponibles.

**nota**  
A diferencia de ECS en EC2, instancias administradas de ECS no utiliza la variable de configuración `ECS_RESERVED_MEMORY`. La reserva de memoria para los procesos del sistema se gestiona mediante la administración de recursos de la plataforma subyacente, y el agente lleva a cabo una contabilidad precisa de los recursos en función de las definiciones de las tareas.

 Para ECS en EC2, el agente de contenedor de Amazon ECS proporciona una variable de configuración con el nombre `ECS_RESERVED_MEMORY`, que se puede utilizar para eliminar un número concreto de MiB de memoria del grupo asignado a las tareas. Este es un mecanismo eficaz que permite reservar memoria para los procesos críticos del sistema.

Si se ocupa toda la memoria de una instancia de contenedor con las tareas, es posible que las tareas compitan con los procesos críticos del sistema por la memoria y posiblemente inicien un error del sistema.

Por ejemplo, si se especifica `ECS_RESERVED_MEMORY=256` en el archivo de configuración del agente, el agente registrará la memoria total menos 256 MiB de esa instancia y las tareas de ECS no podrán asignar 256 MiB de memoria. Para obtener más información sobre las variables de configuración del agente y cómo definirlas, consulte [Configuración del agente de contenedor de Amazon ECS](ecs-agent-config.md) y [Arranque de instancias de contenedor de Linux de Amazon ECS para la transferencia de datos](bootstrap_container_instance.md).

Si especifica 8192 MiB para la tarea y ninguna de las instancias de contenedor tiene 8192 MiB o más de memoria disponible para satisfacer este requisito, la tarea no se puede ubicar en el clúster. Si utiliza un entorno informático administrado, AWS Batch debe iniciar un tipo de instancia de mayor tamaño para poder acomodar la solicitud.

El agente de contenedor de Amazon ECS utiliza la función `ReadMemInfo()` de Docker para consultar la memoria total disponible al sistema operativo. Tanto Linux como Windows cuentan con utilidades de línea de comandos para determinar la memoria total.

**Example - Determinar la memoria total en Linux**  
El comando **free** devuelve la memoria total reconocida por el sistema operativo.  

```
$ free -b
```
Ejemplo de la salida de una instancia `m4.large` que ejecuta la AMI de Amazon Linux optimizada para Amazon ECS.  

```
             total       used       free     shared    buffers     cached
Mem:    8373026816  348180480 8024846336      90112   25534464  205418496
-/+ buffers/cache:  117227520 8255799296
```
Esta instancia tiene 8 373 026 816 bytes de memoria total, lo que se traduce en 7 985 MiB disponibles para tareas.

**Example - Determinar la memoria total en Windows**  
El comando **wmic** devuelve la memoria total reconocida por el sistema operativo.  

```
C:\> wmic ComputerSystem get TotalPhysicalMemory
```
Ejemplo de la salida de una instancia `m4.large` que ejecuta la AMI de Windows Server optimizada para Amazon ECS.  

```
TotalPhysicalMemory
8589524992
```
Esta instancia tiene 8 589 524 992 bytes de memoria total, lo que se traduce en 8 191 MiB disponibles para tareas.

## Visualización de la memoria de instancias de contenedor
<a name="viewing-memory"></a>

Puede consultar la cantidad de memoria que registra una instancia de contenedor a través de la consola de Amazon ECS (o mediante la operación de la API [DescribeContainerInstances](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeContainerInstances.html)). Si, para intentar maximizar el uso de recursos, proporciona la mayor cantidad de memoria posible a las tareas para un determinado tipo de instancia, puede observar la memoria disponible para esa instancia de contenedor y, a continuación, asignar a las tareas esa cantidad de memoria.

**Visualización de la memoria de la instancia de contenedor**

1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. En el panel de navegación, seleccione **Clústeres** y elija el clúster que aloja su instancia de contenedor.

1. Elija **Infraestructura** y, a continuación, en Instancias de contenedor, elija una instancia de contenedor.

1. En la sección **Recursos**, se muestra la memoria registrada y la memoria disponible para la instancia de contenedor.

   El valor del campo **Registrada** corresponde a la memoria que la instancia de contenedor registró en Amazon ECS cuando se inició por primera vez, mientras que el valor del campo **Disponible** corresponde a la memoria que aún no se ha asignado a ninguna tarea.

# Administración remota de instancias de contenedor de Amazon ECS mediante AWS Systems Manager
<a name="ec2-run-command"></a>

Puede utilizar la función Run Command de AWS Systems Manager (Systems Manager) para administrar la configuración de las instancias de contenedor de Amazon ECS de forma segura y remota. Run Command proporciona una manera sencilla de realizar tareas administrativas comunes sin necesidad de iniciar sesión localmente en la instancia. Puede administrar cambios de configuración en los clústeres ejecutando comandos simultáneamente en varias instancia de contenedor. Ejecutar comando notifica el estado y los resultados de cada comando.

Aquí tiene algunos ejemplos de los tipos de tareas que puede llevar a cabo con Ejecutar comando:
+ Instalar o desinstalar paquetes.
+ Realizar actualizaciones de seguridad.
+ Limpiar imágenes de Docker.
+ Parar o comenzar servicios.
+ Ver recursos del sistema.
+ Ver archivos de registro.
+ Realizar operaciones de archivo.

Para obtener más información acerca de Run Command, consulte [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html) en la *Guía del usuario de AWS Systems Manager*.

A continuación, se indican los son requisitos previos para usar Systems Manager con Amazon ECS.

1. Debe conceder permisos al rol de instancia de contenedor (**ecsInstanceRole**) para acceder a las API de Systems Manager. Para ello, asigne **AmazonSSMManagedInstanceCore** al rol `ecsInstanceRole`. Para obtener información acerca de cómo asociar una política a un rol, consulte [Actualización de los permisos de un rol](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-permissions.html) en la *Guía del usuario de AWS Identity and Access Management*.

1. Compruebe que SSM Agent esté instalado en las instancias del contenedor. Para obtener más información, consulte [Instalación y desinstalación manual de SSM Agent en instancias EC2 para Linux](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html).

Después de asociar políticas administradas de Systems Manager al `ecsInstanceRole` y de verificar que el agente de AWS Systems Manager (SSM Agent) esté instalado en las instancias de contenedor, puede comenzar a utilizar Run Command para enviar comandos a las instancias de contenedor. Para obtener información acerca de la ejecución de comandos y scripts del shell en las instancias y la visualización del resultado obtenido, consulte [Ejecución de comandos mediante Run Command de Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html) y [Explicaciones sobre Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command-walkthroughs.html) en la *Guía del usuario de AWS Systems Manager.* 

Un caso de uso común es actualizar el software de la instancia de contenedor con Run Command. Puede seguir los procedimientos de la Guía del usuario de AWS Systems Manager con los siguientes parámetros.


| Parámetro | Valor | 
| --- | --- | 
|  **Documento de comandos**  | AWS-RunShellScript | 
| Comando |  <pre>$ yum update -y</pre> | 
| Instancias de destino | Sus instancias de contenedor | 

# Uso de un proxy HTTP para instancias de contenedor de Linux de Amazon ECS
<a name="http_proxy_config"></a>

Puede configurar las instancias de contenedor de Amazon ECS para que utilicen un proxy HTTP tanto para el agente de contenedor de Amazon ECS como para el daemon de Docker. Esto resulta útil si las instancias de contenedor no tienen acceso de red externo a través de una gateway de Internet de Amazon VPC, una gateway NAT o una instancia. 

Para configurar la instancia de contenedor de Linux de Amazon ECS de modo que utilice un proxy HTTP, establezca las siguientes variables en los archivos correspondiente en el momento del lanzamiento (con datos de usuario de Amazon EC2). También puede editar manualmente el archivo de configuración y, a continuación, reiniciar el agente.

`/etc/ecs/ecs.config` (AMI de Amazon Linux y Amazon Linux 2)    
`HTTP_PROXY=10.0.0.131:3128`  
Establezca este valor en el nombre de host (o dirección IP) y en el número de puerto de un proxy HTTP que se utilizará para que el agente de Amazon ECS se conecte a Internet. Por ejemplo, las instancias de contenedor podrían no tener acceso de red externo a través de una gateway de Internet de Amazon VPC, una gateway NAT o una instancia.  
`NO_PROXY=169.254.169.254,169.254.170.2,/var/run/docker.sock`  
Establezca este valor en `169.254.169.254,169.254.170.2,/var/run/docker.sock` para filtrar los metadatos de las instancias EC2, los roles de IAM para tareas y el tráfico del daemon de Docker procedente del proxy. 

`/etc/systemd/system/ecs.service.d/http-proxy.conf` (Amazon Linux 2 solamente)    
`Environment="HTTP_PROXY=10.0.0.131:3128/"`  
Establezca este valor en el nombre de host (o dirección IP) y en el número de puerto de un proxy HTTP que desee utilizar para que `ecs-init` se conecte a Internet. Por ejemplo, las instancias de contenedor podrían no tener acceso de red externo a través de una gateway de Internet de Amazon VPC, una gateway NAT o una instancia.  
`Environment="NO_PROXY=169.254.169.254,169.254.170.2,/var/run/docker.sock"`  
Establezca este valor en `169.254.169.254,169.254.170.2,/var/run/docker.sock` para filtrar los metadatos de las instancias EC2, los roles de IAM para tareas y el tráfico del daemon de Docker procedente del proxy. 

`/etc/init/ecs.override` (AMI de Amazon Linux solamente)    
`env HTTP_PROXY=10.0.0.131:3128`  
Establezca este valor en el nombre de host (o dirección IP) y en el número de puerto de un proxy HTTP que desee utilizar para que `ecs-init` se conecte a Internet. Por ejemplo, las instancias de contenedor podrían no tener acceso de red externo a través de una gateway de Internet de Amazon VPC, una gateway NAT o una instancia.  
`env NO_PROXY=169.254.169.254,169.254.170.2,/var/run/docker.sock`  
Establezca este valor en `169.254.169.254,169.254.170.2,/var/run/docker.sock` para filtrar los metadatos de las instancias EC2, los roles de IAM para tareas y el tráfico del daemon de Docker procedente del proxy. 

`/etc/systemd/system/docker.service.d/http-proxy.conf` (Amazon Linux 2 solamente)    
`Environment="HTTP_PROXY=http://10.0.0.131:3128"`  
Establezca este valor en el nombre de host (o dirección IP) y en el número de puerto de un proxy HTTP que utilizar para que el daemon de Docker se conecte a Internet. Por ejemplo, las instancias de contenedor podrían no tener acceso de red externo a través de una gateway de Internet de Amazon VPC, una gateway NAT o una instancia.  
`Environment="NO_PROXY=169.254.169.254,169.254.170.2"`  
Establezca este valor en `169.254.169.254,169.254.170.2` para filtrar metadatos de instancia EC2 desde el proxy. 

`/etc/sysconfig/docker` (solo AMI de Amazon Linux y Amazon Linux 2)    
`export HTTP_PROXY=http://10.0.0.131:3128`  
Establezca este valor en el nombre de host (o dirección IP) y en el número de puerto de un proxy HTTP que utilizar para que el daemon de Docker se conecte a Internet. Por ejemplo, las instancias de contenedor podrían no tener acceso de red externo a través de una gateway de Internet de Amazon VPC, una gateway NAT o una instancia.  
`export NO_PROXY=169.254.169.254,169.254.170.2`  
Establezca este valor en `169.254.169.254,169.254.170.2` para filtrar metadatos de instancia EC2 desde el proxy. 

Establecer estas variables de entorno en los archivos anteriores solo afecta al agente de contenedor de Amazon ECS, a `ecs-init` y al daemon de Docker. No configuran ningún otro servicio (como **yum**) para que utilice el proxy.

Para obtener información sobre cómo configurar el proxy, consulte [How do I set up an HTTP proxy for Docker and the Amazon ECS container agent in Amazon Linux 2 or AL2023](https://repost.aws/knowledge-center/ecs-http-proxy-docker-linux2).

# Configuración de instancias preinicializadas para el grupo de escalado automático de Amazon ECS
<a name="using-warm-pool"></a>

Amazon ECS admite grupos de calentamiento de Amazon EC2 Auto Scaling. Un grupo de calentamiento es un grupo de Amazon EC2 instances (Instancias de Amazon EC2) inicializadas previamente listas para ponerse en servicio. Siempre que su aplicación necesita escalar horizontalmente, Amazon EC2 Auto Scaling utiliza las instancias preinicializadas del grupo de calentamiento en lugar de lanzar instancias en frío, permite ejecutar cualquier proceso de inicialización final y, a continuación, pone la instancia en servicio.

Para obtener más información sobre grupos de calentamiento y cómo agregar un grupo de calentamiento a un grupo de Auto Scaling, consulte [Grupos de calentamiento para Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-warm-pools.html) *en la Guía del usuario de Amazon EC2 Auto Scaling*.

Cuando se crea o actualiza un grupo de calentamiento para un grupo de escalado automático para Amazon ECS, no se puede configurar la opción que devuelve las instancias al grupo de calentamiento al reducir horizontalmente (`ReuseOnScaleIn`). Para obtener más información, consulte [put-warm-pool](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-warm-pool.html) en la *Referencia de AWS Command Line Interface*.

Para utilizar los grupos de calentamiento con su clúster de Amazon ECS, establezca la variable de configuración del agente `ECS_WARM_POOLS_CHECK` en `true` en el campo **User data** (Datos de usuario) de la plantilla de lanzamiento del grupo de Amazon EC2 Auto Scaling. 

A continuación, mostramos un ejemplo de cómo se puede especificar la variable de configuración en el campo **User data** (Datos de usuario) de una plantilla de lanzamiento de Amazon EC2. Reemplace *MyCluster* por el nombre del clúster.

```
#!/bin/bash
cat <<'EOF' >> /etc/ecs/ecs.config
ECS_CLUSTER=MyCluster
ECS_WARM_POOLS_CHECK=true
EOF
```

Esta variable `ECS_WARM_POOLS_CHECK` solo se admite en versiones de agente `1.59.0` y posterior. Para obtener más información sobre la variable, consulte [Configuración del agente de contenedor de Amazon ECS](ecs-agent-config.md).

# Actualización del agente de contenedor de Amazon ECS
<a name="ecs-agent-update"></a>

Ocasionalmente, es posible que tenga que actualizar el agente de contenedor de Amazon ECS para obtener correcciones de errores y nuevas características. La actualización del agente de contenedor de Amazon ECS no interrumpe las tareas ni los servicios en marcha en la instancia de contenedor. El proceso de actualización del agente difiere en función de si la instancia de contenedor se lanzó con una AMI optimizada para Amazon ECS u otro sistema operativo.

**nota**  
Las actualizaciones del agente no se aplican a instancias de contenedor de Windows. Le recomendamos que lance nuevas instancias de contenedor para actualizar la versión del agente en sus clústeres Windows.

## Comprobación de la versión del agente de contenedor de Amazon ECS
<a name="checking_agent_version"></a>

Puede comprobar la versión del agente de contenedor que se está ejecutando en sus instancias de contenedor para ver si necesita actualizarlo. La vista de la instancia de contenedor en la consola de Amazon ECS proporciona la versión del agente. Utilice el siguiente procedimiento para comprobar la versión del agente.

------
#### [ Amazon ECS console ]

1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. En la barra de navegación, elija la región en la que se encuentra registrada la instancia externa.

1. En el panel de navegación, elija **Clusters** (Clústeres) y seleccione el clúster que aloja la instancia externa.

1. En la página de **Cluster : *name*** (Clúster; nombre), elija la pestaña **Infrastructure** (Infraestructura).

1. En **Container instances** (Instancias de contenedor), tenga en cuenta la columna **Agent version** (Versión de agente) para sus instancias de contenedor. Si la instancia de contenedor no contiene la versión más reciente del agente de contenedor, la consola genera un mensaje de alerta y marca la versión del agente obsoleta.

   Si la versión de su agente está desactualizada, puede actualizar el agente de contenedor con los siguientes procedimientos:
   + Si la instancia de contenedor está ejecutando una AMI optimizada para Amazon ECS, consulte [Actualización del agente de contenedor de Amazon ECS en una AMI optimizada para Amazon ECS](agent-update-ecs-ami.md).
   + Si la instancia de contenedor no está ejecutando una AMI optimizada para Amazon ECS, consulte [Actualización manual del agente de contenedor de Amazon ECS (para AMI no optimizadas para Amazon ECS)](manually_update_agent.md).
**importante**  
Para actualizar la versión del agente de Amazon ECS de versiones anteriores a la v1.0.0 en la AMI optimizada para Amazon ECS, le recomendamos que termine la instancia de contenedor actual y lance una instancia nueva con la versión de la AMI más reciente. Cualquier instancia de contenedor que utilice una versión de vista previa se debe retirar y sustituir por la AMI más reciente. Para obtener más información, consulte [Lanzamiento de una instancia de contenedor de Linux de Amazon ECS](launch_container_instance.md).

------
#### [ Amazon ECS container agent introspection API  ]

También puede utilizar la API de introspección del agente de contenedor de Amazon ECS para comprobar la versión del agente desde la propia instancia de contenedor. Para obtener más información, consulte [Introspección de contenedor de Amazon ECS](ecs-agent-introspection.md).

**Para comprobar si el agente de contenedor de Amazon ECS ejecuta la versión más reciente a través de la API de introspección**

1. Inicie sesión en su instancia de contenedor mediante SSH.

1. Consulte la API de introspección.

   ```
   [ec2-user ~]$ curl -s 127.0.0.1:51678/v1/metadata | python3 -mjson.tool
   ```
**nota**  
La API de introspección agregó información de `Version` en la versión v1.0.0 del agente de contenedor de Amazon ECS. Si no tiene `Version` a la hora de consultar la API de introspección o la API de introspección no está presente en el agente en absoluto, entonces la versión que ejecuta es v0.0.3 o anterior. Debería actualizar la versión.

------

# Actualización del agente de contenedor de Amazon ECS en una AMI optimizada para Amazon ECS
<a name="agent-update-ecs-ami"></a>

Si está utilizando la AMI optimizada para Amazon ECS, dispone de varias opciones para obtener la versión más reciente del agente de contenedor de Amazon ECS (se muestran por orden de recomendación):
+ Termine las instancias de contenedor actuales y lance la versión más reciente de la AMI de Amazon Linux 2 optimizada para Amazon ECS (ya sea manualmente o actualizando la configuración de lanzamiento de Auto Scaling con la AMI más reciente). Esto proporciona una instancia de contenedor nueva con las versiones probadas y validadas más recientes de Amazon Linux, Docker, `ecs-init` y el agente de contenedor de Amazon ECS. Para obtener más información, consulte [AMI de Linux optimizadas para Amazon ECS](ecs-optimized_AMI.md).
+ Conecte a la instancia con SSH y actualice el paquete `ecs-init` (y sus dependencias) a la versión más reciente. Esta operación ofrece las versiones probadas y validadas más recientes de Docker y `ecs-init` que están disponibles en los repositorios de Amazon Linux, así como la versión más reciente del agente de contenedor de Amazon ECS. Para obtener más información, consulte [Para actualizar el paquete `ecs-init` en la AMI optimizada para Amazon ECS](#procedure_update_ecs-init).
+ Actualice el agente de contenedor con la operación `UpdateContainerAgent` de la API, ya sea a través de la consola, con la AWS CLI o con los SDK de AWS. Para obtener más información, consulte [Actualización del agente de contenedor de Amazon ECS mediante la operación de la API `UpdateContainerAgent`](#agent-update-api).

**nota**  
Las actualizaciones del agente no se aplican a instancias de contenedor de Windows. Le recomendamos que lance nuevas instancias de contenedor para actualizar la versión del agente en sus clústeres Windows.<a name="procedure_update_ecs-init"></a>

**Para actualizar el paquete `ecs-init` en la AMI optimizada para Amazon ECS**

1. Inicie sesión en su instancia de contenedor mediante SSH.

1. Actualice el paquete `ecs-init` con el siguiente comando.

   ```
   sudo yum update -y ecs-init
   ```
**nota**  
El paquete `ecs-init` y el agente de contenedor de Amazon ECS se actualizan de forma inmediata. Sin embargo, las versiones más recientes de Docker no se cargan hasta que se reinicia el daemon de Docker. Para efectuar el reinicio, puede reiniciar la instancia o ejecutar los siguientes comandos en su instancia:  
AMI de Amazon Linux 2 optimizada para Amazon ECS:  

     ```
     sudo systemctl restart docker
     ```
AMI de Amazon Linux optimizada para Amazon ECS:  

     ```
     sudo service docker restart && sudo start ecs
     ```

## Actualización del agente de contenedor de Amazon ECS mediante la operación de la API `UpdateContainerAgent`
<a name="agent-update-api"></a>

**importante**  
La API `UpdateContainerAgent` solo se admite en variantes de Linux de la AMI optimizada para Amazon ECS, a excepción de la AMI de Amazon Linux 2 (arm64) optimizada para Amazon ECS. Para instancias de contenedor que utilizan la AMI de Amazon Linux 2 (arm64) optimizada para Amazon ECS, actualice el paquete `ecs-init` para actualizar el agente. Para instancias de contenedor que están ejecutando otros sistemas operativos, consulte [Actualización manual del agente de contenedor de Amazon ECS (para AMI no optimizadas para Amazon ECS)](manually_update_agent.md). Si utiliza instancias de contenedor de Windows, le recomendamos que lance nuevas instancias de contenedor para actualizar la versión del agente en los clústeres Windows.

El proceso de la API `UpdateContainerAgent` comienza cuando solicita una actualización del agente, ya sea a través de la consola o con la AWS CLI o los SDK de AWS. Amazon ECS compara la versión actual del agente con la versión del agente más reciente disponible y si es posible una actualización. Si no es posible una actualización, por ejemplo, si el agente ya está ejecutando la versión más reciente, se devuelve `NoUpdateAvailableException`.

Las fases en el proceso de actualización mostradas más arriba son las siguientes:

`PENDING`  
Hay una actualización de agente disponible y el proceso de actualización se ha iniciado.

`STAGING`  
El agente ha comenzado a descargar la actualización del agente. Si el agente no puede descargar la actualización o si el contenido de la actualización es incorrecto o está dañada, entonces el agente envía una notificación del error y la actualización pasa al estado `FAILED`.

`STAGED`  
La descarga del agente se ha completado y se ha verificado el contenido del agente.

`UPDATING`  
El servicio `ecs-init` se reinicia y recoge la nueva versión del agente. Si, por alguna razón, el agente no puede reiniciarse, la actualización pasa al estado `FAILED`; de lo contrario, el agente indica a Amazon ECS que la actualización está completa.

**nota**  
Las actualizaciones del agente no se aplican a instancias de contenedor de Windows. Le recomendamos que lance nuevas instancias de contenedor para actualizar la versión del agente en sus clústeres Windows.

**Para actualizar el agente de contenedor de Amazon ECS en una AMI optimizada para Amazon ECS desde la consola**

1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. En la barra de navegación, elija la región en la que se encuentra registrada la instancia externa.

1. En el panel de navegación, elija **Clusters** y seleccione el clúster.

1. En la página de **Cluster : *name*** (Clúster; nombre), elija la pestaña **Infrastructure** (Infraestructura).

1. En **Instancias de contenedor**, seleccione las instancias que desea actualizar y, a continuación, elija **Acciones**, **Actualización del agente**.

# Actualización manual del agente de contenedor de Amazon ECS (para AMI no optimizadas para Amazon ECS)
<a name="manually_update_agent"></a>

Ocasionalmente, es posible que tenga que actualizar el agente de contenedor de Amazon ECS para obtener correcciones de errores y nuevas características. La actualización del agente de contenedor de Amazon ECS no interrumpe las tareas ni los servicios en marcha en la instancia de contenedor.
**nota**  
Las actualizaciones del agente no se aplican a instancias de contenedor de Windows. Le recomendamos que lance nuevas instancias de contenedor para actualizar la versión del agente en sus clústeres Windows.

1. Inicie sesión en su instancia de contenedor mediante SSH.

1. Compruebe si su agente utiliza la variable de entorno `ECS_DATADIR` para guardar su estado.

   ```
   ubuntu:~$ docker inspect ecs-agent | grep ECS_DATADIR
   ```

   Salida:

   ```
   "ECS_DATADIR=/data",
   ```
**importante**  
Si el comando anterior no devuelve la variable de entorno `ECS_DATADIR`, debe detener las tareas en ejecución en esta instancia de contenedor antes de actualizar el agente. Los agentes más recientes con la variable de entorno `ECS_DATADIR` guardan su estado y usted puede actualizarlos mientras que las tareas se ejecuten sin problemas.

1. Detenga el agente de contenedor de Amazon ECS.

   ```
   ubuntu:~$ docker stop ecs-agent
   ```

1. Elimine el contenedor de agente.

   ```
   ubuntu:~$ docker rm ecs-agent
   ```

1. Asegúrese de que el directorio `/etc/ecs` y el archivo de configuración del agente de contenedor de Amazon ECS existan en `/etc/ecs/ecs.config`.

   ```
   ubuntu:~$ sudo mkdir -p /etc/ecs && sudo touch /etc/ecs/ecs.config
   ```

1. Edite el archivo `/etc/ecs/ecs.config` y asegúrese de que contenga al menos las siguientes declaraciones de variables. Si no desea que su instancias de contenedor se registre en el clúster predeterminado, especifique el nombre del clúster como el valor para `ECS_CLUSTER`.

   ```
   ECS_DATADIR=/data
   ECS_ENABLE_TASK_IAM_ROLE=true
   ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=true
   ECS_LOGFILE=/log/ecs-agent.log
   ECS_AVAILABLE_LOGGING_DRIVERS=["json-file","awslogs"]
   ECS_LOGLEVEL=info
   ECS_CLUSTER=default
   ```

   Para obtener más información acerca de estas y otras opciones de tiempo de ejecución de agente, consulte [Configuración del agente de contenedor de Amazon ECS](ecs-agent-config.md).
**nota**  
Si lo desea, puede almacenar las variables de entorno del agente en Amazon S3 (se pueden descargar en las instancias de contenedor en el momento del lanzamiento utilizando datos de usuario de Amazon EC2). Se recomienda su uso para información confidencial como las credenciales de autenticación para repositorios privados. Para obtener más información, consulte [Almacenamiento de la configuración de instancia de contenedor de Amazon ECS en Amazon S3](ecs-config-s3.md) y [Uso de imágenes de contenedor que no sean de AWS en Amazon ECS](private-auth.md).

1. Extraiga la imagen más reciente del agente de contenedor de Amazon ECS de Amazon Elastic Container Registry Public.

   ```
   ubuntu:~$ docker pull public.ecr.aws/ecs/amazon-ecs-agent:latest
   ```

   Salida:

   ```
   Pulling repository amazon/amazon-ecs-agent
   a5a56a5e13dc: Download complete
   511136ea3c5a: Download complete
   9950b5d678a1: Download complete
   c48ddcf21b63: Download complete
   Status: Image is up to date for amazon/amazon-ecs-agent:latest
   ```

1. Ejecute el agente de contenedor de Amazon ECS más reciente en la instancia de contenedor.
**nota**  
Utilice las políticas de reinicio de Docker o un administrador de procesos (como **upstart** o **systemd**) para tratar al agente de contenedor como un servicio o un daemon y asegurarse de que se reinicie después de finalizar su ejecución. Para eso, la AMI optimizada para Amazon ECS utiliza el RPM `ecs-init`, y puede consultar el [código fuente para este RPM](https://github.com/aws/amazon-ecs-init) en GitHub. 

   En el siguiente ejemplo, el comando de ejecución del agente está dividido en líneas separadas para mostrar cada opción. Para obtener más información acerca de estas y otras opciones de tiempo de ejecución de agente, consulte [Configuración del agente de contenedor de Amazon ECS](ecs-agent-config.md).
**importante**  
Los sistemas operativos con SELinux habilitado requieren la opción `--privileged` en el comando **docker run**. Además, para las instancias de contenedor con SELinux habilitado, recomendamos añadir la opción `:Z` a los montajes de volúmenes `/log` y `/data`. No obstante, los montajes de hosts para estos volúmenes deben existir antes de que ejecute el comando; de lo contrario, recibirá un error `no such file or directory`. Realice la siguiente acción si tiene dificultades para ejecutar el agente de Amazon ECS en una instancia de contenedor con SELinux habilitado:  
Cree los puntos de montaje de volumen del host en su instancia de contenedor.  

     ```
     ubuntu:~$ sudo mkdir -p /var/log/ecs /var/lib/ecs/data
     ```
Añada la opción `--privileged` al siguiente comando **docker run**.
Añada la opción `:Z` a los montajes del volumen de contenedor `/log` y `/data` (por ejemplo, `--volume=/var/log/ecs/:/log:Z`) para el siguiente comando **docker run**.

   ```
   ubuntu:~$ sudo docker run --name ecs-agent \
   --detach=true \
   --restart=on-failure:10 \
   --volume=/var/run:/var/run \
   --volume=/var/log/ecs/:/log \
   --volume=/var/lib/ecs/data:/data \
   --volume=/etc/ecs:/etc/ecs \
   --volume=/etc/ecs:/etc/ecs/pki \
   --net=host \
   --env-file=/etc/ecs/ecs.config \
   amazon/amazon-ecs-agent:latest
   ```
**nota**  
Si recibe el mensaje `Error response from daemon: Cannot start container`, puede eliminar el contenedor con errores con el comando **sudo docker rm ecs-agent** e intentar volver a ejecutar el agente. 

# AMI de Windows optimizadas para Amazon ECS
<a name="ecs-optimized_windows_AMI"></a>

Las AMI optimizadas para Amazon ECS están preconfiguradas con los componentes necesarios para ejecutar cargas de trabajo de Amazon ECS. Aunque puede crear su propia AMI de instancia de contenedor que cumpla con las especificaciones básicas necesarias para ejecutar las cargas de trabajo en contenedores en Amazon ECS, la preconfiguración y la prueba de las AMI optimizadas para Amazon ECS la realizan los ingenieros de AWS en Amazon ECS. Es la forma más sencilla para empezar y para conseguir que los contenedores funcionen en AWS rápidamente.

Los metadatos de la AMI optimizada para Amazon ECS de cada variante, incluidos el nombre de la AMI, la versión del agente de contenedor de Amazon ECS y la versión del tiempo de ejecución de Amazon ECS que incluye la versión de Docker, se pueden recuperar mediante programación. Para obtener más información, consulte [Recuperación de metadatos de las AMI de Windows optimizadas para Amazon ECS](retrieve-ecs-optimized_windows_AMI.md).

**importante**  
 Todas las variantes de AMI optimizadas para ECS producidas después de agosto de 2022 migrarán de Docker EE (Mirantis) a Docker CE (proyecto Moby).  
Para asegurarse de que los clientes disponen de las actualizaciones de seguridad más recientes de forma predeterminada, Amazon ECS mantiene al menos las últimas tres AMI de Windows optimizada para Amazon ECS. Después de lanzar nuevas AMI de Windows optimizadas para Amazon ECS, Amazon ECS convierte en privadas las AMI de Windows optimizadas para Amazon ECS más antiguas. Para informarnos que necesita obtener acceso a una AMI privada, envíe un ticket al equipo de Cloud Support.

## Variantes de AMI optimizadas para Amazon ECS
<a name="ecs-optimized-ami-variants"></a>

Las siguientes variantes de Windows Server de la AMI optimizada para Amazon ECS están disponibles para las instancias de Amazon EC2.

**importante**  
Todas las variantes de AMI optimizadas para ECS producidas después de agosto migrarán de Docker EE (Mirantis) a Docker CE (proyecto Moby).
+ **AMI de Windows Server 2025 Full optimizada para Amazon ECS** 
+ **AMI de Windows Server 2025 Core optimizada para Amazon ECS** 
+ **AMI de Windows Server 2022 Full optimizada para Amazon ECS** 
+ **AMI de Windows Server 2022 Core optimizada para Amazon ECS** 
+ **AMI de Windows Server 2019 Full optimizada para Amazon ECS** 
+ **AMI de Windows Server 2019 Core optimizada para Amazon ECS** 
+ **AMI de Windows Server 2016 Full optimizada para Amazon ECS**

**importante**  
Windows Server 2016 no es compatible con la última versión de Docker, por ejemplo, la 25.x.x. Por lo tanto, las AMI completas de Windows Server 2016 no recibirán parches de seguridad o de errores en el entorno en tiempo de ejecución de Docker. Le recomendamos que cambie a una de las siguientes plataformas de Windows:  
Windows Server 2022 Full
Windows Server 2022 Core
Windows Server 2019 Full
Windows Server 2019 Core

El 9 de agosto de 2022, la AMI de Windows Server 20H2 Core optimizada para Amazon ECS llegó a su fecha de fin de soporte. No se lanzarán nuevas versiones de esta AMI. Para obtener más información, vea [Información de la versión de Windows Server](https://learn.microsoft.com/en-us/windows-server/get-started/windows-server-release-info).

Windows Server 2025, Windows Server 2022, Windows Server 2019 y Windows Server 2016 son versiones de canal de servicio a largo plazo (LTSC). Windows Server 20H2 es una versión de canal semestral (SAC). Para obtener más información, vea [Información de la versión de Windows Server](https://learn.microsoft.com/en-us/windows-server/get-started/windows-server-release-info).

### Consideraciones
<a name="windows_caveats"></a>

Estas son algunas cuestiones que debería saber acerca de los contenedores de Amazon EC2 Windows y Amazon ECS.
+ Los contenedores de Windows no se pueden ejecutar en instancias de contenedor Linux y viceversa. Para lograr una mejor ubicación de tareas de Windows y de Linux, debería mantener las instancias de contenedor de Windows y de Linux en clústeres independientes y colocar solo las tareas de Windows en contenedores de Windows. Puede asegurarse de que las definiciones de tareas de Windows solo se coloquen en instancias de Windows estableciendo la siguiente restricción de colocación: `memberOf(ecs.os-type=='windows')`.
+ Los contenedores de Windows son compatibles con las tareas que utilizan EC2 y Fargate.
+ Los contenedores y las instancias de contenedor de Windows no pueden admitir todos los parámetros de definición de tareas disponibles para contenedores e instancias de contenedor de Linux. Algunos parámetros directamente no se admiten, mientras que otros se comportan de modo distinto en Windows y en Linux. Para obtener más información, consulte [Diferencias en la definición de tareas de Amazon ECS para instancias de EC2 que ejecutan Windows](windows_task_definitions.md).
+ En cuanto a la característica de roles de IAM para las tareas, debe configurar las instancias de contenedor de Windows para habilitarla durante el lanzamiento. Los contenedores deben ejecutar algún código de PowerShell proporcionado cuando utilicen la característica. Para obtener más información, consulte [Configuración adicional de las instancias de Amazon EC2 de Windows](task-iam-roles.md#windows_task_IAM_roles).
+ La característica de roles de IAM para las tareas utiliza un proxy de credenciales que proporcionar credenciales a los contenedores. Este proxy de credenciales ocupa el puerto 80 de la instancia de contenedor, es decir que si utiliza los roles de IAM para las tareas, el puerto 80 no está disponible para tareas. En el caso de los contenedores de servicio web, puede utilizar un Application Load Balancer y un mapeo de puertos dinámico para proporcionar conexiones HTTP estándar en el puerto 80 a los contenedores. Para obtener más información, consulte [Uso del equilibrador de carga para distribuir el tráfico de servicio de Amazon ECS](service-load-balancing.md).
+ Las imágenes de Docker de Windows Server son grandes (9 GiB). Por lo tanto, las instancias de contenedor de Windows requieren más espacio de almacenamiento que las instancias de contenedor de Linux.
+ Para ejecutar un contenedor de Windows en un Windows Server, la versión del sistema operativo de imagen base del contenedor debe coincidir con la del host. Para obtener más información, consulte [Compatibilidad de versiones de contenedores Windows](https://learn.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility?tabs=windows-server-2022%2Cwindows-11) en el sitio web de documentación de Microsoft. Si el clúster ejecuta varias versiones de Windows, puede asegurarse de que la tarea se coloque en una instancia de EC2 que se ejecute en la misma versión mediante la restricción de ubicación: `memberOf(attribute:ecs.os-family == WINDOWS_SERVER_<OS_Release>_<FULL or CORE>)`. Para obtener más información, consulte [Recuperación de metadatos de las AMI de Windows optimizadas para Amazon ECS](retrieve-ecs-optimized_windows_AMI.md).

# Recuperación de metadatos de las AMI de Windows optimizadas para Amazon ECS
<a name="retrieve-ecs-optimized_windows_AMI"></a>

Para recuperar el ID de la AMI, el nombre de la imagen, el sistema operativo, la versión del agente de contenedor y la versión del tiempo de ejecución de las AMI optimizada para Amazon ECS mediante programación, consulte la API del Parameter Store de Systems Manager. Para obtener más información acerca de la API del Parameter Store de Systems Manager, consulte [GetParameters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameters.html) y [GetParametersByPath](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParametersByPath.html).

**nota**  
La cuenta administrativa debe tener los siguientes permisos de IAM para recuperar los metadatos de la AMI optimizada para Amazon ECS. Estos permisos se agregaron a la política de IAM `AmazonECS_FullAccess`.  
ssm:GetParameters
ssm:GetParameter
ssm:GetParametersByPath

## Formato de los parámetros de Parameter Store de Systems Manager
<a name="ecs-optimized-ami-parameter-format"></a>

**nota**  
Los siguientes parámetros de la API de Parameter Store de Systems Manager están obsoletos y no deben utilizarse para recuperar las AMI de Windows más recientes:  
`/aws/service/ecs/optimized-ami/windows_server/2016/english/full/recommended/image_id `
`/aws/service/ecs/optimized-ami/windows_server/2019/english/full/recommended/image_id`

A continuación, se muestra el formato del nombre del parámetro para cada variante de AMI optimizada para Amazon ECS.
+ Metadatos de la AMI de Windows Server 2025 Full:

  ```
  /aws/service/ami-windows-latest/Windows_Server-2025-English-Full-ECS_Optimized
  ```
+ Metadatos de la AMI de Windows Server 2025 Core:

  ```
  /aws/service/ami-windows-latest/Windows_Server-2025-English-Core-ECS_Optimized
  ```
+ Metadatos de la AMI de Windows Server 2022 Full:

  ```
  /aws/service/ami-windows-latest/Windows_Server-2022-English-Full-ECS_Optimized
  ```
+ Metadatos de la AMI de Windows Server 2022 Core:

  ```
  /aws/service/ami-windows-latest/Windows_Server-2022-English-Core-ECS_Optimized
  ```
+ Metadatos de la AMI de Windows Server 2019 Full:

  ```
  /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized
  ```
+ Metadatos de la AMI de Windows Server 2019 Core:

  ```
  /aws/service/ami-windows-latest/Windows_Server-2019-English-Core-ECS_Optimized
  ```
+ Metadatos de la AMI de Windows Server 2016 Full:

  ```
  /aws/service/ami-windows-latest/Windows_Server-2016-English-Full-ECS_Optimized
  ```

El siguiente formato de nombre de parámetro recupera los metadatos de la versión estable más reciente de la AMI completa 2019 de Windows Server.

```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized
```

A continuación se muestra un ejemplo del objeto JSON que se devuelve para el valor del parámetro.

```
{
    "Parameters": [
        {
            "Name": "/aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized",
            "Type": "String",
            "Value": "{\"image_name\":\"Windows_Server-2019-English-Full-ECS_Optimized-2023.06.13\",\"image_id\":\"ami-0debc1fb48e4aee16\",\"ecs_runtime_version\":\"Docker (CE) version 20.10.21\",\"ecs_agent_version\":\"1.72.0\"}",
            "Version": 58,
            "LastModifiedDate": "2023-06-22T19:37:37.841000-04:00",
            "ARN": "arn:aws:ssm:us-east-1::parameter/aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized",
            "DataType": "text"
        }
    ],
    "InvalidParameters": []
}
```

Cada uno de los campos de la salida anterior están disponibles para consultarse como parámetros secundarios. Para crear la ruta de parámetros correspondiente a un parámetro secundario, agregue el nombre del parámetro secundario a la ruta de la AMI seleccionada. Están disponibles los siguientes parámetros secundarios:
+ `schema_version`
+ `image_id`
+ `image_name`
+ `os`
+ `ecs_agent_version`
+ `ecs_runtime_version`

## Ejemplos
<a name="ecs-optimized-ami-windows-parameter-examples"></a>

Los siguientes ejemplos muestran formas en las que pueden recuperar los metadatos de cada variante de AMI optimizada para Amazon ECS.

### Recuperación de los metadatos de la AMI optimizada para Amazon ECS estable más reciente
<a name="ecs-optimized-ami-windows-parameter-examples-1"></a>

Utilice los siguientes comandos de la AWS CLI para recuperar la AMI optimizada para Amazon ECS estable más reciente mediante la AWS CLI.
+ **Para la AMI de Windows Server 2025 Full optimizada para Amazon ECS:**

  ```
  aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2025-English-Full-ECS_Optimized --region us-east-1
  ```
+ **Para la AMI de Windows Server 2025 Core optimizada para Amazon ECS:**

  ```
  aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2025-English-Core-ECS_Optimized --region us-east-1
  ```
+ **Para la AMI de Windows Server 2022 Full optimizada para Amazon ECS:**

  ```
  aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2022-English-Full-ECS_Optimized --region us-east-1
  ```
+ **Para la AMI de Windows Server 2022 Core optimizada para Amazon ECS:**

  ```
  aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2022-English-Core-ECS_Optimized --region us-east-1
  ```
+ **Para la AMI de Windows Server 2019 Full optimizada para Amazon ECS:**

  ```
  aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized --region us-east-1
  ```
+ **Para la AMI de Windows Server 2019 Core optimizada para Amazon ECS:**

  ```
  aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Core-ECS_Optimized --region us-east-1
  ```
+ **Para la AMI de Windows Server 2016 Full optimizada para Amazon ECS:**

  ```
  aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2016-English-Full-ECS_Optimized --region us-east-1
  ```

### Utilización de la AMI optimizada para Amazon ECS más reciente recomendada en una plantilla de CloudFormation
<a name="ecs-optimized-ami-windows-parameter-examples-5"></a>

Para hacer referencia a la AMI optimizada para Amazon ECS recomendada en una plantilla de CloudFormation, pude hacer referencia al nombre del almacén de parámetros de Systems Manager.

```
Parameters:
  LatestECSOptimizedAMI:
    Description: AMI ID
    Type: AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>
    Default: /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized/image_id
```

# Versiones de las AMI de Windows optimizadas para Amazon ECS
<a name="ecs-windows-ami-versions"></a>

Vea las versiones anteriores y la actual de las AMI optimizadas para Amazon ECS y sus respectivas versiones del agente de contenedor de Amazon ECS, de Docker y del paquete `ecs-init`.

Los metadatos de la AMI optimizada para Amazon ECS, incluido el ID de la AMI, de cada variante se pueden recuperar mediante programación. Para obtener más información, consulte [Recuperación de metadatos de las AMI de Windows optimizadas para Amazon ECS](retrieve-ecs-optimized_windows_AMI.md). 

En las siguientes pestañas, se muestra una lista de versiones de AMI de Windows optimizadas para Amazon ECS. Para obtener más información sobre cómo hacer referencia al parámetro de Parameter Store de Systems Manager en una plantilla de CloudFormation, consulte [Utilización de la AMI optimizada para Amazon ECS más reciente recomendada en una plantilla de CloudFormation](retrieve-ecs-optimized_AMI.md#ecs-optimized-ami-parameter-examples-5).

**importante**  
Para asegurarse de que los clientes disponen de las actualizaciones de seguridad más recientes de forma predeterminada, Amazon ECS mantiene al menos las últimas tres AMI de Windows optimizada para Amazon ECS. Después de lanzar nuevas AMI de Windows optimizadas para Amazon ECS, Amazon ECS convierte en privadas las AMI de Windows optimizadas para Amazon ECS más antiguas. Para informarnos que necesita obtener acceso a una AMI privada, envíe un ticket al equipo de Cloud Support.  
Windows Server 2016 no es compatible con la última versión de Docker, por ejemplo, la 25.x.x. Por lo tanto, las AMI completas de Windows Server 2016 no recibirán parches de seguridad o de errores en el entorno en tiempo de ejecución de Docker. Le recomendamos que cambie a una de las siguientes plataformas de Windows:  
Windows Server 2022 Full
Windows Server 2022 Core
Windows Server 2019 Full
Windows Server 2019 Core

**nota**  
El registro de complementos gMSA se ha migrado del registro basado en archivos `(C:\ProgramData\Amazon\gmsa)` a Windows Event logging con la versión de la AMI de agosto de 2025. El script del recopilador de registros público recopilará todos los registros de gMSA. Para obtener más información, consulte [Recopilación de registros de contenedor con el recopilador de registros de Amazon ECS](ecs-logs-collector.md).

------
#### [ Windows Server 2025 Full AMI versions ]

En la tabla siguiente, se enumeran las versiones anteriores y la actual de la AMI de Windows Server 2025 Full optimizada para Amazon ECS y sus respectivas versiones del agente de contenedor de Amazon ECS y Docker.


|  AMI de Windows Server 2025 Full optimizada para Amazon ECS  |  Versión del agente de contenedor de Amazon ECS  |  Versión de Docker  |  Visibility  | 
| --- | --- | --- | --- | 
|  **Windows\$1Server-2025-English-Full-ECS\$1Optimized-2025.09.13**  |  `1.99.0`  |  `25.0.6 (Docker CE)`  |  Public  | 
|  **Windows\$1Server-2025-English-Full-ECS\$1Optimized-2025.08.24**  |  `1.98.0`  |  `25.0.6 (Docker CE)`  |  Public  | 
| Windows\$1Server-2025-English-Full-ECS\$1Optimized-2025.08.16 | 1.97.1 | 25.0.6 (Docker CE) | Public | 
|  **Windows\$1Server-2025-English-Full-ECS\$1Optimized-2025.07.16**  |  `1.96.0`  |  `25.0.6 (Docker CE)`  |  Public  | 
|  **Windows\$1Server-2025-English-Full-ECS\$1Optimized-2025.06.13**  |  `1.94.0`  |  `25.0.6 (Docker CE)`  |  Public  | 

Utilice el siguiente comando de la AWS CLI para recuperar la AMI de Windows Server 2025 Full optimizada para Amazon ECS.

```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2025-English-Full-ECS_Optimized
```

------
#### [ Windows Server 2025 Core AMI versions ]

En la tabla siguiente, se enumeran las versiones anteriores y la actual de la AMI de Windows Server 2025 Core optimizada para Amazon ECS y sus respectivas versiones del agente de contenedor de Amazon ECS y Docker.


|  AMI de Windows Server 2025 Core optimizada para Amazon ECS  |  Versión del agente de contenedor de Amazon ECS  |  Versión de Docker  |  Visibility  | 
| --- | --- | --- | --- | 
|  **Windows\$1Server-2025-English-Core-ECS\$1Optimized-2025.09.13**  |  `1.99.0`  |  `25.0.6 (Docker CE)`  |  Public  | 
|  **Windows\$1Server-2025-English-Core-ECS\$1Optimized-2025.08.24**  |  `1.98.0`  |  `25.0.6 (Docker CE)`  |  Public  | 
| Windows\$1Server-2025-English-Core-ECS\$1Optimized-2025.08.16 | 1.97.1 | 25.0.6 (Docker CE) | Public | 
|  **Windows\$1Server-2025-English-Core-ECS\$1Optimized-2025.07.16**  |  `1.96.0`  |  `25.0.6 (Docker CE)`  |  Public  | 
|  **Windows\$1Server-2025-English-Core-ECS\$1Optimized-2025.06.13**  |  `1.94.0`  |  `25.0.6 (Docker CE)`  |  Public  | 

Utilice el siguiente comando de la AWS CLI para recuperar la AMI de Windows Server 2025 Core optimizada para Amazon ECS.

```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2025-English-Core-ECS_Optimized
```

------
#### [ Windows Server 2022 Full AMI versions ]

En la tabla siguiente, se enumeran las versiones anteriores y la actual de la AMI de Windows Server 2022 Full optimizada para Amazon ECS y sus respectivas versiones del agente de contenedor de Amazon ECS y Docker.


|  AMI de Windows Server 2022 Full optimizada para Amazon ECS  |  Versión del agente de contenedor de Amazon ECS  |  Versión de Docker  |  Visibility  | 
| --- | --- | --- | --- | 
|  **Windows\$1Server-2022-English-Full-ECS\$1Optimized-2025.09.13**  |  `1.99.0`  |  `25.0.6 (Docker CE)`  |  Public  | 
|  **Windows\$1Server-2022-English-Full-ECS\$1Optimized-2025.08.24**  |  `1.98.0`  |  `25.0.6 (Docker CE)`  |  Public  | 
| Windows\$1Server-2022-English-Full-ECS\$1Optimized-2025.08.16 | 1.97.1 | 25.0.6 (Docker CE) | Public | 
|  **Windows\$1Server-2022-English-Full-ECS\$1Optimized-2025.07.16**  |  `1.95.0`  |  `25.0.6 (Docker CE)`  |  Public  | 

Utilice el siguiente comando de la AWS CLI para recuperar la AMI de Windows Server 2022 Full optimizada para Amazon ECS.

```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2022-English-Full-ECS_Optimized
```

------
#### [ Windows Server 2022 Core AMI versions ]

En la tabla siguiente, se enumeran las versiones anteriores y la actual de la AMI de Windows Server 2022 Core optimizada para Amazon ECS y sus respectivas versiones del agente de contenedor de Amazon ECS y Docker.


|  AMI de Windows Server 2022 Core optimizada para Amazon ECS  |  Versión del agente de contenedor de Amazon ECS  |  Versión de Docker  |  Visibility  | 
| --- | --- | --- | --- | 
|  **Windows\$1Server-2022-English-Core-ECS\$1Optimized-2025.09.13**  |  `1.99.0`  |  `25.0.6 (Docker CE)`  |  Public  | 
|  **Windows\$1Server-2022-English-Core-ECS\$1Optimized-2025.08.24**  |  `1.98.0`  |  `25.0.6 (Docker CE)`  |  Public  | 
| Windows\$1Server-2022-English-Core-ECS\$1Optimized-2025.08.16 | 1.97.1 | 25.0.6 (Docker CE) | Public | 
|  **Windows\$1Server-2022-English-Core-ECS\$1Optimized-2025.07.16**  |  `1.95.0`  |  `25.0.6 (Docker CE)`  |  Public  | 

Utilice el siguiente comando de la AWS CLI para recuperar la AMI de Windows Server 2022 Full optimizada para Amazon ECS.

```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2022-English-Core-ECS_Optimized
```

------
#### [ Windows Server 2019 Full AMI versions ]

En la tabla siguiente, se enumeran las versiones anteriores y la actual de la AMI de Windows Server 2019 Full optimizada para Amazon ECS y sus respectivas versiones del agente de contenedor de Amazon ECS y Docker.


|  AMI de Windows Server 2019 Full optimizada para Amazon ECS  |  Versión del agente de contenedor de Amazon ECS  |  Versión de Docker  |  Visibility  | 
| --- | --- | --- | --- | 
|  **Windows\$1Server-2019-English-Full-ECS\$1Optimized-2025.09.13**  |  `1.99.0`  |  `25.0.6 (Docker CE)`  |  Public  | 
|  **Windows\$1Server-2019-English-Full-ECS\$1Optimized-2025.08.24**  |  `1.98.0`  |  `25.0.6 (Docker CE)`  |  Public  | 
| Windows\$1Server-2019-English-Full-ECS\$1Optimized-2025.08.16 | 1.97.1 | 25.0.6 (Docker CE) | Public | 
|  **Windows\$1Server-2019-English-Full-ECS\$1Optimized-2025.07.16**  |  `1.95.0`  |  `25.0.6 (Docker CE)`  |  Public  | 

Utilice el siguiente comando de la AWS CLI para recuperar la AMI de Windows Server 2019 Full optimizada para Amazon ECS.

```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Full-ECS_Optimized
```

------
#### [ Windows Server 2019 Core AMI versions ]

En la tabla siguiente, se enumeran las versiones anteriores y la actual de la AMI de Windows Server 2019 Core optimizada para Amazon ECS y sus respectivas versiones del agente de contenedor de Amazon ECS y Docker.


|  AMI de Windows Server 2019 Core optimizada para Amazon ECS  |  Versión del agente de contenedor de Amazon ECS  |  Versión de Docker  |  Visibility  | 
| --- | --- | --- | --- | 
|  **Windows\$1Server-2019-English-Core-ECS\$1Optimized-2025.09.13**  |  `1.99.0`  |  `25.0.6 (Docker CE)`  |  Public  | 
|  **Windows\$1Server-2019-English-Core-ECS\$1Optimized-2025.08.24**  |  `1.98.0`  |  `25.0.6 (Docker CE)`  |  Public  | 
| Windows\$1Server-2019-English-Core-ECS\$1Optimized-2025.08.16 | 1.97.1 | 25.0.6 (Docker CE) | Public | 
|  **Windows\$1Server-2019-English-Core-ECS\$1Optimized-2025.07.16**  |  `1.95.0`  |  `25.0.6 (Docker CE)`  |  Public  | 

Utilice el siguiente comando de la AWS CLI para recuperar la AMI de Windows Server 2019 Full optimizada para Amazon ECS.

```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2019-English-Core-ECS_Optimized
```

------
#### [ Windows Server 2016 Full AMI versions ]

**importante**  
Windows Server 2016 no es compatible con la última versión de Docker, por ejemplo, la 25.x.x. Por lo tanto, las AMI completas de Windows Server 2016 no recibirán parches de seguridad o de errores en el entorno en tiempo de ejecución de Docker. Le recomendamos que cambie a una de las siguientes plataformas de Windows:  
Windows Server 2022 Full
Windows Server 2022 Core
Windows Server 2019 Full
Windows Server 2019 Core

En la tabla siguiente, se enumeran las versiones anteriores y la actual de la AMI de Windows Server 2016 Full optimizada para Amazon ECS y sus respectivas versiones del agente de contenedor de Amazon ECS y Docker.


|  AMI de Windows Server 2016 Full optimizada para Amazon ECS  |  Versión del agente de contenedor de Amazon ECS  |  Versión de Docker  |  Visibility  | 
| --- | --- | --- | --- | 
|  **Windows\$1Server-2016-English-Full-ECS\$1Optimized-2025.09.13**  |  `1.99.0`  |  `20.10.23 (Docker CE)`  |  Public  | 
|  **Windows\$1Server-2016-English-Full-ECS\$1Optimized-2025.08.16**  |  `1.97.1`  |  `20.10.23 (Docker CE)`  |  Public  | 
|  **Windows\$1Server-2016-English-Full-ECS\$1Optimized-2025.07.16**  |  `1.95.0`  |  `20.10.23 (Docker CE)`  |  Public  | 
|  **Windows\$1Server-2016-English-Full-ECS\$1Optimized-2025.06.13**  |  `1.94.0`  |  `20.10.23 (Docker CE)`  |  Public  | 

Utilice la siguiente AWS CLI para la AMI de Windows Server 2016 Full optimizada para Amazon ECS.

```
aws ssm get-parameters --names /aws/service/ami-windows-latest/Windows_Server-2016-English-Full-ECS_Optimized
```

------

# Creación una AMI de Windows optimizada para Amazon ECS propia
<a name="windows-custom-ami"></a>

Utilice el Generador de imágenes de EC2 para crear su propia AMI de Windows optimizada para Amazon ECS personalizada. Así, se simplifica la utilización de una AMI de Windows con su propia licencia en Amazon ECS. Amazon ECS proporciona un componente administrado de Image Builder que proporciona la configuración del sistema necesaria para ejecutar las instancias de Windows en las que se van a alojar los contenedores. Cada componente administrado por Amazon ECS incluye un agente de contenedor y una versión de Docker específicos. Puede personalizar la imagen para que utilice el componente administrado por Amazon ECS más reciente o, si se necesita un agente de contenedor o una versión de Docker anterior, puede especificar un componente diferente.

Para obtener una explicación completa sobre el uso de EC2 Image Builder, consulte [Introducción a EC2 Image Builder](https://docs.aws.amazon.com/imagebuilder/latest/userguide/set-up-ib-env.html#image-builder-accessing-prereq) en la *Guía del usuario de EC2 Image Builder*.

Al crear una AMI de Windows optimizada para Amazon ECS propia mediante EC2 Image Builder, se crea una receta de imagen. La receta de imagen debe cumplir los siguientes requisitos:
+ La **imagen de origen** debe basarse en Windows Server 2019 Core, Windows Server 2019 Full, Windows Server 2022 Core o Windows Server 2022 Full. No se admiten otros sistemas operativos de Windows y es posible que no sean compatibles con el componente.
+ Cuando se especifica la opción **Crear componente**, se requiere el componente `ecs-optimized-ami-windows`. Se recomienda el componente `update-windows`, lo que garantiza que la imagen contenga las actualizaciones de seguridad más recientes.

  Para especificar otra versión de componente diferente, expanda el menú **Opciones de control de versiones** y especifique la versión de componente que desea utilizar. Para obtener más información, consulte [Enumeración de versiones del componente `ecs-optimized-ami-windows`](#windows-component-list).

## Enumeración de versiones del componente `ecs-optimized-ami-windows`
<a name="windows-component-list"></a>

Al crear una receta de EC2 Image Builder y especificar el componente `ecs-optimized-ami-windows`, puede utilizar la opción predeterminada o especificar una versión específica del componente. Para determinar qué versiones del componente están disponibles, junto con las versiones del agente de contenedor de Amazon ECS y de Docker contenidas en el componente, puede utilizar la Consola de administración de AWS.

**Para enumerar las versiones disponibles del componente `ecs-optimized-ami-windows`**

1. Abra la consola de EC2 Image Builder en[https://console.aws.amazon.com/imagebuilder/](https://console.aws.amazon.com/imagebuilder/).

1. En la barra de navegación, seleccione la región en la que está creando la imagen.

1. En el panel de navegación, elija **Components** (Componentes) en el menú **Saved configurations** (Configuraciones guardadas).

1. En la página **Components** (Componentes), escriba `ecs-optimized-ami-windows` en la barra de búsqueda, despliegue el menú de calificación y seleccione **Quick start (Amazon-managed)** (Inicio rápido [administrado por Amazon]).

1. Utilice la columna **Description** (Descripción) para determinar la versión del componente junto con la del agente contenedor de Amazon ECS y la de Docker que requiere su imagen.

# Administración de instancias de contenedor de Windows de Amazon ECS
<a name="manage-windows"></a>

Cuando utiliza instancias de EC2 para las cargas de trabajo de Amazon ECS, es responsable del mantenimiento de las instancias.

Las actualizaciones del agente no se aplican a instancias de contenedor de Windows. Le recomendamos que lance nuevas instancias de contenedor para actualizar la versión del agente en sus clústeres Windows.

**Topics**
+ [Lanzamiento de una instancia de contenedor](launch_window-container_instance.md)
+ [Arranque de instancias de contenedor](bootstrap_windows_container_instance.md)
+ [Uso de un proxy HTTP para instancias de contenedor de Windows](http_proxy_config-windows.md)
+ [Configuración de instancias de contenedor para recibir avisos de instancias de spot](windows-spot-instance-draining-container.md)

# Lanzamiento de una instancia de contenedor de Windows de Amazon ECS
<a name="launch_window-container_instance"></a>

Las instancias de contenedor de Amazon ECS se crean mediante la consola de Amazon EC2. Antes de comenzar, asegúrese de que ha realizado los pasos que se detallan en [Configuración para utilizar Amazon ECS](get-set-up-for-amazon-ecs.md).

Para obtener más información acerca del asistente de inicialización, consulte [Lance una instancia con el nuevo asistente de inicialización de instancias](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-launch-instance-wizard.html) en la *Guía del usuario de Amazon EC2*. 

Puede utilizar el nuevo asistente de Amazon EC2 para lanzar una instancia. Puede utilizar la siguiente lista para los parámetros y dejar los parámetros no listados como predeterminados. Las siguientes instrucciones lo guiarán a través de cada grupo de parámetros.

## Procedimiento
<a name="liw-initiate-instance-launch"></a>

Antes de comenzar, complete los pasos de [Configuración para utilizar Amazon ECS](get-set-up-for-amazon-ecs.md).

1. Abra la consola de Amazon EC2 en [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).

1. En la barra de navegación de la parte superior de la pantalla, se muestra la región de AWS actual (por ejemplo, Este de EE. UU. [Ohio]). Seleccione una región en la que se va a iniciar la instancia. Esta elección es importante porque algunos recursos de Amazon EC2 pueden compartirse entre varias regiones, mientras que otros no. 

1. En el panel de la consola de Amazon EC2, elija **Iniciar instancia**.

## Nombre y etiquetas
<a name="liw-name-and-tags"></a>

El nombre de la instancia es una etiqueta, donde la clave es **Name** (Nombre) y el valor es el nombre que especifique. Puede etiquetar la instancia, los volúmenes y los gráficos elásticos. Para las instancias de spot, solo puede etiquetar la solicitud de instancia de spot. 

Especificar un nombre de instancia y etiquetas adicionales es opcional.
+ En **Name** (Nombre), ingrese un nombre descriptivo para la instancia. Si no especifica un nombre, la instancia se puede identificar mediante su ID, que se genera automáticamente al iniciar la instancia.
+ Para agregar otras etiquetas, elija **Add additional tag** (Agregar etiqueta adicional). Elija **Add tag** (Agregar etiqueta) y, a continuación, ingrese una clave y un valor, y seleccione el tipo de recurso que desea etiquetar. Elija **Add tag** (Agregar etiqueta) para cada etiqueta adicional.

## Imágenes de aplicaciones y sistema operativo (Imagen de máquina de Amazon)
<a name="liw-ami"></a>

Una Imagen de máquina de Amazon (AMI) proporciona la información necesaria para crear una instancia. Por ejemplo, una AMI puede contener el software necesario para funcionar como servidor web, como Apache, y su sitio web.

Para obtener las AMI optimizadas para Amazon ECS más recientes y sus valores, consulte [Versiones de AMI de Windows optimizadas para Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_windows_AMI.html).

Utilice la barra de **búsqueda** para buscar una AMI optimizada para Amazon ECS adecuada publicada por AWS.

1. En función de sus requisitos, ingrese una de las AMI siguientes en la barra de **búsqueda** y pulse **Enter** (Intro).
   + Windows\$1Server-2022-English-Full-ECS\$1Optimized
   + Windows\$1Server-2022-English-Core-ECS\$1Optimized
   + Windows\$1Server-2019-English-Full-ECS\$1Optimized
   + Windows\$1Server-2019-English-Core-ECS\$1Optimized
   + Windows\$1Server-2016-English-Full-ECS\$1Optimized

1. En la página **Choose an Amazon Machine Image (AMI)** (Elija una imagen de máquina de Amazon [AMI]), seleccione la categoría **Community AMIs** (AMI de la comunidad).

1. En la lista que aparece, seleccione una AMI verificada por Microsoft con la fecha de publicación más reciente y haga clic en **Select** (Seleccionar).

## Tipo de instancia
<a name="liw-instance-type"></a>

El tipo de instancia define la configuración de hardware y el tamaño de la instancia. Los tipos de instancia más grandes tienen una CPU y memoria superiores. Para obtener más información, consulte [Tipos de instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html).
+ En **Instance Type** (Tipo de instancia), seleccione el tipo de instancia de la instancia. 

   El tipo de instancia que seleccione determina los recursos disponibles para poner en marcha sus tareas.

## Par de claves (inicio de sesión)
<a name="liw-key-pair"></a>

En **Key pair name** (Nombre de par de claves) seleccione un par de claves existente o seleccione **Create new key pair** (Crear nuevo par de claves) para crear uno nuevo. 

**importante**  
Si elige la opción **Proceed without key pair (Not recommended)** (Continuar sin un par de claves [No recomendado]), no podrá conectarse a la instancia a menos que elija una AMI que esté configurada para ofrecer a los usuarios otra forma de iniciar sesión.

## Configuración de red
<a name="liw-network-settings"></a>

Establezca la configuración de red, según sea necesario.
+ **Networking platform** (Plataforma de redes): elija **Virtual Private Cloud (VPC)** (Nube privada virtual [VPC]) y, a continuación, especifique la subred en la sección **Network interfaces** (Interfaces de red). 
+ **VPC**: seleccione una VPC existente en la que desea crear el grupo de seguridad.
+ **Subnet** (Subred): puede lanzar una instancia en una subred asociada con una zona de disponibilidad, zona local, zona Wavelength u Outpost.

  Para iniciar la instancia en una zona de disponibilidad, seleccione la subred en la que desea iniciar la instancia. Para crear una subred, elija **Crear nueva subred** para ir a la consola de Amazon VPC. Cuando haya terminado, vuelva al asistente de lanzamiento de instancias y elija el ícono Refresh (Actualizar) para cargar la subred en la lista.

  Para iniciar la instancia en una zona local, seleccione una subred que haya creado en la zona local. 

  Para iniciar una instancia en un Outpost, seleccione una subred en una VPC que haya asociado a un Outpost.
+ **Auto-assign Public IP** (Asignar automáticamente IP pública): si desea que se pueda acceder a la instancia desde Internet, compruebe que el campo **Auto-assign Public IP** (Asignar automáticamente IP pública) esté configurado como **Enable** (Habilitar). De lo contrario, configure este campo como **Disable** (Deshabilitar).
**nota**  
Las instancias de contenedor deben obtener acceso para comunicarse con el punto de conexión del servicio de Amazon ECS. Esto puede ser a través de un punto de conexión de VPC de la interfaz o a través de las instancias de contenedor con direcciones IP públicas.  
Para obtener más información acerca de los puntos de conexión de VPC, consulte [Puntos de enlace de la VPC de interfaz de Amazon ECS (AWS PrivateLink)](vpc-endpoints.md).  
Si no tiene configurado un punto de conexión de VPC de la interfaz y las instancias de contenedor no tienen direcciones IP públicas, deberán utilizar traducción de direcciones de red (NAT) para proporcionar este acceso. Para obtener más información, consulte [Puertas de enlace NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) en la *Guía del usuario de Amazon VPC* y [Uso de un proxy HTTP para instancias de contenedor de Linux de Amazon ECS](http_proxy_config.md) en esta guía.
+ **Firewall (security groups)** Firewall (grupos de seguridad): utilice un grupo de seguridad para definir reglas de firewall para la instancia de contenedor. Estas reglas especifican qué tráfico procedente de la red se entregará en la instancia de contenedor. El resto del tráfico se ignora. 
  + Para seleccionar un grupo de seguridad existente, elija **Select an existing security group** (Seleccionar un grupo de seguridad existente) y seleccione el grupo de seguridad que creó en [Configuración para utilizar Amazon ECS](get-set-up-for-amazon-ecs.md).

## Configurar almacenamiento
<a name="liw-storage"></a>

La AMI seleccionada incluye uno o más volúmenes de almacenamiento, incluido el volumen de dispositivo raíz. Se pueden especificar volúmenes adicionales para adjuntar a la instancia.

Se puede utilizar la vista **Simple** (Simple).
+ **Storage type** (Tipo de almacenamiento): configure el almacenamiento de la instancia de contenedor.

  Si utiliza la AMI de Amazon Linux optimizada para Amazon ECS, la instancia tiene configurados dos volúmenes. El volumen **raíz** lo utiliza el sistema operativo y el segundo volumen de Amazon EBS (asociado a `/dev/xvdcz`) lo utiliza Docker.

  Si lo desea, puede aumentar o reducir el tamaño de volumen para su instancia de acuerdo con las necesidades de su aplicación.

## Detalles avanzados
<a name="liw-advanced-details"></a>

En **Detalles avanzados**, expanda la sección para ver los campos y especifique cualquier parámetro adicional para la instancia.
+ **Purchasing option** (Opción de compra): elija **Request Spot instances** (Solicitar instancias de spot) para solicitar una instancia de spot. También debe establecer el resto de los campos relacionados con las instancias de Spot. Para obtener más información, consulte [Spot Instance Requests](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html) (Solicitudes de instancias de Spot).
**nota**  
Si utiliza instancias de Spot y ve un mensaje que indica `Not available`, es posible que deba elegir un tipo de instancia diferente.

  .
+ En **IAM instance profile** (Perfil de instancia de IAM), seleccione el rol de IAM de la instancia de contenedor. Suele llamarse `ecsInstanceRole`.
**importante**  
Si no lanza la instancia de contenedor con los permisos de IAM correspondientes, el agente de Amazon ECS no puede conectarse al clúster. Para obtener más información, consulte [Rol de IAM de instancia de contenedor de Amazon ECS](instance_IAM_role.md).
+ (Opcional) **User data** (Datos de usuario): configure la instancia de contenedor de Amazon ECS con los datos de usuario, por ejemplo, las variables de entorno del agente de [Configuración del agente de contenedor de Amazon ECS](ecs-agent-config.md). Los scripts de datos de usuario de Amazon EC2 se ponen en marcha solo una vez, cuando la instancia se lanza por primera vez. A continuación, se muestran ejemplos comunes del uso de los datos del usuario:
  + De forma predeterminada, su instancia de contenedor se abre en su clúster predeterminado. Para abrirlo en un clúster no predeterminado, seleccione la lista **Advanced Details**. A continuación, pegue el siguiente script en el campo **User data**, reemplazando *your\$1cluster\$1name* con el nombre de su clúster.

    El rol `EnableTaskIAMRole` activa la característica de roles de IAM de tareas para las tareas.

    Además, las siguientes opciones están disponibles cuando se utiliza el modo de red `awsvpc`.
    + `EnableTaskENI`: este indicador activa las redes de tareas y se requiere cuando se utiliza el modo de red `awsvpc`.
    + `AwsvpcBlockIMDS`: este indicador opcional bloquea el acceso a IMDS para los contenedores de tareas que se ejecutan en el modo de red `awsvpc`.
    + `AwsvpcAdditionalLocalRoutes`: este indicador opcional le permite tener rutas adicionales en el espacio de nombres de la tarea.

      Sustituya `ip-address` por la dirección IP para las rutas adicionales, por ejemplo, 172.31.42.23/32.

    ```
    <powershell>
    Import-Module ECSTools
    Initialize-ECSAgent -Cluster your_cluster_name -EnableTaskIAMRole -EnableTaskENI -AwsvpcBlockIMDS -AwsvpcAdditionalLocalRoutes
    '["ip-address"]'
    </powershell>
    ```

# Arranque de instancias de contenedor de Windows de Amazon ECS para la transferencia de datos
<a name="bootstrap_windows_container_instance"></a>

Cuando se lanza una instancia de Amazon EC2, puede transferir los datos de usuario a la instancia de EC2. Los datos se pueden utilizar para llevar a cabo tareas de configuración automatizadas comunes e incluso poner en marcha scripts cuando la instancia arranca. En Amazon ECS, los casos de uso más comunes para los datos de usuario consisten en transferir la información de configuración al daemon de Docker y al agente de contenedor de Amazon ECS.

Puede transferir varios tipos de datos de usuario a Amazon EC2, incluidos cloud boothooks, scripts de shell y directivas `cloud-init`. Para obtener más información acerca de estos u otros tipos de formato, consulte la [documentación de Cloud-Init](https://cloudinit.readthedocs.io/en/latest/explanation/format.html). 

Puede transferir estos datos de usuario cuando utilice el asistente de lanzamiento de Amazon EC2. Para obtener más información, consulte [Lanzamiento de una instancia de contenedor de Linux de Amazon ECS](launch_container_instance.md).

## Datos de usuario de Windows predeterminados
<a name="windows-default-userdata"></a>

Este script de datos de usuario de ejemplo muestra los datos de usuario predeterminados que reciben las instancias de contenedor de Windows si se utiliza la consola. El script a continuación hace lo siguiente:
+ Establece el nombre del clúster con el nombre que ha ingresado.
+ Establece los roles de IAM para las tareas.
+ Establece `json-file` y `awslogs` como los controladores de registro disponibles.

Además, las siguientes opciones están disponibles cuando se utiliza el modo de red `awsvpc`.
+ `EnableTaskENI`: este indicador activa las redes de tareas y se requiere cuando se utiliza el modo de red `awsvpc`.
+ `AwsvpcBlockIMDS`: este indicador opcional bloquea el acceso a IMDS para los contenedores de tareas que se ejecutan en el modo de red `awsvpc`.
+ `AwsvpcAdditionalLocalRoutes`: este indicador opcional le permite disponer de rutas adicionales.

  Sustituya `ip-address` por la dirección IP para las rutas adicionales, por ejemplo, 172.31.42.23/32.

Puede utilizar este script para sus propias instancias de contenedor (siempre que se lancen desde la AMI de Windows Server optimizada para Amazon ECS). 

Sustituya la línea `-Cluster cluster-name` para especificar el nombre de su propio clúster.

```
<powershell>
Initialize-ECSAgent -Cluster cluster-name -EnableTaskIAMRole -LoggingDrivers '["json-file","awslogs"]' -EnableTaskENI -AwsvpcBlockIMDS -AwsvpcAdditionalLocalRoutes
'["ip-address"]'
</powershell>
```

 Para las tareas de Windows configuradas para utilizar el controlador de registros `awslogs`, debe también establecer la variable de entorno `ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE` en la instancia del contenedor. Utilice la siguiente sintaxis. 

Sustituya la línea `-Cluster cluster-name` para especificar el nombre de su propio clúster.

```
<powershell>
[Environment]::SetEnvironmentVariable("ECS_ENABLE_AWSLOGS_EXECUTIONROLE_OVERRIDE", $TRUE, "Machine")
Initialize-ECSAgent -Cluster cluster-name -EnableTaskIAMRole -LoggingDrivers '["json-file","awslogs"]'
</powershell>
```

## Datos de usuario de la instalación del agente de Windows
<a name="agent-service-userdata"></a>

Este script de datos de usuario de ejemplo instala el agente de contenedor de Amazon ECS en una instancia lanzada mediante una AMI **Windows\$1Server-2016-English-Full-Containers**. Se ha adaptado a partir de las instrucciones de instalación del agente que figuran en la página README del [repositorio de GitHub del agente de contenedor de Amazon ECS](https://github.com/aws/amazon-ecs-agent).

**nota**  
Este script se comparte para fines ilustrativos. Resulta mucho más sencillo comenzar a utilizar los contenedores de Windows mediante la AMI de Windows Server optimizada para Amazon ECS. Para obtener más información, consulte [Creación de un clúster de Amazon ECS para cargas de trabajo de Fargate](create-cluster-console-v2.md).

Para obtener información sobre cómo instalar el agente de Amazon ECS en Windows Server 2022 Full, consulte [Issue 3753](https://github.com/aws/amazon-ecs-agent/issues/3753) en GitHub.

Puede utilizar este script para sus propias instancias de contenedor (siempre que se lancen con una versión de la AMI **Windows\$1Server-2016-English-Full-Containers**). Asegúrese de sustituir la línea `windows` para especificar su propio nombre de clúster (si no está utilizando un clúster denominado `windows`).

```
<powershell>
# Set up directories the agent uses
New-Item -Type directory -Path ${env:ProgramFiles}\Amazon\ECS -Force
New-Item -Type directory -Path ${env:ProgramData}\Amazon\ECS -Force
New-Item -Type directory -Path ${env:ProgramData}\Amazon\ECS\data -Force
# Set up configuration
$ecsExeDir = "${env:ProgramFiles}\Amazon\ECS"
[Environment]::SetEnvironmentVariable("ECS_CLUSTER", "windows", "Machine")
[Environment]::SetEnvironmentVariable("ECS_LOGFILE", "${env:ProgramData}\Amazon\ECS\log\ecs-agent.log", "Machine")
[Environment]::SetEnvironmentVariable("ECS_DATADIR", "${env:ProgramData}\Amazon\ECS\data", "Machine")
# Download the agent
$agentVersion = "latest"
$agentZipUri = "https://s3.amazonaws.com/amazon-ecs-agent/ecs-agent-windows-$agentVersion.zip"
$zipFile = "${env:TEMP}\ecs-agent.zip"
Invoke-RestMethod -OutFile $zipFile -Uri $agentZipUri
# Put the executables in the executable directory.
Expand-Archive -Path $zipFile -DestinationPath $ecsExeDir -Force
Set-Location ${ecsExeDir}
# Set $EnableTaskIAMRoles to $true to enable task IAM roles
# Note that enabling IAM roles will make port 80 unavailable for tasks.
[bool]$EnableTaskIAMRoles = $false
if (${EnableTaskIAMRoles}) {
  $HostSetupScript = Invoke-WebRequest https://raw.githubusercontent.com/aws/amazon-ecs-agent/master/misc/windows-deploy/hostsetup.ps1
  Invoke-Expression $($HostSetupScript.Content)
}
# Install the agent service
New-Service -Name "AmazonECS" `
        -BinaryPathName "$ecsExeDir\amazon-ecs-agent.exe -windows-service" `
        -DisplayName "Amazon ECS" `
        -Description "Amazon ECS service runs the Amazon ECS agent" `
        -DependsOn Docker `
        -StartupType Manual
sc.exe failure AmazonECS reset=300 actions=restart/5000/restart/30000/restart/60000
sc.exe failureflag AmazonECS 1
Start-Service AmazonECS
</powershell>
```

# Uso de un proxy HTTP para instancias de contenedor de Windows de Amazon ECS
<a name="http_proxy_config-windows"></a>

Puede configurar las instancias de contenedor de Amazon ECS para que utilicen un proxy HTTP tanto para el agente de contenedor de Amazon ECS como para el daemon de Docker. Esto resulta útil si las instancias de contenedor no tienen acceso de red externo a través de una gateway de Internet de Amazon VPC, una gateway NAT o una instancia.

Para configurar la instancia de contenedor de Windows de Amazon ECS de modo que utilice un proxy HTTP, establezca las siguientes variables en el momento del lanzamiento (con datos de usuario de Amazon EC2).

`[Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.mydomain:port", "Machine")`  
Establezca `HTTP_PROXY` en el nombre de host (o la dirección IP) y en el número de puerto de un proxy HTTP que se utilizará para que el agente de Amazon ECS se conecte a Internet. Por ejemplo, las instancias de contenedor podrían no tener acceso de red externo a través de una gateway de Internet de Amazon VPC, una gateway NAT o una instancia.

`[Environment]::SetEnvironmentVariable("NO_PROXY", "169.254.169.254,169.254.170.2,\\.\pipe\docker_engine", "Machine")`  
Establezca `NO_PROXY` en `169.254.169.254,169.254.170.2,\\.\pipe\docker_engine` para filtrar los metadatos de la instancia EC2, los roles de IAM para tareas y el tráfico del daemon de Docker procedente del proxy. 

**Example Script de datos de usuario de proxy HTTP de Windows**  
El siguiente ejemplo de script de PowerShell de datos de usuario configura al agente de contenedor de Amazon ECS y al daemon de Docker para que utilicen el proxy HTTP que se usted especifique. También puede especificar un clúster en el que se registre la propia instancia de contenedor.  
Para utilizar este script al lanzar una instancia de contenedor, siga los pasos especificados en [Lanzamiento de una instancia de contenedor de Windows de Amazon ECS](launch_window-container_instance.md). Simplemente copie y pegue el script de PowerShell mostrado a continuación en el campo **User data (Datos de usuario)** (asegúrese de sustituir los valores de ejemplo en color rojo por su propia información de proxy y de clúster).  
Se requiere la opción `-EnableTaskIAMRole` para habilitar los roles de IAM para tareas. Para obtener más información, consulte [Configuración adicional de las instancias de Amazon EC2 de Windows](task-iam-roles.md#windows_task_IAM_roles).

```
<powershell>
Import-Module ECSTools

$proxy = "http://proxy.mydomain:port"
[Environment]::SetEnvironmentVariable("HTTP_PROXY", $proxy, "Machine")
[Environment]::SetEnvironmentVariable("NO_PROXY", "169.254.169.254,169.254.170.2,\\.\pipe\docker_engine", "Machine")

Restart-Service Docker
Initialize-ECSAgent -Cluster MyCluster -EnableTaskIAMRole
</powershell>
```

# Configuración de instancias de contenedor de Windows de Amazon ECS para recibir avisos de instancias de spot
<a name="windows-spot-instance-draining-container"></a>

Amazon EC2 termina, detiene o hiberna la instancia de spot cuando el precio de spot supera el precio máximo de su solicitud o cuando ya no hay más capacidad. Amazon EC2 envía un aviso de interrupción de la instancia de spot, que otorga a la instancia una advertencia dos minutos antes de que se interrumpa. Si el vaciado de instancias de spot de Amazon ECS está habilitado en la instancia, ECS recibe el aviso de interrupción de la instancia de spot y coloca la instancia en el estado `DRAINING`.

**importante**  
Amazon ECS monitorea los avisos de interrupción de instancias de spot que tienen las acciones de instancia `terminate` y `stop`. Si especificó el comportamiento de interrupción de la instancia `hibernate` al solicitar las instancias o la flota de spot, el vaciado de instancias de spot de Amazon ECS no es compatible con esas instancias.

Cuando se establece una instancia de contenedor en `DRAINING`, Amazon ECS evita que se programen nuevas tareas para su ubicación en la instancia de contenedor. Las tareas de servicio en la instancia de contenedor que se está vaciando que están en el estado `PENDING` se paran de inmediato. Si hay instancias de contenedor en el clúster que están disponibles, las tareas de servicio de sustitución se inician en ellas.

Puede activar el drenaje de instancias de spot al lanzar una instancia. Debe configurar el parámetro `ECS_ENABLE_SPOT_INSTANCE_DRAINING` antes de iniciar el agente de contenedor. Reemplace *my-cluster* por el nombre de su clúster.

```
[Environment]::SetEnvironmentVariable("ECS_ENABLE_SPOT_INSTANCE_DRAINING", "true", "Machine")

# Initialize the agent
Initialize-ECSAgent -Cluster my-cluster
```

Para obtener más información, consulte [Lanzamiento de una instancia de contenedor de Windows de Amazon ECS](launch_window-container_instance.md).

# Clústeres de Amazon ECS para instancias externas
<a name="ecs-anywhere"></a>

Amazon ECS Anywhere admite el registro de una *instancia externa*, por ejemplo, un servidor ubicado en las instalaciones o una máquina virtual (VM), en el clúster de Amazon ECS. Las instancias externas se han optimizado para que puedan ejecutar aplicaciones que generen tráfico o datos del proceso salientes. Si la aplicación requiere tráfico entrante, la falta de compatibilidad con Elastic Load Balancing hace que la ejecución de estas cargas de trabajo sea menos eficiente. Amazon ECS ha agregado un nuevo tipo de lanzamiento `EXTERNAL` que se puede utilizar para crear servicios o ejecutar tareas en las instancias externas.

## Sistemas operativos y arquitecturas de sistemas compatibles
<a name="ecs-anywhere-supported-os"></a>

La siguiente lista contiene los sistemas operativos compatibles: Se admiten las arquitecturas de CPU `x86_64` y `ARM64`.
+ Amazon Linux 2023
+ Ubuntu 20, Ubuntu 22, Ubuntu 24
+ RHEL 9: Debe asegurarse de que Docker esté instalado antes de ejecutar el [script de instalación ECS Anywhere](https://github.com/aws/amazon-ecs-agent/blob/master/scripts/ecs-anywhere-install.sh). Para obtener más información, consulte [Instalar motor de Docker en RHEL](https://docs.docker.com/engine/install/rhel/) en la documentación de Docker.

A partir del 7 de agosto de 2026, Amazon ECS Anywhere ya no admitirá los siguientes sistemas operativos:
+ Amazon Linux 2
+ CentOS Stream 9
+ RHEL 7, RHEL 8
+ Fedora 32, Fedora 33, Fedora 40
+ openSUSE Tumbleweed
+ Ubuntu 18
+ Debian 9, Debian 10, Debian 11, Debian 12
+ SUSE Enterprise Server 15
+ Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 20H2

## Consideraciones
<a name="ecs-anywhere-considerations"></a>

Antes de comenzar a utilizar instancias externas, tenga en cuenta lo siguiente.
+ Puede registrar una instancia externa en un clúster a la vez. Para obtener instrucciones sobre cómo registrar una instancia externa con un clúster diferente, consulte [Anulación del registro de una instancia externa de Amazon ECS](ecs-anywhere-deregistration.md).
+ Sus instancias externas requieren un rol de IAM que les permita comunicarse con las API de AWS. Para obtener más información, consulte [Rol de IAM de Amazon ECS Anywhere](iam-role-ecsanywhere.md).
+ Las instancias externas no deben tener una cadena de credenciales de instancia preconfigurada definida localmente, ya que interferiría con el script de registro.
+ Para enviar registros de contenedor a CloudWatch Logs, asegúrese de crear y especificar un rol de IAM de ejecución de tareas en la definición de tareas. 
+ Cuando una instancia externa se registra en un clúster, el atributo `ecs.capability.external` se asocia a la instancia. Este atributo identifica la instancia como una instancia externa. Puede agregar atributos personalizados a las instancias externas para utilizarlos como delimitación de ubicación de tareas. Para obtener más información, consulte [Custom attributes (Atributos personalizados)](task-placement-constraints.md#ecs-custom-attributes).
+ Puede agregar etiquetas de recursos a la instancia externa. Para obtener más información, consulte [Adición de etiquetas a instancias de contenedor externas de Amazon ECS](instance-details-tags-external.md).
+ ECS Exec se admite en instancias externas. Para obtener más información, consulte [Supervisión de los contenedores de Amazon ECS con ECS Exec](ecs-exec.md).
+ A continuación, se incluyen consideraciones adicionales específicas de las redes con las instancias externas. Para obtener más información, consulte [Red](#ecs-anywhere-networking).
  + No se admite el equilibrio de carga del servicio.
  + No se admite la detección de servicios.
  + Las tareas que se ejecutan en instancias externas deben utilizar los modos de red `bridge`, `host`, o `none`. No se admite el modo de red `awsvpc`.
  + Existen dominios de servicio de Amazon ECS en cada región de AWS. Se debe permitir que estos dominios de servicio envíen tráfico a las instancias externas.
  + El SSM Agent que se instaló en la instancia externa mantiene las credenciales de IAM que se rotan cada 30 minutos mediante una huella digital de hardware. Si la instancia externa pierde la conexión con AWS, SSM Agent actualiza automáticamente las credenciales después de que se restablece la conexión. Para obtener más información, consulte [Validación de servidores ubicados en las instalaciones y máquinas virtuales mediante una huella digital de hardware](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-technical-details.html#fingerprint-validation) en la *Guía del usuario de AWS Systems Manager*.
  + Puede poner en marcha tareas de Linux en instancias externas en una configuración de solo IPv6 siempre que las instancias estén en subredes de solo IPv6. Para obtener más información, consulte [Uso de VPC en modo de solo IPv6](task-networking.md#networking-ipv6-only).
+ No se admite la API `UpdateContainerAgent`. Para obtener instrucciones sobre cómo actualizar SSM Agent o el agente de Amazon ECS en las instancias externas, consulte [Actualización del agente de AWS Systems Manager y del agente de contenedor de Amazon ECS en una instancia externa](ecs-anywhere-updates.md).
+ No se admiten los proveedores de capacidad de Amazon ECS. Para crear un servicio o ejecutar una tarea independiente en las instancias externas, utilice el tipo de lanzamiento `EXTERNAL`.
+ No se admite SELinux.
+ No se admite la utilización de volúmenes de Amazon EFS ni la especificación de un `EFSVolumeConfiguration`.
+ No se admite la integración con App Mesh.
+ Si utiliza la consola para crear una definición de tareas de instancia externa, debe crear la definición de tareas con el editor JSON de la consola.
+ Cuando utilice una AMI no optimizada para Amazon ECS, ejecute los siguientes comandos en la instancia de contenedor externa para configurar reglas que utilicen los roles de IAM en las tareas. Para obtener más información, consulte [Configuración adicional de las instancias externas](task-iam-roles.md#enable_task_iam_roles).

  ```
  $ sysctl -w net.ipv4.conf.all.route_localnet=1
  $ iptables -t nat -A PREROUTING -p tcp -d 169.254.170.2 --dport 80 -j DNAT --to-destination 127.0.0.1:51679
  $ iptables -t nat -A OUTPUT -d 169.254.170.2 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 51679
  ```

### Red
<a name="ecs-anywhere-networking"></a>

Las instancias externas de Amazon ECS se han optimizado para que puedan ejecutar aplicaciones que generen tráfico o datos del proceso salientes. Si la aplicación requiere tráfico entrante, como un servicio web, la falta de compatibilidad con Elastic Load Balancing hace que la ejecución de estas cargas de trabajo sea menos eficiente porque no se admite la ubicación de estas cargas de trabajo detrás de un balanceador de carga.

A continuación, se incluyen consideraciones adicionales específicas de las redes con las instancias externas. 
+ No se admite el equilibrio de carga del servicio.
+ No se admite la detección de servicios.
+ Las tareas de Linux que se ejecutan en instancias externas deben utilizar los modos de red `bridge`, `host`, o `none`. No se admite el modo de red `awsvpc`. 

  Para obtener más información sobre cada modo de red, consulte [Opciones de red de tareas de Amazon ECS para instancias de EC2](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking.html).
+ Puede poner en marcha tareas de Linux en instancias externas en una configuración de solo IPv6 siempre que las instancias estén en subredes de solo IPv6. Para obtener más información, consulte [Uso de VPC en modo de solo IPv6](task-networking.md#networking-ipv6-only).
+ Existen dominios de servicio de Amazon ECS en cada región y se les debe permitir enviar tráfico a las instancias externas.
+ El SSM Agent que se instaló en la instancia externa mantiene las credenciales de IAM que se rotan cada 30 minutos mediante una huella digital de hardware. Si la instancia externa pierde la conexión con AWS, SSM Agent actualiza automáticamente las credenciales después de que se restablece la conexión. Para obtener más información, consulte [Validación de servidores ubicados en las instalaciones y máquinas virtuales mediante una huella digital de hardware](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-technical-details.html#fingerprint-validation) en la *Guía del usuario de AWS Systems Manager*.

Los siguientes dominios se utilizan para la comunicación entre el servicio de Amazon ECS y el agente de Amazon ECS instalado en la instancia externa. Asegúrese de que se permita el tráfico y de que la resolución DNS funcione. En cada punto de enlace, la *región* representa el identificador de región de una región de AWS compatible con Amazon ECS, como `us-east-2` para la región EE. UU. Este (Ohio). Deben permitirse los puntos de enlace de todas las regiones que utilice. Para los puntos de enlace `ecs-a` y `ecs-t`, debe incluir un asterisco (por ejemplo, `ecs-a-*`).
+ `ecs-a-*.region.amazonaws.com`: este punto de enlace se utiliza cuando se administran tareas.
+ `ecs-t-*.region.amazonaws.com`: este punto de enlace se utiliza para administrar las métricas de tareas y de contenedor.
+ `ecs.region.amazonaws.com`: es el punto de enlace de servicio para Amazon ECS.
+ `ssm.region.amazonaws.com ` — se trata del punto de conexión para AWS Systems Manager.
+ `ec2messages.region.amazonaws.com`: este es el punto de conexión AWS Systems Manager utiliza para comunicarse entre el agente de Systems Manager y el servicio de Systems Manager en la nube.
+ `ssmmessages.region.amazonaws.com`: este punto de conexión necesario para crear y eliminar los canales de sesión con el servicio Session Manager en la nube.
+ Si las tareas requieren comunicación con cualquier otro servicio de AWS, asegúrese de que esos puntos de enlace de servicio se permitan. Las aplicaciones de ejemplo incluyen la utilización de Amazon ECR para extraer imágenes de contenedor o de CloudWatch para CloudWatch Logs. Para obtener más información, consulte [Puntos de enlace de servicio](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html) en la *Referencia general de AWS*.

### Amazon FSx for Windows File Server con ECS Anywhere
<a name="ecs-anywhere-fsx"></a>

**importante**  
Windows ha dejado de ser compatible con Amazon ECS Anywhere. Esta sección ya no es aplicable.

Para utilizar Amazon FSx for Windows File Server con las instancias externas de Amazon ECS debe establecer una conexión entre el centro de datos en las instalaciones y la Nube de AWS. Para obtener más información acerca de las opciones para conectar su red a VPC, consulte [Opciones de conectividad de Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html).

### gMSA con ECS Anywhere
<a name="ecs-anywhere-gmsa"></a>

**importante**  
Windows ha dejado de ser compatible con Amazon ECS Anywhere. Esta sección ya no es aplicable.

Los siguientes casos de uso eran compatibles con ECS Anywhere cuando Windows era un sistema operativo compatible.
+ El Active Directory se encuentra en la Nube de AWS: para esta configuración, cree una conexión de entre la red en las instalaciones y la Nube de AWS mediante una conexión de AWS Direct Connect. Para obtener información acerca de cómo crear la conexión, consulte[Opciones de conectividad de Amazon Virtual Private Cloud](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html). Cree un Active Directory en la Nube de AWS. Para obtener información acerca de cómo empezar a usar AWS Directory Service, consulte [Configuración de AWS Directory Service](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/setting_up.html) en la *Guía de administración de AWS Directory Service*. A continuación, puede unir las instancias externas al dominio mediante la conexión de AWS Direct Connect. Para obtener información acerca de cómo trabajar con gMSA con Amazon ECS, consulte [Obtenga información sobre cómo utilizar gMSA para contenedores de EC2 para Windows en Amazon ECS.](windows-gmsa.md).
+ El Active Directory se encuentra en el centro de datos en las instalaciones. - Para esta configuración, debe unir las instancias externas a Active Directory en las instalaciones. A continuación, se utilizan las credenciales disponibles localmente cuando ejecuta las tareas de Amazon ECS.

# Creación de un clúster de Amazon ECS para cargas de trabajo de instancias externas
<a name="create-cluster-console-v2-ecs-anywhere"></a>

Cree un clúster para definir la infraestructura en la que se ejecutan sus tareas y servicios.

Antes de comenzar, asegúrese de haber seguido los pasos que se detallan en [Configuración para utilizar Amazon ECS](get-set-up-for-amazon-ecs.md) y de asignar el permiso de IAM adecuado. Para obtener más información, consulte [Ejemplos de clústeres de Amazon ECS](security_iam_id-based-policy-examples.md#IAM_cluster_policies). La consola de Amazon ECS ofrece una forma sencilla de crear los recursos que necesita un clúster de Amazon ECS mediante la creación de una pila de CloudFormation. 

Para simplificar al máximo el proceso de creación del clúster, la consola cuenta con selecciones predeterminadas para muchas de las opciones que describimos a continuación. También hay paneles de ayuda disponibles para la mayoría de las secciones de la consola, que proporcionan más contexto. 

Puede modificar las siguientes opciones:
+ Agregue un espacio de nombres al clúster.

  Un espacio de nombres permite que los servicios que cree en el clúster puedan conectarse a los demás servicios del espacio de nombres sin configuración adicional. Para obtener más información, consulte [Interconexión de los servicios de Amazon ECS](interconnecting-services.md).
+ Configurar el clúster para instancias externas
+ Asigne una clave AWS KMS para el almacenamiento administrado. Para obtener información acerca de la creación de una clave, consulte [Creación de una clave KMS](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) en la *Guía del usuario de AWS Key Management Service*.
+ Agregue etiquetas que le permitan identificar el clúster.

**Para crear un nuevo clúster (consola de Amazon ECS)**

1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. En la barra de navegación, seleccione la región a utilizar.

1. En el panel de navegación, seleccione **Clusters (Clústeres)**.

1. En la página **Clusters** (Clústeres), elija **Create Cluster** (Crear clúster).

1. En **Configuraciones del clúster**, configure lo siguiente:
   + En **Nombre del clúster**, escriba un nombre único.

     El nombre puede contener hasta 255 letras (minúsculas y mayúsculas), números y guiones.
   + (Opcional) Para que el espacio de nombre utilizado en Service Connect sea diferente del nombre del clúster, en **Espacio de nombre**, escriba un nombre único.

1. (Opcional) Utilice Información de contenedores, amplíe **Supervisión** y, a continuación, seleccione una de las siguientes opciones:
   + Para usar Información de contenedores con observabilidad mejorada, como se recomienda, elija **Información de contenedores con observabilidad mejorada**.
   + Para usar Información de contenedores, seleccione **Información de contenedores**.

1. (Opcional) Para usar ECS Exec para depurar tareas en el clúster, amplíe la **configuración de solución de problemas** y, a continuación, configure lo siguiente:
   + Seleccione **Activar ECS Exec.**
   + (Opcional) En el caso de **la clave AWS KMS de ECS Exec**, introduzca el ARN de la clave AWS KMS que desee utilizar para cifrar los datos de la sesión de ECS Exec.
   + (Opcional) Para el **registro de ECS Exec**, elija el destino del registro:
     + Para enviar registros a CloudWatch Logs, elija **Amazon CloudWatch**.
     + Para enviar registros a Amazon S3, elija **Amazon S3**.
     + Para deshabilitar el registro, elija **Ninguno**.

1. (Opcional) Cifre los datos en el almacenamiento administrado. En **Cifrado**, para **Almacenamiento administrado**, introduzca el ARN de la clave AWS KMS que desea utilizar para cifrar los datos del almacenamiento administrado.

1. (Opcional) Para ayudar a identificar el clúster, expanda **Tags** (Etiquetas) y, a continuación, configure sus etiquetas.

   [Agregar una etiqueta] Elija **Agregar etiqueta** y haga lo siguiente:
   + En **Key (Clave)**, escriba el nombre de la clave.
   + En **Valor**, escriba el valor de la clave.

1. Seleccione **Crear**.

## Siguientes pasos
<a name="cluster-next-steps-ecs-anywhere"></a>

Debe registrar las instancias en el clúster. Para obtener más información, consulte [Registro de una instancia externa en un clúster de Amazon ECS](ecs-anywhere-registration.md).

Cree una definición de tarea para el tipo de lanzamiento externo. Para obtener más información, consulte [Creación de una definición de tareas de Amazon ECS mediante la consola](create-task-definition.md)

Ponga en marcha sus aplicaciones como tareas independientes o como parte de un servicio. Para obtener más información, consulte los siguientes temas:
+ [Ejecución de una aplicación como tarea de Amazon ECS](standalone-task-create.md)
+ [Creación de una implementación de actualización continua de Amazon ECS](create-service-console-v2.md)

# Registro de una instancia externa en un clúster de Amazon ECS
<a name="ecs-anywhere-registration"></a>

Para cada instancia externa que registre en un clúster de Amazon ECS, debe tener instalados SSM Agent, el agente contenedor de Amazon ECS y Docker. Para registrar la instancia externa en un clúster de Amazon ECS, primero debe registrarse como instancia administrada AWS Systems Manager. El script de instalación se puede crear con unos pocos clics desde la consola de Amazon ECS. El script de instalación incluye una clave de activación de Systems Manager y comandos para instalar cada uno de los agentes requeridos y Docker. El script de instalación se debe ejecutar en el servidor ubicado en las instalaciones o en la máquina virtual para completar los pasos de instalación y registro.

**nota**  
Antes de registrar la instancia externa Linux en el clúster, cree el archivo `/etc/ecs/ecs.config` en la instancia externa y agregue los parámetros de configuración del agente de contenedor que desee. No se puede hacer después de registrar la instancia externa en un clúster. Para obtener más información, consulte [Configuración del agente de contenedor de Amazon ECS](ecs-agent-config.md).

------
#### [ Consola de administración de AWS ]

1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. En la barra de navegación, seleccione la región a utilizar.

1. En el panel de navegación, seleccione **Clusters (Clústeres)**.

1. En la página **Clusters** (Clústeres), elija el clúster en el que desea registrar la instancia externa.

1. En la página de **Cluster : *name*** (Clúster; nombre), elija la pestaña **Infrastructure** (Infraestructura).

1. En la página **Register external instances** (Registrar instancias externas), complete los pasos siguientes.

   1. En **Activation key duration (in days)** (Duración de la clave de activación [en días]), ingrese el número de días durante los que la clave de activación permanece activa. Una vez transcurrido el número de días ingresado, la clave ya no funciona al registrar una instancia externa.

   1. En **Number of instances** (Número de instancias), ingrese el número de instancias externas que desea registrar en el clúster con la clave de activación.

   1. En **Instance role** (Rol de instancia), elija el rol de IAM que desea asociar a las instancias externas. Si aún no se ha creado un rol, elija **Create new role** (Crear nuevo rol) para que Amazon ECS cree un rol en su nombre. Para obtener más información acerca de los permisos de IAM que se requieren para las instancias externas, consulte [Rol de IAM de Amazon ECS Anywhere](iam-role-ecsanywhere.md).

   1.  Copie el comando de registro. Este comando se debe ejecutar en cada instancia externa que desee registrar en el clúster.
**importante**  
La parte Bash del script debe ejecutarse como raíz. Si el comando no se ejecuta como raíz, se genera un error.

   1. Seleccione **Cerrar**.

------
#### [ AWS CLI for Linux operating systems ]

1. Cree un par de activación de Systems Manager. Esto se utiliza para la activación de instancias administradas de Systems Manager. El resultado incluye un `ActivationId` y un `ActivationCode`. Los utilizará en un paso posterior. Asegúrese de especificar el rol de IAM de ECS Anywhere que creó. Para obtener más información, consulte [Rol de IAM de Amazon ECS Anywhere](iam-role-ecsanywhere.md).

   ```
   aws ssm create-activation --iam-role ecsAnywhereRole | tee ssm-activation.json
   ```

1. Descargue el script de instalación en el servidor ubicado en las instalaciones o en la máquina virtual (VM).

   ```
   curl --proto "https" -o "/tmp/ecs-anywhere-install.sh" "https://amazon-ecs-agent.s3.amazonaws.com/ecs-anywhere-install-latest.sh"
   ```

1. (Opcional) En el servidor ubicado en las instalaciones o en la máquina virtual (VM), siga estos pasos para comprobar el script de instalación mediante el archivo SIGNATURE de script.

   1. Descargue e instale GnuPG. Para obtener más información sobre GNUpg, consulte el [sitio web de GnuPG](https://www.gnupg.org). Para sistemas Linux, instale `gpg` utilizando el administrador de paquetes de su versión de Linux.

   1. Recupere la clave pública PGP de Amazon ECS.

      ```
      gpg --keyserver hkp://keys.gnupg.net:80 --recv BCE9D9A42D51784F
      ```

   1. Descargue la firma del script de instalación. La firma es una firma PGP separada en formato ASCII que se almacena en un archivo con la extensión `.asc`.

      ```
      curl --proto "https" -o "/tmp/ecs-anywhere-install.sh.asc" "https://amazon-ecs-agent.s3.amazonaws.com/ecs-anywhere-install-latest.sh.asc"
      ```

   1. Verifique el archivo del script de instalación mediante la clave.

      ```
      gpg --verify /tmp/ecs-anywhere-install.sh.asc /tmp/ecs-anywhere-install.sh
      ```

      El resultado esperado es el siguiente.

      ```
      gpg: Signature made Tue 25 May 2021 07:16:29 PM UTC
      gpg:                using RSA key 50DECCC4710E61AF
      gpg: Good signature from "Amazon ECS <ecs-security@amazon.com>" [unknown]
      gpg: WARNING: This key is not certified with a trusted signature!
      gpg:          There is no indication that the signature belongs to the owner.
      Primary key fingerprint: F34C 3DDA E729 26B0 79BE  AEC6 BCE9 D9A4 2D51 784F
           Subkey fingerprint: D64B B6F9 0CF3 77E9 B5FB  346F 50DE CCC4 710E 61AF
      ```

1. Use el script de instalación en el servidor ubicado en las instalaciones o en la máquina virtual (VM). Especifique el nombre del clúster, la región y el ID de activación de Systems Manager, y el código de activación del primer paso.

   ```
   sudo bash /tmp/ecs-anywhere-install.sh \
       --region $REGION \
       --cluster $CLUSTER_NAME \
       --activation-id $ACTIVATION_ID \
       --activation-code $ACTIVATION_CODE
   ```

   Para un servidor en las instalaciones o una máquina virtual (VM) que tenga el controlador NVIDIA instalado para las cargas de trabajo de la GPU, debe agregar el indicador `--enable-gpu` del script de instalación. Cuando se especifica este indicador, el script de instalación verifica que el controlador NVIDIA se está ejecutando y, a continuación, agrega las variables de configuración necesarias para ejecutar las tareas de Amazon ECS. Para obtener más información acerca de cómo ejecutar cargas de trabajo de GPU y especificar los requisitos de GPU en una definición de tarea, consulte [Especificación de GPU en una definición de tareas de Amazon ECS](ecs-gpu-specifying.md).

   ```
   sudo bash /tmp/ecs-anywhere-install.sh \
       --region $REGION \
       --cluster $CLUSTER_NAME \
       --activation-id $ACTIVATION_ID \
       --activation-code $ACTIVATION_CODE \
       --enable-gpu
   ```

Siga estos pasos para registrar una instancia externa existente en otro clúster.

**Para registrar una instancia externa existente en un clúster diferente**

1. Detenga el agente de contenedor de Amazon ECS.

   ```
   sudo systemctl stop ecs.service
   ```

1. Edite el archivo `/etc/ecs/ecs.config` y, en la línea `ECS_CLUSTER`, asegúrese de que el nombre del clúster coincida con el nombre del clúster con el que se va a registrar la instancia externa.

1. Elimine los datos existentes del agente de Amazon ECS.

   ```
   sudo rm /var/lib/ecs/data/agent.db
   ```

1. Inicie el agente de contenedor de Amazon ECS.

   ```
   sudo systemctl start ecs.service
   ```

------
#### [ AWS CLI for Windows operating systems ]

1. Cree un par de activación de Systems Manager. Esto se utiliza para la activación de instancias administradas de Systems Manager. El resultado incluye un `ActivationId` y un `ActivationCode`. Los utilizará en un paso posterior. Asegúrese de especificar el rol de IAM de ECS Anywhere que creó. Para obtener más información, consulte [Rol de IAM de Amazon ECS Anywhere](iam-role-ecsanywhere.md).

   ```
   aws ssm create-activation --iam-role ecsAnywhereRole | tee ssm-activation.json
   ```

1. Descargue el script de instalación en el servidor ubicado en las instalaciones o en la máquina virtual (VM).

   ```
   Invoke-RestMethod -URI "https://amazon-ecs-agent.s3.amazonaws.com/ecs-anywhere-install.ps1" -OutFile “ecs-anywhere-install.ps1”
   ```

1. (Opcional) Amazon firma el script de Powershell y, por lo tanto, Windows realiza automáticamente la validación del certificado en el mismo. No es necesario realizar ninguna validación manual.

   Para verificar manualmente el certificado, haga clic con el botón derecho en el archivo, vaya a las propiedades y utilice la pestaña Firmas digitales para obtener más detalles.

   Esta opción solo está disponible cuando el host tiene el certificado en el almacén de certificados.

   La verificación debería devolver información similar a la siguiente:

   ```
   # Verification (PowerShell)
   Get-AuthenticodeSignature -FilePath .\ecs-anywhere-install.ps1
   
   SignerCertificate                         Status      Path
   -----------------                         ------      ----
   EXAMPLECERTIFICATE                        Valid       ecs-anywhere-install.ps1
   
   ...
   
   Subject              : CN="Amazon Web Services, Inc.",...
   
   ----
   ```

1. Use el script de instalación en el servidor ubicado en las instalaciones o en la máquina virtual (VM). Especifique el nombre del clúster, la región y el ID de activación de Systems Manager, y el código de activación del primer paso.

   ```
   .\ecs-anywhere-install.ps1 -Region $Region -Cluster $Cluster -ActivationID $ActivationID -ActivationCode $ActivationCode
   ```

1. Verifique que el agente de contenedor de Amazon ECS se esté ejecutando.

   ```
   Get-Service AmazonECS
   
   Status   Name               DisplayName
   ------   ----               -----------
   Running  AmazonECS          Amazon ECS
   ```

Siga estos pasos para registrar una instancia externa existente en otro clúster.

**Para registrar una instancia externa existente en un clúster diferente**

1. Detenga el agente de contenedor de Amazon ECS.

   ```
   Stop-Service AmazonECS
   ```

1. Modifique el parámetro `ECS_CLUSTER` de modo que el nombre del clúster coincida con el nombre del clúster con el que se va a registrar la instancia externa.

   ```
   [Environment]::SetEnvironmentVariable("ECS_CLUSTER", $ECSCluster, [System.EnvironmentVariableTarget]::Machine)
   ```

1. Elimine los datos existentes del agente de Amazon ECS.

   ```
   Remove-Item -Recurse -Force $env:ProgramData\Amazon\ECS\data\*
   ```

1. Inicie el agente de contenedor de Amazon ECS.

   ```
   Start-Service AmazonECS
   ```

------

La AWS CLI se puede utilizar para crear una activación de Systems Manager antes de ejecutar el script de instalación a fin de completar el proceso de registro de instancias externas.

# Anulación del registro de una instancia externa de Amazon ECS
<a name="ecs-anywhere-deregistration"></a>

Le recomendamos que, una vez que termine de utilizar una instancia, anule el registro de la instancia tanto en Amazon ECS como en AWS Systems Manager. Una vez anulado el registro, la instancia externa ya no puede aceptar nuevas tareas.

Si tiene tareas en ejecución en la instancia de contenedor cuando se anula el registro, estas tareas siguen en ejecución hasta que se detengan por otros medios. Sin embargo, Amazon ECS deja de monitorearlas y de considerarlas. Si estas tareas de la instancia externa forman parte de un servicio de Amazon ECS, el programador de servicio inicia otra copia de esa tarea, en una instancia de contenedor distinta, de ser posible.

Después de anular el registro de la instancia, limpie los recursos de AWS de la instancia. A continuación, puede registrarla en un clúster nuevo.

## Procedimiento
<a name="ecs-anywhere-deregistration-procedure"></a>

------
#### [ Consola de administración de AWS ]

1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. En la barra de navegación, elija la región en la que se encuentra registrada la instancia externa.

1. En el panel de navegación, elija **Clusters** (Clústeres) y seleccione el clúster que aloja la instancia externa.

1. En la página de **Cluster : *name*** (Clúster; nombre), elija la pestaña **Infrastructure** (Infraestructura).

1. En **Container instances** (Instancias de contenedor), seleccione el ID de instancia externa cuyo registro desea cancelar. Se lo redirigirá a la página de detalles de la instancia de contenedor.

1. En la página **Container Instance : *id***, seleccione **Deregister**.

1. Revise el mensaje de anulación del registro. Seleccione **Deregister from AWS Systems Manager** (Anular registro de Systems Manager) para anular el registro de la instancia externa como instancia administrada de Systems Manager. Elija **Anular registro**.
**nota**  
Puede anular el registro de la instancia externa como instancia administrada de Systems Manager desde la consola de Systems Manager. Para obtener instrucciones, consulte [Anulación del registro de nodos administrados en un entorno híbrido y multinube](https://docs.aws.amazon.com/systems-manager/latest/userguide/fleet-manager-deregister-hybrid-nodes.html) en la *Guía del usuario de AWS Systems Manager*.

1. Después de anular el registro de la instancia, limpie los recursos de AWS del servidor en las instalaciones o de la VM.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/ecs-anywhere-deregistration.html)

------
#### [ AWS CLI ]

1. Necesita el ID de la instancia y el ARN de la instancia de contenedor para anular el registro de la instancia de contenedor. Si no tiene estos valores, ejecute los siguientes comandos

   Ejecute el siguiente comando para obtener el ID de la instancia.

   Utilice el ID de la instancia (`instanceID`) para obtener el ARN (`containerInstanceARN`) de la instancia de contenedor.

   ```
   instanceId=$(aws ssm describe-instance-information --region "{{ region }}" | jq ".InstanceInformationList[] |select(.IPAddress==\"{{ IPv4 Address }}\") | .InstanceId" | tr -d'"'
   ```

   Use los siguientes comandos.

   Utilice el `containerInstanceArn` como parámetro en el comando para anular el registro de la instancia (`deregister-container-instance`).

   ```
   instances=$(aws ecs list-container-instances --cluster "{{ cluster }}" --region "{{ region }}" | jq -c '.containerInstanceArns')
   containerInstanceArn=$(aws ecs describe-container-instances --cluster "{{ cluster }}" --region "{{ region }}" --container-instances $instances | jq ".containerInstances[] | select(.ec2InstanceId==\"{{ instanceId }}\") | .containerInstanceArn" | tr -d '"')
   ```

1.  Ejecute el siguiente comando para vaciar la instancia.

   ```
   aws ecs update-container-instances-state --cluster "{{ cluster }}" --region "{{ region }}" --container-instances "{{ containerInstanceArn }}" --status DRAINING
   ```

1. Cuando la instancia de contenedor termine de vaciarse, ejecute el siguiente comando para anular el registro de la instancia.

   ```
   aws ecs deregister-container-instance --cluster "{{ cluster }}" --region "{{ region }}" --container-instance "{{ containerInstanceArn }}"
   ```

1. Ejecute el siguiente comando para eliminar las instancias de contenedor desde SSM.

   ```
   aws ssm deregister-managed-instance --region "{{ region }}" --instance-id "{{ instanceId }}"
   ```

1. Después de anular el registro de la instancia, limpie los recursos de AWS del servidor en las instalaciones o de la VM.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/ecs-anywhere-deregistration.html)

------

# Actualización del agente de AWS Systems Manager y del agente de contenedor de Amazon ECS en una instancia externa
<a name="ecs-anywhere-updates"></a>

El servidor ubicado en las instalaciones o la VM deben poner en marcha el agente de AWS Systems Manager (SSM Agent) y el agente de contenedor de Amazon ECS al poner en marcha cargas de trabajo de Amazon ECS. AWS lanza nuevas versiones de estos agentes cuando se agregan o actualizan funciones. Si las instancias externas utilizan una versión anterior de cualquiera de los agentes, puede actualizarlas mediante estos procedimientos.

## Actualización de SSM Agent en una instancia externa
<a name="ecs-anywhere-updates-ssmagent"></a>

AWS Systems Manager recomienda automatizar el proceso de actualización de SSM Agent en las instancias. Proporcionan varios métodos para automatizar las actualizaciones. Para obtener más información, consulte [Automatización de actualizaciones para SSM Agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent-automatic-updates.html) en la *Guía del usuario de AWS Systems Manager*.

## Actualización del agente de Amazon ECS en una instancia externa
<a name="ecs-anywhere-updates-ecsagent"></a>

En las instancias externas, el agente de contenedor de Amazon ECS se actualiza mediante la actualización del paquete `ecs-init`. La actualización del agente de Amazon ECS no interrumpe las tareas o servicios en ejecución. Amazon ECS proporciona el paquete `ecs-init` y el archivo SIGNATURE en un bucket de Amazon S3 en cada región. A partir de la versión `1.52.1-1` de `ecs-init`, Amazon ECS proporciona paquetes `ecs-init` independientes para su utilización en función del sistema operativo y la arquitectura del sistema que utilice la instancia externa. 

Utilice la siguiente tabla para determinar qué paquete `ecs-init` debe descargar en función del sistema operativo y la arquitectura del sistema que utiliza su instancia externa.

**nota**  
Para determinar qué sistema operativo y arquitectura del sistema utiliza la instancia externa, utilice los siguientes comandos.  

```
cat /etc/os-release
uname -m
```


| Sistemas operativos (arquitectura) | Paquete ecs-init | 
| --- | --- | 
|  CentOS 7 (x86\$164) CentOS 8 (x86\$164) CentOS Stream 9 (x86\$164) SUSE Enterprise Server 15 (x86\$164) RHEL 7 (x86\$164) RHEL 8 (x86\$164)  |  `amazon-ecs-init-latest.x86_64.rpm`  | 
|  CentOS 7 (aarch64) CentOS 8 (aarch64) CentOS Stream 9 (aarch64) RHEL 7 (aarch64)  |  `amazon-ecs-init-latest.aarch64.rpm`  | 
|  Debian 9 (x86\$164) Debian 10 (x86\$164) Debian 11 (x86\$164) Debian 12 (x86\$164) Ubuntu 18 (x86\$164) Ubuntu 20 (x86\$164) Ubuntu 22 (x86\$164) Ubuntu 24 (x86\$164)  |  `amazon-ecs-init-latest.amd64.deb`  | 
|  Debian 9 (aarch64) Debian 10 (aarch64) Debian 11 (aarch64) Debian 12 (aarch64) Ubuntu 18 (aarch64) Ubuntu 20 (aarch64) Ubuntu 22 (aarch64) Ubuntu 24 (aarch64)  |  `amazon-ecs-init-latest.arm64.deb`  | 

Siga estos pasos para actualizar el agente de Amazon ECS. 

**Para actualizar el agente de Amazon ECS**

1. Confirme la versión del agente de Amazon ECS que está ejecutando.

   ```
   curl -s 127.0.0.1:51678/v1/metadata | python3 -mjson.tool
   ```

1. Descargue el paquete `ecs-init` correspondiente a su sistema operativo y arquitectura del sistema. Amazon ECS proporciona el archivo del paquete `ecs-init` en un bucket de Amazon S3 en cada región. Asegúrese de sustituir el identificador *<region>* del comando por el nombre de la región (por ejemplo, `us-west-2`) geográficamente más cercana.

   **amazon-ecs-init-latest.x86\$164.rpm**

   ```
   curl -o amazon-ecs-init.rpm https://s3.<region>.amazonaws.com/amazon-ecs-agent-<region>/amazon-ecs-init-latest.x86_64.rpm
   ```

   **amazon-ecs-init-latest.aarch64.rpm**

   ```
   curl -o amazon-ecs-init.rpm https://s3.<region>.amazonaws.com/amazon-ecs-agent-<region>/amazon-ecs-init-latest.aarch64.rpm
   ```

   **amazon-ecs-init-latest.amd64.deb**

   ```
   curl -o amazon-ecs-init.deb https://s3.<region>.amazonaws.com/amazon-ecs-agent-<region>/amazon-ecs-init-latest.amd64.deb
   ```

   **amazon-ecs-init-latest.arm64.deb**

   ```
   curl -o amazon-ecs-init.deb https://s3.<region>.amazonaws.com/amazon-ecs-agent-<region>/amazon-ecs-init-latest.arm64.deb
   ```

1. (Opcional) Verifique la validez del archivo del paquete `ecs-init` mediante la firma PGP.

   1. Descargue e instale GnuPG. Para obtener más información sobre GNUpg, consulte el [sitio web de GnuPG](https://www.gnupg.org). Para sistemas Linux, instale `gpg` utilizando el administrador de paquetes de su versión de Linux.

   1. Recupere la clave pública PGP de Amazon ECS.

      ```
      gpg --keyserver hkp://keys.gnupg.net:80 --recv BCE9D9A42D51784F
      ```

   1. Descargue la firma del paquete `ecs-init`. La firma es una firma PGP separada en formato ASCII que se almacena en un archivo con la extensión `.asc`. Amazon ECS proporciona el archivo SIGNATURE en un bucket de Amazon S3 en cada región. Asegúrese de sustituir el identificador *<region>* del comando por el nombre de la región (por ejemplo, `us-west-2`) geográficamente más cercana.

      **amazon-ecs-init-latest.x86\$164.rpm**

      ```
      curl -o amazon-ecs-init.rpm.asc https://s3.<region>.amazonaws.com/amazon-ecs-agent-<region>/amazon-ecs-init-latest.x86_64.rpm.asc
      ```

      **amazon-ecs-init-latest.aarch64.rpm**

      ```
      curl -o amazon-ecs-init.rpm.asc https://s3.<region>.amazonaws.com/amazon-ecs-agent-<region>/amazon-ecs-init-latest.aarch64.rpm.asc
      ```

      **amazon-ecs-init-latest.amd64.deb**

      ```
      curl -o amazon-ecs-init.deb.asc https://s3.<region>.amazonaws.com/amazon-ecs-agent-<region>/amazon-ecs-init-latest.amd64.deb.asc
      ```

      **amazon-ecs-init-latest.arm64.deb**

      ```
      curl -o amazon-ecs-init.deb.asc https://s3.<region>.amazonaws.com/amazon-ecs-agent-<region>/amazon-ecs-init-latest.arm64.deb.asc
      ```

   1. Verifique el archivo del paquete `ecs-init` mediante la clave.

      **Para los paquetes `rpm`**

      ```
      gpg --verify amazon-ecs-init.rpm.asc ./amazon-ecs-init.rpm
      ```

      **Para los paquetes `deb`**

      ```
      gpg --verify amazon-ecs-init.deb.asc ./amazon-ecs-init.deb
      ```

      El resultado esperado es el siguiente.

      ```
      gpg: Signature made Fri 14 May 2021 09:31:36 PM UTC
      gpg:                using RSA key 50DECCC4710E61AF
      gpg: Good signature from "Amazon ECS <ecs-security@amazon.com>" [unknown]
      gpg: WARNING: This key is not certified with a trusted signature!
      gpg:          There is no indication that the signature belongs to the owner.
      Primary key fingerprint: F34C 3DDA E729 26B0 79BE  AEC6 BCE9 D9A4 2D51 784F
           Subkey fingerprint: D64B B6F9 0CF3 77E9 B5FB  346F 50DE CCC4 710E 61AF
      ```

1. Instale el paquete `ecs-init`.

   **Para el paquete `rpm` en CentOS 7, CentOS 8 y RHEL 7**

   ```
   sudo yum install -y ./amazon-ecs-init.rpm
   ```

   **Para el paquete `rpm` en SUSE Enterprise Server 15**

   ```
   sudo zypper install -y --allow-unsigned-rpm ./amazon-ecs-init.rpm
   ```

   **Para el paquete `deb`**

   ```
   sudo dpkg -i ./amazon-ecs-init.deb
   ```

1. Reinicie el servicio `ecs`.

   ```
   sudo systemctl restart ecs
   ```

1. Verifique que se haya actualizado la versión del agente de Amazon ECS.

   ```
   curl -s 127.0.0.1:51678/v1/metadata | python3 -mjson.tool
   ```

# Actualización de un clúster de Amazon ECS
<a name="update-cluster-v2"></a>

Puede modificar las siguientes propiedaes de clúster:
+ Establecer un proveedor de capacidad predeterminado

  Cada clúster puede tener uno o más proveedores de capacidad y, opcionalmente, una estrategia de proveedor de capacidad. La estrategia de proveedor de capacidad determina cómo se distribuyen las tareas entre los proveedores de capacidad del clúster. Cuando pone en marcha una tarea individual o crea un servicio, utiliza la estrategia de proveedores de capacidad predeterminada del clúster o una estrategia de proveedores de capacidad que anule la estrategia predeterminada.
+ Active Container Insights.

  CloudWatch Container Insights recopila, agrega y resume métricas y registros de las aplicaciones y microservicios en contenedores. Container Insights también proporciona información de diagnóstico, como, por ejemplo, errores de reinicio de contenedores, que usa para aislar problemas y solucionarlos rápidamente. Para obtener más información, consulte [Supervisión de contenedores de Amazon ECS mediante Información de contenedores con capacidad de observabilidad mejorada](cloudwatch-container-insights.md).
+ Agregue etiquetas que le ayuden a identificar los clúster.

**Procedimiento**

1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. En el panel de navegación, seleccione **Clusters (Clústeres)**.

1. En la página **Clusters** (Clústeres), elija el clúster.

1. En la página **Clúster: *nombre***, elija **Actualizar clúster**.

1. Para configurar el proveedor de capacidad predeterminado, en **Estrategia predeterminada del proveedor de capacidad**, elija **Agregar más**.

   1. En **Proveedor de capacidad**, elija el proveedor de capacidad.

   1. (Opcional) En **Base**, introduzca el número mínimo de tareas que se ejecutan en el proveedor de capacidad. 

      Solo puede establecer un valor **base** para un proveedor de capacidad.

   1. (Opcional) En **peso**, introduzca el porcentaje relativo del número total de tareas lanzadas que utiliza el proveedor de capacidad especificado.

   1. (Opcional) Repita los pasos para cualquier proveedor de capacidad adicional.

1. Para activar o desactivar Container Insights, expanda **Supervisión** y, a continuación, active **Utilizar Container Insights**.

1. Para ayudar a identificar el clúster, expanda **Etiquetas** y, a continuación, configure sus etiquetas.

   [Agregar una etiqueta] Elija **Agregar etiqueta** y haga lo siguiente:
   + En **Key (Clave)**, escriba el nombre de la clave.
   + En **Valor**, escriba el valor de la clave.

   [Eliminar una etiqueta] Elija **Eliminar** a la derecha de la clave y el valor de la etiqueta.

1. Elija **Actualizar**.

# Eliminación de un clúster de Amazon ECS
<a name="delete_cluster-new-console"></a>

Si ya ha terminado de usar un clúster, puede eliminarlo. Después de eliminar el clúster, pasa al estado `INACTIVE`. Es posible que los clústeres con estado `INACTIVE` permanezcan detectables en la cuenta durante un período de tiempo. Sin embargo, este comportamiento está sujeto a cambios en el futuro, por lo que no debe contar con la permanencia de los clústeres `INACTIVE`.

Antes de eliminar un clúster, debe realizar las siguientes operaciones:
+ Elimine todos los servicios del clúster. Para obtener más información, consulte [Eliminación de un servicio de Amazon ECS mediante la consola](delete-service-v2.md).
+ Detenga todas las tareas en ejecución actualmente. Para obtener más información, consulte [Detención de una tarea de Amazon ECS](standalone-task-stop.md).
+ Anule el registro de todas las instancias de contenedor registradas del clúster. Para obtener más información, consulte [Anulación del registro de una instancia de contenedor de Amazon ECS](deregister_container_instance.md).
+ Elimine el espacio de nombres de . Para obtener más información, consulte [Eliminación de espacios de nombres](https://docs.aws.amazon.com/cloud-map/latest/dg/deleting-namespaces.html) en la *AWS Cloud MapGuía para desarrolladores de *.

**Procedimiento**

1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. En la barra de navegación, seleccione la región a utilizar.

1. En el panel de navegación, seleccione **Clusters (Clústeres)**.

1. En la página **Clusters**, seleccione el clúster que desea eliminar.

1. En la parte superior derecha de la página, elija **Delete Cluster** (Eliminar clúster). 

   Se muestra un mensaje cuando no ha eliminado todo el recurso asociado al clúster.

1. En el cuadro de confirmación, ingrese **delete *cluster name*** (eliminar nombre de clúster).

# Anulación del registro de una instancia de contenedor de Amazon ECS
<a name="deregister_container_instance"></a>

**importante**  
Este tema aplica solo a instancias de contenedor creadas en Amazon EC2. Para obtener más información acerca de la anulación de registros de instancias externas, consulte [Anulación del registro de una instancia externa de Amazon ECS](ecs-anywhere-deregistration.md).

Cuando ya no necesite una instancia de contenedor respaldada por Amazon EC2, debe anular el registro en el clúster. Tras la cancelación del registro, la instancia de contenedor ya no puede aceptar nuevas tareas.

Si tiene tareas en ejecución en la instancia de contenedor cuando cancela el registro, estas tareas siguen en ejecución hasta que termine la instancia o hasta que las tareas se detengan por otros medios. Sin embargo, estas tareas son huérfanas, es decir, Amazon ECS ya no las monitorea ni las considera). Si una tarea huérfana de la instancia de contenedor forma parte de un servicio de Amazon ECS, el programador de servicio inicia otra copia de esa tarea, en una instancia de contenedor distinta, de ser posible. Se anula el registro de los contenedores de las tareas de servicio huérfanas que estén registradas en un grupo de destino del equilibrador de carga de aplicación. Comienzan el vaciado de conexión de acuerdo con la configuración en el balanceador de carga o grupo de destino. Si una tarea huérfana utiliza el modo de red `awsvpc`, se eliminan sus interfaces de red elásticas.

Si pretende utilizar la instancia de contenedor para algún otro fin después de la cancelación del registro, debe detener todas las tareas que se ejecutan en la instancia de contenedor antes de la cancelación de registro. Esto hace que las tareas sin propietario dejen de consumir recursos.

Al anular el registro de una instancia de contenedor, tenga en cuenta lo siguiente.
+ Ya que cada instancia de contenedor tiene una información de estado única, no se debe cancelar el registro de un clúster y volver a registrarla en otro. Para reubicar los recursos de la instancia de contenedor, le recomendamos que termine las instancias de contenedor en un clúster y lance nuevas instancias de contenedor en el clúster nuevo. Para obtener más información, consulte [Finalizar una instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html) en la *Guía del usuario de Amazon EC2* y [Lanzamiento de una instancia de contenedor de Linux de Amazon ECS](launch_container_instance.md).
+ Si la instancia de contenedor está administrada por un grupo de Auto Scaling o una pila de CloudFormation, termine la instancia mediante la actualización del grupo de Auto Scaling o la pila de CloudFormation. De lo contrario, el grupo de Auto Scaling o CloudFormation crearán una nueva instancia después de que usted la termine.
+ Si termina una instancia de contenedor en ejecución con un agente de contenedor de Amazon ECS conectado, el agente anula automáticamente el registro de la instancia en el clúster. No se cancela automáticamente el registro de las instancias de contenedor paradas o las instancias con agentes desconectados cuando se terminan.
+ La anulación de registro de una instancia de contenedor elimina la instancia de un clúster, pero no termina la instancia de Amazon EC2. Si no va a utilizar más la instancia, asegúrese de terminarla a fin de detener la facturación. Para obtener más información, consulte [Terminar una instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html) en la *Guía del usuario de Amazon EC2*.

## Procedimiento
<a name="deregister_container_instance_procedure"></a>

1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. En la barra de navegación, elija la región en la que se encuentra registrada la instancia externa.

1. En el panel de navegación, elija **Clusters** (Clústeres) y seleccione el clúster que aloja la instancia.

1. En la página de **Cluster : *name*** (Clúster; nombre), elija la pestaña **Infrastructure** (Infraestructura).

1. En **Container instances** (Instancias de contenedor), seleccione el ID de instancia para cancelar el registro. Se lo redirigirá a la página de detalles de la instancia de contenedor.

1. En la página **Container Instance : *id***, seleccione **Deregister**.

1. En la pantalla de confirmación, elija **Anular el registro**.

1. Si no va a utilizar más la instancia de contenedor, termine la instancia de Amazon EC2 subyacente. Para obtener más información, consulte [Finalizar una instancia](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html) en la *Guía del usuario de Amazon EC2*.

# Drenaje de instancias de contenedor de Amazon ECS
<a name="container-instance-draining"></a>

Es posible que, en ocasiones, se deba eliminar una instancia de contenedor de un clúster; por ejemplo, para realizar actualizaciones del sistema o reducir verticalmente la capacidad del clúster. Amazon ECS ofrece la capacidad de pasar de una instancia de contenedor a un estado `DRAINING`. Esto se denomina *vaciado de instancias de contenedor*. Cuando se establece una instancia de contenedor en `DRAINING`, Amazon ECS evita que se programen nuevas tareas para su ubicación en la instancia de contenedor. 

## Comportamiento de drenaje de los servicios
<a name="draining-service-behavior"></a>

Se detiene de inmediato cualquier tarea que forme parte de un servicio que se encuentre en estado `PENDING`. Si la instancia de contenedor tienen capacidad disponible en el clúster, el programador de servicios iniciará las tareas de sustitución. Si la instancia de contenedor no dispone de capacidad suficiente, se enviará un mensaje de evento de servicio indicando el problema.

Las tareas que forman parte de un servicio en la instancia de contenedor y se encuentran en estado `RUNNING` pasan al estado `STOPPED`. El programador de servicios intenta sustituir las tareas de acuerdo con los parámetros `minimumHealthyPercent` y `maximumPercent` de configuración y el tipo de implementación del servicio. Para obtener más información, consulte [Servicios de Amazon ECS](ecs_services.md) y [Parámetros de definición de servicio de Amazon ECS](service_definition_parameters.md).
+ Si `minimumHealthyPercent` está por debajo del 100%, el programador puede hacer caso omiso de `desiredCount` temporalmente durante la sustitución de tareas. Por ejemplo, `desiredCount` son cuatro tareas, un mínimo del 50% permite al programador detener dos tareas existentes antes de iniciar dos nuevas tareas. Si el mínimo es el 100%, el programador de servicio no puede eliminar las tareas existentes hasta que las tareas de sustitución se consideren en buen estado. Si hay tareas para servicios que no utilizan un balanceador de carga en el estado `RUNNING`, se consideran en buen estado. Las tareas para servicios que utilizan un balanceador de carga se consideran en buen estado si están en estado `RUNNING` y el balanceador de carga notifica que la instancia de contenedor en la que están alojados tiene buen estado.
**importante**  
Si usa instancias de spot y `minimumHealthyPercent` es superior o igual al 100 %, el servicio no tendrá tiempo suficiente para reemplazar la tarea antes de que finalice la instancia de spot.
+ El parámetro `maximumPercent` representa un límite superior en la cantidad de tareas en ejecución durante la sustitución de tareas, que permite definir el tamaño del lote de sustitución. Por ejemplo, si `desiredCount` de cuatro tareas, un máximo de 200% comienza cuatro tareas nuevas antes de parar las cuatro tareas que se van a vaciar (siempre que los recursos del clúster requeridos para hacer esto estén disponibles). Si el mínimo es 100%, entonces las tareas de sustitución no pueden comenzar hasta que se hayan parado las tareas de vaciado.
**importante**  
Si tanto `minimumHealthyPercent` como `maximumPercent` son el 100 %, entonces el servicio no puede eliminar las tareas existentes y tampoco puede iniciar tareas de reemplazo. Esto impide el drenaje correcto de las instancias de contenedores e impide realizar nuevas implementaciones.

## Comportamiento de drenaje para tareas independientes
<a name="draining-standalone-behavior"></a>

Las tarea independiente en estado `PENDING` o `RUNNING` no se verán afectadas; debe esperar a que se detengan por su cuenta o detenerlas manualmente. La instancia de contenedor permanecerá en el estado `DRAINING`.

## Comportamiento de vaciado de instancias administradas de Amazon ECS
<a name="managed-instances-draining-behavior"></a>

La terminación de Instancias administradas de Amazon ECS garantiza transiciones de carga de trabajo eficientes y, al mismo tiempo, optimiza los costos y mantiene el sistema en buen estado. El sistema de terminación ofrece tres vías de decisión distintas para la terminación de instancias, cada una con características temporales y perfiles de impacto en los clientes diferentes.

Terminación iniciada por el cliente  
Proporciona un control directo sobre la eliminación de instancias cuando es necesario eliminar inmediatamente las instancias de contenedor del servicio. Se ejecuta `deregister-container-instance` con el parámetro de solicitud `force` establecido en true. Esto significa que es necesaria la terminación inmediata a pesar de que haya cargas de trabajo en ejecución.

Terminación de inactividad iniciada por el sistema  
Instancias administradas de Amazon ECS supervisa de forma continua y optimiza los costos de forma proactiva al terminar las instancias de contenedor de Amazon ECS inactivas que no ejecutan ninguna tarea. ECS utiliza un retraso heurístico para dar a las instancias de contenedor la oportunidad de adquirir las tareas recién lanzadas antes de su terminación. Esto se puede personalizar con el parámetro de configuración del proveedor de capacidad de Instancias administradas de Amazon ECS `scaleInAfter`.

Terminación de actualización de la infraestructura  
Instancias administradas de Amazon ECS administra y actualiza automáticamente el software de las instancias de contenedores administradas para garantizar la seguridad y el cumplimiento y, al mismo tiempo, mantener la disponibilidad de la carga de trabajo mediante un proceso controlado y configurable. Para obtener más información, consulte la [aplicación de revisiones en Instancias administradas de Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/managed-instances-patching.html).

El sistema de terminación implementa un enfoque de dos fases que equilibra la continuidad de la carga de trabajo con los requisitos de administración de la infraestructura.

**Fase 1: periodo de finalización eficiente**  
Durante esta fase, el sistema implementa estrategias de vaciado gradual que priorizan la continuidad de la carga de trabajo. Las tareas de servicio se vacían sin problemas mediante los procesos de programación normales de Amazon ECS. Las tareas independientes siguen en marcha porque es posible que se completen de forma natural. El sistema supervisa que todas las tareas lleguen al estado de parada mediante procesos de finalización naturales.

**Fase 2: cumplimiento de plazos estrictos**  
Cuando la finalización eficiente no permite alcanzar los objetivos de terminaci´n dentro de los plazos aceptables, el sistema implementa un estricto cumplimiento de los plazos. Por lo general, el plazo fijo consiste en vaciar el tiempo de iniciación más siete días, lo que proporciona un tiempo considerable para completarlo de forma gradual y, al mismo tiempo, mantener los requisitos operativos. El cumplimiento incluye procedimientos automáticos de terminación forzosa del registro y terminación inmediata de todas las tareas pendientes, independientemente del estado en que estén terminadas.

Una instancia de contenedor ha completado el vaciado cuando todas las tareas que se ejecutan en la instancia pasan al estado `STOPPED`. La instancia de contenedor permanece en estado `DRAINING` hasta que se vuelva a activar o se elimine. Puede verificar el estado de las tareas de la instancia de contenedor mediante la operación [ListTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ListTasks.html), a través del parámetro `containerInstance`, para obtener una lista de tareas de la instancia, y realizar a continuación la operación [DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html), a través del nombre de recurso de Amazon (ARN) o el ID de cada tarea, para verificar el estado de la tarea.

Cuando esté listo para que la instancia de contenedor comience a alojar nuevamente tareas, cambie el estado de la instancia de contenedor de `DRAINING` a `ACTIVE`. El programador de servicios de Amazon ECS volverá a considerar la instancia de contenedor para la ubicación de tareas.

## Procedimiento
<a name="drain-instances"></a>

Para establecer una instancia de contenedor en vaciado desde la nueva , siga estos pasos Consola de administración de AWS.

También puede utilizar la acción de API [UpdateContainerInstancesState](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateContainerInstancesState.html) o el comando [update-container-instances-state](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-container-instances-state.html) para cambiar el estado de una instancia de contenedor a `DRAINING`.

**Consola de administración de AWS**

1. Abra la consola en [https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2).

1. En el panel de navegación, seleccione **Clusters (Clústeres)**.

1. En la página **Clusters** (Clústeres), elija un clúster que aloja sus instancias.

1. En la página de **Cluster : *name*** (Clúster; nombre), elija la pestaña **Infrastructure** (Infraestructura). En **Container instances** (Instancias de contenedor) seleccione la casilla de verificación junto a cada instancia de contenedor que desee vaciar.

1. Elija **Acciones**, **Vaciar**.

# Cambio del tipo o el tamaño de la instancia fuera del grupo de escalado automático
<a name="container-instance-change-type"></a>

AWS recomienda que mantenga su infraestructura inmutable. Si necesita cambiar el tamaño de instancia, puede hacer lo siguiente: 
+ Escale horizontalmente y agregue instancias adicionales. A continuación, coloque tareas adicionales en esas instancias, o 
+ Escale verticalmente mediante el lanzamiento de una nueva instancia más grande o más pequeña y, a continuación, drene la instancia anterior. 

Ambos enfoques ayudarán a minimizar el impacto en la disponibilidad de las aplicaciones.

Si utilizó otro método para cambiar la instancia, es posible que aparezca el siguiente error: 

```
Container instance type changes are not supported.
```

Cuando aparezca este error, realice los siguientes pasos:

1. Lance nuevas instancias con el tipo de instancia deseado.

1. Drene los tipos de instancias anteriores. Para obtener más información, consulte [Drenaje de instancias de contenedor de Amazon ECS](container-instance-draining.md).

# Instancias de contenedor de EC2 de Amazon ECS
<a name="ecs-agent-versions"></a>

El agente de Amazon ECS es un proceso que se ejecuta en todas las instancias de contenedor que estén registradas en el clúster. Facilita la comunicación entre sus instancias de contenedor y Amazon ECS.

**nota**  
En las instancias de contenedores de Linux, el contenedor de agente monta directorios de nivel superior como `/lib`, `/lib64` y `/proc`. Esto es necesario para las características y funcionalidades de ECS, como los volúmenes de Amazon EBS, el modo de red `awsvpc`, Amazon ECS Service Connect y FireLens para Amazon ECS.

Cada versión del agente de contenedor de Amazon ECS admite un conjunto de características diferente y proporciona correcciones de errores de versiones anteriores. Cuando sea posible, siempre recomendamos utilizar la versión más reciente del agente de contenedor de Amazon ECS. Para actualizar el agente de contenedor a la versión más reciente, consulte [Actualización del agente de contenedor de Amazon ECS](ecs-agent-update.md).

El agente de contenedor de Amazon ECS contiene la imagen `amazon-ecs-pause`. Amazon ECS utiliza esta imagen para las tareas que utilizan el modo de red `awsvpc`.

Para ver las características y mejoras incluidas en cada versión del agente, consulte [https://github.com/aws/amazon-ecs-agent/releases](https://github.com/aws/amazon-ecs-agent/releases).

**importante**  
La versión mínima de Docker para obtener métricas fiables es la versión de Docker `v20.10.13` y versiones posteriores, que se incluyen en la AMI `20220607` optimizada para Amazon ECS y versiones posteriores.  
Los agentes de Amazon ECS versión `1.20.0` y posteriores ya no admiten versiones de Docker anteriores a la `18.01.0`.

## Ciclo de vida
<a name="container-lifecycle"></a>

Cuando el agente de contenedor de Amazon ECS registra una instancia de Amazon EC2 en el clúster, la instancia de Amazon EC2 notifica su estado como `ACTIVE` y su estado de conexión del agente como `TRUE`. Esta instancia de contenedor puede aceptar solicitudes de ejecución de tareas.

Si detiene (no termina) una instancia de contenedor, el estado permanece `ACTIVE`, pero el estado de conexión del agente cambia a `FALSE` en pocos minutos. Cualquier tarea que se estuviera ejecutando en la instancia de contenedor se para. Si vuelve a comenzar la instancia de contenedor, el agente de contenedor vuelve a conectarse al servicio de Amazon ECS, y usted podrá volver a ejecutar tareas en la instancia.

Si cambia el estado de una instancia de contenedor a `DRAINING`, las nuevas tareas no se colocan en la instancia de contenedor. Cualquier tarea de servicio que se ejecute en la instancia de contenedor se elimina, si es posible, para que pueda llevar a cabo las actualizaciones del sistema. Para obtener más información, consulte [Drenaje de instancias de contenedor de Amazon ECS](container-instance-draining.md).

Si cancela el registro o termina una instancia de contenedor, el estado de la instancia de contenedor cambia a `INACTIVE` de inmediato y la instancia de contenedor ya no se notifica cuando se enumeran las instancias de contenedor. No obstante, puede seguir describiendo la instancia de contenedor para una hora tras la terminación. Después de una hora, la descripción de la instancia ya no está disponible.

Puede drenar las instancias manualmente o crear un enlace del ciclo de vida del grupo de Auto Scaling para establecer el estado de la instancia en `DRAINING`. Para obtener más información sobre los enlaces de ciclo de vida de Auto Scaling, consulte [Enlaces de ciclo de vida de Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html).

## Compatibilidad con Docker
<a name="docker-support"></a>

Amazon ECS es compatible con las dos últimas versiones principales de Docker publicadas en Amazon Linux. Actualmente, esto incluye Docker 20.10.x y Docker 25.x.

La versión mínima de Docker necesaria para Amazon ECS se encuentra en el [archivo de especificaciones del agente de Amazon ECS](https://github.com/aws/amazon-ecs-agent/blob/dev/packaging/amazon-linux-ami-integrated/ecs-agent.spec#L53) en GitHub.

Al utilizar la AMI optimizada para Amazon ECS, Docker está previamente instalado y configurado para funcionar con el agente de contenedor de Amazon ECS. La AMI incluye una versión de Docker probada y compatible con Amazon ECS.

**nota**  
Si bien Amazon ECS admite varias versiones de Docker, recomendamos usar la versión de Docker que viene con la AMI optimizada para Amazon ECS para obtener la mejor compatibilidad.

## AMI optimizada para Amazon ECS
<a name="ecs-optimized-ami"></a>

Para obtener más información acerca de la AMI optimizada para Amazon ECS, consulte [AMI de Linux optimizada para Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html).

## Información adicional
<a name="additional-information"></a>

En las páginas siguientes se proporciona información adicional acerca de los cambios:
+ [Registro de cambios del agente de Amazon ECS](https://github.com/aws/amazon-ecs-agent/blob/master/CHANGELOG.md) en GitHub
+ [Notas de la versión de Amazon Linux 2](https://docs.aws.amazon.com/AL2/latest/relnotes/relnotes-al2.html).
+ [Notas de la versión de Docker Engine](https://docs.docker.com/engine/release-notes/27/) en la documentación de Docker
+ [Documentación de controlador NVIDIA](https://docs.nvidia.com/datacenter/tesla/index.html) en la documentación de NVIDIA

# Configuración del agente de contenedor de Amazon ECS
<a name="ecs-agent-config"></a>

**Se aplica a**: instancias de EC2

El agente de contenedor de Amazon ECS admite una serie de opciones de configuración, la mayoría de las cuales se establecen a través de variables de entorno. 

Si la instancia de contenedor se lanzó con la variante de Linux de la AMI optimizada para Amazon ECS, puede establecer estas variables de entorno en el archivo `/etc/ecs/ecs.config` y, a continuación, reiniciar el agente. También puede escribir estas variables de configuración en sus instancias de contenedor con datos de usuario de Amazon EC2 en el momento del lanzamiento. Para obtener más información, consulte [Arranque de instancias de contenedor de Linux de Amazon ECS para la transferencia de datos](bootstrap_container_instance.md).

Si la instancia de contenedor se lanzó con la variante de Windows de la AMI optimizada para Amazon ECS, puede establecer estas variables de entorno en el comando PowerShell SetEnvironmentVariable y luego reiniciar el agente. Para obtener más información, consulte [Ejecución de comandos al lanzar una instancia de EC2 con la entrada de datos de usuario](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) en la *Guía del usuario de Amazon EC2* y [Arranque de instancias de contenedor de Windows de Amazon ECS para la transferencia de datos](bootstrap_windows_container_instance.md).

Si está iniciando manualmente el agente de contenedor de Amazon ECS (para AMI no optimizadas para Amazon ECS), puede utilizar estas variables de entorno en el comando **docker run** que utiliza para iniciar el agente. Utilice estas variables con la sintaxis `--env=VARIABLE_NAME=VARIABLE_VALUE`. En el caso de información confidencial, por ejemplo credenciales de autenticación para repositorios privados, debe almacenar las variables de entorno del agente en un archivo y transmitirlas a la vez con la opción `--env-file path_to_env_file`. Puede utilizar los siguientes comandos para agregar las variables.

```
sudo systemctl stop ecs
sudo vi /etc/ecs/ecs.config 
# And add the environment variables with VARIABLE_NAME=VARIABLE_VALUE format.
sudo systemctl start ecs
```

## Ejecución del agente de Amazon ECS con el espacio de nombres PID del host
<a name="ecs-agent-pid-namespace"></a>

De forma predeterminada, el agente de Amazon ECS se ejecuta con su propio espacio de nombres PID. En las siguientes configuraciones, puede configurar el agente de Amazon ECS para que se ejecute con el espacio de nombres PID del host:
+ El modo de aplicación de SELinux está activado.
+ La política de seguridad SELinux de Docker está establecida como verdadera.

Puede configurar este comportamiento estableciendo la variable de entorno `ECS_AGENT_PID_NAMESPACE_HOST` en `true` en su archivo `/etc/ecs/ecs.config`. Cuando esta variable esté habilitada, `ecs-init` iniciará el contenedor del agente de Amazon ECS con el espacio de nombres PID del host (`--pid=host`), lo que permitirá que el agente se inicie correctamente en entornos que utilizan SELinux. Esta característica está disponible en las versiones de agente `1.94.0` de Amazon ECS y posteriores.

Para habilitar esta característica, agregue la siguiente línea a su archivo `/etc/ecs/ecs.config`:

```
ECS_AGENT_PID_NAMESPACE_HOST=true
```

Tras realizar este cambio, reinicie el agente de Amazon ECS para que surta efecto:

```
sudo systemctl restart ecs
```

Las siguientes características no funcionarán cuando el modo de aplicación de SELinux esté activado y la política de seguridad de Docker esté configurada como verdadera, incluso cuando esté configurado `ECS_AGENT_PID_NAMESPACE_HOST=true`.
+ Amazon ECS Exec
+ Tarea adjunta de Amazon EBS
+ Service Connect
+ FireLens para Amazon ECS

## Parámetros disponibles
<a name="ecs-agent-availparam"></a>

Para obtener más información acerca de la utilización del agente de contenedor, consulte [Parámetros de configuración del agente de contenedor de Amazon ECS](https://github.com/aws/amazon-ecs-agent/blob/master/README.md).

# Almacenamiento de la configuración de instancia de contenedor de Amazon ECS en Amazon S3
<a name="ecs-config-s3"></a>

La configuración del agente de contenedor de Amazon ECS se controla mediante la variable de entorno. Las variantes de Linux de la AMI optimizada para Amazon ECS buscan estas variables en `/etc/ecs/ecs.config` cuando se inicia el agente de contenedor y el agente se configura en consecuencia. Las variables de entorno no sensibles, como `ECS_CLUSTER`, se pueden transmitir a la instancia de contenedor en el lanzamiento a través de los datos de usuario de Amazon EC2 y escribir en este archivo sin consecuencias. No obstante, otro tipo de información confidencial, como las credenciales de AWS o la variable `ECS_ENGINE_AUTH_DATA`, no deben pasarse nunca a una instancia en los datos de usuario ni escribirse en `/etc/ecs/ecs.config` de manera que les permita aparecer en un archivo `.bash_history`.

El almacenamiento de la información de configuración en un bucket privado de Amazon S3 y la concesión de acceso de solo lectura al rol de IAM de instancia de contenedor es una forma práctica y segura de permitir la configuración de instancia de contenedor en el momento del lanzamiento. Puede almacenar una copia del archivo `ecs.config` en un bucket privado. Puede utilizar los datos de usuario de Amazon EC2 para instalar la AWS CLI y copiar la información de configuración en `/etc/ecs/ecs.config` cuando se lance la instancia.

**Para almacenar un archivo `ecs.config` en Amazon S3**

1. Debe conceder permisos al rol de instancia de contenedor (**ecsInstanceRole**) para que tenga acceso de solo lectura a Amazon S3. Para ello, asigne **AmazonS3ReadOnlyAccess** al rol `ecsInstanceRole`. Para obtener información acerca de cómo asociar una política a un rol, consulte [Actualización de los permisos de un rol](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-permissions.html) en la *Guía del usuario de AWS Identity and Access Management*.

1. Cree un `ecs.config` archivo con variables de configuración del agente Amazon ECS válidas con el siguiente formato. En este ejemplo, se configura la autenticación de registros privados. Para obtener más información, consulte [Uso de imágenes de contenedor que no sean de AWS en Amazon ECS](private-auth.md).

   ```
   ECS_ENGINE_AUTH_TYPE=dockercfg
   ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"auth":"zq212MzEXAMPLE7o6T25Dk0i","email":"email@example.com"}}
   ```
**nota**  
Para obtener una lista completa de las variables de configuración del agente Amazon ECS disponibles, consulte [Amazon ECS Container Agent](https://github.com/aws/amazon-ecs-agent/blob/master/README.md) en GitHub.

1. Para almacenar el archivo de configuración, cree un bucket privado en Amazon S3. Para obtener más información, consulte [Creación de un bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html) en la *Guía del usuario de Amazon Simple Storage Service*. 

1. Cargue el archivo `ecs.config` en el bucket de S3. Para obtener más información, consulte [Carga de objetos](https://docs.aws.amazon.com/AmazonS3/latest/userguide/upload-objects.html) en la *Guía del desarrollador de Amazon Simple Storage Service*.

**Para cargar un archivo `ecs.config` desde Amazon S3 en el momento del lanzamiento**

1. Complete los procedimientos indicados anteriormente en esta sección para permitir el acceso de solo lectura de Amazon S3 a las instancias de contenedor y almacenar un archivo `ecs.config` en un bucket de S3 privado.

1. Lance nuevas instancias de contenedor y utilice el siguiente script de ejemplo en Datos de usuario de EC2. El script instala la AWS CLI y copia el archivo de configuración en `/etc/ecs/ecs.config`. Para obtener más información, consulte [Lanzamiento de una instancia de contenedor de Linux de Amazon ECS](launch_container_instance.md).

   ```
   #!/bin/bash
   yum install -y aws-cli
   aws s3 cp s3://your_bucket_name/ecs.config /etc/ecs/ecs.config
   ```

# Instalación del agente de contenedor de Amazon ECS
<a name="ecs-agent-install"></a>

Si desea registrar una instancia de Amazon EC2 en su clúster de Amazon ECS y dicha instancia no utiliza una AMI basada en la AMI optimizada para Amazon ECS, puede instalar el agente de contenedor de Amazon ECS manualmente mediante el siguiente procedimiento. Para ello, puede descargar el agente desde uno de los buckets de Amazon S3 de la región o desde Amazon Elastic Container Registry Public. Si lo descarga de uno de los buckets de Amazon S3 de la región, puede verificar la validez del archivo del agente de contenedor mediante la firma PGP.

**nota**  
Las unidades `systemd` de los servicios de Amazon ECS y de Docker tienen la instrucción de esperar a que `cloud-init` finalice antes de comenzar ambos servicios. El proceso `cloud-init` no se considera finalizado hasta que los datos de usuario de Amazon EC2 hayan terminado de ejecutarse. Por lo tanto, el inicio de Amazon ECS o de Docker a través de los datos de usuario de Amazon EC2 puede provocar un bloqueo. Para comenzar el agente de contenedor mediante los datos de usuario de Amazon EC2, puede utilizar `systemctl enable --now --no-block ecs.service`.

## Instalación del agente de contenedor de Amazon ECS en una instancia de EC2 que no es de Amazon Linux
<a name="ecs-agent-install-nonamazonlinux"></a>

Para instalar el agente de contenedor de Amazon ECS en una instancia de Amazon EC2, puede descargar el agente desde uno de los buckets de Amazon S3 de la región e instalarlo.

**nota**  
Cuando utilice una AMI que no sea de Amazon Linux, la instancia de Amazon EC2 requiere que el `cgroupfs` sea compatible con el controlador `cgroup` para que el agente de Amazon ECS admita los límites de recursos de nivel de tarea. Para obtener más información, consulte [Agente de Amazon ECS en Github](https://github.com/aws/amazon-ecs-agent).

A continuación, se muestran los archivos del agente de contenedor de Amazon ECS más recientes por región para cada arquitectura del sistema, a modo de referencia.


| Región | Nombre de la región | Archivos deb de init de Amazon ECS | Archivos rpm de init de Amazon ECS | 
| --- | --- | --- | --- | 
| us-east-2 | Este de EE. UU. (Ohio) |  [Amazon ECS init amd64](https://s3.us-east-2.amazonaws.com/amazon-ecs-agent-us-east-2/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.us-east-2.amazonaws.com/amazon-ecs-agent-us-east-2/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.us-east-2.amazonaws.com/amazon-ecs-agent-us-east-2/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.us-east-2.amazonaws.com/amazon-ecs-agent-us-east-2/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| us-east-1 | Este de EE. UU. (Norte de Virginia) |  [Amazon ECS init amd64](https://s3.us-east-1.amazonaws.com/amazon-ecs-agent-us-east-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.us-east-1.amazonaws.com/amazon-ecs-agent-us-east-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.us-east-1.amazonaws.com/amazon-ecs-agent-us-east-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.us-east-1.amazonaws.com/amazon-ecs-agent-us-east-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| us-west-1 | Oeste de EE. UU. (Norte de California) |  [Amazon ECS init amd64](https://s3.us-west-1.amazonaws.com/amazon-ecs-agent-us-west-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.us-west-1.amazonaws.com/amazon-ecs-agent-us-west-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.us-west-1.amazonaws.com/amazon-ecs-agent-us-west-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.us-west-1.amazonaws.com/amazon-ecs-agent-us-west-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| us-west-2 | Oeste de EE. UU. (Oregón) |  [Amazon ECS init amd64](https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| ap-east-1 | Asia-Pacífico (Hong Kong) |  [Amazon ECS init amd64](https://s3.ap-east-1.amazonaws.com/amazon-ecs-agent-ap-east-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ap-east-1.amazonaws.com/amazon-ecs-agent-ap-east-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.ap-east-1.amazonaws.com/amazon-ecs-agent-ap-east-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ap-east-1.amazonaws.com/amazon-ecs-agent-ap-east-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| ap-northeast-1 | Asia-Pacífico (Tokio) |  [Amazon ECS init amd64](https://s3.ap-northeast-1.amazonaws.com/amazon-ecs-agent-ap-northeast-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ap-northeast-1.amazonaws.com/amazon-ecs-agent-ap-northeast-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.ap-northeast-1.amazonaws.com/amazon-ecs-agent-ap-northeast-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ap-northeast-1.amazonaws.com/amazon-ecs-agent-ap-northeast-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| ap-northeast-2 | Asia-Pacífico (Seúl) |  [Amazon ECS init amd64](https://s3.ap-northeast-2.amazonaws.com/amazon-ecs-agent-ap-northeast-2/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ap-northeast-2.amazonaws.com/amazon-ecs-agent-ap-northeast-2/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.ap-northeast-2.amazonaws.com/amazon-ecs-agent-ap-northeast-2/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ap-northeast-2.amazonaws.com/amazon-ecs-agent-ap-northeast-2/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| ap-south-1 | Asia-Pacífico (Mumbai) |  [Amazon ECS init amd64](https://s3.ap-south-1.amazonaws.com/amazon-ecs-agent-ap-south-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ap-south-1.amazonaws.com/amazon-ecs-agent-ap-south-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.ap-south-1.amazonaws.com/amazon-ecs-agent-ap-south-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ap-south-1.amazonaws.com/amazon-ecs-agent-ap-south-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| ap-southeast-1 | Asia-Pacífico (Singapur) |  [Amazon ECS init amd64](https://s3.ap-southeast-1.amazonaws.com/amazon-ecs-agent-ap-southeast-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ap-southeast-1.amazonaws.com/amazon-ecs-agent-ap-southeast-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.ap-southeast-1.amazonaws.com/amazon-ecs-agent-ap-southeast-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ap-southeast-1.amazonaws.com/amazon-ecs-agent-ap-southeast-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| ap-southeast-2 | Asia-Pacífico (Sídney) |  [Amazon ECS init amd64](https://s3.ap-southeast-2.amazonaws.com/amazon-ecs-agent-ap-southeast-2/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ap-southeast-2.amazonaws.com/amazon-ecs-agent-ap-southeast-2/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.ap-southeast-2.amazonaws.com/amazon-ecs-agent-ap-southeast-2/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ap-southeast-2.amazonaws.com/amazon-ecs-agent-ap-southeast-2/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| ca-central-1 | Canadá (centro) |  [Amazon ECS init amd64](https://s3.ca-central-1.amazonaws.com/amazon-ecs-agent-ca-central-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.ca-central-1.amazonaws.com/amazon-ecs-agent-ca-central-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.ca-central-1.amazonaws.com/amazon-ecs-agent-ca-central-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.ca-central-1.amazonaws.com/amazon-ecs-agent-ca-central-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| eu-central-1 | Europa (Fráncfort) |  [Amazon ECS init amd64](https://s3.eu-central-1.amazonaws.com/amazon-ecs-agent-eu-central-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.eu-central-1.amazonaws.com/amazon-ecs-agent-eu-central-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.eu-central-1.amazonaws.com/amazon-ecs-agent-eu-central-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.eu-central-1.amazonaws.com/amazon-ecs-agent-eu-central-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| eu-west-1 | Europa (Irlanda) |  [Amazon ECS init amd64](https://s3.eu-west-1.amazonaws.com/amazon-ecs-agent-eu-west-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.eu-west-1.amazonaws.com/amazon-ecs-agent-eu-west-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.eu-west-1.amazonaws.com/amazon-ecs-agent-eu-west-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.eu-west-1.amazonaws.com/amazon-ecs-agent-eu-west-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| eu-west-2 | Europa (Londres) |  [Amazon ECS init amd64](https://s3.eu-west-2.amazonaws.com/amazon-ecs-agent-eu-west-2/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.eu-west-2.amazonaws.com/amazon-ecs-agent-eu-west-2/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.eu-west-2.amazonaws.com/amazon-ecs-agent-eu-west-2/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.eu-west-2.amazonaws.com/amazon-ecs-agent-eu-west-2/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| eu-west-3 | Europa (París) |  [Amazon ECS init amd64](https://s3.eu-west-3.amazonaws.com/amazon-ecs-agent-eu-west-3/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.eu-west-3.amazonaws.com/amazon-ecs-agent-eu-west-3/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.eu-west-3.amazonaws.com/amazon-ecs-agent-eu-west-3/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.eu-west-3.amazonaws.com/amazon-ecs-agent-eu-west-3/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| sa-east-1 | América del Sur (São Paulo) |  [Amazon ECS init amd64](https://s3.sa-east-1.amazonaws.com/amazon-ecs-agent-sa-east-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.sa-east-1.amazonaws.com/amazon-ecs-agent-sa-east-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.sa-east-1.amazonaws.com/amazon-ecs-agent-sa-east-1/amazon-ecs-init-latest.x86_64.rpm) [Amazon ECS init aarch64](https://s3.sa-east-1.amazonaws.com/amazon-ecs-agent-sa-east-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| us-gov-east-1 | AWS GovCloud (Este de EE. UU.) |  [Amazon ECS init amd64](https://s3.us-gov-east-1.amazonaws.com/amazon-ecs-agent-us-gov-east-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.us-gov-east-1.amazonaws.com/amazon-ecs-agent-us-gov-east-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.us-gov-east-1.amazonaws.com/amazon-ecs-agent-us-gov-east-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.us-gov-east-1.amazonaws.com/amazon-ecs-agent-us-gov-east-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 
| us-gov-west-1 | AWS GovCloud (Oeste de EE. UU.) |  [Amazon ECS init amd64](https://s3.us-gov-west-1.amazonaws.com/amazon-ecs-agent-us-gov-west-1/amazon-ecs-init-latest.amd64.deb) (amd64) [Amazon ECS init arm64](https://s3.us-gov-west-1.amazonaws.com/amazon-ecs-agent-us-gov-west-1/amazon-ecs-init-latest.arm64.deb) (arm64)  |  [Amazon ECS init x86\$164](https://s3.us-gov-west-1.amazonaws.com/amazon-ecs-agent-us-gov-west-1/amazon-ecs-init-latest.x86_64.rpm) (x86\$164) [Amazon ECS init aarch64](https://s3.us-gov-west-1.amazonaws.com/amazon-ecs-agent-us-gov-west-1/amazon-ecs-init-latest.aarch64.rpm) (aarch64)  | 

**Para instalar el agente de contenedor de Amazon ECS en una instancia de Amazon EC2 con una AMI que no sea de Amazon Linux**

1. Lance una instancia de Amazon EC2 con un rol de IAM que permita obtener acceso a Amazon ECS. Para obtener más información, consulte [Rol de IAM de instancia de contenedor de Amazon ECS](instance_IAM_role.md).

1. Conéctese a la instancia.

1. Instale la última versión de Docker en su instancia.

1. Compruebe la versión de Docker para verificar que su sistema cumpla con el requisito de la versión mínima. Para obtener más información sobre la compatibilidad de Docker, consulte [Instancias de contenedor de EC2 de Amazon ECS](ecs-agent-versions.md).

   ```
   docker --version
   ```

1. Descargue el archivo del agente correspondiente de Amazon ECS correspondiente correspondiente a su sistema y arquitectura del sistema del sistema e instálelo.

   Para arquitecturas `deb`:

   ```
   ubuntu:~$ curl -O https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.amd64.deb
   ubuntu:~$ sudo dpkg -i amazon-ecs-init-latest.amd64.deb
   ```

   Para arquitecturas `rpm`:

   ```
   fedora:~$ curl -O https://s3.us-west-2.amazonaws.com/amazon-ecs-agent-us-west-2/amazon-ecs-init-latest.x86_64.rpm
   fedora:~$ sudo yum localinstall -y amazon-ecs-init-latest.x86_64.rpm
   ```

1. Edite el archivo `/lib/systemd/system/ecs.service` y agregue la siguiente línea al final de la sección `[Unit]`.

   ```
   After=cloud-final.service
   ```

1. (Opcional) Para registrar la instancia en un clúster distinto del clúster `default`, edite el archivo `/etc/ecs/ecs.config` y agregue los siguientes contenidos. Por ejemplo, lo siguiente especifica el clúster `MyCluster`:

   ```
   ECS_CLUSTER=MyCluster
   ```

   Para obtener más información acerca de estas y otras opciones de tiempo de ejecución de agente, consulte [Configuración del agente de contenedor de Amazon ECS](ecs-agent-config.md). 
**nota**  
Si lo desea, puede almacenar las variables de entorno del agente en Amazon S3 (se pueden descargar en las instancias de contenedor en el momento del lanzamiento utilizando datos de usuario de Amazon EC2). Se recomienda su uso para información confidencial como las credenciales de autenticación para repositorios privados. Para obtener más información, consulte [Almacenamiento de la configuración de instancia de contenedor de Amazon ECS en Amazon S3](ecs-config-s3.md) y [Uso de imágenes de contenedor que no sean de AWS en Amazon ECS](private-auth.md).

1. Inicie el servicio `ecs`.

   ```
   ubuntu:~$ sudo systemctl start ecs
   ```

## Ejecución del agente de Amazon ECS en el modo de red del host
<a name="container_agent_host"></a>

Al ejecutar el agente de contenedor de Amazon ECS, `ecs-init` creará el contenedor del agente de contenedores con el modo de red `host`. Este es el único modo de red compatible para el contenedor de agente de contenedores. 

Esto permite bloquear el acceso al [punto de conexión de servicio de metadatos de la instancia de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) (`http://169.254.169.254`) para los contenedores que inicia el agente de contenedor. Esto garantiza que los contenedores no puedan obtener acceso a las credenciales del rol de IAM desde el perfil de instancia de contenedor y obliga a que las tareas utilicen solo las credenciales del rol de tarea de IAM. Para obtener más información, consulte [Rol de IAM de tarea de Amazon ECS](task-iam-roles.md).

Esto también lo hace para que el agente de contenedor no compita por las conexiones y el tráfico de red en el puente `docker0`.

## Parámetros de configuración del registro del agente de contenedor de Amazon ECS
<a name="agent-logs"></a>

El agente de contenedor de Amazon ECS almacena registros en las instancias de contenedor.

Para el agente de contenedor versión 1.36.0 y posterior, los registros se encuentran de forma predeterminada en `/var/log/ecs/ecs-agent.log` en instancias de Linux y en `C:\ProgramData\Amazon\ECS\log\ecs-agent.log` en instancias de Windows.

Para el agente de contenedor versión 1.35.0 y anterior, los registros se encuentran de forma predeterminada en `/var/log/ecs/ecs-agent.log.timestamp` en instancias de Linux y en `C:\ProgramData\Amazon\ECS\log\ecs-agent.log.timestamp` en instancias de Windows.

De forma predeterminada, los registros de agente rotan cada hora y se almacena un máximo de 24 registros.

A continuación se muestran las variables de configuración del agente de contenedor que se pueden utilizar para cambiar el comportamiento de registro de agente predeterminado. Para obtener información detallada sobre todos los parámetros de configuración disponibles, consulte [Configuración del agente de contenedor de Amazon ECS](ecs-agent-config.md) o el [README del agente de Amazon ECS](https://github.com/aws/amazon-ecs-agent/blob/master/README.md) en GitHub.

Para el agente de contenedor versión 1.36.0 y posterior, a continuación se ofrece un archivo de registro de ejemplo cuando se utiliza el formato `logfmt`.

```
level=info time=2019-12-12T23:43:29Z msg="Loading configuration" module=agent.go
level=info time=2019-12-12T23:43:29Z msg="Image excluded from cleanup: amazon/amazon-ecs-agent:latest" module=parse.go
level=info time=2019-12-12T23:43:29Z msg="Image excluded from cleanup: amazon/amazon-ecs-pause:0.1.0" module=parse.go
level=info time=2019-12-12T23:43:29Z msg="Amazon ECS agent Version: 1.36.0, Commit: ca640387" module=agent.go
level=info time=2019-12-12T23:43:29Z msg="Creating root ecs cgroup: /ecs" module=init_linux.go
level=info time=2019-12-12T23:43:29Z msg="Creating cgroup /ecs" module=cgroup_controller_linux.go
level=info time=2019-12-12T23:43:29Z msg="Loading state!" module=statemanager.go
level=info time=2019-12-12T23:43:29Z msg="Event stream ContainerChange start listening..." module=eventstream.go
level=info time=2019-12-12T23:43:29Z msg="Restored cluster 'auto-robc'" module=agent.go
level=info time=2019-12-12T23:43:29Z msg="Restored from checkpoint file. I am running as 'arn:aws:ecs:us-west-2:0123456789:container-instance/auto-robc/3330a8a91d15464ea30662d5840164cd' in cluster 'auto-robc'" module=agent.go
```

A continuación se ofrece un archivo de registro de ejemplo cuando se utiliza el formato JSON.

```
{"time": "2019-11-07T22:52:02Z", "level": "info", "msg": "Starting Amazon Elastic Container Service Agent", "module": "engine.go"}
```

# Configuración de instancias de contenedor de Amazon ECS para imágenes de Docker privadas
<a name="private-auth-container-instances"></a>

El agente de contenedor de Amazon ECS puede realizar autenticaciones en registros privados, mediante autenticación básica. Cuando se habilita la autenticación de registros privados, puede utilizar las imágenes de Docker privadas en sus definiciones de tareas. Esta característica solo se admite en tareas que utilizan EC2.

Otro método para habilitar la autenticación de registros privados es usar AWS Secrets Manager para almacenar sus credenciales de registros privados de forma segura y hacer referencia a ellas en su definición de contenedor. Esto permite que las tareas usen imágenes de los repositorios privados. Este método es compatible con las tareas que utilizan EC2 o Fargate. Para obtener más información, consulte [Uso de imágenes de contenedor que no sean de AWS en Amazon ECS](private-auth.md).

El agente de contenedor de Amazon ECS busca dos variables de entorno cuando se lanza:
+ `ECS_ENGINE_AUTH_TYPE`, que especifica el tipo de datos de autenticación que se están enviando.
+ `ECS_ENGINE_AUTH_DATA`, que contiene las credenciales de autenticación reales.

Las variantes Linux de la AMI optimizada para Amazon ECS exploran el archivo `/etc/ecs/ecs.config` en busca de estas variables cuando se lanza la instancia de contenedor y cada vez que se inicia el servicio (mediante el comando **sudo start ecs**). Las AMI no optimizadas para Amazon ECS deben almacenar estas variables de entorno en un archivo y pasarlas con la opción `--env-file path_to_env_file` al comando **docker run** que inicia el agente de contenedor.

**importante**  
Recomendamos no introducir estas variables de entorno de autenticación en el momento del lanzamiento de la instancia con los datos de usuario de Amazon EC2 ni transferirlas con la opción `--env` al **docker run**comando . Estos métodos no son adecuados para la información confidencial como las credenciales de autenticación. Para obtener información sobre cómo añadir de forma segura credenciales de autenticación a sus instancias de contenedor, consulte [Almacenamiento de la configuración de instancia de contenedor de Amazon ECS en Amazon S3](ecs-config-s3.md).

## Formatos de autenticación
<a name="docker-auth-formats"></a>

Existen dos formatos disponibles para autenticación de registros privados, `dockercfg` y `docker`.

**Formato de autenticación dockercfg**  
El formato `dockercfg` utiliza la información de autenticación almacenada en el archivo de configuración que se crea cuando se ejecuta el comando **docker login**. Puede crear este archivo ejecutando el comando **docker login** en el sistema local y especificar el nombre de usuario, la contraseña y la dirección de correo electrónico del registro. También puede iniciar sesión en una instancia de contenedor y ejecutar el comando en ella. Dependiendo de su versión de Docker, este archivo se guarda como `~/.dockercfg` o `~/.docker/config.json`.

```
cat ~/.docker/config.json
```

Salida:

```
{
  "auths": {
    "https://index.docker.io/v1/": {
      "auth": "zq212MzEXAMPLE7o6T25Dk0i"
    }
  }
}
```

**importante**  
Las versiones más nuevas de Docker crean un archivo de configuración como se muestra más arriba con un objeto `auths` exterior. El agente de Amazon ECS solo admite los datos de autenticación `dockercfg` que están en el formato siguiente, sin el objeto `auths`. Si tiene instalada la utilidad **jq**, puede extraer estos datos con el siguiente comando: **cat \$1/.docker/config.json \$1 jq .auths**

```
cat ~/.docker/config.json | jq .auths
```

Salida:

```
{
  "https://index.docker.io/v1/": {
    "auth": "zq212MzEXAMPLE7o6T25Dk0i",
    "email": "email@example.com"
  }
}
```

En el ejemplo anterior, se deben agregar las siguientes variables de entorno al archivo de variables de entorno (`/etc/ecs/ecs.config` para la AMI optimizada para Amazon ECS) que el agente de contenedor de Amazon ECS carga en tiempo de ejecución. Si no está utilizando la AMI optimizada para Amazon ECS e inicia el agente manualmente con **docker run**, especifique el archivo de variables de entorno con la opción `--env-file path_to_env_file` al iniciar el agente.

```
ECS_ENGINE_AUTH_TYPE=dockercfg
ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"auth":"zq212MzEXAMPLE7o6T25Dk0i","email":"email@example.com"}}
```

Puede configurar varios registros privados con la sintaxis siguiente:

```
ECS_ENGINE_AUTH_TYPE=dockercfg
ECS_ENGINE_AUTH_DATA={"repo.example-01.com":{"auth":"zq212MzEXAMPLE7o6T25Dk0i","email":"email@example-01.com"},"repo.example-02.com":{"auth":"fQ172MzEXAMPLEoF7225DU0j","email":"email@example-02.com"}}
```

**Formato de autenticación de Docker**  
El formato `docker` utiliza una representación JSON para el servidor de registro en el que el agente se debe autenticar. También incluye los parámetros de autenticación requeridos por dicho registro (por ejemplo, nombre de usuario, contraseña y la dirección de correo electrónico de dicha cuenta). Para una cuenta de Docker Hub, la representación JSON tiene el siguiente aspecto:

```
{
  "https://index.docker.io/v1/": {
    "username": "my_name",
    "password": "my_password",
    "email": "email@example.com"
  }
}
```

En este ejemplo, se deben agregar las siguientes variables de entorno al archivo de variables de entorno (`/etc/ecs/ecs.config` para la AMI optimizada para Amazon ECS) que el agente de contenedor de Amazon ECS carga en tiempo de ejecución. Si no está utilizando la AMI optimizada para Amazon ECS e inicia el agente manualmente con **docker run**, especifique el archivo de variables de entorno con la opción `--env-file path_to_env_file` al iniciar el agente.

```
ECS_ENGINE_AUTH_TYPE=docker
ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"username":"my_name","password":"my_password","email":"email@example.com"}}
```

Puede configurar varios registros privados con la sintaxis siguiente:

```
ECS_ENGINE_AUTH_TYPE=docker
ECS_ENGINE_AUTH_DATA={"repo.example-01.com":{"username":"my_name","password":"my_password","email":"email@example-01.com"},"repo.example-02.com":{"username":"another_name","password":"another_password","email":"email@example-02.com"}}
```

## Procedimiento
<a name="enabling-private-registry"></a>

Utilice el siguiente procedimiento para activar registros privados para las instancias de contenedor.

**Para habilitar los registros privados en la AMI optimizada para Amazon ECS**

1. Inicie sesión en su instancia de contenedor mediante SSH.

1. Abra el archivo `/etc/ecs/ecs.config` y añada los valores `ECS_ENGINE_AUTH_TYPE` y `ECS_ENGINE_AUTH_DATA` para su registro y cuenta:

   ```
   sudo vi /etc/ecs/ecs.config
   ```

   En este ejemplo se autentica una cuenta de usuario de Docker Hub:

   ```
   ECS_ENGINE_AUTH_TYPE=docker
   ECS_ENGINE_AUTH_DATA={"https://index.docker.io/v1/":{"username":"my_name","password":"my_password","email":"email@example.com"}}
   ```

1. Compruebe si su agente utiliza la variable de entorno `ECS_DATADIR` para guardar su estado:

   ```
   docker inspect ecs-agent | grep ECS_DATADIR
   ```

   Salida:

   ```
   "ECS_DATADIR=/data",
   ```
**importante**  
Si el comando anterior no devuelve la variable de entorno `ECS_DATADIR`, debe detener las tareas en ejecución en esta instancia de contenedor antes de detener el agente. Los agentes más recientes con la variable de entorno `ECS_DATADIR` guardan su estado y usted puede detenerlos e iniciarlos mientras que las tareas se ejecuten sin problemas. Para obtener más información, consulte [Actualización del agente de contenedor de Amazon ECS](ecs-agent-update.md).

1. Detenga el servicio `ecs`:

   ```
   sudo stop ecs
   ```

   Salida:

   ```
   ecs stop/waiting
   ```

1. Reinicie el servicio `ecs`.
   + Para la AMI de Amazon Linux 2 optimizada para Amazon ECS:

     ```
     sudo systemctl restart ecs
     ```
   + Para la AMI de Amazon Linux optimizada para Amazon ECS:

     ```
     sudo stop ecs && sudo start ecs
     ```

1. (Opcional) Puede verificar que el agente esté en marcha y ver información acerca de la nueva instancia de contenedor consultando la operación de la API de introspección del agente. Para obtener más información, consulte [Introspección de contenedor de Amazon ECS](ecs-agent-introspection.md).

   ```
   curl http://localhost:51678/v1/metadata
   ```

# Limpieza automática de tareas e imágenes de Amazon ECS
<a name="automated_image_cleanup"></a>

Cada vez que se coloca una tarea en una instancia de contenedor, el agente de contenedor de Amazon ECS comprueba si las imágenes a las que se hace referencia en la tarea son las más recientes de la etiqueta especificada en el repositorio. De lo contrario, el comportamiento predeterminado permite que el agente extraiga las imágenes desde sus repositorios respectivos. Si actualiza las imágenes con frecuencia en las tareas y servicios, el almacenamiento de la instancia de contenedor se puede rellenar rápidamente con imágenes de Docker que ya no utiliza y probablemente no volverá a utilizar. Por ejemplo, podría utilizar una canalización de integración e implementación continuas (CI/CD).

**nota**  
El comportamiento de extracción de imágenes del agente de Amazon ECS se puede personalizar mediante el parámetro `ECS_IMAGE_PULL_BEHAVIOR`. Para obtener más información, consulte [Configuración del agente de contenedor de Amazon ECS](ecs-agent-config.md).

Del mismo modo, los contenedores que pertenecen a tareas detenidas también pueden consumir almacenamiento de la instancia de contenedor con información de registro, volúmenes de datos y otros artefactos. Estos artefactos son útiles para la depuración de contenedores que se han detenido de forma inesperada, pero la mayor parte de este almacenamiento se puede liberar con seguridad tras un periodo de tiempo. 

De forma predeterminada, el agente de contenedor de Amazon ECS limpia automáticamente las tareas detenidas y las imágenes de Docker que no está utilizando ninguna tarea en las instancias de contenedor.

**nota**  
La característica de limpieza automatizada de imágenes requiere al menos la versión 1.13.0 del agente de contenedor de Amazon ECS. Para actualizar el agente a la versión más reciente, consulte [Actualización del agente de contenedor de Amazon ECS](ecs-agent-update.md).

Las siguientes variables de configuración del agente están disponibles para ajustar la experiencia de limpieza de imágenes y tareas automatizada. Para obtener más información acerca de cómo se establecen estas variables en las instancias de contenedor, consulte [Configuración del agente de contenedor de Amazon ECS](ecs-agent-config.md).

`ECS_ENGINE_TASK_CLEANUP_WAIT_DURATION`  
El tiempo de espera predeterminado para eliminar los contenedores de una tarea detenida. Si el valor se establece en menos que 1 segundo, el valor se ignora. De forma predeterminada, este parámetro se establece en 3 horas, pero puede reducir este período a solo 1 minuto, si lo necesita para su aplicación.  
El proceso de limpieza de imágenes no puede eliminar una imagen en tanto en cuando haya un contenedor que haga referencia a la misma. Una vez retirados los contenedores, las imágenes no referenciadas se convierten en candidatas para la limpieza en función de los parámetros de configuración de la limpieza de imágenes.

`ECS_DISABLE_IMAGE_CLEANUP`  
Si establece esta variable como `true`, la limpieza de imagen automatizada se desactiva en la instancia de contenedor y no se elimina ninguna imagen automáticamente.

`ECS_IMAGE_CLEANUP_INTERVAL`  
Esta variable especifica con qué frecuencia debe comprobar el proceso de limpieza de imagen las imágenes para eliminarlas. El valor predeterminado es cada 30 minutos, pero puede reducir este período a solo 10 minutos para eliminar las imágenes con más frecuencia.

`ECS_IMAGE_MINIMUM_CLEANUP_AGE`  
Esta variable especifica la cantidad de tiempo mínima entre la extracción de una imagen y el momento en que puede convertirse en candidata a su eliminación. Esto se utiliza para evitar la limpieza de las imágenes que se acaban de extraer. El valor predeterminado es una hora.

`ECS_NUM_IMAGES_DELETE_PER_CYCLE`  
Esta variable especifica cuántas imágenes se pueden eliminar durante un ciclo de limpieza único. El valor predeterminado es 5 y el mínimo es 1.

Cuando el agente de contenedor de Amazon ECS está en ejecución y no se ha desactivado la limpieza automatizada de imágenes, el agente comprueba si hay imágenes de Docker a las que no se hace referencia en los contenedores en ejecución o detenidos a una frecuencia determinada por la variable `ECS_IMAGE_CLEANUP_INTERVAL`. Si se encuentran imágenes sin utilizar y son más antiguas del tiempo de limpieza mínimo especificado por la variable `ECS_IMAGE_MINIMUM_CLEANUP_AGE`, el agente elimina hasta el número máximo de imágenes especificadas por la variable `ECS_NUM_IMAGES_DELETE_PER_CYCLE`. Se eliminan primero las imágenes a las que se ha hecho referencia menos recientemente. Una vez que las imágenes se han eliminado, el agente espera hasta el siguiente intervalo y vuelve a repetir el proceso.