# Programación de los contenedores en Amazon ECS
<a name="scheduling_tasks"></a>

Amazon Elastic Container Service (Amazon ECS) es un sistema de simultaneidad optimista de estado compartido que ofrece capacidades de programación flexibles para sus cargas de trabajo en contenedores. Los programadores de Amazon ECS utilizan la misma información de estado de clúster que proporciona la API de Amazon ECS para tomar decisiones adecuadas de colocación.

Amazon ECS proporciona un programador de servicio para las tareas y aplicaciones de ejecución prolongada. También ofrece la posibilidad de ejecutar tareas independientes o tareas programadas para trabajos por lotes o tareas que se ejecutan una sola vez. Puede especificar las estrategias de ubicación de tareas y las restricciones para ejecutar las tareas que mejor se adapten a sus necesidades. Por ejemplo, puede especificar si las tareas se ejecutan en varias zonas de disponibilidad o dentro de una sola. Tiene la opción de integrar las tareas con programadores propios personalizados o de terceros.


| Opción | Cuándo se debe usar | Más información | 
| --- | --- | --- | 
| Servicio | El programador de servicios es adecuado para servicios y aplicaciones sin estado, de ejecución prolongada. El programador de servicios también puede asegurarse de que las tareas se registren en una balanceador de carga de Elastic Load Balancing. Puede actualizar los servicios que mantiene el programador de servicios. Esto podría incluir la implementación de una nueva definición de tareas o el cambio del número de tareas deseadas que se ejecutan. De forma predeterminada, el programador de servicios distribuye las tareas en varias zonas de disponibilidad. Sin embargo, puede utilizar estrategias y restricciones de ubicación de tareas para personalizar las decisiones de ubicación de tareas.  | [Servicios de Amazon ECS](ecs_services.md) | 
| Tarea independiente | Una tarea individual es adecuada para procesos tales como trabajos por lotes que hacen el trabajo y, a continuación, se detienen. Por ejemplo, puede tener una llamada de procesos RunTask cuando el trabajo entra en una cola. La tarea extrae trabajo de la cola, realiza el trabajo y, a continuación, se cierra. Al utilizar RunTask, puede permitir que la estrategia predeterminada de ubicación de tareas distribuya las tareas aleatoriamente en el clúster. Esto minimiza las posibilidades de que una sola instancia reciba un número desproporcionado de tareas. | [Tareas independientes de Amazon ECS](standalone-tasks.md) | 
| Tareas programadas | Una tarea programada es adecuada cuando se tienen tareas que se deben ejecutar a intervalos fijos en el clúster; puede utilizar Programador de EventBridge para crear una programación. Puede ejecutar tareas para una operación de copia de seguridad o un análisis de registros. El programa del programador de EventBridge que crea puede ejecutar una o más tareas en el clúster en momentos específicos. El evento programado se puede configurar en un intervalo específico (ejecutar cada N minutos, horas o días). De lo contrario, para una programación más complicada, puede utilizar una expresión cron. | [Uso de Programador de Amazon EventBridge para programar tareas de Amazon ECS](tasks-scheduled-eventbridge-scheduler.md) | 

## Opciones de computación
<a name="compute-option"></a>

Con Amazon ECS, puede especificar la infraestructura en la que se ejecutan sus tareas o servicios. Puede utilizar una estrategia de proveedor de capacidad o un tipo de lanzamiento.

En el caso de Fargate, los proveedores de capacidad son Fargate y Fargate Spot. En EC2, el proveedor de capacidad es el grupo de escalado automático con las instancias de contenedor registradas.

La estrategia del proveedor de capacidad distribuye las tareas entre los proveedores de capacidad asociados al clúster.

Solo los proveedores de capacidad que ya estén asociados a un clúster y tengan un estado `ACTIVE` o `UPDATING` se pueden utilizar en una estrategia de proveedores de capacidad. Puede asociar un proveedor de capacidad a un clúster al crear un clúster. 

En una estrategia de proveedores de capacidad, el valor de *base* opcional designa cuántas tareas, como mínimo, se ejecutan en un proveedor de capacidad especificado. Solo se puede definir una base para uno de los proveedores de capacidad de una estrategia de proveedores de capacidad.

El valor de *peso* designa el porcentaje relativo del número total de tareas lanzadas que utiliza el proveedor de capacidad especificado. Considere el siguiente ejemplo. Tiene una estrategia que contiene dos proveedores de capacidad y ambos tienen un peso de `1`. Cuando se alcanza el porcentaje base, las tareas se dividen en partes iguales entre los dos proveedores de capacidad. Con la misma lógica, suponga que especifica un peso de `1` para *capacityProviderA* y un peso de `4` para *capacityProviderB*. Luego, para cada tarea que se ejecute con *capacityProviderA*, cuatro tareas utilizan *capacityProviderB*.

La opción de computación lanza las tareas directamente en Fargate o en las instancias de Amazon EC2 que haya registrado manualmente en los clústeres.

# Ciclo de vida de las tareas de Amazon ECS
<a name="task-lifecycle-explanation"></a>

Cuando una tarea se inicia, ya sea manualmente o como parte de un servicio, puede pasar por diversos estados antes de que finalice por sí misma o se detenga manualmente. Algunas tareas están destinadas a ejecutarse como tareas por lotes que progresan de forma natural de `PENDING` a `RUNNING` a `STOPPED`. Otras tareas, que pueden formar parte de un servicio, están destinadas a seguir en ejecución indefinidamente o a ampliarse o reducirse en función de las necesidades.

Cuando se solicitan cambios de estado de tareas, por ejemplo, detener una tarea o actualizar el recuento deseado de un servicio para ampliarla o reducirla, el agente de contenedor de Amazon ECS realiza el seguimiento de estos cambios como el último estado conocido (`lastStatus`) y el estado deseado (`desiredStatus`) de la tarea. Tanto el último estado conocido como el estado deseado de una tarea se pueden ver en la consola o mediante la descripción de la tarea con la API o AWS CLI.

El siguiente diagrama de flujo muestra el flujo del ciclo de vida de la tarea.

![\[Diagrama de los estados del ciclo de vida de las tareas. Los estados son PROVISIONING, PENDING, ACTIVATING, RUNNING, DEACTIVATING, STOPPING.\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/images/task-lifecycle.png)


## Estados del ciclo de vida
<a name="lifecycle-states"></a>

A continuación se indican las descripciones de cada uno de los estados de ciclo de vida de la tarea.

PROVISIONING  
Amazon ECS tiene que realizar pasos adicionales antes de que se lance la tarea. Por ejemplo, para las tareas que utilizan el modo de red `awsvpc`, la interfaz de red elástica se tiene que aprovisionar.

PENDIENTE  
Se trata de un estado de transición en el que Amazon ECS está a la espera de que el agente de contenedor realice otras acciones. Una tarea permanecerá en estado pendiente hasta que haya recursos disponibles para la tarea.

ACTIVATING  
Este es un estado de transición en el que Amazon ECS tiene que realizar pasos adicionales después de la tarea se haya lanzado, pero antes de que pueda pasar al estado `RUNNING`. Este es el estado en el que Amazon ECS extrae las imágenes de los contenedores, crea los contenedores, configura la red de tareas, registra los grupos de destino del equilibrador de carga y configura la detección de servicios.

RUNNING  
La tarea se ejecuta correctamente.

DEACTIVATING  
Este es un estado de transición en el que Amazon ECS tiene que realizar pasos adicionales antes de que la tarea se haya detenido. Por ejemplo, en el caso de tareas que forman parte de un servicio configurado para utilizar varios grupos de destino de Elastic Load Balancing, durante este estado se produce la anulación del registro del grupo de destino.

STOPPING  
Se trata de un estado de transición en el que Amazon ECS está a la espera de que el agente de contenedor realice otras acciones.  
En el caso de los contenedores de Linux, el agente de contenedor enviará la señal de detención definida en la imagen del contenedor para notificar que la aplicación debe finalizarse y apagarse mediante la instrucción `STOPSIGNAL`. Este es `SIGTERM` de forma predeterminada. A continuación, enviará `SIGKILL` tras esperar durante el tiempo `StopTimeout` establecido en la definición de la tarea. 

DEPROVISIONING  
Amazon ECS tiene que realizar pasos adicionales después de que la tarea se haya detenido, pero antes de que pase al estado `STOPPED`. Por ejemplo, para las tareas que utilizan el modo de red `awsvpc`, la interfaz de red elástica se tiene que desasociar y eliminar.

STOPPED  
La tarea se ha detenido correctamente.  
Si la tarea se detuvo debido a un error, consulte [Visualización de los errores de las tareas detenidas de Amazon ECS](stopped-task-errors.md).

DELETED  
Se trata de un estado de transición en el que se detiene una tarea. Este estado no se muestra en la consola, pero se muestra en `describe-tasks`.

# Cómo coloca Amazon ECS las tareas en las instancias de contenedor
<a name="task-placement"></a>

Puede usar la ubicación de tareas para configurar Amazon ECS de manera que coloque sus tareas en instancias de contenedor que cumplan ciertos requisitos, por ejemplo, una zona de disponibilidad o un tipo de instancia.

Los siguientes son componentes de ubicación de tareas:
+ Estrategia de ubicación de tareas: el algoritmo para seleccionar instancias de contenedor para ubicación de tareas o tareas para terminación. Por ejemplo, Amazon ECS puede seleccionar las instancias de contenedor de manera aleatoria o de modo que las tareas se distribuyan de forma uniforme entre un grupo de instancias.
+ Grupo de tareas: grupo de tareas relacionadas, por ejemplo, tareas de bases de datos.
+ Restricción de ubicación de tareas: se trata de reglas que se deben cumplir para colocar una tarea en una instancia de contenedor. Si no se cumple la restricción, la tarea no se desplegará y permanecerá en el estado `PENDING`. Por ejemplo, puede utilizar una restricción para colocar tareas únicamente en un tipo de instancia concreto. 

Amazon ECS tiene diferentes algoritmos para las distintas opciones de capacidad. 

## Instancias administradas de Amazon ECS
<a name="managed-instances-launch-type"></a>

En el caso de las tareas que se pongan en marcha en instancias administradas de Amazon ECS, Amazon ECS debe determinar dónde se colocará la tarea y, al reducir verticalmente el recuento de tareas, qué tareas se finalizarán. Amazon ECS toma esta decisión en función de los requisitos de instancia especificados en la plantilla de inicialización del proveedor de capacidad, los requisitos especificados en la definición de la tarea, como la CPU y la memoria, y las restricciones de ubicación de tareas.

**nota**  
Instancias administradas de Amazon ECS no es compatible con las estrategias de ubicación de tareas. Amazon ECS hará todo lo posible para distribuir las tareas entre las zonas de disponibilidad accesibles.

Cuando Amazon ECS ubica las tareas, utiliza este proceso para seleccionar instancias de contenedor:

1. Identificar las instancias de contenedor que satisfacen los requisitos de CPU, GPU, memoria y puerto en la definición de tareas.

1. Identificar las instancias de contenedor que satisfacen las restricciones de ubicación de tareas.

1. Identificar las instancias de contenedor que satisfacen los requisitos de instancia especificados en la plantilla de inicialización del proveedor de capacidad.

1. Seleccionar las instancias de contenedor para ubicación de tareas.

## EC2
<a name="ec2-launch-type"></a>

Para las tareas que utilizan el tipo de lanzamiento de EC2, Amazon ECS debe determinar dónde se colocará la tarea en función de los requisitos especificados en la definición de la tarea, como la CPU y la memoria. Del mismo modo, cuando se reduce la escala del número de tareas, Amazon ECS debe determinar qué tareas debe terminar. Puede aplicar estrategias y restricciones de ubicación de tareas para personalizar la manera en la que Amazon ECS ubica y termina las tareas. 

Las estrategias de ubicación de tareas por defecto dependen de si ejecuta las tareas manualmente (tareas independientes) o dentro de un servicio. Para las tareas que se ejecutan como parte de un servicio de Amazon ECS, la estrategia de ubicación de tareas es `spread` mediante `attribute:ecs.availability-zone`. No existe una restricción de ubicación de tareas predeterminada para las tareas que no están en los servicios. Para obtener más información, consulte [Programación de los contenedores en Amazon ECS](scheduling_tasks.md).

**nota**  
Las estrategias de ubicación de tareas se realizan en la medida de lo posible. Amazon ECS sigue intentando ubicar tareas, incluso cuando la opción de ubicación más adecuada no está disponible. Sin embargo, las restricciones de ubicación de tareas son vinculantes, y pueden impedir la ubicación de tareas. 

Puede utilizar juntas estrategias y restricciones de ubicación de tareas. Por ejemplo, puede utilizar una estrategia de ubicación de tareas y una delimitación de ubicación de tareas para distribuir tareas entre las zonas de disponibilidad y agruparlas en bin packing en función de la memoria de cada zona de disponibilidad, pero únicamente si se trata de instancias G2.

Cuando Amazon ECS ubica las tareas, utiliza este proceso para seleccionar instancias de contenedor:

1. Identificar las instancias de contenedor que satisfacen los requisitos de CPU, GPU, memoria y puerto en la definición de tareas.

1. Identificar las instancias de contenedor que satisfacen las restricciones de ubicación de tareas.

1. Identificar las instancias de contenedor que satisfacen las estrategias de ubicación de tareas.

1. Seleccionar las instancias de contenedor para ubicación de tareas.

## Fargate
<a name="fargate-launch-type"></a>

No se admiten las estrategias ni las restricciones de ubicación de tareas para tareas que utilizan Fargate. Fargate hará todo lo posible para distribuir las tareas entre las zonas de disponibilidad accesibles. Si el proveedor de capacidad incluye Fargate y Fargate Spot, el comportamiento de distribución es independiente para cada proveedor de capacidad. 

# Escalado automático y ubicación de tareas de instancias administradas de Amazon ECS
<a name="managed-instance-auto-scaling"></a>

Instancias administradas de Amazon ECS utiliza algoritmos inteligentes para escalar automáticamente la capacidad del clúster y colocar las tareas de manera eficiente en toda la infraestructura. Entender cómo funcionan estos algoritmos lo ayuda a optimizar las configuraciones de los servicios y a solucionar problemas de comportamiento de ubicación.

## Algoritmo de ubicación de tareas
<a name="managed-instance-task-placement-algorithm"></a>

Instancias administradas de Amazon ECS utiliza un algoritmo de ubicación sofisticado que equilibra la disponibilidad, la utilización de los recursos y los requisitos de la red al programar tareas.

### Distribución por zonas de disponibilidad
<a name="managed-instance-az-spread-behavior"></a>

De forma predeterminada, instancias administradas de Amazon ECS prioriza la disponibilidad al distribuir las tareas entre varias zonas de disponibilidad:
+ En el caso de los servicios con varias tareas, instancias administradas de Amazon ECS garantiza la distribución en al menos tres instancias en diferentes zonas de disponibilidad siempre que sea posible
+ Este comportamiento proporciona tolerancia a errores, pero puede provocar una menor utilización de los recursos por instancia
+ La distribución por zonas de disponibilidad tiene prioridad sobre la optimización del empaquetado de contenedores

### Comportamiento del empaquetado de contenedores
<a name="managed-instance-bin-packing"></a>

Si bien instancias administradas de Amazon ECS puede empaquetar en contenedores para maximizar el uso de los recursos, este comportamiento depende de la configuración de la red:
+ Para realizar el empaquetado de contenedores, configure el servicio para que utilice una única subred
+ Las configuraciones de varias subredes priorizan la distribución de las zonas de disponibilidad por encima de la densidad de los recursos
+ Es más probable que se empaqueten contenedores durante la inicialización inicial del servicio que durante los eventos de escalado

### Consideraciones sobre la densidad de ENI
<a name="managed-instance-eni-density"></a>

En el caso de los servicios que utilizan el modo de red `awsvpc`, instancias administradas de Amazon ECS tiene en cuenta la densidad de la interfaz de red elástica (ENI) al tomar decisiones sobre la ubicación:
+ Cada tarea del modo `awsvpc` requiere una ENI específica
+ Los tipos de instancias tienen diferentes límites de ENI que afectan a la densidad de tareas
+ Instancias administradas de Amazon ECS tiene en cuenta la disponibilidad de ENI al seleccionar las instancias de destino

**nota**  
Continuamente se realizan mejoras en los cálculos de densidad de ENI para optimizar las decisiones de ubicación.

## Lógica de decisiones del proveedor de capacidad
<a name="managed-instance-capacity-provider-decisions"></a>

Los proveedores de capacidad de instancias administradas de Amazon ECS toman decisiones sobre el escalado y la ubicación en función de varios factores:

Requisitos de recursos  
Requisitos de CPU, memoria y red de las tareas pendientes

Disponibilidad de instancias  
Capacidad y utilización actuales en las instancias existentes

Restricciones de red  
Configuración de subred y disponibilidad de ENI

Distribución de zonas de disponibilidad  
Mantenimiento de la tolerancia a errores en varias zonas de disponibilidad

## Opciones de configuración
<a name="managed-instance-configuration-options"></a>

### Estrategia de selección de subredes
<a name="managed-instance-subnet-strategy"></a>

La configuración de subred afecta significativamente al comportamiento de ubicación de tareas:

Varias subredes (predeterminado)  
Prioriza la distribución por zonas de disponibilidad para lograr una alta disponibilidad  
Puede resultar en una menor utilización de los recursos por instancia  
Se recomienda para las cargas de trabajo de producción que necesitan tolerancia a errores

Subred única  
Permite el empaquetado de contenedores para una mayor utilización de los recursos  
Reduce la tolerancia a errores al concentrar las tareas en una zona de disponibilidad  
Adecuado para las cargas de trabajo de desarrollo o con optimización de costos

### Consideraciones sobre el modo de red
<a name="managed-instance-network-mode-considerations"></a>

El modo de red que elija afecta a las decisiones de ubicación:
+ Modo `awsvpc`: cada tarea requiere una ENI específica, lo que limita la densidad de tareas por instancia
+ Modo `host`: las tareas utilizan la red del host directamente, y su ubicación depende principalmente de la disponibilidad de los recursos

### Consideraciones sobre la arquitectura de CPU
<a name="managed-instance-cpu-architecture-considerations"></a>

El valor de `cpuArchitecture` que especifique en la definición de la tarea se utiliza para colocar las tareas en una arquitectura específica. Si no especifica un valor para `cpuArchitecture`, Amazon ECS intentará colocar las tareas en cualquier arquitectura de CPU disponible en función de la configuración del proveedor de capacidad. Puede especificar `X86_64` o `ARM64`.

## Resolución de problemas relacionados con la ubicación de tareas
<a name="managed-instance-troubleshooting-placement"></a>

### Patrones de ubicación comunes
<a name="managed-instance-common-placement-patterns"></a>

Comprender los patrones de ubicación esperados ayuda a distinguir el comportamiento normal de los posibles problemas:

Distribución repartida  
Tareas distribuidas en varias instancias con un uso parcial  
Comportamiento normal cuando se utilizan varias subredes  
Indica que se prioriza la disponibilidad por encima de la eficiencia de los recursos

Ubicación concentrada  
Varias tareas asignadas a un menor número de instancias con una mayor utilización  
Se espera cuando se utiliza una configuración de subred única  
Puede producirse durante el lanzamiento inicial del servicio

Distribución desigual  
Algunas instancias se utilizan mucho, mientras que otras permanecen infrautilizadas  
Puede indicar límites de ENI o restricciones de recursos  
Considere la posibilidad de revisar los tipos de instancias y la configuración de la red

### Optimización del comportamiento de ubicación
<a name="managed-instance-placement-optimization"></a>

Para optimizar la ubicación de las tareas en función de los requisitos específicos:

1. Evalúe los requisitos de disponibilidad según las necesidades de optimización de costos

1. Elija la configuración de subred adecuada según sus prioridades

1. Seleccione los tipos de instancias con la capacidad de ENI adecuada para su modo de red

1. Supervise los patrones de ubicación y ajuste la configuración según sea necesario

## Prácticas recomendadas
<a name="managed-instance-best-practices"></a>
+ **Para las cargas de trabajo de producción**: utilice varias subredes en diferentes zonas de disponibilidad para garantizar una alta disponibilidad y acepte la compensación en la utilización de los recursos
+ **Para el desarrollo o las pruebas**: considere la posibilidad de configurar una sola subred para maximizar la utilización de los recursos y reducir los costos
+ **Para el modo `awsvpc`**: elija tipos de instancias que tengan suficiente capacidad de ENI para evitar restricciones de ubicación
+ **Para la optimización de costos**: supervise los patrones de utilización y ajuste la configuración del servicio para equilibrar la disponibilidad y la eficiencia
+ **Para la solución de problemas**: revise la configuración de la subred y el modo de red cuando investigue patrones de ubicación inesperados

# Uso de estrategias para definir la ubicación de las tareas de Amazon ECS
<a name="task-placement-strategies"></a>

Para las tareas que utilizan el tipo de lanzamiento de EC2, Amazon ECS debe determinar dónde se colocará la tarea en función de los requisitos especificados en la definición de la tarea, como la CPU y la memoria. Del mismo modo, cuando se reduce la escala del número de tareas, Amazon ECS debe determinar qué tareas debe terminar. Puede aplicar estrategias y restricciones de ubicación de tareas para personalizar la manera en la que Amazon ECS ubica y termina las tareas. 

Las estrategias de ubicación de tareas por defecto dependen de si ejecuta las tareas manualmente (tareas independientes) o dentro de un servicio. Para las tareas que se ejecutan como parte de un servicio de Amazon ECS, la estrategia de ubicación de tareas es `spread` mediante `attribute:ecs.availability-zone`. No existe una restricción de ubicación de tareas predeterminada para las tareas que no están en los servicios. Para obtener más información, consulte [Programación de los contenedores en Amazon ECS](scheduling_tasks.md).

**nota**  
Las estrategias de ubicación de tareas se realizan en la medida de lo posible. Amazon ECS sigue intentando ubicar tareas, incluso cuando la opción de ubicación más adecuada no está disponible. Sin embargo, las restricciones de ubicación de tareas son vinculantes, y pueden impedir la ubicación de tareas. 

Puede utilizar juntas estrategias y restricciones de ubicación de tareas. Por ejemplo, puede utilizar una estrategia de ubicación de tareas y una delimitación de ubicación de tareas para distribuir tareas entre las zonas de disponibilidad y agruparlas en bin packing en función de la memoria de cada zona de disponibilidad, pero únicamente si se trata de instancias G2.

Cuando Amazon ECS ubica las tareas, utiliza este proceso para seleccionar instancias de contenedor:

1. Identificar las instancias de contenedor que satisfacen los requisitos de CPU, GPU, memoria y puerto en la definición de tareas.

1. Identificar las instancias de contenedor que satisfacen las restricciones de ubicación de tareas.

1. Identificar las instancias de contenedor que satisfacen las estrategias de ubicación de tareas.

1. Seleccionar las instancias de contenedor para ubicación de tareas.

Las estrategias de ubicación de tareas se especifican en la definición del servicio o en la definición de la tarea mediante el parámetro `placementStrategy`.

```
"placementStrategy": [
    {
        "field": "The field to apply the placement strategy against",
        "type": "The placement strategy to use"
    }
]
```

Puede especificar las estrategias al ejecutar una tarea ([RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html)), crear un nuevo servicio ([CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html)) o actualizar un servicio existente ([UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)).

En la tabla siguiente, se describen los tipos y campos disponibles.


| tipo | Valores de campo válidos | 
| --- | --- | 
| binpack Las tareas se colocan en instancias de contenedor para dejar la menor cantidad de CPU o memoria sin usar. Esta estrategia minimiza el número de instancias de contenedor en uso. Cuando se utiliza esta estrategia y se realiza una acción de reducción horizontal, Amazon ECS termina las tareas. Lo hace en función de la cantidad de recursos que quedan en la instancia del contenedor una vez terminada la tarea. La instancia de contenedor que tenga la mayor cantidad de recursos disponibles después de la terminación de la tarea hace que esa tarea termine. |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/task-placement-strategies.html)  | 
| random Las tareas se colocan aleatoriamente. | No se utiliza | 
| spreadLas tareas se colocan uniformemente en función del valor especificado. Las tareas de servicio se distribuyen en función de las tareas de dicho servicio. Las tareas independientes se distribuyen en función de las tareas del mismo grupo de tareas. Para obtener más información acerca de los grupos de tareas, consulte [Agrupación de tareas relacionadas con Amazon ECS](task-groups.md). Cuando se utiliza la estrategia `spread` y se realiza una acción de reducción horizontal, Amazon ECS selecciona las tareas que mantienen un balance entre las zonas de disponibilidad para terminarlas. Dentro de una zona de disponibilidad, las tareas se seleccionan de manera aleatoria. |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/task-placement-strategies.html)  | 

Las estrategias de colocación de tareas también se pueden actualizar para los servicios existentes. Para obtener más información, consulte [Cómo coloca Amazon ECS las tareas en las instancias de contenedor](task-placement.md).

Puede crear una estrategia de ubicación de tareas que utilice varias estrategias mediante la creación de conjuntos de estrategias en el orden en que desee que se realicen. Por ejemplo, si desea distribuir las tareas entre las zonas de disponibilidad y, a continuación, agrupar las tareas en función de la memoria de cada zona de disponibilidad, especifique la estrategia de la zona de disponibilidad seguida de la estrategia de memoria. Para ver ejemplos de estrategias, consulte [Ejemplo de estrategias de ubicación de tareas de Amazon ECS](strategy-examples.md).

# Ejemplo de estrategias de ubicación de tareas de Amazon ECS
<a name="strategy-examples"></a>

Puede especificar estrategias de ubicación de tarea con las acciones siguientes: [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html), [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) y [RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html).

**Topics**
+ [Distribuir las tareas de manera uniforme entre zonas de disponibilidad](#even-az)
+ [Distribuir las tareas de manera uniforme en todas las instancias](#even-instance)
+ [Agrupar tareas en bin packing en función de la memoria](#binpack)
+ [Ubicar las tareas de forma aleatoria](#random)
+ [Distribuir las tareas de forma uniforme en las zonas de disponibilidad y, a continuación, distribuir las tareas de forma uniforme entre las instancias dentro de cada zona de disponibilidad](#az-instance)
+ [Distribuir las tareas de forma uniforme en las zonas de disponibilidad y, a continuación, agrupar en bin packing las tareas en función de la memoria dentro de cada zona de disponibilidad](#az-memory)
+ [Distribuir las tareas de manera uniforme entre las instancias y, a continuación, agrupar las tareas en bin packing según la memoria](#instance-memory)

## Distribuir las tareas de manera uniforme entre zonas de disponibilidad
<a name="even-az"></a>

La estrategia siguiente distribuye las tareas de forma uniforme entre las zonas de disponibilidad.

```
"placementStrategy": [
    {
        "field": "attribute:ecs.availability-zone",
        "type": "spread"
    }
]
```

## Distribuir las tareas de manera uniforme en todas las instancias
<a name="even-instance"></a>

La estrategia siguiente distribuye las tareas de forma uniforme entre todas las instancias.

```
"placementStrategy": [
    {
        "field": "instanceId",
        "type": "spread"
    }
]
```

## Agrupar tareas en bin packing en función de la memoria
<a name="binpack"></a>

La estrategia siguiente agrupa las tareas en bin packing en función de la memoria.

```
"placementStrategy": [
    {
        "field": "memory",
        "type": "binpack"
    }
]
```

## Ubicar las tareas de forma aleatoria
<a name="random"></a>

La siguiente estrategia ubica las tareas aleatoriamente.

```
"placementStrategy": [
    {
        "type": "random"
    }
]
```

## Distribuir las tareas de forma uniforme en las zonas de disponibilidad y, a continuación, distribuir las tareas de forma uniforme entre las instancias dentro de cada zona de disponibilidad
<a name="az-instance"></a>

La siguiente estrategia distribuye las tareas de forma uniforme en las zonas de disponibilidad y, a continuación, distribuye las tareas de forma uniforme entre las instancias dentro de cada zona de disponibilidad.

```
"placementStrategy": [
    {
        "field": "attribute:ecs.availability-zone",
        "type": "spread"
    },
    {
        "field": "instanceId",
        "type": "spread"
    }
]
```

## Distribuir las tareas de forma uniforme en las zonas de disponibilidad y, a continuación, agrupar en bin packing las tareas en función de la memoria dentro de cada zona de disponibilidad
<a name="az-memory"></a>

La siguiente estrategia distribuye las tareas de forma uniforme en las zonas de disponibilidad y, a continuación, agrupa en bin packing las tareas en función de la memoria dentro de cada zona de disponibilidad.

```
"placementStrategy": [
    {
        "field": "attribute:ecs.availability-zone",
        "type": "spread"
    },
    {
        "field": "memory",
        "type": "binpack"
    }
]
```

## Distribuir las tareas de manera uniforme entre las instancias y, a continuación, agrupar las tareas en bin packing según la memoria
<a name="instance-memory"></a>

La siguiente estrategia distribuye las tareas de manera uniforme en todas las instancias y, a continuación, agrupa las tareas en bin packing en función de la memoria de cada instancia. 

```
"placementStrategy": [
    {
        "field": "instanceId",
        "type": "spread"
    },
    {
        "field": "memory",
        "type": "binpack"
    }
]
```

# Agrupación de tareas relacionadas con Amazon ECS
<a name="task-groups"></a>

Puede identificar un conjunto de tareas relacionadas y colocarlas en un grupo de tareas. Todas las tareas con el mismo nombre de grupo de tareas se consideran un conjunto cuando se utiliza la estrategia de ubicación de tareas `spread`. Por ejemplo, suponga que está ejecutando distintas aplicaciones en un clúster, tales como bases de datos y servidores web. Para asegurarse de que las bases de datos estén balanceadas en las zonas de disponibilidad, agréguelas a un grupo de tareas con el nombre `databases` y, a continuación, utilice la estrategia de ubicación de tareas `spread`. Para obtener más información, consulte [Uso de estrategias para definir la ubicación de las tareas de Amazon ECS](task-placement-strategies.md).

Los grupos de tareas también se pueden utilizar como restricción de ubicación de tareas. Al especificar un grupo de tareas en la restricción `memberOf`, las tareas solo se envían a instancias de contenedores que se encuentran en el grupo de tareas especificado. Para ver un ejemplo, consulta [Ejemplos de restricciones para ubicación de tareas de Amazon ECS](constraint-examples.md).

De forma predeterminada, las tareas independientes utilizan el nombre de familia de definición de tareas (por ejemplo, `family:my-task-definition`) como nombre del grupo de tareas si no se especifica un nombre de grupo de tareas personalizado. Las tareas lanzadas como parte de un servicio utilizan el nombre del servicio como nombre del grupo de tareas y no se pueden cambiar.

Se aplican los siguientes requisitos para el grupo de tareas.
+ Un nombre de grupo de tareas debe tener 255 caracteres o menos.
+ Cada tarea puede estar exactamente en un grupo.
+ Después de lanzar una tarea, no puede modificar su grupo de tarea.

# Definición de las instancias de contenedor que utiliza Amazon ECS para las tareas
<a name="task-placement-constraints"></a>

Una restricción de ubicación de tareas es una regla sobre una instancia de contenedor que Amazon ECS utiliza para determinar si la tarea puede ejecutarse en la instancia. Al menos una instancia de contenedor debe cumplir con la restricción. Si no hay instancias que coincidan con la restricción, la tarea permanece en un estado `PENDING`. Cuando crea un servicio nuevo o actualiza uno existente, puede especificar las restricciones de ubicación de tareas para las tareas del servicio. 

Puede especificar las restricciones de ubicación de tareas en la definición del servicio, la definición de la tarea o la tarea mediante el parámetro `placementConstraint`.

```
"placementConstraints": [
    {
        "expression": "The expression that defines the task placement constraints",
        "type": "The placement constraint type to use"
    }
]
```

En la tabla siguiente, se describe cómo usar los parámetros.


| Constraint type (Tipo de restricción) | Se puede especificar cuándo | 
| --- | --- | 
| distinctInstanceColoque cada tarea activa en una instancia de contenedor distinta.Amazon ECS analiza el estado deseado de las tareas para su colocación. Por ejemplo, si el estado deseado de la tarea existente es `STOPPED` (pero el último estado no lo es), se puede colocar una nueva tarea entrante en la misma instancia a pesar de la restricción de ubicación de `distinctInstance`. Por lo tanto, es posible que vea 2 tareas con el último estado de `RUNNING` en la misma instancia. Recomendamos que los clientes que buscan un aislamiento sólido para sus tareas utilicen Fargate. Fargate ejecuta cada tarea en un entorno de virtualización de hardware. Esto garantiza que estas cargas de trabajo en contenedores no compartan interfaces de red, almacenamiento efímero de Fargate, CPU o memoria con otras tareas. Para obtener más información, consulte [Security Overview of AWS Fargate](https://d1.awsstatic.com/whitepapers/AWS_Fargate_Security_Overview_Whitepaper.pdf). |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/task-placement-constraints.html)  | 
| memberOfColocar tareas en instancias de contenedor que satisfacen una expresión.  | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/task-placement-constraints.html) | 

Cuando utiliza el tipo de restricción `memberOf`, puede crear una expresión mediante el lenguaje de consulta de clústeres que define las instancias de contenedor en las que Amazon ECS puede colocar tareas. La expresión es una forma de agrupar las instancias de contenedor por atributos. La expresión se incluye en el `expression `parámetro de `placementConstraint`.

## Atributos de instancias de contenedor de Amazon ECS
<a name="attributes"></a>

Puede añadir metadatos personalizados a sus instancias de contenedor, conocidas como *atributos*. Cada atributo tiene un nombre y un valor de cadena opcional. Puede utilizar los atributos integrados que ofrece Amazon ECS o definir atributos personalizados.

Las secciones siguientes contienen ejemplos de atributos integrados, opcionales y personalizados.

### Atributos integrados
<a name="ecs-automatic-attributes"></a>

Amazon ECS aplica automáticamente los siguientes atributos a las instancias de contenedor.

`ecs.ami-id`  
El ID de la AMI utilizada para iniciar la instancia. Un valor de ejemplo para este atributo es `ami-1234abcd`.

`ecs.availability-zone`  
La zona de disponibilidad de la instancia. Un valor de ejemplo para este atributo es `us-east-1a`.

`ecs.instance-type`  
El tipo de instancia de la instancia. Un valor de ejemplo para este atributo es `g2.2xlarge`.

`ecs.os-type`  
El sistema operativo de la instancia. Los valores posibles para este atributo son `linux` y `windows`.

`ecs.os-family`  
La versión del sistema operativo de la instancia.  
Para las instancias de Linux, el valor válido es `LINUX`. Para las instancias de Windows, ECS establece el valor en el formato `WINDOWS_SERVER_<OS_Release>_<FULL or CORE>`. Los valores válidos son `WINDOWS_SERVER_2022_FULL`, `WINDOWS_SERVER_2022_CORE`, `WINDOWS_SERVER_20H2_CORE`, `WINDOWS_SERVER_2019_FULL`, `WINDOWS_SERVER_2019_CORE` y `WINDOWS_SERVER_2016_FULL`.  
Esto es importante para los contenedores de Windows y Windows containers on AWS Fargate porque la versión del sistema operativo de cada contenedor de Windows debe coincidir con la del host. Si la versión de Windows de la imagen del contenedor es diferente a la del host, el contenedor no se inicia. 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).

`ecs.cpu-architecture`  
La arquitectura de CPU de la instancia. Los valores de ejemplo para este atributo son `x86_64` y `arm64`.

`ecs.vpc-id`  
La VPC en la que se lanzó la instancia. Un valor de ejemplo para este atributo es `vpc-1234abcd`.

`ecs.subnet-id`  
La subred que está utilizando la instancia. Un valor de ejemplo para este atributo es `subnet-1234abcd`.

**nota**  
Instancias administradas de Amazon ECS admite el siguiente subconjunto de atributos:  
`ecs.subnet-id`
`ecs.availability-zone`
`ecs.instance-type`
`ecs.cpu-architecture`

### Atributos opcionales
<a name="ecs-optional-attributes"></a>

Amazon ECS puede agregar los siguientes atributos a las instancias de contenedor.

`ecs.awsvpc-trunk-id`  
Si este atributo existe, la instancia tiene una interfaz de red troncal. Para obtener más información, consulte [Aumento de las interfaces de red de instancias de contenedor de Linux de Amazon ECS](container-instance-eni.md).

`ecs.outpost-arn`  
Si este atributo existe, contiene el nombre de recurso de Amazon (ARN) del Outpost. Para obtener más información, consulte [Amazon Elastic Container Service en AWS Outposts](using-outposts.md).

`ecs.capability.external`  
Si este atributo existe, la instancia se identifica como instancia externa. Para obtener más información, consulte [Clústeres de Amazon ECS para instancias externas](ecs-anywhere.md).

### Custom attributes (Atributos personalizados)
<a name="ecs-custom-attributes"></a>

Puede aplicar atributos personalizados a sus instancias de contenedor. Por ejemplo, puede definir un atributo con el nombre "stack" y un valor "prod".

Al especificar atributos personalizados, se deben tener en cuenta los siguientes aspectos.
+ El `name` debe contener entre 1 y 128 caracteres, que pueden ser letras (mayúsculas y minúsculas), números, guiones, guiones bajos, barras diagonales, barras invertidas o puntos.
+ El `value` debe contener entre 1 y 128 caracteres, que pueden ser letras (mayúsculas y minúsculas), números, guiones, guiones bajos, puntos, signos de arroba (@), barras diagonales, barras invertidas, dos puntos o espacios. El valor no puede contener ningún espacio en blanco inicial ni final.

# Creación de expresiones para definir instancias de contenedor para las tareas de Amazon ECS
<a name="cluster-query-language"></a>

Las consultas de clúster son expresiones que permiten agrupar objetos. Por ejemplo, puede agrupar instancias de contenedor por atributos tales como zona de disponibilidad, tipo de instancia o metadatos personalizados. Para obtener más información, consulte [Atributos de instancias de contenedor de Amazon ECS](task-placement-constraints.md#attributes).

Después de haber definido un grupo de instancias de contenedor, puede personalizar Amazon ECS para que ubique tareas en instancias de contenedor basadas en grupo. Para obtener más información, consulte [Ejecución de una aplicación como tarea de Amazon ECS](standalone-task-create.md) y [Creación de una implementación de actualización continua de Amazon ECS](create-service-console-v2.md). También puede aplicar un filtro de grupo al mostrar una lista de instancias de contenedor.

## Sintaxis de expresiones
<a name="expression-syntax"></a>

Las expresiones tienen la siguiente sintaxis:

```
subject operator [argument]
```

**Asunto**  
El atributo o campo que se va a evaluar.

`agentConnected`  
Seleccione instancias de contenedor por el estado de conexión del agente de contenedor de Amazon ECS. Puede utilizar este filtro para buscar las instancias cuyos agentes de contenedor están desconectados.  
Los operadores válidos son: equals (==), not\$1equals (\$1=), in, not\$1in (\$1in), matches (=\$1), not\$1matches (\$1\$1)

`agentVersion`  
Seleccione instancias de contenedor según la versión del agente de contenedor de Amazon ECS. Puede utilizar este filtro para buscar las instancias que ejecutan versiones obsoletas del agente de contenedor de Amazon ECS.  
Los operadores válidos son: equals (==), not\$1equals (\$1=), greater\$1than (>), greater\$1than\$1equal (>=), less\$1than (<), less\$1than\$1equal (<=)

`attribute:attribute-name`  
Selecciona instancias de contenedor según el atributo. Para obtener más información, consulte [Atributos de instancias de contenedor de Amazon ECS](task-placement-constraints.md#attributes).

`ec2InstanceId`  
Seleccione instancias de contenedor por el ID de las instancias de Amazon EC2.  
Los operadores válidos son: equals (==), not\$1equals (\$1=), in, not\$1in (\$1in), matches (=\$1), not\$1matches (\$1\$1)

`registeredAt`  
Selecciona instancias de contenedor por la fecha de registro de la instancia de contenedor. Puede utilizar este filtro para encontrar las instancias que se acaban de registrar o las instancias que son muy antiguas.  
Los operadores válidos son: equals (==), not\$1equals (\$1=), greater\$1than (>), greater\$1than\$1equal (>=), less\$1than (<), less\$1than\$1equal (<=)  
Los formatos de fecha válidos son: 2018-06-18T22:28:28\$100:00, 2018-06-18T22:28:28Z, 2018-06-18T22:28:28, 2018-06-18

`runningTasksCount`  
Selecciona instancias de contenedor según el número de tareas en ejecución. Puede utilizar este filtro para encontrar las instancias que estén vacías o casi vacías (con pocas tareas en ejecución).  
Los operadores válidos son: equals (==), not\$1equals (\$1=), greater\$1than (>), greater\$1than\$1equal (>=), less\$1than (<), less\$1than\$1equal (<=)

`task:group`  
Selecciona instancias de contenedor según el grupo de tareas. Para obtener más información, consulte [Agrupación de tareas relacionadas con Amazon ECS](task-groups.md).

**Operador**  
El operador de comparación. Se admiten los siguientes operadores.


|  Operador  |  Descripción  | 
| --- | --- | 
|  ==, equals  |  Igualdad de cadena  | 
|  \$1=, not\$1equals  |  Desigualdad de cadena  | 
|  >, greater\$1than  |  Mayor que  | 
|  >=, greater\$1than\$1equal  |  Mayor o igual que  | 
|  <, less\$1than  |  Menor que  | 
|  <=, less\$1than\$1equal  |  Menor o igual que  | 
|  exists  |  El asunto existe  | 
|  \$1exists, not\$1exists  |  El asunto no existe  | 
|  in  |  El valor está en la lista de argumentos  | 
|  \$1in, not\$1in  |  El valor no está en la lista de argumentos  | 
|  =\$1, matches  |  Coincidencia de patrón  | 
|  \$1\$1, not\$1matches  |  No hay coincidencia de patrón  | 

**nota**  
Una expresión única no puede contener paréntesis. Sin embargo, se pueden utilizar paréntesis para especificar la prioridad en las expresiones compuestas.

**Argumento**  
Para muchos operadores, el argumento es un valor literal.

Los operadores `in` y `not_in` esperan una lista de argumentos como argumento. Una lista de argumentos se especifica del siguiente modo:

```
[argument1, argument2, ..., argumentN]
```

Los operadores matches y not\$1matches esperan un argumento que se ajuste a la sintaxis de la expresión regular Java. Para obtener más información, consulte [java.util.regex.Pattern](http://docs.oracle.com/javase/6/docs/api/java/util/regex/Pattern.html).

**Expresiones compuestas**

Puede combinar expresiones utilizando los siguientes operadores booleanos:
+ &&, y
+ \$1\$1, o bien
+ \$1, not

Puede especificar prioridad utilizando paréntesis:

```
(expression1 or expression2) and expression3
```

## Expresiones de ejemplo
<a name="expression-examples"></a>

A continuación se incluyen expresiones de ejemplo.

**Ejemplo: igualdad de cadena**  
La expresión siguiente selecciona las instancias con el tipo de instancia especificado.

```
attribute:ecs.instance-type == t2.small
```

**Ejemplo: lista de argumentos**  
La expresión siguiente selecciona las instancias en la zona de disponibilidad us-east-1a o us-east-1b.

```
attribute:ecs.availability-zone in [us-east-1a, us-east-1b]
```

**Ejemplo: expresiones compuestas**  
La siguiente expresión selecciona las instancias G2 que no están en la zona de disponibilidad us-east-1d.

```
attribute:ecs.instance-type =~ g2.* and attribute:ecs.availability-zone != us-east-1d
```

**Ejemplo: afinidad de tareas**  
La expresión siguiente selecciona las instancias que alojan tareas en el grupo `service:production`.

```
task:group == service:production
```

**Ejemplo: antiafinidad de tareas**  
La siguiente expresión selecciona las instancias que no alojan tareas en el grupo de base de datos.

```
not(task:group == database)
```

**Ejemplo: Recuento de tareas en ejecución**  
La expresión siguiente selecciona las instancias que solo están ejecutando una tarea.

```
runningTasksCount == 1
```

**Ejemplo: versión del agente de contenedor de Amazon ECS**  
La expresión siguiente selecciona las instancias que están ejecutando una versión del agente de contenedor anterior a la 1.14.5.

```
agentVersion < 1.14.5
```

**Ejemplo: Hora de registro de las instancias**  
La expresión siguiente selecciona las instancias que se han registrado antes del 13 de febrero de 2018.

```
registeredAt < 2018-02-13
```

**Ejemplo: ID de instancias de Amazon EC2**  
Esta expresión selecciona las instancias con los siguientes ID de instancias de Amazon EC2.

```
ec2InstanceId in ['i-abcd1234', 'i-wxyx7890']
```

# Ejemplos de restricciones para ubicación de tareas de Amazon ECS
<a name="constraint-examples"></a>

A continuación, se muestran ejemplos de restricción de ubicación de tareas.

En este ejemplo, se utiliza la restricción `memberOf` para colocar tareas en instancias t2. Se puede especificar con las acciones siguientes: [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html), [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html), [RegisterTaskDefinition](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RegisterTaskDefinition.html) y [RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html).

```
"placementConstraints": [
    {
        "expression": "attribute:ecs.instance-type =~ t2.*",
        "type": "memberOf"
    }
]
```

En el ejemplo, se utiliza la restricción `memberOf` para ubicar tareas de réplica en instancias con otras tareas en el grupo de tareas `daemon-service` del servicio de daemon, respetando las estrategias de ubicación de tareas que también se especifican. Esta restricción garantiza que las tareas del servicio de daemon se coloquen en la instancia de EC2 antes que las tareas del servicio de réplica.

Sustituya `daemon-service` por el nombre del servicio de daemon.

```
"placementConstraints": [
    {
        "expression": "task:group == service:daemon-service",
        "type": "memberOf"
    }
]
```

En el ejemplo, se utiliza la restricción `memberOf` para ubicar tareas en instancias con otras tareas en el grupo de tareas `databases`, respetando las estrategias de ubicación de tareas que también se especifiquen. Para obtener más información acerca de los grupos de tareas, consulte [Agrupación de tareas relacionadas con Amazon ECS](task-groups.md). Se puede especificar con las acciones siguientes: [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html), [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html), [RegisterTaskDefinition](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RegisterTaskDefinition.html) y [RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html).

```
"placementConstraints": [
    {
        "expression": "task:group == databases",
        "type": "memberOf"
    }
]
```

La restricción `distinctInstance` ubica cada tarea del grupo en una instancia diferente. Se puede especificar mediante las siguientes acciones: [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html), [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) y [RunTask](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_RunTask.html)

Amazon ECS analiza el estado deseado de las tareas para su colocación. Por ejemplo, si el estado deseado de la tarea existente es `STOPPED` (pero el último estado no lo es), se puede colocar una nueva tarea entrante en la misma instancia a pesar de la restricción de ubicación de `distinctInstance`. Por lo tanto, es posible que vea 2 tareas con el último estado de `RUNNING` en la misma instancia.

```
"placementConstraints": [
    {
        "type": "distinctInstance"
    }
]
```

# Tareas independientes de Amazon ECS
<a name="standalone-tasks"></a>

Puede ejecutar la aplicación como una tarea si tiene una aplicación que hace algún trabajo y, después, se detiene (por ejemplo, un proceso por lotes). Si quiere ejecutar una tarea una vez, puede usar la consola, la AWS CLI, las API o los SDK.

Si necesita ejecutar su aplicación en un programa basado en tasa, cron o único, puede crear una programación con el Programador de EventBridge.

## Flujo de trabajo de tareas
<a name="task-workflow"></a>

Al lanzar tareas de Amazon ECS (tareas independientes o mediante los servicios de Amazon ECS), se crea una tarea e inicialmente se traslada al estado `PROVISIONING`. Cuando el estado de una tarea es `PROVISIONING`, ni la tarea ni los contenedores existen porque Amazon ECS tiene que encontrar la capacidad de computación para llevar a cabo la tarea.

Amazon ECS selecciona la capacidad de computación adecuada para su tarea en función del tipo de lanzamiento o de la configuración del proveedor de capacidad. Puede utilizar proveedores de capacidad y estrategias de proveedores de capacidad con Fargate y EC2. Con Fargate, no tiene que preocuparse por aprovisionar, configurar y escalar la capacidad de su clúster. Fargate se encarga de toda la gestión de la infraestructura para sus tareas. Para EC2, puede administrar la capacidad del clúster registrando instancias de Amazon EC2 en el clúster o puede usar el escalado automático del clúster para simplificar la administración de la capacidad de computación. El escalado automático del clúster se encarga de escalar dinámicamente la capacidad del clúster para que pueda concentrarse en ejecutar las tareas. Amazon ECS determina dónde colocar la tarea en función de los requisitos que especifique en la definición de tarea, como la CPU y la memoria, así como de sus restricciones y estrategias de ubicación. Para obtener más información, consulte , [Cómo coloca Amazon ECS las tareas en las instancias de contenedor](task-placement.md).

Si utiliza un proveedor de capacidad con el escalado administrado habilitado, las tareas que no se puedan iniciar por falta de capacidad de computación se trasladarán al estado `PROVISIONING` en lugar de generar un error de inmediato. Tras encontrar la capacidad para colocar la tarea, Amazon ECS aprovisiona los adjuntos necesarios (por ejemplo, interfaces de red elásticas [ENI] para las tareas en modo `awsvpc`). Utiliza el agente de contenedor de Amazon ECS para extraer las imágenes de los contenedores y, a continuación, iniciar los contenedores. Una vez finalizado el aprovisionamiento y lanzados los contenedores correspondientes, Amazon ECS pasa la tarea al estado `RUNNING`. Para obtener más información sobre los estados de las tareas, consulte [Ciclo de vida de las tareas de Amazon ECS](task-lifecycle-explanation.md).

# Ejecución de una aplicación como tarea de Amazon ECS
<a name="standalone-task-create"></a>

Puede crear una tarea para un proceso único mediante la Consola de administración de AWS.

**Para crear una tarea independiente (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. La consola de Amazon ECS le permite crear una tarea independiente desde la página de detalles del clúster o desde la lista de revisiones de definiciones de tareas. Siga estos pasos para crear una tarea independiente según la página de recursos que elija.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/standalone-task-create.html)

1. En **Clúster existente**, elija el clúster.

   Elija **Crear clúster** para ejecutar la tarea en un clúster nuevo

1. Elija cómo distribuir las tareas en la infraestructura de clúster. En **Configuración de cómputos**, elija su opción. Para utilizar una estrategia de proveedor de capacidad, debe configurar sus proveedores de capacidad por clúster. 

   Si no ha configurado el clúster para usar un proveedor de capacidad, utilice un tipo de lanzamiento en su lugar.

   Si desea poner en marcha sus cargas de trabajo en instancias administradas de Amazon ECS, debe usar la opción de estrategia del proveedor de capacidad.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/standalone-task-create.html)

1. En **Configuración de implementación**, haga lo siguiente:

   1. En **Definición de tarea**, ingrese la definición de la tarea.
**importante**  
La consola valida la selección para asegurarse de que la familia y la revisión de definiciones de tareas seleccionadas sean compatibles con la configuración de cómputos definida.

   1. En **Desired tasks** (Tareas deseadas), ingrese el número de tareas que se lanzarán.

   1. En **Grupo de tareas**, ingrese el nombre del grupo de tareas.

1. Si la definición de su tarea utiliza el modo de red de `awsvpc`, expanda la opción de **Networking** (Red). Siga estos pasos para especificar una configuración personalizada.

   1. En **VPC**, seleccione la VPC que se va a usar.

   1. En **Subnets** (Subredes), seleccione una o varias subredes de la VPC que el programador de tareas considera al ubicar sus tareas.

   1. En **Grupos de seguridad**, puede seleccionar un grupo de seguridad existente o crear uno nuevo. Para utilizar un grupo de seguridad existente, seleccione el grupo de seguridad y continúe con el próximo paso. Para crear un grupo de seguridad, elija **Create a new security group (Crear un grupo de seguridad nuevo)**. Debe especificar un nombre de grupo de seguridad, una descripción y, a continuación, agregar una o varias reglas de entrada para el grupo de seguridad.

   1. En **Public IP** (IP pública), elija si desea asignar automáticamente una dirección IP pública a la interfaz de red elástica (ENI) de la tarea.

      Las tareas de AWS Fargate pueden recibir una dirección IP pública cuando se ejecuten mediante una subred pública para que tengan una ruta a Internet. A las tareas de EC2 no se les puede asignar una IP pública mediante este campo. Para obtener más información, consulte [Opciones de redes de tareas de Amazon ECS para Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-task-networking.html) y [Asignación de una interfaz de red para una tarea de Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking-awsvpc.html).

1. Si su tarea usa un volumen de datos compatible con la configuración en el momento de la implementación, puede expandir **Volume** para configurar el volumen.

   El nombre y el tipo de volumen se configuran al crear una revisión de la definición de la tarea y no se pueden cambiar cuando se ejecuta una tarea independiente. Para actualizar el nombre y el tipo del volumen, debe crear una nueva revisión de la definición de tareas y ejecutar una tarea con la nueva revisión.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/standalone-task-create.html)

1. (Opcional) Para utilizar una estrategia de ubicación de tareas distinta a la predeterminada, expanda **Task Placement** (Ubicación de tareas) y, a continuación, elija una de las siguientes opciones.

    Para obtener más información, consulte [Cómo coloca Amazon ECS las tareas en las instancias de contenedor](task-placement.md).
   + **Reparto equilibrado en AZ**: distribuya las tareas en las zonas de disponibilidad y entre las instancias de contenedor dentro de cada zona de disponibilidad.
   + **BinPack equilibrado en AZ**: distribuya las tareas en las zonas de disponibilidad y entre las instancias de contenedor con la menor memoria disponible.
   + **BinPack**: distribuya las tareas en función de la cantidad mínima de CPU o memoria disponible.
   + **Una tarea por Host**: coloque como máximo una tarea del servicio en cada instancia de contenedor.
   + **Personalizado**: defina su propia estrategia de colocación de tareas. 

   Si elige **Custom** (Personalizado), defina el algoritmo de ubicación de tareas y las reglas que se tienen en cuenta durante la ubicación de tareas.
   + En **Strategy** (Estrategia), para **Type** (Tipo) y **Field** (Campo), elija el algoritmo y la entidad que quiere utilizar para el algoritmo.

     Puede ingresar un máximo de 5 estrategias.
   + En **Restricción**, para **Tipo** y **Expresión**, elija la regla y el atributo para la restricción.

     Por ejemplo, para establecer la restricción de colocar las tareas en las instancias T2, para la **Expresión**, ingrese **attribute:ecs.instance-type =\$1 t2.\$1**.

     Puede ingresar un máximo de 10 restricciones.

1. (Opcional) Para anular el rol de IAM de la tarea, o el rol de ejecución de la tarea que está definido en su definición de la tarea, expanda **Task overrides** (Anulaciones de tareas) y, a continuación, complete los siguientes pasos:

   1. En **Rol de tarea**, elija un rol de IAM para esta tarea. Para obtener más información, consulte [Rol de IAM de tarea de Amazon ECS](task-iam-roles.md).

      Solo se muestran os roles con la relación de confianza `ecs-tasks.amazonaws.com`. Para obtener instrucciones sobre cómo crear un rol de IAM para las tareas, consulte [Creación del rol de IAM de tareas](task-iam-roles.md#create_task_iam_policy_and_role).

   1. En **Rol de ejecución de tareas**, elija un rol de ejecución de tareas. Para obtener más información, consulte [Rol de IAM de ejecución de tareas de Amazon ECS](task_execution_IAM_role.md).

1. (Opcional) Para anular los comandos del contenedor y las variables de entorno, expanda **Container Overrides** (Anulaciones de contenedores) y, a continuación, expanda el contenedor.
   +  Para enviar un comando al contenedor que no sea el comando de definición de tareas, en **Anulación de comando**, ingrese el comando de Docker.
   + Para agregar una variable de entorno, elija **Add environment variable** (Agregar variable de entorno). En **Key** (Clave), ingrese el nombre de la variable de entorno. En **Value** (Valor), ingrese un valor de cadena el valor de entorno (sin las comillas dobles [`" "`]).

     AWS rodea las cadenas con comillas dobles (" ") y pasa la cadena al contenedor en el formato siguiente:

     ```
     MY_ENV_VAR="This variable contains a string."
     ```

1. (Opcional) Para ayudar a identificar la tarea, expanda la sección **Tags** (Etiquetas) y, a continuación, configure sus etiquetas.

   Para que Amazon ECS etiquete automáticamente todas las tareas recién lanzadas con el nombre del clúster y las etiquetas de definición de tareas, seleccione **Turn on Amazon ECS managed tags** (Activar las etiquetas gestionadas de Amazon ECS) y, a continuación, seleccione **Task definitions** (Definiciones de tareas).

   Añada o elimine una etiqueta.
   + [Agregar una etiqueta] Seleccione **Add tag** (Agregar etiqueta), y, a continuación, haga lo siguiente:
     + En **Clave**, escriba el nombre de la clave.
     + En **Valor**, escriba el valor de la clave.
   + [Eliminar una etiqueta] Junto a la etiqueta, elija **Remove tag (Quitar etiqueta)**.

1. Seleccione **Crear**.

# Uso de Programador de Amazon EventBridge para programar tareas de Amazon ECS
<a name="tasks-scheduled-eventbridge-scheduler"></a>

El Programador de Amazon EventBridge es un programador sin servidor que le permite crear, ejecutar y administrar tareas desde un servicio administrado y centralizado. Proporciona una funcionalidad de programación única y recurrente, independientemente de las reglas y los buses de eventos. El programador de EventBridge es altamente personalizable y ofrece una escalabilidad mejorada en comparación con las reglas programadas de EventBridge, con un conjunto más amplio de operaciones de API y servicios de AWS de destino. El programador de EventBridge proporciona los siguientes programas que puede configurar para sus tareas en la consola del programador de EventBridge:
+ Basada en frecuencia 
+ Basado en cron

  Puede configurar programas basados en cron en cualquier zona horaria.
+ Programas únicos

  Puede configurar programas únicos en cualquier zona horaria.

Puede programar su Amazon ECS mediante el Programador de Amazon EventBridge.

Aunque puede crear una tarea programada en la consola de Amazon ECS, actualmente la consola del programador de EventBridge proporciona más funcionalidad.

Lleve a cabo los pasos siguientes antes de programar una tarea:

1. Utilice la consola de VPC para obtener los ID de subred en los que se ejecutan las tareas y los ID de los grupos de seguridad de las subredes. Para obtener más información, consulte [Subredes para la VPC](https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html) y [Controlar el tráfico hacia los recursos de AWS mediante grupos de seguridad](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) en la *Guía del usuario de Amazon VPC*.

1. Configure el rol de ejecución del programador de EventBridge. Para obtener más información, consulte [Configurar el rol de ejecución](https://docs.aws.amazon.com/scheduler/latest/UserGuide/setting-up.html#setting-up-execution-role) en la *Guía del usuario del programador de Amazon EventBridge*. 

1. Para utilizar una estrategia de proveedor de capacidad, el proveedor de capacidad debe estar asociado con el clúster.

**Para crear un programa nuevo con la consola**

1. Abra la consola del Programador de Amazon EventBridge en[https://console.aws.amazon.com/scheduler/home](https://console.aws.amazon.com/scheduler/home/).

1.  En la página **Programaciones**, elija **Crear programación**. 

1.  En la página **Especificar los detalles de la programación**, en la sección **Nombre y descripción de la programación**, proceda del modo siguiente: 

   1. En **Nombre de la programación**, escriba un nombre para la programación. Por ejemplo, **MyTestSchedule**. 

   1. (Opcional) En **Descripción**, escriba una descripción para su programación. Por ejemplo, **TestSchedule**.

   1. En **Grupo de programaciones**, elija un grupo de programaciones. Si no tiene un grupo, elija **predeterminado**. Para crear un grupo de programaciones, elija **crear mi propia programación**. 

      Los grupos de programaciones se utilizan para añadir etiquetas a grupos de programaciones. 

1. Elija sus opciones de programación.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/tasks-scheduled-eventbridge-scheduler.html)

1. (Opcional) Si elige **Programación recurrente** en el paso anterior, en la sección de **Periodo de tiempo**, realice lo siguiente: 

   1. En **Zona horaria**, elija una zona horaria. 

   1. En **Fecha y hora de inicio**, introduzca una fecha válida con el formato `YYYY/MM/DD` y, a continuación, especifique una marca de tiempo con el formato `hh:mm` de 24 horas. 

   1. En **Fecha y hora de finalización**, introduzca una fecha válida con el formato `YYYY/MM/DD` y, a continuación, especifique una marca de tiempo con el formato `hh:mm` de 24 horas. 

1. Elija **Siguiente**. 

1. En la página **Seleccionar destino**, haga lo siguiente: 

   1. Seleccione **Todas las API** y, a continuación, en el cuadro de búsqueda escriba **ECS**. 

   1. Seleccione **Amazon ECS**.

   1. En el cuadro de búsqueda, escriba **Ejecutar tarea** y, a continuación, seleccione **Ejecutar tarea**.

   1. En **Clúster de ECS**, elija el clúster.

   1. Para la **tarea de ECS**, elija la definición de tarea que se utilizará para la tarea.

   1. Elija cómo distribuir las tareas en la infraestructura de clúster. Expanda las **Opciones de computación** y, a continuación, elija una de las siguientes opciones:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/tasks-scheduled-eventbridge-scheduler.html)

   1. En el caso de las **Subredes**, introduzca los ID de subred en los que se ejecutará la tarea.

   1. En el caso los **Grupos de seguridad**, introduzca los ID de los grupos de seguridad de la subred.

   1. (Opcional) Para utilizar una estrategia de ubicación de tareas que no sea la predeterminada, expanda **Restricción de ubicación** y, a continuación, introduzca las restricciones.

       Para obtener más información, consulte [Cómo coloca Amazon ECS las tareas en las instancias de contenedor](task-placement.md).

   1. (Opcional) Para ayudar a identificar las tareas, en **Etiquetas**, configure las etiquetas.

      Para que Amazon ECS etiquete automáticamente todas las tareas recién lanzadas con las etiquetas de definición de tareas, seleccione **Activar las etiquetas administradas de Amazon ECS**.

1. Elija **Siguiente**. 

1. En la página **Configuración**, haga lo siguiente: 

   1. Para activar la programación, en **Estado de la programación**, cambie a **Habilitar programación**. 

   1. Para configurar una política de reintentos para su programación, en **Política de reintento y cola de mensajes fallidos (DLQ)**, realice lo siguiente:
      + Cambie a **Reintentar**.
      + En **Tiempo de retención máxima del evento**, ingrese el máximo de **horas** y **minutos** que el programador de EventBridge debe mantener un evento sin procesar.
      + El tiempo máximo es de 24 horas.
      + En **Cantidad máxima de reintentos**, introduzca el número máximo de veces que el Programador de EventBridge reintenta la programación si el destino devuelve un error. 

         El valor máximo es 185 reintentos. 

      Con las políticas de reintentos, si un programa no puede invocar su destino, el Programador de EventBridge vuelve a ejecutar el programa. Si se encuentra configurado, debe establecer el tiempo máximo de retención y los reintentos máximos para la programación.

   1. Elija dónde almacena los eventos no entregados el Programador de EventBridge.     
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/tasks-scheduled-eventbridge-scheduler.html)

   1. Para utilizar una clave administrada por el cliente a fin de cifrar la entrada de destino, en **Cifrado**, elija **Personalizar la configuración de cifrado (avanzado)**. 

      Si elige esta opción, ingrese un ARN de clave de KMS existente o elija **Crear una AWS KMS key** para navegar hasta la consola de AWS KMS. Para obtener más información sobre cómo el Programador de EventBridge cifra los datos en reposo, consulte [Encryption at rest](https://docs.aws.amazon.com/scheduler/latest/UserGuide/encryption-rest.html) en *Amazon EventBridge Scheduler User Guide*. 

   1. En **Permisos**, seleccione **Usar el rol existente** y, a continuación, seleccione el rol.

      Para que el Programador de EventBridge cree un rol de ejecución nuevo en su nombre, elija **Crear un nuevo rol para esta programación**. A continuación, ingrese un nombre para el **Nombre de rol**. Si elige esta opción, el Programador de EventBridge adjunta al rol los permisos necesarios para el destino creado con la plantilla. 

1. Elija **Siguiente**. 

1.  En la página de **Revisar y crear una programación**, revise los detalles de su programación. En cada sección, elija **Editar** para volver a ese paso y editar sus detalles. 

1. Elija **Crear programación**. 

   Puede ver una lista de sus programaciones nuevas y existentes en la página **Programaciones**. En la columna **Estado**, verifique que su programación nueva se encuentre **Habilitada**. 

## Siguientes pasos
<a name="eventbridge-scheduler-next-steps"></a>

Puede utilizar la consola del programador de EventBridge o la AWS CLI para administrar el programa. Para obtener más información, consulte [Administración de un programa](https://docs.aws.amazon.com/scheduler/latest/UserGuide/managing-schedule.html) en la *Guía del usuario del programador de Amazon EventBridge*.

# Detención de una tarea de Amazon ECS
<a name="standalone-task-stop"></a>

Si ya no necesita mantener una tarea independiente en ejecución, puede detenerla. La consola de Amazon ECS facilita la detención de una o más tareas.

No puede reiniciar una tarea detenida individual.

Si necesita detener un servicio, consulte [Eliminación de un servicio de Amazon ECS mediante la consola](delete-service-v2.md).

**Para detener una tarea independiente (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 **Clústeres**, elija el clúster para ir a la página de detalles del clúster.

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

1. Puede filtrar las tareas por tipo de lanzamiento mediante la lista **Filtrar tipo de lanzamiento**.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/standalone-task-stop.html)

# Servicios de Amazon ECS
<a name="ecs_services"></a>

Puede utilizar un servicio de Amazon ECS para ejecutar y mantener un número determinado de instancias de una definición de tarea de manera simultánea en un clúster de Amazon ECS. Si una de las tareas falla o se detiene, el programador de servicios de Amazon ECS lanza otra instancia de su definición de tarea para sustituirla. Esto ayuda a mantener el número deseado de tareas en el servicio.

También puede ejecutar el servicio detrás de un equilibrador de carga. El balanceador de carga distribuye el tráfico entre las tareas que están asociadas al servicio.

Se recomienda utilizar el programador de servicios para los servicios y aplicaciones sin estado de larga duración. El programador de servicios garantiza el cumplimiento de la estrategia de programación especificada y reprograma las tareas cuando alguna de ellas falla. Por ejemplo, si falla la infraestructura subyacente, el programador de servicios puede reprogramar una tarea. Puede utilizar estrategias de ubicación de tareas y restricciones para personalizar el modo en que el programador ubica y termina las tareas. Si se detiene una tarea de un servicio, el programador lanza una nueva tarea para sustituirla. Este proceso continúa hasta que el servicio alcanza el número deseado de tareas en función de la estrategia de programación que utiliza el servicio.

El programador de servicios también reemplaza las tareas que se determina que están en mal estado después de que se produzca un error en una comprobación de estado del contenedor o en una comprobación de estado del grupo de destino del equilibrador de cargas. Este reemplazo depende de los parámetros de definición del servicio `maximumPercent` y `desiredCount`. Si una tarea está marcada como en mal estado, el programador de servicios iniciará primero una tarea de reemplazo. Luego, ocurrirá lo siguiente.
+ Si la tarea de reemplazo tiene un estado de `HEALTHY`, el programador de servicios detiene la tarea en mal estado.
+ Si la tarea de reemplazo tiene un estado de `UNHEALTHY`, el programador detendrá la tarea de reemplazo en mal estado o la tarea existente en mal estado para igualar el recuento total de tareas en `desiredCount`.

Si el parámetro `maximumPercent` impide que el programador inicie primero una tarea de reemplazo, detendrá las tareas en mal estado de forma aleatoria de una en una para liberar capacidad y, a continuación, iniciará una tarea de reemplazo. El proceso de inicio y parada continúa hasta que todas las tareas en mal estado se sustituyan por tareas en buen estado. Una vez que se hayan reemplazado todas las tareas en mal estado y solo se estén ejecutando las tareas en buen estado, si el recuento total de tareas supera el límite de `desiredCount`, las tareas en buen estado se detienen aleatoriamente hasta que el recuento total de tareas sea igual a `desiredCount`. Para obtener más información sobre `maximumPercent` y `desiredCount`, consulte [Parámetros de definición de servicios](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html).

El programador de servicios incluye una lógica que limita la frecuencia con la que se reinician las tareas si estas fallan de forma repetida Si una tarea se detiene sin haber entrado en estado `RUNNING`, el programador de servicios comienza a ralentizar los intentos de lanzamiento y envía un mensaje de evento de servicio. Este comportamiento impide que se utilicen recursos innecesarios para tareas fallidas antes de poder resolver el problema. Una vez que el servicio de actualiza, el programador de servicios retoma el comportamiento normal de programación. Para obtener más información, consulte [Lógica de limitación controlada de servicios de Amazon ECS](service-throttle-logic.md) y [Visualización de los mensajes de eventos del servicio de Amazon ECS](service-event-messages.md).

## Opción de computación de infraestructura
<a name="service-conmpute-options"></a>

Hay dos opciones de computación que distribuyen sus tareas.
+ Una estrategia de proveedor de capacidad hace que Amazon ECS distribuya sus tareas en uno o varios proveedores de capacidad. 

  Si desea poner en marcha sus cargas de trabajo en instancias administradas de Amazon ECS, debe usar la opción de estrategia del proveedor de capacidad.

  En **capacity provider strategy** (estrategia de proveedor de capacidad), la consola selecciona una opción de computación de forma predeterminada. A continuación, se describe el orden que utiliza la consola para seleccionar un valor predeterminado:
  + Si su clúster tiene definida una estrategia de proveedor de capacidad por defecto, se seleccionará esa.
  + Si el clúster no tiene definida una estrategia de proveedores de capacidad predeterminada, pero sí tiene los proveedores de capacidad de Fargate agregados al clúster, se selecciona una estrategia de proveedores de capacidad personalizada que utiliza al proveedor de capacidad de `FARGATE`.
  + Si su clúster no tiene definida una estrategia de proveedor de capacidad por defecto, pero tiene uno o varios proveedores de capacidad de grupo de escalado automático agregados al clúster, se seleccionará la opción **Utilizar personalizado (Avanzado)** y tendrá que definir manualmente la estrategia.
  + Si el clúster no tiene definida ninguna estrategia de proveedores de capacidad predeterminada ni tiene proveedores de capacidad agregados al clúster, se selecciona el tipo de lanzamiento de Fargate.
+ Un tipo de lanzamiento hace que Amazon ECS lance nuestras tareas directamente en Fargate o en las instancias de EC2 registradas en sus clústeres.

  Si desea poner en marcha sus cargas de trabajo en instancias administradas de Amazon ECS, debe usar la opción de estrategia del proveedor de capacidad.

  De forma predeterminada, el servicio se inicia en las subredes de la VPC de clúster.

## Escalado automático de servicios
<a name="service-auto-scaling-options"></a>

El escalado automático del servicio es la capacidad de aumentar o disminuir automáticamente la cantidad de tareas deseada en el servicio de Amazon ECS. Amazon ECS utiliza el servicio de Application Auto Scaling para proporcionar esta funcionalidad.

Para obtener más información, consulte [Escalado automático de su servicio de Amazon ECS](service-auto-scaling.md).

## Equilibrio de carga de los servicios
<a name="service-load-balancing-options"></a>

Los servicios de Amazon ECS alojados en AWS Fargate admiten los equilibradores de carga de aplicación, los equilibradores de carga de red y los equilibradores de carga de puerta de enlace. Utilice la siguiente tabla para obtener información sobre el tipo de equilibrador de carga que se debe utilizar.


| Tipo de equilibrador de carga | Utilizar en estos casos | 
| --- | --- | 
|  Equilibrador de carga de aplicación  | Dirija el tráfico HTTP o HTTPS (o de capa 7).Los Application Load Balancers ofrecen varias características nuevas que los hacen interesantes para utilizar con los servicios Amazon ECS: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/ecs_services.html) | 
| Equilibrador de carga de red | Dirija el tráfico TCP o UDP (o de capa 4). | 
| Balanceador de carga de gateway | Dirija el tráfico TCP o UDP (o de capa 4). Utilice dispositivos virtuales, como firewalls, sistemas de prevención y detección de intrusiones, y sistemas de inspección profunda de paquetes. | 

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).

## Interconexión de servicios
<a name="service-connecting-options"></a>

Si necesita una aplicación para conectarse a otras que se ejecutan en los servicios de Amazon ECS, Amazon ECS proporciona las siguientes formas de lograrlo sin un equilibrador de carga:
+ Service Connect: permite que se lleven a cabo las comunicaciones de servicio a servicio con detección automática mediante nombres abreviados y puertos estándar.
+ Detección de servicios: la detección de servicios usa Route 53 para crear un espacio de nombres para el servicio, lo que permite detectarlo a través del DNS.
+ Amazon VPC Lattice: VPC Lattice es un servicio de redes de aplicaciones completamente administrado que puede utilizar para conectar, proteger y monitorear sus servicios en varias cuentas y nubes privadas virtuales (VPC). Su uso conlleva un costo asociado.

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

# Estrategias y controladores de implementación de servicios de Amazon ECS
<a name="ecs_service-options"></a>

Antes de implementar el servicio, determine las opciones para implementarlo y las características que utilizará el servicio.

## Estrategia de programación
<a name="service-strategy"></a>

Existen dos estrategias del programador de servicio:
+ `REPLICA`: la estrategia de programación de réplicas sitúa y mantiene en el clúster el número de tareas deseado. De forma predeterminada, el programador de servicio distribuye las tareas en zonas de disponibilidad. Puede utilizar estrategias y restricciones de ubicación de tareas para personalizar las decisiones de ubicación de las tareas. Para obtener más información, consulte [Estrategia de programación de réplicas](#service_scheduler_replica).
+ `DAEMON`: la estrategia de programación del daemon implementa exactamente una tarea en cada instancia de contenedor activa que cumpla todas las restricciones de ubicación de tareas que se especifiquen para el clúster. Cuando se utiliza esta estrategia, no es necesario especificar un número deseado de tareas, ni una estrategia de ubicación de tareas ni utilizar políticas de Auto Scaling de servicios. Para obtener más información, consulte [Estrategia de programación de daemon](#service_scheduler_daemon).
**nota**  
Las tareas de Fargate no admiten la estrategia de programación de `DAEMON`.

### Estrategia de programación de réplicas
<a name="service_scheduler_replica"></a>

La estrategia de programación de *réplicas* sitúa y mantiene en el clúster el número de tareas deseado.

 En el caso de un servicio que ejecuta tareas en Fargate, cuando el programador de servicios lanza nuevas tareas o deja de ejecutarlas, el programador de servicios hace lo mejor para mantener un equilibrio entre las zonas de disponibilidad. No es necesario especificar estrategias ni restricciones de ubicación de tareas.

Al crear un servicio que ejecuta tareas en instancias EC2, tiene la opción de especificar estrategias y restricciones de ubicación de tareas a fin de personalizar las decisiones de ubicación de tareas. Si no se especifican estrategias o restricciones de ubicación de tareas, el programador de servicios repartirá las tareas de forma predeterminada entre las zonas de disponibilidad. El programador de servicios utiliza la siguiente lógica:
+ Determina cuál de las instancias de contenedor de su clúster puede admitir la definición de la tarea de su servicio (por ejemplo, la CPU, la memoria, los puertos y los atributos de la instancia de contenedor requeridos).
+ Determina qué instancias de contenedor satisfacen las restricciones de ubicación definidas para el servicio.
+ Si tiene un servicio de réplica que depende de un servicio de daemon (por ejemplo, una tarea del enrutador del registro de daemon que debe estar ejecutándose antes de que las tareas puedan utilizar el registro), cree una restricción de ubicación de tareas que garantice que las tareas del servicio de daemon se coloquen en la instancia de EC2 antes que las tareas del servicio de réplica. Para obtener más información, consulte [Ejemplos de restricciones para ubicación de tareas de Amazon ECS](constraint-examples.md).
+ Cuando hay una estrategia de ubicación definida, utilice esa estrategia para seleccionar una instancia entre los candidatos restantes.
+ Si no hay ninguna estrategia de ubicación definida, utilice la siguiente lógica para equilibrar las tareas entre las zonas de disponibilidad de su clúster:
  + Ordena las instancias de contenedor válidas. Da prioridad a las instancias que tienen el menor número de tareas en ejecución para este servicio en su respectiva zona de disponibilidad. Por ejemplo, si la zona A tiene una tarea de servicio en ejecución y las zonas B y C tienen cero cada una, las instancias de contenedor válidas en la zona B o C se consideran óptimas para colocación.
  + Ubica la nueva tarea de servicio en una instancia de contenedor válida en una zona de disponibilidad óptima en función de los pasos anteriores. Favorece las instancias de contenedores con el menor número de tareas en ejecución para este servicio.

Le recomendamos que utilice la característica de reequilibrio de servicios cuando utilice la estrategia de `REPLICA`, ya que ayuda a garantizar una alta disponibilidad del servicio.

### Estrategia de programación de daemon
<a name="service_scheduler_daemon"></a>

La estrategia de programación de *daemon* implementa exactamente una tarea en cada instancia de contenedor activa que cumpla todas las restricciones de ubicación de tareas especificadas en el clúster. El programador de servicios evalúa las restricciones de ubicación de las tareas en ejecución y detiene las tareas que no cumplen las restricciones de ubicación. Al utilizar esta estrategia, no es necesario especificar un número deseado de tareas ni una estrategia de ubicación de tareas, ni utilizar políticas de escalado automático de servicio.

Amazon ECS reserva los recursos de computación de la instancia de contenedor, incluido CPU, memoria e interfaces de red, para las tareas del daemon. Cuando se lanza un servicio daemon en un clúster con otros servicios de réplica, Amazon ECS prioriza la tarea del daemon. Esto significa que la tarea del daemon es la primera en lanzarse en las instancias y la última en detenerse después de que se detengan todas las tareas de réplica. Esta estrategia garantiza que las tareas de réplica pendientes no utilicen esos recursos y estén disponibles para las tareas del daemon.

El programador de servicios del daemon no ubica tareas en las instancias que tienen el estado `DRAINING`. Si una instancia de contenedor cambia al estado `DRAINING`, las tareas del daemon que incluya se detienen. El programador de servicios también monitorea cuándo se agregan nuevas instancias de contenedor al clúster y agrega las tareas de daemon en ellas.

Al especificar una configuración de implementación, el valor del parámetro `maximumPercent` debe ser `100` (especificado como porcentaje), que es el valor predeterminado que se utiliza si no se establece. El valor predeterminado del parámetro `minimumHealthyPercent` es `0` (especificado como porcentaje).

Debe reiniciar el servicio cuando cambie las restricciones de ubicación del servicio del daemon. Amazon ECS actualiza de forma dinámica los recursos reservados en instancias aptas para la tarea del daemon. Para las instancias existentes, el programador intenta ubicar la tarea en la instancia. 

Una nueva implementación se inicia cuando hay un cambio en el tamaño de la tarea o en la reserva de recursos del contenedor en la definición de la tarea. Una nueva implementación también comienza cuando se actualiza un servicio o se establece una revisión diferente de la definición de la tarea. Amazon ECS recoge las reservas de memoria y CPU actualizadas para el daemon y, a continuación, bloquea esa capacidad para la tarea del daemon.

Si no hay recursos suficientes para cualquiera de los casos anteriores, ocurre lo siguiente:
+ Se produce un error en la ubicación de la tarea.
+ Se genera un evento de CloudWatch.
+ Amazon ECS continúa intentando programar la tarea en la instancia a la espera de que los recursos estén disponibles. 
+ Amazon ECS libera todas las instancias reservadas que ya no cumplan con los criterios de restricción de ubicación y detiene las tareas de daemon correspondientes.

La estrategia de programación de daemon se puede utilizar en los siguientes casos:
+ Ejecución de contenedores de aplicaciones
+ Ejecución de contenedores de soporte para tareas de registro, monitoreo y seguimiento

Las tareas que utilizan Fargate o los tipos de controlador de implementación `CODE_DEPLOY` o `EXTERNAL` no admiten la estrategia de programación del daemon.

Cuando el programador de servicios detiene las tareas en ejecución, intenta mantener un balance entre las zonas de disponibilidad del clúster. El programador utiliza la siguiente lógica: 
+ Si se ha definido una estrategia de ubicación, utilice esta estrategia para seleccionar las tareas que deben terminar. Por ejemplo, si un servicio tiene definida una estrategia de distribución de zonas de disponibilidad, se seleccionará una tarea que deje a las demás tareas con la mejor distribución.
+ Si no hay ninguna estrategia de ubicación definida, mantenga el equilibrio entre las zonas de disponibilidad de su clúster con la siguiente lógica:
  + Ordene las instancias de contenedor válidas. Dé prioridad a las instancias que tienen el mayor número de tareas en ejecución para este servicio en su respectiva zona de disponibilidad. Por ejemplo, si la zona A tiene una tarea de servicio en ejecución y las zonas B y C tienen dos cada una, las instancias de contenedor en la zona B o C se consideran óptimas para terminación.
  + Detenga la tarea en una instancia de contenedor en una zona de disponibilidad óptima en función de los pasos anteriores. Priorice las instancias de contenedores con el mayor número de tareas en ejecución para este servicio.

## Controladores de implementación
<a name="service_deployment-controllers"></a>

El controlador de implementación es el mecanismo que determina cómo se implementan las tareas del servicio. Las opciones válidas son las siguientes:
+ ECS

  Al crear un servicio que utiliza el controlador de implementación de `ECS`, puede elegir entre las siguientes estrategias de implementación:
  + `ROLLING`: cuando crea un servicio que utiliza la estrategia de implementación de *actualización continua* (`ROLLING`), el programador de servicios de Amazon ECS sustituye las tareas que se están ejecutando actualmente por unas nuevas. El número de tareas que Amazon ECS agrega o elimina del servicio durante una actualización continua se controla mediante la configuración de implementación del servicio. 

    Las implementaciones de actualizaciones continuas son las más adecuadas para los siguientes escenarios:
    + Actualizaciones graduales del servicio: debe actualizar el servicio de forma gradual sin desconectar todo el servicio de una sola vez.
    + Requisitos de recursos limitados: desea evitar los costos generados por los recursos adicionales que supone ejecutar dos entornos completos de forma simultánea (como lo exigen las implementaciones azul/verde).
    + Tiempo de implementación aceptable: su aplicación puede tolerar un proceso de implementación más prolongado, ya que las actualizaciones continuas sustituyen las tareas una por una.
    + No es necesario realizar una reversión inmediata: su servicio puede tolerar un proceso de reversión que tarde minutos en lugar de segundos.
    + Proceso de implementación simple: prefiere un método de implementación sencillo sin la complejidad de administrar varios entornos, grupos de destino y oyentes.
    + No se requiere un equilibrador de carga: su servicio no usa ni requiere un equilibrador de carga, equilibrador de carga de aplicación, equilibrador de carga de red o Service Connect (que son necesarios para las implementaciones azul/verde).
    + Aplicaciones con estado: su aplicación mantiene un estado que dificulta la ejecución de dos entornos paralelos.
    + Sensibilidad a los costos: desea no tener que ejecutar entornos duplicados durante la implementación para minimizar los costos de implementación.

    Las actualizaciones continuas son la estrategia de implementación predeterminada de los servicios y proporcionan un equilibrio entre la seguridad de la implementación y la eficiencia de los recursos en muchos escenarios de aplicaciones comunes.
  + `BLUE_GREEN`: una estrategia de implementación *azul/verde* (`BLUE_GREEN`) es una metodología de lanzamiento que reduce el tiempo de inactividad y el riesgo al ejecutar dos entornos de producción idénticos, denominados azul y verde. Con las implementaciones azul/verde de Amazon ECS, puede validar las nuevas revisiones de servicios antes de dirigir el tráfico de producción hacia ellas. Este método proporciona una forma más segura de implementar cambios con la capacidad de revertirlos rápidamente si es necesario.

    Las implementaciones azul/verde de Amazon ECS son las más adecuadas para los siguientes escenarios:
    + Validación de servicio: cuando tiene que validar nuevas revisiones de servicio antes de dirigir el tráfico de producción hacia ellas
    + Tiempo de inactividad cero: cuando su servicio requiere implementaciones sin tiempo de inactividad
    + Reversión instantánea: cuando necesita la capacidad de revertir rápidamente si se detectan problemas
    + Requisito de equilibrador de carga: cuando su servicio utiliza un equilibrador de carga de aplicación, equilibrador de carga de red o Service Connect
  + `LINEAR`: una estrategia de implementación *lineal* (`LINEAR`) cambia gradualmente el tráfico del entorno de producción actual a un nuevo entorno en incrementos porcentuales iguales durante un periodo de tiempo específico. Con las implementaciones lineales de Amazon ECS, puede controlar el ritmo de cambio del tráfico y validar las nuevas revisiones de servicio con cantidades crecientes de tráfico de producción.

    Las implementaciones lineales de Amazon ECS son las más adecuadas para los siguientes escenarios:
    + Validación gradual: cuando desee validar gradualmente la nueva versión de su servicio con un aumento del tráfico
    + Supervisión del rendimiento: cuando necesita tiempo para supervisar las métricas y el rendimiento durante la implementación
    + Minimización de riesgos: cuando quiere minimizar los riesgos al exponer la nueva versión al tráfico de producción de forma incremental
    + Requisito de equilibrador de carga: cuando su servicio utiliza un equilibrador de carga de aplicación, equilibrador de carga de red o Service Connect
  + `CANARY`: una estrategia de implementación *canario* (`CANARY`) cambia primero un pequeño porcentaje del tráfico a la nueva revisión del servicio y, a continuación, cambia el tráfico restante de una sola vez después de un periodo de tiempo específico. Esto le permite probar la nueva versión con un subconjunto de usuarios antes de la implementación completa.

    Las implementaciones canario de Amazon ECS son las más adecuadas para los siguientes escenarios:
    + Pruebas de características: cuando desee probar nuevas características con un pequeño subconjunto de usuarios antes de la implementación completa
    + Validación de producción: cuando tenga que validar el rendimiento y la funcionalidad con tráfico de producción real
    + Control del radio de impacto: si desea minimizar el radio de impacto si se detectan problemas en la nueva versión
    + Requisito de equilibrador de carga: cuando su servicio utiliza un equilibrador de carga de aplicación, equilibrador de carga de red o Service Connect
+ Externo

  Utilice un controlador de implementación de terceros.
+ Implementación azul/verde (con tecnología de AWS CodeDeploy)

  CodeDeploy instala una versión actualizada de la aplicación como un nuevo conjunto de tareas de sustitución y vuelve a enrutar el tráfico de producción del conjunto de tareas original al conjunto de tareas de sustitución. Cuando la implementación se realiza correctamente, se termina el conjunto de tareas original. Este tipo de implementación permite verificar la nueva implementación de un servicio antes de enviar el tráfico de producción hacia este.

# Detección de errores de implementación de Amazon ECS
<a name="deployment-failure-detection"></a>

Amazon ECS proporciona dos métodos para detectar errores de implementación:
+ Interruptor de circuitos de implementación
+ Alarmas de CloudWatch

Ambos métodos se pueden configurar para revertir automáticamente las implementaciones con errores al último estado válido conocido.

Considere lo siguiente:
+ Ambos métodos solo admiten los tipos de implementación de actualizaciones continuas y de implementación azul/verde.
+ Cuando se utilizan ambos métodos, cualquiera de ellos puede provocar un error en la implementación.
+ El método de reversión requiere una implementación previa en estado COMPLETADO.
+ Se generan eventos de EventBridge para los cambios en el estado de la implementación.

# Detección de errores por el interruptor de circuito de implementación de Amazon ECS
<a name="deployment-circuit-breaker"></a>

El disyuntor de implementación es el mecanismo de actualización continua que determina si las tareas alcanzan un estado estable. El interruptor de implementación tiene una opción que revertirá automáticamente una implementación con errores a la implementación con el estado `COMPLETED`.

Cuando una implementación de servicio cambia de estado, Amazon ECS envía un evento de cambio de estado de implementación del servicio a EventBridge. Esto proporciona una forma programática de monitorear el estado de las implementaciones de servicios. Para obtener más información, consulte [Eventos de cambio de estado de implementación de servicios de Amazon ECS](ecs_service_deployment_events.md). Recomendamos que cree y supervise una regla de EventBridge con un `eventName` de `SERVICE_DEPLOYMENT_FAILED` para que pueda tomar medidas manuales para iniciar la implementación. Para obtener más información, consulte [Introducción a EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html) en la *Guía del usuario de Amazon EventBridge*.

Cuando el disyuntor de implementación determina que una implementación tiene errores, este busca la implementación más reciente que se encuentre en un estado `COMPLETED`. Esta es la implementación que utiliza como implementación restaurada. Cuando se inicia la reversión, la implementación cambia de `COMPLETED` a `IN_PROGRESS`. Esto significa que la implementación no es apta para otra reversión hasta que alcance el estado `COMPLETED`. Cuando el disyuntor de implementación no encuentra ninguna implementación que esté en estado `COMPLETED`, no inicia nuevas tareas y la implementación se detiene. 

Al crear un servicio, el programador hace un seguimiento de las tareas que no se pudieron iniciar en dos etapas.
+ Fase 1: el programador supervisa las tareas para comprobar si pasan al estado EN EJECUCIÓN.
  + Éxito: la implementación tiene posibilidades de pasar al estado COMPLETADO porque hay más de una tarea que ha pasado al estado EN EJECUCIÓN. Se omite el criterio de fallo y el disyuntor pasa a la fase 2.
  + Error: Hay tareas consecutivas que no pasaron al estado EN EJECUCIÓN y es posible que la implementación pase al estado ERROR. 
+ Fase 2: la implementación entra en esta etapa cuando hay al menos una tarea en ejecución. El disyuntor comprueba las comprobaciones de estado de las tareas de la implementación actual que se están evaluando. Las comprobaciones de estado validadas son Elastic Load Balancing, las comprobaciones de estado del servicio AWS Cloud Map y las comprobaciones de estado de los contenedores. 
  + Correcto: hay al menos una tarea en ejecución cuyas comprobaciones de estado se han superado.
  + Error: Las tareas que se reemplazan debido a errores en las comprobaciones de estado han alcanzado el umbral de error.

Tenga en cuenta lo siguiente cuando utilice el método del interruptor de implementación en un servicio. EventBridge genera la regla.
+ La respuesta de `DescribeServices` proporciona información sobre el estado de una implementación, el `rolloutState` y el `rolloutStateReason`. Cuando se inicia una nueva implementación, el estado de despliegue comienza en el estado `IN_PROGRESS`. Cuando el servicio alcanza un estado estable, el estado de implementación pasa a `COMPLETED`. Si el servicio no alcanza un estado estable y el interruptor está activado, la implementación pasará al estado `FAILED`. Una implementación en estado `FAILED` no lanzará ninguna tarea nueva.
+ Además de los eventos de cambio de estado de implementación del servicio que Amazon ECS envía para implementaciones que se han iniciado y completado, Amazon ECS también envía un evento cuando falla una implementación con interruptor activado. Estos eventos proporcionan detalles acerca de por qué falló una implementación o si se inició debido a una restauración. Para obtener más información, consulte [Eventos de cambio de estado de implementación de servicios de Amazon ECS](ecs_service_deployment_events.md).
+ Si se inicia una nueva implementación porque se produjo un error en una implementación anterior y causó una restauración, el campo `reason` del evento de cambio de estado de implementación del servicio indica que la implementación se inició debido a una restauración.
+ El interruptor de implementación solo es compatible con los servicios de Amazon ECS que utilizan el controlador de implementación de actualización continua (`ECS`).
+ Debe utilizar la consola de Amazon ECS o la AWS CLI cuando utilice el interruptor de implementación con la opción CloudWatch. Para obtener más información, consulte [Creación de un servicio a partir de los parámetros definidos](create-service-console-v2.md#create-custom-service) y [create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html) en la *Referencia de la AWS Command Line Interface*.

En los siguientes ejemplos de la AWS CLI de `create-service`, se muestra cómo crear un servicio de Linux cuando se usa el interruptor de implementación con la opción de restauración.

```
aws ecs create-service \
     --service-name MyService \
     --deployment-controller type=ECS \
     --desired-count 3 \
     --deployment-configuration "deploymentCircuitBreaker={enable=true,rollback=true}" \
     --task-definition sample-fargate:1 \
     --launch-type FARGATE \
     --platform-family LINUX \
     --platform-version 1.4.0 \
     --network-configuration "awsvpcConfiguration={subnets=[subnet-12344321],securityGroups=[sg-12344321],assignPublicIp=ENABLED}"
```

Ejemplo:

La implementación 1 está en estado `COMPLETED`.

La implementación 2 no puede iniciarse, por lo que el disyuntor vuelve a la implementación 1. La implementación 1 pasa al estado `IN_PROGRESS`.

La implementación 3 se inicia y no hay ninguna implementación en estado `COMPLETED`, por lo que la implementación 3 no puede revertir ni iniciar tareas. 

## Failure threshold
<a name="failure-threshold"></a>

El disyuntor de despliegue calcula el valor umbral y, a continuación, lo utiliza para determinar cuándo mover la implementación a un estado `FAILED`.

El disyuntor de implementación tiene un umbral mínimo de 3 y un umbral máximo de 200, y utiliza los valores de la siguiente fórmula para determinar el error de implementación.

```
Minimum threshold <= 0.5 * desired task count => maximum threshold
```

Cuando el resultado del cálculo es superior al mínimo de 3, pero inferior al máximo de 200, el umbral de error se establece en el umbral calculado (redondeado al alza).

**nota**  
No se puede cambiar ninguno de los valores de umbral.

Hay dos etapas para la comprobación del estado de la implementación.

1. El disyuntor de despliegue supervisa las tareas que forman parte de la implementación y comprueba las tareas que se encuentran en el estado `RUNNING`. El programador ignora los criterios de error cuando una tarea de la implementación actual se encuentra en el estado `RUNNING` y pasa a la siguiente etapa. Cuando las tareas no alcanzan en el estado `RUNNING`, el disyuntor de implementación aumenta el recuento de error en uno. Cuando el recuento de errores es igual al umbral, la implementación se marca como `FAILED`.

1. Se entra en esta etapa cuando hay una o más tareas en el estado `RUNNING`. El disyuntor de implementación realiza comprobaciones de estado de los siguientes recursos para las tareas de la implementación actual:
   + Balanceadores de carga de Elastic Load Balancing
   + AWS Cloud MapServicio de 
   + Comprobaciones de estado de los contenedores de Amazon ECS

   Cuando falla una comprobación de estado de la tarea, el disyuntor de implementación aumenta el recuento de errores en uno. Cuando el recuento de errores es igual al umbral, la implementación se marca como `FAILED`.

La siguiente tabla muestra algunos ejemplos.


| Recuento deseado de tareas | Cálculo | Umbral | 
| --- | --- | --- | 
|  1  |  <pre>3 <= 0.5 * 1 => 200</pre>  | 3 (el valor calculado es inferior al mínimo) | 
|  25  |  <pre>3 <= 0.5 * 25 => 200</pre>  | 13 (el valor se redondea hacia arriba) | 
|  400  |  <pre>3 <= 0.5 * 400 => 200</pre>  | 200 | 
|  800  |  <pre>3 <= 0.5 * 800 => 200</pre>  | 200 (el valor calculado es mayor que el máximo) | 

Por ejemplo, cuando el umbral es 3, el disyuntor comienza con el recuento de fallos establecido en 0. Cuando una tarea no alcanza el estado `RUNNING`, el disyuntor de implementación aumenta el recuento de error en uno. Cuando el recuento de errores es igual 3, la implementación se marca como `FAILED`.

Para obtener más ejemplos acerca de cómo usar la opción de restauración, consulte [Anuncio del interruptor de cirtcuito de implementación de Amazon ECS](https://aws.amazon.com/blogs/containers/announcing-amazon-ecs-deployment-circuit-breaker/).

# Detección de errores en la implementación de Amazon ECS por las alarmas de CloudWatch
<a name="deployment-alarm-failure"></a>

Puede configurar Amazon ECS para que defina la implementación como fallida cuando detecte que una alarma de CloudWatch específica ha pasado al estado `ALARM`.

Si lo desea, puede establecer la configuración para restaurar una implementación con errores a la última implementación completada.

En los siguientes ejemplos de la AWS CLI de `create-service`, se muestra cómo crear un servicio de Linux cuando se utilizan las alarmas de implementación con la opción de restauración.

```
aws ecs create-service \
     --service-name MyService \
     --deployment-controller type=ECS \
     --desired-count 3 \
     --deployment-configuration "alarms={alarmNames=[alarm1Name,alarm2Name],enable=true,rollback=true}" \
     --task-definition sample-fargate:1 \
     --launch-type FARGATE \
     --platform-family LINUX \
     --platform-version 1.4.0 \
     --network-configuration "awsvpcConfiguration={subnets=[subnet-12344321],securityGroups=[sg-12344321],assignPublicIp=ENABLED}"
```

Tenga en cuenta lo siguiente al utilizar el método de alarmas de Amazon CloudWatch en un servicio.
+ El tiempo durante el cual las revisiones de servicio azul y verde se ejecutan simultáneamente después de que se haya transferido el tráfico de producción. Amazon ECS calcula este periodo en función de la configuración de alarma asociada a la implementación. No puede establecer este valor. 
+ El parámetro de solicitud `deploymentConfiguration` ahora contiene el tipo de datos `alarms`. Puede especificar los nombres de las alarmas, si desea utilizar el método y si desea iniciar una restauración cuando las alarmas indiquen un error de implementación. Para obtener más información, consulte [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html) en la *Referencia de la API de Amazon Elastic Container Service*.
+ La respuesta de `DescribeServices` proporciona información sobre el estado de una implementación, el `rolloutState` y el `rolloutStateReason`. Cuando se inicia una nueva implementación, el estado de implementación comienza en el estado `IN_PROGRESS`. Cuando el servicio alcanza un estado estable y se completa el tiempo de incorporación, el estado de implementación pasa a `COMPLETED`. Si el servicio no alcanza un estado estable y la alarma pasa al estado `ALARM`, la implementación pasará al estado `FAILED`. Si el estado de una implementación es `FAILED`, no lanzará ninguna tarea nueva.
+ Además de los eventos de cambio de estado de implementación del servicio que Amazon ECS envía para implementaciones que se han iniciado y completado, Amazon ECS también envía un evento cuando se produce un error con una implementación que usa alarmas. Estos eventos proporcionan detalles acerca de por qué falló una implementación o si se inició debido a una restauración. Para obtener más información, consulte [Eventos de cambio de estado de implementación de servicios de Amazon ECS](ecs_service_deployment_events.md).
+ Si se inicia una nueva implementación porque se produjo un error en una implementación anterior y se activó la restauración, el campo `reason` del evento de cambio de estado de implementación de servicio indicará que la implementación se inició debido a una restauración.
+ Si utiliza el interruptor de implementación y las alarmas de Amazon CloudWatch para detectar errores, los dos pueden iniciar un error de implementación tan pronto como se cumplan los criterios de cualquiera de los métodos. Se produce una restauración cuando se utiliza esta opción en el método que inició el error de implementación.
+ Las alarmas de Amazon CloudWatch solo son compatibles con los servicios de Amazon ECS que utilizan el controlador de implementación de actualización continua (`ECS`).
+ Puede configurar esta opción mediante la consola de Amazon ECS o la AWS CLI. Para obtener más información, consulte [Creación de un servicio a partir de los parámetros definidos](create-service-console-v2.md#create-custom-service) y [create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html) en la *Referencia de la AWS Command Line Interface*.
+ Notará que el estado de implementación permanece `IN_PROGRESS` durante un periodo prolongado. La razón de esto es que Amazon ECS no cambia el estado hasta que no haya eliminado la implementación activa y esto no ocurre hasta después del tiempo de incorporación. En función de la configuración de alarmas, puede parecer que la implementación tarda varios minutos más que si no se utilizan alarmas (aunque el nuevo conjunto de tareas principal escale verticalmente y la implementación anterior se reduzca verticalmente). Si usa los tiempos de espera de CloudFormation, considere aumentarlos. Para obtener más información, consulte [Creación de condiciones de espera en una plantilla](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-waitcondition.html) en la *Guía del usuario de AWS CloudFormation*.
+ Amazon ECS llama a `DescribeAlarms` para sondear las alarmas. Las llamadas a `DescribeAlarms` contabilizarán para las cuotas de servicio de CloudWatch asociadas a su cuenta. Si tiene otros servicios de AWS que llamen a `DescribeAlarms`, Amazon ECS podría tener un impacto en el sondeo de las alarmas. Por ejemplo, si otro servicio hace suficientes llamadas a `DescribeAlarms` para alcanzar la cuota, ese servicio recibe una limitación y el de Amazon ECS también, y no puede sondear las alarmas. Si se genera una alarma durante el periodo de limitación, es posible que Amazon ECS no la detecte y que no se produzca la restauración. No hay ningún otro impacto en la implementación. Para obtener más información sobre las cuotas de servicio de CloudWatch, consulte [Service Quotas de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_limits.htm) en la *Guía del usuario de CloudWatch*.
+ Si hay una alarma en el estado `ALARM` al principio de una implementación, Amazon ECS no supervisará las alarmas mientras dure esa implementación (Amazon ECS ignora la configuración de la alarma). Este comportamiento aborda el caso en el que desee iniciar una nueva implementación para corregir un error de implementación inicial.

## Alarmas recomendadas
<a name="ecs-deployment-alarms"></a>

Le recomendamos que utilice las siguientes métricas de alarma:
+ Si usa un equilibrador de carga de aplicación, use las métricas de equilibrador de carga de aplicación `HTTPCode_ELB_5XX_Count` y `HTTPCode_ELB_4XX_Count`. Estas métricas comprueban si hay picos de HTTP. Para obtener más información acerca de las métricas del equilibrador de carga de aplicación, consulte [Métricas de CloudWatch para su equilibrador de carga de aplicación](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html) en la *Guía del usuario para equilibradores de carga de aplicaciones*.
+ Si ya tiene una aplicación, utilice las métricas `CPUUtilization` y `MemoryUtilization`. Estas métricas comprueban el porcentaje de CPU y memoria que utiliza el clúster o el servicio. Para obtener más información, consulte [Consideraciones](cloudwatch-metrics.md#enable_cloudwatch).
+ Si usa colas de Amazon Simple Queue Service en sus tareas, utilice la métrica `ApproximateNumberOfMessagesNotVisible` de Amazon SQS. Esta métrica comprueba el número de mensajes de la cola que van con retraso y no están disponibles para su lectura inmediata. Para obtener más información sobre las métricas de Amazon SQS, consulte [Métricas de CloudWatch disponibles para Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-available-cloudwatch-metrics.html) en la *Guía para desarrolladores de Amazon Simple Queue Service*.

## Tiempo procesamiento
<a name="deployment-bake-time"></a>

Cuando utiliza la opción de reversión para las implementaciones de servicios, Amazon ECS espera un periodo adicional después de implementar la revisión del servicio de destino antes de enviar una alarma de CloudWatch. Esto se conoce como tiempo de incorporación. Este tiempo comienza después de lo siguiente:
+ Todas las tareas de una revisión de servicio de destino están en marcha y en buen estado
+ Las revisiones del servicio de origen se han reducido al 0 %

El tiempo de incorporación predeterminado es inferior a 5 minutos. La implementación del servicio se marca como completada una vez transcurrido el tiempo de incorporación.

Puede configurar el tiempo de incorporación de una implementación continua. Al usar las alarmas de CloudWatch para detectar un error, si cambia el tiempo de incorporación y, a continuación, decide que prefiere el valor predeterminado de Amazon ECS, debe configurar el tiempo de incorporación manualmente.

# Enlaces de ciclo de vida para las implementaciones de servicios de Amazon ECS
<a name="deployment-lifecycle-hooks"></a>

Cuando se inicia una implementación, pasa por las etapas del ciclo de vida. Estas etapas pueden estar en estados como IN\$1PROGRESS o SUCCESSFUL. Puede utilizar enlaces de ciclo de vida, que son funciones de Lambda que Amazon ECS ejecuta en su nombre en etapas del ciclo de vida específicas. Las funciones pueden ser cualquiera de las siguientes opciones:
+ Una API asíncrona que valida la comprobación de estado en 15 minutos.
+ Una API de sondeo que inicia otro proceso asíncrono que evalúa la finalización del enlace de ciclo de vida. 

Una vez que la función haya terminado de ejecutarse, debe devolver un `hookStatus` para que la implementación continúe. Si no se devuelve un `hookStatus` o si la función falla, la implementación se revierte. Los siguientes son valores del `hookStatus`:
+ `SUCCEEDED`: la implementación pasa a la siguiente fase del ciclo de vida.
+ `FAILED`: la implementación se revierte a la última implementación correcta.
+ `IN_PROGRESS`: Amazon ECS vuelve a ejecutar la función tras un breve periodo. De forma predeterminada, es un intervalo de 30 segundos; sin embargo, este valor se puede personalizar devolviendo un `callBackDelay` junto con el `hookStatus`.

En el siguiente ejemplo se muestra cómo devolver un `hookStatus` con un retraso de devolución de llamada personalizado. En este ejemplo, Amazon ECS volvería a intentar este enlace en 60 segundos en lugar de los 30 segundos predeterminados:

```
{
    "hookStatus": "IN_PROGRESS",
    "callBackDelay": 60
}
```

Cuando se produce una reversión, Amazon ECS ejecuta los enlaces de ciclo de vida para las siguientes etapas de dicho ciclo de vida:
+ PRODUCTION\$1TRAFFIC\$1SHIFT
+ TEST\$1TRAFFIC\$1SHIFT

## Cargas útiles del ciclo de vida
<a name="service-deployment-lifecycle-payloads"></a>

 Cuando configura los enlaces de ciclo de vida para las implementaciones de sus servicios de ECS, Amazon ECS invoca estos enlaces en etapas específicas del proceso de implementación. Cada etapa del ciclo de vida proporciona una carga útil de JSON con información acerca del estado actual de la implementación. En este documento se describe la estructura de carga útil de cada etapa del ciclo de vida. 

### Estructura común de las cargas útiles
<a name="common-payload-structure"></a>

 Todas las cargas útiles de las etapas del ciclo de vida incluyen los siguientes campos comunes: 
+  `serviceArn`: el nombre de recurso de Amazon (ARN) del servicio. 
+  `targetServiceRevisionArn`: el ARN de la revisión de servicio de destino que se está implementando. 
+  `testTrafficWeights`: un mapa de los ARN de las revisiones de servicio con sus correspondientes porcentajes de ponderación de tráfico de prueba. 
+  `productionTrafficWeights`: un mapa de los ARN de las revisiones de servicio con sus correspondientes porcentajes de ponderación de tráfico de producción. 

### Cargas útiles de las etapas del ciclo de vida
<a name="lifecycle-stage-payloads"></a>

#### RECONCILE\$1SERVICE
<a name="reconcile-service"></a>

 Esta etapa se produce al principio del proceso de implementación cuando se está conciliando el servicio. A continuación, se muestra un ejemplo de carga útil para esta etapa del ciclo de vida.

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100,
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0
  },
  "productionTrafficWeights": {
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100,
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0
  }
}
```

 **Expectativas para esta etapa:** 
+ El conjunto de tareas principal está en una escala del 0 %

#### PRE\$1SCALE\$1UP
<a name="pre-scale-up"></a>

 Esta etapa se produce antes de que se escalen verticalmente las nuevas tareas. A continuación, se muestra un ejemplo de carga útil para esta etapa del ciclo de vida.

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {},
  "productionTrafficWeights": {}
}
```

 **Expectativas para esta etapa:** 
+ Las tareas de revisión de servicio verde están en una escala del 0 %

#### POST\$1SCALE\$1UP
<a name="post-scale-up"></a>

 Esta etapa se produce una vez que las nuevas tareas se han escalado verticalmente y están en buen estado. A continuación, se muestra un ejemplo de carga útil para esta etapa del ciclo de vida.

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {},
  "productionTrafficWeights": {}
}
```

 **Expectativas para esta etapa:** 
+ Las tareas de revisión de servicio verde están en una escala del 100 %
+ Las tareas de revisión de servicio verde están en buen estado

#### TEST\$1TRAFFIC\$1SHIFT
<a name="test-traffic-shift"></a>

 Esta etapa se produce cuando el tráfico de prueba se está transfiriendo a las tareas de revisión de servicio verde. 

A continuación, se muestra un ejemplo de carga útil para esta etapa del ciclo de vida.

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100,
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0
  },
  "productionTrafficWeights": {}
}
```

 **Expectativas para esta etapa:** 
+ El tráfico de pruebas está pasando hacia las tareas de revisión de servicio verde. 

#### POST\$1TEST\$1TRAFFIC\$1SHIFT
<a name="post-test-traffic-shift"></a>

 Esta etapa se produce después de que el tráfico de prueba se haya transferido por completo a las nuevas tareas. 

A continuación, se muestra un ejemplo de carga útil para esta etapa del ciclo de vida.

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {},
  "productionTrafficWeights": {}
}
```

 **Expectativas para esta etapa:** 
+ El 100 % del tráfico de prueba se destinó a las tareas de revisión de servicio verde. 

#### PRODUCTION\$1TRAFFIC\$1SHIFT
<a name="production-traffic-shift"></a>

 Esta etapa se produce cuando el tráfico de producción se está transfiriendo a las tareas de revisión de servicio verde. 

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {},
  "productionTrafficWeights": {
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892": 100,
    "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/78652123": 0
  }
}
```

 **Expectativas para esta etapa:** 
+ El tráfico de producción está pasando hacia la revisión de servicio verde. 

#### POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT
<a name="post-production-traffic-shift"></a>

 Esta etapa se produce cuando el tráfico de producción se ha transferido por completo a las tareas de revisión de servicio verde. 

```
{
  "serviceArn": "arn:aws:ecs:us-west-2:1234567890:service/myCluster/myService",
  "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:1234567890:service-revision/myCluster/myService/01275892",
  "testTrafficWeights": {},
  "productionTrafficWeights": {}
}
```

 **Expectativas para esta etapa:** 
+ El 100 % del tráfico de producción se destinó a las tareas de revisión de servicio verde. 

### Categorías de etapas del ciclo de vida
<a name="lifecycle-stage-categories"></a>

 Las etapas del ciclo de vida se dividen en dos categorías: 

1.  **Etapas de invocación única**: estas etapas se invocan solo una vez durante la implementación de un servicio: 
   + PRE\$1SCALE\$1UP
   + POST\$1SCALE\$1UP
   + POST\$1TEST\$1TRAFFIC\$1SHIFT
   + POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT

1.  **Etapas de invocación recurrentes**: estas etapas se pueden invocar varias veces durante la implementación de un servicio, por ejemplo, cuando se produce una operación de reversión: 
   + TEST\$1TRAFFIC\$1SHIFT
   + PRODUCTION\$1TRAFFIC\$1SHIFT

### Estado de la implementación durante los enlaces de ciclo de vida
<a name="deployment-status-during-lifecycle-hooks"></a>

 Mientras los enlaces de ciclo de vida estén en ejecución, el estado de la implementación será `IN_PROGRESS` para todas las etapas del ciclo de vida. 


| Etapa del ciclo de vida | Estado de la implementación | 
| --- | --- | 
| RECONCILE\$1SERVICE | IN\$1PROGRESS | 
| PRE\$1SCALE\$1UP | IN\$1PROGRESS | 
| POST\$1SCALE\$1UP | IN\$1PROGRESS | 
| TEST\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | 
| POST\$1TEST\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | 
| PRODUCTION\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | 
| POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | IN\$1PROGRESS | 

# Detención de las implementaciones de servicios de Amazon ECS
<a name="stop-service-deployment"></a>

Puede detener de forma manual una implementación cuando el interruptor o las alarmas de CloudWatch no detecten una implementación fallida. Están disponibles los siguientes tipos de detención:
+ Reversión: esta opción revierte la implementación del servicio a la revisión de servicio anterior. 

  Puede usar esta opción incluso si no configuró la implementación del servicio con la opción de reversión. 

Es posible detener una implementación que se encuentre en alguno de los estados siguientes. Para obtener más información sobre los estados de implementación de servicios, consulte [Visualización del historial de servicios mediante las implementaciones de servicios de Amazon ECS](service-deployment.md).
+ PENDING: la implementación del servicio pasa al estado ROLLBACK\$1REQUESTED y, a continuación, se inicia la operación de reversión.
+ IN\$1PROGRESS: la implementación del servicio pasa al estado ROLLBACK\$1REQUESTED y, a continuación, comienza la operación de reversión.
+ STOP\$1REQUESTED: la implementación del servicio continúa deteniéndose.
+ ROLLBACK\$1REQUESTED: la implementación del servicio continúa con la operación de reversión.
+ ROLLBACK\$1IN\$1PROGRESS: la implementación del servicio continúa con la operación de reversión.

## Procedimiento
<a name="stop-service-deployment-procedure"></a>

Antes de empezar, configure los permisos necesarios para ver las implementaciones de servicios. Para obtener más información, consulte [Permisos necesarios para ver las implementaciones de servicios de Amazon ECS](service-deployment-permissions.md).

------
#### [ 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 página **Clusters** (Clústeres), elija el clúster.

1. En la página de detalles del clúster, en la sección **Servicios**, elija el servicio.

   Aparecerá la página de detalles del servicio.

1. En la página de detalles del servicio, elija **Implementaciones**.

   Se muestra la página de implementaciones.

1. En **Implementación en curso**, elija **Revertir**. A continuación, en la ventana de confirmación, elija **Revertir**.

------
#### [ AWS CLI ]

1. Ejecute `list-service-deployments` para recuperar el ARN de implementación del servicio. 

   Sustituya las *entradas del usuario* por sus valores.

   ```
   aws ecs list-service-deployments --cluster cluster-name --service service-name
   ```

   Anote el valor de `serviceDeploymentArn` para la implementación que quiere detener.

   ```
   {
       "serviceDeployments": [
           {
               "serviceDeploymentArn": "arn:aws:ecs:us-west-2:123456789012:service-deployment/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5",
               "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/cluster-name/service-name",
               "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/cluster-name",
               "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:123456789012:service-revision/cluster-name/service-name/4980306466373577095",
               "status": "SUCCESSFUL"
           }
       ]
   }
   ```

1. Ejecuta `stop-service-deployments`. Utilice el identificador `serviceDeploymentArn` que se devolvió de `list-service-deployments`.

   Sustituya las *entradas del usuario* por sus valores.

   ```
   aws ecs stop-service-deployment --service-deployment-arn arn:aws:ecs:region:123456789012:service-deployment/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5 --stop-type ROLLBACK
   ```

------

## Siguientes pasos
<a name="stop-service-deployment-next-step"></a>

Decida qué cambios deben realizarse en el servicio y, a continuación, actualícelo. Para obtener más información, consulte [Actualización de un servicio de Amazon ECS](update-service-console-v2.md).

# Implementación de los servicios de Amazon ECS mediante el reemplazo de tareas
<a name="deployment-type-ecs"></a>

Cuando crea un servicio que utiliza el tipo de implementación de *actualización continua* (`ECS`), el programador de servicios de Amazon ECS reemplaza las tareas que se ejecutan en ese momento por unas nuevas. El número de tareas que Amazon ECS agrega o elimina del servicio durante una actualización continua se controla mediante la configuración de implementación del servicio. 

Amazon ECS utiliza los siguientes parámetros para determinar el número de tareas:
+ El valor `minimumHealthyPercent` representa el límite mínimo del número de tareas que se deben poner en marcha en buen estado para un servicio durante una implementación continua o cuando una instancia de contenedor se está agotando, como un porcentaje del número deseado de tareas para el servicio. Este valor se redondea hacia arriba. Por ejemplo, si el porcentaje mínimo en buen estado es `50` y el número de tareas deseado es cuatro, entonces el programador puede detener dos tareas existentes antes de iniciar dos nuevas. Del mismo modo, si el porcentaje mínimo en buen estado es del 75 % y el recuento de tareas deseado es dos, entonces el programador no puede detener ninguna tarea debido a que el valor resultante también es dos.
+ El valor `maximumPercent` representa el límite máximo del número de tareas que se deben poner en marcha para un servicio durante una implementación continua o cuando una instancia de contenedor se está agotando, como un porcentaje del número deseado de tareas para un servicio. Este valor se redondea hacia abajo. Por ejemplo, si el porcentaje máximo es `200` y el recuento de tareas deseado es cuatro, entonces el programador puede iniciar cuatro tareas nuevas antes de detener cuatro tareas existentes. Del mismo modo, si el porcentaje máximo es `125` y el recuento de tareas deseado es tres, el programador no puede iniciar ninguna tarea debido a que el valor resultante también es tres.

Durante una implementación continua, cuando las tareas tienen un estado incorrecto, Amazon ECS las reemplaza para mantener el valor de `minimumHealthyPercent` del servicio y proteger la disponibilidad. Las tareas con un estado incorrecto se sustituyen por la misma revisión de servicio a la que pertenecen. Esto garantiza que la sustitución de tareas con un estado incorrecto en la revisión de origen sea independiente de los errores de tareas en la revisión de destino. Cuando el parámetro `maximumPercent` lo permita, el programador inicializa las tareas de reemplazo antes de detener las que tienen un estado incorrecto. Si el parámetro `maximumPercent` impide que el programador inicie primero una tarea de reemplazo, detiene una tarea en mal estado de forma a la vez para liberar capacidad antes de inicializar una tarea de reemplazo.

**importante**  
Al establecer un porcentaje mínimo o uno máximo en buen estado, debe asegurarse de que el programador pueda detener o iniciar al menos una tarea cuando se inicia una implementación. Si la implementación del servicio está atascada debido a una configuración de implementación no válida, se enviará un mensaje de evento de servicio. Para obtener más información, consulte [servicio (*service-name*) no pudo detener o iniciar tareas durante una implementación debido a la configuración de implementación del servicio. Actualice el valor minimumHealthyPercent o MaximumPercent y vuelva a intentarlo.](service-event-messages-list.md#service-event-messages-7).

Las implementaciones continuas tienen dos métodos que proporcionan una forma de identificar rápidamente cuando se produce un error en la implementación de un servicio:
+ [Detección de errores por el interruptor de circuito de implementación de Amazon ECS](deployment-circuit-breaker.md)
+ [Detección de errores en la implementación de Amazon ECS por las alarmas de CloudWatch](deployment-alarm-failure.md)

Los métodos se pueden utilizar por separado o juntos. Si utiliza ambos métodos, la implementación se establece en un estado con errores en cuanto se cumplen los criterios de error de cualquiera de los métodos.

Utilice las siguientes directrices para determinar qué método debe utilizar:
+ Interruptor: utilice este método cuando quiera detener una implementación en caso de que las tareas no puedan iniciarse.
+ Alarmas de CloudWatch: utilice este método cuando quiera detener una implementación en función de las métricas de la aplicación.

Ambos métodos permiten revertir a la revisión de servicio anterior.

## Resolución de imagen de contenedor
<a name="deployment-container-image-stability"></a>

De forma predeterminada, Amazon ECS convierte las etiquetas de imágenes de contenedores especificadas en la definición de la tarea en resúmenes de imágenes de contenedores. Si crea un servicio que ejecuta y mantiene una sola tarea, esa tarea se utiliza para establecer los resúmenes de imágenes de los contenedores de la tarea. Si crea un servicio que ejecuta y mantiene varias tareas, la primera tarea iniciada por el programador de servicios durante la implementación se utiliza para establecer resúmenes de imágenes para los contenedores de las tareas.

Si se producen errores en tres o más intentos de establecer los resúmenes de imágenes del contenedor, la implementación continúa sin la resolución del resumen de la imagen. Si el interruptor de circuito de implementación está activado, la implementación también fallará y se revertirá.

Una vez establecidos los resúmenes de imágenes del contenedor, Amazon ECS los utiliza para iniciar cualquier otra tarea deseada y para cualquier futura actualización del servicio. Esto garantiza que todas las tareas de un servicio ejecuten siempre imágenes de contenedor idénticas, resultando en la consistencia de las versiones del software.

Puede configurar este comportamiento para cada contenedor de la tarea mediante el parámetro `versionConsistency` de la definición del contenedor. Para obtener más información, consulte [versionConsistency](task_definition_parameters.md#ContainerDefinition-versionconsistency).

**nota**  
Las versiones del agente de Amazon ECS inferiores a `1.31.0` no admiten la resolución de resúmenes de imágenes. Las versiones del agente `1.31.0` a `1.69.0` admiten la resolución de resúmenes de imágenes solo para las imágenes enviadas a los repositorios de Amazon ECR. Las versiones del agente `1.70.0` o superiores admiten la resolución de resúmenes de imágenes para todas las imágenes. 
La versión de la plataforma Fargate Linux mínima para la resolución de resumen de imágenes es `1.3.0`. La versión de la plataforma Fargate Windows mínima para la resolución de resumen de imágenes es `1.0.0`.
Amazon ECS no captura resúmenes de contenedores sidecar administrados por Amazon ECS, como el agente de seguridad Amazon GuardDuty o el proxy Service Connect.
Para reducir la latencia potencial asociada a la resolución de imágenes de contenedores en servicios con varias tareas, ejecute la versión del agente Amazon ECS `1.83.0` o superior en las instancias de contenedor EC2. Para evitar la latencia potencial, especifique los resúmenes de imágenes del contenedor en la definición de la tarea.
Si se crea un servicio con un recuento de tareas deseado igual a cero, Amazon ECS no podrá establecer los resúmenes del contenedor hasta que active otra implementación del servicio con un recuento de tareas deseado superior a cero.
Para establecer resúmenes de imágenes actualizados, puede forzar una nueva implementación. Los resúmenes actualizados se utilizarán para iniciar nuevas tareas y no afectarán a las tareas que ya estén en ejecución. Para obtener más información sobre cómo forzar nuevas implementaciones, consulte [ForceNewDeployment](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html#ECS-UpdateService-request-forceNewDeployment) en la *referencia de la API de Amazon* ECS.
Cuando se utilizan proveedores de capacidad de EC2, si no hay suficiente capacidad para iniciar una tarea durante la implementación inicial, es posible que no se logre la coherencia de las versiones del software. Para garantizar que se mantenga la coherencia de las versiones incluso cuando la capacidad sea limitada, configure `versionConsistency: "enabled"` de forma explícita en la configuración del contenedor de definición de tareas en lugar de basarse en el comportamiento predeterminado. Esto hace que Amazon ECS espere hasta que haya capacidad disponible antes de continuar con la implementación.

# Prácticas recomendadas para los parámetros de servicio de Amazon ECS
<a name="service-options"></a>

Para garantizar que no haya tiempo de inactividad de las aplicaciones, el proceso de implementación es el siguiente:

1. Inicie los nuevos contenedores de aplicaciones y mantenga en funcionamiento los contenedores existentes.

1. Compruebe que los nuevos contenedores estén en buen estado.

1. Detenga los contenedores antiguos.

 En función de la configuración de implementación y de la cantidad de espacio libre y sin reservar en el clúster, es posible que se necesiten varias rondas para completar el proceso y sustituir todas las tareas antiguas por tareas nuevas. 

Existen dos opciones de configuración del servicio que puede utilizar para modificar el número:
+ `minimumHealthyPercent`: 100 % (predeterminado)

  El límite inferior del número de tareas de su servicio que deben permanecer en el estado `RUNNING` durante una implementación. Es un porcentaje de `desiredCount` que se redondea al número entero más cercano. Este parámetro le permite implementar sin utilizar capacidad de clúster adicional.
+ `maximumPercent`: 200 % (predeterminado)

   El límite superior del número de tareas para su servicio que se permiten en el estado `RUNNING` o `PENDING` durante una implementación. Es un porcentaje de `desiredCount` que se redondea a la baja número entero más cercano.

**Ejemplo: Opciones de configuración predeterminadas**

Considere el siguiente servicio, que tiene seis tareas, implementado en un clúster con capacidad para ocho tareas en total. Las opciones de configuración del servicio predeterminadas no permiten que la implementación supere el 100 % de las seis tareas deseadas.

El proceso de implementación es el siguiente:

1. El objetivo es sustituir las seis tareas.

1. El programador inicia dos nuevas tareas porque la configuración predeterminada requiere que haya seis tareas en ejecución en todo momento.

   Ahora hay seis tareas existentes y dos nuevas en ejecución.

1. El programador detiene dos de las tareas existentes.

   Ahora hay cuatro tareas existentes y dos nuevas en ejecución.

1. El programador inicia dos nuevas tareas adicionales.

   Ahora hay cuatro tareas existentes y cuatro nuevas.

1. El programador detiene dos de las tareas existentes.

   Ahora hay dos tareas existentes y cuatro nuevas en ejecución.

1. El programador inicia dos nuevas tareas adicionales.

   Ahora hay dos tareas existentes y seis nuevas en ejecución.

1. El programador detiene las dos últimas tareas existentes.

   Ahora hay seis tareas nuevas en ejecución.

En el ejemplo anterior, si utiliza los valores predeterminados para las opciones, tendrá que esperar 2 minutos y medio para que se inicie una nueva tarea. Además, es posible que el equilibrador de carga tenga que esperar 5 minutos para que se detenga la tarea anterior. 

**Ejemplo: Modificar `minimumHealthyPercent`**

Puede acelerar la implementación estableciendo el valor `minimumHealthyPercent` en un 50 %.

Considere el siguiente servicio, que tiene seis tareas, implementado en un clúster con capacidad para ocho tareas en total. El proceso de implementación es el siguiente:

1. El objetivo es sustituir seis tareas.

1. El programador detiene tres de las tareas existentes. 

   Todavía hay tres tareas existentes en ejecución que cumplen con el valor `minimumHealthyPercent`.

1. El programador inicia cinco nuevas tareas.

   Ahora hay tres tareas existentes y cinco nuevas.

1. El programador detiene las tres tareas existentes restantes.

   Ahora hay cinco tareas nuevas.

1. El programador inicia las tareas nuevas finales.

   Ahora hay seis tareas nuevas.

**Ejemplo: Modificar el espacio libre del clúster**

También puede agregar espacio libre adicional para poder ejecutar tareas adicionales. 

Considere el siguiente servicio, que tiene seis tareas, implementado en un clúster con capacidad para diez tareas en total. El proceso de implementación es el siguiente:

1. El objetivo es sustituir las tareas existentes.

1. El programador detiene tres de las tareas existentes.

   Ahora hay tres tareas existentes.

1. El programador inicia seis tareas nuevas.

   Ahora tiene las tareas existentes y seis nuevas.

1. El programador detiene las tres tareas existentes.

   Ahora hay seis tareas nuevas.

**Recomendaciones**

Utilice los siguientes valores para las opciones de configuración del servicio cuando sus tareas estén inactivas durante algún tiempo y no tengan una tasa de uso elevada.
+ `minimumHealthyPercent`: 50 %
+ `maximumPercent`: 200 % 

# Creación de una implementación de actualización continua de Amazon ECS
<a name="create-service-console-v2"></a>

Cree un servicio para ejecutar y mantener simultáneamente un número determinado de instancias de una definición de tarea en un clúster. Si una de las tareas falla o se detiene, el programador de servicios de Amazon ECS lanza otra instancia de su definición de tarea para sustituirla. Esto ayuda a mantener el número deseado de tareas en el servicio.

Decida los siguientes parámetros de configuración antes de crear un servicio:
+ Hay dos opciones de computación que distribuyen sus tareas.
  + Una **estrategia de proveedor de capacidad** hace que Amazon ECS distribuya sus tareas en uno o varios proveedores de capacidad. 

    Si desea poner en marcha sus cargas de trabajo en instancias administradas de Amazon ECS, debe usar la opción de estrategia del proveedor de capacidad.
  + Un **tipo de lanzamiento** hace que Amazon ECS lance nuestras tareas directamente en Fargate o en las instancias de EC2 registradas en sus clústeres.

    Si desea poner en marcha sus cargas de trabajo en instancias administradas de Amazon ECS, debe usar la opción de estrategia del proveedor de capacidad.
+ Las definiciones de tareas que utilizan el modo de red `awsvpc` o los servicios configurados para utilizar un balanceador de carga deben tener una configuración de redes. De forma predeterminada, la consola selecciona la Amazon VPC predeterminada junto con todas las subredes y el grupo de seguridad predeterminado dentro de la Amazon VPC predeterminada. 
+ La estrategia de ubicación. La estrategia de ubicación de tareas predeterminada distribuye uniformemente las tareas entre las zonas de disponibilidad. 

  Le recomendamos que utilice el reequilibrio de zonas de disponibilidad para garantizar una alta disponibilidad del servicio. Para obtener más información, consulte [Equilibrio de un servicio de Amazon ECS entre zonas de disponibilidad](service-rebalancing.md).
+ Cuando utiliza el **Tipo de lanzamiento** para su implementación de servicios, el servicio se inicia en las subredes de su VPC de clúster de forma predeterminada.
+ En **capacity provider strategy** (estrategia de proveedor de capacidad), la consola selecciona una opción de computación de forma predeterminada. A continuación, se describe el orden que utiliza la consola para seleccionar un valor predeterminado:
  + Si su clúster tiene definida una estrategia de proveedor de capacidad por defecto, se seleccionará esa.
  + Si el clúster no tiene definida una estrategia de proveedores de capacidad predeterminada, pero sí tiene los proveedores de capacidad de Fargate agregados al clúster, se selecciona una estrategia de proveedores de capacidad personalizada que utiliza al proveedor de capacidad de `FARGATE`.
  + Si su clúster no tiene definida una estrategia de proveedor de capacidad por defecto, pero tiene uno o varios proveedores de capacidad de grupo de escalado automático agregados al clúster, se seleccionará la opción **Utilizar personalizado (Avanzado)** y tendrá que definir manualmente la estrategia.
  + Si el clúster no tiene definida ninguna estrategia de proveedores de capacidad predeterminada ni tiene proveedores de capacidad agregados al clúster, se selecciona el tipo de lanzamiento de Fargate.
+ Las opciones predeterminadas de detección de errores en implementación son utilizar el **disyuntor de implementación de Amazon ECS** con la opción de **reversión en caso de errores**.

  Para obtener más información, consulte [Detección de errores por el interruptor de circuito de implementación de Amazon ECS](deployment-circuit-breaker.md).
+ Decida si desea que Amazon ECS aumente o disminuya automáticamente la cantidad deseada de tareas del servicio. Para obtener información, consulte ., [Escalado automático de su servicio de Amazon ECS](service-auto-scaling.md).
+ Si necesita una aplicación para conectarse a otras aplicaciones que se ejecutan en Amazon ECS, determine la opción que se adapte a su arquitectura. Para obtener más información, consulte [Interconexión de los servicios de Amazon ECS](interconnecting-services.md). 
+ Cuando crea un servicio que utiliza un interruptor de Amazon ECS, Amazon ECS crea una implementación y una revisión de servicios. Estos recursos le permiten ver información detallada sobre el historial del servicio. Para obtener más información, consulte [Visualización del historial de servicios mediante las implementaciones de servicios de Amazon ECS](service-deployment.md).

  Para obtener información sobre cómo crear un servicio con la AWS CLI, consulte [https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html) en la *Referencia de la AWS Command Line Interface*.

  Para obtener información sobre cómo crear un servicio mediante AWS CloudFormation, consulte [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-service.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-service.html) en la *Guía del usuario de AWS CloudFormation*.

## Creación de un servicio con las opciones predeterminadas
<a name="create-default-service"></a>

Puede utilizar la consola para crear e implementar rápidamente un servicio. El servicio tiene la siguiente configuración:
+ Se implementa en la VPC y en las subredes asociadas a su clúster
+ Implementa una tarea
+ Utiliza la implementación continua
+ Utiliza la estrategia del proveedor de capacidad con su proveedor de capacidad predeterminado
+ Utiliza el disyuntor de implementación para detectar errores y establece la opción de restaurar automáticamente la implementación en caso de error

Para que la implementación de un servicio se lleve a cabo con los parámetros predeterminados, siga estos pasos.

**Para crear un servicio (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, elija **Clústeres**.

1. En la página **Clústeres**, seleccione el clúster en el que va a crear el servicio.

1. En la pestaña **Services** (Servicios), elija **Create** (Crear).

   Aparecerá la página **Crear servicio**.

1. En **Detalles del servicio**, haga lo siguiente:

   1. En **Definición de tareas**, ingrese la familia y la revisión de definiciones de tareas que se va a utilizar.

   1. En **Service name** (Nombre del servicio), ingrese un nombre para el servicio.

1. Para usar ECS Exec para depurar el servicio, en **Configuración de solución de problemas**, seleccione **Activar ECS Exec**.

1. En **Configuración de implementación**, haga lo siguiente:

   1. En **Desired tasks** (Tareas deseadas), ingrese el número de tareas que se lanzarán y mantendrán en el servicio.

1. (Opcional) Para ayudar a identificar el servicio y las tareas, expanda la sección **Tags** (Etiquetas) y, a continuación, configure sus etiquetas.

   Para que Amazon ECS etiquete automáticamente todas las tareas recién lanzadas con el nombre del clúster y las etiquetas de definición de tareas, seleccione **Turn on Amazon ECS managed tags** (Activar las etiquetas gestionadas de Amazon ECS) y, a continuación, seleccione **Task definitions** (Definiciones de tareas).

   Para que Amazon ECS etiquete automáticamente todas las tareas recién lanzadas con el nombre del clúster y las etiquetas de servicio, seleccione **Turn on Amazon ECS managed tags** (Activar las etiquetas gestionadas de Amazon ECS) y, a continuación, seleccione **Service** (Servicio).

   Añada o elimine una etiqueta.
   + [Agregar una etiqueta] Seleccione **Add tag** (Agregar etiqueta), y, a continuación, haga lo siguiente:
     + En **Clave**, escriba el nombre de la clave.
     + En **Valor**, escriba el valor de la clave.
   + [Eliminar una etiqueta] Junto a la etiqueta, elija **Remove tag (Quitar etiqueta)**.

## Creación de un servicio a partir de los parámetros definidos
<a name="create-custom-service"></a>

Para crear un servicio a partir de los parámetros definidos, siga estos pasos.

**Para crear un servicio (consola de Amazon ECS)**

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

1. Determine el recurso desde el que lanza el servicio.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/create-service-console-v2.html)

   Aparecerá la página **Crear servicio**.

1. En Detalles del servicio, haga lo siguiente:

   1. En **Definición de tarea**, ingrese la definición de la tarea que va a usar. A continuación, en **Revisión**, elija la revisión que desee utilizar.

   1. En **Service name** (Nombre del servicio), ingrese un nombre para el servicio.

1. En **Clúster existente**, elija el clúster.

   Elija **Crear clúster** para ejecutar la tarea en un clúster nuevo

1. Elija cómo distribuir las tareas en la infraestructura de clúster. En **Configuración de computación**, elija su opción.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/create-service-console-v2.html)

1. Para usar ECS Exec para depurar el servicio, en **Configuración de solución de problemas**, seleccione **Activar ECS Exec**.

1. En **Configuración de implementación**, haga lo siguiente:

   1. En **Service type** (Tipo de servicio), elija la estrategia de programación del servicio.
      + Para que el programador implemente exactamente una tarea en cada instancia de contenedor activa que cumpla con todas las restricciones de colocación de tareas, elija **Daemon**.
      + Para que el programador coloque y mantenga el número deseado de tareas en su clúster, elija **Replica** (Réplica).

   1. Si eligió **Replica** (Réplica), en **Desired tasks** (Tareas deseadas), ingrese el número de tareas que se lanzarán y mantendrán en el servicio.

   1. Si eligió **Réplica** para que Amazon ECS supervise la distribución de las tareas entre las zonas de disponibilidad y las redistribuya cuando haya un desequilibrio, en **Reequilibrio del servicio de zonas de disponibilidad**, seleccione **Reequilibrio del servicio de zonas de disponibilidad**.

   1. En **Periodo de gracia de la comprobación de estado**, ingrese la cantidad de tiempo (en segundos) durante la cual el programador de servicios ignora las comprobaciones de estado de Elastic Load Balancing, VPC Lattice y contenedor en mal estado después de que se haya iniciado una tarea por primera vez. Si no se especifica ningún valor para el período de gracia de comprobación de estado, se utiliza el valor predeterminado: 0.

   1. Determine el tipo de implementación de su servicio. Amplíe **Opciones de implementación** y, a continuación, especifique los siguientes parámetros.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/create-service-console-v2.html)

   1. Para configurar el modo en que Amazon ECS detecta y gestiona los errores de implementación, expanda **Deployment failure detection** (Detección de errores de implementación) y, a continuación, elija sus opciones. 

      1. Para detener una implementación cuando las tareas no puedan iniciarse, seleccione **Use the Amazon ECS deployment circuit breaker** (Utilizar el interruptor de circuito de implementación de Amazon ECS).

         Para que el software restaure automáticamente la implementación a su último estado completado cuando el disyuntor de implementación establezca un estado con error, seleccione **Restauración en caso de error**.

      1. Para detener una implementación en función de las métricas de la aplicación, seleccione **Use CloudWatch alarms**. A continuación, elija las alarmas en **Nombre de la alarma de CloudWatch**. Para crear una alarma nueva, vaya a la consola de CloudWatch.

         Para que el software restaure automáticamente la implementación a su último estado de implementación completada cuando una alarma de CloudWatch establezca un estado con error, seleccione **Restauración en caso de error**.

1. Si la definición de la tarea utiliza el modo de red `awsvpc`, puede especificar una configuración de red personalizada, expandir **Redes** y, a continuación, hacer lo siguiente:

   1. En **VPC**, seleccione la VPC que se va a usar.

   1. En **Subnets** (Subredes), seleccione una o varias subredes de la VPC que el programador de tareas considera al ubicar sus tareas.

   1. En **Security groups** (Grupos de seguridad), puede seleccionar un grupo de seguridad existente o crear uno nuevo. Para utilizar un grupo de seguridad existente, seleccione el grupo de seguridad y continúe con el próximo paso. Para crear un grupo de seguridad, elija **Create a new security group (Crear un grupo de seguridad nuevo)**. Debe especificar un nombre de grupo de seguridad, una descripción y, a continuación, agregar una o varias reglas de entrada para el grupo de seguridad.

   1. En **Public IP** (IP pública), elija si desea asignar automáticamente una dirección IP pública a la interfaz de red elástica (ENI) de la tarea.

      Las tareas de AWS Fargate pueden recibir una dirección IP pública cuando se ejecuten mediante una subred pública para que tengan una ruta a Internet. A las tareas de EC2 no se les puede asignar una IP pública mediante este campo. Para obtener más información, consulte [Opciones de redes de tareas de Amazon ECS para Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-task-networking.html) y [Asignación de una interfaz de red para una tarea de Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking-awsvpc.html).

1. (Opcional) Para interconectar su servicio con Service Connect, expanda **Service Connect** y, a continuación, especifique lo siguiente:

   1.  Seleccione **Activar Service Connect**.

   1. En **Service Connect configuration** (Configuración de Service Connect), especifique el modo cliente.
      + Si su servicio ejecuta una aplicación cliente de red que solo necesita conectarse a otros servicios del espacio de nombres, elija **Solo en el lado del cliente**.
      + Si su servicio ejecuta una aplicación de servicio web o red y necesita proporcionar puntos de conexión para este servicio y se conecta a otros servicios del espacio de nombres, elija **Client and server** (Cliente y servidor).

   1. Para usar un espacio de nombres que no sea el espacio de nombres predeterminado del clúster, en **Namespace** (Espacio de nombres), elija el espacio de nombres del servicio. Puede ser un espacio de nombres creado por separado en la misma Región de AWS de su Cuenta de AWS o un espacio de nombres en la misma región que se comparta con su cuenta mediante AWS Resource Access Manager (AWS RAM). Para obtener más información sobre los espacios de nombres de AWS Cloud Map compartidos, consulte [Cross-account AWS Cloud Map namespace sharing](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) en la *Guía para desarrolladores de AWS Cloud Map*.

   1. (Opcional) Especifique una configuración de registro. Seleccione **Utilizar colección de registros**. La opción predeterminada envía registros de contenedor a los Registros de CloudWatch. Las demás opciones del controlador de registro se configuran mediante AWS FireLens. Para obtener más información, consulte [Envío de registros de Amazon ECS a un servicio de AWS o AWS Partner](using_firelens.md).

      A continuación, se describe con más detalle cada uno de los destinos de registro de contenedor.
      + **Amazon CloudWatch**: configure la tarea para enviar registros de contenedor a CloudWatch Logs. Se proporcionan las opciones de controlador de registro predeterminadas que crean un grupo de registros de CloudWatch en su nombre. Para especificar otro nombre de grupo de registros, cambie los valores de las opciones del controlador.
      + **Amazon Data Firehose**: configure la tarea para enviar registros de contenedor a Firehose. Se proporcionan las opciones de controlador de registro predeterminadas que envían registros a un flujo de entrega de Firehose. Para especificar un nombre de flujo de entrega distinto, cambie los valores de las opciones del controlador.
      + **Amazon Kinesis Data Streams**: configure la tarea para enviar registros de contenedores a Kinesis Data Streams. Se proporcionan las opciones de controlador de registro predeterminadas que envían registros a un flujo de Kinesis Data Streams. Para especificar otro nombre de transmisión, cambie los valores de las opciones del controlador.
      + **Amazon OpenSearch Service**: configure la tarea para enviar registros de contenedor a un dominio de OpenSearch Service. Se deben proporcionar las opciones del controlador de registros. 
      + **Amazon S3**: configure la tarea para enviar registros de contenedor a un bucket de Amazon S3. Se proporcionan las opciones de controlador de registro predeterminadas, pero debe especificar un nombre de bucket de Amazon S3 válido.

   1. (Opcional) Para habilitar los registros de acceso, siga estos pasos:

      1. Amplíe **Configuración del registro de acceso**. En **Formato**, elija **JSON** o `TEXT`.

      1. Para incluir los parámetros de consulta en los registros de acceso, seleccione **Incluir parámetros de consulta**.

1. (Opcional) Para interconectar su servicio con Detección de servicios, expanda la opción **Detección de servicios** y, a continuación, haga lo siguiente.

   1. Seleccione **Utilizar la detección de servicios**.

   1. Para usar un espacio de nombres nuevo, seleccione **Crear un nuevo espacio de nombres** en **Configurar el espacio de nombres** y, a continuación, proporcione un nombre y una descripción del espacio de nombres. Para usar un espacio de nombres existente, elija **Seleccione un espacio de nombres existente** y, a continuación, elija el espacio de nombres que desea usar.

   1. Proporcione la información del servicio de detección de servicios, como el nombre y la descripción del servicio.

   1. Para que Amazon ECS ejecute comprobaciones de estado periódicas por contenedor, seleccione **Habilitar la propagación del estado de las tareas de Amazon ECS**.

   1. En **Tipo de registro DNS**, seleccione el tipo de registro DNS para el servicio. La detección de servicios de Amazon ECS solo admite registros **A** y **SRV**, según el modo de red que se especifique en la definición de tareas. Para obtener más información sobre estos tipos de registros, consulte [Tipos de registros de DNS que se admiten](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/ResourceRecordTypes.html) en la *Guía para desarrolladores de Amazon Route 53*.
      + Si la definición de tarea que especifica su tarea de servicio utiliza el modo de red `bridge` o `host`, solo se admiten los registros de tipo **SRV**. Elija una combinación de nombre y contenedor de contenedor para asociarla con el registro.
      + Si la definición de tarea que especifica su tarea de servicio utiliza el modo de red `awsvpc`, seleccione el tipo de registro **A** o **SRV**. Si eligió **A**, vaya al siguiente paso. Si está seleccionado el tipo **SRV**, especifique el puerto en el que se puede encontrar el servicio o una combinación de nombre y puerto de contenedor para asociarla con el registro.

      En el caso del **TTL**, introduzca el tiempo en segundos en el que los solucionadores de DNS y los navegadores web almacenan en caché un conjunto de registros.

1. (Opcional) Para interconectar su servicio con VPC Lattice, expanda la opción **VPC Lattice** y, a continuación, haga lo siguiente:

   1. Seleccione **Activar VPC Lattice**

   1. En **Rol de infraestructura**, elija el rol de infraestructura.

      Si no ha creado un rol, elija **Crear rol de infraestructura**.

   1. En **Grupos de destino**, elija el grupo o grupos de destino. Debe elegir un mínimo de un grupo de destino y un máximo de cinco. Elija **Agregar grupo de destino** para agregar grupos de destino adicionales. Elija el **nombre del puerto**, el **protocolo** y el **puerto** para cada grupo de destino que elija. 

      Para eliminar un grupo de destino, elija **Eliminar**.
**nota**  
Si quiere agregar grupos de destino existentes, debe utilizar la AWS CLI. Para obtener instrucciones sobre cómo agregar grupos de destino mediante la AWS CLI, consulte [register-targets](https://docs.aws.amazon.com/cli/latest/reference/vpc-lattice/register-targets.html) en la *Referencia de AWS Command Line Interface*.
Si bien un servicio de VPC Lattice puede tener varios grupos de destino, cada grupo de destino solo se puede agregar a un servicio.

   1. Para completar la configuración de VPC Lattice, mediante la inclusión de los nuevos grupos de destino en la acción predeterminada del agente de escucha o en las reglas de un servicio de VPC Lattice existente en la consola de VPC Lattice. Para obtener más información, consulte [Reglas de oyente para el servicio de VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/listener-rules.html).

1. (Opcional) Para configurar un equilibrador de carga para el servicio, expanda **Load balancing** (Equilibrio de carga).

   Elija el equilibrador de carga.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/create-service-console-v2.html)

1. (Opcional) Para configurar el escalado automático de servicios, expanda **Escalado automático de servicios** y, a continuación, especifique los siguientes parámetros. Para utilizar el escalado automático predictivo, que analiza los datos de cargas anteriores de los flujos de tráfico, configúrelo después de crear el servicio. Para obtener más información, consulte [Uso de patrones históricos para escalar los servicios de Amazon ECS con escalado predictivo](predictive-auto-scaling.md).

   1. Para utilizar el escalado automático de servicios, seleccione **Service auto scaling** (Escalado automático de servicios).

   1. En **Cantidad mínima de tareas**, ingrese el límite mínimo del número de tareas que se va a utilizar para el escalado automático del servicio. El recuento deseado no será inferior a este recuento.

   1. En **Cantidad máxima de tareas**, ingrese el límite máximo del número de tareas que se va a utilizar para el escalado automático del servicio. El recuento deseado no será superior a este recuento.

   1. Elija el tipo de política. En **Tipo de política de escalado**, elija una de las siguientes opciones.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/create-service-console-v2.html)

1. (Opcional) Para utilizar una estrategia de ubicación de tareas distinta a la predeterminada, expanda **Task Placement** (Ubicación de tareas) y, a continuación, elija una de las siguientes opciones.

    Para obtener más información, consulte [Cómo coloca Amazon ECS las tareas en las instancias de contenedor](task-placement.md).
   + **Reparto equilibrado en AZ**: distribuya las tareas en las zonas de disponibilidad y entre las instancias de contenedor dentro de cada zona de disponibilidad.
   + **BinPack equilibrado en AZ**: distribuya las tareas en las zonas de disponibilidad y entre las instancias de contenedor con la menor memoria disponible.
   + **BinPack**: distribuya las tareas en función de la cantidad mínima de CPU o memoria disponible.
   + **Una tarea por Host**: coloque como máximo una tarea del servicio en cada instancia de contenedor.
   + **Personalizado**: defina su propia estrategia de colocación de tareas. 

   Si elige **Custom** (Personalizado), defina el algoritmo de ubicación de tareas y las reglas que se tienen en cuenta durante la ubicación de tareas.
   + En **Strategy** (Estrategia), para **Type** (Tipo) y **Field** (Campo), elija el algoritmo y la entidad que quiere utilizar para el algoritmo.

     Puede ingresar un máximo de 5 estrategias.
   + En **Restricción**, para **Tipo** y **Expresión**, elija la regla y el atributo para la restricción.

     Por ejemplo, para establecer la restricción de colocar las tareas en las instancias T2, para la **Expresión**, ingrese **attribute:ecs.instance-type =\$1 t2.\$1**.

     Puede ingresar un máximo de 10 restricciones.

1. Si su tarea usa un volumen de datos compatible con la configuración en el momento de la implementación, puede expandir **Volume** para configurar el volumen.

   El nombre del volumen y el tipo de volumen se configuran al crear una revisión de definición de tareas y no se pueden cambiar al crear un servicio. Para actualizar el nombre y el tipo del volumen, debe crear una nueva revisión de la definición de tareas y crear un servicio con la nueva revisión.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/create-service-console-v2.html)

1. Para usar ECS Exec para depurar el servicio, en **Configuración de solución de problemas**, seleccione **Activar ECS Exec**.

1. (Opcional) Para ayudar a identificar el servicio y las tareas, expanda la sección **Tags** (Etiquetas) y, a continuación, configure sus etiquetas.

   Para que Amazon ECS etiquete automáticamente todas las tareas recién lanzadas con el nombre del clúster y las etiquetas de definición de tareas, seleccione **Activar las etiquetas administradas de Amazon ECS** y, a continuación, en **Propagar etiquetas de**, seleccione **Definiciones de tareas**.

   Para que Amazon ECS etiquete automáticamente todas las tareas recién lanzadas con el nombre del clúster y las etiquetas de servicio, seleccione **Activar las etiquetas administradas de Amazon ECS** y, a continuación, en **Propagar etiquetas de**, seleccione **Servicio**.

   Añada o elimine una etiqueta.
   + [Agregar una etiqueta] Seleccione **Add tag** (Agregar etiqueta), y, a continuación, haga lo siguiente:
     + En **Clave**, escriba el nombre de la clave.
     + En **Valor**, escriba el valor de la clave.
   + [Eliminar una etiqueta] Junto a la etiqueta, elija **Remove tag (Quitar etiqueta)**.

1. Seleccione **Crear**.

## Siguientes pasos
<a name="create-service-next-steps"></a>

Las siguientes son acciones adicionales que están disponibles después de crear un servicio.
+ Configure el escalado automático predictivo, que analiza los datos de cargas anteriores de los flujos de tráfico. Para obtener más información, consulte [Uso de patrones históricos para escalar los servicios de Amazon ECS con escalado predictivo](predictive-auto-scaling.md).
+ Haga un seguimiento de la implementación y consulte el historial de los servicios que utiliza el interruptor de Amazon ECS. Para obtener más información, consulte [Visualización del historial de servicios mediante las implementaciones de servicios de Amazon ECS](service-deployment.md).

# Implementaciones “blue/green” de Amazon ECS
<a name="deployment-type-blue-green"></a>

Una estrategia de implementación azul/verde es una metodología de lanzamiento que reduce el tiempo de inactividad y el riesgo al ejecutar dos entornos de producción idénticos, denominados azul y verde. Con las implementaciones azul/verde de Amazon ECS, puede validar las nuevas revisiones de servicios antes de dirigir el tráfico de producción hacia ellas. Este método proporciona una forma más segura de implementar cambios con la capacidad de revertirlos rápidamente si es necesario.

## Ventajas
<a name="blue-green-deployment-benefits"></a>

El uso de las implementaciones azul/verde ofrece los siguientes beneficios:
+ Reduce el riesgo mediante pruebas con el tráfico de producción antes de cambiar de producción. Puede validar la nueva implementación con tráfico de prueba antes de dirigir el tráfico de producción hacia él.
+ Implementaciones sin tiempo de inactividad. El entorno de producción permanece disponible durante todo el proceso de implementación, lo que garantiza la disponibilidad continua del servicio.
+ Reversión sencilla si se detectan problemas. Si surgen problemas con la implementación verde, puede volver rápidamente a la implementación azul sin interrumpir el servicio por periodos prolongados.
+ Entorno de pruebas controlado. El entorno verde proporciona un espacio aislado para comprobar nuevas características con patrones de tráfico reales antes de su implementación completa.
+ Proceso de implementación predecible. El método estructurado con etapas del ciclo de vida definidas hace que las implementaciones sean más coherentes y fiables.
+ Validación automatizada mediante enlaces de ciclo de vida. Puede incorporar pruebas automatizadas en varias etapas de la implementación para verificar la funcionalidad.

## Terminología
<a name="blue-green-deployment-terms"></a>

A continuación se indican los términos de implementación azul/verde de Amazon ECS:
+ Tiempo de incorporación: el tiempo durante el cual las revisiones de servicio azul y verde se ejecutan simultáneamente después de que se haya transferido el tráfico de producción.
+ Implementación azul: la revisión de servicio de producción actual que desea sustituir.
+ Implementación verde: la nueva revisión de servicio que desea implementar.
+ Etapas del ciclo de vida: serie de eventos de la operación de implementación, como “una transferencia de tráfico posterior a la producción”.
+ Enlace de ciclo de vida: una función de Lambda que verifica la implementación en una etapa específica del ciclo de vida.
+ Oyente: un recurso de Elastic Load Balancing que comprueba las solicitudes de conexión utilizando el protocolo y el puerto configurados. Las reglas que defina para un oyente determinan cómo Amazon ECS va a enrutar las solicitudes hacia sus destinos registrados.
+ Regla: un recurso de Elastic Load Balancing asociado a un oyente. Una regla define cómo se enrutan las solicitudes y consta de una acción, una condición y una prioridad.
+ Grupo de destino: un recurso de Elastic Load Balancing que se utiliza para enrutar las solicitudes a uno o más destinos registrados (por ejemplo, instancias de EC2). Cuando se crea un agente de escucha, especifica un grupo de destino para su acción predeterminada. El tráfico se reenvía al grupo de destino especificado en la regla del agente de escucha.
+ Transferencia de tráfico: el proceso que Amazon ECS utiliza para transferir el tráfico de la implementación azul a la implementación verde. Para las implementaciones azul/verde de Amazon ECS, todo el tráfico se transfiere del servicio azul al servicio verde a la vez.

## Consideraciones
<a name="blue-green-deployment-considerations"></a>

Tenga en cuenta lo siguiente al elegir un tipo de implementación:
+ Uso de recursos: las implementaciones azul/verde ejecutan temporalmente las revisiones de servicio azul y verde simultáneamente, lo que puede duplicar el uso de recursos durante las implementaciones.
+ Monitoreo de la implementación: las implementaciones azul/verde proporcionan información más detallada sobre el estado de la implementación, lo que le permite monitorear cada etapa del proceso de implementación.
+ Reversión: las implementaciones azul/verde facilitan la reversión a la versión anterior si se detectan problemas, ya que la revisión azul se mantiene activa hasta que vence el tiempo de incorporación.
+ Enlaces de ciclo de vida del Equilibrador de carga de red: si utiliza un Equilibrador de carga de red para las implementaciones azul/verde, hay 10 minutos adicionales para cada etapa de ciclo de vida de TEST\$1TRAFFIC\$1SHIFT y PRODUCTION\$1TRAFFIC\$1SHIFT. Esto se debe a que Amazon ECS se cerciora de que sea seguro cambiar el tráfico.

# Flujo de trabajo de implementación de servicios azul/verde de Amazon ECS
<a name="blue-green-deployment-how-it-works"></a>

El proceso de implementación azul/verde de Amazon ECS sigue un método estructurado con seis fases distintas que garantizan actualizaciones de aplicaciones seguras y fiables. Cada fase tiene un propósito específico al validar y hacer la transición de la aplicación de la versión actual (azul) a la nueva versión (verde).

1. **Fase de preparación**: cree el entorno verde junto con el entorno azul existente. Esto incluye el aprovisionamiento de nuevas revisiones de los servicios y la preparación de los grupos de destino.

1. **Fase de implementación**: implemente la nueva revisión de servicio en un entorno verde. Amazon ECS lanza nuevas tareas mediante la revisión de servicio actualizada, mientras que el entorno azul sigue sirviendo al tráfico de producción.

1. **Fase de prueba**: valide el entorno verde mediante el enrutamiento del tráfico de prueba. El equilibrador de carga de aplicación dirige las solicitudes de prueba al entorno verde mientras que el tráfico de producción permanece en el entorno azul.

1. **Fase de transferencia de tráfico**: transfiera el tráfico de producción de azul a verde en función de la estrategia de implementación que haya configurado. Esta fase incluye puntos de control de monitoreo y validación.

1. **Fase de monitoreo**: monitoree el estado de las aplicaciones, las métricas de rendimiento y los estados de alarma durante el periodo correspondiente al tiempo de incorporación. Cuando se detectan problemas, se inicia una operación de reversión.

1. **Fase de finalización**: finalice la implementación cerrando el entorno azul o manteniéndolo para posibles escenarios de reversión, según la configuración.

## Flujo de trabajo
<a name="blue-green-deployment-workflow"></a>

El siguiente diagrama ilustra el flujo de trabajo integral de implementación azul/verde y muestra la interacción entre Amazon ECS y el equilibrador de carga de aplicación:

![\[Diagrama completo en el que se muestra el proceso de implementación azul/verde en Amazon ECS con interacciones detalladas de los componentes, fases de transferencia de tráfico y puntos de control de monitoreo\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/images/blue-green.png)


El flujo de trabajo de implementación mejorado incluye los siguientes pasos detallados:

1. **Estado inicial**: el servicio azul (producción actual) administra el 100 % del tráfico de producción. El equilibrador de carga de aplicación tiene un único oyente con reglas que enrutan todas las solicitudes al grupo de destino azul que contiene tareas azules en buen estado.

1. **Aprovisionamiento de un entorno verde**: Amazon ECS crea nuevas tareas mediante la definición de tareas actualizada. Estas tareas se registran en un nuevo grupo de destino verde, pero inicialmente no reciben tráfico.

1. **Validación de comprobaciones de estado**: el equilibrador de carga de aplicación realiza comprobaciones de estado de las tareas verdes. La implementación solo pasa a la siguiente fase cuando las tareas verdes superan las comprobaciones de estado.

1. **Enrutamiento de tráfico de prueba**: si están configuradas, las reglas de oyente del equilibrador de carga de aplicación enrutan patrones de tráfico específicos (como las solicitudes con encabezados de prueba) al entorno verde para su validación, mientras que el tráfico de producción permanece en el entorno azul. Esto lo controla el mismo oyente que gestiona el tráfico de producción mediante reglas diferentes en función de los atributos de las solicitudes.

1. **Transferencia de tráfico de producción**: transfiera el tráfico de producción de azul a verde en función de la configuración de implementación. En las implementaciones azul/verde de ECS, se trata de una transferencia inmediata (de una sola vez) en la que el 100 % del tráfico se traslada del entorno azul al verde. El equilibrador de carga de aplicación utiliza un único oyente con reglas correspondientes que controlan la distribución del tráfico entre los grupos de destino azules y verdes en función de las ponderaciones.

1. **Monitoreo y validación**: durante toda la transferencia de tráfico, Amazon ECS monitorea las métricas de CloudWatch, los estados de alarma y el estado de la implementación. Los activadores automáticos de reversión se activan si se detectan problemas.

1. **Tiempo de incorporación**: el tiempo durante el cual las revisiones de servicio azul y verde se ejecutan simultáneamente después de que se haya transferido el tráfico de producción.

1. **Cierre del entorno azul**: tras la validación y transferencia de tráfico correctos, se ciera el entorno azul para liberar recursos del clúster o se mantiene para poder revertirlo rápidamente.

1. **Estado final**: el entorno verde se convierte en el nuevo entorno de producción y gestiona el 100 % del tráfico. La implementación está marcada como exitosa.

## Etapas del ciclo de vida de la implementación
<a name="blue-green-deployment-stages"></a>

El proceso de implementación azul/verde progresa a través de distintas etapas del ciclo de vida (una serie de eventos en la operación de implementación, como “una transferencia de tráfico posterior a la producción”), cada una con responsabilidades específicas y puntos de control de validación. Conocer estas etapas le ayuda a monitorear el progreso de la implementación y a solucionar los problemas de forma eficaz.

 Cada etapa del ciclo de vida puede durar hasta 24 horas. Recomendamos que el valor se mantenga por debajo de la marca de 24 horas. Esto se debe a que los procesos asíncronos necesitan tiempo para activar los enlaces. El sistema agota el tiempo de espera, no se realiza la implementación y, después, inicia una reversión cuando una etapa alcanza las 24 horas. Las implementaciones de CloudFormation tienen restricciones de tiempo de espera adicionales. Si bien el límite por etapas de 24 horas sigue vigente, CloudFormation impone un límite de 36 horas para toda la implementación. Si el proceso no se completa en 36 horas, CloudFormation marca un error en la implementación y, a continuación, se inicia una reversión.


| Etapas del ciclo de vida | Descripción | ¿Desea utilizar esta etapa para el enlace de ciclo de vida? | 
| --- | --- | --- | 
| RECONCILE\$1SERVICE | Esta etapa solo ocurre cuando se inicia una nueva implementación de servicio con más de una revisión de servicio en estado ACTIVO. | Sí | 
| PRE\$1SCALE\$1UP | La revisión de servicio verde no ha comenzado. La revisión de servicio azul gestiona el 100 % del tráfico de producción. No hay tráfico de prueba. | Sí | 
| SCALE\$1UP | El momento en que la revisión de servicio verde se escala verticalmente al 100 % e inicia nuevas tareas. La revisión de servicio verde no sirve ningún tráfico en este momento. | No | 
| POST\$1SCALE\$1UP | La revisión de servicio verde ha comenzado. La revisión de servicio azul gestiona el 100 % del tráfico de producción. No hay tráfico de prueba. | Sí | 
| TEST\$1TRAFFIC\$1SHIFT | Las revisiones de servicio azul y verde están en curso. La revisión de servicio azul gestiona el 100 % del tráfico de producción. La revisión de servicio verde está migrando del 0 % al 100 % del tráfico de prueba. | Sí | 
| POST\$1TEST\$1TRAFFIC\$1SHIFT | Se ha completado la transferencia de tráfico de prueba. La revisión de servicio verde gestiona el 100 % del tráfico de prueba. | Sí | 
| PRODUCTION\$1TRAFFIC\$1SHIFT | El tráfico de producción se está transfiriendo a la revisión de servicio verde. La revisión de servicio verde está migrando del 0 % al 100 % del tráfico de producción. | Sí | 
| POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | Se ha completado la transferencia de tráfico de producción. | Sí | 
| BAKE\$1TIME | El tiempo durante el cual las revisiones de servicio azul y verde se ejecutan simultáneamente. | No | 
| CLEAN\$1UP | La revisión de servicio azul se ha reducido verticalmente por completo a 0 tareas en curso. Tras esta etapa, la revisión de servicio verde es ahora la revisión de servicio de producción. | No | 

Cada etapa del ciclo de vida incluye puntos de control de validación integrados que deben superarse antes de pasar a la siguiente etapa. Si se produce un error en la validación, la implementación se puede revertir automáticamente para mantener la disponibilidad y la fiabilidad del servicio.

Cuando utiliza una función de Lambda, esta debe completar el trabajo o devolver IN\$1PROGRESS en un plazo de 15 minutos. Puede utilizar el `callBackDelaySeconds` para retrasar la llamada a Lambda. Para obtener más información, consulte la [función app.py](https://github.com/aws-samples/sample-amazon-ecs-blue-green-deployment-patterns/blob/main/ecs-bluegreen-lifecycle-hooks/src/approvalFunction/app.py#L20-L25) en sample-amazon-ecs-blue-green-deployment-patterns en GitHub.

# Recursos necesarios para las implementaciones azul/verde de Amazon ECS
<a name="blue-green-deployment-implementation"></a>

Para utilizar una implementación azul/verde con transferencia de tráfico administrada, su servicio debe utilizar una de las siguientes características:
+ Elastic Load Balancing
+ Service Connect

Los servicios que no utilizan Detección de servicios, Service Connect, VPC Lattice o Elastic Load Balancing también pueden utilizar implementaciones azul/verde, pero no obtienen ninguno de los beneficios de la transferencia de tráfico administrada.

En la siguiente lista se proporciona una descripción general de alto nivel de lo que se debe configurar para las implementaciones azul/verde de Amazon ECS:
+ Su servicio utiliza un equilibrador de carga de aplicación, un equilibrador de carga de red o Service Connect. Configure los recursos adecuados.
  + Equilibrador de carga de aplicación: para más información, consulte [Recursos de equilibrador de carga de aplicación para las implementaciones azul/verde, las implementaciones lineales y las implementaciones canario](alb-resources-for-blue-green.md).
  + Equilibrador de carga de red: para más información, consulte [Recursos de Equilibrador de carga de red para las implementaciones azul/verde, las implementaciones lineales y las implementaciones canario de Amazon ECS](nlb-resources-for-blue-green.md).
  + Service Connect: para más información, consulte [Recursos de Service Connect para las implementaciones azul/verde, las implementaciones lineales y las implementaciones canario de Amazon ECS](service-connect-blue-green.md).
+ Establezca el controlador de implementación del servicio en `ECS`.
+ Configure la estrategia de implementación como `blue/green` en su definición de servicio.
+ Opcionalmente, configure parámetros adicionales, como:
  + Tiempo de incorporación para la nueva implementación
  + Alarmas de CloudWatch para la reversión automática
  + Enlaces de ciclo de vida de la implementación para realizar pruebas (son funciones de Lambda que se ejecutan en etapas de implementación específicas)

## Prácticas recomendadas
<a name="blue-green-deployment-best-practices"></a>

Siga estas prácticas recomendadas para una implementación azul/verde de Amazon ECS exitosa:
+ Configure las comprobaciones de estado adecuadas que reflejen con precisión el estado de su aplicación.
+ Establezca un tiempo de incorporación que permita realizar pruebas suficientes de la implementación verde.
+ Implemente alarmas de CloudWatch para detectar automáticamente los problemas y activar las reversiones.
+ Utilice los enlaces de ciclo de vida para realizar pruebas automatizadas en cada etapa de la implementación.
+ Asegúrese de que la aplicación pueda gestionar revisiones de servicio azules y verdes que se pongan en marcha simultáneamente.
+ Planifique una capacidad de clúster suficiente para gestionar ambas revisiones de servicio durante la implementación.
+ Compruebe sus procedimientos de reversión antes de implementarlos en producción.

# Recursos de equilibrador de carga de aplicación para las implementaciones azul/verde, las implementaciones lineales y las implementaciones canario
<a name="alb-resources-for-blue-green"></a>

Para utilizar los equilibradores de carga de aplicación con las implementaciones azul/verde de Amazon ECS, debe configurar recursos específicos que permitan el enrutamiento del tráfico entre las revisiones de servicio azul y verde. 

## Grupos de destino
<a name="alb-target-groups"></a>

Para las implementaciones azul/verde con Elastic Load Balancing, debe crear dos grupos de destino:
+ Un grupo de destino principal para la revisión de servicio azul (tráfico de producción actual)
+ Un grupo de destino alternativo para la revisión de servicio verde (nueva versión)

Ambos grupos de destino deben configurarse con los siguientes ajustes:
+ Tipo de destino: `IP` (para Fargate o EC2 con modo de red `awsvpc`)
+ Protocolo: `HTTP` (o el protocolo que utilice su aplicación)
+ Puerto: el puerto en el que escucha su aplicación (normalmente `80` para HTTP)
+ VPC: la misma VPC que sus tareas de Amazon ECS
+ Configuración de comprobación de estado: configurada para comprobar correctamente el estado de la aplicación

Durante una implementación azul/verde, Amazon ECS registra automáticamente las tareas con el grupo de destino adecuado en función de la etapa de implementación.

**Example Creación de grupos de destino para un equilibrador de carga de aplicación**  
Los siguientes comandos de la CLI crean dos grupos de destino para usarlos con un equilibrador de carga de aplicación en una implementación azul/verde:  

```
aws elbv2 create-target-group \
    --name blue-target-group \
    --protocol HTTP \
    --port 80 \
    --vpc-id vpc-abcd1234 \
    --target-type ip \
    --health-check-path / \
    --health-check-protocol HTTP \
    --health-check-interval-seconds 30 \
    --health-check-timeout-seconds 5 \
    --healthy-threshold-count 2 \
    --unhealthy-threshold-count 2

aws elbv2 create-target-group \
    --name green-target-group \
    --protocol HTTP \
    --port 80 \
    --vpc-id vpc-abcd1234 \
    --target-type ip \
    --health-check-path / \
    --health-check-protocol HTTP \
    --health-check-interval-seconds 30 \
    --health-check-timeout-seconds 5 \
    --healthy-threshold-count 2 \
    --unhealthy-threshold-count 2
```

## Equilibrador de carga de aplicación
<a name="alb-load-balancer"></a>

Debe crear un equilibrador de carga de aplicación con la siguiente configuración:
+ Esquema: con acceso a Internet o interno, según sus necesidades
+ Tipo de dirección IP: IPv4
+ VPC: la misma VPC que sus tareas de Amazon ECS
+ Subredes: al menos dos subredes en diferentes zonas de disponibilidad
+ Grupos de seguridad: un grupo de seguridad que permita el tráfico en los puertos de oyentes

El grupo de seguridad adjunto al equilibrador de carga de aplicación debe tener una regla de salida que permita el tráfico al grupo de seguridad adjunto a las tareas de Amazon ECS.

**Example Creación de un Application Load Balancer**  
El siguiente comando de la CLI crea un equilibrador de carga de aplicación para su uso en una implementación azul/verde:  

```
aws elbv2 create-load-balancer \
    --name my-application-load-balancer \
    --type application \
    --security-groups sg-abcd1234 \
    --subnets subnet-12345678 subnet-87654321
```

## Oyentes y reglas
<a name="alb-listeners"></a>

En el caso de las implementaciones azul/verde, debe configurar los oyentes en su equilibrador de carga de aplicación:
+ Oyente de producción: gestiona el tráfico de producción (normalmente en los puertos 80 o 443)
  + Inicialmente remite el tráfico hacia el grupo de destino principal (revisión de servicio azul)
  + Tras la implementación, remite el tráfico al grupo de destino alternativo (revisión de servicio verde)
+ Oyente de prueba (opcional): gestiona el tráfico de prueba para validar la revisión de servicio verde antes de transferir el tráfico de producción
  + Se puede configurar en un puerto diferente (por ejemplo, 8080 o 8443)
  + Remite el tráfico al grupo de destino alternativo (revisión de servicio verde) durante la fase de prueba

Durante una implementación azul/verde, Amazon ECS actualiza automáticamente las reglas de oyente para que enruten el tráfico hacia el grupo de destino adecuado en función de la etapa de implementación.

**Example Creación de un oyente de producción**  
El siguiente comando de la CLI crea un oyente de producción en el puerto 80 que remite el tráfico al grupo de destino principal (azul):  

```
aws elbv2 create-listener \
    --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/app/my-application-load-balancer/abcdef123456 \
    --protocol HTTP \
    --port 80 \
    --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/blue-target-group/abcdef123456
```

**Example Creación de un oyente de prueba**  
El siguiente comando de la CLI crea un oyente de prueba en el puerto 8080 que remite el tráfico al grupo de destino alternativo (verde):  

```
aws elbv2 create-listener \
    --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/app/my-application-load-balancer/abcdef123456 \
    --protocol HTTP \
    --port 8080 \
    --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/ghijkl789012
```

**Example Creación de una regla de oyente para el enrutamiento basado en rutas**  
El siguiente comando de la CLI crea una regla que remite el tráfico de una ruta específica al grupo de destino verde para llevar a cabo pruebas:  

```
aws elbv2 create-rule \
    --listener-arn arn:aws:elasticloadbalancing:region:123456789012:listener/app/my-application-load-balancer/abcdef123456/ghijkl789012 \
    --priority 10 \
    --conditions Field=path-pattern,Values='/test/*' \
    --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/ghijkl789012
```

**Example Creación de una regla de oyente para el enrutamiento basado en encabezados**  
El siguiente comando de la CLI crea una regla que remite el tráfico con un encabezado específico al grupo de destino verde para llevar a cabo pruebas:  

```
aws elbv2 create-rule \
    --listener-arn arn:aws:elasticloadbalancing:region:123456789012:listener/app/my-application-load-balancer/abcdef123456/ghijkl789012 \
    --priority 20 \
    --conditions Field=http-header,HttpHeaderConfig='{Name=X-Environment,Values=[test]}' \
    --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/ghijkl789012
```

## Configuración del servicio
<a name="alb-service-configuration"></a>

Debe tener permisos para autorizar a Amazon ECS que en su nombre administre los recursos del equilibrador de carga en sus clústeres. Para obtener más información, consulte [Rol de IAM de infraestructura de Amazon ECS para los equilibradores de carga](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). 

Al crear o actualizar un servicio de Amazon ECS para las implementaciones azul/verde con Elastic Load Balancing, debe especificar la siguiente configuración.

Sustituya las *entradas del usuario* por sus valores.

Los componentes clave de esta configuración son:
+ `targetGroupArn`: el ARN del grupo de destino principal (revisión de servicio azul).
+ `alternateTargetGroupArn`: el ARN del grupo de destino alternativo (revisión de servicio verde).
+ `productionListenerRule`: el ARN de la regla de oyente para el tráfico de producción.
+ `roleArn`: el ARN del rol que permite que Amazon ECS administre los recursos de Elastic Load Balancing.
+ `strategy`: configúrelo en `BLUE_GREEN` para habilitar las implementaciones azul/verde.
+ `bakeTimeInMinutes`: el tiempo durante el cual las revisiones de servicio azul y verde se ejecutan simultáneamente después de que se haya transferido el tráfico de producción.
+ `TestListenerRule`: el ARN de la regla de oyente para el tráfico de prueba. Se trata de un parámetro opcional.

```
{
    "loadBalancers": [
        {
            "targetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/primary-target-group/abcdef123456",
            "containerName": "container-name",
            "containerPort": 80,
            "advancedConfiguration": {
                "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:region:account-id:targetgroup/alternate-target-group/ghijkl789012",
                "productionListenerRule": "arn:aws:elasticloadbalancing:region:account-id:listener-rule/app/load-balancer-name/abcdef123456/listener/ghijkl789012/rule/mnopqr345678",
                "roleArn": "arn:aws:iam::123456789012:role/ecs-elb-role"
            }
        }
    ],
    "deploymentConfiguration": {
        "strategy": "BLUE_GREEN",
        "maximumPercent": 200,
        "minimumHealthyPercent": 100,
        "bakeTimeInMinutes": 5
    }
}
```

## Flujo de tráfico durante la implementación
<a name="alb-traffic-flow"></a>

Durante una implementación azul/verde con Elastic Load Balancing, el tráfico fluye por el sistema de la siguiente manera:

1. *Estado inicial*: todo el tráfico de producción se enruta al grupo de destino principal (revisión de servicio azul).

1. *Implementación de la revisión de servicio verde*: Amazon ECS implementa las nuevas tareas y las registra en el grupo de destino alternativo.

1. *Tráfico de prueba*: si se configura un oyente, el tráfico de prueba se enruta al grupo de destino alternativo para validar la revisión de servicio verde.

1. *Transferencia de tráfico de producción*: Amazon ECS actualiza la regla de oyentes de producción para enrutar el tráfico al grupo de destino alternativo (revisión de servicio verde).

1. *Tiempo de incorporación*: el tiempo durante el cual las revisiones de servicio azul y verde se ejecutan simultáneamente después de que se haya transferido el tráfico de producción.

1. *Finalización*: tras una implementación correcta, se da por finalizada la revisión de servicio azul.

Si se detectan problemas durante la implementación, Amazon ECS puede revertirlos automáticamente enrutando nuevamente el tráfico al grupo de destino principal (revisión de servicio azul).

# Recursos de Equilibrador de carga de red para las implementaciones azul/verde, las implementaciones lineales y las implementaciones canario de Amazon ECS
<a name="nlb-resources-for-blue-green"></a>

Para usar un equilibrador de carga de red con las implementaciones azul/verde de Amazon ECS, debe configurar recursos específicos que permitan el enrutamiento del tráfico entre las revisiones de servicio azul y verde. En esta sección se explican los componentes necesarios y su configuración.

Cuando su configuración incluye un equilibrador de carga de red, Amazon ECS agrega un retraso de 10 minutos a las siguientes etapas del ciclo de vida:
+ TEST\$1TRAFFIC\$1SHIFT
+ PRODUCTION\$1TRAFFIC\$1SHIFT

Este retraso explica los problemas de tiempo de ejecución del equilibrador de carga de red que pueden provocar una discordancia entre las ponderaciones de tráfico configuradas y el enrutamiento de tráfico real en el plano de datos. 

## Grupos de destino
<a name="nlb-target-groups"></a>

Para las implementaciones azul/verde con un equilibrador de carga de red, debe crear dos grupos de destino:
+ Un grupo de destino principal para la revisión de servicio azul (tráfico de producción actual)
+ Un grupo de destino alternativo para la revisión de servicio verde (nueva revisión del servicio)

Ambos grupos de destino deben configurarse con los siguientes ajustes:
+ Tipo de destino: `ip` (para Fargate o EC2 con modo de red `awsvpc`)
+ Protocolo: `TCP` (o el protocolo que utilice su aplicación)
+ Puerto: el puerto en el que escucha su aplicación (normalmente `80` para HTTP)
+ VPC: la misma VPC que sus tareas de Amazon ECS
+ Configuración de comprobación de estado: configurada para comprobar correctamente el estado de la aplicación

  Para las comprobaciones de estado del TCP, el equilibrador de carga de red establece una conexión TCP con el destino. Si la conexión se realiza correctamente, se considera que el destino está en buen estado.

  Para las comprobaciones de estado de HTTP/HTTPS, el equilibrador de carga de red envía una solicitud HTTP/HTTPS al destino y verifica la respuesta.

Durante una implementación azul/verde, Amazon ECS registra automáticamente las tareas con el grupo de destino adecuado en función de la etapa de implementación.

**Example Creación de grupos de destino para el equilibrador de carga de red**  
Los siguientes comandos de la AWS CLI crean dos grupos de destino para usarlos con un equilibrador de carga de red en una implementación azul/verde:  

```
aws elbv2 create-target-group \
    --name blue-target-group \
    --protocol TCP \
    --port 80 \
    --vpc-id vpc-abcd1234 \
    --target-type ip \
    --health-check-protocol TCP

aws elbv2 create-target-group \
    --name green-target-group \
    --protocol TCP \
    --port 80 \
    --vpc-id vpc-abcd1234 \
    --target-type ip \
    --health-check-protocol TCP
```

## Equilibrador de carga de red
<a name="nlb-load-balancer"></a>

Debe crear un equilibrador de carga de red con la siguiente configuración:
+ Esquema: con acceso a Internet o interno, según sus necesidades
+ Tipo de dirección IP: IPv4
+ VPC: la misma VPC que sus tareas de Amazon ECS
+ Subredes: al menos dos subredes en diferentes zonas de disponibilidad

A diferencia de los equilibradores de carga de aplicaciones, los equilibradores de carga de red funcionan en la capa de transporte (capa 4) y no utilizan grupos de seguridad. En su lugar, debe asegurarse de que los grupos de seguridad asociados a sus tareas de Amazon ECS permitan el tráfico del equilibrador de carga de red en los puertos de oyente.

**Example Creación de un Network Load Balancer**  
El siguiente comando de la AWS CLI crea un equilibrador de carga de red para utilizarlo en una implementación azul/verde:  

```
aws elbv2 create-load-balancer \
    --name my-network-load-balancer \
    --type network \
    --subnets subnet-12345678 subnet-87654321
```

## Consideraciones acerca del uso de equilibradores de carga de red con las implementaciones azul/verde
<a name="nlb-considerations"></a>

Cuando use un equilibrador de carga de red para implementaciones azul/verde, tenga en cuenta lo siguiente:
+ **Funcionamiento de la capa 4**: los equilibradores de carga de red funcionan en la capa de transporte (capa 4) y no inspeccionan el contenido de la capa de aplicación (capa 7). Esto significa que no puede usar encabezados o rutas HTTP para tomar decisiones respecto al enrutamiento.
+ **Comprobaciones de estado**: las comprobaciones de estado de un equilibrador de carga de red se limitan a los protocolos TCP, HTTP o HTTPS. Para las comprobaciones de estado de TCP, el equilibrador de carga de red solo verifica que se pueda establecer la conexión.
+ **Conservación de la conexión**: los equilibradores de carga de red conservan la dirección IP de origen del cliente, lo que puede resultar útil por motivos de seguridad y registro.
+ **Direcciones IP estáticas**: los equilibradores de carga de red proporcionan direcciones IP estáticas para cada subred, lo que puede resultar útil para su inclusión en listas blancas o cuando los clientes necesitan conectarse a una dirección IP fija.
+ **Tráfico de prueba**: dado que los equilibradores de carga de red no admiten el enrutamiento basado en el contenido, el tráfico de prueba debe enviarse a un puerto diferente al del tráfico de producción.

## Oyentes y reglas
<a name="nlb-listeners"></a>

Para las implementaciones azul/verde con un equilibrador de carga de red, debe configurar oyentes:
+ Oyente de producción: gestiona el tráfico de producción (normalmente en los puertos 80 o 443)
  + Inicialmente remite el tráfico hacia el grupo de destino principal (revisión de servicio azul)
  + Tras la implementación, remite el tráfico al grupo de destino alternativo (revisión de servicio verde)
+ Oyente de prueba (opcional): gestiona el tráfico de prueba para validar la revisión de servicio verde antes de transferir el tráfico de producción
  + Se puede configurar en un puerto diferente (por ejemplo, 8080 o 8443)
  + Remite el tráfico al grupo de destino alternativo (revisión de servicio verde) durante la fase de prueba

A diferencia de los equilibradores de carga de aplicación, los equilibradores de carga de red no admiten reglas de enrutamiento basadas en el contenido. En su lugar, el tráfico se enruta en función del puerto y el protocolo del oyente.

Los siguientes comandos de la AWS CLI crean oyentes de producción y de prueba para un equilibrador de carga de red:

Sustituya las *entradas del usuario* por sus valores.

```
aws elbv2 create-listener \
    --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/net/my-network-lb/1234567890123456 \
    --protocol TCP \
    --port 80 \
    --default-actions Type=forward, TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/blue-target-group/1234567890123456

aws elbv2 create-listener \
    --load-balancer-arn arn:aws:elasticloadbalancing:region:123456789012:loadbalancer/net/my-network-lb/1234567890123456 \
    --protocol TCP \
    --port 8080 \
    --default-actions Type=forward, TargetGroupArn=arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/1234567890123456
```

## Configuración del servicio
<a name="nlb-service-configuration"></a>

Debe tener permisos para autorizar a Amazon ECS que en su nombre administre los recursos del equilibrador de carga en sus clústeres. Para obtener más información, consulte [Rol de IAM de infraestructura de Amazon ECS para los equilibradores de carga](AmazonECSInfrastructureRolePolicyForLoadBalancers.md). 

Al crear o actualizar un servicio de Amazon ECS para implementaciones azul/verde con un equilibrador de carga de red, debe especificar la siguiente configuración:

Sustituya las *entradas del usuario* por sus valores.

Los componentes clave de esta configuración son:
+ `targetGroupArn`: el ARN del grupo de destino principal (revisión de servicio azul)
+ `alternateTargetGroupArn`: el ARN del grupo de destino alternativo (revisión de servicio verde)
+ `productionListenerRule`: el ARN del oyente para el tráfico de producción
+ `testListenerRule`: (opcional) el ARN del oyente para el tráfico de prueba
+ `roleArn`: el ARN del rol que permite que Amazon ECS administre los recursos del equilibrador de carga de red
+ `strategy`: se configura en `BLUE_GREEN` para habilitar las implementaciones azul/verde
+ `bakeTimeInMinutes`: el tiempo durante el cual las revisiones de servicio azul y verde se ejecutan simultáneamente después de que se haya transferido el tráfico de producción

```
{
    "loadBalancers": [
        {
            "targetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/blue-target-group/1234567890123456",
            "containerName": "container-name",
            "containerPort": 80,
            "advancedConfiguration": {
                "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:region:123456789012:targetgroup/green-target-group/1234567890123456",
                "productionListenerRule": "arn:aws:elasticloadbalancing:region:123456789012:listener/net/my-network-lb/1234567890123456/1234567890123456",
                "testListenerRule": "arn:aws:elasticloadbalancing:region:123456789012:listener/net/my-network-lb/1234567890123456/2345678901234567",
                "roleArn": "arn:aws:iam::123456789012:role/ecs-nlb-role"
            }
        }
    ],
    "deploymentConfiguration": {
        "strategy": "BLUE_GREEN",
        "maximumPercent": 200,
        "minimumHealthyPercent": 100,
        "bakeTimeInMinutes": 5
    }
}
```

## Flujo de tráfico durante la implementación
<a name="nlb-traffic-flow"></a>

Durante una implementación azul/verde con un equilibrador de carga de red, el tráfico fluye por el sistema de la siguiente manera:

1. *Estado inicial*: todo el tráfico de producción se enruta al grupo de destino principal (revisión de servicio azul).

1. *Implementación de la revisión de servicio verde*: Amazon ECS implementa las nuevas tareas y las registra en el grupo de destino alternativo.

1. *Tráfico de prueba*: si se configura un oyente, el tráfico de prueba se enruta al grupo de destino alternativo para validar la revisión de servicio verde.

1. *Transferencia de tráfico de producción*: Amazon ECS actualiza el oyente de producción para enrutar el tráfico al grupo de destino alternativo (revisión de servicio verde).

1. *Tiempo de incorporación*: el tiempo durante el cual las revisiones de servicio azul y verde se ejecutan simultáneamente después de que se haya transferido el tráfico de producción.

1. *Finalización*: tras una implementación correcta, se da por finalizada la revisión de servicio azul.

Si se detectan problemas durante la implementación, Amazon ECS puede revertirlos automáticamente enrutando nuevamente el tráfico al grupo de destino principal (revisión de servicio azul).

# Recursos de Service Connect para las implementaciones azul/verde, las implementaciones lineales y las implementaciones canario de Amazon ECS
<a name="service-connect-blue-green"></a>

Al utilizar Service Connect con implementaciones azul/verde, debe configurar componentes específicos para habilitar el enrutamiento de tráfico adecuado entre las revisiones de servicio azul y verde. En esta sección se explican los componentes necesarios y su configuración.

## Información general de la arquitectura
<a name="service-connect-blue-green-architecture"></a>

Service Connect crea capacidades tanto de detección de servicios como de malla de servicios a través de un proxy sidecar administrado que se incorpora automáticamente a las tareas de Amazon ECS. Estos proxies gestionan las decisiones de enrutamiento, los reintentos y la recopilación de métricas, a la vez que AWS Cloud Map proporciona el backend del registro de servicios. Al implementar un servicio con Service Connect habilitado, el servicio se registra en AWS Cloud Map y los servicios de cliente lo detectan a través del espacio de nombres.

En una implementación estándar de Service Connect, los servicios de cliente se conectan a nombres de servicios lógicos y el proxy sidecar gestiona el enrutamiento a las instancias de servicio reales. Con las implementaciones azul/verde, este modelo se amplía para incluir el enrutamiento del tráfico de prueba a través de la configuración de `testTrafficRules`.

Durante una implementación azul/verde, los siguientes componentes clave trabajan juntos:
+ **Proxy de Service Connect**: todo el tráfico entre los servicios pasa a través del proxy de Service Connect, que toma las decisiones de enrutamiento en función de la configuración.
+ **Registro de AWS Cloud Map**: las implementaciones azul y verde se registran con AWS Cloud Map, pero la implementación verde se registra inicialmente como un punto de conexión de “prueba”.
+ **Enrutamiento de tráfico de prueba**: las `testTrafficRules` en la configuración de Service Connect determinan cómo identificar y enrutar el tráfico de prueba a la implementación verde. Esto se logra mediante el **enrutamiento basado en encabezados**, donde los encabezados HTTP específicos de las solicitudes dirigen el tráfico a la revisión de prueba. De forma predeterminada, Service Connect reconoce el encabezado `x-amzn-ecs-blue-green-test` de los protocolos basados en HTTP cuando no se especifican reglas personalizadas.
+ **Configuración del cliente**: todos los clientes del espacio de nombres reciben automáticamente las rutas de producción y de prueba, pero solo las solicitudes que coincidan con las reglas de prueba se destinarán a la implementación verde.

Lo que hace que este método sea eficaz es que gestiona la complejidad de la detección de servicios durante las transiciones. A medida que el tráfico pasa de la implementación azul a la verde, todos los mecanismos de conectividad y detección se actualizan automáticamente. No es necesario actualizar los registros de DNS, reconfigurar los equilibradores de carga ni implementar los cambios de detección de servicios por separado, ya que la malla de servicios se encarga de todo.

## Enrutamiento y comprobación del tráfico
<a name="service-connect-blue-green-traffic-routing"></a>

Service Connect proporciona capacidades avanzadas de enrutamiento de tráfico para implementaciones azul/verde, incluido el enrutamiento basado en encabezados y la configuración de alias de cliente para escenarios de prueba.

### Reglas de encabezado de tráfico de prueba
<a name="service-connect-test-traffic-header-rules"></a>

Durante las implementaciones azul/verde, puede configurar las reglas de los encabezados de tráfico de prueba para enrutar solicitudes específicas a la (nueva) revisión de servicio verde con fines de prueba. Esto le permite validar la nueva versión con tráfico controlado antes de completar la implementación.

Service Connect utiliza el **enrutamiento basado en encabezados** para identificar el tráfico de prueba. De forma predeterminada, Service Connect reconoce el encabezado `x-amzn-ecs-blue-green-test` de los protocolos basados en HTTP cuando no se especifican reglas personalizadas. Cuando este encabezado está presente en una solicitud, el proxy de Service Connect enruta automáticamente la solicitud a la implementación verde para su prueba.

Las reglas de los encabezados de tráfico de prueba le permiten hacer lo siguiente:
+ Enrutar solicitudes con encabezados específicos a la revisión de servicio verde
+ Comprobar la nueva funcionalidad con un subconjunto de tráfico
+ Validar el comportamiento del servicio antes de la transición total del tráfico
+ Implementar estrategias de pruebas canarias
+ Realizar pruebas de integración en un entorno similar al de producción

El mecanismo de enrutamiento basado en encabezados funciona a la perfección con la arquitectura de aplicaciones existente. Los servicios de cliente no necesitan conocer el proceso de implementación azul/verde, simplemente incluyen los encabezados apropiados al enviar las solicitudes de prueba y el proxy de Service Connect gestiona la lógica de enrutamiento automáticamente.

Para más información acerca de cómo configurar reglas de encabezado de tráfico de prueba, consulte [ServiceConnectTestTrafficHeaderRules](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectTestTrafficHeaderRules.html) en la *Referencia de la API de Amazon Elastic Container Service*.

### Reglas de coincidencia de encabezados
<a name="service-connect-header-match-rules"></a>

Las reglas de coincidencia de encabezados definen los criterios para enrutar el tráfico de prueba durante las implementaciones azul/verde. Puede configurar varias condiciones de coincidencia para controlar con precisión qué solicitudes se enrutan a la revisión de servicio verde.

La coincidencia de encabezados admite lo siguiente:
+ Coincidencias exactas con el valor del encabezado
+ Comprobación de la presencia de encabezados
+ Coincidencias basadas en patrones
+ Múltiples combinaciones de encabezados

Los ejemplos de casos de uso incluyen el enrutamiento de solicitudes con cadenas de agentes de usuario específicas, versiones de API o indicadores de características al servicio verde para llevar a cabo pruebas.

Para más información sobre la configuración de coincidencias de encabezados, consulte [ServiceConnectTestTrafficHeaderMatchRules](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectTestTrafficHeaderMatchRules.html) en la *Referencia de la API de Amazon Elastic Container Service*.

### Alias de cliente para implementaciones azul/verde
<a name="service-connect-client-alias-blue-green"></a>

Los alias de cliente proporcionan puntos de conexión de DNS estables para los servicios durante las implementaciones azul/verde. Permiten enrutar el tráfico sin problemas entre las revisiones de servicio azul y verde sin necesidad de que las aplicaciones de cliente cambien sus puntos de conexión.

Durante una implementación azul/verde, los alias de cliente:
+ Mantienen nombres de DNS coherentes para las conexiones de cliente
+ Habilitan la transferencia automática del tráfico entre las revisiones de servicio
+ Respaldan estrategias de migración gradual del tráfico
+ Proporcionan capacidades de reversión al redireccionar el tráfico a la revisión azul

Puede configurar varios alias de cliente para distintos puertos o protocolos, lo que permite que las arquitecturas de servicios complejas mantengan la conectividad durante las implementaciones.

Para más información acerca de la configuración de alias de cliente, consulte [ServiceConnectClientAlias](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectClientAlias.html) en la *Referencia de la API de Amazon Elastic Container Service*.

### Prácticas recomendadas para el enrutamiento de tráfico
<a name="service-connect-blue-green-best-practices"></a>

Al implementar el enrutamiento de tráfico para las implementaciones azul/verde con Service Connect, tenga en cuenta las siguientes prácticas recomendadas:
+ **Comience con las pruebas basadas en encabezados**: utilice las reglas de encabezado de tráfico de prueba para validar el servicio verde con tráfico controlado antes de transferir todo el tráfico.
+ **Configure las comprobaciones de estado**: asegúrese de que los servicios azul y verde tengan configuradas las comprobaciones de estado adecuadas para evitar que el tráfico se enrute a instancias en mal estado.
+ **Monitoree las métricas del servicio**: realice un seguimiento de los indicadores clave de rendimiento de ambas revisiones de servicio durante la implementación para identificar los problemas de forma temprana.
+ **Planifique una estrategia de reversión**: configure los alias de los clientes y las reglas de enrutamiento para permitir una reversión rápida al servicio azul en caso de que se detecten problemas.
+ **Compruebe la lógica de coincidencia de encabezados**: valide las reglas de coincidencia de encabezados en un entorno que no sea de producción antes de aplicarlas a las implementaciones de producción.

## Flujo de trabajo de las implementaciones azul/verde de Service Connect
<a name="service-connect-blue-green-workflow"></a>

Comprender cómo Service Connect administra el proceso de implementación azul/verde le ayuda a implementar y solucionar los problemas de las implementaciones de forma eficaz. El siguiente flujo de trabajo muestra cómo interactúan los distintos componentes durante cada fase de la implementación.

### Fases de la implementación
<a name="service-connect-deployment-phases"></a>

La implementación azul/verde de Service Connect pasa por varias fases distintas:

1. **Estado inicial**: el servicio azul gestiona el 100 % del tráfico de producción. Todos los servicios de cliente del espacio de nombres se conectan al servicio azul mediante el nombre lógico del servicio configurado en Service Connect.

1. **Registro de servicio verde**: cuando se inicia la implementación verde, se registra con AWS Cloud Map como punto de conexión de “prueba”. El proxy de Service Connect en los servicios de cliente recibe automáticamente las configuraciones de ruta de producción y prueba.

1. **Enrutamiento de tráfico de prueba**: el proxy de Service Connect enruta automáticamente las solicitudes que contienen los encabezados de tráfico de prueba (por ejemplo, `x-amzn-ecs-blue-green-test`) al servicio verde. El tráfico de producción sigue fluyendo hacia el servicio azul.

1. **Preparación para la transferencia de tráfico**: tras realizar satisfactoriamente las pruebas, el proceso de implementación se prepara para la transferencia de tráfico de producción. Tanto los servicios azules como los verdes permanecen registrados y en buen estado.

1. **Transferencia de tráfico de producción**: la configuración de Service Connect se actualiza para enrutar el tráfico de producción al servicio verde. Esto ocurre automáticamente sin necesidad de actualizar el servicio del cliente ni cambiar el DNS.

1. **Tiempo de incorporación**: el tiempo durante el cual las revisiones de servicio azul y verde se ejecutan simultáneamente después de que se haya transferido el tráfico de producción.

1. **Cancelación del registro de servicio azul**: tras la validación y la transferencia de tráfico correctos, se anula el registro de servicio azul de AWS Cloud Map y se cancela, completándose así la implementación.

### Comportamiento del proxy de Service Connect
<a name="service-connect-proxy-behavior"></a>

El proxy de Service Connect desempeña un papel crucial en la administración del tráfico durante las implementaciones azul/verde. Comprender su comportamiento le ayuda a diseñar estrategias de implementación y comprobación eficaces.

Comportamientos de proxy clave durante las implementaciones azul/verde:
+ **Detección automática de rutas**: el proxy detecta automáticamente las rutas de producción y de prueba de AWS Cloud Map sin necesidad de reiniciar la aplicación ni cambiar la configuración.
+ **Enrutamiento basado en encabezados**: el proxy examina los encabezados de las solicitudes entrantes y enruta el tráfico a la revisión de servicio correspondiente en función de las reglas de tráfico de prueba configuradas.
+ **Integración de comprobaciones de estado**: el proxy solo enruta el tráfico a las instancias de servicio en buen estado y excluye automáticamente las tareas en mal estado del grupo de enrutamiento.
+ **Reintento y desconexión de circuitos**: el proxy ofrece funciones integradas de lógica de reintento y desconexión de circuitos, lo que mejora la resiliencia durante las implementaciones.
+ **Recopilación de métricas**: el proxy recopila métricas detalladas de los servicios azules y verdes, lo que permite un monitoreo exhaustivo durante las implementaciones.

### Actualizaciones de la detección de servicios
<a name="service-connect-service-discovery-updates"></a>

Una de las principales ventajas de usar Service Connect para las implementaciones azul/verde es la gestión automática de las actualizaciones de detección de servicios. Las implementaciones azul/verde tradicionales suelen requerir actualizaciones de DNS complejas o una reconfiguración del equilibrador de carga, pero Service Connect administra estos cambios de forma transparente.

Durante una implementación, Service Connect gestiona:
+ **Actualizaciones del espacio de nombres**: el espacio de nombres de Service Connect incluye automáticamente los puntos de conexión de servicio azules y verdes, con las reglas de enrutamiento adecuadas.
+ **Configuración del cliente**: todos los servicios de cliente del espacio de nombres reciben automáticamente la información de enrutamiento actualizada sin necesidad de reiniciarlos ni volver a distribuirlos.
+ **Transición gradual**: las actualizaciones de detección de servicios se realizan de forma gradual y segura, lo que garantiza que no se interrumpan las solicitudes en curso.
+ **Compatibilidad con las reversiones**: si es necesario llevar a cabo una reversión, Service Connect puede revertir rápidamente las configuraciones de detección de servicios para enrutar el tráfico hacia el servicio azul.

# Creación de una implementación azul/verde de Amazon ECS
<a name="deploy-blue-green-service"></a>

 Con las implementaciones azul/verde de Amazon ECS, puede realizar y comprobar cambios en el servicio antes de implementarlos en un entorno de producción. 

## Requisitos previos
<a name="deploy-blue-green-service-prerequisites"></a>

Realice las siguientes operaciones antes de iniciar una implementación azul/verde. 

1. Configure los permisos adecuados.
   + Para obtener información sobre los permisos de Elastic Load Balancing, consulte [Rol de IAM de infraestructura de Amazon ECS para los equilibradores de carga](AmazonECSInfrastructureRolePolicyForLoadBalancers.md).
   + Para obtener información acerca de los permisos de Lambda, consulte [Permisos necesarios para las funciones de Lambda en las implementaciones azul/verde de Amazon ECS](blue-green-permissions.md)

1. Las implementaciones azul/verde de Amazon ECS requieren que su servicio utilice una de las siguientes características: configure los recursos adecuados.
   + Equilibrador de carga de aplicación: para más información, consulte [Recursos de equilibrador de carga de aplicación para las implementaciones azul/verde, las implementaciones lineales y las implementaciones canario](alb-resources-for-blue-green.md).
   + Equilibrador de carga de red: para más información, consulte [Recursos de Equilibrador de carga de red para las implementaciones azul/verde, las implementaciones lineales y las implementaciones canario de Amazon ECS](nlb-resources-for-blue-green.md).
   + Service Connect: para más información, consulte [Recursos de Service Connect para las implementaciones azul/verde, las implementaciones lineales y las implementaciones canario de Amazon ECS](service-connect-blue-green.md).

1. Decida si quiere ejecutar las funciones de Lambda para las etapas del ciclo de vida.
   + PRE\$1SCALE\$1UP
   + POST\$1SCALE\$1UP
   + TEST\$1TRAFFIC\$1SHIFT
   + POST\$1TEST\$1TRAFFIC\$1SHIFT
   + PRODUCTION\$1TRAFFIC\$1SHIFT
   + POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT

   Para más información, consulte [Cree una función de Lambda con la consola](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#getting-started-create-function) en la *Guía para desarrolladores de AWS Lambda*.

## Procedimiento
<a name="deploy-blue-green-service-procedure"></a>

Puede utilizar la consola o la AWS CLI para crear un servicio azul/verde de Amazon ECS.

------
#### [ Console ]

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

1. Determine el recurso desde el que lanza el servicio.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/deploy-blue-green-service.html)

   Aparecerá la página **Crear servicio**.

1. En **Detalles del servicio**, haga lo siguiente:

   1. En **Familia de definiciones de tareas**, elija la definición de tarea que se va a utilizar. A continuación, en **Revisión de la definición de tareas**, introduzca la revisión que desee utilizar.

   1. En **Service name** (Nombre del servicio), ingrese un nombre para el servicio.

1. Para ejecutar el servicio en un clúster existente, en **Clúster existente**, elija el clúster. Para ejecutar el servicio en un clúster nuevo, seleccione **Crear clúster** 

1. Elija cómo distribuir las tareas en la infraestructura de clúster. En **Configuración de computación**, elija su opción.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/deploy-blue-green-service.html)

1. En **Configuración de implementación**, haga lo siguiente:

   1. En **Tipo de servicio**, seleccione **Réplica**.

   1. En **Desired tasks** (Tareas deseadas), ingrese el número de tareas que se lanzarán y mantendrán en el servicio.

   1. Para que Amazon ECS monitoree la distribución de las tareas entre las zonas de disponibilidad y las redistribuya cuando haya un desequilibrio, en **Reequilibrio del servicio de zonas de disponibilidad**, seleccione **Reequilibrio del servicio de zonas de disponibilidad**.

   1. En **Periodo de gracia de la comprobación de estado**, introduzca la cantidad de tiempo (en segundos) durante la cual el programador de servicios ignora las comprobaciones de estado de Elastic Load Balancing, VPC Lattice y contenedores en mal estado después de que se haya iniciado una tarea por primera vez. Si no se especifica ningún valor para el período de gracia de comprobación de estado, se utiliza el valor predeterminado: 0.

1. 

   1. En **Tiempo de incorporación**, introduzca el número de minutos que las revisiones de servicio azul y verde durarán simultáneamente antes de que finalice la revisión azul. Esto permite disponer de tiempo para la verificación y la comprobación.

   1. (Opcional) Ejecute las funciones de Lambda que se van a ejecutar en etapas específicas de la implementación. En **Enlaces de ciclo de vida de la implementación**, seleccione las etapas para ejecutar los enlaces de ciclo de vida.

      Para agregar un enlace de ciclo de vida:

      1. Elija **Agregar**.

      1. En **Función de Lambda**, introduzca el nombre o el ARN de la función.

      1. En **Rol**, selecione el rol de IAM que tiene permiso para invocar la función de Lambda.

      1. En **Etapas del ciclo de vida**, seleccione las etapas en las que debe ejecutarse la función de Lambda.

1. Para configurar el modo en que Amazon ECS detecta y gestiona los errores de implementación, expanda **Deployment failure detection** (Detección de errores de implementación) y, a continuación, elija sus opciones. 

   1. Para detener una implementación cuando las tareas no puedan iniciarse, seleccione **Use the Amazon ECS deployment circuit breaker** (Utilizar el interruptor de circuito de implementación de Amazon ECS).

      Para que el software restaure automáticamente la implementación a su último estado completado cuando el disyuntor de implementación establezca un estado con error, seleccione **Restauración en caso de error**.

   1. Para detener una implementación en función de las métricas de la aplicación, seleccione **Use CloudWatch alarms**. A continuación, elija las alarmas en **Nombre de la alarma de CloudWatch**. Para crear una alarma nueva, vaya a la consola de CloudWatch.

      Para que el software restaure automáticamente la implementación a su último estado de implementación completada cuando una alarma de CloudWatch establezca un estado con error, seleccione **Restauración en caso de error**.

1. (Opcional) Para interconectar su servicio con Service Connect, expanda **Service Connect** y, a continuación, especifique lo siguiente:

   1.  Seleccione **Activar Service Connect**.

   1. En **Service Connect configuration** (Configuración de Service Connect), especifique el modo cliente.
      + Si su servicio ejecuta una aplicación cliente de red que solo necesita conectarse a otros servicios del espacio de nombres, elija **Solo en el lado del cliente**.
      + Si su servicio ejecuta una aplicación de servicio web o red y necesita proporcionar puntos de conexión para este servicio y se conecta a otros servicios del espacio de nombres, elija **Client and server** (Cliente y servidor).

   1. Para usar un espacio de nombres que no sea el espacio de nombres predeterminado del clúster, en **Namespace** (Espacio de nombres), elija el espacio de nombres del servicio. Puede ser un espacio de nombres creado por separado en la misma Región de AWS de su Cuenta de AWS o un espacio de nombres en la misma región que se comparta con su cuenta mediante AWS Resource Access Manager (AWS RAM). Para obtener más información sobre los espacios de nombres de AWS Cloud Map compartidos, consulte [Cross-account AWS Cloud Map namespace sharing](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) en la *Guía para desarrolladores de AWS Cloud Map*.

   1. (Opcional) Configure las reglas de encabezado de tráfico de prueba para las implementaciones azul/verde. En **Enrutamiento de tráfico de prueba**, especifique lo siguiente:

      1. Seleccione **Habilitar las reglas de encabezado de tráfico de prueba** para enrutar solicitudes específicas a la revisión de servicio verde durante las pruebas.

      1. En **Reglas de coincidencia de encabezados**, configure los criterios para enrutar el tráfico de prueba:
         + **Nombre del encabezado**: introduzca el nombre del encabezado HTTP que desee que coincida (por ejemplo, `X-Test-Version` o `User-Agent`).
         + **Tipo de coincidencia**: elija los criterios de coincidencia:
           + **Coincidencia exacta**: se enrutan las solicitudes en las que el valor del encabezado coincida exactamente con el valor especificado.
           + **Encabezado presente**: se enrutan las solicitudes que contienen el encabezado especificado, independientemente del valor.
           + **Coincidencia de patrones**: se enrutan las solicitudes en las que el valor del encabezado coincide con un patrón especificado.
         + **Valor del encabezado** (si se utiliza una coincidencia exacta o una coincidencia de patrón): introduzca el valor o patrón con el que desea que haya coincidencia.

         Puede agregar varias reglas de coincidencia de encabezados para crear una lógica de enrutamiento compleja. Las solicitudes que coincidan con alguna de las reglas configuradas se enrutarán a la revisión de servicio verde para su comprobación.

      1. Elija **Agregar regla de encabezado** para configurar condiciones de coincidencia de encabezados adicionales.
**nota**  
Las reglas de encabezado de tráfico de prueba le permiten validar la nueva funcionalidad con tráfico controlado antes de finalizar la implementación completa. Esto le permite comprobar la revisión de servicio verde con solicitudes específicas (como las de las herramientas de pruebas internas o de los usuarios de la versión beta) y, al mismo tiempo, mantener un flujo de tráfico normal hacia la revisión de servicio azul.

   1. (Opcional) Especifique una configuración de registro. Seleccione **Utilizar colección de registros**. La opción predeterminada envía registros de contenedor a los Registros de CloudWatch. Las demás opciones del controlador de registro se configuran mediante AWS FireLens. Para obtener más información, consulte [Envío de registros de Amazon ECS a un servicio de AWS o AWS Partner](using_firelens.md).

      A continuación, se describe con más detalle cada uno de los destinos de registro de contenedor.
      + **Amazon CloudWatch**: configure la tarea para enviar registros de contenedor a CloudWatch Logs. Se proporcionan las opciones de controlador de registro predeterminadas que crean un grupo de registros de CloudWatch en su nombre. Para especificar otro nombre de grupo de registros, cambie los valores de las opciones del controlador.
      + **Amazon Data Firehose**: configure la tarea para enviar registros de contenedor a Firehose. Se proporcionan las opciones de controlador de registro predeterminadas que envían registros a un flujo de entrega de Firehose. Para especificar un nombre de flujo de entrega distinto, cambie los valores de las opciones del controlador.
      + **Amazon Kinesis Data Streams**: configure la tarea para enviar registros de contenedores a Kinesis Data Streams. Se proporcionan las opciones de controlador de registro predeterminadas que envían registros a un flujo de Kinesis Data Streams. Para especificar otro nombre de transmisión, cambie los valores de las opciones del controlador.
      + **Amazon OpenSearch Service**: configure la tarea para enviar registros de contenedor a un dominio de OpenSearch Service. Se deben proporcionar las opciones del controlador de registros. 
      + **Amazon S3**: configure la tarea para enviar registros de contenedor a un bucket de Amazon S3. Se proporcionan las opciones de controlador de registro predeterminadas, pero debe especificar un nombre de bucket de Amazon S3 válido.

1. (Opcional) Configure el **equilibrio de carga** para una implementación azul/verde.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/deploy-blue-green-service.html)

1. (Opcional) Para ayudar a identificar el servicio y las tareas, expanda la sección **Tags** (Etiquetas) y, a continuación, configure sus etiquetas.

   Para que Amazon ECS etiquete automáticamente todas las tareas recién lanzadas con el nombre del clúster y las etiquetas de definición de tareas, seleccione **Activar las etiquetas administradas de Amazon ECS** y, a continuación, en **Propagar etiquetas de**, seleccione **Definiciones de tareas**.

   Para que Amazon ECS etiquete automáticamente todas las tareas recién lanzadas con el nombre del clúster y las etiquetas de servicio, seleccione **Activar las etiquetas administradas de Amazon ECS** y, a continuación, en **Propagar etiquetas de**, seleccione **Servicio**.

   Añada o elimine una etiqueta.
   + [Agregar una etiqueta] Seleccione **Add tag** (Agregar etiqueta), y, a continuación, haga lo siguiente:
     + En **Clave**, escriba el nombre de la clave.
     + En **Valor**, escriba el valor de la clave.
   + [Eliminar una etiqueta] Junto a la etiqueta, elija **Remove tag (Quitar etiqueta)**.

1. Seleccione **Crear**.

------
#### [ AWS CLI ]

1. Cree un archivo llamado `service-definition.json` con el siguiente contenido.

   Sustituya las *entradas del usuario* por sus valores.

   ```
   {
     "serviceName": "myBlueGreenService",
     "cluster": "arn:aws:ecs:us-west-2:123456789012:cluster/sample-fargate-cluster",
     "taskDefinition": "sample-fargate:1",
     "desiredCount": 5,
     "launchType": "FARGATE",
     "networkConfiguration": {
       "awsvpcConfiguration": {
         "subnets": [
           "subnet-09ce6e74c116a2299",
           "subnet-00bb3bd7a73526788",
           "subnet-0048a611aaec65477"
         ],
         "securityGroups": [
           "sg-09d45005497daa123"
         ],
         "assignPublicIp": "ENABLED"
       }
     },
     "deploymentController": {
       "type": "ECS"
     },
     "deploymentConfiguration": {
       "strategy": "BLUE_GREEN",
       "maximumPercent": 200,
       "minimumHealthyPercent": 100,
       "bakeTimeInMinutes": 2,
       "alarms": {
         "alarmNames": [
           "myAlarm"
         ],
         "rollback": true,
         "enable": true
       },
       "lifecycleHooks": [
         {
           "hookTargetArn": "arn:aws:lambda:us-west-2:7123456789012:function:checkExample",
           "roleArn": "arn:aws:iam::123456789012:role/ECSLifecycleHookInvoke",
           "lifecycleStages": [
             "PRE_SCALE_UP"
           ]
         }
       ]
     },
     "loadBalancers": [
       {
         "targetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-target-group/54402ff563af1197",
         "containerName": "fargate-app",
         "containerPort": 80,
         "advancedConfiguration": {
           "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-target-group/cad10a56f5843199",
           "productionListenerRule": "arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-blue-green-demo/32e0e4f946c3c05b/9cfa8c482e204f7d/831dbaf72edb911",
           "roleArn": "arn:aws:iam::123456789012:role/LoadBalancerManagementforECS"
         }
       }
     ]
   }
   ```

1. Ejecuta `create-service`.

   Sustituya las *entradas del usuario* por sus valores.

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

   Como alternativa, puede usar el siguiente ejemplo, que crea un servicio de implementación azul/verde con una configuración de equilibrador de carga:

   ```
   aws ecs create-service \
      --cluster "arn:aws:ecs:us-west-2:123456789012:cluster/MyCluster" \
      --service-name "blue-green-example-service" \
      --task-definition "nginxServer:1" \
      --launch-type "FARGATE" \
      --network-configuration "awsvpcConfiguration={subnets=[subnet-12345,subnet-67890,subnet-abcdef,subnet-fedcba],securityGroups=[sg-12345],assignPublicIp=ENABLED}" \
      --desired-count 3 \
      --deployment-controller "type=ECS" \
      --deployment-configuration "strategy=BLUE_GREEN,maximumPercent=200,minimumHealthyPercent=100,bakeTimeInMinutes=0" \
      --load-balancers "targetGroupArn=arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/MyBGtg1/abcdef1234567890,containerName=nginx,containerPort=80,advancedConfiguration={alternateTargetGroupArn=arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/MyBGtg2/0987654321fedcba,productionListenerRule=arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/MyLB/1234567890abcdef/1234567890abcdef,roleArn=arn:aws:iam::123456789012:role/ELBManagementRole}"
   ```

------

## Siguientes pasos
<a name="deploy-blue-green-service-next-steps"></a>
+ Actualice el servicio para iniciar la implementación. Para obtener más información, consulte [Actualización de un servicio de Amazon ECS](update-service-console-v2.md).
+ Monitoree el proceso de implementación para asegurarse de que sigue el patrón azul/verde:
  + Se crea y escala verticalmente la revisión de servicio verde
  + El tráfico de prueba se enruta a la revisión verde (si está configurada)
  + El tráfico de producción se transfiere a la revisión verde
  + Transcurrido el tiempo de incorporación, la revisión azul finaliza

# Solución de problemas de las implementaciones azul/verde de Amazon ECS
<a name="troubleshooting-blue-green"></a>

Las siguientes son las soluciones para los problemas más comunes que puede encontrar al utilizar las implementaciones azul/verde con Amazon ECS. Los errores de las implementaciones azul/verde pueden producirse durante las siguientes fases:
+ *Ruta sincrónica*: errores que aparecen inmediatamente en respuesta a las llamadas a la API `CreateService` o `UpdateService`.
+ *Ruta asíncrona*: errores que aparecen en el campo `statusReason` de `DescribeServiceDeployments` y provocan una reversión de la implementación

**sugerencia**  
Puede usar el [Servidor MCP de Amazon ECS](ecs-mcp-introduction.md) con asistentes de IA para monitorear las implementaciones y solucionar problemas de implementación mediante un lenguaje natural.

## Problemas en la configuración del equilibrador de carga
<a name="troubleshooting-blue-green-load-balancer"></a>

La configuración del equilibrador de carga es un componente fundamental de las implementaciones azul/verde en Amazon ECS. La configuración adecuada de las reglas de oyente, los grupos objetivo y los tipos de equilibradores de carga es esencial para que las implementaciones tengan éxito. En esta sección, se describen los problemas de configuración más comunes del equilibrador de carga que pueden provocar que las implementaciones azul/verde fallen.

Al solucionar problemas con el equilibrador de carga, es importante comprender la relación entre las reglas de oyente y los grupos de destino. En una implementación azul/verde:
+ La regla de oyente de producción dirige el tráfico a la revisión del servicio actualmente activa (azul).
+ La regla de oyente de prueba se puede utilizar para validar la nueva revisión del servicio (verde) antes de desplazar el tráfico de producción.
+ Los grupos objetivo se utilizan para registrar las instancias de contenedor de cada revisión del servicio.
+ Durante la implementación, el tráfico se desplaza gradualmente de la revisión de servicio azul a la revisión de servicio verde ajustando las ponderaciones de los grupos objetivo en las reglas de oyente.

### Errores de configuración en la regla de oyente
<a name="troubleshooting-blue-green-listener-rules"></a>

Los siguientes problemas se refieren a una configuración incorrecta de la regla de oyente en las implementaciones azul/verde.

Uso de un ARN de oyente del equilibrador de carga de aplicación en lugar de un ARN de la regla de oyente  
*Mensaje de error*: `productionListenerRule has an invalid ARN format. Must be RuleArn for ALB or ListenerArn for NLB. Got: arn:aws:elasticloadbalancing:us-west-2:123456789012:listener/app/my-alb/abc123/def456`  
*Solución*: cuando utilice un equilibrador de carga de aplicación, debe especificar un ARN de regla de oyente para `productionListenerRule` y `testListenerRule`, no un ARN de oyente. Para los equilibradores de carga de red, debe usar el ARN de oyente.  
 Para obtener más información sobre cómo encontrar el ARN de oyente, consulte [Oyentes para Equilibrador de carga de aplicación](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html) en la *Guía del usuario de equilibradores de carga de aplicación*. El ARN de una regla tiene el formato `arn:aws:elasticloadbalancing:region:account-id:listener-rule/app/...`.

Uso de la misma regla tanto para los oyentes de producción como para los de prueba  
*Mensaje de error*: `The following rules cannot be used as both production and test listener rules: arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-alb/abc123/def456/ghi789`  
*Solución*: debe usar reglas de oyente diferentes para el tráfico de producción y de prueba. Cree una regla de oyente independiente para el tráfico de prueba que se dirija al grupo de destino de prueba.

El grupo de destino no está asociado con las reglas de oyente  
*Mensaje de error*: `Service deployment rolled back because of invalid networking configuration: Target group arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/myAlternateTG/abc123 is not associated with either productionListenerRule or testListenerRule.`  
*Solución*: tanto el grupo de destino principal como el grupo de destino alternativo deben estar asociados a la regla de oyente de producción o a la regla de oyente de prueba. Actualice la configuración del equilibrador de carga para asegurarse de que ambos grupos objetivo estén asociados correctamente a sus reglas de oyente.

Falta una regla de oyente de prueba con un equilibrador de carga de aplicación  
*Mensaje de error*: `For Application LoadBalancer, testListenerRule is required when productionListenerRule is not associated with both targetGroup and alternateTargetGroup`  
*Solución*: cuando utiliza un equilibrador de carga de aplicación, si ambos grupos objetivo no están asociados a la regla de oyente de producción, debe especificar una regla de oyente de prueba. Añada un `testListenerRule` a su configuración y asegúrese de que ambos grupos objetivo estén asociados a la regla de escucha de producción o de prueba. Para obtener más información, consulte [Oyentes para Equilibrador de carga de aplicación](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html) en la *Guía del usuario de los equilibradores de carga de aplicaciones*.

### Errores en la configuración de grupo de destino
<a name="troubleshooting-blue-green-target-groups"></a>

Los siguientes problemas se refieren a una configuración incorrecta del grupo de destino en las implementaciones azul/verde.

Varios grupos objetivo con tráfico en la regla de oyente  
*Mensaje de error*: `Service deployment rolled back because of invalid networking configuration. productionListenerRule arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-alb/abc123/def456/ghi789 should have exactly one target group serving traffic but found 2 target groups which are serving traffic`  
*Solución*: antes de iniciar una implementación azul/verde, asegúrese de que solo un grupo de destino reciba tráfico (con un peso distinto de cero) en la regla de oyente. Actualice la configuración de las reglas de oyente para establecer el peso en cero para cualquier grupo de destino que no deba recibir tráfico.

Grupos objetivo duplicados en las entradas del equilibrador de carga  
*Mensaje de error*: `Duplicate targetGroupArn found: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/myecs-targetgroup/abc123`  
*Solución*: el ARN de cada grupo de destino debe ser único en todas las entradas del equilibrador de carga de la definición del servicio. Revise la configuración y asegúrese de usar grupos de destino diferentes para cada entrada del equilibrador de carga.

Grupo de destino inesperado en la regla de oyente de producción  
*Mensaje de error*: `Service deployment rolled back because of invalid networking configuration. Production listener rule is forwarding traffic to unexpected target group arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/random-nlb-tg/abc123. Expected traffic to be forwarded to either targetGroupArn: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/nlb-targetgroup/def456 or alternateTargetGroupArn: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/nlb-tg-alternate/ghi789`  
*Solución*: la regla de oyente de producción está reenviando el tráfico a un grupo de destino que no está especificado en la definición del servicio. Asegúrese de que la regla de oyente esté configurada para reenviar el tráfico únicamente a los grupos de destino especificados en la definición del servicio.   
Para obtener más información, consulte [forward actions](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html#forward-actions) en la *Guía del usuario de equilibradores de carga de aplicaciones*.

### Errores en la configuración del tipo de equilibrador de carga
<a name="troubleshooting-blue-green-load-balancer-types"></a>

Los siguientes problemas se refieren a una configuración incorrecta del tipo de equilibrador de carga en las implementaciones azul/verde.

Mezcla de configuraciones del equilibrador de carga clásico, el equilibrador de carga de aplicación y el equilibrador de carga de red  
*Mensaje de error*: `All loadBalancers must be strictly either ELBv1 (defining loadBalancerName) or ELBv2 (defining targetGroupArn)`  
Los equilibradores de carga clásicos son los equilibradores de carga de la generación anterior de Elastic Load Balancing. Se recomienda que migre a un equilibrador de carga de la generación actual. Para obtener más información, consulte [Migrar el Equilibrador de carga clásico](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/migrate-classic-load-balancer.html).
*Solución*: . Use todos los equilibradores de carga clásicos o todos los equilibradores de carga de aplicación y los equilibradores de carga de red.  
Para los equilibradores de carga de aplicación y los equilibradores de carga de red, especifique solo el campo `targetGroupArn`.

Uso de una configuración avanzada con un equilibrador de carga clásico  
*Mensaje de error*: `advancedConfiguration field is not allowed with ELBv1 loadBalancers`  
*Solución*: la configuración avanzada para las implementaciones azul/verde solo se admite con los equilibradores de carga de aplicación y los equilibradores de carga de red. Si utiliza un equilibrador de carga clásico (especificado con `loadBalancerName`), no podrá usar el campo `advancedConfiguration`. Cambie a un equilibrador de carga de aplicación o elimine el campo `advancedConfiguration`.

Configuración avanzada incoherente en todos los equilibradores de carga  
*Mensaje de error*: `Either all or none of the provided loadBalancers must have advancedConfiguration defined`  
*Solución*: si utiliza varios equilibradores de carga, debe definir `advancedConfiguration` para todos o para ninguno. Actualice la configuración para garantizar la coherencia en todas las entradas del equilibrador de carga.

Falta una configuración avanzada con una implementación azul/verde  
*Mensaje de error*: `advancedConfiguration field is required for all loadBalancers when using a non-ROLLING deployment strategy`  
*Solución*: si utiliza una estrategia de implementación azul/verde con los equilibradores de carga de aplicación, debe especificar el campo `advancedConfiguration` para todas las entradas del equilibrador de carga. Añada el `advancedConfiguration` necesario a la configuración del equilibrador de carga.

## Problemas con los permisos
<a name="troubleshooting-blue-green-permissions"></a>

Estos son los problemas relacionados con la falta de permisos para las implementaciones azul/verde.

Falta una política de confianza sobre el rol de infraestructura  
*Mensaje de error*: `Service deployment rolled back because of invalid networking configuration. ECS was unable to manage the ELB resources due to missing permissions on ECS Infrastructure Role 'arn:aws:iam::123456789012:role/Admin'.`  
*Solución*: el rol de IAM especificado para administrar los recursos del equilibrador de carga no tiene la política de confianza correcta. Actualice la política de confianza del rol para permitirle al servicio que lo asuma. La política de confianza debe incluir lo siguiente:    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ecs.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
```

Faltan permisos de lectura en el rol del equilibrador de carga  
*Mensaje de error*: `service myService failed to describe target health on target-group myTargetGroup with (error User: arn:aws:sts::123456789012:assumed-role/myELBRole/ecs-service-scheduler is not authorized to perform: elasticloadbalancing:DescribeTargetHealth because no identity-based policy allows the elasticloadbalancing:DescribeTargetHealth action)`  
*Solución*: el rol de IAM utilizado para administrar los recursos del equilibrador de carga no tiene permiso para leer la información sobre el estado del destino. Agregue el permiso `elasticloadbalancing:DescribeTargetHealth` a la política del rol. Para obtener información sobre los permisos de Elastic Load Balancing, consulte [Rol de IAM de infraestructura de Amazon ECS para los equilibradores de carga](AmazonECSInfrastructureRolePolicyForLoadBalancers.md).

Faltan permisos de escritura en el rol del equilibrador de carga  
*Mensaje de error*: `service myService failed to register targets in target-group myTargetGroup with (error User: arn:aws:sts::123456789012:assumed-role/myELBRole/ecs-service-scheduler is not authorized to perform: elasticloadbalancing:RegisterTargets on resource: arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/myTargetGroup/abc123 because no identity-based policy allows the elasticloadbalancing:RegisterTargets action)`  
*Solución*: el rol de IAM utilizado para administrar los recursos del equilibrador de carga no tiene permiso para registrar los destinos. Agregue el permiso `elasticloadbalancing:RegisterTargets` a la política del rol. Para obtener información sobre los permisos de Elastic Load Balancing, consulte [Rol de IAM de infraestructura de Amazon ECS para los equilibradores de carga](AmazonECSInfrastructureRolePolicyForLoadBalancers.md).

Falta permiso para modificar las reglas de oyente  
*Mensaje de error*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. User: arn:aws:sts::123456789012:assumed-role/myELBRole/ECSNetworkingWithELB is not authorized to perform: elasticloadbalancing:ModifyListener on resource: arn:aws:elasticloadbalancing:us-west-2:123456789012:listener/app/my-alb/abc123/def456 because no identity-based policy allows the elasticloadbalancing:ModifyListener action`  
*Solución*: el rol de IAM utilizado para administrar los recursos del equilibrador de carga no tiene permiso modificar los oyentes. Agregue el permiso `elasticloadbalancing:ModifyListener` a la política del rol. Para obtener información sobre los permisos de Elastic Load Balancing, consulte [Rol de IAM de infraestructura de Amazon ECS para los equilibradores de carga](AmazonECSInfrastructureRolePolicyForLoadBalancers.md).

Para las implementaciones azul/verde, recomendamos adjuntar la política administrada `AmazonECS-ServiceLinkedRolePolicy` al rol de infraestructura, que incluye todos los permisos necesarios para administrar los recursos del equilibrador de carga.

## Problemas del enlace de ciclo de vida
<a name="troubleshooting-blue-green-lifecycle-hooks"></a>

Estos son los problemas relacionados con los enlaces de ciclo de vida en las implementaciones azul/verde.

Política de confianza incorrecta en el rol de enlace de Lambda  
*Mensaje de error*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. ECS was unable to assume role arn:aws:iam::123456789012:role/Admin`  
*Solución*: el rol de IAM especificado para el enlace de ciclo de vida de Lambda no tiene la política de confianza correcta. Actualice la política de confianza del rol para permitirle al servicio que lo asuma. La política de confianza debe incluir lo siguiente:    
****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ecs.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
```

El enlace de Lambda devuelve el estado FALLIDO  
*Mensaje de error*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. Lifecycle hook target arn:aws:lambda:us-west-2:123456789012:function:myHook returned FAILED status.`  
*Solución*: la función de Lambda especificada como enlace de ciclo de vida devolvió el estado FALLIDO. Compruebe los registros de funciones de Lambda en los registros de Amazon CloudWatch para determinar el motivo del error y actualice la función para gestionar correctamente el evento de implementación.

Falta permiso para invocar una función de Lambda  
*Mensaje de error*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. ECS was unable to invoke hook target arn:aws:lambda:us-west-2:123456789012:function:myHook due to User: arn:aws:sts::123456789012:assumed-role/myLambdaRole/ECS-Lambda-Execution is not authorized to perform: lambda:InvokeFunction on resource: arn:aws:lambda:us-west-2:123456789012:function:myHook because no identity-based policy allows the lambda:InvokeFunction action`  
*Solución*: el rol de IAM utilizado para el enlace de ciclo de vida de Lambda no tiene permiso para invocar la función de Lambda. Agregue el permiso `lambda:InvokeFunction` a la política del rol para el ARN específico de la función de Lambda. Para obtener información acerca de los permisos de Lambda, consulte [Permisos necesarios para las funciones de Lambda en las implementaciones azul/verde de Amazon ECS](blue-green-permissions.md).

Caducidad del tiempo de espera de la función de Lambda o respuesta no válida  
*Mensaje de error*: `Service deployment rolled back because TEST_TRAFFIC_SHIFT lifecycle hook(s) failed. ECS was unable to parse the response from arn:aws:lambda:us-west-2:123456789012:function:myHook due to HookStatus must not be null`  
*Solución*: la función de Lambda agotó el tiempo de espera o devolvió una respuesta no válida. Asegúrese de que la función de Lambda devuelva una respuesta válida con un campo `hookStatus` establecido en `SUCCEEDED` o `FAILED`. Además, compruebe que el tiempo de espera de la función de Lambda esté configurado de forma adecuada para su lógica de validación. Para obtener más información, consulte [Enlaces de ciclo de vida para las implementaciones de servicios de Amazon ECS](deployment-lifecycle-hooks.md).  
Ejemplo de una respuesta de Lambda válida:  

```
{
  "hookStatus": "SUCCEEDED",
  "reason": "Validation passed"
}
```

# Implementaciones lineales de Amazon ECS
<a name="deployment-type-linear"></a>

Las implementaciones lineales cambian gradualmente el tráfico de la revisión de servicio antigua a la nueva en incrementos iguales a lo largo del tiempo, lo que le permite supervisar cada paso antes de continuar con el siguiente. Con las implementaciones lineales de Amazon ECS, controla el ritmo de cambio del tráfico y validar las nuevas revisiones de servicio con cantidades crecientes de tráfico de producción. Este método proporciona una forma controlada de implementar cambios con la capacidad de supervisar el rendimiento en cada incremento.

## Recursos involucrados en una implementación lineal
<a name="linear-deployment-resources"></a>

Los siguientes son los recursos que intervienen en las implementaciones lineales de Amazon ECS:
+ Cambio de tráfico: el proceso que Amazon ECS utiliza para cambiar el tráfico de producción. En el caso de las implementaciones lineales de Amazon ECS, el tráfico se cambia en incrementos porcentuales iguales con tiempos de espera entre incrementos que se pueden configurar.
+ Porcentaje del paso: el porcentaje del tráfico que se va a cambiar en cada incremento durante una implementación lineal. El valor de este campo es doble y los valores válidos oscilan entre 3,0 y 100,0.
+ Tiempo de incorporación del paso: el tiempo de espera entre cada incremento del cambio de tráfico durante una implementación lineal. Los valores válidos oscilan entre 0 y 1440 minutos.
+ Tiempo de incorporación de la implementación: el tiempo, en minutos, que Amazon ECS espera después de cambiar todo el tráfico de producción a la nueva revisión de servicio antes de finalizar la revisión de servicio antigua. Es el tiempo durante el cual las revisiones de servicio azul y verde se ponen en marcha simultáneamente después de que se haya transferido el tráfico de producción.
+ Etapas del ciclo de vida: serie de eventos de la operación de implementación, como “una transferencia de tráfico posterior a la producción”.
+ Enlace de ciclo de vida: una función de Lambda que se pone en marcha en una etapa específica del ciclo de vida. Puede crear una función que verifique la implementación. Las funciones de Lambda o los enlaces de ciclo de vida configurados para PRODUCTION\$1TRAFFIC\$1SHIFT se invocarán en cada paso del cambio de tráfico de producción.
+ Grupo de destino: un recurso de Elastic Load Balancing que se utiliza para enrutar las solicitudes a uno o más destinos registrados (por ejemplo, instancias de EC2). Cuando se crea un agente de escucha, especifica un grupo de destino para su acción predeterminada. El tráfico se reenvía al grupo de destino especificado en la regla del agente de escucha.
+ Oyente: un recurso de Elastic Load Balancing que comprueba las solicitudes de conexión utilizando el protocolo y el puerto configurados. Las reglas que defina para un oyente determinan cómo Amazon ECS va a enrutar las solicitudes hacia sus destinos registrados.
+ Regla: un recurso de Elastic Load Balancing asociado a un oyente. Una regla define cómo se enrutan las solicitudes y consta de una acción, una condición y una prioridad.

## Consideraciones
<a name="linear-deployment-considerations"></a>

Tenga en cuenta lo siguiente al elegir un tipo de implementación:
+ Uso de recursos: las implementaciones lineales ponen en marcha temporalmente las revisiones de servicio azul y verde simultáneamente, lo que puede duplicar el uso de recursos durante las implementaciones.
+ Supervisión de la implementación: las implementaciones lineales proporcionan información detallada sobre el estado de la implementación, lo que le permite supervisar cada etapa del proceso de implementación y cada incremento del cambio de tráfico.
+ Reversión: las implementaciones lineales facilitan la reversión a la versión anterior si se detectan problemas, ya que la revisión azul se mantiene activa hasta que vence el tiempo de incorporación.
+ Validación gradual: las implementaciones lineales permiten validar la nueva revisión con cantidades crecientes de tráfico de producción, lo que aumenta la confianza en la implementación.
+ Duración de la implementación: las implementaciones lineales tardan más en completarse que las implementaciones únicas debido a los cambios incrementales del tráfico y a los tiempos de espera entre los pasos.

## Funcionamiento de la implementación lineal
<a name="linear-deployment-how-works"></a>

El proceso de implementación lineal de Amazon ECS sigue un método estructurado con seis fases distintas que garantizan actualizaciones de aplicaciones seguras y fiables. Cada fase tiene un propósito específico al validar y hacer la transición de la aplicación de la versión actual (azul) a la nueva versión (verde).

1. Fase de preparación: cree el entorno verde junto con el entorno azul existente.

1. Fase de implementación: implemente la nueva revisión de servicio en un entorno verde. Amazon ECS lanza nuevas tareas mediante la revisión de servicio actualizada, mientras que el entorno azul sigue sirviendo al tráfico de producción.

1. Fase de prueba: valide el entorno verde mediante el enrutamiento del tráfico de prueba. El equilibrador de carga de aplicación dirige las solicitudes de prueba al entorno verde mientras que el tráfico de producción permanece en el entorno azul.

1. Fase de cambio del tráfico lineal: cambie el tráfico de producción de azul a verde gradualmente en incrementos porcentuales iguales en función de la estrategia de implementación que haya configurado.

1. Fase de monitoreo: monitoree el estado de las aplicaciones, las métricas de rendimiento y los estados de alarma durante el periodo correspondiente al tiempo de incorporación. Cuando se detectan problemas, se inicia una operación de reversión.

1. Fase de finalización: para completar la implementación, finalice el entorno azul.

La fase de cambio lineal del tráfico sigue estos pasos:
+ Inicial: la implementación comienza con el 100 % del tráfico dirigido a la revisión de servicio azul (actual). La revisión de servicio verde (nueva) recibe tráfico de prueba, pero inicialmente no recibe tráfico de producción.
+ Cambio de tráfico incremental: el tráfico cambia gradualmente de azul a verde en incrementos porcentuales iguales. Por ejemplo, con una configuración de pasos del 10,0 %, los cambios de tráfico se producen de la siguiente manera:
  + Paso 1: 10,0 % a verde, 90,0 % a azul
  + Paso 2: 20,0 % a verde, 80,0 % a azul
  + Paso 3: 30,0 % a verde, 70,0 % a azul
  + Y así sucesivamente hasta que el 100 % alcance el entorno verde
+ Tiempo de incorporación del paso: entre cada incremento del cambio de tráfico, la implementación espera un tiempo configurable (tiempo de incorporación del paso) para poder supervisar y validar el rendimiento de la nueva revisión con la carga del tráfico aumentado. Tenga en cuenta que el tiempo de incorporación del último paso se omite una vez que el tráfico se ha cambiado un 100,0 %.
+ Enlaces de ciclo de vida: las funciones de Lambda opcionales se pueden poner en marcha en varias etapas del ciclo de vida durante la implementación para realizar una validación, supervisión o lógica personalizada automatizadas. Las funciones de Lambda o los enlaces de ciclo de vida configurados para PRODUCTION\$1TRAFFIC\$1SHIFT se invocarán en cada paso del cambio de tráfico de producción.

## Etapas del ciclo de vida de la implementación
<a name="linear-deployment-lifecycle-stages"></a>

El proceso de implementación lineal avanza durante las distintas etapas del ciclo de vida, cada una con responsabilidades y puntos de control de validación específicos. Conocer estas etapas le ayuda a monitorear el progreso de la implementación y a solucionar los problemas de forma eficaz.

Cada etapa del ciclo de vida puede durar hasta 24 horas y, además, cada paso del cambio de tráfico de PRODUCTION\$1TRAFFIC\$1SHIFT puede durar hasta 24 horas. Recomendamos que el valor se mantenga por debajo de la marca de 24 horas. Esto se debe a que los procesos asíncronos necesitan tiempo para activar los enlaces. El sistema agota el tiempo de espera, no se realiza la implementación y, después, inicia una reversión cuando una etapa alcanza las 24 horas.

Las implementaciones de CloudFormation tienen restricciones de tiempo de espera adicionales. Si bien el límite por etapas de 24 horas sigue vigente, CloudFormation impone un límite de 36 horas para toda la implementación. Si el proceso no se completa en 36 horas, CloudFormation marca un error en la implementación y, a continuación, se inicia una reversión.


| Etapas del ciclo de vida | Descripción | Compatibilidad con los enlaces de ciclo de vida | 
| --- | --- | --- | 
| RECONCILE\$1SERVICE | Esta etapa solo ocurre cuando se inicia una nueva implementación de servicio con más de una revisión de servicio en estado ACTIVO. | Sí | 
| PRE\$1SCALE\$1UP | La revisión de servicio verde no ha comenzado. La revisión de servicio azul gestiona el 100 % del tráfico de producción. No hay tráfico de prueba. | Sí | 
| SCALE\$1UP | El momento en que la revisión de servicio verde se escala verticalmente al 100 % e inicia nuevas tareas. La revisión de servicio verde no sirve ningún tráfico en este momento. | No | 
| POST\$1SCALE\$1UP | La revisión de servicio verde ha comenzado. La revisión de servicio azul gestiona el 100 % del tráfico de producción. No hay tráfico de prueba. | Sí | 
| TEST\$1TRAFFIC\$1SHIFT | Las revisiones de servicio azul y verde están en curso. La revisión de servicio azul gestiona el 100 % del tráfico de producción. La revisión de servicio verde está migrando del 0 % al 100 % del tráfico de prueba. | Sí | 
| POST\$1TEST\$1TRAFFIC\$1SHIFT | Se ha completado la transferencia de tráfico de prueba. La revisión de servicio verde gestiona el 100 % del tráfico de prueba. | Sí | 
| PRODUCTION\$1TRAFFIC\$1SHIFT | El tráfico cambia gradualmente del entorno azul al verde en incrementos porcentuales iguales hasta que el entorno verde recibe el 100 % del tráfico. Cada cambio de tráfico invoca un enlace de ciclo de vida con un tiempo de espera de 24 horas. | 
| POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | Se ha completado la transferencia de tráfico de producción. | Sí | 
| BAKE\$1TIME | El tiempo durante el cual las revisiones de servicio azul y verde se ejecutan simultáneamente. | No | 
| CLEAN\$1UP | La revisión de servicio azul se ha reducido verticalmente por completo a 0 tareas en curso. Tras esta etapa, la revisión de servicio verde es ahora la revisión de servicio de producción. | No | 

# Recursos necesarios para las implementaciones lineales de Amazon ECS
<a name="linear-deployment-implementation"></a>

Para utilizar una implementación lineal con transferencia de tráfico administrada, su servicio debe utilizar una de las siguientes características:
+ Elastic Load Balancing
+ Service Connect

En la siguiente lista se proporciona una descripción general de alto nivel de lo que se debe configurar para las implementaciones lineales de Amazon ECS:
+ Su servicio utiliza un equilibrador de carga de aplicación, un equilibrador de carga de red o Service Connect. Configure los recursos adecuados.
  + Equilibrador de carga de aplicación: para más información, consulte [Recursos de equilibrador de carga de aplicación para las implementaciones azul/verde, las implementaciones lineales y las implementaciones canario](alb-resources-for-blue-green.md).
  + Equilibrador de carga de red: para más información, consulte [Recursos de Equilibrador de carga de red para las implementaciones azul/verde, las implementaciones lineales y las implementaciones canario de Amazon ECS](nlb-resources-for-blue-green.md).
  + Service Connect: para más información, consulte [Recursos de Service Connect para las implementaciones azul/verde, las implementaciones lineales y las implementaciones canario de Amazon ECS](service-connect-blue-green.md).
+ Establezca el controlador de implementación del servicio en `ECS`.
+ Configure la estrategia de implementación como `linear` en su definición de servicio.
+ Opcionalmente, configure parámetros adicionales, como:
  + Tiempo de incorporación para la nueva implementación
  + El porcentaje de tráfico que se cambiará en cada incremento.
  + El tiempo de espera en minutos entre cada incremento de cambio de tráfico. 
  + Alarmas de CloudWatch para la reversión automática
  + Enlaces de ciclo de vida de la implementación (son funciones de Lambda que se ponen en marcha en etapas de implementación específicas, como BEFORE\$1INSTALL, PRODUCTION\$1TRAFFIC\$1SHIFT o POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT)

## Prácticas recomendadas
<a name="linear-deployment-best-practices"></a>

Siga estas prácticas recomendadas para una implementación lineal de Amazon ECS correcta:
+ **Asegúrese de que la aplicación pueda gestionar ambas revisiones de servicio funcionando simultáneamente.**
+ **Planifique una capacidad de clúster suficiente para gestionar ambas revisiones de servicio durante la implementación.**
+ **Compruebe sus procedimientos de reversión antes de implementarlos en producción.**
+ Configure las comprobaciones de estado adecuadas que reflejen con precisión el estado de su aplicación.
+ Establezca un tiempo de incorporación que permita realizar pruebas suficientes de la nueva revisión de servicio.
+ Implemente alarmas de CloudWatch para detectar automáticamente los problemas y activar las reversiones.
+ Elija porcentajes de pasos y tiempos de incorporación que equilibren la velocidad de implementación con las necesidades de validación.
+ Utilice porcentajes de pasos más pequeños (del 5 al 10 %) para las aplicaciones críticas a fin de minimizar la exposición a los riesgos.
+ Establezca tiempos de incorporación más largos para los pasos de las aplicaciones que necesitan tiempo para activarse o estabilizarse.
+ Implemente alarmas de CloudWatch para detectar automáticamente los problemas y activar las reversiones en cualquier incremento del tráfico.
+ Supervise de cerca las métricas de las aplicaciones durante cada cambio de tráfico para detectar si se degrada el rendimiento de forma temprana.
+ Asegúrese de que la aplicación pueda gestionar ambas revisiones de servicio funcionando simultáneamente.
+ Compruebe sus procedimientos de reversión en diferentes porcentajes de tráfico antes de implementarlos en producción.

# Creación de una implementación lineal de Amazon ECS
<a name="deploy-linear-service"></a>

Al utilizar las implementaciones lineales de Amazon ECS, puede cambiar gradualmente el tráfico en incrementos iguales durante intervalos de tiempo específicos. De esta forma, tiene una validación controlada en cada paso del proceso de implementación.

## Requisitos previos
<a name="deploy-linear-service-prerequisites"></a>

Realice las siguientes operaciones antes de iniciar una implementación lineal.

1. Configure los permisos adecuados.
   + Para obtener información sobre los permisos de Elastic Load Balancing, consulte [Rol de IAM de infraestructura de Amazon ECS para los equilibradores de carga](AmazonECSInfrastructureRolePolicyForLoadBalancers.md).
   + Para obtener información acerca de los permisos de Lambda, consulte [Permisos necesarios para las funciones de Lambda en las implementaciones azul/verde de Amazon ECS](blue-green-permissions.md).

1. Las implementaciones lineales de Amazon ECS requieren que su servicio utilice una de las siguientes características: configure los recursos adecuados.
   + Equilibrador de carga de aplicación: para más información, consulte [Recursos de equilibrador de carga de aplicación para las implementaciones azul/verde, las implementaciones lineales y las implementaciones canario](alb-resources-for-blue-green.md).
   + Equilibrador de carga de red: para más información, consulte [Recursos de Equilibrador de carga de red para las implementaciones azul/verde, las implementaciones lineales y las implementaciones canario de Amazon ECS](nlb-resources-for-blue-green.md).
   + Service Connect: para más información, consulte [Recursos de Service Connect para las implementaciones azul/verde, las implementaciones lineales y las implementaciones canario de Amazon ECS](service-connect-blue-green.md).

## Procedimiento
<a name="deploy-linear-service-procedure"></a>

Puede utilizar la consola o la AWS CLI para crear un servicio de implementación lineal de Amazon ECS.

------
#### [ Console ]

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

1. Determine el recurso desde el que lanza el servicio.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/deploy-linear-service.html)

   Aparecerá la página **Crear servicio**.

1. En **Detalles del servicio**, haga lo siguiente:

   1. En **Familia de definiciones de tareas**, elija la definición de tarea que se va a utilizar. A continuación, en **Revisión de la definición de tareas**, introduzca la revisión que desee utilizar.

   1. En **Service name** (Nombre del servicio), ingrese un nombre para el servicio.

1. Para ejecutar el servicio en un clúster existente, en **Clúster existente**, elija el clúster. Para ejecutar el servicio en un clúster nuevo, seleccione **Crear clúster** 

1. Elija cómo distribuir las tareas en la infraestructura de clúster. En **Configuración de computación**, elija su opción.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/deploy-linear-service.html)

1. En **Configuración de implementación**, haga lo siguiente:

   1. En **Tipo de servicio**, seleccione **Réplica**.

   1. En **Desired tasks** (Tareas deseadas), ingrese el número de tareas que se lanzarán y mantendrán en el servicio.

   1. Para que Amazon ECS monitoree la distribución de las tareas entre las zonas de disponibilidad y las redistribuya cuando haya un desequilibrio, en **Reequilibrio del servicio de zonas de disponibilidad**, seleccione **Reequilibrio del servicio de zonas de disponibilidad**.

   1. En **Periodo de gracia de la comprobación de estado**, introduzca la cantidad de tiempo (en segundos) durante la cual el programador de servicios ignora las comprobaciones de estado de Elastic Load Balancing, VPC Lattice y contenedores en mal estado después de que se haya iniciado una tarea por primera vez. Si no se especifica ningún valor para el período de gracia de comprobación de estado, se utiliza el valor predeterminado: 0.

1. En **Configuración de implementación**, configure la implementación lineal:

   1. En **Estrategia de implementación**, elija **Lineal**.

   1. En **Porcentaje de incremento de tráfico**, introduzca el porcentaje de tráfico que se va a cambiar en cada incremento (por ejemplo, 10 % para cambiar el tráfico en incrementos del 10 %).

   1. En **Intervalo entre incrementos**, introduzca el tiempo de espera en minutos entre cada incremento de cambio de tráfico.

   1. En **Tiempo de incorporación**, introduzca el número de minutos que las revisiones de servicio azul y verde durarán simultáneamente después del último cambio de tráfico y antes de que finalice la revisión azul.

   1. (Opcional) Ejecute las funciones de Lambda que se van a ejecutar en etapas específicas de la implementación. En **Enlaces de ciclo de vida de la implementación**, seleccione las etapas para ejecutar los enlaces de ciclo de vida.

      Para agregar un enlace de ciclo de vida:

      1. Elija **Agregar**.

      1. En **Función de Lambda**, introduzca el nombre o el ARN de la función.

      1. En **Rol**, selecione el rol de IAM que tiene permiso para invocar la función de Lambda.

      1. En **Etapas del ciclo de vida**, seleccione las etapas en las que debe ejecutarse la función de Lambda.

1. Para configurar el modo en que Amazon ECS detecta y gestiona los errores de implementación, expanda **Deployment failure detection** (Detección de errores de implementación) y, a continuación, elija sus opciones. 

   1. Para detener una implementación cuando las tareas no puedan iniciarse, seleccione **Use the Amazon ECS deployment circuit breaker** (Utilizar el interruptor de circuito de implementación de Amazon ECS).

      Para que el software restaure automáticamente la implementación a su último estado completado cuando el disyuntor de implementación establezca un estado con error, seleccione **Restauración en caso de error**.

   1. Para detener una implementación en función de las métricas de la aplicación, seleccione **Use CloudWatch alarms**. A continuación, elija las alarmas en **Nombre de la alarma de CloudWatch**. Para crear una alarma nueva, vaya a la consola de CloudWatch.

      Para que el software restaure automáticamente la implementación a su último estado de implementación completada cuando una alarma de CloudWatch establezca un estado con error, seleccione **Restauración en caso de error**.

1. (Opcional) Para interconectar su servicio con Service Connect, expanda **Service Connect** y, a continuación, especifique lo siguiente:

   1.  Seleccione **Activar Service Connect**.

   1. En **Service Connect configuration** (Configuración de Service Connect), especifique el modo cliente.
      + Si su servicio ejecuta una aplicación cliente de red que solo necesita conectarse a otros servicios del espacio de nombres, elija **Solo en el lado del cliente**.
      + Si su servicio ejecuta una aplicación de servicio web o red y necesita proporcionar puntos de conexión para este servicio y se conecta a otros servicios del espacio de nombres, elija **Client and server** (Cliente y servidor).

   1. Para usar un espacio de nombres que no sea el espacio de nombres predeterminado del clúster, en **Namespace** (Espacio de nombres), elija el espacio de nombres del servicio. Puede ser un espacio de nombres creado por separado en la misma Región de AWS de su Cuenta de AWS o un espacio de nombres en la misma región que se comparta con su cuenta mediante AWS Resource Access Manager (AWS RAM). Para obtener más información sobre los espacios de nombres de AWS Cloud Map compartidos, consulte [Cross-account AWS Cloud Map namespace sharing](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) en la *Guía para desarrolladores de AWS Cloud Map*.

   1. (Opcional) Configure las reglas de encabezado de tráfico de prueba para las implementaciones lineales. En **Enrutamiento de tráfico de prueba**, especifique lo siguiente:

      1. Seleccione **Habilitar las reglas de encabezado de tráfico de prueba** para enrutar solicitudes específicas a la revisión de servicio verde durante las pruebas.

      1. En **Reglas de coincidencia de encabezados**, configure los criterios para enrutar el tráfico de prueba:
         + **Nombre del encabezado**: introduzca el nombre del encabezado HTTP que desee que coincida (por ejemplo, `X-Test-Version` o `User-Agent`).
         + **Tipo de coincidencia**: elija los criterios de coincidencia:
           + **Coincidencia exacta**: se enrutan las solicitudes en las que el valor del encabezado coincida exactamente con el valor especificado.
           + **Encabezado presente**: se enrutan las solicitudes que contienen el encabezado especificado, independientemente del valor.
           + **Coincidencia de patrones**: se enrutan las solicitudes en las que el valor del encabezado coincide con un patrón especificado.
         + **Valor del encabezado** (si se utiliza una coincidencia exacta o una coincidencia de patrón): introduzca el valor o patrón con el que desea que haya coincidencia.

         Puede agregar varias reglas de coincidencia de encabezados para crear una lógica de enrutamiento compleja. Las solicitudes que coincidan con alguna de las reglas configuradas se enrutarán a la revisión de servicio verde para su comprobación.

      1. Elija **Agregar regla de encabezado** para configurar condiciones de coincidencia de encabezados adicionales.
**nota**  
Las reglas de encabezado de tráfico de prueba le permiten validar la nueva funcionalidad con tráfico controlado antes de finalizar la implementación completa. Esto le permite comprobar la revisión de servicio verde con solicitudes específicas (como las de las herramientas de pruebas internas o de los usuarios de la versión beta) y, al mismo tiempo, mantener un flujo de tráfico normal hacia la revisión de servicio azul.

   1. (Opcional) Especifique una configuración de registro. Seleccione **Utilizar colección de registros**. La opción predeterminada envía registros de contenedor a los Registros de CloudWatch. Las demás opciones del controlador de registro se configuran mediante AWS FireLens. Para obtener más información, consulte [Envío de registros de Amazon ECS a un servicio de AWS o AWS Partner](using_firelens.md).

      A continuación, se describe con más detalle cada uno de los destinos de registro de contenedor.
      + **Amazon CloudWatch**: configure la tarea para enviar registros de contenedor a CloudWatch Logs. Se proporcionan las opciones de controlador de registro predeterminadas que crean un grupo de registros de CloudWatch en su nombre. Para especificar otro nombre de grupo de registros, cambie los valores de las opciones del controlador.
      + **Amazon Data Firehose**: configure la tarea para enviar registros de contenedor a Firehose. Se proporcionan las opciones de controlador de registro predeterminadas que envían registros a un flujo de entrega de Firehose. Para especificar un nombre de flujo de entrega distinto, cambie los valores de las opciones del controlador.
      + **Amazon Kinesis Data Streams**: configure la tarea para enviar registros de contenedores a Kinesis Data Streams. Se proporcionan las opciones de controlador de registro predeterminadas que envían registros a un flujo de Kinesis Data Streams. Para especificar otro nombre de transmisión, cambie los valores de las opciones del controlador.
      + **Amazon OpenSearch Service**: configure la tarea para enviar registros de contenedor a un dominio de OpenSearch Service. Se deben proporcionar las opciones del controlador de registros. 
      + **Amazon S3**: configure la tarea para enviar registros de contenedor a un bucket de Amazon S3. Se proporcionan las opciones de controlador de registro predeterminadas, pero debe especificar un nombre de bucket de Amazon S3 válido.

1. (Opcional) Configure **Equilibrio de carga** para una implementación lineal.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/deploy-linear-service.html)

1. (Opcional) Para ayudar a identificar el servicio y las tareas, expanda la sección **Tags** (Etiquetas) y, a continuación, configure sus etiquetas.

   Para que Amazon ECS etiquete automáticamente todas las tareas recién lanzadas con el nombre del clúster y las etiquetas de definición de tareas, seleccione **Activar las etiquetas administradas de Amazon ECS** y, a continuación, en **Propagar etiquetas de**, seleccione **Definiciones de tareas**.

   Para que Amazon ECS etiquete automáticamente todas las tareas recién lanzadas con el nombre del clúster y las etiquetas de servicio, seleccione **Activar las etiquetas administradas de Amazon ECS** y, a continuación, en **Propagar etiquetas de**, seleccione **Servicio**.

   Añada o elimine una etiqueta.
   + [Agregar una etiqueta] Seleccione **Add tag** (Agregar etiqueta), y, a continuación, haga lo siguiente:
     + En **Clave**, escriba el nombre de la clave.
     + En **Valor**, escriba el valor de la clave.
   + [Eliminar una etiqueta] Junto a la etiqueta, elija **Remove tag (Quitar etiqueta)**.

1. Seleccione **Crear**.

------
#### [ AWS CLI ]

1. Cree un archivo llamado `linear-service-definition.json` con el siguiente contenido.

   Sustituya las *entradas del usuario* por sus valores.

   ```
   {
     "serviceName": "myLinearService",
     "cluster": "arn:aws:ecs:us-west-2:123456789012:cluster/sample-fargate-cluster",
     "taskDefinition": "sample-fargate:1",
     "desiredCount": 5,
     "launchType": "FARGATE",
     "networkConfiguration": {
       "awsvpcConfiguration": {
         "subnets": [
           "subnet-09ce6e74c116a2299",
           "subnet-00bb3bd7a73526788",
           "subnet-0048a611aaec65477"
         ],
         "securityGroups": [
           "sg-09d45005497daa123"
         ],
         "assignPublicIp": "ENABLED"
       }
     },
     "deploymentController": {
       "type": "ECS"
     },
     "deploymentConfiguration": {
       "strategy": "LINEAR",
       "maximumPercent": 200,
       "minimumHealthyPercent": 100,
       "linearConfiguration": {
         "stepPercentage": 10.0,
         "stepBakeTimeInMinutes":6
       },
       "bakeTimeInMinutes": 10,
       "alarms": {
         "alarmNames": [
           "myAlarm"
         ],
         "rollback": true,
         "enable": true
       }
     },
     "loadBalancers": [
       {
         "targetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-target-group/54402ff563af1197",
         "containerName": "fargate-app",
         "containerPort": 80,
         "advancedConfiguration": {
           "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-target-group/cad10a56f5843199",
           "productionListenerRule": "arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-linear-demo/32e0e4f946c3c05b/9cfa8c482e204f7d/831dbaf72edb911",
           "roleArn": "arn:aws:iam::123456789012:role/LoadBalancerManagementforECS"
         }
       }
     ]
   }
   ```

1. Ejecuta `create-service`.

   ```
   aws ecs create-service --cli-input-json file://linear-service-definition.json
   ```

------

## Siguientes pasos
<a name="deploy-linear-service-next-steps"></a>
+ Actualice el servicio para iniciar la implementación. Para obtener más información, consulte [Actualización de un servicio de Amazon ECS](update-service-console-v2.md).
+ Supervise el proceso de implementación para asegurarse de que siga el patrón lineal:
  + Se crea y escala verticalmente la revisión de servicio verde
  + El tráfico se cambia de forma incremental en los intervalos especificados
  + Cada incremento espera el intervalo de tiempo especificado antes del siguiente cambio
  + Una vez que se haya cambiado todo el tráfico, comienza el tiempo de incorporación
  + Transcurrido el tiempo de incorporación, la revisión azul finaliza

# Implementaciones canario de Amazon ECS
<a name="canary-deployment"></a>

Las implementaciones canario primero enrutan un pequeño porcentaje del tráfico a la nueva revisión para realizar las pruebas iniciales y, después, cambian todo el tráfico restante a la vez cuando la fase de la implementación canario finaliza correctamente. Con las implementaciones canario de Amazon ECS, puede validar las nuevas revisiones de servicio con el tráfico de usuarios real y, al mismo tiempo, minimizar la exposición a los riesgos. Este método proporciona una forma controlada de implementar cambios con la capacidad de supervisar el rendimiento y revertirlos rápidamente si se detectan problemas.

## Recursos involucrados en una implementación canario
<a name="canary-deployment-resources"></a>

Los siguientes son los recursos que intervienen en las implementaciones canario de Amazon ECS:
+ Cambio de tráfico: el proceso que Amazon ECS utiliza para cambiar el tráfico de producción. En el caso de las implementaciones canario de Amazon ECS, el tráfico se cambia en dos fases: primero hasta el porcentaje de la implementación canario y, después, hasta completar la implementación.
+ Porcentaje de la implementación canario: el porcentaje del tráfico enrutado a la nueva versión durante el periodo de evaluación.
+ Tiempo de incorporación de la implementación canario: el tiempo que se dedica a supervisar la versión canario antes de proceder a la implementación completa.
+ Tiempo de incorporación de la implementación: el tiempo, en minutos, que Amazon ECS espera después de cambiar todo el tráfico de producción a la nueva revisión de servicio antes de finalizar la revisión de servicio antigua. Es el tiempo durante el cual las revisiones de servicio azul y verde se ponen en marcha simultáneamente después de que se haya transferido el tráfico de producción.
+ Etapas del ciclo de vida: serie de eventos de la operación de implementación, como “una transferencia de tráfico posterior a la producción”.
+ Enlace de ciclo de vida: una función de Lambda que se pone en marcha en una etapa específica del ciclo de vida. Puede crear una función que verifique la implementación.
+ Grupo de destino: un recurso de Elastic Load Balancing que se utiliza para enrutar las solicitudes a uno o más destinos registrados (por ejemplo, instancias de EC2). Cuando se crea un agente de escucha, especifica un grupo de destino para su acción predeterminada. El tráfico se reenvía al grupo de destino especificado en la regla del agente de escucha.
+ Oyente: un recurso de Elastic Load Balancing que comprueba las solicitudes de conexión utilizando el protocolo y el puerto configurados. Las reglas que defina para un oyente determinan cómo Amazon ECS va a enrutar las solicitudes hacia sus destinos registrados.
+ Regla: un recurso de Elastic Load Balancing asociado a un oyente. Una regla define cómo se enrutan las solicitudes y consta de una acción, una condición y una prioridad.

## Consideraciones
<a name="canary-deployment-considerations"></a>

Tenga en cuenta lo siguiente al elegir un tipo de implementación:
+ Uso de recursos: las implementaciones canario ponen en marcha el conjunto de tareas original y el conjunto de tareas canario simultáneamente durante el periodo de evaluación, lo que aumenta el uso de recursos.
+ Volumen de tráfico: asegúrese de que el porcentaje de tráfico canario genere suficiente tráfico para lograr una validación significativa de la nueva versión.
+ Complejidad de la supervisión: las implementaciones canario requieren la supervisión y comparación de las métricas entre dos versiones diferentes de forma simultánea.
+ Velocidad de reversión: las implementaciones canario permiten llevar a cabo una reversión rápida al revertir el tráfico al conjunto de tareas original.
+ Mitigación de riesgos: las implementaciones canario proporcionan una excelente mitigación de riesgos al limitar la exposición a un pequeño porcentaje de usuarios.
+ Duración de la implementación: las implementaciones canario incluyen periodos de evaluación que amplían el tiempo total de implementación, pero ofrecen oportunidades de validación.

## Funcionamiento de las implementaciones canario
<a name="canary-how-it-works"></a>

El proceso de implementación canario de Amazon ECS sigue un método estructurado con seis fases distintas que garantizan actualizaciones de aplicaciones seguras y fiables. Cada fase tiene un propósito específico al validar y hacer la transición de la aplicación de la versión actual (azul) a la nueva versión (verde).

1. Fase de preparación: cree el entorno verde junto con el entorno azul existente.

1. Fase de implementación: implemente la nueva revisión de servicio en un entorno verde. Amazon ECS lanza nuevas tareas mediante la revisión de servicio actualizada, mientras que el entorno azul sigue sirviendo al tráfico de producción.

1. Fase de prueba: valide el entorno verde mediante el enrutamiento del tráfico de prueba. El equilibrador de carga de aplicación dirige las solicitudes de prueba al entorno verde mientras que el tráfico de producción permanece en el entorno azul.

1. Fase de cambio de tráfico de la implementación canario: durante la fase de implementación canario, se cambia el porcentaje configurado del tráfico a la nueva revisión de servicio verde, seguido de un cambio del 100,0 % del tráfico a la revisión de servicio verde

1. Fase de monitoreo: monitoree el estado de las aplicaciones, las métricas de rendimiento y los estados de alarma durante el periodo correspondiente al tiempo de incorporación. Cuando se detectan problemas, se inicia una operación de reversión.

1. Fase de finalización: para completar la implementación, finalice el entorno azul.

La fase de cambio del tráfico canario sigue estos pasos:
+ Inicial: la implementación comienza con el 100 % del tráfico dirigido a la revisión de servicio azul (actual). La revisión de servicio verde (nueva) recibe tráfico de prueba, pero inicialmente no recibe tráfico de producción.
+ Cambio de tráfico canario: se trata de una estrategia de cambio de tráfico en dos pasos.
  + Paso 1: 10,0 % a verde, 90,0 % a azul
  + Paso 2: 100,0 % a verde, 0,0 % a azul
+ Tiempo de incorporación del tráfico canario: espera un tiempo configurable (tiempo de incorporación del tráfico canario) después del cambio del tráfico canario para poder supervisar y validar el rendimiento de la nueva revisión con la carga del tráfico aumentado.
+ Enlaces de ciclo de vida: las funciones de Lambda opcionales se pueden poner en marcha en varias etapas del ciclo de vida durante la implementación para realizar una validación, supervisión o lógica personalizada automatizadas. Las funciones de Lambda o los enlaces de ciclo de vida configurados para PRODUCTION\$1TRAFFIC\$1SHIFT se invocarán en cada paso del cambio de tráfico de producción.

### Etapas del ciclo de vida de la implementación
<a name="canary-deployment-lifecycle-stages"></a>

El proceso de implementación canario avanza durante las distintas etapas del ciclo de vida, cada una con responsabilidades y puntos de control de validación específicos. Conocer estas etapas le ayuda a monitorear el progreso de la implementación y a solucionar los problemas de forma eficaz.

Cada etapa del ciclo de vida puede durar hasta 24 horas y, además, cada paso del cambio de tráfico de PRODUCTION\$1TRAFFIC\$1SHIFT puede durar hasta 24 horas. Recomendamos que el valor se mantenga por debajo de la marca de 24 horas. Esto se debe a que los procesos asíncronos necesitan tiempo para activar los enlaces. El sistema agota el tiempo de espera, no se realiza la implementación y, después, inicia una reversión cuando una etapa alcanza las 24 horas.

Las implementaciones de CloudFormation tienen restricciones de tiempo de espera adicionales. Si bien el límite por etapas de 24 horas sigue vigente, CloudFormation impone un límite de 36 horas para toda la implementación. Si el proceso no se completa en 36 horas, CloudFormation marca un error en la implementación y, a continuación, se inicia una reversión.


**Etapas del ciclo de vida**  

| Etapas del ciclo de vida | Descripción | Compatibilidad con los enlaces de ciclo de vida | 
| --- | --- | --- | 
| RECONCILE\$1SERVICE | Esta etapa solo ocurre cuando se inicia una nueva implementación de servicio con más de una revisión de servicio en estado ACTIVO. | Sí | 
| PRE\$1SCALE\$1UP | La revisión de servicio verde no ha comenzado. La revisión de servicio azul gestiona el 100 % del tráfico de producción. No hay tráfico de prueba. | Sí | 
| SCALE\$1UP | El momento en que la revisión de servicio verde se escala verticalmente al 100 % e inicia nuevas tareas. La revisión de servicio verde no sirve ningún tráfico en este momento. | No | 
| POST\$1SCALE\$1UP | La revisión de servicio verde ha comenzado. La revisión de servicio azul gestiona el 100 % del tráfico de producción. No hay tráfico de prueba. | Sí | 
| TEST\$1TRAFFIC\$1SHIFT | Las revisiones de servicio azul y verde están en curso. La revisión de servicio azul gestiona el 100 % del tráfico de producción. La revisión de servicio verde está migrando del 0 % al 100 % del tráfico de prueba. | Sí | 
| POST\$1TEST\$1TRAFFIC\$1SHIFT | Se ha completado la transferencia de tráfico de prueba. La revisión de servicio verde gestiona el 100 % del tráfico de prueba. | Sí | 
| PRODUCTION\$1TRAFFIC\$1SHIFT | El tráfico de producción canario se enruta a la revisión verde y se invoca el enlace de ciclo de vida con un tiempo de espera de 24 horas. El segundo paso cambia el tráfico de producción restante a la revisión verde. | Sí | 
| POST\$1PRODUCTION\$1TRAFFIC\$1SHIFT | Se ha completado la transferencia de tráfico de producción. | Sí | 
| BAKE\$1TIME | El tiempo durante el cual las revisiones de servicio azul y verde se ejecutan simultáneamente. | No | 
| CLEAN\$1UP | La revisión de servicio azul se ha reducido verticalmente por completo a 0 tareas en curso. Tras esta etapa, la revisión de servicio verde es ahora la revisión de servicio de producción. | No | 

### Parámetros de configuración
<a name="canary-configuration-parameters"></a>

Los siguientes parámetros de configuración son necesarios para las implementaciones canario:
+ Porcentaje canario: porcentaje del tráfico que se enruta a la nueva revisión de servicio durante la fase canario. Esto permite realizar pruebas con un subconjunto controlado del tráfico de producción.
+ Tiempo de incorporación del tráfico canario: el tiempo que se debe esperar durante la fase canario antes de cambiar el tráfico restante a la nueva revisión de servicio. Esto proporciona tiempo para supervisar y validar la nueva versión.

### Administración del tráfico
<a name="canary-traffic-management"></a>

Las implementaciones canario usan grupos de destino con equilibradores de carga para administrar la distribución del tráfico:
+ Grupo de destino original: contiene las tareas de la versión estable actual y recibe la mayor parte del tráfico.
+ Grupo de destino canario: contiene las tareas de la nueva versión y recibe un pequeño porcentaje del tráfico para realizar las pruebas.
+ Enrutamiento ponderado: el equilibrador de carga usa reglas de enrutamiento ponderado para distribuir el tráfico entre los grupos de destino en función del porcentaje de tráfico canario configurado.

### Supervisión y validación
<a name="canary-monitoring-validation"></a>

Las implementaciones canario eficaces se basan en una supervisión integral:
+ Comprobaciones de estado: ambos conjuntos de tareas deben superar las comprobaciones de estado antes de recibir tráfico.
+ Comparación de métricas: compare los indicadores clave de rendimiento entre la versión original y la versión canario, como el tiempo de respuesta, la tasa de errores y el rendimiento.
+ Reversión automática: configure alarmas de CloudWatch para que activen una reversión automáticamente si la versión canario presenta una reducción del rendimiento.
+ Validación manual: utilice el periodo de evaluación para revisar manualmente los registros, las métricas y los comentarios de los usuarios antes de continuar.

### Prácticas recomendadas para las implementaciones canario
<a name="canary-best-practices"></a>

Siga estas prácticas recomendadas para garantizar el éxito de las implementaciones canario con servicios.

#### Selección de los porcentajes de tráfico adecuados
<a name="canary-traffic-percentage"></a>

Tenga en cuenta estos factores al seleccionar los porcentajes de tráfico canario:
+ Comience poco a poco: comience con un porcentaje de tráfico de entre el 5 y el 10 % para minimizar el impacto en caso de que surjan problemas.
+ Tenga en cuenta la importancia de las aplicaciones: utilice porcentajes más bajos para las aplicaciones críticas para su empresa y porcentajes más altos para los servicios menos importantes.
+ Tenga en cuenta el volumen de tráfico: asegúrese de que el porcentaje de tráfico canario genere suficiente tráfico para lograr una validación significativa.

#### Definición de periodos de evaluación adecuados
<a name="canary-evaluation-time"></a>

Configure los periodos de evaluación en función de estas consideraciones:
+ Deje tiempo suficiente: establezca periodos de evaluación lo suficientemente largos como para capturar datos de rendimiento significativos; normalmente de 10 a 30 minutos.
+ Tenga en cuenta los patrones de tráfico: tenga en cuenta los patrones de tráfico y las horas de máximo uso de la aplicación.
+ Equilibre la velocidad y la seguridad: los periodos de evaluación más largos proporcionan más datos, pero reducen la velocidad de implementación.

#### Implementación de una supervisión integral
<a name="canary-monitoring-setup"></a>

Configure medidas de supervisión para realizar un seguimiento del rendimiento de la implementación canario:
+ Métricas clave: supervise el tiempo de respuesta, la tasa de errores, el rendimiento y la utilización de los recursos para ambos conjuntos de tareas.
+ Reversión basada en alarmas: configure alarmas de CloudWatch para que activen una reversión automáticamente cuando las métricas superen los umbrales.
+ Análisis comparativo: configure paneles de control para comparar las métricas entre la versión original y la versión canario de forma detallada.
+ Métricas de empresa: incluya métricas específicas de la empresa, como las tasas de conversión o la interacción de los usuarios, junto con las métricas técnicas.

#### Planificación de estrategias de reversión
<a name="canary-rollback-strategy"></a>

Prepárese para posibles escenarios de reversión con estas estrategias:
+ Reversión automática: configure activadores de reversiones automáticas en función de las comprobaciones de estado y las métricas de rendimiento.
+ Procedimientos de reversión manual: documente procedimientos claros para realizar una reversión manual cuando los activadores automáticos no capturen todos los problemas.
+ Pruebas de reversión: pruebe periódicamente los procedimientos de reversión para asegurarse de que funcionarán correctamente cuando sea necesario.

#### Validación exhaustiva antes de la implementación
<a name="canary-testing-validation"></a>

Asegúrese de realizar una validación exhaustiva antes de proceder con las implementaciones canario:
+ Pruebas previas a la implementación: pruebe minuciosamente los cambios en los entornos de ensayo antes de la implementación canario.
+ Configuración de las comprobaciones de estado: asegúrese de que las comprobaciones de estado reflejen con precisión la preparación y la funcionalidad de las aplicaciones.
+ Validación de las dependencias: compruebe que las nuevas versiones sean compatibles con los servicios previos y posteriores.
+ Coherencia de datos: asegúrese de que los cambios en el esquema de la base de datos y las migraciones de datos sean compatibles con las versiones anteriores.

#### Coordinación de la participación del equipo
<a name="canary-team-coordination"></a>

Asegúrese de que haya una coordinación eficaz del equipo durante las implementaciones canario:
+ Periodos de implementación: programe las implementaciones canario durante el horario laboral, cuando los equipos estén disponibles para supervisar y responder.
+ Canales de comunicación: establezca canales de comunicación claros para conocer el estado de la implementación y derivar los problemas al equipo adecuado.
+ Asignación de roles: defina los roles y responsabilidades para la supervisión, la toma de decisiones y la puesta en marcha de las reversiones.

# Recursos necesarios para las implementaciones canario de Amazon ECS
<a name="canary-deployment-implementation"></a>

Para utilizar una implementación canario con transferencia de tráfico administrada, su servicio debe utilizar una de las siguientes características:
+ Elastic Load Balancing
+ Service Connect

En la siguiente lista se proporciona una descripción general de alto nivel de lo que se debe configurar para las implementaciones canario de Amazon ECS:
+ Su servicio utiliza un equilibrador de carga de aplicación, un equilibrador de carga de red o Service Connect. Configure los recursos adecuados.
  + Equilibrador de carga de aplicación: para más información, consulte [Recursos de equilibrador de carga de aplicación para las implementaciones azul/verde, las implementaciones lineales y las implementaciones canario](alb-resources-for-blue-green.md).
  + Equilibrador de carga de red: para más información, consulte [Recursos de Equilibrador de carga de red para las implementaciones azul/verde, las implementaciones lineales y las implementaciones canario de Amazon ECS](nlb-resources-for-blue-green.md).
  + Service Connect: para más información, consulte [Recursos de Service Connect para las implementaciones azul/verde, las implementaciones lineales y las implementaciones canario de Amazon ECS](service-connect-blue-green.md).
+ Establezca el controlador de implementación del servicio en `ECS`.
+ Configure la estrategia de implementación como `canary` en su definición de servicio.
+ Opcionalmente, configure parámetros adicionales, como:
  + Tiempo de incorporación para la nueva implementación
  + Porcentaje del tráfico que se enruta a la nueva revisión de servicio durante la fase canario. 
  + El tiempo que se debe esperar durante la fase canario antes de cambiar el tráfico restante a la nueva revisión de servicio. 
  + Alarmas de CloudWatch para la reversión automática
  + Enlaces de ciclo de vida de la implementación (son funciones de Lambda que se ponen en marcha en etapas de implementación específicas)

## Prácticas recomendadas
<a name="canary-deployment-best-practices"></a>

Siga estas prácticas recomendadas para una implementación canario de Amazon ECS correcta:
+ **Asegúrese de que la aplicación pueda gestionar ambas revisiones de servicio funcionando simultáneamente.**
+ **Planifique una capacidad de clúster suficiente para gestionar ambas revisiones de servicio durante la implementación.**
+ **Compruebe sus procedimientos de reversión antes de implementarlos en producción.**
+ Configure las comprobaciones de estado adecuadas que reflejen con precisión el estado de su aplicación.
+ Establezca un tiempo de incorporación que permita realizar pruebas suficientes de la implementación verde.
+ Implemente alarmas de CloudWatch para detectar automáticamente los problemas y activar las reversiones.
+ Utilice los enlaces de ciclo de vida para realizar pruebas automatizadas en cada etapa de la implementación.
+ Comience con porcentajes de tráfico canario pequeños (del 5 al 10 %) para minimizar el impacto en caso de que surjan problemas.
+ Establezca periodos de evaluación adecuados que dejen tiempo suficiente para recopilar datos de rendimiento significativos.
+ Implemente una supervisión integral con alarmas de CloudWatch para activar reversiones automáticas.
+ Configure comprobaciones de estado que reflejen con precisión la preparación y la funcionalidad de la aplicación.
+ Durante la evaluación, supervise tanto las métricas técnicas (tiempo de respuesta, tasa de errores) como las métricas de empresa.
+ Asegúrese de que la aplicación pueda gestionar la división del tráfico sin problemas de sesión o estado.
+ Planifique los procedimientos de reversión y pruébelos periódicamente para asegurarse de que funcionarán cuando sea necesario.
+ Programe las implementaciones canario durante el horario laboral, cuando los equipos puedan supervisar y responder.
+ Valide los cambios minuciosamente en los entornos de ensayo antes de la implementación canario.
+ Documente procedimientos claros para las intervenciones manuales y las decisiones de reversión.

# Creación de una implementación canario de Amazon ECS
<a name="deploy-canary-service"></a>

Al utilizar las implementaciones canario de Amazon ECS, puede cambiar un pequeño porcentaje del tráfico a la nueva revisión de servicio (la revisión “canario”). Valide la implementación y, a continuación, transfiera el tráfico restante a la vez tras un intervalo específico. Este enfoque le permite probar la nueva funcionalidad con un riesgo mínimo antes de realizar la implementación completa.

## Requisitos previos
<a name="deploy-canary-service-prerequisites"></a>

Realice las siguientes operaciones antes de iniciar una implementación canario.

1. Configure los permisos adecuados.
   + Para obtener información sobre los permisos de Elastic Load Balancing, consulte [Rol de IAM de infraestructura de Amazon ECS para los equilibradores de carga](AmazonECSInfrastructureRolePolicyForLoadBalancers.md).
   + Para obtener información acerca de los permisos de Lambda, consulte [Permisos necesarios para las funciones de Lambda en las implementaciones azul/verde de Amazon ECS](blue-green-permissions.md).

1. Las implementaciones canario de Amazon ECS requieren que su servicio utilice una de las siguientes características: configure los recursos adecuados.
   + Equilibrador de carga de aplicación: para más información, consulte [Recursos de equilibrador de carga de aplicación para las implementaciones azul/verde, las implementaciones lineales y las implementaciones canario](alb-resources-for-blue-green.md).
   + Equilibrador de carga de red: para más información, consulte [Recursos de Equilibrador de carga de red para las implementaciones azul/verde, las implementaciones lineales y las implementaciones canario de Amazon ECS](nlb-resources-for-blue-green.md).
   + Service Connect: para más información, consulte [Recursos de Service Connect para las implementaciones azul/verde, las implementaciones lineales y las implementaciones canario de Amazon ECS](service-connect-blue-green.md).

## Procedimiento
<a name="deploy-canary-service-procedure"></a>

Puede utilizar la consola o la AWS CLI para crear un servicio de implementación canario de Amazon ECS.

------
#### [ Console ]

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

1. Determine el recurso desde el que lanza el servicio.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/deploy-canary-service.html)

   Aparecerá la página **Crear servicio**.

1. En **Detalles del servicio**, haga lo siguiente:

   1. En **Familia de definiciones de tareas**, elija la definición de tarea que se va a utilizar. A continuación, en **Revisión de la definición de tareas**, introduzca la revisión que desee utilizar.

   1. En **Service name** (Nombre del servicio), ingrese un nombre para el servicio.

1. Para ejecutar el servicio en un clúster existente, en **Clúster existente**, elija el clúster. Para ejecutar el servicio en un clúster nuevo, seleccione **Crear clúster** 

1. Elija cómo distribuir las tareas en la infraestructura de clúster. En **Configuración de computación**, elija su opción.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/deploy-canary-service.html)

1. En **Configuración de implementación**, haga lo siguiente:

   1. En **Tipo de servicio**, seleccione **Réplica**.

   1. En **Desired tasks** (Tareas deseadas), ingrese el número de tareas que se lanzarán y mantendrán en el servicio.

   1. Para que Amazon ECS monitoree la distribución de las tareas entre las zonas de disponibilidad y las redistribuya cuando haya un desequilibrio, en **Reequilibrio del servicio de zonas de disponibilidad**, seleccione **Reequilibrio del servicio de zonas de disponibilidad**.

   1. En **Periodo de gracia de la comprobación de estado**, introduzca la cantidad de tiempo (en segundos) durante la cual el programador de servicios ignora las comprobaciones de estado de Elastic Load Balancing, VPC Lattice y contenedores en mal estado después de que se haya iniciado una tarea por primera vez. Si no se especifica ningún valor para el período de gracia de comprobación de estado, se utiliza el valor predeterminado: 0.

1. En **Configuración de implementación**, configure la implementación canario:

   1. En **Estrategia de implementación**, elija **Canario**.

   1. En **Porcentaje de tráfico canario**, introduzca el porcentaje de tráfico que pasará a la revisión de servicio verde en la primera etapa (por ejemplo, un 10 % para el tráfico canario inicial).

   1. En **Tiempo de incorporación del tráfico canario**, introduzca el tiempo de espera en minutos antes de cambiar el tráfico restante a la revisión de servicio verde.

   1. En **Tiempo de incorporación**, introduzca el número de minutos que las revisiones de servicio azul y verde durarán simultáneamente después del último cambio de tráfico y antes de que finalice la revisión azul.

   1. (Opcional) Ejecute las funciones de Lambda que se van a ejecutar en etapas específicas de la implementación. En **Enlaces de ciclo de vida de la implementación**, seleccione las etapas para ejecutar los enlaces de ciclo de vida.

      Para agregar un enlace de ciclo de vida:

      1. Elija **Agregar**.

      1. En **Función de Lambda**, introduzca el nombre o el ARN de la función.

      1. En **Rol**, selecione el rol de IAM que tiene permiso para invocar la función de Lambda.

      1. En **Etapas del ciclo de vida**, seleccione las etapas en las que debe ejecutarse la función de Lambda.

1. Para configurar el modo en que Amazon ECS detecta y gestiona los errores de implementación, expanda **Deployment failure detection** (Detección de errores de implementación) y, a continuación, elija sus opciones. 

   1. Para detener una implementación cuando las tareas no puedan iniciarse, seleccione **Use the Amazon ECS deployment circuit breaker** (Utilizar el interruptor de circuito de implementación de Amazon ECS).

      Para que el software restaure automáticamente la implementación a su último estado completado cuando el disyuntor de implementación establezca un estado con error, seleccione **Restauración en caso de error**.

   1. Para detener una implementación en función de las métricas de la aplicación, seleccione **Use CloudWatch alarms**. A continuación, elija las alarmas en **Nombre de la alarma de CloudWatch**. Para crear una alarma nueva, vaya a la consola de CloudWatch.

      Para que el software restaure automáticamente la implementación a su último estado de implementación completada cuando una alarma de CloudWatch establezca un estado con error, seleccione **Restauración en caso de error**.

1. (Opcional) Para interconectar su servicio con Service Connect, expanda **Service Connect** y, a continuación, especifique lo siguiente:

   1.  Seleccione **Activar Service Connect**.

   1. En **Service Connect configuration** (Configuración de Service Connect), especifique el modo cliente.
      + Si su servicio ejecuta una aplicación cliente de red que solo necesita conectarse a otros servicios del espacio de nombres, elija **Solo en el lado del cliente**.
      + Si su servicio ejecuta una aplicación de servicio web o red y necesita proporcionar puntos de conexión para este servicio y se conecta a otros servicios del espacio de nombres, elija **Client and server** (Cliente y servidor).

   1. Para usar un espacio de nombres que no sea el espacio de nombres predeterminado del clúster, en **Namespace** (Espacio de nombres), elija el espacio de nombres del servicio. Puede ser un espacio de nombres creado por separado en la misma Región de AWS de su Cuenta de AWS o un espacio de nombres en la misma región que se comparta con su cuenta mediante AWS Resource Access Manager (AWS RAM). Para obtener más información sobre los espacios de nombres de AWS Cloud Map compartidos, consulte [Cross-account AWS Cloud Map namespace sharing](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) en la *Guía para desarrolladores de AWS Cloud Map*.

   1. (Opcional) Configure las reglas de encabezado de tráfico de prueba para las implementaciones canario. En **Enrutamiento de tráfico de prueba**, especifique lo siguiente:

      1. Seleccione **Habilitar las reglas de encabezado de tráfico de prueba** para enrutar solicitudes específicas a la revisión de servicio verde durante las pruebas.

      1. En **Reglas de coincidencia de encabezados**, configure los criterios para enrutar el tráfico de prueba:
         + **Nombre del encabezado**: introduzca el nombre del encabezado HTTP que desee que coincida (por ejemplo, `X-Test-Version` o `User-Agent`).
         + **Tipo de coincidencia**: elija los criterios de coincidencia:
           + **Coincidencia exacta**: se enrutan las solicitudes en las que el valor del encabezado coincida exactamente con el valor especificado.
           + **Encabezado presente**: se enrutan las solicitudes que contienen el encabezado especificado, independientemente del valor.
           + **Coincidencia de patrones**: se enrutan las solicitudes en las que el valor del encabezado coincide con un patrón especificado.
         + **Valor del encabezado** (si se utiliza una coincidencia exacta o una coincidencia de patrón): introduzca el valor o patrón con el que desea que haya coincidencia.

         Puede agregar varias reglas de coincidencia de encabezados para crear una lógica de enrutamiento compleja. Las solicitudes que coincidan con alguna de las reglas configuradas se enrutarán a la revisión de servicio verde para su comprobación.

      1. Elija **Agregar regla de encabezado** para configurar condiciones de coincidencia de encabezados adicionales.
**nota**  
Las reglas de encabezado de tráfico de prueba le permiten validar la nueva funcionalidad con tráfico controlado antes de finalizar la implementación completa. Esto le permite comprobar la revisión de servicio verde con solicitudes específicas (como las de las herramientas de pruebas internas o de los usuarios de la versión beta) y, al mismo tiempo, mantener un flujo de tráfico normal hacia la revisión de servicio azul.

   1. (Opcional) Especifique una configuración de registro. Seleccione **Utilizar colección de registros**. La opción predeterminada envía registros de contenedor a los Registros de CloudWatch. Las demás opciones del controlador de registro se configuran mediante AWS FireLens. Para obtener más información, consulte [Envío de registros de Amazon ECS a un servicio de AWS o AWS Partner](using_firelens.md).

      A continuación, se describe con más detalle cada uno de los destinos de registro de contenedor.
      + **Amazon CloudWatch**: configure la tarea para enviar registros de contenedor a CloudWatch Logs. Se proporcionan las opciones de controlador de registro predeterminadas que crean un grupo de registros de CloudWatch en su nombre. Para especificar otro nombre de grupo de registros, cambie los valores de las opciones del controlador.
      + **Amazon Data Firehose**: configure la tarea para enviar registros de contenedor a Firehose. Se proporcionan las opciones de controlador de registro predeterminadas que envían registros a un flujo de entrega de Firehose. Para especificar un nombre de flujo de entrega distinto, cambie los valores de las opciones del controlador.
      + **Amazon Kinesis Data Streams**: configure la tarea para enviar registros de contenedores a Kinesis Data Streams. Se proporcionan las opciones de controlador de registro predeterminadas que envían registros a un flujo de Kinesis Data Streams. Para especificar otro nombre de transmisión, cambie los valores de las opciones del controlador.
      + **Amazon OpenSearch Service**: configure la tarea para enviar registros de contenedor a un dominio de OpenSearch Service. Se deben proporcionar las opciones del controlador de registros. 
      + **Amazon S3**: configure la tarea para enviar registros de contenedor a un bucket de Amazon S3. Se proporcionan las opciones de controlador de registro predeterminadas, pero debe especificar un nombre de bucket de Amazon S3 válido.

1. (Opcional) Configure **Equilibrio de carga** para una implementación canario.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/deploy-canary-service.html)

1. (Opcional) Para ayudar a identificar el servicio y las tareas, expanda la sección **Tags** (Etiquetas) y, a continuación, configure sus etiquetas.

   Para que Amazon ECS etiquete automáticamente todas las tareas recién lanzadas con el nombre del clúster y las etiquetas de definición de tareas, seleccione **Activar las etiquetas administradas de Amazon ECS** y, a continuación, en **Propagar etiquetas de**, seleccione **Definiciones de tareas**.

   Para que Amazon ECS etiquete automáticamente todas las tareas recién lanzadas con el nombre del clúster y las etiquetas de servicio, seleccione **Activar las etiquetas administradas de Amazon ECS** y, a continuación, en **Propagar etiquetas de**, seleccione **Servicio**.

   Añada o elimine una etiqueta.
   + [Agregar una etiqueta] Seleccione **Add tag** (Agregar etiqueta), y, a continuación, haga lo siguiente:
     + En **Clave**, escriba el nombre de la clave.
     + En **Valor**, escriba el valor de la clave.
   + [Eliminar una etiqueta] Junto a la etiqueta, elija **Remove tag (Quitar etiqueta)**.

1. Seleccione **Crear**.

------
#### [ AWS CLI ]

1. Cree un archivo llamado `canary-service-definition.json` con el siguiente contenido.

   Sustituya las *entradas del usuario* por sus valores.

   ```
   {
     "serviceName": "myCanaryService",
     "cluster": "arn:aws:ecs:us-west-2:123456789012:cluster/sample-fargate-cluster",
     "taskDefinition": "sample-fargate:1",
     "desiredCount": 5,
     "launchType": "FARGATE",
     "networkConfiguration": {
       "awsvpcConfiguration": {
         "subnets": [
           "subnet-09ce6e74c116a2299",
           "subnet-00bb3bd7a73526788",
           "subnet-0048a611aaec65477"
         ],
         "securityGroups": [
           "sg-09d45005497daa123"
         ],
         "assignPublicIp": "ENABLED"
       }
     },
     "deploymentController": {
       "type": "ECS"
     },
     "deploymentConfiguration": {
       "strategy": "CANARY",
       "maximumPercent": 200,
       "minimumHealthyPercent": 100,
       "canaryConfiguration" : {
           "canaryPercent" : 5.0,
           "canaryBakeTime" : 10
       },
       "bakeTimeInMinutes": 10,
       "alarms": {
         "alarmNames": [
           "myAlarm"
         ],
         "rollback": true,
         "enable": true
       }
     },
     "loadBalancers": [
       {
         "targetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-target-group/54402ff563af1197",
         "containerName": "fargate-app",
         "containerPort": 80,
         "advancedConfiguration": {
           "alternateTargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-target-group/cad10a56f5843199",
           "productionListenerRule": "arn:aws:elasticloadbalancing:us-west-2:123456789012:listener-rule/app/my-canary-demo/32e0e4f946c3c05b/9cfa8c482e204f7d/831dbaf72edb911",
           "roleArn": "arn:aws:iam::123456789012:role/LoadBalancerManagementforECS"
         }
       }
     ]
   }
   ```

1. Ejecuta `create-service`.

   ```
   aws ecs create-service --cli-input-json file://canary-service-definition.json
   ```

------

## Siguientes pasos
<a name="deploy-canary-service-next-steps"></a>

Tras configurar la implementación canario, siga estos pasos:
+ Actualice el servicio para iniciar la implementación. Para obtener más información, consulte [Actualización de un servicio de Amazon ECS](update-service-console-v2.md).
+ Supervise el proceso de implementación para asegurarse de que siga el patrón de la implementación canario:
  + Se crea y escala verticalmente la revisión de servicio verde
  + Un pequeño porcentaje del tráfico (canario) se transfiere a la revisión verde
  + El sistema espera el intervalo canario especificado
  + El tráfico restante se transfiere a la vez a la revisión verde
  + Transcurrido el tiempo de incorporación, la revisión azul finaliza

## Terminología de implementación
<a name="deployment-terminology"></a>

Los siguientes términos se utilizan en la documentación sobre implementaciones de Amazon ECS:

Implementación azul/verde  
Una estrategia de implementación que crea un entorno nuevo (verde) junto con el entorno existente (azul) y, a continuación, cambia el tráfico del entorno azul al verde tras la validación.

Implementación de valores controlados  
Una estrategia de implementación que enruta un pequeño porcentaje del tráfico a una nueva versión y, al mismo tiempo, mantiene la mayoría en la versión estable para su validación.

Implementación lineal  
Una estrategia de implementación que cambia gradualmente el tráfico desde la versión antigua a la nueva en incrementos iguales a lo largo del tiempo.

Implementación continua  
Una estrategia de implementación que reemplaza las instancias de la versión antigua por instancias de la nueva versión, una por una.

Conjunto de tareas  
Conjunto de tareas que ponen en marcha la misma definición de tarea dentro de un servicio durante una implementación.

Grupo de destino  
Agrupación lógica de destinos que reciben tráfico de un equilibrador de carga durante las implementaciones.

Controlador de implementación  
El método utilizado para implementar nuevas versiones del servicio, como Amazon ECS, CodeDeploy o controladores externos.

Reversión  
El proceso de volver a una versión anterior de la aplicación cuando se detectan problemas durante la implementación.

# Implementación de los servicios de Amazon ECS mediante un controlador de terceros
<a name="deployment-type-external"></a>

El tipo de implementación *externa* le permite utilizar cualquier controlador de implementación de terceros para tener un control completo del proceso de implementación de un servicio de Amazon ECS. Los detalles del servicio se administran por medio de las acciones de la API de administración de servicios (`CreateService`, `UpdateService` y `DeleteService`) o las acciones de la API de administración de conjunto de tareas (`CreateTaskSet`, `UpdateTaskSet`, `UpdateServicePrimaryTaskSet` y `DeleteTaskSet`). Cada acción de la API administra un subconjunto de los parámetros de definición del servicio.

La acción de la API `UpdateService` actualiza los parámetros de período de gracia de comprobación de estado y recuento deseados de un servicio. Si se tienen que actualizar la opción de computación, la versión de la plataforma, los detalles del equilibrador de carga, la configuración de red o la definición de tarea, debe crear un nuevo conjunto de tareas.

La acción de la API `UpdateTaskSet` actualiza únicamente el parámetro de escala de un conjunto de tarea.

La acción de la API `UpdateServicePrimaryTaskSet` modifica qué conjunto de tareas de un servicio es el conjunto de tareas principal. Cuando llama a la acción de la API `DescribeServices`, devuelve todos los campos especificados para un conjunto de tareas principal. Si se actualiza el conjunto de tareas principal para un servicio, cualquier valor de parámetro del conjunto de tareas que exista en el nuevo conjunto de tareas principal que difieran del conjunto de tareas principal antiguo en un servicio se actualiza al nuevo valor cuando se define un nuevo conjunto de tareas principal. Si no se ha definido ningún conjunto de tareas principal para un servicio, al describir el servicio, los campos del conjunto de tareas son nulos.

## Consideraciones acerca de la implementación externa
<a name="deployment-type-external-considerations"></a>

Tenga en cuenta lo siguiente al utilizar el tipo de implementación externa:
+ Los tipos de balanceador de carga admitidos son balanceador de carga de aplicaciones o balanceador de carga de red.
+ Fargate o los tipos de controlador de implementación `EXTERNAL` no son compatibles con la estrategia de programación de `DAEMON`.
+ La integración del escalado automático de aplicaciones con Amazon ECS solo admite el servicio Amazon ECS como destino. La dimensión escalable admitida para Amazon ECS es `ecs:service:DesiredCount`, el recuento de tareas de un servicio de Amazon ECS. No existe una integración directa entre los conjuntos de tareas de escalado automático de aplicaciones y Amazon ECS. Los conjuntos de tareas de Amazon ECS calculan el `ComputedDesiredCount` en función del `DesiredCount` del servicio de Amazon ECS.

## Flujo de trabajo de implementación externa
<a name="deployment-type-external-workflow"></a>

A continuación, se muestra el flujo de trabajo básico para administrar una implementación externa en Amazon ECS.

**Para administrar un servicio de Amazon ECS mediante un controlador de implementación externo**

1. Creación de un servicio de Amazon ECS. El único parámetro obligatorio es el nombre de servicio. Puede especificar los siguientes parámetros al crear un servicio con un controlador de implementación externo. Todos los demás parámetros de servicio se especifican al crear un conjunto de tareas dentro del servicio.  
`serviceName`  
Tipo: cadena  
Obligatorio: sí  
El nombre de su servicio. Se admiten hasta 255 letras (mayúsculas y minúsculas), números, guiones y caracteres de subrayado. Los nombres de servicio deben ser únicos dentro de un clúster, pero puede tener servicios con el mismo nombre en varios clústeres dentro de una región o en varias regiones.  
`desiredCount`  
El número de instancias de la definición de tarea de conjunto de tareas especificada para colocar y seguir ejecutando en el servicio.  
`deploymentConfiguration`  
Parámetros de implementación opcionales que controlan cuántas tareas se ejecutan durante una implementación y la ordenación de tareas de parada e inicio.   
`tags`  
Tipo: matriz de objetos   
Obligatorio: no  
Los metadatos que se aplican al servicio para ayudarle a categorizarlas y organizarlas. Cada etiqueta está formada por una clave y un valor opcional, ambos definidos por el usuario. Cuando se elimina un servicio, también se eliminan las etiquetas. Se puede aplicar un máximo de 50 etiquetas al servicio. Para obtener más información, consulte [Etiquetado de los recursos de Amazon ECS](ecs-using-tags.md).  
Al actualizar un servicio, este parámetro no desencadena la implementación de un nuevo servicio.    
`key`  
Tipo: cadena  
Limitaciones de longitud: longitud mínima de 1. Longitud máxima de 128.  
Obligatorio: no  
Una parte de un par clave-valor que compone una etiqueta. Un clave es una etiqueta general que actúa como una categoría para valores de etiqueta más específicos.  
`value`  
Tipo: cadena  
Limitaciones de longitud: longitud mínima de 0. La longitud máxima es de 256 caracteres.  
Obligatorio: no  
La parte opcional de un par clave-valor que compone una etiqueta. Un valor actúa como un descriptor en una categoría de etiquetas (clave).  
`enableECSManagedTags`  
Especifica si se deben usar etiquetas administradas por Amazon ECS para las tareas dentro del servicio. Para obtener más información, consulte [Uso de etiquetas para facturación](ecs-using-tags.md#tag-resources-for-billing).  
`propagateTags`  
Tipo: cadena  
Valores válidos: `TASK_DEFINITION` \$1 `SERVICE`  
Obligatorio: no  
Especifica si se deben copiar las etiquetas de la definición de tareas o el servicio en las tareas del servicio. Si no se especifica ningún valor, las etiquetas no se copian. Solo se pueden copiar las etiquetas en las tareas del servicio durante la creación del servicio. Para agregar etiquetas a una tarea tras la creación del servicio, utilice la acción de la API `TagResource`.  
Al actualizar un servicio, este parámetro no desencadena la implementación de un nuevo servicio.  
`schedulingStrategy`  
La estrategia de programación que se va a utilizar. Los servicios que utilizan un controlador de implementación solo admiten la estrategia de programación `REPLICA`.  
`placementConstraints`  
Una matriz de objetos de restricción de colocación que utilizar para tareas en su servicio. Puede especificar 10 restricciones como máximo por tarea (este límite incluye restricciones en la definición de tareas y las especificadas en tiempo de ejecución). Si utiliza Fargate, no se admiten las restricciones de ubicación de tareas.  
`placementStrategy`  
Los objetos de estrategia colocación que utilizar para tareas en su servicio. Puede especificar un máximo de cuatro reglas de estrategia por servicio.

   A continuación, se muestra un ejemplo de definición de servicio para crear un servicio mediante un controlador de implementación externo.

   ```
   {
       "cluster": "",
       "serviceName": "",
       "desiredCount": 0,
       "role": "",
       "deploymentConfiguration": {
           "maximumPercent": 0,
           "minimumHealthyPercent": 0
       },
       "placementConstraints": [
           {
               "type": "distinctInstance",
               "expression": ""
           }
       ],
       "placementStrategy": [
           {
               "type": "binpack",
               "field": ""
           }
       ],
       "schedulingStrategy": "REPLICA",
       "deploymentController": {
           "type": "EXTERNAL"
       },
       "tags": [
           {
               "key": "",
               "value": ""
           }
       ],
       "enableECSManagedTags": true,
       "propagateTags": "TASK_DEFINITION"
   }
   ```

1. Crear un conjunto de tareas inicial. El conjunto de tareas contiene los siguientes detalles sobre el servicio:  
`taskDefinition`  
La definición de tareas en el conjunto de tareas que se va a utilizar.  
`launchType`  
Tipo: cadena  
Valores válidos: `EC2` \$1 `FARGATE` \$1 `EXTERNAL`  
Obligatorio: no  
El tipo de lanzamiento en el que ejecutar su servicio. Si no se especifica ningún tipo de lanzamiento, se usará `capacityProviderStrategy` de forma predeterminada.  
Al actualizar un servicio, este parámetro desencadena la implementación de un nuevo servicio.  
Si se especifica `launchType`, se debe omitir el parámetro `capacityProviderStrategy`.  
`platformVersion`  
Tipo: cadena  
Requerido: no  
La versión de la plataforma en la que se ejecutan sus tareas en el servicio. La versión de la plataforma solo se especifica para las tareas que utilizan el tipo de lanzamiento de Fargate. Si no se especifica ninguna, se usará la versión más reciente (`LATEST`) de forma predeterminada.  
Al actualizar un servicio, este parámetro desencadena la implementación de un nuevo servicio.  
AWSLas versiones de la plataforma de Fargate se utilizan para hacer referencia a un entorno en tiempo de ejecución específico para la infraestructura de tareas de Fargate. Cuando se especifica la versión de la plataforma `LATEST` al ejecutar una tarea o crear un servicio, se obtiene la versión más actual de la plataforma disponible para las tareas. Cuando se escala un servicio, esas tareas reciben la versión de la plataforma especificada en la implementación actual del servicio. Para obtener más información, consulte [Versiones de la plataforma Fargate para Amazon ECS](platform-fargate.md).  
No se especifican las versiones de la plataforma para las tareas que utilizan el tipo de lanzamiento de EC2.  
`loadBalancers`  
Un objeto de balanceador de carga que representa el balanceador de carga que utilizar con su servicio. Cuando se utiliza un controlador de implementación externo, solo se admiten Application Load Balancers y Network Load Balancers. Si utiliza un Application Load Balancer, solo se permite un grupo de destino del Application Load Balancer por conjunto de tareas.  
El siguiente fragmento muestra un objeto `loadBalancer` de ejemplo que se va a utilizar.  

   ```
   "loadBalancers": [
           {
               "targetGroupArn": "",
               "containerName": "",
               "containerPort": 0
           }
   ]
   ```
Al especificar un objeto `loadBalancer`, debe especificar un `targetGroupArn` y omitir los parámetros `loadBalancerName`.  
`networkConfiguration`  
La configuración de red del servicio. Este parámetro es necesario para definiciones de tareas que usan el modo de red `awsvpc` para recibir su propia interfaz de red elástica y no se admite para otros modos de red. Para obtener más información acerca de las redes para Fargate, consulte [Opciones de red de tareas de Amazon ECS para Fargate](fargate-task-networking.md).  
`serviceRegistries`  
Los detalles de los registros de detección de servicios que asignar a este servicio. Para obtener más información, consulte [Uso de la detección de servicios para conectar los servicios de Amazon ECS con nombres de DNS](service-discovery.md).  
`scale`  
Un porcentaje de punto flotante del número de tareas deseado que colocar y seguir ejecutando en el conjunto de tareas. El valor se especifica como un total de porcentaje del de un servicio `desiredCount`. Los valores aceptados son números entre 0 y 100.

   A continuación, se muestra un ejemplo JSON para crear un conjunto de tareas para un controlador de implementación externo.

   ```
   {
       "service": "",
       "cluster": "",
       "externalId": "",
       "taskDefinition": "",
       "networkConfiguration": {
           "awsvpcConfiguration": {
               "subnets": [
                   ""
               ],
               "securityGroups": [
                   ""
               ],
               "assignPublicIp": "DISABLED"
           }
       },
       "loadBalancers": [
           {
               "targetGroupArn": "",
               "containerName": "",
               "containerPort": 0
           }
       ],
       "serviceRegistries": [
           {
               "registryArn": "",
               "port": 0,
               "containerName": "",
               "containerPort": 0
           }
       ],
       "launchType": "EC2",
       "capacityProviderStrategy": [
           {
               "capacityProvider": "",
               "weight": 0,
               "base": 0
           }
       ],
       "platformVersion": "",
       "scale": {
           "value": null,
           "unit": "PERCENT"
       },
       "clientToken": ""
   }
   ```

1. Cuando es necesario cambiar el servicio, utilice la acción de la API `UpdateService`, `UpdateTaskSet` o `CreateTaskSet` en función de los parámetros que esté actualizando. Si ha creado un conjunto de tareas, utilice el parámetro `scale` para cada conjunto de tareas en un servicio para determinar cuántas tareas hay que mantener en ejecución en el servicio. Por ejemplo, si tiene un servicio que contiene `tasksetA` y crea un `tasksetB`, puede probar la validez de transición `tasksetB` antes de que desear pasar el tráfico de producción al mismo. Podría establecer el valor `scale` de ambos conjunto de tareas en `100` y cuando esté listo para pasar todo el tráfico de producción a `tasksetB`, podría actualizar el valor de `scale` de `tasksetA` a `0` para reducirlo.

# Implementaciones azul/verde de CodeDeploy para Amazon ECS
<a name="deployment-type-bluegreen"></a>

Le recomendamos que utilice la implementación azul/verde de Amazon ECS. Para obtener más información, consulte [Creación de una implementación azul/verde de Amazon ECS](deploy-blue-green-service.md).

El tipo de implementación *blue/green* utiliza el modelo de implementación blue/green controlado por CodeDeploy. Este tipo de implementación permite verificar una nueva implementación de un servicio antes de enviar el tráfico de producción a este. Para obtener más información, consulte [What Is CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) en la *Guía del usuario de AWS CodeDeploy*. Valide el estado de un servicio de Amazon ECS antes de la implementación.

Hay tres formas de desviar el tráfico en una implementación azul/verde:
+ **canario**: el tráfico se desvía en dos incrementos. Puede elegir opciones de valor controlado predefinidas que especifiquen el porcentaje de tráfico desviado al conjunto de tareas actualizado en el primer incremento y el intervalo, en minutos, antes de que el tráfico restante se desvíe en el segundo incremento.
+ **Lineal**: el tráfico se desvía en incrementos iguales con el mismo número de minutos entre incrementos. Puede elegir opciones lineales predefinidas que especifiquen el porcentaje de tráfico desviado en cada incremento y el número de minutos entre cada incremento.
+ **Todo a la vez**: todo el tráfico se desvía del conjunto de tareas original al conjunto de tareas actualizado a la vez.

A continuación, se indican los componentes de CodeDeploy que emplea Amazon ECS cuando un servicio utiliza el tipo de implementación blue/green:

**Aplicación CodeDeploy**  
Colección de recursos de CodeDeploy. Se compone de uno o varios grupos de implementación.

**Grupo de implementaciones de CodeDeploy**  
Configuración de la implementación. Consta de los elementos siguientes:  
+ Servicio y clúster de Amazon ECS
+ Información del grupo de destino del equilibrador de carga y del oyente
+ Estrategia de reversión de implementación
+ Configuración de redireccionamiento del tráfico
+ Configuración de terminación de revisión original
+ Configuración de implementación
+ Configuración de alarmas de CloudWatch que se pueden configurar para detener las implementaciones
+ Configuración de SNS o CloudWatch Events para notificaciones
Para obtener más información, consulte [Utilización de grupos de implementación](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html) en la *Guía del usuario de AWS CodeDeploy*.

**Configuración de implementación de CodeDeploy**  
Especifica de qué manera dirige CodeDeploy el tráfico de producción al conjunto de tareas de sustitución durante la implementación. La siguiente configuración de implementación lineal y de valor controlado predefinida está disponible. También puede crear implementaciones lineales y de valor controlado definidas personalizadas. Para obtener más información, consulte [Utilización de configuraciones de implementación](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html) en la *Guía del usuario de AWS CodeDeploy*.  
+ **CodeDeployDefault.ECSAllAtOnce**: desplaza todo el tráfico al contenedor de Amazon ECS actualizado de una vez.
+ **CodeDeployDefault.ecsLinear10PercentEvery1Minutes**: desplaza el 10 % del tráfico cada minuto hasta que se haya desplazado todo el tráfico.
+ **CodeDeployDefault.ecsLinear10PercentEvery3Minutes**: desplaza el 10 % del tráfico cada tres minutos hasta que se haya desplazado todo el tráfico.
+ **CodeDeployDefault.ECSCanary10Percent5Minutes**: desplaza el 10 % del tráfico en el primer incremento. El 90 por ciento restante se implementa cinco minutos más tarde.
+ **CodeDeployDefault.ECSCanary10Percent15Minutes**: desplaza el 10 % del tráfico en el primer incremento. El 90 por ciento restante se implementa 15 minutos más tarde.

**Revisión**  
Una revisión es el archivo de especificación de la aplicación CodeDeploy (archivo AppSpec). En el archivo AppSpec, debe especificar el ARN completo de la definición de la tarea, el contenedor y el puerto del conjunto de tareas de sustitución hacia donde debe dirigirse el tráfico cuando se crea una implementación nueva. El nombre del contenedor debe ser uno de los nombres de contenedor al que se hace referencia en la definición de tarea. Si la configuración de red o versión de la plataforma se ha actualizado en la definición del servicio, también debe especificar esos detalles en el archivo AppSpec. También puede especificar las funciones de Lambda que se deben ejecutar durante los eventos del ciclo de vida de la implementación. Las funciones de Lambda le permiten ejecutar pruebas y obtener métricas durante la implementación. Para obtener más información, consulte [Referencia del archivo AppSpec](https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-appspec-file.html) en la *Guía del usuario de AWS CodeDeploy*.

## Consideraciones
<a name="deployment-type-bluegreen-considerations"></a>

Tenga en cuenta lo siguiente al utilizar el tipo de implementación blue/green:
+ Cuando un servicio de Amazon ECS que utiliza el tipo de implementación blue/green se crea inicialmente, se crea un conjunto de tareas de Amazon ECS.
+ Debe configurar el servicio para que utilice un Application Load Balancer o un Network Load Balancer. A continuación se indican los requisitos del balanceador de carga:
  + Debe añadir un agente de escucha de producción al balanceador de carga, que se utiliza para dirigir el tráfico de producción.
  + Es posible añadir un agente de escucha de pruebe opcional al balanceador de carga, que se utiliza para dirigir el tráfico de prueba. Si especifica un agente de escucha de prueba, CodeDeploy dirige el tráfico de prueba al conjunto de tareas de sustitución durante una implementación.
  + Tanto los agentes de escucha de prueba como de producción deben pertenecer al mismo balanceador de carga.
  + Debe definir un grupo de destino para el balanceador de carga. El grupo de destino dirige el tráfico al conjunto de tareas original en un servicio a través del agente de escucha de producción.
  + Cuando se utiliza un Network Load Balancer, solo se admite la configuración de implementación `CodeDeployDefault.ECSAllAtOnce`.
+ Para los servicios configurados para que utilicen el escalado automático del servicio y el tipo de implementación “green/blue”, el escalado automático no se bloquea durante una implementación, pero la implementación puede fallar en algunas circunstancias. A continuación, se describe este comportamiento con más detalle.
  + Si un servicio está escalando y se inicia una implementación, se crea el conjunto de tareas “green” (verdes) y CodeDeploy esperará hasta una hora para que el conjunto de tareas verdes alcance el estado constante, y no cambiará el tráfico hasta que lo haga.
  + Si un servicio está en proceso de implementación “blue/green” y se produce un evento de escalado, el tráfico continuará cambiando durante 5 minutos. Si el servicio no alcanza el estado estable en 5 minutos, CodeDeploy detendrá la implementación y la marcará como fallida.
+ Las tareas que utilizan Fargate o los tipos de controlador de implementación `CODE_DEPLOY` no admiten la estrategia de programación de `DAEMON`.
+ Cuando crea inicialmente una aplicación y un grupo de implementaciones de CodeDeploy, debe especificar lo siguiente:
  + Debe definir dos grupos de destino para el balanceador de carga. Un grupo de destino debe ser el grupo de destino inicial que se definió para el balanceador de carga al crear el servicio de Amazon ECS. El único requisito del segundo grupo de destino es que no puede asociarse con un balanceador de carga diferente al utilizado por el servicio.
+ Cuando crea una implementación de CodeDeploy para un servicio de Amazon ECS, CodeDeploy crea un *conjunto de tareas de sustitución* (o un *conjunto de tareas “green” [verdes]*) en la implementación. Si ha agregado un agente de escucha de prueba al balanceador de carga, CodeDeploy dirige el tráfico de prueba al conjunto de tareas de sustitución. Esto es cuando puede ejecutar cualquier prueba de validación. A continuación, CodeDeploy redirige el tráfico de producción del conjunto de tareas original al conjunto de tareas de sustitución de acuerdo con la configuración de redireccionamiento del tráfico para el grupo de implementaciones.

## Permisos de IAM necesarios
<a name="deployment-type-bluegreen-IAM"></a>

Las implementaciones azul/verde son posibles gracias a la combinación de las API de Amazon ECS y CodeDeploy. Los usuarios deben tener los permisos adecuados para estos servicios antes de que puedan utilizar las implementaciones azul/verde de Amazon ECS desde la Consola de administración de AWS o los SDK de AWS CLI. 

Además de los permisos estándar de IAM para crear y actualizar servicios, Amazon ECS requiere los siguientes permisos. Estos permisos se agregaron a la política de IAM `AmazonECS_FullAccess`. Para obtener más información, consulte [AmazonECS\$1FullAccess](security-iam-awsmanpol.md#security-iam-awsmanpol-AmazonECS_FullAccess).
+ `codedeploy:CreateApplication`
+ `codedeploy:CreateDeployment`
+ `codedeploy:CreateDeploymentGroup`
+ `codedeploy:GetApplication`
+ `codedeploy:GetDeployment`
+ `codedeploy:GetDeploymentGroup`
+ `codedeploy:ListApplications`
+ `codedeploy:ListDeploymentGroups`
+ `codedeploy:ListDeployments`
+ `codedeploy:StopDeployment`
+ `codedeploy:GetDeploymentTarget`
+ `codedeploy:ListDeploymentTargets`
+ `codedeploy:GetDeploymentConfig`
+ `codedeploy:GetApplicationRevision`
+ `codedeploy:RegisterApplicationRevision`
+ `codedeploy:BatchGetApplicationRevisions`
+ `codedeploy:BatchGetDeploymentGroups`
+ `codedeploy:BatchGetDeployments`
+ `codedeploy:BatchGetApplications`
+ `codedeploy:ListApplicationRevisions`
+ `codedeploy:ListDeploymentConfigs`
+ `codedeploy:ContinueDeployment`
+ `sns:ListTopics`
+ `cloudwatch:DescribeAlarms`
+ `lambda:ListFunctions`

**nota**  
Además de los permisos estándar de Amazon ECS requeridos para ejecutar tareas y servicios, los usuarios también requieren permisos `iam:PassRole` para utilizar roles de IAM para las tareas.

CodeDeploy necesita permisos para llamar a las API de Amazon ECS, modificar Elastic Load Balancing, invocar funciones de Lambda y describir alarmas de CloudWatch, y permisos para modificar el recuento deseado del servicio en su nombre. Antes de crear un servicio de Amazon ECS que utilice el tipo de implementación “blue/green”, debe crear un rol de IAM (`ecsCodeDeployRole`). Para obtener más información, consulte [Rol de IAM de CodeDeploy de Amazon ECS](codedeploy_IAM_role.md).

# Migre las implementaciones azul/verde de CodeDeploy a las implementaciones azul/verde de Amazon ECS
<a name="migrate-codedeploy-to-ecs-bluegreen"></a>

Las implementaciones azul/verde de CodeDeploy y las implementaciones azul/verde de Amazon ECS ofrecen una funcionalidad similar, pero difieren en su configuración y administración.

## Descripción general de las implementaciones azul/verde de CodeDeploy
<a name="codedeploy-bluegreen-overview"></a>

Al crear un servicio de Amazon ECS mediante CodeDeploy, debe:

1. Crear un equilibrador de carga con un oyente de producción y (opcionalmente) un oyente de prueba. Cada oyente está configurado con una única regla (predeterminada) que enruta todo el tráfico a un único grupo de destino (el grupo de destino principal).

1. Crear un servicio de Amazon ECS, configurado para usar el oyente y el grupo de destino, con el tipo `deploymentController` establecido en `CODE_DEPLOY`. La creación del servicio da como resultado la creación de un conjunto de tareas (azul) registrado en el grupo de destino especificado.

1. Cree un grupo de implementación de CodeDeploy (como parte de una aplicación CodeDeploy) y configúrelo con detalles del clúster de Amazon ECS, el nombre del servicio, los oyentes del equilibrador de carga, dos grupos de destino (el grupo de destino principal utilizado en la regla de oyente de producción y un grupo de destino secundario que se utilizará para tareas de sustitución), un rol de servicio (para conceder permisos a CodeDeploy a fin de que pueda manipular los recursos de Amazon ECS y de Elastic Load Balancing) y varios parámetros que controlan el comportamiento de la implementación.

Con CodeDeploy, las nuevas versiones de un servicio se implementan mediante `CreateDeployment()`, especificando el nombre de la aplicación de CodeDeploy, el nombre del grupo de implementación y un archivo AppSpec que proporciona detalles de la nueva revisión y los enlaces de ciclo de vida opcionales. La implementación de CodeDeploy crea un conjunto de tareas de sustitución (verde) y registra sus tareas en el grupo de destino secundario. Cuando este recupere el buen estado, estará disponible para pruebas (opcional) y para producción. En ambos casos, el redireccionamiento se logra cambiando la regla de oyente correspondiente para que apunte al grupo de destino secundario asociado al conjunto de tareas verde. La reversión se logra haciendo que la regla de oyente de producción pase a ser la del grupo de destino principal.

## Descripción general de las implementaciones azul/verde de Amazon ECS
<a name="ecs-bluegreen-overview"></a>

En el caso de las implementaciones azul/verde de Amazon ECS, la configuración de implementación forma parte del propio servicio de Amazon ECS:

1. Debe preconfigurar el oyente de producción del equilibrador de carga con una regla que incluya dos grupos de destino con ponderaciones de 1 y 0.

1. Debe especificar los siguientes recursos o actualizar los recursos del servicio: 
   + El ARN de esta regla de oyente 
   + Los dos grupos de destino
   + Un rol de IAM para conceder a Amazon ECS permiso para llamar a las API de Elastic Load Balancing
   + Un rol de IAM opcional para ejecutar funciones de Lambda
   + Defina el tipo `deploymentController` en `ECS` y `deploymentConfiguration.strategy` en `BLUE_GREEN`. Esto da como resultado la creación de una implementación de servicio (azul) cuyas tareas se registran en el grupo de destino principal.

Con las implementaciones azul/verde de Amazon ECS, se crea una nueva revisión de servicio llamando a `UpdateService()` de Amazon ECS y pasando los detalles de la nueva revisión. La implementación del servicio crea nuevas tareas de revisión de servicio (verde) y las registra en el grupo de destino secundario. Amazon ECS administra las operaciones de redireccionamiento y reversión cambiando las ponderaciones de la regla de oyente.

## Diferencias de implementación claves
<a name="implementation-differences"></a>

Si bien ambos métodos dan como resultado la creación de un conjunto de tareas inicial, la implementación subyacente es diferente:
+ CodeDeploy utiliza un conjunto de tareas, mientras que Amazon ECS utiliza una revisión de servicio. Los conjuntos de tareas de Amazon ECS son un constructo antiguo que ha sido sustituido por las revisiones e implementaciones de servicios de Amazon ECS. Estas últimas ofrecen una mayor visibilidad del proceso de implementación, así como del historial de implementación y revisión de servicio.
+ Con CodeDeploy, los enlaces de ciclo de vida se especifican como parte del archivo AppSpec que se suministra a `CreateDeployment()`. Esto significa que los enlaces se pueden cambiar de una implementación a otra. Con las implementaciones azul/verde de Amazon ECS, los enlaces se especifican como parte de la configuración del servicio y cualquier actualización requerirá una llamada a `UpdateService()`.
+ Tanto las implementaciones azul/verde de CodeDeploy como las de Amazon ECS utilizan Lambda para la implementación de enlaces, pero las entradas y salidas esperadas son diferentes.

  Con CodeDeploy, la función debe llamar a `PutLifecycleEventHookExecutionStatus()` para devolver el estado del enlace, que puede ser `SUCCEEDED` o `FAILED`. Con Amazon ECS, la respuesta de Lambda se utiliza para indicar el estado del enlace.
+ CodeDeploy invoca cada enlace como una llamada única y espera que se devuelva el estado de ejecución final en una hora. Los enlaces de Amazon ECS son más flexibles, ya que pueden devolver un indicador `IN_PROGRESS`, lo que significa que el enlace debe volver a invocarse repetidamente hasta que dé como resultado `SUCCEEDED` o `FAILED`. Para obtener más información, consulte [Enlaces de ciclo de vida para las implementaciones de servicios de Amazon ECS](deployment-lifecycle-hooks.md).

## Enfoques de migración
<a name="migration-paths"></a>

Existen tres métodos principales para migrar de las implementaciones azul/verde de CodeDeploy a las implementaciones azul/verde de Amazon ECS. Cada método tiene características diferentes en términos de complejidad, riesgo, capacidad de reversión y posible tiempo de inactividad.

### Reutilice los mismos recursos de Elastic Load Balancing utilizados para CodeDeploy
<a name="inplace-update"></a>

Debe actualizar el servicio de Amazon ECS existente para utilizar el controlador de implementación de Amazon ECS con una estrategia de implementación azul/verde en lugar del controlador de implementación de CodeDeploy. Tenga en cuenta lo siguiente cuando utilice este método:
+ El procedimiento de migración es más sencillo porque está actualizando el controlador de implementación del servicio de Amazon ECS y la estrategia de implementación existentes.
+ Si se configura y migra correctamente, no hay tiempo de inactividad.
+ Una reversión requiere que se revierta la revisión de servicio.
+ El riesgo es alto porque no hay una configuración azul/verde paralela.

Utiliza el mismo oyente y los mismos grupos de destino del equilibrador de carga que se utilizan para CodeDeploy. Si está usando CloudFormation, consulta [Migración de una plantilla de implementación azul/verde de CodeDeploy de CloudFormation a una plantilla de CloudFormation azul/verde de Amazon ECS](migrate-codedeploy-to-ecs-bluegreen-cloudformation-template.md).

1. Modifique la regla predeterminada de los oyentes de producción o de prueba para incluir el grupo de destino alternativo y establezca la ponderación del grupo de destino principal en 1 y del grupo de destino alternativo en 0.

   En el caso de CodeDeploy, los oyentes del equilibrador de carga adjunto al servicio se configuran con una sola regla (predeterminada) que enruta todo el tráfico a un único grupo de destino. En el caso de Amazon ECS (azul/verde), los oyentes del equilibrador de carga deben estar preconfigurados con una regla que incluya los dos grupos de destino con ponderaciones. El grupo de destino principal debe tener una ponderación de 1, y el grupo de destino alternativo debe tener una ponderación de 0.

1. Actualice el servicio de Amazon ECS existente llamando a la API `UpdateService` y configurando el parámetro `deploymentController` en `ECS` y el parámetro `deploymentStrategy` en `BLUE_GREEN`. Especifique los ARN del grupo de destino, el grupo de destino alternativo, el oyente de producción y un oyente de prueba opcional.

1. Compruebe que el servicio funciona según lo previsto.

1. Elimine la configuración de CodeDeploy para este servicio de Amazon ECS, ya que ahora utiliza implementaciones azul/verde de Amazon ECS.

### Servicio nuevo con un equilibrador de carga existente
<a name="new-service-existing-lb"></a>

Este método utiliza la estrategia azul/verde para la migración. 

Tenga en cuenta lo siguiente cuando utilice este método:
+ La interrupción es mínima. Solo se produce durante el intercambio de puertos de Elastic Load Balancing.
+ Una reversión requiere que restituya el intercambio de puertos de Elastic Load Balancing.
+ El riesgo es bajo porque hay configuraciones en paralelo. Por lo tanto, puede realizar la prueba antes de la transferencia de tráfico.

1. Deje intactos los oyentes, los grupos de destino y el servicio de Amazon ECS para la configuración de CodeDeploy a fin de que pueda revertirse fácilmente a esta configuración si es necesario.

1. Cree nuevos grupos de destino y nuevos oyentes (con puertos diferentes a los de los oyentes originales) en el equilibrador de carga existente. A continuación, cree un nuevo servicio de Amazon ECS que coincida con el servicio de Amazon ECS existente, excepto si utiliza `ECS` como controlador de implementación, `BLUE_GREEN` como estrategia de implementación, y pase los ARN a los nuevos grupos de destino y las nuevas reglas de oyente.

1. Verifique la nueva configuración enviando manualmente el tráfico HTTP al servicio. Si todo va bien, cambie los puertos de los oyentes originales por los de los nuevos para enrutar el tráfico a la nueva configuración.

1. Compruebe la nueva configuración y, si todo sigue funcionando según lo previsto, elimine la configuración de CodeDeploy.

### Servicio nuevo con un nuevo equilibrador de carga
<a name="new-service-new-lb"></a>

Al igual que el método anterior, este utiliza la estrategia azul/verde para la migración. La diferencia clave es que el cambio de la configuración de CodeDeploy a la configuración azul/verde de Amazon ECS se produce en una capa de proxy inversa por encima del equilibrador de carga. Algunos ejemplos de implementaciones para la capa de proxy inverso son Route 53 y CloudFront.

Este método es adecuado para los clientes que ya disponen de esta capa de proxy inverso y si toda la comunicación con el servicio se realiza a través de ella (por ejemplo, si no hay comunicación directa a nivel del equilibrador de carga).

Tenga en cuenta lo siguiente cuando utilice este método:
+ Esto requiere una capa de proxy inversa.
+ El procedimiento de migración es más complejo porque es necesario actualizar el controlador de implementación del servicio de Amazon ECS y la estrategia de implementación existentes.
+ La interrupción es mínima. Solo se produce durante el intercambio de puertos de Elastic Load Balancing.
+ Una reversión requiere que se reviertan los cambios en la configuración del proxy.
+ El riesgo es bajo porque hay configuraciones en paralelo. Por lo tanto, puede realizar la prueba antes de la transferencia de tráfico.

1. No modifique la configuración de CodeDeploy existente intacta (equilibrador de carga, oyentes, grupos de destino, servicio de Amazon ECS y grupo de implementación de CodeDeploy).

1. Cree un nuevo equilibrador de carga, grupos de destino y oyentes configurados para implementaciones azul/verde de Amazon ECS.

   Configure los recursos adecuados.
   + Equilibrador de carga de aplicación: para más información, consulte [Recursos de equilibrador de carga de aplicación para las implementaciones azul/verde, las implementaciones lineales y las implementaciones canario](alb-resources-for-blue-green.md).
   + Equilibrador de carga de red: para más información, consulte [Recursos de Equilibrador de carga de red para las implementaciones azul/verde, las implementaciones lineales y las implementaciones canario de Amazon ECS](nlb-resources-for-blue-green.md).

1. Cree un nuevo servicio con `ECS` como controlador de implementación y `BLUE_GREEN` como estrategia de implementación, apuntando a los nuevos recursos del equilibrador de carga.

1. Verifique la nueva configuración probándola con el nuevo equilibrador de carga.

1. Actualice la configuración del proxy inverso para enrutar el tráfico al nuevo equilibrador de carga.

1. Observe la nueva revisión de servicio y, si todo sigue funcionando según lo esperado, elimine la configuración de CodeDeploy.

## Siguientes pasos
<a name="post-migration-considerations"></a>

Después de migrar a las implementaciones azul/verde de Amazon ECS:
+ Actualice los scripts de implementación y las canalizaciones de CI/CD para usar la API `UpdateService` de Amazon ECS en lugar de la API `CreateDeployment` de CodeDeploy.
+ Actualice el monitoreo y las alertas para realizar un seguimiento de las implementaciones del servicio de Amazon ECS en lugar de las implementaciones de CodeDeploy.
+ Considere la posibilidad de implementar pruebas automatizadas de su nuevo proceso de implementación para asegurarse de que funciona según lo esperado.

# Migración de una implementación azul/verde de CodeDeploy a una implementación de servicio azul/verde de Amazon ECS
<a name="migrate-code-deploy-to-ecs-blue-green"></a>

 Con las implementaciones azul/verde de Amazon ECS, puede realizar y comprobar cambios en el servicio antes de implementarlos en un entorno de producción. 

Debe crear nuevos enlaces de ciclo de vida para su implementación azul/verde de Amazon ECS.

## Requisitos previos
<a name="migrate-code-deploy-to-ecs-blue-green-prerequisites"></a>

Realice las siguientes operaciones antes de iniciar una implementación azul/verde.

1. Sustituya el rol de IAM de CodeDeploy de Amazon ECS por los siguientes permisos.
   + Para obtener información sobre los permisos de Elastic Load Balancing, consulte [Rol de IAM de infraestructura de Amazon ECS para los equilibradores de carga](AmazonECSInfrastructureRolePolicyForLoadBalancers.md).
   + Para obtener información acerca de los permisos de Lambda, consulte [Permisos necesarios para las funciones de Lambda en las implementaciones azul/verde de Amazon ECS](blue-green-permissions.md).

1. Desactive la automatización de CodeDeploy. Para más información, consulte [Working with deployment groups in CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html) en la *Guía del usuario de CodeDeploy*. 

1. Asegúrese de disponer de la siguiente información de su implementación azul/verde de CodeDeploy. Puede reutilizar esta información para la implementación azul/verde de Amazon ECS:
   + El grupo de destino de producción
   + El oyente de producción
   + La regla de producción
   + El grupo de destino de prueba

     Este es el grupo de destino de la revisión de servicio verde,

1. Asegúrese de que los grupos de destino del equilibrador de carga de aplicación estén asociados correctamente a las reglas de oyente:
   + Si no utiliza oyentes de prueba, ambos grupos de destino (de producción y de prueba) deben estar asociados a las reglas de oyente de producción.
   + Si utiliza oyentes de prueba, un grupo de destino debe estar vinculado a las reglas de oyente de producción y el otro grupo de destino debe estar vinculado a las reglas de oyente de prueba.

   Si no se cumple este requisito, la implementación del servicio fallará y se generará el siguiente error: `Service deployment rolled back because of invalid networking configuration. Both targetGroup and alternateTargetGroup must be associated with the productionListenerRule or testListenerRule.`

1. Compruebe que no haya implementaciones de servicio en curso para el servicio. Para obtener más información, consulte [Visualización del historial de servicios mediante las implementaciones de servicios de Amazon ECS](service-deployment.md).

1. Las implementaciones azul/verde de Amazon ECS requieren que su servicio utilice una de las siguientes características: configure los recursos adecuados.
   + Equilibrador de carga de aplicación: para más información, consulte [Recursos de equilibrador de carga de aplicación para las implementaciones azul/verde, las implementaciones lineales y las implementaciones canario](alb-resources-for-blue-green.md).
   + Equilibrador de carga de red: para más información, consulte [Recursos de Equilibrador de carga de red para las implementaciones azul/verde, las implementaciones lineales y las implementaciones canario de Amazon ECS](nlb-resources-for-blue-green.md).
   + Service Connect: para más información, consulte [Recursos de Service Connect para las implementaciones azul/verde, las implementaciones lineales y las implementaciones canario de Amazon ECS](service-connect-blue-green.md).

1. Decida si desea ejecutar funciones de Lambda para las etapas del ciclo de vida de la implementación azul/verde de Amazon ECS.
   + Antes de escalar verticalmente
   + Después de escalar verticalmente
   + Transferencia de tráfico de prueba
   + Después de la transferencia de tráfico de prueba
   + Transferencia de tráfico de producción
   + Después de la transferencia de tráfico de producción

   Cree funciones de Lambda para cada etapa del ciclo de vida. Para más información, consulte [Cree una función de Lambda con la consola](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html#getting-started-create-function) en la *Guía para desarrolladores de AWS Lambda*.

Para más información sobre la actualización de un controlador de implementación de un servicio, consulte [Actualización de los parámetros de servicio de Amazon ECS](update-service-parameters.md).

## Procedimiento
<a name="migrate-code-deploy-to-ecs-procedure"></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.

   Aparecerá la página de detalles del clúster.

1. En la pestaña **Servicios**, elija el servicio.

   Aparecerá la página de detalles del servicio.

1. En el encabezado, seleccione **Actualizar el tipo de controlador de implementación**.

   Aparecerá la página **Migrar tipo de controlador de implementación**.

1. Expanda **Nuevo** y, a continuación, especifique los siguientes parámetros.

   1. En **Tipo de controlador de implementación**, elija **ECS**.

   1. En **Estrategia de implementación**, seleccione **Azul/verde**.

   1. En **Tiempo de incorporación**, introduzca la hora a la que se ejecutan las revisiones de servicio azul y verde.

   1. Para ejecutar las funciones de Lambda en una etapa del ciclo de vida, en **Enlaces de ciclo de vida de la implementación**, haga lo siguiente para cada función de Lambda única:

      1. Elija **Agregar**.

         Repita este procedimiento para cada función única que desee ejecutar.

      1. En **Función de Lambda**, ingrese el nombre de la función.

      1. En **Rol**, elija el rol que creó en los requisitos previos con los permisos azul/verde.

         Para obtener más información, consulte [Permisos necesarios para las funciones de Lambda en las implementaciones azul/verde de Amazon ECS](blue-green-permissions.md).

      1. En **Etapas del ciclo de vida**, seleccione las etapas que ejecuta la función de Lambda.

      1.  (Opcional) En **Detalles del enlace**, introduzca un par clave-valor que proporcione información sobre el enlace.

1. Expanda **Equilibrio de carga** y, a continuación, configure lo siguiente:

   1. En **Rol**, elija el rol que creó en los requisitos previos con los permisos azul/verde.

      Para obtener más información, consulte [Permisos necesarios para las funciones de Lambda en las implementaciones azul/verde de Amazon ECS](blue-green-permissions.md).

   1. En **Oyente**, elija el oyente de producción de su implementación azul/verde de CodeDeploy.

   1. En **Regla de producción**, elija la regla de producción de su implementación azul/verde de CodeDeploy.

   1. En **Regla de prueba**, elija la regla de prueba de su implementación azul/verde de CodeDeploy.

   1. En **Grupo de destino**, elija el grupo de destino de producción de su implementación azul/verde de CodeDeploy.

   1. En **Grupo de destino alternativo**, elija el grupo de destino de prueba de su implementación azul/verde de CodeDeploy.

1. Elija **Actualizar**.

## Siguientes pasos
<a name="migrate-code-deploy-to-ecs-blue-green-next-steps"></a>
+ Actualice el servicio para iniciar la implementación. Para obtener más información, consulte [Actualización de un servicio de Amazon ECS](update-service-console-v2.md).
+ Monitoree el proceso de implementación para asegurarse de que sigue el patrón azul/verde:
  + Se crea y escala verticalmente la revisión de servicio verde
  + El tráfico de prueba se enruta a la revisión verde (si está configurada)
  + El tráfico de producción se transfiere a la revisión verde
  + Transcurrido el tiempo de incorporación, la revisión azul finaliza

# Migración de una plantilla de implementación azul/verde de CodeDeploy de CloudFormation a una plantilla de CloudFormation azul/verde de Amazon ECS
<a name="migrate-codedeploy-to-ecs-bluegreen-cloudformation-template"></a>

Migre una plantilla de CloudFormation que utilice las implementaciones azul/verde de CodeDeploy para los servicios de Amazon ECS a una que utilice la estrategia de implementación azul/verde nativa de Amazon ECS. La migración sigue el método “Reutilizar los mismos recursos de Elastic Load Balancing utilizados para CodeDeploy”. Para obtener más información, consulte [Migre las implementaciones azul/verde de CodeDeploy a las implementaciones azul/verde de Amazon ECS](migrate-codedeploy-to-ecs-bluegreen.md).

## Plantilla de origen
<a name="source-template"></a>

Esta plantilla utiliza la transformación `AWS::CodeDeployBlueGreen` y el enlace `AWS::CodeDeploy::BlueGreen` para poner en marcha implementaciones azul/verde para un servicio de Amazon ECS.

### Origen
<a name="code-deploy-source"></a>

Esta es la plantilla de CloudFormation completa que utiliza la implementación azul/verde de CodeDeploy. Para obtener más información, consulte el [ejemplo de plantilla de implementación azul/verde](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/blue-green-template-example.html#blue-green-template-example.json) en la *Guía del usuario de AWS CloudFormation*:

```
{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Parameters": {
    "Vpc": {
      "Type": "AWS::EC2::VPC::Id"
    },
    "Subnet1": {
      "Type": "AWS::EC2::Subnet::Id"
    },
    "Subnet2": {
      "Type": "AWS::EC2::Subnet::Id"
    }
  },
  "Transform": [
    "AWS::CodeDeployBlueGreen"
  ],
  "Hooks": {
    "CodeDeployBlueGreenHook": {
      "Type": "AWS::CodeDeploy::BlueGreen",
      "Properties": {
        "TrafficRoutingConfig": {
          "Type": "TimeBasedCanary",
          "TimeBasedCanary": {
            "StepPercentage": 15,
            "BakeTimeMins": 5
          }
        },
        "Applications": [
          {
            "Target": {
              "Type": "AWS::ECS::Service",
              "LogicalID": "ECSDemoService"
            },
            "ECSAttributes": {
              "TaskDefinitions": [
                "BlueTaskDefinition",
                "GreenTaskDefinition"
              ],
              "TaskSets": [
                "BlueTaskSet",
                "GreenTaskSet"
              ],
              "TrafficRouting": {
                "ProdTrafficRoute": {
                  "Type": "AWS::ElasticLoadBalancingV2::Listener",
                  "LogicalID": "ALBListenerProdTraffic"
                },
                "TargetGroups": [
                  "ALBTargetGroupBlue",
                  "ALBTargetGroupGreen"
                ]
              }
            }
          }
        ]
      }
    }
  },
  "Resources": {
    "ExampleSecurityGroup": {
      "Type": "AWS::EC2::SecurityGroup",
      "Properties": {
        "GroupDescription": "Security group for ec2 access",
        "VpcId": {"Ref": "Vpc"},
        "SecurityGroupIngress": [
          {
            "IpProtocol": "tcp",
            "FromPort": 80,
            "ToPort": 80,
            "CidrIp": "0.0.0.0/0"
          },
          {
            "IpProtocol": "tcp",
            "FromPort": 8080,
            "ToPort": 8080,
            "CidrIp": "0.0.0.0/0"
          },
          {
            "IpProtocol": "tcp",
            "FromPort": 22,
            "ToPort": 22,
            "CidrIp": "0.0.0.0/0"
          }
        ]
      }
    },
    "ALBTargetGroupBlue": {
      "Type": "AWS::ElasticLoadBalancingV2::TargetGroup",
      "Properties": {
        "HealthCheckIntervalSeconds": 5,
        "HealthCheckPath": "/",
        "HealthCheckPort": "80",
        "HealthCheckProtocol": "HTTP",
        "HealthCheckTimeoutSeconds": 2,
        "HealthyThresholdCount": 2,
        "Matcher": {
          "HttpCode": "200"
        },
        "Port": 80,
        "Protocol": "HTTP",
        "Tags": [
          {
            "Key": "Group",
            "Value": "Example"
          }
        ],
        "TargetType": "ip",
        "UnhealthyThresholdCount": 4,
        "VpcId": {"Ref": "Vpc"}
      }
    },
    "ALBTargetGroupGreen": {
      "Type": "AWS::ElasticLoadBalancingV2::TargetGroup",
      "Properties": {
        "HealthCheckIntervalSeconds": 5,
        "HealthCheckPath": "/",
        "HealthCheckPort": "80",
        "HealthCheckProtocol": "HTTP",
        "HealthCheckTimeoutSeconds": 2,
        "HealthyThresholdCount": 2,
        "Matcher": {
          "HttpCode": "200"
        },
        "Port": 80,
        "Protocol": "HTTP",
        "Tags": [
          {
            "Key": "Group",
            "Value": "Example"
          }
        ],
        "TargetType": "ip",
        "UnhealthyThresholdCount": 4,
        "VpcId": {"Ref": "Vpc"}
      }
    },
    "ExampleALB": {
      "Type": "AWS::ElasticLoadBalancingV2::LoadBalancer",
      "Properties": {
        "Scheme": "internet-facing",
        "SecurityGroups": [
          {"Ref": "ExampleSecurityGroup"}
        ],
        "Subnets": [
          {"Ref": "Subnet1"},
          {"Ref": "Subnet2"}
        ],
        "Tags": [
          {
            "Key": "Group",
            "Value": "Example"
          }
        ],
        "Type": "application",
        "IpAddressType": "ipv4"
      }
    },
    "ALBListenerProdTraffic": {
      "Type": "AWS::ElasticLoadBalancingV2::Listener",
      "Properties": {
        "DefaultActions": [
          {
            "Type": "forward",
            "ForwardConfig": {
              "TargetGroups": [
                {
                  "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
                  "Weight": 1
                }
              ]
            }
          }
        ],
        "LoadBalancerArn": {"Ref": "ExampleALB"},
        "Port": 80,
        "Protocol": "HTTP"
      }
    },
    "ALBListenerProdRule": {
      "Type": "AWS::ElasticLoadBalancingV2::ListenerRule",
      "Properties": {
        "Actions": [
          {
            "Type": "forward",
            "ForwardConfig": {
              "TargetGroups": [
                {
                  "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
                  "Weight": 1
                }
              ]
            }
          }
        ],
        "Conditions": [
          {
            "Field": "http-header",
            "HttpHeaderConfig": {
              "HttpHeaderName": "User-Agent",
              "Values": [
                "Mozilla"
              ]
            }
          }
        ],
        "ListenerArn": {"Ref": "ALBListenerProdTraffic"},
        "Priority": 1
      }
    },
    "ECSTaskExecutionRole": {
      "Type": "AWS::IAM::Role",
      "Properties": {
        "AssumeRolePolicyDocument": {
          "Version": "2012-10-17",		 	 	 
          "Statement": [
            {
              "Sid": "",
              "Effect": "Allow",
              "Principal": {
                "Service": "ecs-tasks.amazonaws.com"
              },
              "Action": "sts:AssumeRole"
            }
          ]
        },
        "ManagedPolicyArns": [
          "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
        ]
      }
    },
    "BlueTaskDefinition": {
      "Type": "AWS::ECS::TaskDefinition",
      "Properties": {
        "ExecutionRoleArn": {"Fn::GetAtt": ["ECSTaskExecutionRole", "Arn"]},
        "ContainerDefinitions": [
          {
            "Name": "DemoApp",
            "Image": "nginxdemos/hello:latest",
            "Essential": true,
            "PortMappings": [
              {
                "HostPort": 80,
                "Protocol": "tcp",
                "ContainerPort": 80
              }
            ]
          }
        ],
        "RequiresCompatibilities": [
          "FARGATE"
        ],
        "NetworkMode": "awsvpc",
        "Cpu": "256",
        "Memory": "512",
        "Family": "ecs-demo"
      }
    },
    "ECSDemoCluster": {
      "Type": "AWS::ECS::Cluster",
      "Properties": {}
    },
    "ECSDemoService": {
      "Type": "AWS::ECS::Service",
      "Properties": {
        "Cluster": {"Ref": "ECSDemoCluster"},
        "DesiredCount": 1,
        "DeploymentController": {
          "Type": "EXTERNAL"
        }
      }
    },
    "BlueTaskSet": {
      "Type": "AWS::ECS::TaskSet",
      "Properties": {
        "Cluster": {"Ref": "ECSDemoCluster"},
        "LaunchType": "FARGATE",
        "NetworkConfiguration": {
          "AwsVpcConfiguration": {
            "AssignPublicIp": "ENABLED",
            "SecurityGroups": [
              {"Ref": "ExampleSecurityGroup"}
            ],
            "Subnets": [
              {"Ref": "Subnet1"},
              {"Ref": "Subnet2"}
            ]
          }
        },
        "PlatformVersion": "1.4.0",
        "Scale": {
          "Unit": "PERCENT",
          "Value": 100
        },
        "Service": {"Ref": "ECSDemoService"},
        "TaskDefinition": {"Ref": "BlueTaskDefinition"},
        "LoadBalancers": [
          {
            "ContainerName": "DemoApp",
            "ContainerPort": 80,
            "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"}
          }
        ]
      }
    },
    "PrimaryTaskSet": {
      "Type": "AWS::ECS::PrimaryTaskSet",
      "Properties": {
        "Cluster": {"Ref": "ECSDemoCluster"},
        "Service": {"Ref": "ECSDemoService"},
        "TaskSetId": {"Fn::GetAtt": ["BlueTaskSet", "Id"]}
      }
    }
  }
}
```

## Pasos para realizar la migración
<a name="migration-steps"></a>

### Eliminación de recursos específicos de CodeDeploy
<a name="remove-codedeploy-resources"></a>

Ya no necesita las siguientes propiedades:
+ La transformación `AWS::CodeDeployBlueGreen`
+ El enlace `CodeDeployBlueGreenHook`
+ Los recursos `GreenTaskDefinition` y `GreenTaskSet` (los administrará Amazon ECS)
+ El recurso `PrimaryTaskSet` (Amazon ECS administrará los conjuntos de tareas internamente)

### Reconfiguración del oyente del equilibrador de carga
<a name="reconfigure-load-balancer"></a>

Modifique el recurso `ALBListenerProdTraffic` para utilizar una acción de remisión con dos grupos de destino:

```
{
  "DefaultActions": [
    {
      "Type": "forward",
      "ForwardConfig": {
        "TargetGroups": [
          {
            "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
            "Weight": 1
          },
          {
            "TargetGroupArn": {"Ref": "ALBTargetGroupGreen"},
            "Weight": 0
          }
        ]
      }
    }
  ]
}
```

### Actualización de las propiedades de implementación
<a name="update-ecs-service"></a>

Actualice y agregue lo siguiente:
+ Cambie la propiedad `DeploymentController` de `EXTERNAL` a `ECS`.
+ Agregue la propiedad `Strategy` y establézcala en BLUE\$1GREEN.
+ Agregue la propiedad `BakeTimeInMinutes`.

  ```
  {
    "DeploymentConfiguration": {
      "MaximumPercent": 200,
      "MinimumHealthyPercent": 100,
      "DeploymentCircuitBreaker": {
        "Enable": true,
        "Rollback": true
      },
      "BakeTimeInMinutes": 5,
      "Strategy": "BLUE_GREEN"
    }
  }
  ```
+ Agregue la configuración del equilibrador de carga al servicio:

  ```
  {
    "LoadBalancers": [
      {
        "ContainerName": "DemoApp",
        "ContainerPort": 80,
        "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
        "AdvancedConfiguration": {
          "AlternateTargetGroupArn": {"Ref": "ALBTargetGroupGreen"},
          "ProductionListenerRule": {"Ref": "ALBListenerProdRule"},
          "RoleArn": {"Fn::GetAtt": ["ECSInfrastructureRoleForLoadBalancers", "Arn"]}
        }
      }
    ]
  }
  ```
+ Agregue la referencia de definición de tareas al servicio:

  ```
  {
    "TaskDefinition": {"Ref": "BlueTaskDefinition"}
  }
  ```

### Creación del rol AmazonECSInfrastructureRolePolicyForLoadBalancers
<a name="create-ecs-service-role"></a>

Agregue un nuevo rol de IAM que permita que Amazon ECS administre los recursos del equilibrador de carga. Para obtener más información, consulte [Rol de IAM de infraestructura de Amazon ECS para los equilibradores de carga](AmazonECSInfrastructureRolePolicyForLoadBalancers.md)

## Comprobación de recomendaciones
<a name="testing-recommendations"></a>

1. Implemente la plantilla migrada en un entorno que no sea de producción.

1. Compruebe que el servicio se implementa correctamente con la configuración inicial.

1. Compruebe una implementación actualizando la definición de la tarea y observando el proceso de implementación azul/verde.

1. Compruebe que el tráfico se transfiere correctamente entre las implementaciones azul y verde.

1. Para probar la funcionalidad de reversión, fuerce un error en la implementación.

## Plantilla posterior a la migración
<a name="migrated-template"></a>

### Plantilla final
<a name="ecs-bluegreen-template"></a>

Esta es la plantilla de CloudFormation completa que utiliza la implementación azul/verde de Amazon ECS:

```
{
  "AWSTemplateFormatVersion": "2010-09-09",
  "Parameters": {
    "Vpc": {
      "Type": "AWS::EC2::VPC::Id"
    },
    "Subnet1": {
      "Type": "AWS::EC2::Subnet::Id"
    },
    "Subnet2": {
      "Type": "AWS::EC2::Subnet::Id"
    }
  },
  "Resources": {
    "ExampleSecurityGroup": {
      "Type": "AWS::EC2::SecurityGroup",
      "Properties": {
        "GroupDescription": "Security group for ec2 access",
        "VpcId": {"Ref": "Vpc"},
        "SecurityGroupIngress": [
          {
            "IpProtocol": "tcp",
            "FromPort": 80,
            "ToPort": 80,
            "CidrIp": "0.0.0.0/0"
          },
          {
            "IpProtocol": "tcp",
            "FromPort": 8080,
            "ToPort": 8080,
            "CidrIp": "0.0.0.0/0"
          },
          {
            "IpProtocol": "tcp",
            "FromPort": 22,
            "ToPort": 22,
            "CidrIp": "0.0.0.0/0"
          }
        ]
      }
    },
    "ALBTargetGroupBlue": {
      "Type": "AWS::ElasticLoadBalancingV2::TargetGroup",
      "Properties": {
        "HealthCheckIntervalSeconds": 5,
        "HealthCheckPath": "/",
        "HealthCheckPort": "80",
        "HealthCheckProtocol": "HTTP",
        "HealthCheckTimeoutSeconds": 2,
        "HealthyThresholdCount": 2,
        "Matcher": {
          "HttpCode": "200"
        },
        "Port": 80,
        "Protocol": "HTTP",
        "Tags": [
          {
            "Key": "Group",
            "Value": "Example"
          }
        ],
        "TargetType": "ip",
        "UnhealthyThresholdCount": 4,
        "VpcId": {"Ref": "Vpc"}
      }
    },
    "ALBTargetGroupGreen": {
      "Type": "AWS::ElasticLoadBalancingV2::TargetGroup",
      "Properties": {
        "HealthCheckIntervalSeconds": 5,
        "HealthCheckPath": "/",
        "HealthCheckPort": "80",
        "HealthCheckProtocol": "HTTP",
        "HealthCheckTimeoutSeconds": 2,
        "HealthyThresholdCount": 2,
        "Matcher": {
          "HttpCode": "200"
        },
        "Port": 80,
        "Protocol": "HTTP",
        "Tags": [
          {
            "Key": "Group",
            "Value": "Example"
          }
        ],
        "TargetType": "ip",
        "UnhealthyThresholdCount": 4,
        "VpcId": {"Ref": "Vpc"}
      }
    },
    "ExampleALB": {
      "Type": "AWS::ElasticLoadBalancingV2::LoadBalancer",
      "Properties": {
        "Scheme": "internet-facing",
        "SecurityGroups": [
          {"Ref": "ExampleSecurityGroup"}
        ],
        "Subnets": [
          {"Ref": "Subnet1"},
          {"Ref": "Subnet2"}
        ],
        "Tags": [
          {
            "Key": "Group",
            "Value": "Example"
          }
        ],
        "Type": "application",
        "IpAddressType": "ipv4"
      }
    },
    "ALBListenerProdTraffic": {
      "Type": "AWS::ElasticLoadBalancingV2::Listener",
      "Properties": {
        "DefaultActions": [
          {
            "Type": "forward",
            "ForwardConfig": {
              "TargetGroups": [
                {
                  "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
                  "Weight": 1
                },
                {
                  "TargetGroupArn": {"Ref": "ALBTargetGroupGreen"},
                  "Weight": 0
                }
              ]
            }
          }
        ],
        "LoadBalancerArn": {"Ref": "ExampleALB"},
        "Port": 80,
        "Protocol": "HTTP"
      }
    },
    "ALBListenerProdRule": {
      "Type": "AWS::ElasticLoadBalancingV2::ListenerRule",
      "Properties": {
        "Actions": [
          {
            "Type": "forward",
            "ForwardConfig": {
              "TargetGroups": [
                {
                  "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
                  "Weight": 1
                },
                {
                  "TargetGroupArn": {"Ref": "ALBTargetGroupGreen"},
                  "Weight": 0
                }
              ]
            }
          }
        ],
        "Conditions": [
          {
            "Field": "http-header",
            "HttpHeaderConfig": {
              "HttpHeaderName": "User-Agent",
              "Values": [
                "Mozilla"
              ]
            }
          }
        ],
        "ListenerArn": {"Ref": "ALBListenerProdTraffic"},
        "Priority": 1
      }
    },
    "ECSTaskExecutionRole": {
      "Type": "AWS::IAM::Role",
      "Properties": {
        "AssumeRolePolicyDocument": {
          "Version": "2012-10-17",		 	 	 
          "Statement": [
            {
              "Sid": "",
              "Effect": "Allow",
              "Principal": {
                "Service": "ecs-tasks.amazonaws.com"
              },
              "Action": "sts:AssumeRole"
            }
          ]
        },
        "ManagedPolicyArns": [
          "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
        ]
      }
    },
    "ECSInfrastructureRoleForLoadBalancers": {
      "Type": "AWS::IAM::Role",
      "Properties": {
        "AssumeRolePolicyDocument": {
          "Version": "2012-10-17",		 	 	 
          "Statement": [
            {
              "Sid": "AllowAccessToECSForInfrastructureManagement",
              "Effect": "Allow",
              "Principal": {
                "Service": "ecs.amazonaws.com"
              },
              "Action": "sts:AssumeRole"
            }
          ]
        },
        "ManagedPolicyArns": [
          "arn:aws:iam::aws:policy/AmazonECSInfrastructureRolePolicyForLoadBalancers"
        ]
      }
    },
    "BlueTaskDefinition": {
      "Type": "AWS::ECS::TaskDefinition",
      "Properties": {
        "ExecutionRoleArn": {"Fn::GetAtt": ["ECSTaskExecutionRole", "Arn"]},
        "ContainerDefinitions": [
          {
            "Name": "DemoApp",
            "Image": "nginxdemos/hello:latest",
            "Essential": true,
            "PortMappings": [
              {
                "HostPort": 80,
                "Protocol": "tcp",
                "ContainerPort": 80
              }
            ]
          }
        ],
        "RequiresCompatibilities": [
          "FARGATE"
        ],
        "NetworkMode": "awsvpc",
        "Cpu": "256",
        "Memory": "512",
        "Family": "ecs-demo"
      }
    },
    "ECSDemoCluster": {
      "Type": "AWS::ECS::Cluster",
      "Properties": {}
    },
    "ECSDemoService": {
      "Type": "AWS::ECS::Service",
      "Properties": {
        "Cluster": {"Ref": "ECSDemoCluster"},
        "DesiredCount": 1,
        "DeploymentController": {
          "Type": "ECS"
        },
        "DeploymentConfiguration": {
          "MaximumPercent": 200,
          "MinimumHealthyPercent": 100,
          "DeploymentCircuitBreaker": {
            "Enable": true,
            "Rollback": true
          },
          "BakeTimeInMinutes": 5,
          "Strategy": "BLUE_GREEN"
        },
        "NetworkConfiguration": {
          "AwsvpcConfiguration": {
            "AssignPublicIp": "ENABLED",
            "SecurityGroups": [
              {"Ref": "ExampleSecurityGroup"}
            ],
            "Subnets": [
              {"Ref": "Subnet1"},
              {"Ref": "Subnet2"}
            ]
          }
        },
        "LaunchType": "FARGATE",
        "PlatformVersion": "1.4.0",
        "TaskDefinition": {"Ref": "BlueTaskDefinition"},
        "LoadBalancers": [
          {
            "ContainerName": "DemoApp",
            "ContainerPort": 80,
            "TargetGroupArn": {"Ref": "ALBTargetGroupBlue"},
            "AdvancedConfiguration": {
              "AlternateTargetGroupArn": {"Ref": "ALBTargetGroupGreen"},
              "ProductionListenerRule": {"Ref": "ALBListenerProdRule"},
              "RoleArn": {"Fn::GetAtt": ["ECSInfrastructureRoleForLoadBalancers", "Arn"]}
            }
          }
        ]
      }
    }
  }
}
```

# Migración de una implementación azul/verde de CodeDeploy a una implementación de servicio de actualización continua de Amazon ECS
<a name="migrate-code-deploy-to-ecs-rolling"></a>

 Puede migrar las implementaciones de sus servicios de una implementación azul/verde de CodeDeploy a una implementación de actualización continua de Amazon ECS. Esto lo aleja de la dependencia de CodeDeploy y pasa a utilizar una implementación integrada.

El programador de servicios de Amazon ECS sustituye las tareas que se están ejecutando actualmente por unas nuevas. El número de tareas que Amazon ECS agrega o elimina del servicio durante una actualización continua se controla mediante la configuración de implementación del servicio.

## Requisitos previos
<a name="migrate-code-deploy-to-ecs-rolling-prerequisites"></a>

Realice las siguientes operaciones antes de iniciar una implementación azul/verde. 

1. Ya no necesita el rol de IAM de CodeDeploy en Amazon ECS.

1. Desactive la automatización de CodeDeploy. Para más información, consulte [Working with deployment groups in CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-groups.html) en la *Guía del usuario de CodeDeploy*.

1. Compruebe que no haya implementaciones de servicio en curso para el servicio. Para obtener más información, consulte [Visualización del historial de servicios mediante las implementaciones de servicios de Amazon ECS](service-deployment.md).

Para más información sobre la actualización de un controlador de implementación de un servicio, consulte [Actualización de los parámetros de servicio de Amazon ECS](update-service-parameters.md).

## Procedimiento
<a name="migrate-code-deploy-to-ecs-rolling-procedure"></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.

   Aparecerá la página de detalles del clúster.

1. En la pestaña **Servicios**, elija el servicio.

   Aparecerá la página de detalles del servicio.

1. En el banner, elija **Migrar**.

   Aparece la página **Actualizar la configuración de implementación**.

1. Amplíe **Opciones de implementación** y, a continuación, especifique los siguientes parámetros.

   1. En **Tipo de controlador de implementación**, elija **ECS**.

   1. En **Estrategia de implementación**, seleccione **Actualización continua**.

   1. En **Max running tasks** (Máximo de tareas en ejecución), ingrese el límite máximo del número de tareas del servicio que se permiten en el estado `RUNNING` durante una implementación, como porcentaje del número de tareas deseado del servicio (redondeado al entero inferior más próximo). Para obtener más información, consulte [Configuración de la implementación](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html#sd-deploymentconfiguration).

   1. En **Max running tasks** (Máximo de tareas en ejecución), ingrese el límite máximo del número de tareas del servicio que se permiten en el estado `RUNNING` o `PENDING` durante una implementación, como porcentaje del número de tareas deseado del servicio (redondeado al entero inferior más próximo).

1. Expanda **Equilibrio de carga** y, a continuación, configure lo siguiente:

   1. En **Rol**, elija el rol que creó en los requisitos previos con los permisos azul/verde.

      Para obtener más información, consulte [Permisos necesarios para las funciones de Lambda en las implementaciones azul/verde de Amazon ECS](blue-green-permissions.md).

   1. En **Oyente**, elija el oyente de producción de su implementación azul/verde de CodeDeploy.

   1. En **Grupo de destino**, elija el grupo de destino de producción de su implementación azul/verde de CodeDeploy.

1. Elija **Actualizar**.

## Siguientes pasos
<a name="migrate-code-deploy-to-ecs-rolling-next-steps"></a>

Debe actualizar el servicio para que los cambios surtan efecto. Para obtener más información, consulte [Actualización de un servicio de Amazon ECS](update-service-console-v2.md).

# Actualización de la estrategia de implementación de Amazon ECS
<a name="migrate-deployment-strategies"></a>

Amazon ECS admite varias estrategias de implementación para actualizar sus servicios. Puede migrar entre estas estrategias en función de los requisitos de su aplicación. Este tema explica cómo migrar entre las implementaciones azul/verde y las implementaciones continuas.

## Información sobre las estrategias de implementación de Amazon ECS
<a name="deployment-strategies-overview"></a>

Antes de migrar de una estrategia de implementación a otra, es importante entender cómo funciona cada estrategia y cuáles son sus principales diferencias:

**Implementaciones continuas**  
En una implementación continua, Amazon ECS sustituye la versión continua actual de la aplicación por una nueva versión. El programador de servicio utiliza los parámetros de porcentaje de buen estado mínimo y máximo para determinar la estrategia de implementación.  
Las implementaciones continuas son más sencillas de configurar, pero ofrecen menos control sobre el proceso de implementación y el enrutamiento del tráfico.

**Implementaciones azul/verde**  
En una implementación azul/verde, Amazon ECS crea una nueva versión de su servicio (verde) junto con la versión existente (azul). Esto permite verificar la nueva versión antes de enrutar el tráfico de producción hacia ella.  
Las implementaciones azul/verde proporcionan un mayor control sobre el proceso de implementación, incluidas las capacidades de transferencia, comprobación y reversión del tráfico.

## Prácticas recomendadas
<a name="migration-best-practices"></a>

Siga estas prácticas recomendadas al migrar entre estrategias de implementación:
+ **Realice pruebas en un entorno que no sea de producción**: pruebe siempre la actualización en un entorno que no sea de producción antes de aplicar cambios a los servicios de producción.
+ **Planifique la reversión**: tenga un plan de reversión en caso de que la actualización no funcione como se esperaba.
+ **Monitoree durante la transición**: monitoree de cerca su servicio durante y después de la migración para asegurarse de que siga funcionando correctamente.
+ **Actualice la documentación**: actualice la documentación de implementación para que refleje la nueva estrategia de implementación.
+ **Tenga en cuenta el impacto en el tráfico**: comprenda cómo la actualización podría afectar al tráfico de su servicio y planifique según corresponda.

# Actualización de la estrategia de implementación de la actualización continua a la implementación azul/verde de Amazon ECS
<a name="update-rolling-to-bluegreen"></a>

Puede migrar de una implementación de actualizaciones continuas a una implementación azul/verde de Amazon ECS cuando desee realizar y comprobar cambios en el servicio antes de implementarlos en un entorno de producción. 

## Requisitos previos
<a name="update-rolling-to-bluegreen-prerequisites"></a>

Antes de migrar su servicio de una implementación continua a una implementación azul/verde, asegúrese de contar con lo siguiente:
+  Espere a que se completen las implementaciones actuales. 
+ Un servicio de Amazon ECS existente que utiliza la estrategia de implementación continua.
+ Si tiene varias revisiones de servicio que sirven el tráfico, Amazon ECS intenta consolidar el tráfico en una sola revisión durante la migración. Si esto no funciona, es posible que tenga que actualizar manualmente el servicio para utilizar una sola revisión antes de migrar.
+ Configure los permisos adecuados.
  + Para obtener información sobre los permisos de Elastic Load Balancing, consulte [Rol de IAM de infraestructura de Amazon ECS para los equilibradores de carga](AmazonECSInfrastructureRolePolicyForLoadBalancers.md).
  + Para obtener información acerca de los permisos de Lambda, consulte [Permisos necesarios para las funciones de Lambda en las implementaciones azul/verde de Amazon ECS](blue-green-permissions.md).
+ En función de la configuración, tendrá que llevar a cabo una de las siguientes opciones:
  + Si su servicio usa Elastic Load Balancing, actualícelo con la nueva “advancedConfiguration” e inicie una implementación continua. 
  + Si su servicio usa Service Connect, actualícelo e inicie una implementación continua. 
  + Si su servicio usa Elastic Load Balancing y Service Connect, lleve a cabo los dos pasos anteriores (puede usar una sola solicitud de UpdateService). 
  + Si su servicio no utiliza ninguna de las opciones anteriores, no será necesaria ninguna operación adicional.
+ Las implementaciones azul/verde de Amazon ECS requieren que su servicio utilice una de las siguientes características. Configure los recursos adecuados.
  + Equilibrador de carga de aplicación: para más información, consulte [Recursos de equilibrador de carga de aplicación para las implementaciones azul/verde, las implementaciones lineales y las implementaciones canario](alb-resources-for-blue-green.md).
  + Equilibrador de carga de red: para más información, consulte [Recursos de Equilibrador de carga de red para las implementaciones azul/verde, las implementaciones lineales y las implementaciones canario de Amazon ECS](nlb-resources-for-blue-green.md).
  + Service Connect: para más información, consulte [Recursos de Service Connect para las implementaciones azul/verde, las implementaciones lineales y las implementaciones canario de Amazon ECS](service-connect-blue-green.md).

## Procedimiento
<a name="update-rolling-to-bluegreen-procedure"></a>

1. Abra la consola de Amazon ECS 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 el clúster que contiene el servicio que desea migrar.

   Se mostrará la página de detalles del clúster.

1. En la página **Detalles del clúster**, seleccione la pestaña **Servicios**.

1. Elija el servicio y, a continuación, elija **Actualizar**.

   Se mostrará la página del servicio de actualización

1. Expanda **Opciones de implementación** y, a continuación, haga lo siguiente:

1. En **Estrategia de implementación**, seleccione **Azul/verde**.

1. Configure los ajustes de implementación azul/verde:

   1. En **Tiempo de incorporación**, introduzca el número de minutos que las revisiones de servicio azul y verde durarán simultáneamente antes de que finalice la revisión azul. 

      Esto permite disponer de tiempo para la verificación y la comprobación.

   1. (Opcional) Configure las funciones de Lambda que se van a ejecutar en etapas específicas de la implementación. En **Enlaces de ciclo de vida de implementación**, configure las funciones de Lambda para las siguientes etapas:
      + **Antes de escalar verticalmente**: se ejecuta antes de escalar verticalmente la revisión de servicio verde
      + **Después de escalar verticalmente**: se ejecuta después de escalar verticalmente la revisión de servicio verde
      + **Transferencia de tráfico de prueba**: se ejecuta durante el enrutamiento de tráfico de prueba hacia la revisión de servicio verde
      + **Después de la transferencia de tráfico de prueba**: se ejecuta después de que el tráfico de prueba se enruta a la revisión del servicio verde
      + **Transferencia de tráfico de producción**: se ejecuta durante el tráfico de producción y se enruta a la revisión de servicio verde
      + **Después de la transferencia de tráfico de producción**: se ejecuta después de que el tráfico de producción se enruta a la revisión del servicio verde

      Para agregar un enlace de ciclo de vida:

      1. Elija **Agregar**.

      1. En **Función de Lambda**, introduzca el nombre o el ARN de la función.

      1. En **Rol**, elija el rol de IAM que tiene permiso para invocar la función de Lambda.

      1. En **Etapas del ciclo de vida**, seleccione las etapas en las que debe ejecutarse la función de Lambda.

      1. Opcional: en **Detalles del enlace**, introduzca los pares clave-valor para proporcionar información adicional al enlace.

1. Configure los ajustes del equilibrador de carga:

   1. En **Equilibrio de carga**, compruebe que el servicio está configurado para utilizar un equilibrador de carga.

   1. En **Grupo de destino**, elija el grupo de destino principal para su entorno (azul) de producción.

   1. En **Grupo de destino alternativo**, elija el grupo de destino para su entorno (verde) de prueba.

   1. En **Regla de oyente de producción**, elija la regla de oyente para enrutar el tráfico de producción.

   1. Opcional: En **Regla de oyente de prueba**, elija una regla de oyente para enrutar el tráfico de prueba a su entorno verde.

   1. En **Rol**, elija el rol de IAM que permite a Amazon ECS administrar el equilibrador de carga.

1. Revise los cambios de configuración y, a continuación, seleccione **Actualizar**.

## Siguientes pasos
<a name="update-rolling-to-bluegreen-next-steps"></a>
+ Actualice el servicio para iniciar la implementación. Para obtener más información, consulte [Actualización de un servicio de Amazon ECS](update-service-console-v2.md).
+ Monitoree el proceso de implementación para asegurarse de que sigue el patrón azul/verde:
  + Se crea y escala verticalmente la revisión de servicio verde
  + El tráfico de prueba se enruta a la revisión verde (si está configurada)
  + El tráfico de producción se transfiere a la revisión verde
  + Transcurrido el tiempo de incorporación, la revisión azul finaliza

# Actualización de la estrategia de implementación azul/verde de Amazon ECS a una actualización continua
<a name="update-bluegreen-to-rolling"></a>

Puede migrar una implementación azul/verde a una implementación de actualización continua.

Tenga en cuenta las siguientes consideraciones al migrar a implementaciones continuas:
+ **Gestión del tráfico**: con las implementaciones continuas, las nuevas tareas comienzan a recibir tráfico en cuanto pasan las comprobaciones de estado. No hay una fase de prueba independiente como ocurre con las implementaciones azul/verde.
+ **Eficiencia de los recursos**: las implementaciones continuas suelen utilizar menos recursos que las implementaciones azul/verde porque sustituyen las tareas de forma gradual en lugar de crear un entorno completamente duplicado.
+ **Complejidad de la reversión**: las implementaciones continuas hacen que las reversiones sean más complejas en comparación con las implementaciones azul/verde. Si necesita realizar una reversión, debe iniciar una nueva implementación con la definición de tarea anterior.
+ **Velocidad de implementación**: las implementaciones continuas pueden tardar más en completarse que las implementaciones azul/verde, especialmente en el caso de los servicios con muchas tareas.
+ **Configuración del equilibrador de carga**: la configuración del equilibrador de carga actual seguirá funcionando con las implementaciones continuas, pero el comportamiento al transferir el tráfico será diferente.

## Requisitos previos
<a name="update-bluegreen-to-rolling-prerequisites"></a>

Antes de migrar el servicio de una implementación azul/verde a una implementación continua, asegúrese de tener lo siguiente:
+ Un servicio de Amazon ECS existente que utiliza la estrategia de implementación azul/verde
+ No hay implementaciones continuas del servicio (espere a que se completen las implementaciones actuales)
+ Una comprensión clara de cómo se comportará su servicio con las implementaciones continuas

**nota**  
No puede migrar un servicio a una implementación continua si tiene una implementación en curso. Espere a que se complete cualquier implementación actual antes de continuar.

## Procedimiento de migración
<a name="update-bluegreen-to-rolling-procedure"></a>

Siga estos pasos para migrar su servicio de Amazon ECS de una implementación azul/verde a una implementación continua:

1. Abra la consola de Amazon ECS 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 el clúster que contiene el servicio que desea migrar.

1. En la página **Detalles del clúster**, seleccione la pestaña **Servicios**.

1. Seleccione el servicio que desee migrar y, a continuación, elija **Actualizar**.

1. En la página **Actualizar servicio**, vaya a la sección **Opciones de implementación** y expándala si es necesario.

1. En **Estrategia de implementación**, seleccione **Actualización continua**.

1. Configure los ajustes de la implementación continua:

   1. En **Porcentaje mínimo en buen estado**, ingrese el porcentaje mínimo de tareas que el servicio debe mantener en el estado `RUNNING` durante una implementación. Este valor se especifica como un porcentaje del número deseado de tareas para el servicio.

   1. En **Porcentaje máximo**, ingrese el porcentaje máximo de tareas que se permiten en el estado `RUNNING` o `PENDING` durante una implementación. Este valor se especifica como un porcentaje del número deseado de tareas para el servicio.

1. Opcional: en **Detección de errores de implementación**, configure el modo en que Amazon ECS detecta y gestiona los errores de implementación:

   1. Para utilizar el interruptor de circuito de implementación, seleccione **Utilizar el interruptor de circuito de implementación de Amazon ECS**.

   1. Para revertir automáticamente las implementaciones fallidas, seleccione **Revertir en caso de error**.

1. Revise los cambios de configuración y, a continuación, seleccione **Actualizar** para guardar los cambios y migrar el servicio a una implementación continua.

Amazon ECS actualizará la configuración del servicio para utilizar la estrategia de implementación continua. La próxima vez que actualice su servicio, utilizará el proceso de implementación continua.

**nota**  
Al migrar de una implementación azul/verde a una implementación continua, Amazon ECS gestiona la transición de la siguiente manera:  
Identifica la revisión de servicio activa actual que sirve el tráfico.
Mantiene la configuración del equilibrador de carga existente, pero cambia la forma en que se gestionan las nuevas implementaciones.
Prepara el servicio para futuras implementaciones continuas.

## Siguientes pasos
<a name="update-bluegreen-to-rolling-next-steps"></a>
+ Actualice el servicio para iniciar la implementación. Para obtener más información, consulte [Actualización de un servicio de Amazon ECS](update-service-console-v2.md).

# Resolución de problemas de actualizaciones de la estrategia de implementación de Amazon ECS
<a name="troubleshooting-deployment-controller-migration"></a>

En esta sección se brindan soluciones a problemas comunes que puede encontrar al migrar estrategias de implementación.

## Múltiples revisiones de servicio o conjuntos de tareas
<a name="troubleshooting-multiple-task-sets"></a>

Los siguientes problemas se refieren a tener varias revisiones de servicio para una sola implementación.

Varios conjuntos de tareas al actualizar el controlador de implementación de ECS  
*Mensaje de error*: `Updating the deployment controller is not supported when there are multiple tasksets in the service. Please ensure your service has only one taskset and try again.`  
*Solución*: este error se produce al intentar cambiar el tipo de controlador de implementación de un servicio con varios conjuntos de tareas activos. Para resolver este problema en el controlador de implementación `CODE_DEPLOY` o `EXTERNAL`:  

1. Compruebe los conjuntos de tareas actuales:

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].taskSets"
   ```

1. Espere a que se complete cualquier implementación en curso.

1. Fuerce una nueva implementación para limpiar los conjuntos de tareas:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --force-new-deployment
   ```

1. Si es necesario, elimine manualmente los conjuntos de tareas adicionales:

   ```
   aws ecs delete-task-set --cluster your-cluster-name --service your-service-name --task-set task-set-id
   ```

1. Cuando solo quede un conjunto de tareas, vuelva a intentar actualizar el controlador de implementación.
Para obtener más información, consulte [Estrategias y controladores de implementación de servicios de Amazon ECS](ecs_service-options.md).

Falta el conjunto de tareas principal al actualizar el controlador de implementación `ECS`  
*Mensaje de error*: `Updating the deployment controller requires a primary taskset in the service. Please ensure your service has a primary taskset and try again.`  
*Solución*: este error se produce al intentar cambiar el tipo de controlador de implementación de un servicio que no tiene un conjunto de tareas principal. Para resolver este problema, siga estos pasos:  

1. Verifique el estado del servicio y los conjuntos de tareas. ). Si existe un conjunto de tareas en el servicio, debe marcarse como `ACTIVE`. 

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].taskSets[*].[status,id]
   ```

   Si no hay ningún conjunto de tareas en estado `ACTIVE`, migre la implementación. Para más información, consulte [Métodos de migración](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/migrate-codedeploy-to-ecs-bluegreen.html#migration-paths). 

1. Si el servicio no tiene tareas en ejecución, implemente al menos una tarea actualizando el servicio:

   ```
   aws ecs update-service-primary-task-set --cluster your-cluster-name --service your-service-name --primary-task-set your-taskset-id
   ```

   Esto marcará el conjunto de tareas (anteriormente `ACTIVE`) en el servicio como en estado `PRIMARY`.

1. Espere a que la tarea alcance un estado de ejecución estable. Puede comprobar el estado con:

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deployments"
   ```

1. Una vez que el servicio tenga una tarea principal configurada con tareas en ejecución, vuelva a intentar actualizar el controlador de implementación.
Para obtener más información, consulte [Estrategias y controladores de implementación de servicios de Amazon ECS](ecs_service-options.md).

## Discrepancia entre el tipo de detección de errores de implementación y el controlador de implementación
<a name="troubleshooting-failure-detection"></a>

Los problemas siguientes se relacionan con una discrepancia entre el tipo de detección de errores de implementación y el controlador de implementación.

Interruptor de circuito de implementación con un controlador que no es de ECS  
*Mensaje de error*: `Deployment circuit breaker feature is only supported with ECS deployment controller. Update to ECS deployment controller and try again.`  
*Solución*: este error se produce al intentar habilitar la característica de interruptor de circuito de implementación en un servicio que no utiliza el controlador de implementación `ECS`. El interruptor de circuito de implementación solo es compatible con el controlador de implementación `ECS`.  

1. Compruebe el controlador de implementación actual del servicio:

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deploymentController"
   ```

1. Actualice su servicio para usar el controlador de implementación `ECS`:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS
   ```

1. Una vez que el servicio utilice el controlador de implementación `ECS`, active el interruptor de ccircuito de implementación:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-configuration "deploymentCircuitBreaker={enable=true,rollback=true}"
   ```
Para obtener más información, consulte [Detección de errores por el interruptor de circuito de implementación de Amazon ECS](deployment-circuit-breaker.md).

Reversión basada en alarmas con un controlador que no es de ECS  
*Mensaje de error*: `Alarm based rollback feature is only supported with ECS deployment controller. Update to ECS deployment controller and try again.`  
*Solución*: este error se produce al intentar configurar la reversión basada en alarmas en un servicio que no utiliza el controlador de implementación `ECS`. La característica de reversión basada en alarmas solo es compatible con el controlador de implementación `ECS`.  

1. Compruebe el controlador de implementación actual del servicio:

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deploymentController"
   ```

1. Actualice su servicio para usar el controlador de implementación `ECS`:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS
   ```

1. Una vez que el servicio utilice el controlador de implementación `ECS`, configure la reversión basada en alarmas:

   ```
   aws ecs update-service --cluster your-cluster-name --services your-service-name --deployment-configuration "alarms={alarmNames=[your-alarm-name],enable=true,rollback=true}"
   ```
Para obtener más información, consulte [Detección de errores en la implementación de Amazon ECS por las alarmas de CloudWatch](deployment-alarm-failure.md).

## Discrepancia entre Service Connect y el controlador de implementación
<a name="troubleshooting-service-connect-mismatch"></a>

Los siguientes problemas se relacionan con una discrepancia entre Service Connect y el controlador de implementación.

Controlador `EXTERNAL` con Service Connect  
*Mensaje de error*: `The EXTERNAL deployment controller type is not supported for services using Service Connect.`  
*Solución*: este error se produce al intentar utilizar el controlador de implementación `EXTERNAL` con un servicio que tiene activado Service Connect. El controlador `EXTERNAL` no es compatible con Service Connect.  

1. Compruebe si su servicio tiene activado Service Connect:

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].serviceConnectConfiguration"
   ```

1. Si necesita usar el controlador de implementación `EXTERNAL`, desactive Service Connect actualizando el servicio:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --service-connect-configuration "{}"
   ```

1. Como alternativa, si debe usar Service Connect, utilice el controlador de implementación `ECS` en su lugar:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS
   ```
Para obtener más información, consulte [Estrategias y controladores de implementación de servicios de Amazon ECS](ecs_service-options.md).

Service Connect con un controlador que no es de ECS  
*Mensaje de error*: `Service Connect feature is only supported with ECS (rolling update) deployment controller. Update to ECS deployment controller and try again.`  
*Solución*: este error se produce al intentar configurar Service Connect en un servicio que no utiliza el controlador de implementación `ECS`. La característica Service Connect solo es compatible con el controlador de implementación `ECS`.  

1. Compruebe el controlador de implementación actual del servicio:

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].deploymentController"
   ```

1. Actualice su servicio para usar el controlador de implementación de ECS:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS
   ```

1. Una vez que el servicio utilice el controlador de implementación de ECS, habilite Service Connect:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --service-connect-configuration "enabled=true,namespace=your-namespace"
   ```
Para obtener más información, consulte [Estrategias y controladores de implementación de servicios de Amazon ECS](ecs_service-options.md).

## Discrepancia entre el tipo de controlador y la estrategia de programación
<a name="troubleshooting-controller-type-scheduling"></a>

Los siguientes problemas se relacionan con una discrepancia entre el tipo de controlador y la estrategia de programación.

Controlador `CODE_DEPLOY` con estrategia de programación `DAEMON`  
*Mensaje de error*: `The CODE_DEPLOY deployment controller type is not supported for services using the DAEMON scheduling strategy.`  
*Solución*: este error se produce al intentar utilizar el controlador de implementación CODE\$1DEPLOY con un servicio que utiliza la estrategia de programación `DAEMON`. El controlador `CODE_DEPLOY` solo es compatible con la estrategia de programación `REPLICA`.  

1. Compruebe la estrategia de programación actual de su servicio:

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].schedulingStrategy"
   ```

1. Si necesita implementaciones azul/verde, cambie su servicio para usar la estrategia de programación `REPLICA`:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --scheduling-strategy REPLICA
   ```

1. Como alternativa, si debe utilizar la estrategia de programación `DAEMON`, utilice el controlador de implementación `ECS` en su lugar:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS
   ```
Para obtener más información, consulte [Estrategias y controladores de implementación de servicios de Amazon ECS](ecs_service-options.md).

Controlador EXTERNAL con la estrategia de programación DAEMON  
*Mensaje de error*: `The EXTERNAL deployment controller type is not supported for services using the DAEMON scheduling strategy.`  
*Solución*: este error se produce al intentar utilizar el controlador de implementación EXTERNAL con un servicio de ECS que utiliza la estrategia de programación DAEMON. El controlador EXTERNAL solo es compatible con la estrategia de programación REPLICA.  

1. Compruebe la estrategia de programación actual de su servicio:

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].schedulingStrategy"
   ```

1. Si necesita usar el controlador de implementación `EXTERNAL`, cambie su servicio para usar la estrategia de programación `REPLICA`:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --scheduling-strategy REPLICA
   ```

1. Como alternativa, si debe utilizar la estrategia de programación `DAEMON`, utilice el controlador de implementación `ECS` en su lugar:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --deployment-controller type=ECS
   ```
Para obtener más información, consulte [Estrategias y controladores de implementación de servicios de Amazon ECS](ecs_service-options.md).

Registros de servicios con tipo de lanzamiento externo  
*Mensaje de error*: `Service registries are not supported for external launch type.`  
*Solución*: este error se produce al intentar configurar la detección de servicios (registros de servicios) para un servicio que utiliza el tipo de lanzamiento `EXTERNAL`. La detección de servicios no es compatible con el tipo de lanzamiento `EXTERNAL`.  

1. Compruebe el tipo de lanzamiento actual de su servicio:

   ```
   aws ecs describe-services --cluster your-cluster-name --services your-service-name --query "services[0].launchType"
   ```

1. Si necesita la detección de servicio, cámbielo para usar el tipo de lanzamiento `EC2` o `FARGATE`:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --launch-type FARGATE
   ```

1. Como alternativa, si debe usar el tipo de lanzamiento `EXTERNAL`, elimine la configuración del registro de servicio:

   ```
   aws ecs update-service --cluster your-cluster-name --service your-service-name --service-registries "[]"
   ```
Para obtener más información, consulte [Estrategias y controladores de implementación de servicios de Amazon ECS](ecs_service-options.md).

## Reversión de una actualización del controlador de implementación
<a name="troubleshooting-revert"></a>

Si decide que desea volver al controlador de implementaciones anterior, puede optar por uno de los siguientes procedimientos:
+ Si utilizó CloudFormation, puede utilizar la plantilla anterior para crear una nueva pila. Para más información, consulte [Creación de una pila desde](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html) en la *Guía del usuario de CloudFormation*.
+ Si utilizó la consola de Amazon ECS o la AWS CLI, puede actualizar el servicio. Para obtener más información, consulte [Actualización de un servicio de Amazon ECS](update-service-console-v2.md).

  Si utiliza el comando update-service, utilice la opción `--deployment-controller` y configúrela en el controlador de implementación anterior.

# Visualización del historial de servicios mediante las implementaciones de servicios de Amazon ECS
<a name="service-deployment"></a>

Las implementaciones de servicios proporcionan una visión completa de las implementaciones. Las implementaciones de servicio proporcionan la siguiente información acerca del servicio:
+ La configuración de la carga de trabajo actualmente implementada (la revisión de servicios de origen)
+ La configuración de la carga de trabajo que se está implementando (la revisión de servicios de destino)
+ Estado de las implementaciones
+ El número de tareas con errores que detectó el interruptor
+ Las alarmas de CloudWatch que están en alarma
+ Cuando se inició y finalizó la implementación del servicio
+ Los detalles de una reversión, si se ha producido

Para obtener información sobre las propiedades de implementación del servicio, consulte [Propiedades incluidas en la implementación de un servicio de Amazon ECS](service-deployment-property.md).

Las implementaciones de servicios son de solo lectura y cada una tiene un identificador único. 

Hay tres etapas de implementación del servicio:


| Etapa | Definición | Estados asociados | 
| --- | --- | --- | 
| Pending (Pendiente) | Se ha creado una implementación de servicios, pero no se ha iniciado | PENDIENTE | 
| Continuo | La implementación de servicios está en curso. |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/service-deployment.html)  | 
| Completado  | La implementación de un servicio ha finalizado (correctamente o con errores) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/service-deployment.html)  | 

Utilice las implementaciones de servicios para comprender el ciclo de vida de su servicio y determinar si hay alguna acción que deba tomar. Por ejemplo, si se ha producido una reversión, es posible que tenga que investigar la implementación del servicio y analizar los eventos del servicio.

Puede ver el historial de 90 días más reciente de las implementaciones creadas a partir del 25 de octubre de 2024 mediante la consola, la API y la AWS CLI. 

Puede detener una implementación que no se haya completado. Para obtener más información, consulte [Detención de las implementaciones de servicios de Amazon ECS](stop-service-deployment.md).

## Ciclo de la implementación de servicios
<a name="service-deployments-lifecycle"></a>

Amazon ECS crea una nueva implementación de servicio automáticamente cuando se produce alguna de las siguientes acciones:
+ Un usuario crea un servicio.
+ Un usuario actualiza el servicio y utiliza la opción de forzar una nueva implementación.
+ Un usuario actualiza una o varias propiedades del servicio que requieren una implementación.

Mientras la implementación está en curso, Amazon ECS actualiza las siguientes propiedades de implementación de servicios para reflejar el progreso de la implementación de servicios:
+ El estado
+ El número de tareas en ejecución

  Es posible que el número de tareas en ejecución indicado en la revisión de servicios no sea igual al número real de tareas en ejecución. Este número representa el número de tareas en ejecución cuando se completó la implementación. Por ejemplo, si ha lanzado tareas independientes de la implementación del servicio, esas tareas no se incluyen en el recuento de tareas en ejecución para la revisión de servicios.
+ Detección de error en el interruptor:
  + El número de tareas que han presentado un error al iniciarse
+ Detección de un error de alarma de CloudWatch
  + Las alarmas activas
+ Información de reversión:
  + La hora de inicio
  + El motivo de la reversión
  + El ARN de la revisión de servicio que se utilizó para la reversión
+ El motivo del estado

Amazon ECS elimina la implementación del servicio cuando usted elimina un servicio.

## Estados de implementaciones de servicios
<a name="service-deployments-states"></a>

La implementación de un servicio comienza en el estado `PENDING`. 

En la siguiente ilustración se muestran los estados de implementación del servicio que pueden producirse después del estado `PENDING`: `IN_PROGRESS`, `ROLLBACK_REQUESTED`, `SUCCESSFUL`, `STOP_REQUESTED`, `ROLLBACK_IN_PROGRESSS`, `ROLLBACK_FAILED`, `ROLLBACK_SUCCESSFUL` y `STOPPED`.

![\[Los estados STOP_REQUESTED, SUCCESSFUL y ROLLBACK_IN_PROGRESS de implementación del servicio pueden producirse después del estado IN_PROGRESS.\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/images/service-deployment-states.png)


La siguiente información proporciona detalles sobre los estados de implementación de servicios:
+ `PENDING`: se ha creado la implementación de servicios, pero no se ha iniciado.

  El estado puede pasar a ser `IN_PROGRESS`, `ROLLBACK_REQUESTED`, `STOP_REQUESTED` o `STOPPED`.
+ `IN_PROGRESS`: la implementación del servicio está en curso.

  El estado puede pasar a ser `SUCCESSFUL`, `STOP_REQUESTED`, `ROLLBACK_REQUESTED`, `ROLLBACK_IN_PROGRESS` y `STOPPED`.
+ `STOP_REQUESTED`: el estado de implementación del servicio pasa a ser `STOP_REQUESTED` cuando ocurre alguna de las siguientes situaciones:
  + Un usuario inicia una nueva implementación de servicios.
  + La opción de reversión no se utiliza para el mecanismo de detección de errores (el interruptor o la alarma) y el servicio no alcanza el estado `SUCCESSFUL`.

  El estado pasa a ser `STOPPED`.
+  `ROLLBACK_REQUESTED`: el estado de implementación del servicio pasa a `ROLLBACK_REQUESTED` cuando un usuario solicita una reversión a través de la consola, la API o la CLI.

  El estado puede pasar a ser `SUCCESSFUL`, `ROLLBACK_IN_PROGRESS` y `STOPPED`.
+ `SUCCESSFUL`: el estado de implementación del servicio pasa a ser `SUCCESSFUL` cuando la implementación del servicio se completa correctamente.
+  `ROLLBACK_IN_PROGRESS`: el estado de implementación del servicio pasa a ser `ROLLBACK_IN_PROGRESS` cuando se utiliza la opción de reversión para el mecanismo de detección de errores (el interruptor o la alarma) y el servicio produce un error.

   El estado pasa a ser `ROLLBACK_SUCCESSFUL` o `ROLLBACK_FAILED`.

# Propiedades incluidas en la implementación de un servicio de Amazon ECS
<a name="service-deployment-property"></a>

Las siguientes propiedades se incluyen en la implementación de un servicio.


| Propiedad | Descripción | 
| --- | --- | 
|  ARN de implementación de servicios  |  El ARN de la implementación de servicios.  | 
| ARN de servicio |  El ARN del servicio para esta implementación de servicios.  | 
|  ARN del clúster  |  El ARN del clúster que aloja el servicio.  | 
| Hora de creación de la implementación de servicios | La hora a la que se creó la implementación de servicios.  | 
| Hora de inicio de la implementación de servicios | La hora a la que se inició la implementación de servicios.  | 
|  Hora de finalización de la implementación de servicios  | La hora a la que finalizó la implementación de servicios. | 
| Hora de detención de la implementación de servicios | La hora a la que se detuvo la implementación de servicios.  | 
| Hora de actualización de la implementación de servicios | La hora de la última actualización de la implementación de servicios.  | 
| Revisiones de servicios de origen |  Las revisiones del servicio que se están ejecutando actualmente.  Para obtener más información sobre las propiedades incluidas, consulte [Propiedades incluidas en una revisión de servicios de Amazon ECS](service-revision-property.md).  | 
| Configuración de implementación | Los parámetros de implementación incluyen la configuración del interruptor y las alarmas que determinan.[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/service-deployment-property.html) | 
| Revisión de servicios de destino | La revisión de servicios que se debe implementar. Una vez que la implementación se complete correctamente, la revisión de servicios de destino es la revisión de servicios en ejecución. | 
| Estados de implementación de servicios | El estado de la implementación de servicios.Los valores válidos son PENDING, SUCCESSFUL, STOP\$1REQUESTED, STOP\$1IN\$1PROGRESS, IN\$1PROGRESS, ROLLBACK\$1IN\$1PROGRESS, ROLLBACK\$1SUCCESSFUL y ROLLBACK\$1FAILED. | 
| Información de estado de la implementación de servicios | Información sobre por qué la implementación del servicio se encuentra en el estado actual. Por ejemplo, el interruptor detectó un error. | 
|  Información de reversión | Las opciones de reversión que utiliza la implementación del servicio cuando se produce un error en la implementación. | 
| Opciones de interruptor de implementación de servicios | El interruptor que determina que se produjo un error en la implementación de un servicio. | 
| Alarmas de CloudWatch para la implementación de servicios | Las alarmas de CloudWatch que determinan cuándo se produce un error en la implementación de un servicio. | 

# Permisos necesarios para ver las implementaciones de servicios de Amazon ECS
<a name="service-deployment-permissions"></a>

 Si sigue la práctica recomendada de concesión de privilegios mínimos, debe agregar más permisos para ver las implementaciones de servicios en la consola.

Debe acceder a las siguientes acciones:
+ ListServiceDeployments
+ DescribeServiceDeployments
+ DescribeServiceRevisions

Debe acceder a los siguientes recursos:
+ Servicio
+ Implementación de servicios
+ Revisión de servicios

La siguiente política de ejemplo contiene los permisos necesarios y limita las acciones a un servicio especificado. 

Sustituya `account`, `cluster-name` y `service-name` por sus valores.

------
#### [ JSON ]

****  

```
{
"Statement": [
    {
        "Effect": "Allow",
        "Action": [
            "ecs:ListServiceDeployments",
            "ecs:DescribeServiceDeployments",
            "ecs:DescribeServiceRevisions"
        ],
        "Resource": [
            "arn:aws:ecs:us-east-1:123456789012:service/cluster-name/service-name",
            "arn:aws:ecs:us-east-1:123456789012:service-deployment/cluster-name/service-name/*",
            "arn:aws:ecs:us-east-1:123456789012:service-revision/cluster-name/service-name/*"
            ]
        }
   ]
}
```

------

# Visualización de las implementaciones de servicios de Amazon ECS
<a name="view-service-deployment"></a>

Puede consultar el historial de 90 días más reciente de las implementaciones creadas a partir del 25 de octubre de 2024. Las implementaciones de servicios pueden tener alguno de los estados que se indican a continuación:
+ En curso 
+ Pending (Pendiente)
+ Completado

 Puede usar esta información para determinar si debe actualizar la forma en que se implementa el servicio o la revisión de servicios. Para obtener más información sobre las propiedades incluidas, consulte [Propiedades incluidas en la implementación de un servicio de Amazon ECS](service-deployment-property.md).

Antes de empezar, configure los permisos necesarios para ver las implementaciones de servicios. Para obtener más información, consulte [Permisos necesarios para ver las implementaciones de servicios de Amazon ECS](service-deployment-permissions.md).

------
#### [ 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 página **Clusters** (Clústeres), elija el clúster.

1. En la página de detalles del clúster, en la sección **Servicios**, elija el servicio.

   Aparecerá la página de detalles del servicio.

1. En la página de detalles del servicio, elija **Implementaciones**.

1. Elija la implementación de servicios que desea ver.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/view-service-deployment.html)

   Se abrirá la página de detalles de la implementación de servicios.

1. (Opcional) Compare las revisiones del servicio para ver las diferencias.

   En **Revisiones del servicio**, elija **Comparar revisiones** y, a continuación, seleccione 2 revisiones para comparar.

   Las revisiones del servicio se muestran una al lado de la otra con las diferencias resaltadas.

------
#### [ AWS CLI ]

1. Ejecute `list-service-deployments` para recuperar el ARN de implementación del servicio. 

   Sustituya las variables por valores propios.

   ```
   aws ecs list-service-deployments --cluster cluster-name --service service-name
   ```

   Anote el identificador serviceDeploymentArn de la implementación que quiere ver.

   ```
   {
       "serviceDeployments": [
           {
               "serviceDeploymentArn": "arn:aws:ecs:us-west-2:123456789012:service-deployment/example/sd-example/NCWGC2ZR-taawPAYrIaU5",
               "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/example/sd-example",
               "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/example",
               "targetServiceRevisionArn": "arn:aws:ecs:us-west-2:123456789012:service-revision/example/sd-example/4980306466373577095",
               "status": "SUCCESSFUL"
           }
       ]
   }
   ```

1. Ejecuta `describe-service-deployments`. Utilice el identificador `serviceDeploymentArn` que se devolvió de `list-service-deployments`.

   Sustituya las variables por valores propios.

   ```
   aws ecs describe-service-deployments --service-deployment-arns arn:aws:ecs:region:123456789012:service-deployment/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5
   ```

------

## Siguientes pasos
<a name="view-service-deployment-next-step"></a>

Puede ver los detalles de las revisiones de servicios en la implementación. Para obtener más información, consulte [Visualización de los detalles de la revisión de servicios de Amazon ECS](view-service-revision.md)

# Revisiones de servicios de Amazon ECS
<a name="service-revision"></a>

Una revisión de servicios contiene un registro de la configuración de carga de trabajo que Amazon ECS intenta implementar. Cada vez que crea o implementa un servicio, Amazon ECS crea y captura automáticamente la configuración que intenta implementar en la revisión de servicios.

 Las revisiones de servicios son de solo lectura y tienen identificadores únicos. Para obtener más información sobre las propiedades incluidas, consulte [Propiedades incluidas en una revisión de servicios de Amazon ECS](service-revision-property.md).

 Las revisiones de servicios proporcionan los siguientes beneficios:
+ Durante una implementación de un servicio, puede comparar la revisión de servicios actualmente implementada (origen) con la que se está implementando (destino).
+ Cuando utiliza la opción de reversión para una implementación de un servicio, Amazon ECS restablece automáticamente la implementación del servicio hasta la última revisión de servicios implementada correctamente.
+ Las revisiones de servicios contienen el registro de la configuración de la carga de trabajo en un recurso. 

## Ciclo de vida de las revisiones de servicios
<a name="service-revisions-lifecycle"></a>

Amazon ECS crea automáticamente una nueva revisión de servicios al crear un servicio o al actualizar una propiedad del servicio que inicia una implementación.

 Amazon ECS no crea una nueva revisión de servicios para una operación de reversión. Amazon ECS utiliza la última revisión de servicios correcta para la reversión. 

Una revisión de servicios no se puede cambiar.

Amazon ECS elimina la revisión de servicios cuando usted elimina un servicio.

Puede ver las revisiones de servicios creadas a partir del 25 de octubre de 2024 mediante la consola, la API y la CLI.

# Propiedades incluidas en una revisión de servicios de Amazon ECS
<a name="service-revision-property"></a>

Las siguientes propiedades se incluyen en una revisión de servicios.


| Recurso | Descripción | 
| --- | --- | 
|  ARN de servicio  |  El ARN que identifica el servicio.  | 
|  ARN del clúster  |  El ARN del clúster que aloja el servicio.  | 
|  ARN de definición de tarea  |  El ARN de la definición de tareas que se utiliza para las tareas del servicio.  | 
|  Registros de servicios  |  Los detalles de los registros de servicios que se utilizan para la detección de servicios. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| Proveedores de capacidad |  Los detalles de la estrategia del proveedor de capacidad. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| Imágenes de contenedor |  Los detalles acerca de las imágenes del contenedor.  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| Red |  La configuración de red del servicio. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| Tipo de lanzamiento | La opción de computación utilizada para el servicio. | 
| Propiedades específicas de Fargate |  Si usa Fargate, se trata de información sobre la versión de Fargate. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| Los volúmenes de Amazon EBS que se configuran en la implementación |  La configuración de un volumen que se especifica en la definición de la tarea como un volumen que se configura en el momento del lanzamiento.  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/service-revision-property.html)  | 
|  Service Connect |  La configuración de Service Connect. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| Equilibradores de carga de los servicios |  Los equilibradores de carga que enrutan el tráfico del servicio. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/service-revision-property.html)  | 
| Supervisión en tiempo de ejecución | Indica si la supervisión del tiempo de ejecución está activada. | 
| Fecha de creación |  La fecha en que se creó la revisión de servicios.  | 
| VPC Lattice |  La configuración de VPC Lattice para la revisión de servicios.  | 

# Visualización de los detalles de la revisión de servicios de Amazon ECS
<a name="view-service-revision"></a>

Puede ver información sobre los siguientes tipos de revisiones de servicios que se crearon el 25 de octubre de 2024 o después:
+ Origen: configuración de carga de trabajo actualmente implementada
+ Destino: configuración de la carga de trabajo que se implementa

------
#### [ 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 página **Clusters** (Clústeres), elija el clúster.

1. En la página de detalles del clúster, en la sección **Servicios**, elija el servicio.

   Aparecerá la página de detalles del servicio.

1. En la página de detalles del servicio, elija **Implementaciones**.

1. Elija la revisión de servicios que quiere ver.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/view-service-revision.html)

------
#### [ AWS CLI ]

1. Ejecute `describe-service-deployments` para recuperar el ARN de la revisión de servicios. 

   Sustituya las variables por valores propios.

   ```
   aws ecs describe-service-deployments --service-deployment-arns arn:aws:ecs:region:account-id:service/cluster-name/service-name/NCWGC2ZR-taawPAYrIaU5
   ```

   Anote el `arn` de `sourceServiceRevisions` o `targetServiceRevisions`.

   ```
   {
       "serviceDeployments": [
           {
               "serviceDeploymentArn": "arn:aws:ecs:us-west-2:123456789012:service-deployment/example/sd-example/NCWGC2ZR-taawPAYrIaU5",
               "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/example/sd-example",
               "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/example",
               "updatedAt": "2024-09-10T16:49:35.572000+00:00",
               "sourceServiceRevision": {
                   "arn": "arn:aws:ecs:us-west-2:123456789012:service-revision/example/sd-example/4980306466373578954",
                   "requestedTaskCount": 0,
                   "runningTaskCount": 0,
                   "pendingTaskCount": 0
               },
               "targetServiceRevision": {
                   "arn": "arn:aws:ecs:us-west-2:123456789012:service-revision/example/sd-example/4980306466373577095",
                   "requestedTaskCount": 0,
                   "runningTaskCount": 0,
                   "pendingTaskCount": 0
               },
               "status": "IN_PROGRESS",
               "deploymentConfiguration": {
                   "deploymentCircuitBreaker": {
                       "enable": false,
                       "rollback": false
                   },
                   "maximumPercent": 200,
                   "minimumHealthyPercent": 100
               }
           }
       ],
       "failures": []
   }
   ```

1. Ejecuta `describe-service-revisions`. Utilice el identificador `arn` que se devolvió de `describe-service-deployments`.

   Sustituya las variables por valores propios.

   ```
   aws ecs describe-service-revisions --service-revision-arns arn:aws:ecs:region:123456789012:service-revision/cluster-name/service-name/4980306466373577095
   ```

------

# Equilibrio de un servicio de Amazon ECS entre zonas de disponibilidad
<a name="service-rebalancing"></a>

A partir del 5 de septiembre de 2025, Amazon ECS habilitará el reequilibrio de zonas de disponibilidad para todos los servicios compatibles con la característica. Un servicio es compatible cuando la distribución de zonas de disponibilidad es la primera estrategia de ubicación de tareas o cuando no existe una estrategia de ubicación.

Para ayudar a que sus aplicaciones alcancen una alta disponibilidad, le recomendamos configurar sus servicios multitarea para que se ejecuten en varias zonas de disponibilidad. En el caso de los servicios que especifican que su primera estrategia de ubicación es la distribución por zonas de disponibilidad, AWS hace todo lo posible por distribuir uniformemente las tareas de servicio entre las zonas de disponibilidad disponibles.

Sin embargo, puede haber ocasiones en las que la cantidad de tareas que se ejecutan en una zona de disponibilidad no sea la misma que en otras zonas de disponibilidad, como, por ejemplo, después de una interrupción en una zona de disponibilidad. Para corregir este desequilibrio de tareas, puede habilitar la característica de reequilibrio de las zonas de disponibilidad.

Con el reequilibrio de las zonas de disponibilidad, Amazon ECS supervisa de forma continua la distribución de las tareas entre las zonas de disponibilidad para cada uno de los servicios. Cuando Amazon ECS detecta una distribución desigual de las tareas, toma medidas automáticamente para reequilibrar la carga de trabajo entre las zonas de disponibilidad. Esto implica lanzar nuevas tareas en las zonas de disponibilidad con el menor número de tareas y finalizar las tareas en las zonas de disponibilidad sobrecargadas.

Esta redistribución garantiza que ninguna zona de disponibilidad se convierta en un punto de error, lo que ayuda a mantener la disponibilidad general de las aplicaciones en contenedores. El proceso de reequilibrio automatizado elimina la necesidad de intervención manual, lo que acelera el tiempo de recuperación después de un evento.

A continuación, se muestra el proceso de reequilibrio de zonas de disponibilidad:

1. Amazon ECS comienza a supervisar un servicio una vez que alcanza el estado estable y analiza el número de tareas que se ejecutan en cada zona de disponibilidad.

1. Amazon ECS realiza las siguientes operaciones cuando detecta un desequilibrio en el número de tareas que se ejecutan en cada zona de disponibilidad:
   + Envía un evento de servicio que indica que se está iniciando el reequilibrio de las zonas de disponibilidad.
   + Inicia tareas en las zonas de disponibilidad con el menor número de tareas en ejecución.
   + Detiene las tareas en las zonas de disponibilidad con el mayor número de tareas en ejecución.
   + El programador espera a que las tareas recién iniciadas tengan el estado `HEALTHY` y `RUNNING` antes de detenerlas en la zona de disponibilidad sobredimensionada.
   + Envía un evento de servicio con el resultado del reequilibrio de la zona de disponibilidad.

## Cómo detecta Amazon ECS la distribución desigual de las tareas
<a name="service-rebalancing-imbalance"></a>

Amazon ECS determina un desequilibrio en el número de tareas que se ejecutan en cada zona de disponibilidad dividiendo el recuento de tareas deseado del servicio entre el número de zonas de disponibilidad configuradas. Si el recuento de tareas deseado no se divide de manera uniforme, Amazon ECS distribuye el resto de las tareas de manera uniforme entre las zonas de disponibilidad configuradas. Cada zona de disponibilidad debe tener al menos una tarea.

Por ejemplo, considere un servicio de Amazon ECS con un recuento deseado de dos tareas configurado para dos zonas de disponibilidad. En este escenario, el recuento de tareas deseado se divide de manera uniforme. Una distribución equilibrada sería una tarea por zona de disponibilidad. Si hay dos tareas en la zona de disponibilidad 1 y cero tareas en la zona de disponibilidad 2, Amazon ECS aplicaría el reequilibrio iniciando una tarea en la zona de disponibilidad 2 antes de detener una tarea en la zona de disponibilidad 1.

Ahora, considere un servicio de Amazon ECS con un recuento deseado de tres tareas configurado para dos zonas de disponibilidad. En este escenario, el recuento de tareas deseado no se divide de manera uniforme. Una distribución equilibrada sería una tarea en la zona de disponibilidad 1 y dos tareas en la zona de disponibilidad 2, ya que cada zona de disponibilidad tiene al menos una tarea y la tarea restante se coloca en la zona de disponibilidad 2.

Considere un servicio de Amazon ECS que tenga un recuento deseado de cinco tareas configuradas para tres zonas de disponibilidad. En este escenario, el recuento de tareas deseado no se divide de manera uniforme. Una distribución equilibrada sería una tarea en la zona de disponibilidad 1 y dos tareas en cada una de las zonas de disponibilidad 2 y 3. Después de asignar una tarea a cada zona de disponibilidad, las dos tareas restantes se distribuyen de manera uniforme entre las zonas de disponibilidad.

## Consideraciones para configurar el reequilibrio de zonas de disponibilidad
<a name="service-rebalancing-configurations"></a>

Tenga en cuenta lo siguiente cuando desee configurar el reequilibrio de zonas de disponibilidad:
+ El reequilibrio de zonas de disponibilidad es compatible con los proveedores de capacidad de Fargate y EC2, y es compatible con instancias administradas de Amazon ECS. En el caso de Fargate, Amazon ECS redistribuirá automáticamente las tareas entre las zonas de disponibilidad disponibles para mantener el equilibrio. En el caso de los proveedores de capacidad de EC2, Amazon ECS reequilibra las tareas entre las instancias de contenedor existentes en la medida en que sea posible, y respeta las estrategias y restricciones de ubicación definidas. Sin embargo, Amazon ECS no puede lanzar nuevas instancias en zonas de disponibilidad infrautilizadas como parte del proceso de reequilibrio, lo que limita el reequilibrio a las instancias de contenedor existentes.
+ El reequilibrio de las zonas de disponibilidad funciona en las siguientes configuraciones:
  + Servicios que utilizan la estrategia `Replica`
  + Los servicios que especifican la zona de disponibilidad se distribuyen como primera estrategia de ubicación de tareas o no especifican una estrategia de ubicación.
+ No puede utilizar el reequilibrio de zonas de disponibilidad con servicios que cumplan alguno de los siguientes criterios:
  + Utiliza la estrategia `Daemon`
  + Utiliza el tipo de lanzamiento `EXTERNAL` (ECS Anywhere)
  + Utiliza el 100 % para el valor de `maximumPercent`
  + Utiliza un equilibrador de carga clásico
  + Utiliza `attribute:ecs.availability-zone` como restricción de ubicación de tareas

## Estrategias y restricciones de ubicación con el reequilibrio de las zonas de disponibilidad
<a name="service-rebalancing-placement-constraints"></a>

Las estrategias de ubicación determinan la forma en que Amazon ECS selecciona las instancias de contenedor y las zonas de disponibilidad para finalizar la ubicación de tareas. Las restricciones de ubicación de las tareas son reglas que determinan si una tarea puede ejecutarse en una instancia de contenedor específica.

En el caso de EC2, puede usar estrategias de ubicación y restricciones de ubicación junto con el reequilibrio de la zona de disponibilidad. Sin embargo, para que el reequilibrio de las zonas de disponibilidad funcione, la estrategia de distribución de las zonas de disponibilidad debe ser la primera estrategia especificada.

El reequilibrio de la zona de disponibilidad es compatible con varias combinaciones de estrategias de ubicación. Por ejemplo, puede crear una estrategia que primero distribuye las tareas de forma uniforme en las zonas de disponibilidad y, a continuación, agrupa las tareas en contenedores en función de la memoria de cada zona de disponibilidad. En este caso, el reequilibrio de las zonas de disponibilidad funciona porque primero se especifica la estrategia de distribución de las zonas de disponibilidad.

Es importante tener en cuenta que el reequilibrio de las zonas de disponibilidad no funcionará si la primera estrategia de la matriz de estrategias de ubicación no es un componente de distribución de las zonas de disponibilidad. Este requisito garantiza que el objetivo principal de la distribución de tareas sea mantener el equilibrio entre las zonas de disponibilidad, lo cual es crucial para una alta disponibilidad.

Para obtener más información sobre las estrategias y restricciones de ubicación de tareas, consulte [Cómo coloca Amazon ECS las tareas en las instancias de contenedor](task-placement.md).

No se admiten las estrategias ni las restricciones de ubicación de tareas para tareas que utilizan Fargate. Fargate hará todo lo posible para distribuir las tareas entre las zonas de disponibilidad accesibles. Si el proveedor de capacidad incluye Fargate y Fargate Spot, el comportamiento de distribución es independiente para cada proveedor de capacidad.

La estrategia de ejemplo siguiente distribuye las tareas de forma uniforme en las zonas de disponibilidad y, a continuación, agrupa las tareas en contenedores en función de la memoria de cada zona de disponibilidad. El reequilibrio de la zona de disponibilidad es compatible con el servicio porque la estrategia de `spread` es lo primero.

```
"placementStrategy": [
    {
        "field": "attribute:ecs.availability-zone",
        "type": "spread"
    },
    {
        "field": "memory",
        "type": "binpack"
    }
]
```

## Activación del reequilibrio de la zona de disponibilidad
<a name="service-rebalancing-use"></a>

Debe habilitar el reequilibrio de la zona de disponibilidad para los servicios nuevos y existentes.

Puede habilitar y deshabilitar el reequilibrio de zonas de disponibilidad mediante la consola, las API, la AWS CLI o la CloudFormation.

El comportamiento predeterminado de `AvailabilityZoneRebalancing` difiere entre las solicitudes de creación y actualización:
+ Para las solicitudes de creación de servicios, cuando no se especifica ningún valor para `AvailabilityZoneRebalancing`, Amazon ECS establece el valor predeterminado en `ENABLED`.
+ Para las solicitudes de actualización de servicios, cuando no se especifica ningún valor para `AvailabilityZoneRebalancing`, Amazon ECS utiliza de forma predeterminada el valor `AvailabilityZoneRebalancing` del servicio existente. Si el servicio nunca tuvo un valor `AvailabilityZoneRebalancing` establecido, Amazon ECS lo trata como `DISABLED`.


| Tipo de servicio | API | Consola | CLI | 
| --- | --- | --- | --- | 
| Existentes | [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) |  [Actualización de un servicio de Amazon ECS](update-service-console-v2.md)  | [update-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html) | 
| New | [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html) |  [Creación de una implementación de actualización continua de Amazon ECS](create-service-console-v2.md)  | [create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html) | 

En el siguiente ejemplo se muestra cómo habilitar el reequilibrio de servicios al crear un nuevo servicio:

```
aws ecs create-service \
    --cluster my-cluster \
    --service-name my-service \
    --task-definition my-task-definition:1 \
    --desired-count 6 \
    --availability-zone-rebalancing ENABLED
```

# Seguimiento del reequilibrio de las zonas de disponibilidad de Amazon ECS
<a name="track-service-rebalancing"></a>

Puede comprobar si el reequilibrio de las zonas de disponibilidad está habilitado para un servicio en la consola o mediante una llamada a `describe-services`. El siguiente ejemplo se puede utilizar para ver el estado con la CLI.

La respuesta será `ENABLED` o `DISABLED`.

```
aws ecs describe-services \
    --services service-name \
    --cluster cluster-name \
    --query services[0].availabilityZoneRebalancing
```

## Eventos de servicio
<a name="service-info-events"></a>

Amazon ECS envía eventos de acciones de servicio para ayudar a comprender el ciclo de vida del reequilibrio de la zona de disponibilidad. 


| Evento | Escenario | Tipo | Más información | 
| --- | --- | --- | --- | 
| SERVICE\$1REBALANCING\$1STARTED | Amazon ECS inicia una operación de reequilibrio de la zona de disponibilidad. | INFO | [service (*nombre-del-servicio*) is not AZ balanced with *número-de-tareas* tasks in *zona de disponibilidad 1*, *número-de-tareas* in *zona de disponibilidad 2*, and *número-de-tareas* in *zona de disponibilidad 3*. El reequilibrio de la zona de disponibilidad está en curso.](service-rebalancing-event-messages-list.md#service-rebalancing-started) | 
| SERVICE\$1REBALANCING\$1COMPLETED | Se completa la operación de reequilibrio de la zona de disponibilidad. |  INFO | [service (*nombre-del-servicio*) is AZ balanced with *número-de-tareas* tasks in *zona de disponibilidad 1*, *número-de-tareas* tasks in *zona de disponibilidad 2*, and *número-de-tareas* tasks in *zona de disponibilidad 3*.](service-rebalancing-event-messages-list.md#service-rebalancing-completed) | 
| TASKS\$1STARTED | Amazon ECS inicia correctamente las tareas como parte de la operación de reequilibrio de la zona de disponibilidad | INFO | [*nombre-del-servicio* has started *número-de-tareas* tasks in *zona de disponibilidad* to AZ Rebalance: *id-de-tareas*.](service-rebalancing-event-messages-list.md#service-rebalancing-tasks-started) | 
| TASKS\$1STOPPED | Amazon ECS detiene correctamente las tareas como parte de la operación de reequilibrio de la zona de disponibilidad. | INFO | [*nombre-del-servicio* has stopped *número-de-tareas* running tasks in *zona de disponibilidad* due to AZ rebalancing: *id-de-tarea*.](service-rebalancing-event-messages-list.md#service-rebalancing-tasks-stopped) | 
| SERVICE\$1TASK\$1PLACEMENT\$1FAILURE | Amazon ECS no pudo iniciar una tarea como parte de la operación de reequilibrio de la zona de disponibilidad. | ERROR | Para EC2, consulte [service (*nombre-del-servicio*) is unable to place a task in *zona de disponibilidad* because no container instance met all of its requirements.](service-rebalancing-event-messages-list.md#service-rebalancing-placement-failure-instance) Para Fargate, consulte [service (*nombre-del-servicio*) is unable to place a task in *zona de disponibilidad*.](service-rebalancing-event-messages-list.md#service-rebalancing-placement-failure) | 
| TASKSET\$1SCALE\$1IN\$1FAILURE\$1BY\$1TASK\$1PROTECTION | La operación de reequilibrio de la zona de disponibilidad está bloqueada porque se utiliza la protección de tareas. | INFO | [service (*nombre-del-servicio*) was unable to AZ Rebalance because *nombre-del-conjunto-de-tareas* was unable to scale in due to *motivo*.](service-rebalancing-event-messages-list.md#service-rebalancing-task-protection-failure) | 
| SERVICE\$1REBALANCING\$1STOPPED | La operación de reequilibrio de la zona de disponibilidad se detuvo. Amazon ECS envía eventos adicionales que proporcionan más información. | INFO | [service (*nombre-del-servicio*) stopped AZ Rebalancing.](service-rebalancing-event-messages-list.md#service-rebalancing-operation-stopped) | 

## Eventos de cambio de estado de tarea
<a name="task-state-change-events"></a>

Amazon ECS envía un evento de cambio de estado de la tarea (`START`) para cada tarea que se inicia como parte del proceso de reequilibrio.

Amazon ECS envía un evento de cambio de estado de la tarea (`STOPPED`) por cada tarea que detiene como parte del proceso de reequilibrio. El motivo está establecido en `Availability-zone rebalancing initiated by (deployment ecs-svc/deployment-id)`.

Para obtener más información acerca de los eventos, consulte [Eventos de cambio de estado de tarea de Amazon ECS](ecs_task_events.md).

## Solución de problemas de reequilibrio de servicios
<a name="service-rebalancing-troubleshooting"></a>

Si tiene problemas con el reequilibrio de los servicios, tenga en cuenta los siguientes pasos de solución de problemas:

El reequilibrio no se inicia  
Verifique lo siguiente:  
+ El reequilibrio de servicios está activado para su servicio
+ El servicio usa una configuración compatible (consulte [Consideraciones para configurar el reequilibrio de zonas de disponibilidad](#service-rebalancing-configurations))
+ El servicio alcanzó un estado estable

Errores en la ubicación de las tareas durante el reequilibrio  
Si ve eventos `SERVICE_TASK_PLACEMENT_FAILURE`:  
+ Para EC2: compruebe si tiene instancias de contenedor disponibles en la zona de disponibilidad de destino
+ Para Fargate: compruebe si hay restricciones de recursos o cuotas de servicio que limiten la ubicación de las tareas
+ Revise las restricciones de ubicación de tareas para asegurarse de que no impidan una distribución adecuada de estas

El reequilibrio se detiene inesperadamente  
Si ve eventos `SERVICE_REBALANCING_STOPPED`:  
+ Compruebe si hay alguna protección de tareas que pueda estar bloqueando la operación
+ Búsqueda de implementaciones de servicios simultáneas que puedan interrumpir el reequilibrio
+ Revise los eventos de servicio para obtener información adicional sobre por qué se detuvo el reequilibrio

## Prácticas recomendadas para el reequilibrio de servicios
<a name="service-rebalancing-best-practices"></a>

Siga estas prácticas recomendadas para sacar el máximo provecho del reequilibrio de servicio:
+ **Monitoree las operaciones de reequilibrio**: configure las alarmas de CloudWatch para monitorear los eventos de servicio relacionados con el reequilibrio e identificar rápidamente cualquier problema.
+ **Tenga en cuenta el impacto en el rendimiento**: tenga en cuenta que las operaciones de reequilibrio pueden aumentar temporalmente el uso de los recursos, ya que se inician nuevas tareas antes de que se detengan las antiguas.
+ **Utilice la protección de tareas de forma estratégica**: si tiene tareas críticas que no deberían finalizarse durante el reequilibrio, considere la posibilidad de utilizar la protección de tareas.
+ **Planifique la capacidad de EC2**: para EC2, asegúrese de tener suficientes instancias de contenedor en todas las zonas de disponibilidad para permitir un reequilibrio efectivo.
+ **Compruebe el comportamiento de reequilibrio**: antes de confiar en el reequilibrio en producción, compruebe cómo se comportan sus servicios durante las operaciones de reequilibrio en un entorno que no sea de producción.

# Uso del equilibrador de carga para distribuir el tráfico de servicio de Amazon ECS
<a name="service-load-balancing"></a>

Opcionalmente, su servicio se puede configurar para usar Elastic Load Balancing a fin de distribuir el tráfico de manera uniforme entre las tareas de su servicio.

**nota**  
Cuando utiliza conjuntos de tareas, todas las tareas del conjunto deben configurarse para utilizar Elastic Load Balancing o para no utilizar Elastic Load Balancing. 

Los servicios de Amazon ECS alojados en AWS Fargate admiten los equilibradores de carga de aplicación, los equilibradores de carga de red y los equilibradores de carga de puerta de enlace. Utilice la siguiente tabla para obtener información sobre el tipo de equilibrador de carga que se debe utilizar.


| Tipo de equilibrador de carga | Utilizar en estos casos | 
| --- | --- | 
|  Equilibrador de carga de aplicación  | Dirija el tráfico HTTP o HTTPS (o de capa 7).Los Application Load Balancers ofrecen varias características nuevas que los hacen interesantes para utilizar con los servicios Amazon ECS: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/service-load-balancing.html) | 
| Equilibrador de carga de red | Dirija el tráfico TCP o UDP (o de capa 4). | 
| Balanceador de carga de gateway | Dirija el tráfico TCP o UDP (o de capa 4). Utilice dispositivos virtuales, como firewalls, sistemas de prevención y detección de intrusiones, y sistemas de inspección profunda de paquetes. | 

Recomendamos utilizar los equilibradores de carga de aplicación para los servicios de Amazon ECS de manera que pueda aprovechar estas características más recientes, a menos que el servicio requiera una característica que solo esté disponible en los equilibradores de carga de aplicación o equilibradores de carga de puerta de enlace. Para obtener más información acerca de Elastic Load Balancing y las diferencias entre estos tipos de balanceadores de carga, consulte la [Guía del usuario de Elastic Load Balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/).

Con el equilibrador de carga, solo se paga por lo que se usa. Para obtener más información, consulte [Precios de Elastic Load Balancing](https://aws.amazon.com/elasticloadbalancing/pricing/). 

# Optimización de los parámetros de comprobación de estado del equilibrador de carga para Amazon ECS
<a name="load-balancer-healthcheck"></a>

Los equilibradores de carga dirigen las solicitudes únicamente a los destinos en buen estado de las zonas de disponibilidad del equilibrador de carga. Cada destino está registrado en un grupo de destino. El equilibrador de carga comprueba el estado de cada destino; para ello, utiliza la configuración de comprobación de estado de los grupos de destino. Una vez que registra el destino, debe superar una comprobación de estado para que se considere que se encuentra en buen estado. Amazon ECS supervisa el equilibrador de carga. El equilibrador de carga envía periódicamente comprobaciones de estado al contenedor de Amazon ECS. El agente de Amazon ECS supervisa el equilibrador de carga y espera a que este informe sobre el estado del contenedor. Lo hace antes de considerar que el contenedor esté en buen estado.

Dos parámetros de comprobación de estado de Elastic Load Balancing afectan a la velocidad de implementación:
+ Intervalo de comprobaciones de estado: determina la cantidad aproximada de tiempo, en segundos, entre comprobaciones de estado de un contenedor individual. De forma predeterminada, el equilibrador de carga se comprueba cada 30 segundos.

  Este parámetro se denomina:
  + `HealthCheckIntervalSeconds` en la API de Elastic Load Balancing
  + **Intervalo** en la consola de Amazon EC2
+ Recuento de umbral en buen estado: determina la cantidad de comprobaciones de estado consecutivas correctas que deben superarse para considerar que un contenedor con un estado incorrecto vuelve a estar en estado correcto. De forma predeterminada, el equilibrador de carga requiere pasar cinco comprobaciones de estado antes de informar que el contenedor de destino está en buen estado.

  Este parámetro se denomina:
  + `HealthyThresholdCount` en la API de Elastic Load Balancing
  + **Umbral en buen estado** en la consola de Amazon EC2

**Importante:** Para los destinos recién registrados, solo se requiere una comprobación de estado correcta para considerar que el destino está en buen estado, independientemente del valor establecido para el umbral de estado correcto. El umbral de estado correcto solo se aplica cuando un destino está pasando de un estado incorrecto a un estado correcto.

Con la configuración predeterminada, si el destino se vuelve incorrecto y luego se recupera, el tiempo total para determinar el estado de un contenedor es de 2 minutos y 30 segundos (`30 seconds * 5 = 150 seconds`).

Puede acelerar el proceso de comprobación de estado si el servicio se inicia y se estabiliza en menos de 10 segundos. Para acelerar el proceso, reduzca el intervalo de comprobación de estado y el recuento de umbral de estado.
+ `HealthCheckIntervalSeconds` (nombre de la API de Elastic Load Balancing) o **Intervalo** (nombre de la consola de Amazon EC2): 5
+ `HealthyThresholdCount` (nombre de la API de Elastic Load Balancing) o **Umbral de estado correcto** (nombre de la consola de Amazon EC2): 2

Con esta configuración, el proceso de comprobación de estado tarda 10 segundos, en lugar de los 2 minutos y 30 segundos predeterminados.

Para obtener más información acerca de las comprobaciones de estado de Elastic Load Balancing, consulte [Health checks for your target groups](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html) en la *Guía de usuario de Elastic Load Balancing*.

# Optimización de los parámetros de drenaje de conexiones del equilibrador de carga para Amazon ECS
<a name="load-balancer-connection-draining"></a>

Para permitir la optimización, los clientes mantienen una conexión permanente con el servicio de contenedores. Esto permite a las solicitudes posteriores de ese cliente reutilizar la conexión existente. Cuando quiera detener el tráfico hacia un contenedor, notifica al equilibrador de carga. El equilibrador de carga hace una comprobación periódica para ver si el cliente cerró la conexión persistente. Amazon ECS supervisa el equilibrador de carga y espera a que este informe de que la conexión permanente está cerrada (el destino está en un estado `UNUSED`).

El tiempo que el equilibrador de carga espera para mover el destino al estado `UNUSED` es el retraso en la cancelación del registro. Puede configurar el siguiente parámetro del equilibrador de carga para acelerar las implementaciones.
+ `deregistration_delay.timeout_seconds`: 300 (predeterminado)

Si tiene un servicio con un tiempo de respuesta inferior a 1 segundo, establezca el parámetro en el siguiente valor para que el equilibrador de carga solo espere 5 segundos antes de interrumpir la conexión entre el cliente y el servicio de backend: 
+ `deregistration_delay.timeout_seconds`: 5 

**nota**  
No establezca el valor en 5 segundos cuando tenga un servicio con solicitudes de larga duración, como cargas lentas de archivos o conexiones de streaming.

## Capacidad de respuesta de SIGTERM
<a name="sigterm"></a>

Amazon ECS envía primero una señal detención a la tarea para notificar que la aplicación debe finalizar y cerrarse. Esta señal se puede definir en la imagen de su contenedor con la instrucción STOPSIGNAL y, de forma predeterminada, será SIGTERM. A continuación, Amazon ECS envía un mensaje SIGKILL. Cuando las aplicaciones ignoran el SIGTERM, el servicio Amazon ECS debe esperar a enviar la señal SIGKILL para terminar el proceso. 

El tiempo que Amazon ECS espera para enviar el mensaje SIGKILL viene determinado por la siguiente opción de agente de Amazon ECS:
+ `ECS_CONTAINER_STOP_TIMEOUT`: 30 (predeterminado)

  Para obtener más información sobre el parámetro de agente contenedor, consulte [Amazon ECS Container Agent](https://github.com/aws/amazon-ecs-agent/blob/master/README.md) en GitHub.

Para acelerar el periodo de espera, defina el parámetro del agente de Amazon ECS en el siguiente valor:
+ `ECS_CONTAINER_STOP_TIMEOUT`: 2

  Si la solicitud tarda más de 1 segundo, multiplique el valor por 2 y utilice ese número como valor.

En este caso, Amazon ECS espera 2 segundos a que se cierre el contenedor y, a continuación, envía un mensaje SIGKILL cuando la aplicación no se detiene.

También puede modificar el código de la aplicación para capturar la señal SIGTERM y reaccionar ante ella. El siguiente es un ejemplo en JavaScript: 

```
process.on('SIGTERM', function() { 
  server.close(); 
})
```

Este código hace que el servidor HTTP deje de aceptar nuevas solicitudes, termine de responder a las solicitudes en curso y, a continuación, finalice el proceso de Node.js porque el bucle de eventos no tiene más tareas pendientes. Por lo tanto, si el proceso tarda solo 500 ms en finalizar sus solicitudes en tránsito, finaliza antes de tiempo sin tener que esperar a que acabe el tiempo de espera y recibir un SIGKILL. 

# Uso de un equilibrador de carga de aplicaciones para Amazon ECS
<a name="alb"></a>

Un Application Load Balancer toma decisiones de enrutamiento en la capa de aplicación (HTTP/HTTPS), admite el enrutamiento basado en rutas y puede dirigir las solicitudes a uno o varios puertos de cada instancia de contenedor del clúster. Los Application Load Balancers admiten el mapeo de puertos de host dinámico. Por ejemplo, si la definición de contenedor de la tarea especifica el puerto 80 para un puerto de contenedor NGINX y el puerto 0 para el puerto de host, el puerto de host se elige dinámicamente en el rango de puertos efímeros de la instancia de contenedor (como, por ejemplo, del 32768 al 61000 en las AMI optimizadas para Amazon ECS más recientes). Cuando se lanza la tarea, el contenedor NGINX se registra en el equilibrador de carga de aplicación como una combinación de ID de instancia y puerto, y el tráfico se distribuye al ID de la instancia y al puerto correspondientes a dicho contenedor. Este mapeo dinámico le permite tener varias tareas desde un servicio único en la misma instancia de contenedor. Para obtener más información, consulte la [Guía del usuario de Application Load Balancers](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/).

Para obtener información sobre las prácticas recomendadas para establecer parámetros que aceleren las implementaciones, consulte los siguientes recursos:
+ [Optimización de los parámetros de comprobación de estado del equilibrador de carga para Amazon ECS](load-balancer-healthcheck.md)
+ [Optimización de los parámetros de drenaje de conexiones del equilibrador de carga para Amazon ECS](load-balancer-connection-draining.md)

Al utilizar los equilibradores de carga de aplicación con Amazon ECS, tenga en cuenta lo siguiente:
+ Amazon ECS requiere el rol de IAM vinculado al servicio, que proporciona los permisos necesarios para registrar y anular el registro de destinos en el balanceador de carga al crear y detener tareas. Para obtener más información, consulte [Uso de roles vinculados al servicio para Amazon ECS](using-service-linked-roles.md).
+ En el caso de los servicios en una configuración de solo IPv6, debe establecer el tipo de dirección IP del grupo de destino del equilibrador de carga de aplicación en `dualstack` o `dualstack-without-public-ipv4`.
+ Para los servicios con tareas que utilizan el modo de red `awsvpc`, al crear un grupo de destino para el servicio, debe elegir `ip` como tipo de destino, no `instance`. Esto se debe a que las tareas que utilizan el modo de red `awsvpc` están asociadas a una interfaz de red elástica, no a una instancia de Amazon EC.
+ Si el servicio requiere acceso a varios puertos con equilibrador de carga, como el puerto 80 y el puerto 443 para un servicio HTTP o HTTPS, puede configurar dos oyentes. Un agente de escucha es responsable de las solicitudes HTTPS que reenvían la solicitud al servicio y otro agente de escucha es responsable de redirigir las solicitudes HTTP al puerto HTTPS adecuado. Para obtener más información, consulte [Creación de un agente de escucha para el Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-listener.html) en la *Guía del usuario de Application Load Balancers*.
+ La configuración de subred del balanceador de carga debe incluir todas las zonas de disponibilidad en las que residen las instancias de contenedor.
+ Después de crear un servicio, la configuración del equilibrador de carga no se puede cambiar desde la Consola de administración de AWS. Puede usar el Copiloto de AWS, AWS CloudFormation, AWS CLI o SDK para modificar la configuración del equilibrador de carga solo del controlador de implementación progresiva `ECS`, no AWS CodeDeploy azul/verde o exterior. Cuando agrega, actualiza o elimina una configuración de equilibrador de carga, Amazon ECS inicia una nueva implementación con la configuración actualizada de Elastic Load Balancing. Esto hace que las tareas se registren y eliminen el registro de los equilibradores de carga. Le recomendamos que lo verifique en un entorno de prueba antes de actualizar la configuración de Elastic Load Balancing. Para obtener más información acerca de cómo modificar la configuración, consulte [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) en la *Referencia de la API de Amazon Elastic Container Service*. 
+ Si la tarea de un servicio no supera los criterios de comprobación de estado del equilibrador de carga, la tarea se detiene y se reinicia. Este proceso continúa hasta que el servicio alcanza el número de tareas en ejecución deseadas.
+ Si está teniendo problemas con los servicios habilitados para el balanceador de carga, consulte [Solución de problemas de los equilibradores de carga de servicio en Amazon ECS](troubleshoot-service-load-balancers.md).
+ Cuando use el tipo de destino `instance`, las tareas y el equilibrador de carga deben estar en la misma VPC. Cuando se utiliza el tipo de destino `ip`, se admite la conectividad entre VPC.
+ Utilice un grupo de destino único para cada servicio. 

  El uso del mismo grupo de destino para varios servicios puede provocar problemas durante la implementación del servicio.
+ Debe especificar los grupos de destino que están asociados a un equilibrador de carga de aplicación.

Para obtener información sobre cómo crear un equilibrador de carga de aplicaciones, consulte [Create an Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html) en *Application Load Balancers *

# Uso de un equilibrador de carga de red para Amazon ECS
<a name="nlb"></a>

Un Network Load Balancer toma las decisiones de enrutamiento en la capa de transporte (TCP/SSL). Puede gestionar millones de solicitudes por segundo. Una vez que el balanceador de carga ha recibido una conexión, selecciona un destino del grupo de destinos para la regla predeterminada por medio de un algoritmo hash de flujo de direccionamiento. Intenta abrir una conexión TCP con el destino seleccionado en el puerto especificado en la configuración del agente de escucha. Reenvía la solicitud sin modificar los encabezados. Los Network Load Balancers admiten el mapeo de puertos de host dinámico. Por ejemplo, si la definición de contenedor de la tarea especifica el puerto 80 para un puerto de contenedor NGINX y el puerto 0 para el puerto de host, el puerto de host se elige dinámicamente en el rango de puertos efímeros de la instancia de contenedor (como, por ejemplo, del 32768 al 61000 en las AMI optimizadas para Amazon ECS más recientes). Cuando se lanza la tarea, el contenedor NGINX se registra en el Network Load Balancer como una combinación de ID de instancia y puerto, y el tráfico se distribuye al ID de la instancia y al puerto correspondiente a ese contenedor. Este mapeo dinámico le permite tener varias tareas desde un servicio único en la misma instancia de contenedor. Para obtener más información, consulte la [Guía del usuario de balanceadores de carga de red](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/).

Para obtener información sobre las prácticas recomendadas para establecer parámetros que aceleren las implementaciones, consulte los siguientes recursos:
+ [Optimización de los parámetros de comprobación de estado del equilibrador de carga para Amazon ECS](load-balancer-healthcheck.md)
+ [Optimización de los parámetros de drenaje de conexiones del equilibrador de carga para Amazon ECS](load-balancer-connection-draining.md)

Al utilizar los equilibradores de carga de red con Amazon ECS, tenga en cuenta lo siguiente:
+ Amazon ECS requiere el rol de IAM vinculado al servicio, que proporciona los permisos necesarios para registrar y anular el registro de destinos en el balanceador de carga al crear y detener tareas. Para obtener más información, consulte [Uso de roles vinculados al servicio para Amazon ECS](using-service-linked-roles.md).
+ No se pueden asociar más de cinco grupos de destino a un servicio.
+ En el caso de los servicios en una configuración de solo IPv6, debe establecer el tipo de dirección IP del grupo de destino del equilibrador de carga de red en `dualstack`.
+ Para los servicios con tareas que utilizan el modo de red `awsvpc`, al crear un grupo de destino para el servicio, debe elegir `ip` como tipo de destino, no `instance`. Esto se debe a que las tareas que utilizan el modo de red `awsvpc` están asociadas a una interfaz de red elástica, no a una instancia de Amazon EC2.
+ La configuración de subred del balanceador de carga debe incluir todas las zonas de disponibilidad en las que residen las instancias de contenedor.
+ Después de crear un servicio, la configuración del equilibrador de carga no se puede cambiar desde la Consola de administración de AWS. Puede usar el Copiloto de AWS, AWS CloudFormation, AWS CLI o SDK para modificar la configuración del equilibrador de carga solo del controlador de implementación progresiva `ECS`, no AWS CodeDeploy azul/verde o exterior. Cuando agrega, actualiza o elimina una configuración de equilibrador de carga, Amazon ECS inicia una nueva implementación con la configuración actualizada de Elastic Load Balancing. Esto hace que las tareas se registren y eliminen el registro de los equilibradores de carga. Le recomendamos que lo verifique en un entorno de prueba antes de actualizar la configuración de Elastic Load Balancing. Para obtener más información acerca de cómo modificar la configuración, consulte [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) en la *Referencia de la API de Amazon Elastic Container Service*. 
+ Si la tarea de un servicio no supera los criterios de comprobación de estado del equilibrador de carga, la tarea se detiene y se reinicia. Este proceso continúa hasta que el servicio alcanza el número de tareas en ejecución deseadas.
+ Cuando se utilizan equilibradores de carga de puerta de enlace configurados con direcciones IP como destinos y la conservación de la IP del cliente está desactivada, las solicitudes se ven como procedentes de la dirección IP privada de los equilibradores de carga de puerta de enlace. Esto significa que los servicios detrás de un equilibrador de carga de puerta de enlace se abren de manera efectiva al mundo en cuanto se permiten solicitudes entrantes y comprobaciones de estado en el grupo de seguridad de destino.
+ Para las tareas de Fargate, debe utilizar la versión de la plataforma `1.4.0` (Linux) o `1.0.0` (Windows).
+ Si está teniendo problemas con los servicios habilitados para el balanceador de carga, consulte [Solución de problemas de los equilibradores de carga de servicio en Amazon ECS](troubleshoot-service-load-balancers.md).
+ Cuando use el tipo de destino `instance`, las tareas y el equilibrador de carga deben estar en la misma VPC. Cuando se utiliza el tipo de destino `ip`, se admite la conectividad entre VPC.
+ La conservación de la dirección IP del cliente del equilibrador de carga de red también es compatible con los destinos de Fargate.
+ Utilice un grupo de destino único para cada servicio. 

  El uso del mismo grupo de destino para varios servicios puede provocar problemas durante la implementación del servicio.
+ Debe especificar los grupos de destino que están asociados a un equilibrador de carga de red.

Para obtener información sobre cómo crear un equilibrador de carga de red, consulte [Create a Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html) en *Equilibrador de carga de red *

**importante**  
Si la definición de tareas del servicio utiliza el modo de red `awsvpc` (que es obligatorio para Fargate), se debe elegir `ip` como tipo de destino, no `instance`. Esto se debe a que las tareas que utilizan el modo de red `awsvpc` están asociadas a una interfaz de red elástica, no a una instancia de Amazon EC2.   
No puede registrar instancias por ID de instancia si tienen los siguientes tipos de instancia: C1, CC1, CC2, CG1, CG2, CR1, G1, G2, HI1, HS1, M1, M2, M3 y T1. Puede registrar las instancias de estos tipos por dirección IP. 

# Uso de un equilibrador de carga de puerta de enlace para Amazon ECS
<a name="glb"></a>

Un equilibrador de carga de puerta de enlace opera en la tercera capa del modelo de interconexión de sistemas abiertos (OSI), es decir, la capa de red. Escucha todos los paquetes IP en todos los puertos y reenvía el tráfico al grupo de destino especificado en la regla de oyentes. Mantiene la persistencia de los flujos en un dispositivo de destino específico mediante 5 tuplas (para flujos TCP/UDP) o 3 tuplas (para flujos que no son TCP/UDP). Por ejemplo, si la definición de contenedor de la tarea especifica el puerto 80 para un puerto de contenedor NGINX y el puerto 0 para el puerto de host, el puerto de host se elige dinámicamente en el rango de puertos efímeros de la instancia de contenedor (como, por ejemplo, del 32768 al 61000 en las AMI optimizadas para Amazon ECS más recientes). Cuando se lanza la tarea, el contenedor NGINX se registra en el equilibrador de carga de puerta de enlace como una combinación de ID de instancia y puerto, y el tráfico se distribuye al ID de la instancia y al puerto correspondientes a ese contenedor. Este mapeo dinámico le permite tener varias tareas desde un servicio único en la misma instancia de contenedor. Para obtener más información, consulte [What is a Gateway Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/introduction.html) en *Gateway Load Balancers*.

Para obtener información sobre las prácticas recomendadas para establecer parámetros que aceleren las implementaciones, consulte los siguientes recursos:
+ [Optimización de los parámetros de comprobación de estado del equilibrador de carga para Amazon ECS](load-balancer-healthcheck.md)
+ [Optimización de los parámetros de drenaje de conexiones del equilibrador de carga para Amazon ECS](load-balancer-connection-draining.md)

Tenga en cuenta lo siguiente al utilizar los equilibradores de carga de puerta de enlace con Amazon ECS:
+ Amazon ECS requiere el rol de IAM vinculado al servicio, que proporciona los permisos necesarios para registrar y anular el registro de destinos en el balanceador de carga al crear y detener tareas. Para obtener más información, consulte [Uso de roles vinculados al servicio para Amazon ECS](using-service-linked-roles.md).
+ En el caso de los servicios en una configuración de solo IPv6, debe establecer el tipo de dirección IP del grupo de destino del equilibrador de carga de puerta de enlace en `dualstack`.
+ En el caso de los servicios con tareas que utilizan un modo de red que no sea el de `awsvpc`, no se admiten los equilibradores de carga de puerta de enlace.
+ La configuración de subred del balanceador de carga debe incluir todas las zonas de disponibilidad en las que residen las instancias de contenedor.
+ Después de crear un servicio, la configuración del equilibrador de carga no se puede cambiar desde la Consola de administración de AWS. Puede usar el Copiloto de AWS, AWS CloudFormation, AWS CLI o SDK para modificar la configuración del equilibrador de carga solo del controlador de implementación progresiva `ECS`, no AWS CodeDeploy azul/verde o exterior. Cuando agrega, actualiza o elimina una configuración de equilibrador de carga, Amazon ECS inicia una nueva implementación con la configuración actualizada de Elastic Load Balancing. Esto hace que las tareas se registren y eliminen el registro de los equilibradores de carga. Le recomendamos que lo verifique en un entorno de prueba antes de actualizar la configuración de Elastic Load Balancing. Para obtener más información acerca de cómo modificar la configuración, consulte [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) en la *Referencia de la API de Amazon Elastic Container Service*. 
+ Si la tarea de un servicio no supera los criterios de comprobación de estado del equilibrador de carga, la tarea se detiene y se reinicia. Este proceso continúa hasta que el servicio alcanza el número de tareas en ejecución deseadas.
+ Al utilizar el equilibrador de carga de puerta de enlace configurado con direcciones IP como destinos, las solicitudes se ven como procedentes de la dirección IP privada de los equilibradores de carga de puerta de enlace. Esto significa que los servicios detrás de un equilibrador de carga de puerta de enlace se abren de manera efectiva al mundo en cuanto se permiten solicitudes entrantes y comprobaciones de estado en el grupo de seguridad de destino.
+ Para las tareas de Fargate, debe utilizar la versión de la plataforma `1.4.0` (Linux) o `1.0.0` (Windows).
+ Si está teniendo problemas con los servicios habilitados para el balanceador de carga, consulte [Solución de problemas de los equilibradores de carga de servicio en Amazon ECS](troubleshoot-service-load-balancers.md).
+ Cuando use el tipo de destino `instance`, las tareas y el equilibrador de carga deben estar en la misma VPC. Cuando se utiliza el tipo de destino `ip`, se admite la conectividad entre VPC.
+ Utilice un grupo de destino único para cada servicio. 

  El uso del mismo grupo de destino para varios servicios puede provocar problemas durante la implementación del servicio.
+ Debe especificar los grupos de destino que están asociados a un equilibrador de carga de puerta de enlace.

Para obtener información sobre cómo crear un equilibrador de carga de puerta de enlace, consulte [Introducción a los equilibradores de carga de puertas de enlace](https://docs.aws.amazon.com/elasticloadbalancing/latest/gateway/getting-started.html) en los *equilibradores de carga de puerta de enlace *.

**importante**  
Si la definición de tareas del servicio utiliza el modo de red `awsvpc` (que es obligatorio para Fargate), se debe elegir `ip` como tipo de destino, no `instance`. Esto se debe a que las tareas que utilizan el modo de red `awsvpc` están asociadas a una interfaz de red elástica, no a una instancia de Amazon EC2.   
No puede registrar instancias por ID de instancia si tienen los siguientes tipos de instancia: C1, CC1, CC2, CG1, CG2, CR1, G1, G2, HI1, HS1, M1, M2, M3 y T1. Puede registrar las instancias de estos tipos por dirección IP. 

# Registro de varios grupos de destino en un servicio de Amazon ECS
<a name="register-multiple-targetgroups"></a>

El servicio de Amazon ECS puede atender el tráfico procedente de varios balanceadores de carga y exponer varios puertos con de carga balanceada cuando se especifican varios grupos de destino en una definición de servicio.

Actualmente, si desea crear un servicio que especifique varios grupos de destino, debe crear el servicio mediante la API de Amazon ECS, el SDK, la AWS CLI o una plantilla de CloudFormation. Una vez creado el servicio, puede ver el servicio y los grupos de destino registrados con él con la Consola de administración de AWS. Se debe utilizar `[UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)` para modificar la configuración del balanceador de carga de un servicio existente.

Se puede especificar en una definición de servicio varios grupos de destino utilizando el siguiente formato. Para obtener la sintaxis completa de una definición de servicio, consulte [Plantilla de definición de servicio](sd-template.md).

```
"loadBalancers":[
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456",
      "containerName":"container_name",
      "containerPort":container_port
   },
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321",
      "containerName":"container_name",
      "containerPort":container_port
   }
]
```

## Consideraciones
<a name="multiple-targetgroups-considerations"></a>

Cuando se especifiquen varios grupos de destino en una definición de servicio, debe tenerse en cuenta lo siguiente.
+ En el caso de los servicios que utilizan un Application Load Balancer o un Network Load Balancer, no se pueden asociar más de cinco grupos de destino a un servicio.
+ La especificación de varios grupos de destino en una definición de servicio solo se admite en las siguientes condiciones:
  + El servicio debe utilizar un Application Load Balancer o un Network Load Balancer.
  + El servicio debe utilizar el tipo de controlador de implementación (`ECS`). Puede ser la implementación azul/verde o nativa de Amazon ECS o la implementación de actualizaciones sucesivas.
+ Se admite la especificación de varios grupos de destino para servicios que contengan tareas que utilicen los tipos de lanzamiento de Fargate y EC2.
+ Al crear un servicio que especifica varios grupos de destino, se debe crear el rol vinculado al servicio de Amazon ECS. Para crear el rol, omita el parámetro `role` en las solicitudes de API o la propiedad `Role` en CloudFormation. Para obtener más información, consulte [Uso de roles vinculados al servicio para Amazon ECS](using-service-linked-roles.md).

## Ejemplos de definiciones de servicio
<a name="multiple-targetgroups-examples"></a>

A continuación se muestran unos ejemplos de casos de uso para especificar varios grupos de destino en una definición de servicio. Para obtener la sintaxis completa de una definición de servicio, consulte [Plantilla de definición de servicio](sd-template.md).

### Configuración de equilibradores de carga independientes para el tráfico interno y externo
<a name="multiple-targetgroups-example1"></a>

En el siguiente caso de uso, un servicio utiliza dos balanceadores de carga independientes, uno para el tráfico interno y otro para el tráfico de Internet, para el mismo contenedor y puerto.

```
"loadBalancers":[
   //Internal ELB
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456",
      "containerName":"nginx",
      "containerPort":8080
   },
   //Internet-facing ELB
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321",
      "containerName":"nginx",
      "containerPort":8080
   }
]
```

### Exposición de varios puertos desde el mismo contenedor
<a name="multiple-targetgroups-example1"></a>

En el siguiente caso de uso, un servicio utiliza un balanceador de carga pero expone varios puertos desde el mismo contenedor. Por ejemplo, un contenedor Jenkins podría exponer el puerto 8080 para la interfaz web de Jenkins y el puerto 50000 para la API.

```
"loadBalancers":[
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456",
      "containerName":"jenkins",
      "containerPort":8080
   },
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321",
      "containerName":"jenkins",
      "containerPort":50000
   }
]
```

### Exposición de puertos desde varios contenedores
<a name="multiple-targetgroups-example3"></a>

En el siguiente caso de uso, un servicio utiliza un balanceador de carga y dos grupos de destino para exponer puertos desde contenedores independientes.

```
"loadBalancers":[
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_1/1234567890123456",
      "containerName":"webserver",
      "containerPort":80
   },
   {  
      "targetGroupArn":"arn:aws:elasticloadbalancing:region:123456789012:targetgroup/target_group_name_2/6543210987654321",
      "containerName":"database",
      "containerPort":3306
   }
]
```

# Escalado automático de su servicio de Amazon ECS
<a name="service-auto-scaling"></a>

El *escalado automático* es la posibilidad de aumentar o disminuir automáticamente la cantidad de tareas deseada en el servicio de Amazon ECS. Amazon ECS utiliza el servicio de Application Auto Scaling para proporcionar esta funcionalidad. Para obtener más información, consulte la [Guía del usuario de Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html).

Amazon ECS publica métricas de CloudWatch de la utilización de memoria y CPU promedio del servicio. Para obtener más información, consulte [Métricas de uso de los servicios de Amazon ECS](service_utilization.md). Puede usar estas y otras métricas de CloudWatch para escalar horizontalmente el servicio (agregar más tareas) a fin de abordar demandas elevadas en horas pico y para reducir horizontalmente el servicio (ejecutar menos tareas) a fin de disminuir los costos durante períodos de poco uso. 

Service Auto Scaling de Amazon ECS admite los siguientes tipos de escalado automático:
+ [Uso de una métrica de destino para escalar los servicios de Amazon ECS](service-autoscaling-targettracking.md): aumenta o reduce el número de tareas que ejecuta el servicio en función del valor de destino para una métrica determinada. Se asemeja a los termostatos que se utilizan para mantener la temperatura del hogar. Se selecciona la temperatura y el termostato hace el resto.
+ [Uso de incrementos predefinidos en función de las alarmas de CloudWatch para escalar los servicios de Amazon ECS](service-autoscaling-stepscaling.md): aumenta o reduce el número de tareas que ejecuta el servicio en función de una serie de ajustes de escalado, denominados ajustes por pasos, que variarán en función del tamaño de la interrupción de alarma. 
+ [Uso de acciones programadas para escalar los servicios de Amazon ECS](service-autoscaling-schedulescaling.md): aumente o reduzca el número de tareas que ejecuta el servicio en función de la fecha y la hora.
+ [Uso de patrones históricos para escalar los servicios de Amazon ECS con escalado predictivo](predictive-auto-scaling.md): aumenta o disminuye el número de tareas que ejecuta el servicio en función del análisis de datos de carga históricos para detectar patrones diarios o semanales en los flujos de tráfico. 

   

## Consideraciones
<a name="auto-scaling-concepts"></a>

Cuando utilice las políticas de escalado, tenga en cuenta lo siguiente:
+ Amazon ECS envía métricas a CloudWatch a intervalos de 1 minuto. Las métricas no están disponibles hasta que los clústeres y servicios envían las métricas a CloudWatch, y no puede crear alarmas de CloudWatch para métricas que no existen. 
+ Las políticas de escalado admiten un período de recuperación. Este es la cantidad de tiempo, en segundos, que se debe esperar a que surta efecto una actividad de escalado anterior. 
  + En el caso de las políticas de escalado horizontal, la intención es realizar el escalado horizontal de manera continua (pero no excesiva). Después de que Service Auto Scaling efectúa correctamente el escalado horizontal a través de una política de escalado por pasos, comienza a calcular el tiempo de recuperación. La política de escalado no volverá a aumentar la capacidad deseada a menos que se inicie el escalado horizontal o finalice el periodo de recuperación. Mientras el periodo de recuperación del escalado ascendente esté en vigor, la capacidad agregada por la actividad inicial de escalado ascendente se considerará parte de la capacidad deseada para la siguiente actividad de escalado ascendente. 
  + En el caso de eventos de reducción horizontal, la intención es efectuar un reducción horizontal de forma conservadora a fin de proteger la disponibilidad de la aplicación, de modo que las actividades de reducción horizontal se bloqueen hasta que haya transcurrido el período de recuperación. No obstante, si otra alarma inicia una actividad de escalado horizontal durante el periodo de recuperación de la reducción horizontal, Service Auto Scaling escala horizontalmente el destino de inmediato. En este caso, el periodo de recuperación de reducción horizontal se detiene y no se completa. 
+ El programador de servicios respeta el recuento deseado en todo momento, pero si dispone de políticas y alarmas de escalado activas en un servicio, Service Auto Scaling podría cambiar el recuento deseado que se estableció manualmente.
+ Si el recuento deseado de un servicio se establece por debajo de su valor de capacidad mínimo y una alarma desencadena una actividad de escalado horizontal, Service Auto Scaling aumenta el recuento deseado al valor de capacidad mínimo y, luego, continúa con el escalado horizontal, según corresponda, en función de la política de escalado asociada a la alarma. No obstante, una actividad de reducción horizontal no ajusta el recuento deseado, porque ya se encuentra por debajo del valor de capacidad mínimo.
+ Si el recuento deseado de un servicio se establece por encima de su valor de capacidad máximo y una alarma desencadena una actividad de reducción horizontal, Service Auto Scaling escala el recuento deseado al valor de capacidad máximo y, luego, continúa con la reducción horizontal, según corresponda, en función de la política de escalado asociada a la alarma. No obstante, una actividad de reducción de escala no ajusta el recuento deseado, porque ya se encuentra por encima del valor de capacidad máximo.
+ Durante las actividades de escalado, el recuento de tareas en ejecución real de un servicio es el valor que Service Auto Scaling utiliza como punto de inicio, en contraposición con el recuento deseado. Esto es lo que se supone que es la capacidad de procesamiento. Esto impide un escalado excesivo (descontrolado) que podría no satisfacerse, por ejemplo, si no hubiera suficientes recursos de instancia de contenedor para colocar las tareas adicionales. Si la capacidad de la instancia de contenedor está disponible más tarde, la actividad de escalado pendiente podría tener éxito y, entonces, las actividades de escalado adicionales podrían continuar después del periodo de recuperación.
+ Si desea que el recuento de tareas se escale a cero cuando no haya trabajo por hacer, establezca una capacidad mínima de 0. Con las políticas de escalado de seguimiento de destino, cuando la capacidad real es 0 y la métrica indica que hay demanda de carga de trabajo, Service Auto Scaling espera que se envíe un punto de datos antes del escalado horizontal. En este caso, se escala horizontalmente la cantidad mínima posible como punto de partida y, a continuación, reanuda el escalado en función del recuento real de tareas en ejecución.
+ El escalado automático de aplicaciones desactiva los procesos de reducir horizontalmente mientras se llevan a cabo las implementaciones de Amazon ECS. Sin embargo, los procesos de escalado horizontal continúan produciéndose durante una implementación, a menos que se suspendan. Este comportamiento no se aplica a los servicios de Amazon ECS que utilizan el controlador de implementación externo. Para obtener más información, consulte [Escalado automático de servicios e implementaciones](#service-auto-scaling-deployments).
+ Dispone de varias opciones de escalado automático de aplicaciones para las tareas de Amazon ECS. El seguimiento de destinos es el modo más fácil de utilizar. Con él, todo lo que necesita hacer es establecer un valor de destino para una métrica, como la utilización media de la CPU. Luego, el escalador automático administra de forma automática la cantidad de tareas necesarias para alcanzar ese valor. Con el escalado por pasos, puede reaccionar más rápidamente a los cambios en la demanda, ya que define los umbrales específicos para sus métricas de escalado y cuántas tareas agregar o eliminar cuando se superen los umbrales. Y, lo que es más importante, puede reaccionar muy rápidamente ante los cambios en la demanda al minimizar el tiempo que una alarma supera el umbral.

Para más información sobre las prácticas recomendadas para el escalado automático de servicios, consulte [Optimización del escalado automático de servicios de Amazon ECS](capacity-autoscaling-best-practice.md).

## Escalado automático de servicios e implementaciones
<a name="service-auto-scaling-deployments"></a>

El escalado automático de aplicaciones desactiva los procesos de reducir horizontalmente mientras se llevan a cabo las implementaciones de Amazon ECS. Sin embargo, los procesos de escalado horizontal continúan produciéndose durante una implementación, a menos que se suspendan. Este comportamiento no se aplica a los servicios de Amazon ECS que utilizan el controlador de implementación externo. Si desea suspender los procesos de escalado horizontal mientras las implementaciones están en curso, siga estos pasos.

1. Ejecute el comando [describe-scalable-targets](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/describe-scalable-targets.html), especificando el ID de recurso del servicio asociado al destino escalable en Application Auto Scaling (Ejemplo: `service/default/sample-webapp`). Registre el resultado. Lo necesitará cuando ejecute el próximo comando.

1. Ejecute el comando [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html), especificando el ID de recurso, el espacio de nombres y la dimensión escalable. Especifique `true` tanto para `DynamicScalingInSuspended` como para `DynamicScalingOutSuspended`.

1. Una vez completada la implementación, puede ejecutar el comando [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html) para reanudar el escalado.

Para obtener más información, consulte [Suspensión y reanudación del escalado para Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-suspend-resume-scaling.html).

# Uso de una métrica de destino para escalar los servicios de Amazon ECS
<a name="service-autoscaling-targettracking"></a>

Las políticas de escalado de seguimiento de destino le permiten seleccionar una métrica y establecer un valor de destino. El escalado automático de servicios de Amazon ECS crea y administra las alarmas de CloudWatch que controlan la política de escalado y calcula el ajuste de escalado en función de la métrica y el valor de destino. La política de escalado amplía o reduce las tareas de servicio en función de las necesidades para mantener la métrica en el valor de destino especificado o en un valor próximo. Además de mantener la métrica próxima al valor de destino, la política de escalado de seguimiento de destino también se ajusta a las fluctuaciones de la métrica producidas por un patrón de carga fluctuante y minimiza las fluctuaciones rápidas en el número de tareas que se ejecutan en su servicio.

Las políticas de seguimiento de destinos eliminan la necesidad de definir manualmente alarmas en CloudWatch y en los ajustes de escalamiento. Amazon ECS gestiona esto automáticamente en función del destino que establezca.

Tenga en cuenta lo siguiente al utilizar las políticas de seguimiento de destino:
+ En las políticas de escalado de seguimiento de destino, se presupone que el escalado ascendente se lleva a cabo cuando la métrica está por encima del valor de destino. No puede utilizar una política de escalado de seguimiento de destinos si la métrica especificada está por debajo del valor de destino.
+ Las políticas de escalado de seguimiento de destino no realizan el escalado cuando la métrica especificada no tiene datos suficientes. No realiza el escalado porque la carencia de datos no se interpreta como una infrautilización de recursos.
+ Es posible que haya diferencias entre el valor de destino y los puntos de datos de la métrica real. Esto se debe a que Service Auto Scaling siempre actúa de forma conservadora y redondea hacia arriba o hacia abajo a la hora de determinar la cantidad de capacidad que debe agregar o quitar. Con esto se evita que se agrega capacidad insuficiente o se elimine demasiada capacidad. 
+ Para garantizar la disponibilidad de la aplicación, el servicio se escala en horizontal proporcionalmente a la métrica tan rápido como puede, pero se escala de forma descendente más gradualmente.
+ El escalado automático de aplicaciones desactiva los procesos de reducir horizontalmente mientras se llevan a cabo las implementaciones de Amazon ECS. Sin embargo, los procesos de escalado horizontal continúan produciéndose durante una implementación, a menos que se suspendan. Este comportamiento no se aplica a los servicios de Amazon ECS que utilizan el controlador de implementación externo. Para obtener más información, consulte [Escalado automático de servicios e implementaciones](service-auto-scaling.md#service-auto-scaling-deployments).
+ Se pueden tener varias políticas de escalado de seguimiento de destino para un servicio de Amazon ECS, siempre que cada una de ellas utilice una métrica diferente. El objetivo de Service Auto Scaling siempre es dar prioridad a la disponibilidad, por lo que su comportamiento varía en función de si las políticas de seguimiento de destino están listas para el escalado o la reducción horizontal. Realizará un escalado horizontal del servicio si cualquiera de las políticas de seguimiento de destino está lista para el escalado horizontal, pero solo realizará la reducción horizontal si todas las políticas de seguimiento de destino (que tienen la parte de reducción horizontal activada) están listas para la reducción horizontal. 
+ No modifique ni elimine las alarmas de CloudWatch que administra Service Auto Scaling para una política de escalado de seguimiento de destino. Service Auto Scaling elimina automáticamente las alarmas cuando se elimina la política de escalado.
+ La métrica `ALBRequestCountPerTarget` para las políticas de escalado de seguimiento de destino no es compatible con el tipo de implementación azul/verde. 

Para obtener más información acerca de políticas de escalado de seguimiento de destino, consulte [Políticas de escalado de seguimiento de destino](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html) en la *Guía del usuario de Application Auto Scaling*.

# Creación de una política de escalado de seguimiento de destino para el escalado automático de servicios de Amazon ECS
<a name="target-tracking-create-policy"></a>

Cree una política de escalado de seguimiento de destino para que Amazon ECS aumente o disminuya automáticamente el número de tareas deseado en el servicio. El seguimiento de destino funciona a partir de un valor de métricas de destino.

## Consola
<a name="target-tracking-create-policy-aws-console"></a>

1. Además de los permisos estándar de IAM para crear y actualizar servicios, necesita permisos adicionales. Para obtener más información, consulte [Permisos de IAM necesarios para el escalado automático del servicio de Amazon ECS](auto-scaling-IAM.md).

1. Determine las métricas que quiere utilizar para la política. Están disponibles las siguientes métricas:
   +  **ECSServiceAverageCPUUtilization**: uso medio de la CPU que debe utilizar el servicio. 
   + **ECSServiceAverageMemoryUtilization**: uso medio de la memoria que debe utilizar el servicio. 
   + **ALBRequestCountPerTarget**: número medio de solicitudes por minuto que debe recibir de manera ideal.

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 de detalles del clúster, en la sección **Servicios**, elija el servicio.

   Se abrirá la página de detalles del servicio.

1. Elija **Establecer el número de tareas**.

1. En **Recuento de tareas de servicio de Amazon ECS**, elija **Usar escalado automático**.

   Se abrirá la sección **Recuento de tareas**.

   1. En **Cantidad mínima de tareas**, ingrese el límite mínimo del número de tareas que se va a utilizar para el escalado automático del servicio. El recuento deseado no será inferior a este recuento.

   1. En **Máximo**, ingrese el límite máximo del número de tareas que se va a utilizar para el escalado automático del servicio. El recuento deseado no será superior a este recuento.

   1. Seleccione **Save**.

      Se abrirá la página de políticas.

1. Elija **Crear política de escalado**.

   Se abrirá la página **Crear política**.

1. Para **Scaling policy type** (Tipo de política de escalado), elija **Target tracking** (Seguimiento de destino).

1. En **Policy name** (Nombre de la política), ingrese el nombre de la política.

1. En **Tipo de métricas**, elija las métricas de la lista de opciones.

1. En **Utilización objetivo**, introduzca el valor objetivo del porcentaje de tareas que debe mantener Amazon ECS. El escalado automático del servicio escala horizontalmente la capacidad hasta que la utilización media se encuentre en la utilización objetivo, o hasta que alcance el número máximo de tareas que haya especificado.

1. En **Configuración adicional**, haga lo siguiente:

   1. En **Periodo de recuperación de reducción horizontal**, escriba la cantidad de tiempo, en segundos, tras completarse una actividad de reducción horizontal antes de que pueda comenzar otra actividad de reducción horizontal. 

   1. En **Periodo de recuperación de escalado horizontal**, ingrese la cantidad de tiempo, en segundos, que debe esperarse para que surta efecto una actividad de reducción horizontal anterior.

   1. Seleccione **Deshabilitar la reducción horizontal** para crear solo una política de escalado horizontal.

1. Elija **Crear política de escalado**.

## AWS CLI
<a name="target-tracking-create-policy-aws-cli"></a>

1. Registre su servicio de Amazon ECS como un destino escalable mediante el comando [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html).

1. Cree una política de escalado mediante el comando [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html).

# Uso de incrementos predefinidos en función de las alarmas de CloudWatch para escalar los servicios de Amazon ECS
<a name="service-autoscaling-stepscaling"></a>

Con las políticas de escalado por pasos, crea y administra las alarmas de CloudWatch que invocan el proceso de escalado. Cuando se infringe una alarma, Amazon ECS inicia la política de escalado asociada a esa alarma. La política de escalado por pasos escala las tareas mediante un conjunto de ajustes, conocidos como ajustes escalonados. La magnitud del ajuste varía en función del tamaño de la interrupción de la alarma. 
+ Si la infracción supera el primer umbral, Amazon ECS aplicará el ajuste del primer paso. 
+ Si la infracción supera el segundo umbral, Amazon ECS aplicará el ajuste del segundo paso, y así sucesivamente.

Le recomendamos que utilice políticas de escalado de seguimiento de destinos para escalar según métricas como la utilización promedio de la CPU o el recuento promedio de solicitudes por destino. Las métricas que disminuyen cuando aumenta la capacidad y aumentan cuando disminuye la capacidad se pueden usar para reducir o escalar horizontalmente de forma proporcional el número de tareas que utilizan el seguimiento de destino. Esto ayuda a garantizar que Amazon ECS siga de cerca la curva de demanda de sus aplicaciones.

# Creación de una política de escalado por pasos para el escalado automático de servicios de Amazon ECS
<a name="step-scaling-create-policy"></a>

Cree una política de escalado por pasos para que Amazon ECS aumente o disminuya automáticamente el número deseado de tareas en el servicio. El escalado por pasos se ejecuta según una serie de ajustes de escalado, denominados ajustes por pasos, que pueden variar en función del tamaño de la interrupción de alarma. 

## Consola
<a name="step-scaling-create-policy-aws-console"></a>

1. Además de los permisos estándar de IAM para crear y actualizar servicios, necesita permisos adicionales. Para obtener más información, consulte [Permisos de IAM necesarios para el escalado automático del servicio de Amazon ECS](auto-scaling-IAM.md).

1. Determine las métricas que quiere utilizar para la política. Están disponibles las siguientes métricas:
   +  **ECSServiceAverageCPUUtilization**: uso medio de la CPU que debe utilizar el servicio. 
   + **ECSServiceAverageMemoryUtilization**: uso medio de la memoria que debe utilizar el servicio. 
   + **ALBRequestCountPerTarget**: número medio de solicitudes por minuto que debe recibir de manera ideal.

1. Cree las alarmas de CloudWatch para las métricas. Para obtener más información, consulte [Create a CloudWatch alarm based on a static threshold](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html) (Creación de una alarma de CloudWatch basada en un umbral estático) en la *Guía del usuario de Amazon CloudWatch*.

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 de detalles del clúster, en la sección **Servicios**, elija el servicio.

   Se abrirá la página de detalles del servicio.

1. Elija **Establecer el número de tareas**.

1. En **Recuento de tareas de servicio de Amazon ECS**, elija **Usar escalado automático**.

   Se abrirá la sección **Recuento de tareas**.

   1. En **Cantidad mínima de tareas**, ingrese el límite mínimo del número de tareas que se va a utilizar para el escalado automático del servicio. El recuento deseado no será inferior a este recuento.

   1. En **Máximo**, ingrese el límite máximo del número de tareas que se va a utilizar para el escalado automático del servicio. El recuento deseado no será superior a este recuento.

   1. Seleccione **Save**.

      Se abrirá la página de políticas.

1. Elija **Crear política de escalado**.

   Se abrirá la página **Crear política**.

1. Para **Tipo de política de escalado**, elija **Escalado de pasos**.

1. Configure las propiedades de escalado horizontal. En **Pasos para agregar tareas**, haga lo siguiente:

   1. En **Policy name** (Nombre de la política), ingrese el nombre de la política.

   1. En **Nombre de la alarma de CloudWatch**, elija la alarma de CloudWatch.

   1. En **Tipo de agregación de métricas**, elija cómo comparar la métrica seleccionada con el umbral definido.

   1. En **Tipos de ajuste**, elija si el ajuste se basa en un cambio en el número de tareas o en un cambio en el porcentaje de tareas.

   1. En **Acciones que ejecutar**, introduzca los valores de la acción que se va a realizar.

      Seleccione **Agregar paso** para agregar otras acciones.

1. Configure las propiedades de la reducción horizontal. En **Pasos para quitar tareas**, haga lo siguiente:

   1. En **Policy name** (Nombre de la política), ingrese el nombre de la política.

   1. En **Nombre de la alarma de CloudWatch**, elija la alarma de CloudWatch.

   1. En **Tipo de agregación de métricas**, elija cómo comparar la métrica seleccionada con el umbral definido.

   1. En **Tipos de ajuste**, elija si el ajuste se basa en un cambio en el número de tareas o en un cambio en el porcentaje de tareas.

   1. En **Acciones que ejecutar**, introduzca los valores de la acción que se va a realizar.

      Seleccione **Agregar paso** para agregar otras acciones.

1. En **Periodo de recuperación**, ingrese la cantidad de tiempo, en segundos, que debe esperarse para que surta efecto una actividad de reducción horizontal anterior. En el caso de una política de ampliación, este es el momento en el que, después de una actividad de escalado horizontal, la política de escalado bloquea las actividades de reducción horizontal y limita el número de tareas que se pueden escalar horizontalmente a la vez. En el caso de una política de reducción horizontal, este es el tiempo que debe transcurrir tras completarse una actividad de reducción horizontal antes de que pueda comenzar otra actividad de reducción horizontal. 

1. Elija **Crear política de escalado**.

## AWS CLI
<a name="step-scaling-create-policy-aws-cli"></a>

1. Registre su servicio de Amazon ECS como un destino escalable mediante el comando [register-scalable-target](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/register-scalable-target.html).

1. Cree una política de escalado mediante el comando [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html).

# Uso de acciones programadas para escalar los servicios de Amazon ECS
<a name="service-autoscaling-schedulescaling"></a>

Con el escalado programado, puede configurar el escalado automático para su aplicación en función de cambios de carga predecibles mediante la creación de acciones programadas que aumenten o disminuyan el número de tareas en momentos específicos. Esto le permite escalar su aplicación de forma proactiva para adaptarla a los cambios de carga predecibles.

Estas acciones de escalado programadas le permiten optimizar los costes y el rendimiento. Su aplicación tiene un número de tareas suficiente para gestionar los picos de tráfico a mitad de semana, pero no aprovisiona en exceso el número de tareas en otros momentos. 

Puede combinar el escalado programado y las políticas de escalado para obtener los beneficios de enfoques tanto proactivos como reactivos al escalado. Después de ejecutar una acción de escalado programado, la política de escalado puede seguir tomando decisiones sobre si desea ampliar el número de tareas. Esto ayuda a garantizar que tiene un número de tareas suficiente para gestionar la carga de su aplicación. Mientras la aplicación se escala para adaptarse a la demanda, la capacidad actual debe estar dentro del número de tareas mínimo y máximo que establece la acción programada. 

Puede configurar el escalado de la programación mediante la AWS CLI. Para obtener más información sobre el escalado programado, consulte [Scheduled Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-scheduled-scaling.html) en la *Guía del usuario de Application Auto Scaling*.

# Creación de una acción programada para el escalado automático de servicios de Amazon ECS
<a name="scheduled-action-create-policy"></a>

Creación de una acción programada para que Amazon ECS aumento o disminuya el número de tareas que ejecuta el servicio en función de la fecha y la hora. 

## Consola
<a name="scheduled-action-policy-aws-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 de detalles del clúster, en la sección **Servicios**, elija el servicio.

   Se abrirá la página de detalles del servicio.

1. Elija **Escalado automático de servicio**.

   Aparece la página de escalado automático del servicio.

1. Si no ha configurado el escalado automático del servicio, elija **Establecer la cantidad de tareas**.

   Aparece la sección **Recuento de tareas del servicio de Amazon ECS**.

   En **Recuento de tareas del servicio de Amazon ECS**, seleccione **Utilizar el escalado automático del servicio para ajustar el recuento de tareas deseado del servicio**.

   Se abrirá la sección **Recuento de tareas**.

   1. En **Cantidad mínima de tareas**, ingrese el límite mínimo del número de tareas que se va a utilizar para el escalado automático del servicio. El recuento deseado no será inferior a este recuento.

   1. En **Máximo**, ingrese el límite máximo del número de tareas que se va a utilizar para el escalado automático del servicio. El recuento deseado no será superior a este recuento.

   1. Elija **Elegir Guardar**.

      Se abrirá la página de políticas.

1. Elija **Acciones programadas** y, a continuación, elija **Crear**.

   Se abrirá la página **Crear acción programada**.

1. En **Nombre de acción**, escriba un nombre único.

1. Para **Zona horaria**, elija una zona horaria.

   Todas las zonas horarias enumeradas provienen de la base de datos de zona horaria de IANA. Para obtener más información, consulte [List of tz database time zones](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).

1. En **Hora de inicio**, introduzca la **fecha** y la **hora** en que comienza la acción.

   Si elige una programación recurrente, la hora de inicio define cuándo se ejecuta la primera acción programada de la serie recurrente.

1. En **Recurrence (Recurrencia)**, elija una de las opciones disponibles.
   + Para escalar según una programación recurrente, elija la frecuencia con la que Amazon ECS ejecuta la acción programada.
     + Si elige una opción que comienza por **Frecuencia**, la expresión cron se crea automáticamente.
     + Si elige **Cron**, escriba una expresión cron que especifique cuándo se debe realizar la acción. 
   + Para escalar una sola vez, elija **Una vez**.

1. En **Ajustes de tareas**, haga lo siguiente:
   + En **Mínimo**, introduzca el número mínimo de tareas que debe ejecutar el servicio.
   + En **Máximo**, introduzca el número máximo de tareas que debe ejecutar el servicio.

1. Elija **Crear acción programada**.

## CLI
<a name="scheduled-action-aws-cli"></a>

Use la AWS CLI como se indica a continuación para configurar políticas de escalado programado para el servicio. Reemplace cada *marcador de posición de entrada del usuario* con información propia.

**Ejemplo: Escalar solo una vez**  
Utilice el siguiente comando [put-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scheduled-action.html) con la `--start-time "YYYY-MM-DDThh:mm:ssZ"` y una o ambas opciones `--MinCapacity` y `--MaxCapacity`. 

```
aws application-autoscaling put-scheduled-action --service-namespace ecs \
  --resource-id service/my-cluster/my-service \
  --scheduled-action-name my-one-time-schedule \
  --start-time 2021-01-30T12:00:00 \
  --scalable-target-action MinCapacity=3,MaxCapacity=10
```

**Ejemplo: Para programar el escalado de forma periódica**  
Utilice el siguiente comando [put-scheduled-action](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scheduled-action.html). Sustituya las *entradas del usuario* por sus valores.

```
aws application-autoscaling put-scheduled-action --service-namespace ecs \
  --resource-id service/my-cluster/my-service \
  --scheduled-action-name my-recurring-action \
  --schedule "rate(5 hours)" \
  --start-time 2021-01-30T12:00:00 \
  --end-time 2021-01-31T22:00:00 \
  --scalable-target-action MinCapacity=3,MaxCapacity=10
```

El programa de recurrencia especificado se ejecuta según la zona horaria UTC. Para especificar una zona horaria diferente, incluya la opción `--time-zone` y el nombre para la zona horaria de IANA, como en el siguiente ejemplo.

```
--time-zone "America/New_York"
```

Para obtener más información, consulte [List of tz database time zones](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).

# Uso de patrones históricos para escalar los servicios de Amazon ECS con escalado predictivo
<a name="predictive-auto-scaling"></a>

El escalado predictivo analiza los datos de cargas anteriores de los flujos de tráfico para analizar los patrones diarios o semanales. Luego, utiliza este análisis para anticipar las necesidades futuras y aumentar proactivamente las tareas de su servicio según sea necesario.

El escalado automático predictivo es más útil en las siguientes situaciones.
+ Tráfico cíclico: uso elevado de recursos durante el horario laborable normal y un uso reducido de recursos por la noche o los fines de semana.
+ Patrones recurrentes de carga de trabajo de activación y desactivación, como el procesamiento por lotes, pruebas o análisis periódicos de datos.
+ Aplicaciones que tardan mucho tiempo en inicializarse: esto puede repercutir en el rendimiento de las aplicaciones durante eventos de escalado horizontal, lo que provoca una latencia notable.

En general, si sus aplicaciones tardan mucho tiempo en inicializarse y el tráfico aumenta en un patrón regular, debe considerar el uso del escalado predictivo. Esto ayuda a escalar más rápido, ya que aumenta de forma proactiva el número de tareas para las cargas previstas en lugar de utilizar políticas de escalado dinámicas, como de seguimiento de destino o de escalado por pasos únicamente. Al ayudar a evitar la posibilidad de aprovisionar en exceso el número de tareas, con el escalado predictivo también puede ahorrar dinero.

Por ejemplo, piense en una aplicación que tiene un uso elevado durante el horario laborable y un uso bajo durante la noche. Al comienzo de cada día laborable, el escalado predictivo puede escalar horizontalmente tareas antes de la primera afluencia de tráfico. Esto ayuda a la aplicación a mantener una alta disponibilidad y rendimiento al pasar de un periodo de menor utilización a uno de mayor utilización. No tiene que esperar a que el escalado dinámico reaccione a los cambios en el tráfico. Tampoco tiene que dedicar tiempo a revisar los patrones de carga de la aplicación e intentar programar la cantidad correcta de tareas mediante el escalado programado.

El escalado predictivo es una capacidad de nivel de servicio que escala la tarea del servicio independientemente del escalado de la capacidad de computación subyacente (por ejemplo, EC2 o Fargate). Para Fargate, AWS administra y escala de forma automática la capacidad subyacente en función de los requisitos de la tarea. Para la capacidad de EC2, puede utilizar los proveedores de capacidad de grupo de escalado automático para escalar automáticamente las instancias de EC2 subyacentes en función de los requisitos de escalado de las tareas.

**Topics**
+ [Información general del escalado predictivo](#predictive-auto-scaling-overview)
+ [Creación de una política de escalado predictivo](predictive-scaling-create-policy.md)
+ [Evaluación de las políticas de escalado predictivo](predictive-scaling-graphs.md)
+ [Anulación del pronóstico](predictive-scaling-overriding-forecast-capacity.md)
+ [Uso de métricas personalizadas](predictive-scaling-custom-metrics.md)

## Cómo funciona el escalado predictivo en Amazon ECS
<a name="predictive-auto-scaling-overview"></a>

Aquí puede obtener información sobre las consideraciones relacionadas con el uso del escalado predictivo, cómo funciona y cuáles son los límites.

### Consideraciones sobre el uso del escalado predictivo
<a name="predictive-auto-scaling-considerations"></a>
+ Desea asegurarse de que el escalado predictivo sea adecuado para la carga de trabajo. Para comprobarlo, configure las políticas de escalado en el modo de **solo previsión** y consulte las recomendaciones de la consola. Debe evaluar la previsión y las recomendaciones antes de empezar a utilizar el escalado predictivo.
+ Antes de que el escalado predictivo pueda iniciar el pronóstico, este necesita al menos 24 horas de datos históricos. Cuantos más datos históricos estén disponibles, más eficaz será la previsión. Lo ideal es dos semanas. También tendrá que esperar 24 horas para que el escalado predictivo pueda generar nuevas previsiones cuando elimine un servicio de Amazon ECS y cree uno nuevo. Una forma de acelerar este proceso es usar métricas personalizadas para agregar métricas de servicios de Amazon ECS nuevos y antiguos.
+ Elija una métrica de carga que represente con precisión la carga total de la aplicación y que sea el aspecto de la aplicación que más le interese escalar.
+ El escalado dinámico con el escalado predictivo ayuda a seguir de cerca la demanda de la aplicación, de modo que puede reducir horizontalmente durante los periodos de menor demanda y escalar horizontalmente durante aumentos inesperados de tráfico. Cuando hay activas varias políticas de escalado, cada política determina el número de tareas deseado de forma independiente, y el número de tareas deseado se establece en el máximo de las políticas.
+ Puede utilizar el escalado predictivo junto con sus políticas de escalado dinámico, como el seguimiento de destino o el escalado gradual, para que las aplicaciones se escalen en función de patrones históricos y en tiempo real. Por sí solo, el escalado predictivo no reduce horizontalmente las tareas. 
+ Si utiliza un rol personalizado al llamar a la API `register-scalable-target`, es posible que aparezca un error que indique que la política de escalado predictivo solo funciona con el SLR habilitado. En este caso, debe volver a llamar a `register-scalable-target`, pero sin role-arn. Utilice el SLR al registrar el destino escalable y llame a la API `put-scaling-policy`.

### Funcionamiento del escalado predictivo
<a name="predictive-auto-scaling-details"></a>

Utiliza el escalado predictivo al crear una política de escalado predictivo que especifique la métrica de CloudWatch que se va a supervisar y analizar. El escalado predictivo debe tener datos de, por lo menos, las últimas 24 horas, para comenzar a pronosticar los valores futuros.

Tras crear la política, el escalado predictivo comienza a analizar los datos de las métricas de los últimos 14 días para identificar patrones. Este análisis se utiliza para generar previsiones por hora de requisitos de las próximas 48 horas. Los datos más recientes de CloudWatch se utilizan para actualizar la previsión cada 6 horas. A medida que llegan nuevos datos, el escalado predictivo puede mejorar continuamente la precisión de las previsiones futuras.

La primera vez que se habilita el escalado predictivo, se ejecuta en modo de *solo previsión*. Genera pronósticos en este modo, pero no escala el servicio de Amazon ECS en función de esos pronósticos. Esto significa que puede evaluar la precisión e idoneidad del pronóstico. Ve los datos del pronóstico mediante la operación de la API `GetPredictiveScalingForecast` o la Consola de administración de AWS.

Cuando decida empezar a utilizar el escalado predictivo, cambie la política de escalado al modo de *pronóstico y escalado*. En este modo, ocurre lo siguiente.

De forma predeterminada, su servicio de Amazon ECS se escala al principio de cada hora en función del pronóstico de esa hora. Puede optar por empezar antes mediante el uso de la propiedad `SchedulingBufferTime` de la operación de la API `PutScalingPolicy`. Esto permite que las nuevas tareas se inicien antes de la demanda pronosticada y les da tiempo para arrancar y prepararse para gestionar el tráfico.

### Límite máximo de tareas
<a name="predictive-scaling-maximum-tasks-limit"></a>

Cuando registra los servicios de Amazon ECS para el escalado, define un número máximo de tareas que se pueden lanzar por servicio. De manera predeterminada, cuando se establecen políticas de escalado, estas no pueden aumentar el número de tareas por encima del límite máximo.

Como alternativa, puede permitir que el número máximo de tareas del servicio se incremente automáticamente si la previsión se acerca al número máximo de tareas del servicio de Amazon ECS o lo supera.

**aviso**  
Tenga cuidado al permitir que el número máximo de tareas aumente automáticamente. Esto puede provocar que se lancen más tareas de las previstas si no se supervisa ni gestiona el aumento del número máximo de tareas. El aumento del número máximo de tareas se convierte en el nuevo número máximo normal de tareas del servicio de Amazon ECS hasta que lo actualice manualmente. El número máximo de tareas no disminuye automáticamente hasta el máximo original.

### Regiones admitidas
<a name="predictive-auto-scaling-supported-regions"></a>
+ Este de EE. UU. (Norte de Virginia)
+ Este de EE. UU. (Ohio)
+ Oeste de EE. UU. (Norte de California)
+ Oeste de EE. UU. (Oregón)
+ África (Ciudad del Cabo)
+ Asia-Pacífico (Hong Kong)
+ Asia-Pacífico (Yakarta)
+ Asia-Pacífico (Mumbai)
+ Asia-Pacífico (Osaka)
+ Asia-Pacífico (Seúl)
+ Asia-Pacífico (Singapur)
+ Asia-Pacífico (Sídney)
+ Asia-Pacífico (Tokio)
+ Canadá (centro)
+ China (Pekín)
+ China (Ningxia)
+ Europa (Fráncfort)
+ Europa (Irlanda)
+ Europa (Londres)
+ Europa (Milán)
+ Europa (París)
+ Europa (Estocolmo)
+ Medio Oriente (Baréin)
+ América del Sur (São Paulo)
+ AWS GovCloud (Este de EE. UU.)
+ AWS GovCloud (Oeste de EE. UU.)

# Creación de una política de escalado predictivo para el escalado automático de servicios de Amazon ECS
<a name="predictive-scaling-create-policy"></a>

Cree una política de escalado predictiva de modo que Amazon ECS aumente o disminuya la cantidad de tareas que el servicio ejecuta en función de datos históricos. 

**nota**  
Un servicio nuevo debe proporcionar datos de, por lo menos, las últimas 24 horas para poder generar un pronóstico.

## Consola
<a name="predictive-scaling-policy-aws-console"></a>

1. Además de los permisos estándar de IAM para crear y actualizar servicios, necesita permisos adicionales. Para obtener más información, consulte [Permisos de IAM necesarios para el escalado automático del servicio de Amazon ECS](auto-scaling-IAM.md).

1. Determine las métricas que quiere utilizar para la política. Están disponibles las siguientes métricas:
   +  **ECSServiceAverageCPUUtilization**: uso medio de la CPU que debe utilizar el servicio. 
   + **ECSServiceAverageMemoryUtilization**: uso medio de la memoria que debe utilizar el servicio. 
   + **ALBRequestCountPerTarget**: número medio de solicitudes por minuto que debe recibir de manera ideal.

   También puede utilizar una métrica personalizada. Debe definir los siguientes valores:
   + Carga: una métrica de carga que representa con precisión la carga total de la aplicación y que es el aspecto de la aplicación que más le interesa escalar.
   + Métrica de escalado: el mejor indicador del grado de utilización ideal para su aplicación.

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 de detalles del clúster, en la sección **Servicios**, elija el servicio.

   Se abrirá la página de detalles del servicio.

1. Elija **Escalado automático de servicio** y, a continuación, elija **Establecer la cantidad de tareas**.

1. En **Recuento de tareas de servicio de Amazon ECS**, elija **Usar escalado automático**.

   Se abrirá la sección **Recuento de tareas**.

   1. En **Cantidad mínima de tareas**, ingrese el límite mínimo del número de tareas que se va a utilizar para el escalado automático del servicio. El recuento deseado no será inferior a este recuento.

   1. En **Máximo**, ingrese el límite máximo del número de tareas que se va a utilizar para el escalado automático del servicio. El recuento deseado no será superior a este recuento.

   1. Seleccione **Save**.

      Se abrirá la página de políticas.

1. Elija **Crear política de escalado**.

   Se abrirá la página **Crear política**.

1. Para **Tipo de política de escalado**, elija **Escalado predictivo**.

1. En **Policy name** (Nombre de la política), ingrese el nombre de la política.

1. En **Par de métricas**, elija las métricas de la lista de opciones.

   Si eligió **Application Load Balancer request count per target (Recuento de solicitudes de Application Load Balancer por destino)**, luego elija un grupo de destino en **Target group (Grupo de destino)**. **Recuento de solicitudes del equilibrador de carga de aplicación por destino** solo se admite si ha adjuntado un grupo de destino del equilibrador de carga de aplicación para el servicio. 

   Si eligió **Par de métricas personalizadas**, elija métricas individuales en las listas de **Métrica de carga** y **Métrica de escalado**. 

1. En **Utilización objetivo**, introduzca el valor objetivo del porcentaje de tareas que debe mantener Amazon ECS. El escalado automático del servicio escala horizontalmente la capacidad hasta que la utilización media se encuentre en la utilización objetivo, o hasta que alcance el número máximo de tareas que haya especificado.

1. Elija **Crear política de escalado**.

## AWS CLI
<a name="predictive-scaling-policy-aws-cli"></a>

Use la AWS CLI como se indica a continuación para configurar políticas de escalado predictivo para el servicio de Amazon ECS. Reemplace cada *marcador de posición de entrada del usuario* con información propia.

Para obtener más información acerca de las métricas de CloudWatch que puede especificar, consulte [PredictivEscalingMetricSpecification](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_PredictiveScalingMetricSpecification.html) en la *Referencia de la API de Amazon EC2 Auto Scaling*.

### Ejemplo 1: política de escalado predictivo con memoria predefinida.
<a name="predictive-scaling-cli-example-one"></a>

A continuación, se muestra un ejemplo de política con una configuración de memoria predefinida.

```
cat policy.json
{
    "MetricSpecifications": [
        {
            "TargetValue": 40,
            "PredefinedMetricPairSpecification": {
                "PredefinedMetricType": "ECSServiceMemoryUtilization"
            }
        }
    ],
    "SchedulingBufferTime": 3600,
    "MaxCapacityBreachBehavior": "HonorMaxCapacity",
    "Mode": "ForecastOnly"
}
```

En el ejemplo siguiente se muestra cómo crear la política mediante la ejecución del comando [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html) con el archivo de configuración especificado.

```
aws application-autoscaling put-scaling-policy \
--service-namespace ecs \
--region us-east-1 \
--policy-name predictive-scaling-policy-example \
--resource-id service/MyCluster/test \
--policy-type PredictiveScaling \
--scalable-dimension ecs:service:DesiredCount \
--predictive-scaling-policy-configuration file://policy.json
```

Si se ejecuta correctamente, este comando devolverá el ARN de la política.

```
{
    "PolicyARN": "arn:aws:autoscaling:us-east-1:012345678912:scalingPolicy:d1d72dfe-5fd3-464f-83cf-824f16cb88b7:resource/ecs/service/MyCluster/test:policyName/predictive-scaling-policy-example",
    "Alarms": []
}
```

### Ejemplo 2: política de escalado predictivo con CPU predefinida.
<a name="predictive-scaling-cli-example-two"></a>

A continuación, se muestra un ejemplo de política con una configuración de CPU predefinida.

```
cat policy.json
{
    "MetricSpecifications": [
        {
            "TargetValue": 0.00000004,
            "PredefinedMetricPairSpecification": {
                "PredefinedMetricType": "ECSServiceCPUUtilization"
            }
        }
    ],
    "SchedulingBufferTime": 3600,
    "MaxCapacityBreachBehavior": "HonorMaxCapacity",
    "Mode": "ForecastOnly"
}
```

En el ejemplo siguiente se muestra cómo crear la política mediante la ejecución del comando [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html) con el archivo de configuración especificado.

```
aws aas put-scaling-policy \
--service-namespace ecs \
--region us-east-1 \
--policy-name predictive-scaling-policy-example \
--resource-id service/MyCluster/test \
--policy-type PredictiveScaling \
--scalable-dimension ecs:service:DesiredCount \
--predictive-scaling-policy-configuration file://policy.json
```

Si se ejecuta correctamente, este comando devolverá el ARN de la política.

```
{
    "PolicyARN": "arn:aws:autoscaling:us-east-1:012345678912:scalingPolicy:d1d72dfe-5fd3-464f-83cf-824f16cb88b7:resource/ecs/service/MyCluster/test:policyName/predictive-scaling-policy-example",
    "Alarms": []
}
```

# Evaluación de las políticas de escalado predictivo para Amazon ECS
<a name="predictive-scaling-graphs"></a>

Antes de utilizar una política de escalado predictivo para escalar automáticamente los servicios, consulte las recomendaciones y otros datos de la política en la consola de Amazon ECS. Esto es importante porque no es recomendable que una política de escalado predictivo amplíe su capacidad real hasta que sepa que sus predicciones son precisas.

Si el servicio es nuevo, espere 24 horas para crear el primer pronóstico.

Cuando AWS crea un pronóstico, utiliza datos históricos. Si el servicio aún no cuenta con muchos datos históricos recientes, el escalado predictivo podría rellenar temporalmente el pronóstico con agregados creados a partir de los agregados históricos disponibles actualmente. Las previsiones se rellenan hasta dos semanas antes de la fecha de creación de la política.

## Visualización de las recomendaciones de escalado predictivo
<a name="view-predictive-scaling-recommendations"></a>

Para poder llevar a cabo un análisis eficaz, el escalado automático del servicio debe tener al menos dos políticas de escalado predictivo para comparar. (Sin embargo, aún puede revisar los resultados de una sola política). Al crear varias políticas, puede evaluar una política que usa una métrica en comparación con una política que usa una diferente. También puede evaluar el impacto de diferentes combinaciones de valores y métricas de destino. Una vez creadas las políticas de escalado predictivo, Amazon ECS comienza inmediatamente a evaluar qué política haría un mejor trabajo a la hora de escalar el grupo.

**Visualización de las recomendaciones en la 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 página **Clusters** (Clústeres), elija el clúster.

1. En la página de detalles del clúster, en la sección **Servicios**, elija el servicio.

   Se abrirá la página de detalles del servicio.

1. Elija **Escalado automático de servicio**.

1. Elija la política de escalado predictivo y, a continuación, elija **Acciones**, **Escalado predictivo** y **Ver recomendación**.

   Puede ver los detalles de una política junto con nuestra recomendación. La recomendación indica si la política de escalado predictivo funciona mejor que si no se utiliza. 

   Si no está seguro de si una política de escalado predictivo es adecuada para su grupo, revise las columnas **Impacto en la disponibilidad** e **Impacto en los costos** para elegir la política correcta. La información de cada columna indica cuál es el impacto de la política. 
   + **Impacto en la disponibilidad**: describe si la política evitaría un impacto negativo en la disponibilidad al aprovisionar suficientes tareas para gestionar la carga de trabajo, en comparación con no utilizar la política.
   + **Impacto en los costos**: describe si la política evitaría un impacto negativo en los costos al no aprovisionar en exceso las tareas, en comparación con no utilizar la política. Al aprovisionar demasiado, los servicios quedan infrautilizadas o inactivas, lo que no hace más que aumentar el impacto en los costos.

   Si tiene varias políticas, aparecerá una etiqueta que pondrá **Mejor predicción** junto al nombre de la política que ofrece la mayor cantidad de beneficios de disponibilidad a un costo menor. Se da más importancia al impacto en la disponibilidad. 

1. (Opcional) Para seleccionar el periodo deseado para los resultados de la recomendación, elija el valor que prefiera en el menú desplegable **Periodo de evaluación**: **2 días**, **1 semana** o **2 semanas**. De forma predeterminada, el periodo de evaluación son las dos últimas semanas. Un periodo de evaluación más largo proporciona más puntos de datos para los resultados de la recomendación. Sin embargo, es posible que agregar más puntos de datos no mejore los resultados si los patrones de carga han cambiado, por ejemplo, después de un periodo de demanda excepcional. En este caso, puede obtener una recomendación más específica si consulta datos más recientes.

**nota**  
Las recomendaciones se generan solo para las políticas que están en el modo **Solo previsión**. La característica de recomendaciones funciona mejor cuando una política está en el modo **Solo previsión** durante el periodo de evaluación. Si inicia una política en modo **Previsión y escalado** y luego la cambia al modo **Solo previsión**, es probable que los resultados de esa política estén sesgados. Esto se debe a que la política ya ha contribuido a la capacidad real.

## Revisión de los gráficos de supervisión del escalado predictivo
<a name="review-predictive-scaling-monitoring-graphs"></a>

En la consola, puede revisar el pronóstico de los días, semanas o meses anteriores para visualizar el rendimiento de la política a lo largo del tiempo. También puede utilizar esta información para evaluar la precisión de las predicciones a la hora de decidir si va a permitir que una política escale el número de tareas real.

**Revisión de los gráficos de supervisión del escalado predictivo en la 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 página **Clusters** (Clústeres), elija el clúster.

1. En la página de detalles del clúster, en la sección **Servicios**, elija el servicio.

   Se abrirá la página de detalles del servicio.

1. Elija **Escalado automático de servicio**.

1. Elija la política de escalado predictivo y, a continuación, elija **Acciones**, **Escalamiento predictivo** y **Ver gráfico**.

1. En la sección **Supervisión**, puede ver las previsiones pasadas y futuras de su política de carga y capacidad y compararlas con los valores reales. En el gráfico **Carga** se muestra el pronóstico de carga y los valores reales para la métrica de carga que elija. En el gráfico **Capacidad** se muestra el número de tareas pronosticado por la política. También se incluye el número real de tareas lanzadas. La línea vertical separa los valores históricos de las previsiones futuras. Estos gráficos estarán disponibles poco después de que se cree la política. 

1. (Opcional) Para cambiar la cantidad de datos históricos que se muestra en el gráfico, elija su valor preferido en el menú desplegable **Periodo de evaluación** en la parte superior de la página. El periodo de evaluación no transforma los datos de esta página de ninguna manera. Solo cambia la cantidad de datos históricos que se muestran.

**Comparación de datos en el gráfico **Carga****  
Cada línea horizontal representa un conjunto diferente de puntos de datos de los que se ha informado en intervalos de una hora:

1. **Carga real observada** utiliza la estadística SUM de la métrica de carga elegida para mostrar la carga total por hora en el pasado.

1. **Carga pronosticada por la política** muestra la predicción de carga por hora. Esta predicción se basa en las dos semanas anteriores de observaciones de carga reales.

**Comparación de los datos en el gráfico **Capacidad****  
Cada línea horizontal representa un conjunto diferente de puntos de datos de los que se ha informado en intervalos de una hora:

1. En **Número de tareas real observado** se muestra la capacidad real del servicio de Amazon ECS en el pasado, lo que depende de las demás políticas de escalado y del tamaño mínimo del grupo en vigor durante el periodo seleccionado.

1. **Capacidad pronosticada por la política** muestra la capacidad de referencia que puede esperar tener al principio de cada hora cuando la política esté en modo **Previsión y escalado**.

1. En **Número de tareas necesario inferido** se muestra el número ideal de tareas de su servicio para mantener la métrica de escalado en el valor de destino que haya elegido.

1. En **Cantidad mínima de tareas** se muestra el número mínimo de tareas del servicio.

1. En **Capacidad máxima** se muestra el número máximo de tareas del servicio.

Para calcular la capacidad necesaria inferida, primero suponemos que cada tarea se utiliza por igual en un valor de destino específico. En la práctica, el número de tareas no se utiliza por igual. Sin embargo, si suponemos que la utilización se distribuye de manera uniforme entre las tareas, podemos hacer una estimación probabilística de la cantidad de capacidad que se necesita. A continuación, se calcula el requisito del número de tareas para que sea inversamente proporcional a la métrica de escalado que se utilizó para la política de escalado predictivo. En otras palabras, a medida que aumenta el número de tareas, la métrica de escalado disminuye al mismo ritmo. Por ejemplo, si el número de tareas se duplica, la métrica de escalado debe reducirse a la mitad. 

La fórmula para la capacidad necesaria inferida:

 `sum of (actualServiceUnits*scalingMetricValue)/(targetUtilization)`

Por ejemplo, tomamos los valores de `actualServiceUnits` (`10`) y `scalingMetricValue` (`30`) de una hora determinada. A continuación, tomamos el valor de `targetUtilization` que especificó en su política de escalado predictivo (`60`) y calculamos la capacidad necesaria inferida de la misma hora. Esto devuelve un valor de `5`. Esto significa que cinco es la cantidad de capacidad inferida necesaria para mantener la capacidad en proporción inversa directa al valor de destino de la métrica de escalado.

**nota**  
Hay varias palancas disponibles para ajustar y mejorar el ahorro de costos y la disponibilidad de la aplicación.  
Se utiliza el escalado predictivo para la capacidad de referencia y el escalado dinámico para gestionar la capacidad adicional. El escalado dinámico funciona independientemente del escalado predictivo, escalando vertical u horizontalmente en función de la utilización actual. En primer lugar, Amazon ECS calcula el número recomendado de tareas para cada política de escalado no programado. A continuación, se escala en función de la política que proporciona la mayor cantidad de tareas.
Para permitir que se reduzca horizontalmente cuando la carga disminuya, el servicio siempre debe tener al menos una política de escalado dinámico con la parte de reducción horizontal habilitada.
Puede mejorar el rendimiento del escalado si se asegura de que su capacidad mínima y máxima no sean demasiado restrictivas. Se impedirá que una política con un número recomendado de tareas que no se encuentre dentro del rango de capacidad mínima y máxima se reduzca o escale horizontalmente.

# Supervisión de métricas de escalado predictivo para Amazon ECS con CloudWatch
<a name="predictive-scaling-monitoring"></a>

Puede utilizar Amazon CloudWatch para supervisar los datos para el escalado predictivo. Una política de escalado predictivo recopila datos que se utilizan para pronosticar la carga futura. Los datos recopilados se almacenan automáticamente en CloudWatch a intervalos regulares y se pueden utilizar para visualizar el rendimiento de la política a lo largo del tiempo. También puede crear alarmas de CloudWatch para que le notifiquen cuando los indicadores de rendimiento cambien más allá de los límites que defina.

## Visualización de los datos de las previsiones
<a name="visualize-historical-forecast-data"></a>

Los datos de pronósticos de carga para una política de escalado predictivo se pueden ver en CloudWatch y pueden ser útiles al visualizar pronósticos con respecto a otras métricas de CloudWatch en un solo gráfico. También puede consultar un intervalo de tiempo mayor para ver las tendencias a lo largo del tiempo. Puede acceder a métricas históricas de hasta 15 meses para obtener una mejor perspectiva del rendimiento de su política.

**Para consultar los datos de las previsiones históricas mediante la consola de CloudWatch**

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

1. En el panel de navegación, elija **Metrics** (Métricas) y, a continuación, **All metrics** (Todas las métricas).

1. Seleccione el espacio de nombres de la métrica de **Escalado automático de aplicaciones**.

1. Elija **Pronósticos de carga de escalado predictivo**.

1. En el campo de búsqueda, ingrese el nombre de la política de escalado predictivo o el nombre del grupo del servicio de Amazon ECS y, a continuación, pulse Intro para filtrar los resultados. 

1. Para representar gráficamente una métrica, active la casilla de verificación situada junto a ella. Para cambiar el nombre del gráfico, seleccione el icono de lápiz. Para cambiar el intervalo de tiempo, seleccione uno de los valores predefinidos o elija **custom (personalizado)**. Para obtener más información, consulte [Graphing a metric](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/graph_a_metric.html) (Representación gráfica de métricas) en *Amazon CloudWatch User Guide* (Guía del usuario de Amazon CloudWatch).

1. Para cambiar la estadística, elija la pestaña **Graphed metrics**. Elija el encabezado de columna o un valor individual y, a continuación, elija una estadística diferente. Aunque puede elegir cualquier estadística en cada métrica, tenga en cuenta que no todas las estadísticas son útiles para las métricas **PredictiveScalingLoadForecast**. Por ejemplo, las estadísticas **Media**, **Mínimo** y **Máximo** son útiles para el uso de la CPU, pero no así la estadística **Suma**.

1. Para agregar otra métrica al gráfico, en **Browse** (Examinar), elija **All** (Todo), busque la métrica específica y luego seleccione la casilla de verificación que aparece a su lado. Puede añadir hasta 10 métricas.

1. (Opcional) Para agregar este gráfico a un panel CloudWatch, elija **Acciones** y después **Agregar al panel**.

## Creación de métricas de precisión mediante la matemática métrica
<a name="create-accuracy-metrics"></a>

Las matemáticas en las métricas le permiten consultar varias métricas de CloudWatch y usar expresiones matemáticas para crear nuevas series temporales basadas en estas métricas. Puede visualizar las series temporales resultantes en la consola de CloudWatch y agregarlas a los paneles. Para obtener más información, consulte [Using metric math](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) (Uso de cálculo de métricas) en *Amazon CloudWatch User Guide* (Guía del usuario de Amazon CloudWatch).

Con la matemática métrica, puede representar gráficamente los datos que genera el escalado automático del servicio para el escalado predictivo de distinas formas. Esto es de utilidad para supervisar el rendimiento de las políticas a lo largo del tiempo y a comprender si se puede mejorar la combinación de métricas.

Por ejemplo, puede usar una expresión matemática métrica para supervisar el [mean absolute percentage error](https://en.wikipedia.org/wiki/Mean_absolute_percentage_error) (error porcentual absoluto medio o MAPE). La métrica MAPE ayuda a supervisar la diferencia entre los valores pronosticados y los valores reales observados durante un periodo de previsión determinado. Los cambios en el valor de MAPE pueden indicar si el rendimiento de la política se degrada con el tiempo a medida que cambia la naturaleza de la aplicación. Un aumento en MAPE indica una brecha más amplia entre los valores pronosticados y los valores reales. 

**Ejemplo: expresiones matemáticas de métricas**

Para empezar a utilizar este tipo de gráfica, puede crear una expresión matemática métrica como la que se muestra en el siguiente ejemplo.



En lugar de una sola métrica, hay una matriz de estructuras de consulta de datos métricos para `MetricDataQueries`. Cada elemento de `MetricDataQueries` obtiene una métrica o realiza una expresión matemática. El primer elemento, `e1`, es la expresión matemática. La expresión designada establece el parámetro `ReturnData` a `true`, que en última instancia produce una sola serie temporal. Para todas las demás métricas, el valor `ReturnData` es `false`. 

En el ejemplo, la expresión designada utiliza los valores reales y previstos como entrada y devuelve la nueva métrica (MAPE). `m1` es la métrica de CloudWatch que contiene los valores de carga reales (si suponemos que el uso de CPU es la métrica de carga que se especificó originalmente para la política denominada `my-predictive-scaling-policy`). `m2` es la métrica de CloudWatch que contiene los valores de carga previstos. La sintaxis matemática de la métrica MAPE es la siguiente:

*Average of (abs ((Actual - Forecast)/(Actual))) (Promedio de (abs ((Real - Previsión)/(Real)))*

### Visualización de métricas de precisión y configuración de alarmas
<a name="visualize-accuracy-metrics-set-alarms"></a>

Para visualizar los datos de la métrica de precisión, seleccione la pestaña **Metrics** (Métricas) en la consola de CloudWatch. Puede hacer una representación gráfica de los datos desde allí. Para obtener más información, consulte [Adding a math expression to a CloudWatch graph](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html#adding-metrics-expression-console) (Adición de una expresión matemática a un gráfico de CloudWatch) en *Amazon CloudWatch User Guide* (Guía del usuario de Amazon CloudWatch).

Puede configurar una alarma para una métrica que supervise desde la sección **Metrics**. Mientras está en la pestaña **Métricas diagramadas**, puede seleccionar el icono **Crear alarma** en la columna **Acciones**. El icono **Create alarm** se representa como una pequeña campana. Para obtener más información y opciones de notificaciones, consulte [Creación de una alarma de CloudWatch basada en una expresión matemática de métrica](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create-alarm-on-metric-math-expression.html) y [Notificaciones de cambios de alarma para usuarios](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Notify_Users_Alarm_Changes.html) en la *Guía del usuario de Amazon CloudWatch*.

También puede utilizar [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html) y [PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html) para realizar los cálculos mediante matemáticas métricas y crear alarmas basadas en los resultados.

# Uso de acciones programadas para anular los valores de previsión de Amazon ECS
<a name="predictive-scaling-overriding-forecast-capacity"></a>

A veces, es posible que tenga información adicional sobre los requisitos futuros de la aplicación que el cálculo del pronóstico no pueda tener en cuenta. Por ejemplo, los cálculos de previsiones podrían subestimar las tareas necesarias para un próximo evento de marketing. Puede utilizar acciones programadas para anular temporalmente el pronóstico durante periodos futuros. Las acciones programadas se pueden ejecutar de forma periódica, o en una fecha y hora específicas cuando hay fluctuaciones de demanda únicas. 

Por ejemplo, puede crear una acción programada con una cantidad de tareas superior a la pronosticada. En el tiempo de ejecución, Amazon ECS actualiza el número mínimo de tareas del servicio. Dado que el escalado predictivo optimiza en función de la cantidad de tareas, se cumple una acción programada con una cantidad mínima de tareas superior a los valores pronosticados. De este modo se evita que la cantidad de tareas sea inferior a la prevista. Para dejar de anular la previsión, utilice una segunda acción programada para devolver la cantidad mínima de tareas a su configuración original.

En el siguiente procedimiento se describen los pasos para anular el pronóstico durante periodos futuros. 

**Topics**
+ [Paso 1: (opcional) Analizar los datos de serie temporal](#analyzing-time-series-data)
+ [Paso 2: Crear dos acciones programadas](#scheduling-capacity)

**importante**  
En este tema, se supone que está intentando anular la previsión para escalar a una capacidad superior a la prevista. Si necesita reducir temporalmente la cantidad de tareas sin que interfiera una política de escalado predictivo, utilice en su lugar el modo de *solo previsión*. Mientras esté en el modo de solo previsión, el escalado predictivo seguirá generando previsiones, pero no aumentará automáticamente la cantidad de tareas. De esta manera, puede supervisar la utilización de los recursos y reducir manualmente el número de tareas según sea necesario. 

## Paso 1: (opcional) Analizar los datos de serie temporal
<a name="analyzing-time-series-data"></a>

Para comenzar, analice los datos de serie temporal del pronóstico. Este es un paso opcional, pero resulta útil si desea comprender los detalles del pronóstico.

1. **Recuperar el pronóstico**

   Una vez creado el pronóstico, puede consultar un periodo específico en el pronóstico. El objetivo de la consulta es obtener una vista completa de los datos de serie temporal para un periodo específico. 

   La consulta puede incluir hasta dos días de datos de pronósticos futuros. Si hace tiempo utiliza el escalado predictivo, también puede acceder a los datos de pronóstico anteriores. Sin embargo, la duración máxima entre la hora de inicio y la hora de finalización es de 30 días. 

   Para obtener el pronóstico mediante el comando [get-predictive-scaling-forecast](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/get-predictive-scaling-forecast.html) de la AWS CLI, proporcione los siguientes parámetros en el comando: 
   + Indique el nombre del clúster en el parámetro `resource-id`. 
   + Ingrese el nombre de la política en el parámetro `--policy-name`. 
   + Indique la hora de inicio en el parámetro `--start-time` para devolver solo los datos pronosticados para la hora especificada o con posterioridad.
   + Indique la hora de finalización en el parámetro `--end-time` para devolver solo los datos pronosticados para antes de la hora especificada. 

   ```
   aws application-autoscaling get-predictive-scaling-forecast \
       --service-namespace ecs \
       --resource-id service/MyCluster/test \
       --policy-name cpu40-predictive-scaling-policy \
       --scalable-dimension ecs:service:DesiredCount \
       --start-time "2021-05-19T17:00:00Z" \
       --end-time "2021-05-19T23:00:00Z"
   ```

   Si se ejecuta correctamente, el comando devuelve datos similares al ejemplo siguiente. 

   ```
   {
       "LoadForecast": [
           {
               "Timestamps": [
                   "2021-05-19T17:00:00+00:00",
                   "2021-05-19T18:00:00+00:00",
                   "2021-05-19T19:00:00+00:00",
                   "2021-05-19T20:00:00+00:00",
                   "2021-05-19T21:00:00+00:00",
                   "2021-05-19T22:00:00+00:00",
                   "2021-05-19T23:00:00+00:00"
               ],
               "Values": [
                   153.0655799339254,
                   128.8288551285919,
                   107.1179447150675,
                   197.3601844551528,
                   626.4039934516954,
                   596.9441277518481,
                   677.9675713779869
               ],
               "MetricSpecification": {
                   "TargetValue": 40.0,
                   "PredefinedMetricPairSpecification": {
                       "PredefinedMetricType": "ASGCPUUtilization"
                   }
               }
           }
       ],
       "CapacityForecast": {
           "Timestamps": [
               "2021-05-19T17:00:00+00:00",
               "2021-05-19T18:00:00+00:00",
               "2021-05-19T19:00:00+00:00",
               "2021-05-19T20:00:00+00:00",
               "2021-05-19T21:00:00+00:00",
               "2021-05-19T22:00:00+00:00",
               "2021-05-19T23:00:00+00:00"
           ],
           "Values": [
               2.0,
               2.0,
               2.0,
               2.0,
               4.0,
               4.0,
               4.0
           ]
       },
       "UpdateTime": "2021-05-19T01:52:50.118000+00:00"
   }
   ```

   La respuesta incluye dos pronósticos: `LoadForecast` y `CapacityForecast`. `LoadForecast` muestra el pronóstico de carga por hora. `CapacityForecast` muestra los valores pronosticados para la capacidad que se necesita cada hora para gestionar la carga pronosticada mientras se mantiene un `TargetValue` de 40,0 (una utilización media de la CPU del 40 %).

1. **Identifique el periodo de destino**

   Identifique la o las horas en las que debe tener lugar la fluctuación de la demanda única. Recuerde que las fechas y horas que aparecen en el pronóstico están en UTC.

## Paso 2: Crear dos acciones programadas
<a name="scheduling-capacity"></a>

A continuación, cree dos acciones programadas para un periodo específico en el que la aplicación tendrá una carga superior a la pronosticada. Por ejemplo, si tiene un evento de marketing que incrementará el tráfico hacia su sitio durante un periodo de tiempo limitado, puede programar una acción única para actualizar la capacidad mínima cuando comience. A continuación, programe otra acción para devolver la capacidad mínima a la configuración original cuando el evento finalice. 

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 de detalles del clúster, en la sección **Servicios**, elija el servicio.

   Se abrirá la página de detalles del servicio.

1. Elija **Escalado automático de servicio**.

   Se abrirá la página de políticas.

1. Elija **Acciones programadas** y, a continuación, elija **Crear**.

   Se abrirá la página **Crear acción de programación**.

1. En **Nombre de acción**, escriba un nombre único.

1. Para **Zona horaria**, elija una zona horaria.

   Todas las zonas horarias enumeradas provienen de la base de datos de zona horaria de IANA. Para obtener más información, consulte [List of tz database time zones](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones).

1. En **Hora de inicio**, introduzca la **fecha** y la **hora** en que comienza la acción.

1. En **Recurrencia**, elija **Una vez**.

1. En **Ajustes de tareas**, en Mínimo, introduzca un valor inferior o igual a la cantidad máxima de tareas.

1. Elija **Crear acción programada**.

   Se abrirá la página de políticas.

1. Configure una segunda acción programada para devolver la cantidad mínima de tareas a la configuración original al final del evento. El escalado predictivo puede escalar la cantidad de tareas únicamente cuando el valor establecido para **Mínimo** es menor que los valores de la previsión.

**Para crear dos acciones programadas para eventos únicos (AWS CLI)**  
Para utilizar la AWS CLI para crear las acciones programadas, utilice el comando [put-scheduled-update-group-action](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scheduled-update-group-action.html). 

Por ejemplo, definamos una programación que mantenga una capacidad mínima de tres instancias el 19 de mayo a las 17:00 durante ocho horas. En los siguientes comandos se muestra cómo implementar este escenario.

El primer comando [put-scheduled-update-group-action](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scheduled-update-group-action.html) indica a Amazon EC2 Auto Scaling que actualice la capacidad mínima del grupo de escalado automático especificado a las 17:00 (UTC) del 19 de mayo de 2021. 

```
aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-event-start \
  --auto-scaling-group-name my-asg --start-time "2021-05-19T17:00:00Z" --minimum-capacity 3
```

El segundo comando indica a Amazon EC2 Auto Scaling que establezca la capacidad mínima del grupo en uno a la 1:00 (UTC) del 20 de mayo de 2021. 

```
aws autoscaling put-scheduled-update-group-action --scheduled-action-name my-event-end \
  --auto-scaling-group-name my-asg --start-time "2021-05-20T01:00:00Z" --minimum-capacity 1
```

Después de agregar estas acciones programadas al grupo de escalado automático, Amazon EC2 Auto Scaling realiza lo siguiente: 
+ A las 17:00 (UTC) del 19 de mayo de 2021, se ejecuta la primera acción programada. Si el grupo tiene actualmente menos de tres instancias, el grupo se escala horizontalmente hasta tres instancias. Durante este tiempo y durante las siguientes ocho horas, Amazon EC2 Auto Scaling puede seguir escalando horizontalmente si la capacidad prevista es superior a la capacidad real o si existe una política de escalado dinámico en vigor. 
+ A la 1:00 (UTC) del 20 de mayo de 2021, se ejecuta la segunda acción programada. Esto devuelve la capacidad mínima a la configuración original al final del evento.

### Escalado basado en programaciones recurrentes
<a name="scheduling-recurring-actions"></a>

Para anular el pronóstico para el mismo periodo cada semana, cree dos acciones programadas y proporcione la lógica de fecha y hora utilizando una expresión cron. 

El formato de una expresión cron consta de cinco campos separados por espacios: [minuto] [hora] [día\$1del\$1mes] [mes\$1del\$1año] [día\$1de\$1la\$1semana]. Los campos pueden contener cualquier valor permitido, incluidos caracteres especiales. 

Por ejemplo, la siguiente expresión cron ejecuta una acción todos los martes a las 6:30. El asterisco se utiliza como comodín para coincidir con todos los valores de un campo.

```
30 6 * * 2
```

### Véase también
<a name="scheduling-scaling-see-also"></a>

Para obtener más información sobre cómo administrar las acciones programadas, consulte [Uso de acciones programadas para escalar los servicios de Amazon ECS](service-autoscaling-schedulescaling.md).

# Políticas avanzadas de escalado predictivo mediante métricas personalizadas para Amazon ECS
<a name="predictive-scaling-custom-metrics"></a>

Puede utilizar métricas predefinidas o personalizadas en una política de escalado predictivo. Las métricas personalizadas son prácticas cuando las métricas predefinidas (como CPU, memoria, etc.) no son suficientes para describir adecuadamente la carga de la aplicación.

Al crear una política de escalado predictivo con métricas personalizadas, puede especificar otras métricas de CloudWatch que proporciona AWS. Si lo desea, también puede especificar las métricas que defina y publique usted. También puede usar las matemáticas métricas para agregar y transformar las métricas existentes en una nueva serie temporal que AWS no realice un seguimiento automático. Por ejemplo, cuando combina valores en los datos al calcular nuevas sumas o promedios, se denomina *agregación*. Los datos obtenidos se denominan *aggregate* (agrupación).

En la siguiente sección se encuentran las mejores prácticas y ejemplos de cómo construir la estructura JSON para la política.

## Requisitos previos
<a name="predictive-scaling-custom-metrics-prerequisites"></a>

Para agregar métricas personalizadas en la política de escalado predictivo, debe tener permisos de `cloudwatch:GetMetricData`.

Para especificar sus propias métricas en lugar de las métricas que proporciona AWS, debe, en primer lugar, publicar las métricas en CloudWatch. Para obtener más información, consulte [Publicación de métricas personalizadas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) en la *Guía del usuario de Amazon CloudWatch*. 

Si publica sus propias métricas, asegúrese de publicar los puntos de datos con una frecuencia mínima de cinco minutos. Los puntos de datos se recuperan de CloudWatch en función de la duración del periodo que necesita. Por ejemplo, la especificación de la métrica de carga utiliza métricas por horas que permiten medir la carga de su aplicación. CloudWatch utiliza sus datos métricos publicados para proporcionar un único valor de datos en cualquier periodo de una hora mediante la agrupación de todos los puntos de datos con marcas temporales que entran en cada periodo de una hora.

## Prácticas recomendadas
<a name="predictive-scaling-custom-metrics-best-practices"></a>

Las siguientes prácticas recomendadas pueden ayudarlo a utilizar las métricas personalizadas de manera más eficaz:
+ La métrica más útil para la especificación de las métricas de carga es una métrica que representa la carga en un grupo de escalado automático en su conjunto.
+ La métrica más útil para el escalado por parte la especificación de la métrica de escalado es una métrica de rendimiento o uso promedio por tarea.
+ El uso objetivo debe coincidir con el tipo de métrica de escalado. Para configurar una política que emplee la utilización de la CPU, se trata de un porcentaje objetivo, por ejemplo.
+ Si no se siguen estas recomendaciones, es probable que los valores futuros pronosticados de la serie temporal sean incorrectos. Para validar que los datos son correctos, puede ver los valores pronosticados en la consola. Como alternativa, una vez creada la política de escalado predictivo, examine los objetos `LoadForecast` que se devuelven mediante una llamada a la API [GetPredictiveScalingForecast](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_GetPredictiveScalingForecast.html).
+ Se recomienda configurar el escalado predictivo en modo Solo pronóstico para poder evaluar el pronóstico antes de que el escalado predictivo comience a escalar de forma activa.

## Limitaciones
<a name="predicitve-scaling-custom-metrics-limitations"></a>
+ Puede consultar puntos de datos de hasta 10 métricas en una especificación de métrica.
+ A efectos de este límite, una expresión cuenta como una métrica.

## Solución de problemas de una política de escalado predictivo con métricas personalizadas
<a name="predictive-scaling-custom-metrics-troubleshooting"></a>

Si se produce un problema durante el uso de las métricas personalizadas, se recomienda seguir los siguientes pasos:
+ Si encuentra un problema en una implementación azul/verde al usar una expresión de búsqueda, asegúrese de haber creado una expresión de búsqueda que busque una coincidencia parcial y no una coincidencia exacta. También debe comprobar que en la consulta solo se busquen los grupos de escalado automático que se ejecutan en la aplicación específica. Para obtener más información sobre la sintaxis de expresiones de búsqueda, consulte [Sintaxis de la expresión de búsqueda de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/search-expression-syntax.html) en la *Guía del usuario de Amazon CloudWatch*.
+ El comando [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/put-scaling-policy.html) valida una expresión cuando crea la política de escalado. Sin embargo, existe la posibilidad de que este comando no identifique la causa exacta de los errores detectados. Para corregir esto, solucione los errores que recibe en la respuesta de una solicitud al comando [get-metric-data](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/get-metric-data.html). También puede solucionar problemas de la expresión desde la consola de CloudWatch.
+ Debe especificar `false` para `ReturnData` si `MetricDataQueries` especifica la función SEARCH() por sí sola sin una función matemática como SUM(). Esto se debe a que las expresiones de búsqueda podrían devolver varias series temporales, mientras que una especificación métrica basada en una expresión solo puede devolver una serie temporal.
+ Todas las métricas que aparecen en una expresión de búsqueda deben tener la misma resolución.

# Creación del archivo JSON para las métricas personalizadas de escalado predictivo con Amazon ECS
<a name="predictive-scaling-custom-metrics-example"></a>

En la siguiente sección hay ejemplos de cómo configurar el escalado predictivo para consultar datos de CloudWatch. Existen dos métodos diferentes para configurar esta opción, y el método que elija afectará al formato que utilice para construir el JSON para su política de escalado predictivo. Cuando usa matemáticas métricas, el formato del JSON varía aún más en función de las matemáticas métricas que se estén desempeñando.

1. Para crear una política que obtenga datos directamente de otras métricas de CloudWatch proporcionadas por AWS o de las métricas que publique en CloudWatch, consulte [Ejemplo de política de escalado predictivo con métricas personalizadas de escalado y de carga mediante la AWS CLI](#predictive-scaling-custom-metrics-example1).

## Ejemplo de política de escalado predictivo con métricas personalizadas de escalado y de carga mediante la AWS CLI
<a name="predictive-scaling-custom-metrics-example1"></a>

Para crear una política de escalado predictivo con métricas de carga y escalado personalizadas con AWS CLI, almacene los argumentos de `--predictive-scaling-configuration` en un archivo JSON denominado `config.json`.

Para empezar a agregar métricas personalizadas, sustituya los valores reemplazables del siguiente ejemplo por los de sus métricas y su utilización objetivo.

```
{
  "MetricSpecifications": [
    {
      "TargetValue": 50,
      "CustomizedScalingMetricSpecification": {
        "MetricDataQueries": [
          {
            "Id": "scaling_metric",
            "MetricStat": {
              "Metric": {
                "MetricName": "MyUtilizationMetric",
                "Namespace": "MyNameSpace",
                "Dimensions": [
                  {
                    "Name": "MyOptionalMetricDimensionName",
                    "Value": "MyOptionalMetricDimensionValue"
                  }
                ]
              },
              "Stat": "Average"
            }
          }
        ]
      },
      "CustomizedLoadMetricSpecification": {
        "MetricDataQueries": [
          {
            "Id": "load_metric",
            "MetricStat": {
              "Metric": {
                "MetricName": "MyLoadMetric",
                "Namespace": "MyNameSpace",
                "Dimensions": [
                  {
                    "Name": "MyOptionalMetricDimensionName",
                    "Value": "MyOptionalMetricDimensionValue"
                  }
                ]
              },
              "Stat": "Sum"
            }
          }
        ]
      }
    }
  ]
}
```

Para obtener más información, consulte [MetricDataQuery](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_MetricDataQuery.html) en la *Referencia de la API de Amazon EC2 Auto Scaling*.

**nota**  
Los siguientes son algunos de los recursos adicionales que pueden ayudarle a encontrar nombres de métricas, espacios de nombres, dimensiones y estadísticas para las métricas de CloudWatch:   
Para obtener más información sobre las métricas disponibles en los servicios de AWS, consulte [Servicios de AWS que publican métricas de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/aws-services-cloudwatch-metrics.html) en la *Guía del usuario de Amazon CloudWatch*.
Para obtener el nombre exacto de la métrica, el espacio de nombres y las dimensiones (si corresponde) de una métrica de CloudWatch con la AWS CLI, consulte [list-metrics](https://docs.aws.amazon.com/cli/latest/reference/cloudwatch/list-metrics.html). 

Para crear esta política, ejecute el comando [put-scaling-policy](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/put-scaling-policy.html) con el archivo de JSON como entrada, tal y como se muestra en el ejemplo siguiente.

```
aws application-autoscaling put-scaling-policy --policy-name my-predictive-scaling-policy \
  --auto-scaling-group-name my-asg --policy-type PredictiveScaling \
  --predictive-scaling-configuration file://config.json
```

Si se ejecuta correctamente, este comando devuelve el nombre de recurso de Amazon (ARN) de la política.

```
{
  "PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-predictive-scaling-policy",
  "Alarms": []
}
```

# Uso de expresiones de cálculos de métricas
<a name="predictive-scaling-math-expression"></a>

En la siguiente sección se proporciona información acerca del uso de las matemáticas de métricas con políticas de escalado predictivo en su política. 

## Descripción del cálculo de métricas
<a name="predictive-scaling-custom-metrics-math"></a>

Si todo lo que desea hacer es agrupar datos de métricas existentes, los cálculos de métricas de CloudWatch permiten ahorrar tiempo y costos en la publicación de otras métricas en CloudWatch. Puede utilizar cualquier métrica que proporcione AWS y, además, puede usar las métricas que defina como parte de sus aplicaciones.

Para obtener más información, consulte [Uso de cálculo de métricas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) en la *Guía del usuario de Amazon CloudWatch*. 

Si decide utilizar una expresión de cálculo de métricas en su política de escalado predictivo, tenga en cuenta los siguientes aspectos:
+ Las operaciones de cálculo de métricas utilizan los puntos de datos de la combinación única de nombre de métrica, espacio de nombres y pares de claves/valores de la dimensión de las métricas. 
+ Puede utilizar cualquier operador aritmético (\$1 - \$1 / ^), función estadística (como PROM o SUM) u otra función que sea compatible con CloudWatch. 
+ Puede utilizar tanto las métricas como los resultados de otras expresiones matemáticas en las fórmulas de la expresión matemática. 
+ Sus expresiones de cálculo de métricas se pueden formar con diferentes agrupaciones. Sin embargo, es una práctica recomendada para el resultado final de la agrupación que se utilice `Average` para la métrica de escalado y `Sum` para la métrica de carga.
+ Todas las expresiones utilizadas en la especificación de una métrica deben devolver en última instancia una única serie temporal.

Para utilizar cálculos de métricas, haga lo siguiente:
+ Elija una o más métricas de CloudWatch. A continuación, cree la expresión. Para obtener más información, consulte [Uso de cálculo de métricas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) en la *Guía del usuario de Amazon CloudWatch*. 
+ Compruebe que la expresión del cálculo de métricas sea válida mediante el uso de la consola de CloudWatch o la API [GetMetricData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html) de CloudWatch.

## Ejemplo de política de escalado predictivo que combina las métricas mediante el uso del cálculo de métricas (AWS CLI)
<a name="custom-metrics-ex2"></a>

En ocasiones, en lugar de especificar la métrica directamente, es posible que tenga que procesar primero sus datos de alguna manera. Por ejemplo, puede tener una aplicación que extraiga trabajo de una cola de Amazon SQS y puede querer utilizar el número de elementos en la cola como criterio para realizar un escalado predictivo. El número de mensajes en la cola no define exclusivamente el número de instancias que necesita. Por lo tanto, es necesario trabajar más para crear una métrica que pueda utilizarse para calcular las tareas pendientes por instancia.

A continuación se presenta un ejemplo de política de escalado predictivo para este caso. Especifica las métricas de escalado y carga que dependen de la métrica `ApproximateNumberOfMessagesVisible` de Amazon SQS, es decir, el número de mensajes disponibles para recuperar de la cola. Asimismo, utiliza la métrica `GroupInServiceInstances` de Amazon EC2 Auto Scaling y una expresión matemática que permite calcular las tareas pendientes por instancia para la métrica de escalado.

```
aws application-autoscaling put-scaling-policy --policy-name my-sqs-custom-metrics-policy \
  --policy-type PredictiveScaling \
  --predictive-scaling-configuration file://config.json
  --service-namespace ecs \
  --resource-id service/MyCluster/test \
  "MetricSpecifications": [
    {
      "TargetValue": 100,
      "CustomizedScalingMetricSpecification": {
        "MetricDataQueries": [
          {
            "Label": "Get the queue size (the number of messages waiting to be processed)",
            "Id": "queue_size",
            "MetricStat": {
              "Metric": {
                "MetricName": "ApproximateNumberOfMessagesVisible",
                "Namespace": "AWS/SQS",
                "Dimensions": [
                  {
                    "Name": "QueueName",
                    "Value": "my-queue"
                  }
                ]
              },
              "Stat": "Sum"
            },
            "ReturnData": false
          },
          {
            "Label": "Get the group size (the number of running instances)",
            "Id": "running_capacity",
            "MetricStat": {
              "Metric": {
                "MetricName": "GroupInServiceInstances",
                "Namespace": "AWS/AutoScaling",
                "Dimensions": [
                  {
                    "Name": "AutoScalingGroupName",
                    "Value": "my-asg"
                  }
                ]
              },
              "Stat": "Sum"
            },
            "ReturnData": false
          },
          {
            "Label": "Calculate the backlog per instance",
            "Id": "scaling_metric",
            "Expression": "queue_size / running_capacity",
            "ReturnData": true
          }
        ]
      },
      "CustomizedLoadMetricSpecification": {
        "MetricDataQueries": [
          {
            "Id": "load_metric",
            "MetricStat": {
              "Metric": {
                "MetricName": "ApproximateNumberOfMessagesVisible",
                "Namespace": "AWS/SQS",
                "Dimensions": [
                  {
                    "Name": "QueueName",
                    "Value": "my-queue"
                  }
                ],
              },
              "Stat": "Sum"
            },
            "ReturnData": true
          }
        ]
      }
    }
  ]
}
```

En el ejemplo se devuelve el ARN de la política.

```
{
  "PolicyARN": "arn:aws:autoscaling:region:account-id:scalingPolicy:2f4f5048-d8a8-4d14-b13a-d1905620f345:autoScalingGroupName/my-asg:policyName/my-sqs-custom-metrics-policy",
  "Alarms": []
}
```

# Interconexión de los servicios de Amazon ECS
<a name="interconnecting-services"></a>

Las aplicaciones que se ejecutan en las tareas de Amazon ECS a menudo necesitan recibir conexiones de Internet o conectarse a otras aplicaciones que se ejecutan en los servicios de Amazon ECS. Si necesita conexiones externas desde Internet, le recomendamos usar Elastic Load Balancing. Para obtener más información sobre el equilibrador de carga integrado, consulte [Uso del equilibrador de carga para distribuir el tráfico de servicio de Amazon ECS](service-load-balancing.md).

Si necesita una aplicación para conectarse a otras aplicaciones que se ejecutan en los servicios de Amazon ECS, Amazon ECS proporciona las siguientes formas de hacerlo sin un equilibrador de carga:
+ *Amazon ECS Service Connect*

  Recomendamos Service Connect, que proporciona la configuración de Amazon ECS para la detección de servicios, la conectividad y la supervisión del tráfico. Con Service Connect, sus aplicaciones pueden usar nombres abreviados y puertos estándar para conectarse a los servicios de Amazon ECS del mismo clúster o a otros clústeres, incluso a través de VPC de la misma Región de AWS.

  Cuando utiliza Service Connect, Amazon ECS administra todas las partes de la detección de servicios: crea los nombres que se pueden descubrir, administra dinámicamente las entradas de cada tarea a medida que se inician y se detienen las tareas y ejecuta un agente en cada tarea que está configurado para descubrir los nombres. La aplicación puede buscar los nombres mediante la funcionalidad estándar para los nombres de DNS y establecer conexiones. Si su aplicación ya lo hace, no tendrá que modificarla para usar Service Connect.

  Usted proporciona la configuración completa dentro de cada definición de servicio y tarea. Amazon ECS administra los cambios en esta configuración en cada implementación de servicio para garantizar que todas las tareas de una implementación se comporten de la misma manera. Por ejemplo, un problema común con el DNS en la detección de servicios es el control de una migración. Si cambia un nombre de DNS para que apunte a las nuevas direcciones IP de reemplazo, es posible que pase el tiempo máximo de TTL antes de que todos los clientes comiencen a usar el nuevo servicio. Con Service Connect, la implementación del cliente actualiza la configuración sustituyendo las tareas del cliente. Puede configurar el disyuntor de implementación y otras configuraciones de implementación para que afecten a los cambios de Service Connect de la misma manera que cualquier otra implementación.

  Para obtener más información, consulte [Uso de Service Connect para conectar los servicios de Amazon ECS con nombres abreviados](service-connect.md).
+ *Detección de servicios de Amazon ECS*

  Otro enfoque para la comunicación de servicio a servicio es la comunicación directa mediante la detección de servicios. En este enfoque, puede utilizar la integración de detección de servicios AWS Cloud Map con Amazon ECS. Mediante la detección de servicios, Amazon ECS sincroniza la lista de tareas iniciadas en AWS Cloud Map, que mantiene un nombre de host DNS que se resuelve en las direcciones IP internas de una o más tareas de ese servicio en particular. Otros servicios de Amazon VPC pueden usar este nombre de host DNS para enviar tráfico directamente a otro contenedor mediante su dirección IP interna. 

  Este enfoque de comunicación de servicio a servicio proporciona una baja latencia. No hay componentes adicionales entre los contenedores. El tráfico viaja directamente de un contenedor al otro.

  Este enfoque es adecuado cuando se utiliza el modo de red `awsvpc`, en el que cada tarea tiene su propia dirección IP única. La mayoría de los programas solo admiten el uso de registros `A` de DNS, que se resuelven directamente en las direcciones IP. Cuando se utiliza el modo de red `awsvpc`, la dirección IP de cada tarea es un registro `A`. Sin embargo, si utiliza el modo de red `bridge`, es posible que varios contenedores compartan la misma dirección IP. Además, las asignaciones dinámicas de puertos hacen que a los contenedores se les asignen números de puerto de forma aleatoria en esa única dirección IP. En este punto, un registro `A` ya no es suficiente para la detección de servicios. También debe usar un registro `SRV`. Este tipo de registro puede hacer un seguimiento de las direcciones IP y los números de puerto, pero requiere que configure las aplicaciones de forma adecuada. Es posible que algunas aplicaciones prediseñadas que utilice no admitan registros `SRV`.

  Otra ventaja del modo de red `awsvpc` es que tiene un grupo de seguridad único para cada servicio. Puede configurar este grupo de seguridad para permitir las conexiones entrantes únicamente desde los servicios ascendentes específicos que necesitan comunicarse con ese servicio.

  La principal desventaja de la comunicación directa entre servicios mediante la detección de servicios es que se debe implementar una lógica adicional para llevar a cabo reintentos y solucionar los errores de conexión. Los registros de DNS tienen un período de vida (TTL) que controla el periodo durante el que se almacenan en caché. El registro DNS tarda algún tiempo en actualizarse y la caché en caducar para que las aplicaciones puedan recoger la última versión del registro DNS. Por lo tanto, su aplicación podría terminar resolviendo el registro DNS para que apunte a otro contenedor que ya no está allí. Su aplicación debe gestionar los reintentos y tener una lógica para ignorar los backends defectuosos.

  Para obtener más información, consulte [Uso de la detección de servicios para conectar los servicios de Amazon ECS con nombres de DNS](service-discovery.md)
+ *Amazon VPC Lattice *

  Amazon VPC Lattice es un servicio de redes de aplicaciones administrado que utilizan los clientes de Amazon ECS para observar, proteger y supervisar las aplicaciones creadas en servicios de computación, VPC y cuentas de AWS sin tener que modificar su código.

  VPC Lattice usa grupos de destino, que son un conjunto de recursos de computación. Estos destinos ejecutan la aplicación o servicio y pueden ser instancias de Amazon EC2, direcciones IP, funciones de Lambda y equilibradores de carga de aplicación. Al asociar sus servicios de Amazon ECS a un grupo de destino de VPC Lattice, los clientes ahora pueden habilitar las tareas de Amazon ECS como destinos de IP en VPC Lattice. Amazon ECS registra automáticamente las tareas en el grupo de destino de VPC Lattice cuando se lanzan las tareas del servicio registrado.

  Para obtener más información, consulte [Uso de Amazon VPC Lattice para conectar, observar y proteger los servicios de Amazon ECS](ecs-vpc-lattice.md).

## Tabla de compatibilidad del modo de red
<a name="interconnect-network-mode-compatibility-table"></a>

La siguiente tabla describe la compatibilidad entre estas opciones y los modos de red de tareas. En la tabla, “cliente” hace referencia a la aplicación que hace las conexiones desde una tarea de Amazon ECS.


****  

| Opciones de interconexión | Puenteado | `awsvpc` | Host | 
| --- | --- | --- | --- | 
| Detección de servicios | sí, pero requiere que los clientes conozcan los registros SRV en DNS sin hostPort. | sí | sí, pero requiere que los clientes conozcan los registros SRV en DNS sin hostPort. | 
| Service Connect  | sí | sí | no | 
| VPC Lattice | sí | sí | sí | 

# Uso de Service Connect para conectar los servicios de Amazon ECS con nombres abreviados
<a name="service-connect"></a>

Amazon ECS Service Connect proporciona la administración de la comunicación de servicio a servicio como configuración de Amazon ECS. Crea una detección de servicios y una malla de servicios en Amazon ECS. Esto proporciona la configuración completa de cada servicio que administra usted mediante implementaciones de servicios, una manera unificada de hacer referencia a los servicios dentro de los espacios de nombres que no depende de la configuración de DNS de VPC, y métricas y registros estandarizados para supervisar todas las aplicaciones. Service Connect solo interconecta servicios.

En el siguiente diagrama se muestra un ejemplo de red Service Connect con 2 subredes en la VPC y 2 servicios. Un servicio de cliente que ejecuta WordPress con 1 tarea en cada subred. Un servicio de servidor que ejecuta MySQL con 1 tarea en cada subred. Ambos servicios tienen una alta disponibilidad y son resilientes ante los problemas de tareas y zonas de disponibilidad, ya que cada servicio ejecuta varias tareas distribuidas en 2 subredes. Las flechas continuas muestran una conexión de WordPress a MySQL. Por ejemplo, un comando de la CLI de `mysql --host=mysql` que se ejecuta desde el interior del contenedor de WordPress en la tarea con la dirección IP `172.31.16.1`. El comando utiliza el nombre corto `mysql` en el puerto predeterminado para MySQL. Este nombre y puerto se conectan al proxy de Service Connect en la misma tarea. El proxy de la tarea de WordPress utiliza el equilibrador de carga de distribución equilibrada y cualquier información de error anterior en la detección de valores atípicos para elegir a qué tarea de MySQL conectarse. Como muestran las flechas continuas del diagrama, el proxy se conecta al segundo proxy de la tarea MySQL con la dirección IP `172.31.16.2`. El segundo proxy se conecta al servidor MySQL local en la misma tarea. Ambos proxys informan del rendimiento de la conexión, que se puede ver en los gráficos de las consolas de Amazon ECS y de Amazon CloudWatch, de modo que puede obtener métricas de rendimiento de todo tipo de aplicaciones de la misma manera.

![\[Ejemplo de red Service Connect que muestra un mínimo de servicios de alta disponibilidad\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/images/serviceconnect.png)


Los siguientes términos se utilizan con Service Connect:

**nombre del puerto**  
La configuración de definición de tareas de Amazon ECS que asigna un nombre a una asignación de puertos determinada. Esta configuración solo la usa Amazon ECS Service Connect.

**alias de cliente**  
La configuración del servicio de Amazon ECS que asigna el número de puerto que se usa en el punto de conexión. Además, el alias del cliente puede asignar el nombre DNS del punto de conexión y anular el nombre de detección. Si no se proporciona un nombre de detección en el servicio de Amazon ECS, el nombre del alias del cliente sustituye al nombre del puerto como nombre del punto de conexión. Para ver ejemplos de puntos de conexión, consulte la definición de *punto de conexión*. Se pueden asignar varios alias de cliente a un servicio de Amazon ECS. Esta configuración solo la usa Amazon ECS Service Connect.

**nombre de detección**  
El nombre intermedio opcional que puede crear para un puerto especificado de la definición de la tarea. Este nombre se utiliza para crear un servicio de AWS Cloud Map. Si no se proporciona este nombre, se utiliza el nombre del puerto de la definición de la tarea. Se pueden asignar varios nombres de detección a un puerto específico de un servicio de Amazon ECS. Esta configuración solo la usa Amazon ECS Service Connect.  
Los nombres de servicio de AWS Cloud Map deben ser únicos en un espacio de nombres. Debido a esta limitación, solo puede tener una configuración de Service Connect sin un nombre de detección para una definición de tarea determinada en cada espacio de nombres.

**endpoint**  
La URL para conectarse a una API o un sitio web. La URL contiene el protocolo, un nombre DNS y el puerto. Para obtener más información sobre los puntos de conexión en general, consulte [punto de conexión](https://docs.aws.amazon.com/glossary/latest/reference/glos-chap.html#endpoint) en el *glosario de AWS* en la Referencia general de Amazon Web Services.  
Service Connect crea puntos de conexión que se conectan a los servicios de Amazon ECS y configura las tareas de los servicios de Amazon ECS para conectarse a los puntos de conexión. La URL contiene el protocolo, un nombre DNS y el puerto. Seleccione el protocolo y el nombre del puerto en la definición de la tarea, ya que el puerto debe coincidir con la aplicación que se encuentra dentro de la imagen del contenedor. En el servicio, selecciona cada puerto por nombre y puede asignar el nombre DNS. Si no especifica un nombre DNS en la configuración del servicio de Amazon ECS, se utiliza de forma predeterminada el nombre del puerto de la definición de la tarea. Por ejemplo, un punto de conexión de Service Connect podría ser `http://blog:80`, `grpc://checkout:8080` o `http://_db.production.internal:99`.

**Servicio de Service Connect**  
La configuración de un punto de conexión único en un servicio de Amazon ECS. Forma parte de la configuración de Service Connect y consiste en una sola fila en la **Service Connect and discovery name configuration** (Configuración de Service Connect y nombre de detección) de la consola, o un objeto de la lista de `services` de la configuración JSON de un servicio de Amazon ECS. Esta configuración solo la usa Amazon ECS Service Connect.  
Para obtener más información, consulte [ServiceConnectService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectService.html) en la Referencia de la API de Amazon Elastic Container Service.

**namespace**  
El nombre corto o el nombre de recurso de Amazon (ARN) completo del espacio de nombres de AWS Cloud Map para su uso con Service Connect. El espacio de nombres debe estar en la misma Región de AWS que el servicio y el clúster de Amazon ECS. El tipo de espacio de nombres en AWS Cloud Map no afecta a Service Connect. El espacio de nombres puede ser uno compartido con su Cuenta de AWS mediante AWS Resource Access Manager (AWS RAM) en Regiones de AWS en las que AWS RAM esté disponible. Para obtener más información sobre los espacios de nombres compartidos, consulte [Cross-account AWS Cloud Map namespace sharing](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) en la *Guía para desarrolladores de AWS Cloud Map*.  
Service Connect utiliza el espacio de nombres de AWS Cloud Map como una agrupación lógica de tareas de Amazon ECS que se comunican entre sí. Cada servicio de Amazon ECS solo puede pertenecer a un espacio de nombres. Los servicios de un espacio de nombres se pueden distribuir en diferentes clústeres de Amazon ECS dentro de la misma Región de AWS. Si el espacio de nombres es un espacio de nombres compartido, los servicios se pueden distribuir entre las Cuentas de AWS del propietario del espacio de nombres y del consumidor del espacio de nombres. Puede organizar con toda libertad los servicios según cualquier criterio.

**servicio de cliente**  
Un servicio que ejecuta una aplicación cliente de red. Este servicio debe tener un espacio de nombres configurado. Cada tarea del servicio puede detectar y conectarse a todos los puntos de conexión del espacio de nombres a través de un contenedor del proxy de Service Connect.  
Si alguno de los contenedores de la tarea necesita conectarse a un punto de conexión desde un servicio de un espacio de nombres, elija un servicio de cliente. Si una aplicación de frontend, proxy inverso o equilibrador de carga recibe tráfico externo mediante otros métodos, como desde Elastic Load Balancing, podría utilizar este tipo de configuración de Service Connect.

**servicio cliente-servidor**  
Un servicio de Amazon ECS que ejecuta una aplicación de red o servicio web. Este servicio debe tener un espacio de nombres y al menos un punto de conexión configurado. Se puede acceder a cada tarea del servicio mediante los puntos de conexión. El contenedor del proxy de Service Connect escucha el nombre y el puerto del punto de conexión para dirigir el tráfico a los contenedores de aplicaciones de la tarea.  
Si alguno de los contenedores expone y escucha el tráfico de red en un puerto, elija un servicio cliente-servidor. Estas aplicaciones no necesitan conectarse a otros servicios cliente-servidor en el mismo espacio de nombres, pero la configuración del cliente es necesaria. Un backend, un middleware, un nivel empresarial o la mayoría de los microservicios pueden utilizar este tipo de configuración de Service Connect. Si desea que una aplicación de frontend, proxy inverso o equilibrador de carga reciba tráfico de otros servicios configurados con Service Connect en el mismo espacio de nombres, estos servicios deben usar este tipo de configuración de Service Connect.

La característica Service Connect crea una red virtual de servicios relacionados. Se puede usar la misma configuración de servicio en varios espacios de nombres diferentes para ejecutar conjuntos de aplicaciones independientes, pero idénticos. Service Connect define el contenedor del proxy en el servicio de Amazon ECS. De esta forma, se puede utilizar la misma definición de tarea para ejecutar aplicaciones idénticas en diferentes espacios de nombres con diferentes configuraciones de Service Connect. Cada tarea que lleva a cabo el servicio ejecuta un contenedor del proxy en la tarea.

Service Connect es adecuado para conexiones entre servicios de Amazon ECS dentro del mismo espacio de nombres. Para las siguientes aplicaciones, debe utilizar un método de interconexión adicional para conectarse a un servicio de Amazon ECS configurado con Service Connect:
+ Tareas configuradas en otros espacios de nombres
+ Tareas que no están configuradas para Service Connect
+ Otras aplicaciones fuera de Amazon ECS

Estas aplicaciones pueden conectarse a través del proxy de Service Connect, pero no pueden resolver los nombres de los puntos de conexión de Service Connect.

Para que estas aplicaciones resuelvan las direcciones IP de las tareas de Amazon ECS, debe utilizar otro método de interconexión. 

**Topics**
+ [Precios](#service-connect-pricing)
+ [Componentes de Amazon ECS Service Connect](service-connect-concepts-deploy.md)
+ [Información general de la configuración de Amazon ECS Service Connect](service-connect-concepts.md)
+ [Amazon ECS Service Connect con espacios de nombres de AWS Cloud Map compartidos](service-connect-shared-namespaces.md)
+ [Registros de acceso de Amazon ECS Service Connect](service-connect-envoy-access-logs.md)
+ [Cifrado del tráfico de Amazon ECS Service Connect](service-connect-tls.md)
+ [Configuración de Amazon ECS Service Connect con la AWS CLI](create-service-connect.md)

## Precios
<a name="service-connect-pricing"></a>
+ Los precios de Amazon ECS Service Connect dependerán de si utiliza AWS Fargate o la infraestructura de Amazon EC2 para alojar sus cargas de trabajo en contenedores. Cuando se utiliza Amazon ECS en AWS Outposts, los precios siguen el mismo modelo que cuando se utiliza Amazon EC2 directamente. Para obtener más información, consulte [Precios de Amazon ECS](https://aws.amazon.com/ecs/pricing).
+ El uso de Amazon ECS Service Connect no supone ningún cargo adicional.
+ El uso de AWS Cloud Map junto con Service Connect no supone ningún cargo adicional.
+ Los clientes pagan por los recursos de computación que utiliza Amazon ECS Service Connect, incluidas la vCPU y la memoria. Como el agente de Amazon ECS Service Connect se pone en marcha dentro de una tarea del cliente, poner en marcha no conlleva ningún cargo adicional. Los recursos de la tarea se comparten entre la carga de trabajo del cliente y el agente de Amazon ECS Service Connect.
+ Al utilizar la funcionalidad de cifrado de tráfico de Amazon ECS Service Connect con AWS Private CA, los clientes pagan por la autoridad de certificación privada que crean y por cada certificado TLS emitido. Para obtener más información, consulte [Precios de AWS Private Certificate Authority](https://aws.amazon.com/private-ca/pricing/). Para calcular el costo mensual de los certificados TLS, los clientes deben saber el número de servicios de Amazon ECS que tienen activado el TLS, multiplicarlo por el costo del certificado y, a continuación, multiplicarlo por seis. Como Amazon ECS Service Connect rota automáticamente los certificados TLS cada cinco días, se emiten seis certificados por servicio de Amazon ECS, por mes, de media.

# Componentes de Amazon ECS Service Connect
<a name="service-connect-concepts-deploy"></a>

Cuando utiliza Amazon ECS Service Connect, configura cada servicio de Amazon ECS para ejecutar una aplicación de servidor que recibe solicitudes de red (servicio cliente-servidor) o para ejecutar una aplicación cliente que hace las solicitudes (servicio de cliente).

Cuando se prepare para empezar a utilizar Service Connect, comience con un servicio cliente-servidor. Puede agregar una configuración de Service Connect a un servicio nuevo o existente. Amazon ECS crea un punto de conexión de Service Connect en el espacio de nombres. Además, Amazon ECS crea una nueva implementación en el servicio para reemplazar las tareas que se están ejecutando actualmente.

Las tareas y otras aplicaciones existentes pueden seguir conectándose a los puntos de conexión existentes y a las aplicaciones externas. Si un servicio cliente-servidor agrega tareas mediante el escalado horizontal, las nuevas conexiones de los clientes se equilibrarán entre todas las tareas. Si se actualiza un servicio cliente-servidor, las nuevas conexiones de los clientes se equilibrarán entre las tareas de la nueva versión.

Las tareas existentes no pueden resolverse ni conectarse al nuevo punto de conexión. Solo las tareas nuevas con una configuración de Service Connect en el mismo espacio de nombres y que comiencen a ejecutarse después de esta implementación pueden resolverse y conectarse a este punto de conexión. 

Esto significa que el operador de la aplicación cliente determina cuándo cambia la configuración de su aplicación, aunque el operador de la aplicación de servidor puede cambiar su configuración en cualquier momento. La lista de puntos de conexión del espacio de nombres puede cambiar cada vez que se implemente cualquier servicio del espacio de nombres. Las tareas existentes y las tareas de reemplazo siguen comportándose del mismo modo que después de la implementación más reciente.

Considere los siguientes ejemplos:

En primer lugar, suponga que está creando una aplicación que está disponible para el Internet público en una sola plantilla de AWS CloudFormation y una sola pila de CloudFormation. CloudFormation debe crear la detección pública y la accesibilidad en último lugar, incluido el servicio de cliente frontend. El servicio debe crearse en este orden para evitar un período en el que el servicio de cliente frontend se esté ejecutando y esté disponible para el público, pero el backend no lo esté. Esto evita que los mensajes de error se envíen al público durante ese periodo. En AWS CloudFormation, debe utilizar `dependsOn` para indicar a CloudFormation que no se pueden crear varios servicios de Amazon ECS en paralelo o simultáneamente. Debe agregar `dependsOn` al servicio de cliente frontend para cada servicio cliente-servidor backend al que se conecten las tareas del cliente.

En segundo lugar, suponga que existe un servicio frontend sin la configuración de Service Connect. Las tareas se conectan a un servicio de backend existente. Agregue primero una configuración de Service Connect de cliente-servidor al servicio backend, con el mismo nombre en el **DNS** o el `clientAlias` que usa el frontend. Esto crea una nueva implementación, es decir, toda la detección de restauración de la implementación o la Consola de administración de AWS, la AWS CLI, los SDK de AWS y otros métodos para revertir y restaurar el servicio de backend a la implementación y la configuración anteriores. Si está satisfecho con el rendimiento y el comportamiento del servicio de backend, agregue una configuración de Service Connect de cliente o cliente-servidor al servicio frontend. Solo las tareas de la nueva implementación utilizan el proxy de Service Connect que se agrega a esas tareas nuevas. Si tiene problemas con esta configuración, puede revertir y volver a su configuración anterior mediante la detección de restauración de la implementación o la Consola de administración de AWS, la AWS CLI, los SDK de AWS y otros métodos para revertir y restaurar el servicio de backend a la implementación y la configuración anteriores. Si utiliza otro sistema de detección de servicios basado en DNS en lugar de Service Connect, cualquier aplicación frontend o de cliente empezará a utilizar nuevos puntos de conexión y una configuración de punto de conexión modificada una vez que caduque la caché de DNS local, lo que suele tardar varias horas.

## Red
<a name="service-connect-concepts-network"></a>

De manera predeterminada, el proxy de Service Connect escucha en `containerPort` desde la asignación de puertos de la definición de la tarea. Las reglas del grupo de seguridad deben permitir el tráfico entrante a este puerto desde las subredes en las que se ejecutarán los clientes.

Incluso si establece un número de puerto en la configuración del servicio de Service Connect, esto no cambia el puerto del servicio cliente-servidor que escucha el proxy de Service Connect. Al configurar este número de puerto, Amazon ECS cambia el puerto del punto de conexión al que se conectan los servicios del cliente, en el proxy de Service Connect dentro de esas tareas. El proxy del servicio de cliente se conecta al proxy del servicio cliente-servidor mediante el `containerPort`.

Si desea cambiar el puerto que escucha el proxy de Service Connect, cambie `ingressPortOverride` en la configuración de Service Connect del servicio cliente-servidor. Si cambia este número de puerto, debe permitir el tráfico entrante en este puerto que utiliza el tráfico hacia este servicio.

El tráfico que sus aplicaciones envían a los servicios de Amazon ECS configurados para Service Connect requiere que Amazon VPC y las subredes cuenten con reglas de tabla de enrutamiento y reglas de ACL de red que permitan los números de puerto `containerPort` y `ingressPortOverride` que está utilizando.

 Puede utilizar Service Connect para enviar tráfico entre las VPC. Los mismos requisitos para las reglas de la tabla de enrutamiento, las ACL de red y los grupos de seguridad se aplican a ambas VPC.

Por ejemplo, dos clústeres crean tareas en diferentes VPC. Un servicio de cada clúster está configurado para usar el mismo espacio de nombres. Las aplicaciones de estos dos servicios pueden resolver todos los puntos de conexión del espacio de nombres sin ninguna configuración de DNS de VPC. Sin embargo, los proxies no se pueden conectar a menos que el emparejamiento de VPC, las tablas de enrutamiento de subredes o VPC, y las ACL de red de VPC permitan el tráfico en los números de puerto `containerPort` y `ingressPortOverride`.

Para las tareas que utilizan el modo de red `bridge`, debe crear un grupo de seguridad con una regla de entrada que permita el tráfico en el rango superior de puertos dinámicos. A continuación, asigne el grupo de seguridad a todas las instancias EC2 del clúster de Service Connect.

## Proxy de Service Connect
<a name="service-connect-concepts-proxy"></a>

Si crea o actualiza un servicio con la configuración de Service Connect, Amazon ECS agrega un contenedor nuevo a cada tarea nueva a medida que se inicia. Este patrón de uso de un contenedor independiente se denomina `sidecar`. Este contenedor no está presente en la definición de la tarea y no puede configurarlo. Amazon ECS administra la configuración de este contenedor en el servicio. Esto le permite reutilizar las mismas definiciones de tareas entre varios servicios, espacios de nombres y tareas sin Service Connect.

**Recursos de proxy**
+ Para las definiciones de tareas, debe establecer los parámetros de la CPU y la memoria. 

  Recomendamos agregar 256 unidades de CPU adicionales y al menos 64 MiB de memoria a la memoria y la CPU de la tarea del contenedor del proxy de Service Connect. En AWS Fargate, la cantidad mínima de memoria que puede configurar es de 512 MiB. En Amazon EC2, es necesaria la memoria de definición de tareas.
+ Para el servicio, se establece la configuración del registro en la configuración de Service Connect.
+ Si espera que las tareas de este servicio reciban más de 500 solicitudes por segundo en su carga máxima, le recomendamos agregar 512 unidades de CPU a la CPU de tareas en esta definición de tareas para el contenedor del proxy de Service Connect.
+ Si espera crear más de 100 servicios de Service Connect en el espacio de nombres o 2000 tareas en total en todos los servicios de Amazon ECS dentro del espacio de nombres, le recomendamos agregar 128 MiB de memoria a la memoria de tareas para el contenedor del proxy de Service Connect. Debe hacerlo en todas las definiciones de tareas que utilicen todos los servicios de Amazon ECS del espacio de nombres.

**Configuración del proxy**  
Sus aplicaciones se conectan al proxy del contenedor sidecar en la misma tarea en la que se encuentra la aplicación. Amazon ECS configura la tarea y los contenedores para que las aplicaciones solo se conecten al proxy cuando la aplicación se conecta a los nombres de los puntos de conexión en el mismo espacio de nombres. El resto del tráfico no utiliza el proxy. El resto del tráfico incluye direcciones IP en la misma VPC, puntos de conexión de servicios de AWS y tráfico externo.

**Equilibrio de carga**  
Service Connect configura el proxy para que utilice la estrategia de distribución equilibrada para equilibrar la carga entre las tareas en un punto de conexión de Service Connect. El proxy local que se encuentra en la tarea desde la que proviene la conexión selecciona una de las tareas del servicio cliente-servidor que proporciona el punto de conexión.  
Por ejemplo, consideremos una tarea que ejecuta WordPress en un servicio configurado como *servicio de cliente* en un espacio de nombres llamado *local*. Hay otro servicio con 2 tareas que ejecuta la base de datos MySQL. Este servicio está configurado para proporcionar un punto de conexión llamado `mysql` a través de Service Connect en el mismo espacio de nombres. En la tarea de WordPress, la aplicación de WordPress se conecta a la base de datos mediante el nombre del punto de conexión. Las conexiones con este nombre van al proxy que se ejecuta en un contenedor asociado en la misma tarea. A continuación, el proxy puede conectarse a cualquiera de las tareas de MySQL mediante la estrategia de distribución equilibrada.  
Estrategias de equilibrio de carga: distribución equilibrada

**Detección de valores atípicos**  
Esta característica utiliza los datos que el proxy tiene sobre conexiones con errores anteriores para evitar enviar nuevas conexiones a los hosts que tenían las conexiones con errores. Service Connect configura la característica de detección de valores atípicos del proxy para proporcionar comprobaciones de estado pasivas.  
Con el ejemplo anterior, el proxy puede conectarse a cualquiera de las tareas de MySQL. Si el proxy realizó varias conexiones a una tarea de MySQL específica y 5 o más de las conexiones fallaron en los últimos 30 segundos, el proxy evita esa tarea de MySQL durante 30 a 300 segundos.

**Reintentos**  
Service Connect configura el proxy para volver a intentar la conexión que pasa por el proxy y falla, y el segundo intento evita usar el host de la conexión anterior. Esto garantiza que cada conexión a través de Service Connect no tenga errores por motivos puntuales.  
Número de reintentos: 2

**Tiempo de espera**  
Service Connect configura el proxy para que espere un tiempo máximo a que respondan las aplicaciones cliente-servidor. El valor de tiempo de espera predeterminado es de 15 segundos, pero se puede actualizar.  
Parámetros opcionales:  
**idleTimeout**: el tiempo en segundos que una conexión permanece activa mientras está inactiva. Un valor de `0` deshabilita `idleTimeout`.  
El `idleTimeout` predeterminado de `HTTP`/`HTTP2`/`GRPC` es 5 minutos.  
El `idleTimeout` predeterminado de `TCP` es una hora.  
**perRequestTimeout**: el tiempo que se tarda en esperar a que el remitente responda con una respuesta completa por solicitud. El valor `0` desactiva `perRequestTimeout`. Esto solo se puede configurar cuando `appProtocol` del contenedor de la aplicación es `HTTP`, `HTTP2` o `GRPC`. El valor predeterminado es de 15 segundos.  
Si `idleTimeout` se establece en un tiempo inferior a `perRequestTimeout`, la conexión se cerrará cuando `idleTimeout` se alcance y no el `perRequestTimeout`.

## Consideraciones
<a name="service-connect-considerations"></a>

Cuando utilice Service Connect, tenga en cuenta lo siguiente:
+ Las tareas que se ejecutan en Fargate deben utilizar la versión `1.4.0` o superior de la plataforma de Fargate Linux para utilizar Service Connect.
+ La versión del agente de Amazon ECS en la instancia de contenedor debe ser `1.67.2` o una superior.
+ Las instancias de contenedor deben ejecutar la versión AMI de Amazon Linux 2023 optimizada para Amazon ECS `20230428` o una posterior o la versión AMI de Amazon Linux 2 optimizada para Amazon ECS `2.0.20221115` para utilizar Service Connect. Estas versiones tienen el agente de Service Connect además del agente de contenedor de Amazon ECS. Para obtener más información sobre el agente de ECS, consulte [Agente de Service Connect de Amazon ECS](https://github.com/aws/amazon-ecs-service-connect-agent) en GitHub.
+ Las instancias de contenedor deben tener el permiso `ecs:Poll` para el recurso `arn:aws:ecs:region:0123456789012:task-set/cluster/*`. Si utiliza `ecsInstanceRole`, no es necesario que agregue permisos adicionales. La política administrada `AmazonEC2ContainerServiceforEC2Role` tiene los permisos necesarios. Para obtener más información, consulte [Rol de IAM de instancia de contenedor de Amazon ECS](instance_IAM_role.md).
+ Las tareas que usan el modo de red `bridge` y utilizan Service Connect no admiten el parámetro de definición de contenedor `hostname`.
+ Las definiciones de tareas deben establecer el límite de memoria de tareas para usar Service Connect. Para obtener más información, consulte [Proxy de Service Connect](#service-connect-concepts-proxy).
+ No se admiten las definiciones de tareas que establezcan límites de memoria de contenedores.

  Puede establecer límites de memoria de contenedores en sus contenedores, pero debe establecer el límite de memoria de tareas en un número mayor que la suma de los límites de memoria del contenedor. El contenedor del proxy de Service Connect y otros contenedores que no establecen límites de contenedores utilizan la CPU y la memoria adicionales de los límites de tareas que no están asignadas en los límites de contenedores. Para obtener más información, consulte [Proxy de Service Connect](#service-connect-concepts-proxy).
+ Puede configurar Service Connect para utilizar cualquier espacio de nombres de AWS Cloud Map de la misma región que esté en la misma Cuenta de AWS o se comparta con su Cuenta de AWS mediante AWS Resource Access Manager. 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).
+ Cada servicio puede pertenecer a un solo espacio de nombres.
+ Solo se admiten las tareas que crean los servicios. 
+ Todos los puntos de conexión deben ser únicos dentro de un espacio de nombres.
+ Todos los nombres de detección deben ser únicos dentro de un espacio de nombres.
+ Debe volver a implementar los servicios existentes para que las aplicaciones puedan resolver nuevos puntos de conexión. Los puntos de conexión nuevos que se agreguen al espacio de nombres después de la implementación más reciente no se agregarán a la configuración de la tarea. Para obtener más información, consulte [Componentes de Amazon ECS Service Connect](#service-connect-concepts-deploy).
+ Service Connect no elimina los espacios de nombres cuando se eliminan los clústeres. Debe eliminar los espacios de nombres en AWS Cloud Map.
+ El tráfico del Equilibrador de carga de aplicación se dirige de forma predeterminada a través del agente Service Connect en el modo de red `awsvpc`. Si desea que el tráfico no relacionado con el servicio omita el agente de Service Connect, utilice el parámetro `[ingressPortOverride](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectService.html)` en la configuración del servicio de Service Connect.
+ Service Connect con TLS no admite el modo de red `bridge`. Solo se admite el modo de red `awsvpc`.
+ En el modo `awsvpc`, el proxy de Service Connect reenvía el tráfico al host local de IPv4 `127.0.0.1` para los servicios en configuraciones de doble pila y solo IPv4. En el caso de los servicios en una configuración de solo IPv6, el proxy reenvía el tráfico al host local de IPv6 `::1`. Recomendamos configurar las aplicaciones para que escuchen ambos hosts locales para evitar problemas cuando un servicio se actualice de una configuración de solo IPv4 o de doble pila a una configuración de solo IPv6. Para obtener más información, consulte [Opciones de red de tareas de Amazon ECS para EC2](task-networking.md) y [Opciones de red de tareas de Amazon ECS para Fargate](fargate-task-networking.md).

**Service Connect no admite lo siguiente:**
+ Contenedores de Windows
+ HTTP 1.0
+ Tareas independientes
+ Servicios que utilizan los tipos de implementación azul/verde impulsada por CodeDeploy y la implementación externa
+ Service Connect no admite la instancia de contenedor `External` para Amazon ECS Anywhere.
+ PPv2
+ Modo FIPS

# Información general de la configuración de Amazon ECS Service Connect
<a name="service-connect-concepts"></a>

Cuando se utiliza Service Connect, hay parámetros que se deben configurar en los recursos. 

En la siguiente tabla se describen los parámetros de configuración de los recursos de Amazon ECS.


| Ubicación de parámetros | Tipo de aplicación | Descripción | Obligatorio | 
| --- | --- | --- | --- | 
| Definición de tarea | Cliente | No hay cambios disponibles para Service Connect en las definiciones de tareas del cliente. | N/A | 
| Definición de tarea | Cliente-servidor | Los servidores deben agregar campos name a los puertos en las portMappings de los contenedores. Para obtener más información, consulte [portMappings](task_definition_parameters.md#ContainerDefinition-portMappings) | Sí | 
| Definición de tarea | Cliente-servidor | De manera opcional, los servidores pueden proporcionar un protocolo de aplicación (por ejemplo, HTTP) para recibir métricas específicas del protocolo para sus aplicaciones de servidor (por ejemplo, HTTP 5xx). | No | 
| Definición de servicio | Cliente | Los servicios de cliente deben agregar una serviceConnectConfiguration para configurar el espacio de nombres al cual unirse. Este espacio de nombres debe contener todos los servicios de servidor que este servicio debe detectar. Para obtener más información, consulte [serviceConnectConfiguration](service_definition_parameters.md#Service-serviceConnectConfiguration). | Sí | 
| Definición de servicio | Cliente-servidor | Los servicios del servidor deben agregar una serviceConnectConfiguration para configurar los nombres DNS, los números de puerto y el espacio de nombres desde los que está disponible el servicio. Para obtener más información, consulte [serviceConnectConfiguration](service_definition_parameters.md#Service-serviceConnectConfiguration). | Sí | 
| Clúster | Cliente | Los clústeres pueden agregar un espacio de nombres de Service Connect predeterminado. Los nuevos servicios del clúster heredan el espacio de nombres cuando Service Connect se configura en un servicio.  | No | 
| Clúster | Cliente-servidor | No hay cambios disponibles para Service Connect en los clústeres que aplican a los servicios del servidor. Las definiciones y los servicios de las tareas del servidor deben establecer la configuración correspondiente. | N/A | 

**Descripción general de los pasos para configurar Service Connect**  
En los siguientes pasos se proporciona información general sobre cómo configurar Service Connect.

**importante**  
 Service Connect crea servicios de AWS Cloud Map en la cuenta. La modificación de estos recursos AWS Cloud Map mediante el registro o la anulación del registro manual de las instancias, el cambio de los atributos de la instancia o la eliminación de un servicio puede provocar un comportamiento inesperado en el tráfico de las aplicaciones o en las implementaciones posteriores.
 Service Connect no admite enlaces en la definición de la tarea.

1. Agregue los nombres de los puertos a las asignaciones de puertos en las definiciones de las tareas. Además, puede identificar el protocolo de capa 7 de la aplicación para obtener métricas adicionales.

1. Cree un clúster con un espacio de nombres de AWS Cloud Map, use un espacio de nombres compartido o cree el espacio de nombres por separado. Para una organización sencilla, cree un clúster con el nombre que desea para el espacio de nombres y especifique un nombre idéntico para el espacio de nombres. En este caso, Amazon ECS crea un nuevo espacio de nombres HTTP con la configuración necesaria. Service Connect no utiliza ni crea zonas alojadas de DNS en Amazon Route 53.

1. Configure los servicios para crear puntos de conexión de Service Connect dentro del espacio de nombres.

1. Implemente los servicios para crear los puntos de conexión. Amazon ECS agrega un contenedor del proxy de Service Connect a cada tarea y crea los puntos de conexión de Service Connect en AWS Cloud Map. Este contenedor no está configurado en la definición de la tarea y la definición de la tarea se puede reutilizar sin modificaciones para crear varios servicios en el mismo espacio de nombres o en varios espacios de nombres.

1. Implemente aplicaciones cliente como servicios para conectarse a los puntos de conexión. Amazon ECS los conecta a los puntos de conexión de Service Connect a través del proxy de Service Connect en cada tarea.

   Las aplicaciones solo utilizan el proxy para conectarse a los puntos de conexión de Service Connect. No hay ninguna configuración adicional para utilizar el proxy. El proxy realiza el equilibrio de cargas de distribución equilibrada, la detección de valores atípicos y los reintentos. Para obtener más información sobre el proxy, consulte [Proxy de Service Connect](service-connect-concepts-deploy.md#service-connect-concepts-proxy).

1. Monitoree el tráfico a través del proxy de Service Connect en Amazon CloudWatch.

## Configuración del clúster
<a name="service-connect-concepts-cluster-defaults"></a>

Puede establecer un espacio de nombres predeterminado para Service Connect cuando crea o actualiza el clúster. El nombre del espacio de nombres que especifique de forma predeterminada puede estar en la misma Región de AWS y en la misma cuenta o en la misma Región de AWS y compartida por otra Cuenta de AWS mediante AWS Resource Access Manager.

Si crea un clúster y especifica un espacio de nombres de Service Connect predeterminado, el clúster espera en estado `PROVISIONING` mientras Amazon ECS crea el espacio de nombres. Puede ver una `attachment` en el estado del clúster que muestra el estado del espacio de nombres. Las conexiones no se muestran de forma predeterminada en la AWS CLI, debe agregar `--include ATTACHMENTS` para verlos.

Si desea utilizar un espacio de nombres compartido con su Cuenta de AWS mediante AWS RAM, especifique el nombre de recurso de Amazon (ARN) del espacio de nombres en la configuración del clúster. Para obtener más información acerca de los espacios de nombres de AWS Cloud Map compartidos, consulte [Amazon ECS Service Connect con espacios de nombres de AWS Cloud Map compartidos](service-connect-shared-namespaces.md).

## Configuración del servicio
<a name="service-connect-concepts-config"></a>

Service Connect está diseñado para requerir la configuración mínima. Debe establecer un nombre para cada asignación de puertos que desee utilizar con Service Connect en la definición de la tarea. En el servicio, debe activar Service Connect y seleccionar un espacio de nombres de su Cuenta de AWS o un espacio de nombres compartido para crear un servicio de cliente. Para crear un servicio cliente-servidor, debe agregar una configuración del servicio Service Connect única que coincida con el nombre de una de las asignaciones de puertos. Amazon ECS reutiliza el número de puerto y el nombre del puerto de la definición de la tarea para definir el servicio y el punto de conexión de Service Connect. Para anular esos valores, puede utilizar los demás parámetros **Detección**, **DNS** y **Puerto** en la consola o `discoveryName` y `clientAliases`, respectivamente, en la API de Amazon ECS.

## Configuración de la comprobación de estado inicial
<a name="service-connect-concepts-health-check"></a>

Service Connect se asegura de que las tareas estén en buen estado antes de enrutar el tráfico hacia ellas. Cuando se inicializa una tarea (durante las implementaciones, el escalado o las sustituciones), Service Connect supervisa el estado de la tarea para asegurarse de que esté lista para aceptar el tráfico. Debe definir comprobaciones de estado para el contenedor esencial en la definición de la tarea a fin de habilitar este comportamiento.

El comportamiento de la comprobación de estado inicial tiene en cuenta los posibles retrasos a la hora de alcanzar el estado en el que una tarea está lista para aceptar tráfico:
+ Si una tarea tiene el estado `HEALTHY`, significa que está inmediatamente disponible para el tráfico.
+ Si el estado de una tarea es `UNKNOWN`, Service Connect sigue la configuración de la comprobación de estado del contenedor (consulte [Comprobación de estado](task_definition_parameters.md#container_definition_healthcheck)) de los contenedores esenciales de la tarea para calcular el tiempo de espera, hasta `8 minutes`, antes de ponerlo a disposición del tráfico, incluso si permanece en el estado `UNKNOWN`.
+ Si una tarea es `UNHEALTHY`, Amazon ECS puede iniciar tareas de reemplazo. Si no hay ninguna tarea en buen estado disponible, la implementación podría revertirse en función de la configuración del servicio.

Para todo el tráfico continuo, Service Connect utiliza comprobaciones de estado pasivas basadas en la detección de valores atípicos para enrutar el tráfico de manera eficiente.

# Amazon ECS Service Connect con espacios de nombres de AWS Cloud Map compartidos
<a name="service-connect-shared-namespaces"></a>

Amazon ECS Service Connect admite el uso de espacios de nombres de AWS Cloud Map compartidos entre varias Cuentas de AWS dentro de la misma Región de AWS. Esta capacidad le permite crear aplicaciones distribuidas en las que los servicios que se ponen en marcha en diferentes Cuentas de AWS pueden detectarse y comunicarse entre sí a través de Service Connect. Los espacios de nombres compartidos se administran mediante AWS Resource Access Manager (AWS RAM), lo que permite compartir recursos entre cuentas de forma segura. Para obtener más información sobre los espacios de nombres compartidos, consulte [Cross-account AWS Cloud Map namespace sharing](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) en la *Guía para desarrolladores de AWS Cloud Map*.

**importante**  
Debe usar el permiso administrado `AWSRAMPermissionCloudMapECSFullPermission` para compartir el espacio de nombres para que Service Connect funcione correctamente con el espacio de nombres.

Cuando usa espacios de nombres de AWS Cloud Map compartidos con Service Connect, los servicios de varias Cuentas de AWS pueden participar en el mismo espacio de nombres del servicio. Esto resulta especialmente útil para las organizaciones con varias Cuentas de AWS que tienen que mantener la comunicación entre servicios a través de los límites de las cuentas y, al mismo tiempo, preservar la seguridad y el aislamiento.

**nota**  
Para comunicarse con los servicios que se encuentran en diferentes VPC, deberá configurar la conectividad entre VPC. Esto se puede lograr mediante una conexión de emparejamiento de VPC. Para obtener más información, consulte [Creación o eliminación de una interconexión de VPC](https://docs.aws.amazon.com/vpc/latest/peering/create-vpc-peering-connection.html) en la *Guía de emparejamiento de VPC de Amazon Virtual Private Cloud*.

# Uso de espacios de nombres de AWS Cloud Map compartidos con Amazon ECS Service Connect
<a name="service-connect-shared-namespaces-setup"></a>

La configuración de los AWS Cloud Map espacios de nombres compartidos para Service Connect implica los siguientes pasos: el propietario del espacio de nombres crea el espacio de nombres, el propietario lo comparte mediante AWS Resource Access Manager (AWS RAM), el consumidor acepta el recurso compartido y el consumidor configura Service Connect para usar el espacio de nombres compartido.

## Paso 1: Creación del espacio de nombres de AWS Cloud Map
<a name="service-connect-shared-namespaces-create"></a>

El propietario del espacio de nombres crea un espacio de nombres de AWS Cloud Map que se compartirá con otras cuentas.

**Creación de un espacio de nombres para compartirlo mediante Consola de administración de AWS**

1. Abra la consola de AWS Cloud Map en [https://console.aws.amazon.com/cloudmap/](https://console.aws.amazon.com/cloudmap/).

1. Elija **Crear espacio de nombres**.

1. Introduzca un nombre en **Nombre del espacio de nombres**. Los servicios de todas las cuentas participantes utilizarán este nombre.

1. En **Tipo de espacio de nombres**, elija el tipo adecuado para su caso de uso:
   + **Llamadas a la API**: espacios de nombres HTTP para la detección de servicios sin funcionalidad de DNS.
   + **Llamadas a la API y consultas de DNS en las VPC**: espacios de nombres de DNS privados para la detección de servicios con consultas de DNS privadas en una VPC.
   + **Llamadas a la API y consultas de DNS públicas**: espacios de nombres de DNS públicos para la detección de servicios con consultas de DNS públicas.

1.  Elija **Crear espacio de nombres**.

## Paso 2: Uso compartido del espacio de nombres con AWS RAM
<a name="service-connect-shared-namespaces-share"></a>

El propietario del espacio de nombres utiliza AWS RAM para compartir el espacio de nombres con otras Cuentas de AWS.

**Uso compartido de un espacio de nombres mediante la consola de AWS RAM**

1. Abra la consola de AWS RAM en [https://console.aws.amazon.com/ram/](https://console.aws.amazon.com/ram/).

1. Elija **Crear recurso compartido**.

1. En **Nombre**, introduzca un nombre descriptivo para el recurso compartido.

1. En la sección **Recursos**:

   1. En **Tipo de recurso**, seleccione **Espacios de nombres de Cloud Map**.

   1. Seleccione el espacio de nombres que creó en el paso anterior.

1. En la sección **Permisos administrados**, especifique **AWSRAMPermissionCloudMapECSFullPermission**.
**importante**  
Debe usar el permiso administrado `AWSRAMPermissionCloudMapECSFullPermission` para compartir el espacio de nombres para que Service Connect funcione correctamente con el espacio de nombres.

1. En la sección **Entidades principales**, especifique las Cuentas de AWS con las que desea compartir el espacio de nombres. Puede introducir ID de cuenta o ID de unidad organizativa.

1. Elija **Crear recurso compartido**.

## Paso 3: Aceptación del recurso compartido
<a name="service-connect-shared-namespaces-accept"></a>

Las cuentas de consumidor del espacio de nombres deben aceptar la invitación del recurso compartido para usar el espacio de nombres compartido.

**Aceptación de la invitación del recurso compartido mediante la consola de AWS RAM**

1. En la cuenta de consumidor, abra la consola de AWS RAM en [https://console.aws.amazon.com/ram/](https://console.aws.amazon.com/ram/).

1. En el panel de navegación, elija **Compartidos conmigo** y, a continuación, seleccione **Recursos compartidos**.

1. Seleccione la invitación del recurso compartido y elija **Aceptar el recurso compartido**.

1. Tras aceptar, anote el ARN del espacio de nombres compartido que se indica en los detalles del recurso. Utilizará este ARN al configurar los servicios de Service Connect.

## Paso 4: Configuración de un servicio de Amazon ECS con el espacio de nombres compartido
<a name="service-connect-shared-namespaces-configure"></a>

Tras aceptar el espacio de nombres compartido, el consumidor del espacio de nombres puede configurar los servicios de Amazon ECS para que usen el espacio de nombres compartido. La configuración es similar a usar un espacio de nombres normal, pero debe especificar el ARN del espacio de nombres en lugar del nombre. Para ver un procedimiento detallado de creación de servicios, consulte [Creación de una implementación de actualización continua de Amazon ECS](create-service-console-v2.md).

**Creación de un servicio con un espacio de nombres compartido mediante la 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 página **Clústeres**, seleccione el clúster en el que desea crear el servicio.

1. En **Servicios**, seleccione **Crear**.

1. Tras rellenar otros detalles en función de la carga de trabajo, en la sección **Service Connect**, seleccione **Usar Service Connect**.

1. En **Espacio de nombres**, introduzca el ARN completo del espacio de nombres compartido.

   El formato del ARN es: `arn:aws:servicediscovery:region:account-id:namespace/namespace-id`

1. Configure el resto de los ajustes de Service Connect según sea necesario para su tipo de servicio (cliente o cliente-servidor).

1. Complete el proceso de creación del servicio.

También puede configurar los servicios mediante la AWS CLI o los SDK de AWSespecificando el ARN del espacio de nombres compartido en el parámetro `namespace` de `serviceConnectConfiguration`.

```
aws ecs create-service \
    --cluster my-cluster \
    --service-name my-service \
    --task-definition my-task-def \
    --service-connect-configuration '{
        "enabled": true,
        "namespace": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-abcdef1234567890",
        "services": [{
            "portName": "web",
            "discoveryName": "my-service",
            "clientAliases": [{
                "port": 80,
                "dnsName": "my-service"
            }]
        }]
    }'
```

## Consideraciones
<a name="service-connect-shared-namespaces-considerations"></a>

Cuando utilice espacios de nombres de AWS Cloud Map compartidos con Service Connect, tenga en cuenta lo siguiente:
+ AWS RAM debe estar disponible en la Región de AWS en la que desee utilizar el espacio de nombres compartido.
+ El espacio de nombres compartido debe estar en la misma Región de AWS que los servicios y clústeres de Amazon ECS.
+ Debe usar el ARN del espacio de nombres, no el ID, al configurar Service Connect con un espacio de nombres compartido.
+ Se admiten todos los tipos de espacios de nombres: HTTP, DNS privado y DNS público.
+ Si se revoca el acceso a un espacio de nombres compartido, se producirá un error en las operaciones de Amazon ECS que necesiten la interacción con el espacio de nombres (como `CreateService`, `UpdateService` y `ListServicesByNamespace`) fallarán. Para obtener más información sobre cómo solucionar problemas relacionados con los permisos con espacios de nombres compartidos, consulte [Solución de problemas de Amazon ECS Service Connect con espacios de nombres de AWS Cloud Map compartidos](service-connect-shared-namespaces-troubleshooting.md).
+ Para la detección de servicios mediante consultas de DNS en un espacio de nombres de DNS privado compartido, siga estos pasos:
  + El propietario del espacio de nombres tendrá que llamar a `create-vpc-association-authorization` con el ID de la zona alojada privada asociada al espacio de nombres y la VPC del consumidor.

    ```
    aws route53 create-vpc-association-authorization --hosted-zone-id Z1234567890ABC --vpc VPCRegion=us-east-1,VPCId=vpc-12345678
    ```
  + El consumidor del espacio de nombres tendrá que llamar a `associate-vpc-with-hosted-zone` con el ID de la zona alojada privada.

    ```
    aws route53 associate-vpc-with-hosted-zone --hosted-zone-id Z1234567890ABC --vpc VPCRegion=us-east-1,VPCId=vpc-12345678
    ```
+ Solo el propietario del espacio de nombres puede administrar el recurso compartido.
+ Los consumidores del espacio de nombres pueden crear y administrar servicios dentro del espacio de nombres compartido, pero no pueden modificar el espacio de nombres en sí.
+ Los nombres de detección deben ser únicos dentro del espacio de nombres compartido, independientemente de la cuenta que cree el servicio.
+ Los servicios del espacio de nombres compartido pueden detectar servicios de otras cuentas de AWS que tengan acceso al espacio de nombres y conectarse a ellos.
+ Al habilitar TLS para Service Connect y usar un espacio de nombres compartido, la autoridad de certificación (CA) de AWS Private CA se limita al espacio de nombres. Cuando se revoca el acceso al espacio de nombres compartido, se detiene el acceso a la CA.
+ Al trabajar con un espacio de nombres compartido, los propietarios y los consumidores del espacio de nombres no tienen acceso a las métricas de varias cuentas de Amazon CloudWatch de forma predeterminada. Las métricas de destino solo se publican para las cuentas que tienen servicios cliente. Las cuenta que son propietarias de servicios cliente no tienen acceso a las métricas que reciben las cuenta que son propietarias de servicios cliente-servidor, y viceversa. Para permitir el acceso entre cuentas a las métricas, configure la observabilidad entre cuentas de CloudWatch. Para obtener más información sobre cómo configurar la observabilidad entre cuentas, consulte [Observabilidad entre cuentas de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html) en la *Guía del usuario de Amazon CloudWatch*. Para obtener más información acerca de las métricas de CloudWatch para Service Connect, consulte [Métricas de CloudWatch de Amazon ECS](available-metrics.md).

# Solución de problemas de Amazon ECS Service Connect con espacios de nombres de AWS Cloud Map compartidos
<a name="service-connect-shared-namespaces-troubleshooting"></a>

Utilice la siguiente información para solucionar problemas con los espacios de nombres de AWS Cloud Map compartidos y Service Connect. Para obtener más información sobre la localización de los mensajes de error, consulte [Solución de problemas de Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshooting.html).

Los mensajes de error relacionados con problemas de permisos aparecen porque faltan permisos o si se ha revocado el acceso al espacio de nombres. 

**importante**  
Debe usar el permiso administrado `AWSRAMPermissionCloudMapECSFullPermission` para compartir el espacio de nombres para que Service Connect funcione correctamente con el espacio de nombres.

El mensaje de error aparece en uno de los siguientes formatos:

Se produjo un error (ClientException) al llamar a la operación <OperationName>: el usuario: arn:aws:iam::<account-id>:user/<user-name> no está autorizado para realizar: <ActionName> en el recurso: <ResourceArn> porque no hay ninguna política basada en recursos que permita la acción <ActionName>

Los escenarios siguientes pueden dar lugar a un mensaje de error en este formato:

**Error al crear o actualizar el clúster**  
Estos problemas se produce cuando surge un error en operaciones de Amazon ECS como `CreateCluster` o `UpdateCluster` debido a la falta de permisos de AWS Cloud Map. Las operaciones necesitan permisos para las siguientes acciones de AWS Cloud Map:  
+ `servicediscovery:GetNamespace`
Asegúrese de que la invitación del recurso compartido se haya aceptado en la cuenta del consumidor y de que en la configuración de Service Connect se utilice el ARN del espacio de nombres correcto.

**Error al crear o actualizar el servicio**  
Estos problemas se produce cuando surge un error en operaciones de Amazon ECS como `CreateService` o `UpdateService` debido a la falta de permisos de AWS Cloud Map. Las operaciones necesitan permisos para las siguientes acciones de AWS Cloud Map:  
+ `servicediscovery:CreateService`
+ `servicediscovery:GetNamespace`
+ `servicediscovery:GetOperation` (para crear un nuevo servicio de AWS Cloud Map)
+ `servicediscovery:GetService` (para cuando ya existe un servicio de AWS Cloud Map)
Asegúrese de que la invitación del recurso compartido se haya aceptado en la cuenta del consumidor y de que en la configuración de Service Connect se utilice el ARN del espacio de nombres correcto.

**`ListServicesByNamespace` Error en la operación**  
Este problema surge cuando se produce un error en la operación `ListServicesByNamespace` de Amazon ECS. La operación necesita permisos para las siguientes acciones de AWS Cloud Map:  
+ `servicediscovery:GetNamespace`
Para resolver este problema, siga estos pasos:  
+ Compruebe que la cuenta del consumidor tenga el permiso `servicediscovery:GetNamespace`.
+ Use el ARN del espacio de nombres al llamar a la API, no el nombre.
+ Asegúrese de que el recurso compartido esté activo y de que se haya aceptado la invitación.

El usuario: <iam-user> no está autorizado para realizar: <ActionName> en el recurso: <ResourceArn> con una denegación explícita en una política basada en la identidad.

Los escenarios siguientes pueden dar lugar a un mensaje de error en este formato:

**Se produce un error al eliminar el servicio y se queda bloqueado en el estado `DRAINING`**  
Este problema surge cuando se produce un error en las operaciones `DeleteService` de Amazon ECS debido a la falta del permiso `servicediscovery:DeleteService` cuando se revoca el acceso al espacio de nombres. Al principio puede parecer que el servicio se ha eliminado correctamente, pero se quedará bloqueado en el estado `DRAINING`. El mensaje de error aparece como un evento del servicio de Amazon ECS.  
Para resolver este problema, el propietario del espacio de nombres debe compartir el espacio de nombres con la cuenta del consumidor para permitir que se complete la eliminación del servicio.

**Las tareas del servicio no se pueden poner en marcha**  
Este problema se produce cuando las tareas no se inician debido a la falta de permisos. El mensaje de error aparece como un error de tarea detenida. Para obtener más información, consulte [Solución de los errores de las tareas detenidas de Amazon ECS](resolve-stopped-errors.md).  
Se necesitan las siguientes acciones de AWS Cloud Map para poner en marcha una tarea:  
+ `servicediscovery:GetOperation`
+ `servicediscovery:RegisterInstance`
Asegúrese de que la cuenta del consumidor tenga los permisos necesarios y de que se pueda acceder al espacio de nombres compartido.

**Las tareas no se detienen correctamente o se quedan bloqueadas en el estado `DEACTIVATING` o `DEPROVISIONING`**  
Este problema se produce cuando no se puede anular el registro de las tareas del servicio de AWS Cloud Map durante el cierre debido a la falta de permisos. El error aparece como `statusReason` en el adjunto de la tarea que se puede recuperar mediante la API `DescribeTasks`. Para obtener más información, consulte [DescribeTasks](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DescribeTasks.html) en la *Referencia de la API de Amazon Elastic Container Service*.  
Se necesitan las siguientes acciones de AWS Cloud Map para detener una tarea:  
+ `servicediscovery:DeregisterInstance`
+ `servicediscovery:GetOperation`
Si se revoca el acceso al espacio de nombres compartido, las tareas pueden permanecer en un estado `DEACTIVATING` o `DEPROVISIONING` hasta que se restablezca el acceso al espacio de nombres. Solicite al propietario del espacio de nombres que restablezca el acceso al espacio de nombres.

# Registros de acceso de Amazon ECS Service Connect
<a name="service-connect-envoy-access-logs"></a>

Amazon ECS Service Connect es compatible con los registros de acceso para proporcionar telemetría detallada sobre las solicitudes individuales procesadas por el proxy de Service Connect. Los registros de acceso complementan los registros de aplicaciones existentes al capturar metadatos de tráfico por solicitud, como los métodos HTTP, las rutas, los códigos de respuesta, los indicadores y la información de temporización. Esto brinda una observabilidad más detallada de los patrones de tráfico a nivel de las solicitudes y las interacciones de los servicios para una resolución de problemas y una supervisión eficaces.

Para habilitar los registros de acceso, especifique los objetos `logConfiguration` y `accessLogConfiguration` del objeto `serviceConnectConfiguration`. Puede configurar el formato de los registros y si los registros deben incluir parámetros de consulta en `accessLogConfiguration`. El controlador de registro especificado en `logConfiguration` entrega los registros al grupo de registro de destino.

```
{
    "serviceConnectConfiguration": {
        "enabled": true,
        "namespace": "myapp.namespace",
        "services": [
            ...
        ],
        "logConfiguration": {
            "logDriver": "awslogs",
            "options": {
                "awslogs-group": "my-envoy-log-group",
                "awslogs-region": "us-west-2",
                "awslogs-stream-prefix": "myapp-envoy-logs"
            }
        },
         "accessLogConfiguration": {
            "format": "TEXT",
            "includeQueryParameters": "ENABLED" 
        }
    }
}
```

## Consideraciones
<a name="service-connect-envoy-access-logs-considerations"></a>

Tenga en cuenta lo siguiente cuando habilite el acceso a los registros de acceso:
+ Tanto los registros de acceso como los registros de aplicación se escriben en `/dev/stdout`. Para separar los registros de acceso de los registros de aplicación, se recomienda utilizar el controlador de registro `awsfirelens` con una configuración Fluent Bit o Fluentd personalizada.
+  Se recomienda utilizar el controlador de registro `awslogs` para enviar los registros de aplicación y de acceso al mismo destino de CloudWatch.
+ Los registros de acceso son compatibles con los servicios de Fargate que utilizan la versión `1.4.0` y posteriores de la plataforma.
+ De forma predeterminada, los parámetros de consulta, como los ID de solicitud y los tokens, no se incluyen en los registros de acceso. Para incluir los parámetros de consulta en los registros de acceso, establezca `includeQueryParameters` en `"ENABLED"`.

## Formatos de los registro de acceso
<a name="service-connect-envoy-access-logs-formats"></a>

Los registros de acceso se pueden formatear en diccionarios en formato JSON o en cadenas de formato de texto, con diferencias en los operadores de comandos compatibles para los distintos tipos de registros de acceso.

### Registros de acceso HTTP
<a name="service-connect-envoy-access-logs-formats-http"></a>

Los siguientes operadores de comandos se incluyen de forma predeterminada en los registros HTTP:

------
#### [ Text ]

```
[%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%"
%RESPONSE_CODE% %BYTES_RECEIVED% %BYTES_SENT% %DURATION%
%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% "%REQ(X-FORWARDED-FOR)%" "%REQ(USER-AGENT)%"
"%REQ(X-REQUEST-ID)%" "%REQ(:AUTHORITY)%" "%UPSTREAM_HOST%"\n
```

------
#### [ JSON ]

```
{
  "start_time": "%START_TIME%",
  "method": "%REQ(:METHOD)%",
  "path": "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%",
  "protocol": "%PROTOCOL%",
  "response_code": "%RESPONSE_CODE%",
  "bytes_received": "%BYTES_RECEIVED%",
  "bytes_sent": "%BYTES_SENT%",
  "duration_ms": "%DURATION%",
  "upstream_service_time": "%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%",
  "forwarded_for": "%REQ(X-FORWARDED-FOR)%",
  "user_agent": "%REQ(USER-AGENT)%",
  "request_id": "%REQ(X-REQUEST-ID)%",
  "authority": "%REQ(:AUTHORITY)%",
  "upstream_host": "%UPSTREAM_HOST%"
}
```

------

### Registros de acceso HTTP2
<a name="service-connect-envoy-access-logs-formats-http2"></a>

Además de los operadores de comandos incluidos en los registros HTTP, los registros HTTP2 incluyen el operador `%STREAM_ID%` de forma predeterminada.

------
#### [ Text ]

```
[%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%"
%RESPONSE_CODE% %BYTES_RECEIVED% %BYTES_SENT% %DURATION%
%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% "%REQ(X-FORWARDED-FOR)%" "%REQ(USER-AGENT)%"
"%REQ(X-REQUEST-ID)%" "%REQ(:AUTHORITY)%" "%UPSTREAM_HOST%" "%STREAM_ID%"\n
```

------
#### [ JSON ]

```
{
  "start_time": "%START_TIME%",
  "method": "%REQ(:METHOD)%",
  "path": "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%",
  "protocol": "%PROTOCOL%",
  "response_code": "%RESPONSE_CODE%",
  "bytes_received": "%BYTES_RECEIVED%",
  "bytes_sent": "%BYTES_SENT%",
  "duration": "%DURATION%",
  "upstream_service_time": "%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%",
  "forwarded_for": "%REQ(X-FORWARDED-FOR)%",
  "user_agent": "%REQ(USER-AGENT)%",
  "request_id": "%REQ(X-REQUEST-ID)%",
  "authority": "%REQ(:AUTHORITY)%",
  "upstream_host": "%UPSTREAM_HOST%",
  "stream_id": "%STREAM_ID%"
}
```

------

### Registros de acceso gRPC
<a name="service-connect-envoy-access-logs-formats-grpc"></a>

Además de los operadores de comandos incluidos en los registros HTTP, los registros de acceso gRPC incluyen los operadores `%STREAM_ID%` y `%GRPC_STATUS()%` de forma predeterminada.

------
#### [ Text ]

```
[%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%"
%RESPONSE_CODE% %GRPC_STATUS()% %BYTES_RECEIVED% %BYTES_SENT% %DURATION%
%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% "%REQ(X-FORWARDED-FOR)%" "%REQ(USER-AGENT)%"
"%REQ(X-REQUEST-ID)%" "%REQ(:AUTHORITY)%" "%UPSTREAM_HOST%" "%STREAM_ID%"\n
```

------
#### [ JSON ]

```
{
  "start_time": "%START_TIME%",
  "method": "%REQ(:METHOD)%",
  "path": "%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%",
  "protocol": "%PROTOCOL%",
  "response_code": "%RESPONSE_CODE%",
  "grpc_status": "%GRPC_STATUS()%",
  "bytes_received": "%BYTES_RECEIVED%",
  "bytes_sent": "%BYTES_SENT%",
  "duration": "%DURATION%",
  "upstream_service_time": "%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%",
  "forwarded_for": "%REQ(X-FORWARDED-FOR)%",
  "user_agent": "%REQ(USER-AGENT)%",
  "request_id": "%REQ(X-REQUEST-ID)%",
  "authority": "%REQ(:AUTHORITY)%",
  "upstream_host": "%UPSTREAM_HOST%",
  "stream_id": "%STREAM_ID%"
}
```

------

### Registros de acceso TCP
<a name="service-connect-envoy-access-logs-formats-tcp"></a>

Los siguientes operadores de comandos se incluyen de forma predeterminada en los registros de acceso TCP:

------
#### [ Text ]

```
[%START_TIME%] %DOWNSTREAM_REMOTE_ADDRESS% %DOWNSTREAM_REMOTE_PORT% 
%BYTES_RECEIVED% %BYTES_SENT% %DURATION%  
%CONNECTION_TERMINATION_DETAILS% %CONNECTION_ID%\n
```

------
#### [ JSON ]

```
{
  "start_time": "%START_TIME%",
  "downstream_remote_address": "%DOWNSTREAM_REMOTE_ADDRESS%",
  "downstream_remote_port": "%DOWNSTREAM_REMOTE_PORT%",s
  "bytes_received": "%BYTES_RECEIVED%",
  "bytes_sent": "%BYTES_SENT%",
  "duration": "%DURATION%",
  "connection_termination_details": "%CONNECTION_TERMINATION_DETAILS%",
  "connection_id": %CONNECTION_ID%
}
```

------

Para obtener más información acerca de estos operadores de comandos, consulte [Command Operators](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage#command-operators) en la documentación de Envoy.

# Habilitación de registros de acceso para Amazon ECS Service Connect
<a name="service-connect-access-logs-configuration"></a>

Los registros de acceso no están habilitados de forma predeterminada para los servicios de Amazon ECS que utilizan Service Connect. Puede habilitar los registros de acceso de las siguientes formas.

## Habilitación de registros de acceso mediante la AWS CLI
<a name="service-connect-access-logs-configure-cli"></a>

El siguiente comando muestra cómo puede habilitar los registros de acceso para un servicio de Amazon ECS mediante la AWS CLI especificando `accessLogConfiguration` al crear el servicio:

```
aws ecs create-service \
    --cluster my-cluster \
    --service-name my-service \
    --task-definition my-task-def \
    --service-connect-configuration '{
        "enabled": true,
        "namespace": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-abcdef1234567890",
        "services": [{
            "portName": "web",
            "discoveryName": "my-service",
            "clientAliases": [{
                "port": 80,
                "dnsName": "my-service"
            }]
        }],
        "logConfiguration": {
            "logDriver": "awslogs",
            "options": {
                "awslogs-group": "my-envoy-log-group",
                "awslogs-region": "us-west-2",
                "awslogs-stream-prefix": "myapp-envoy-logs"
            }
        },
         "accessLogConfiguration": {
            "format": "TEXT",
            "includeQueryParameters": "ENABLED" 
        }
    }'
```

## Habilitación de registro de acceso desde la consola
<a name="service-connect-access-logs-configure-console"></a>

Para ver un procedimiento detallado de creación de servicios, consulte [Creación de una implementación de actualización continua de Amazon ECS](create-service-console-v2.md).

**Creación de un servicio con un espacio de nombres compartido mediante la 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 página **Clústeres**, seleccione el clúster en el que desea crear el servicio.

1. En **Servicios**, seleccione **Crear**.

1. Tras rellenar otros detalles en función de la carga de trabajo, en la sección **Service Connect**, seleccione **Usar Service Connect**.

1. Configure los ajustes de Service Connect según sea necesario para su tipo de servicio (cliente o cliente-servidor).

1. Amplíe **Configuración del registro de acceso**. En **Formato**, elija **JSON** o `TEXT`.

1. Para incluir los parámetros de consulta en los registros de acceso, seleccione **Incluir parámetros de consulta**.

1. Complete el proceso de creación del servicio.

# Cifrado del tráfico de Amazon ECS Service Connect
<a name="service-connect-tls"></a>

Amazon ECS Service Connect admite el cifrado automático del tráfico con certificados de seguridad de la capa de transporte (TLS) para los servicios de Amazon ECS. Cuando dirige sus servicios de Amazon ECS hacia un [AWS Private Certificate Authority(AWS Private CA)](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html), Amazon ECS aprovisiona automáticamente certificados TLS para cifrar el tráfico entre sus servicios de Amazon ECS Service Connect. Amazon ECS genera, rota y distribuye los certificados TLS que se utilizan para el cifrado del tráfico.

El cifrado automático del tráfico con Service Connect utiliza funcionalidades de cifrado líderes del sector para proteger la comunicación entre servicios, lo que ayuda a cumplir sus requisitos de seguridad. Es compatible con los certificados TLS AWS Private Certificate Authority con el cifrado `256-bit ECDSA` y `2048-bit RSA`. También tiene el control total sobre los certificados privados y las claves de firma para ayudarle a cumplir los requisitos de conformidad. De forma predeterminada, se admite TLS 1.3, pero no se admite TLS 1.0 - 1.2. Service Connect admite TLS 1.3 con los siguientes cifrados:
+ `TLS_AES_128_GCM_SHA256`
+ `TLS_AES_256_GCM_SHA384`
+ `TLS_CHACHA20_POLY1305_SHA256`

**nota**  
Para poder utilizar TLS 1.3, debe habilitarlo en el oyente del destino.  
Solo se cifra el tráfico entrante y saliente que pasa por el agente de Amazon ECS.

## Service Connect y comprobación del estado del equilibrador de carga de aplicación
<a name="service-connect-tls-alb-healthchecks"></a>

Puede usar Service Connect con las comprobaciones de estado del equilibrador de carga de aplicación y el cifrado TLS 1.3. 

### Configuración del equilibrador de carga de aplicación
<a name="service-connect-tls-alb-config"></a>

Configure el equilibrador de carga de aplicación con la siguiente configuración:
+ Configure un oyente TLS con una política de seguridad TLS 1.3 (como `ELBSecurityPolicy-TLS13-1-2-2021-06`). Para obtener más información, consulte [Políticas de seguridad para el Equilibrador de carga de aplicación](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/describe-ssl-policies.html). 
+ Cree un grupo de destinos con la siguiente configuración:
  + Establezca el protocolo en HTTPS
  + Adjunte el grupo de destinos al oyente de TLS
  + Configure el puerto de comprobación de estado para que coincida con el puerto del contenedor del servicio Service Connect

### Configuración de Service Connect
<a name="service-connect-tls-sc-config"></a>

Configure un servicio con la siguiente configuración:
+ Configure el servicio para que utilice el modo de red `awsvpc`, ya que el modo de red `bridge` no es compatible.
+ Habilite Service Connect para el servicio.
+ Establezca la configuración del equilibrador de carga con los siguientes ajustes:
  + Especifique el grupo de destino que configuró para el rquilibrador de carga de aplicación
  + Configure el puerto del contenedor para que coincida con el puerto del contenedor del servicio TLS de Service Connect
+ Evite configurar `ingressPortOverride` para el servicio. Para obtener más información, consulte [ServiceConnectService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceConnectService.html) en la *Referencia de la API de Amazon Elastic Container Service*.

### Consideraciones
<a name="service-connect-tls-alb-considerations"></a>

Cuando utilice el equilibrador de carga de aplicación, TLS y Service Connect, tenga en cuenta lo siguiente:
+ Utilice el modo de red `awsvpc` en lugar del modo de red `bridge` para las comprobaciones de estado de HTTPS cuando utilice Service Connect con cifrado TLS. Las comprobaciones de estado de HTTP seguirán funcionando con el modo `bridge`.
+ Configure el puerto de comprobación de estado del grupo de destino para que coincida con el puerto del contenedor del servicio Service Connect, no con el puerto HTTPS predeterminado (443).

## Certificados AWS Private Certificate Authority y Service Connect
<a name="service-connect-tls-certificates"></a>

Debe tener el rol de IAM de infraestructura. Para obtener más información sobre este rol, consulte [Rol de IAM para la infraestructura de Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/infrastructure_IAM_role.html                     ).

**Modos de AWS Private Certificate Authority de Service Connect**

AWS Private Certificate Authority puede funcionar en dos modos: de uso general y de corta duración.
+ Uso general: certifica que se pueden configurar con cualquier fecha de caducidad.
+ De corta duración: emite certificados con un periodo de validez máximo de siete días.

Si bien Amazon ECS admite ambos modos, recomendamos utilizar certificados de corta duración. De forma predeterminada, los certificados se renuevan cada cinco días y, si se ejecutan en el modo de corta duración, se obtienen importantes ahorros de costos en comparación con el uso general.

Service Connect no admite la revocación de certificados, pero aprovecha los certificados de corta duración con una rotación frecuente de certificados. Tiene la autoridad para modificar la frecuencia de rotación, deshabilitar o eliminar los secretos mediante la [rotación administrada](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets_managed.html) en [Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html), pero hacerlo podría acarrear las siguientes consecuencias.
+ Frecuencia de rotación más corta: una frecuencia de rotación más corta implica costos más altos debido a que AWS Private CA, AWS KMS, Secrets Manager y Auto Scaling experimentan una mayor carga de trabajo para la rotación.
+ Frecuencia de rotación más larga: las comunicaciones de sus aplicaciones fallan si la frecuencia de rotación supera los **siete** días.
+ Eliminación del secreto: la eliminación del secreto provoca un error de rotación y afecta a las comunicaciones de las aplicaciones con los clientes.

En caso de que la rotación secreta no funcione, se publicará un evento `RotationFailed` en [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html). También puede configurar una [alarma de CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) para `RotationFailed`.

**importante**  
No agregue regiones de réplica a los secretos. Si las agrega, se evita que Amazon ECS elimine el secreto, ya que Amazon ECS no tiene permiso para eliminar regiones de la replicación. Si ya agregó la replicación, ejecute el siguiente comando.  

```
aws secretsmanager remove-regions-from-replication \
 --secret-id SecretId \
 --remove-replica-regions region-name
```

**Entidades de certificación subordinadas**  
Puede incorporar cualquier AWS Private CA, raíz o subordinado a TLS de Service Connect para emitir certificados de entidad final para los servicios. El emisor proporcionado se considera el firmante y la raíz de la confianza en todas partes. Puede emitir certificados de entidad final para distintas partes de la solicitud desde distintas entidades de certificación subordinadas. Al utilizar la AWS CLI, proporcione el Nombre de recurso de Amazon (ARN) de la CA para establecer la cadena de confianza.

**Autoridades de certificación en las instalaciones**  
Para usar su CA en las instalaciones, debe crear y configurar una CA subordinada en AWS Private Certificate Authority. Esto garantiza que todos los certificados TLS emitidos para sus cargas de trabajo de Amazon ECS compartan la cadena de confianza con las cargas de trabajo que ejecuta en las instalaciones y puedan conectarse de forma segura.

**importante**  
Agregue la etiqueta **obligatoria** `AmazonECSManaged : true` en su AWS Private CA. 

**Infraestructura como código**  
Al utilizar TLS de Service Connect con las herramientas de infraestructura como código (IaC), es importante configurar las dependencias correctamente para evitar problemas, como el agotamiento de los servicios. La clave de AWS KMS (si la ha proporcionado), el rol de IAM y las dependencias de AWS Private CA se deben eliminar después de utilizar el servicio de Amazon ECS.

Si el espacio de nombres que se usa para Service Connect es un espacio de nombres compartido, puede optar por utilizar un recurso compartido de AWS Private CA. Para obtener más información, consulte [Attach a policy for cross-account access](https://docs.aws.amazon.com/privateca/latest/userguide/pca-ram.html) en la *Guía del usuario de AWS Private Certificate Authority*.

## Service Connect y Secrets Manager
<a name="service-connect-asm"></a>

**Cuando se utiliza Amazon ECS Service Connect con el cifrado TLS, el servicio interactúa con Secrets Manager de las siguientes maneras:**  
Service Connect utiliza el rol de infraestructura proporcionado para crear secretos en Secrets Manager. Estos secretos se utilizan para almacenar las claves privadas asociadas para los certificados TLS para cifrar el tráfico entre los servicios de Service Connect.

**aviso**  
La creación y administración automáticas de estos secretos mediante Service Connect agiliza el proceso de implementación del cifrado TLS para los servicios. Sin embargo, es importante tener en cuenta las posibles implicaciones de seguridad. Es posible que otros roles de IAM que tengan acceso de lectura a Secrets Manager puedan acceder a estos secretos creados automáticamente. Esto podría exponer el material criptográfico confidencial a terceros no autorizados si los controles de acceso no están configurados correctamente.  
Para mitigar este riesgo, siga estas prácticas recomendadas:  
Administre y restrinja con cautela el acceso a Secrets Manager, sobre todo a los secretos creados por Service Connect.
Audite periódicamente los roles de IAM y sus permisos para garantizar que se mantenga el principio del privilegio mínimo.

Al conceder acceso de lectura a Secrets Manager, considere la posibilidad de excluir las claves privadas TLS creadas por Service Connect. Para ello, utilice una condición en las políticas de IAM para excluir los secretos con ARN que coincidan con el patrón:

```
"arn:aws:secretsmanager:::secret:ecs-sc!"
```

Un ejemplo de política de IAM que niega la acción `GetSecretValue` a todos los secretos con el prefijo `ecs-sc!`:

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "secretsmanager:GetSecretValue",
            "Resource": "arn:aws:secretsmanager:*:*:secret:ecs-sc!*"
        }
    ]
}
```

------

**nota**  
Este es un ejemplo general y puede que sea necesario ajustarlo en función del caso de uso específico y de la configuración de la cuenta de AWS. Pruebe siempre minuciosamente las políticas de IAM para garantizar que proporcionan el acceso previsto y, al mismo tiempo, mantienen la seguridad.

Al comprender cómo interactúa Service Connect con Secrets Manager, podrá administrar mejor la seguridad de los servicios de Amazon ECS y, al mismo tiempo, aprovechar las ventajas del cifrado TLS automático.

## Service Connect y AWS Key Management Service
<a name="service-connect-kms"></a>

Puede usar [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html) para cifrar y descifrar los recursos de Service Connect. AWS KMS es un servicio administrado por AWS con el que puede crear y administrar claves criptográficas que protejan sus datos.

Al usar AWS KMS con Service Connect, puede elegir usar una clave AWS propia que AWS administre por usted o puede elegir una clave AWS KMS existente. También puede [crear una clave de AWS KMS nueva](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk) para utilizarla.

**Proporcionar su propia clave de cifrado**  
Puede proporcionar sus propios materiales clave o puede utilizar un almacén de claves externo mediante AWS Key Management Service Import your own key into AWS KMS y, a continuación, especificar el nombre de recurso de Amazon (ARN) de esa clave en Amazon ECS Service Connect.

A continuación, se muestra una política AWS KMS de ejemplo. Sustituya las *entradas del usuario* por valores propios.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "id",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/role-name"
      },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:GenerateDataKey",
        "kms:GenerateDataKeyPair"
      ],
      "Resource": "*"
    }
  ]
}
```

------

Para obtener información sobre las políticas de claves, consulte [Creating a key policy](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-overview.html) en la *Guía para desarrolladores de AWS Key Management Service*.

**nota**  
Service Connect solo es compatible con claves de cifrado de AWS KMS simétricas. No puede utilizar ningún otro tipo de clave de AWS KMS para cifrar los recursos de Service Connect. Para obtener ayuda a fin de determinar si una clave AWS KMS es una clave de cifrado simétrica, consulte [Identificación de claves KMS asimétricas](https://docs.aws.amazon.com/kms/latest/developerguide/identify-key-types.html#identify-asymm-keys).

Para obtener más información sobre la clave de cifrado simétrica de AWS Key Management Service, consulte [Symmetric encryption AWS KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#symmetric-cmks) en la *Guía para desarrolladores de AWS Key Management Service*.

# Habilitación de TLS para Amazon ECS Service Connect
<a name="enable-service-connect-tls"></a>

El cifrado de tráfico se activa al crear o actualizar un servicio de Service Connect.

**Para habilitar el cifrado del tráfico de un servicio en un espacio de nombres existente mediante la Consola de administración de AWS**

1. Debe tener el rol de IAM de infraestructura. Para obtener más información sobre este rol, consulte [Rol de IAM para la infraestructura de Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/infrastructure_IAM_role.html                     ).

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 **Namespaces (Espacios de nombres)**.

1. Elija el **Espacio de nombres** con el **Servicio** para el que quiera habilitar el cifrado del tráfico.

1. Elija el **Servicio** para el que quiere habilitar el cifrado del tráfico.

1. Elija **Actualizar servicio** en la esquina superior derecha y desplácese hacia abajo hasta la sección Service Connect.

1. Elija **Activar el cifrado de tráfico** en la información del servicio para activar el TLS.

1. En **Rol de TLS de Service Connect**, elija entre crear un nuevo rol de IAM de infraestructura o usar uno que ya exista.

1. En **Autoridad de certificación firmante**, elija una entidad de certificación existente o cree una nueva.

   Para obtener más información, consulte [Certificados AWS Private Certificate Authority y Service Connect](service-connect-tls.md#service-connect-tls-certificates).

1. En **Elegir una AWS KMS key**, elija una clave propia y administrada por AWS o puede elegir una clave diferente. También tiene la opción de crear una nueva.

Si quiere ver un ejemplo del uso de la AWS CLI para configurar TLS para su servicio, consulte [Configuración de Amazon ECS Service Connect con la AWS CLI](create-service-connect.md).

# Comprobación de la habilitación de TLS para Amazon ECS Service Connect
<a name="verify-tls-enabled"></a>

Service Connect inicia el TLS en el agente de Service Connect y lo termina en el agente de destino. Como resultado, el código de la aplicación nunca ve las interacciones de TLS. Para comprobar que TLS esté habilitado, haga lo siguiente.

1. Incluya la CLI de `openssl` en la imagen de la aplicación.

1. Habilite [ECS Exec](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-exec.html) en sus servicios para que se conecten a sus tareas a través de SSM. Como alternativa, puede lanzar una instancia de Amazon EC2 en la misma VPC de Amazon que el servicio.

1. Recupere la IP y el puerto de una tarea de un servicio que desee verificar. Puede recuperar la dirección IP de la consola de AWS Cloud Map. La información se encuentra en la página de detalles del servicio dentro del espacio de nombres. 

1. Inicie sesión en cualquiera de las tareas mediante `execute-command`, tal como se muestra en el ejemplo siguiente. Como alternativa, inicie sesión en la instancia de Amazon EC2 creada en el **paso 2**.

   ```
   $ aws ecs execute-command --cluster cluster-name \
       --task task-id  \
       --container container-name \
       --interactive \
       --command "/bin/sh"
   ```
**nota**  
Al llamar directamente al nombre DNS no se revela el certificado.

1. En el shell conectado, utilice la CLI de `openssl` para comprobar y ver el certificado adjunto a la tarea.

   Ejemplo:

   ```
   openssl s_client -connect 10.0.147.43:6379 < /dev/null 2> /dev/null \ 
   | openssl x509 -noout -text
   ```

   Respuesta de ejemplo:

   ```
   Certificate:
       Data:
           Version: 3 (0x2)
           Serial Number:
               <serial-number>
           Signature Algorithm: ecdsa-with-SHA256
           Issuer: <issuer>
           Validity
               Not Before: Jan 23 21:38:12 2024 GMT
               Not After : Jan 30 22:38:12 2024 GMT
           Subject: <subject>
           Subject Public Key Info:
               Public Key Algorithm: id-ecPublicKey
                   Public-Key: (256 bit)
                   pub:
                       <pub>
                   ASN1 OID: prime256v1
                   NIST CURVE: P-256
           X509v3 extensions:
               X509v3 Subject Alternative Name:
                   DNS:redis.yelb-cftc
               X509v3 Basic Constraints:
                   CA:FALSE
               X509v3 Authority Key Identifier:
                   keyid:<key-id>
   
               X509v3 Subject Key Identifier:
                   1D:<id>
               X509v3 Key Usage: critical
                   Digital Signature, Key Encipherment
               X509v3 Extended Key Usage:
                   TLS Web Server Authentication, TLS Web Client Authentication
       Signature Algorithm: ecdsa-with-SHA256
           <hash>
   ```

# Configuración de Amazon ECS Service Connect con la AWS CLI
<a name="create-service-connect"></a>

Puede crear un servicio de Amazon ECS para una tarea de Fargate que utilice Service Connect a través de la AWS CLI.

**nota**  
Puede utilizar puntos de conexión de servicio de doble pila para interactuar con Amazon ECS desde la 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).

## Requisitos previos
<a name="create-service-connect-prereqs"></a>

A continuación, se indican los requisitos previos de Service Connect:
+ Compruebe que la última versión de la AWS CLI esté instalada y configurada. Para obtener más información, 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).
+ 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.
+ Tiene una VPC, una subred, una tabla de enrutamiento 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).
+ Tiene un rol de ejecución de tareas con el nombre `ecsTaskExecutionRole` y la política administrada `AmazonECSTaskExecutionRolePolicy` está asociada al rol. Este rol permite a Fargate escribir los registros de aplicaciones de NGINX y los registros de proxy de Service Connect en los registros de Amazon CloudWatch. Para obtener más información, consulte [Creación del rol de de ejecución de tareas](task_execution_IAM_role.md#create-task-execution-role).

## Paso 1: Crear el clúster
<a name="create-service-connect-cluster"></a>

Siga los pasos a continuación para crear el clúster y el espacio de nombres de Amazon ECS.

**Para crear un clúster de Amazon ECS y espacio de nombres de AWS Cloud Map**

1. Cree un clúster de Amazon ECS con el nombre `tutorial` para su utilización. El parámetro `--service-connect-defaults` establece el espacio de nombres predeterminado del clúster. En el resultado del ejemplo, no existe un espacio de nombres de AWS Cloud Map con nombre `service-connect` en esta cuenta y Región de AWS, por lo tanto, Amazon ECS crea el espacio de nombres. El espacio de nombres se crea en AWS Cloud Map en la cuenta y es visible con todos los demás espacios de nombres, así que debe usar un nombre que indique el propósito.

   ```
   aws ecs create-cluster --cluster-name tutorial --service-connect-defaults namespace=service-connect
   ```

   Salida:

   ```
   {
       "cluster": {
           "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/tutorial",
           "clusterName": "tutorial",
           "serviceConnectDefaults": {
               "namespace": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-EXAMPLE"
           },
           "status": "PROVISIONING",
           "registeredContainerInstancesCount": 0,
           "runningTasksCount": 0,
           "pendingTasksCount": 0,
           "activeServicesCount": 0,
           "statistics": [],
           "tags": [],
           "settings": [
               {
                   "name": "containerInsights",
                   "value": "disabled"
               }
           ],
           "capacityProviders": [],
           "defaultCapacityProviderStrategy": [],
           "attachments": [
               {
                   "id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
                   "type": "sc",
                   "status": "ATTACHING",
                   "details": []
               }
           ],
           "attachmentsStatus": "UPDATE_IN_PROGRESS"
       }
   }
   }
   ```

1. Compruebe que se haya creado el clúster:

   ```
   aws ecs describe-clusters --clusters tutorial
   ```

   Salida:

   ```
   {
       "clusters": [
           {
               "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/tutorial",
               "clusterName": "tutorial",
               "serviceConnectDefaults": {
                   "namespace": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-EXAMPLE"
               },
               "status": "ACTIVE",
               "registeredContainerInstancesCount": 0,
               "runningTasksCount": 0,
               "pendingTasksCount": 0,
               "activeServicesCount": 0,
               "statistics": [],
               "tags": [],
               "settings": [],
               "capacityProviders": [],
               "defaultCapacityProviderStrategy": []
           }
       ],
       "failures": []
   }
   ```

1. (Opcional) Compruebe que el espacio de nombres se haya creado en AWS Cloud Map. Puede usar la Consola de administración de AWS o la configuración normal de la AWS CLI, ya que esto se crea en AWS Cloud Map.

   Por ejemplo, use la AWS CLI:

   ```
   aws servicediscovery get-namespace --id ns-EXAMPLE
   ```

   Salida:

   ```
   {
       "Namespace": {
           "Id": "ns-EXAMPLE",
           "Arn": "arn:aws:servicediscovery:us-west-2:123456789012:namespace/ns-EXAMPLE",
           "Name": "service-connect",
           "Type": "HTTP",
           "Properties": {
               "DnsProperties": {
                   "SOA": {}
               },
               "HttpProperties": {
                   "HttpName": "service-connect"
               }
           },
           "CreateDate": 1661749852.422,
           "CreatorRequestId": "service-connect"
       }
   }
   ```

## Paso 2: crear el servicio para el servidor
<a name="create-service-connect-nginx-server"></a>

La característica de Service Connect está diseñada para interconectar varias aplicaciones en Amazon ECS. Al menos una de esas aplicaciones debe proporcionar un servicio web al cual conectarse. En este paso, creará:
+ La definición de tarea que utiliza la imagen del contenedor oficial de NGINX sin modificar e incluye la configuración de Service Connect.
+ La definición de servicio de Amazon ECS que configura Service Connect para proporcionar la detección de servicios y el proxy de malla de servicios para el tráfico a este servicio. La configuración reutiliza el espacio de nombres predeterminado de la configuración del clúster para reducir la cantidad de configuración que se realiza para cada servicio.
+ El servicio de Amazon ECS. Ejecuta una tarea mediante la definición de tarea e inserta un contenedor adicional para el proxy de Service Connect. El proxy escucha en el puerto desde la asignación de puertos del contenedor de la definición de la tarea. En una aplicación de cliente que se ejecuta en Amazon ECS, el proxy de la tarea del cliente escucha las conexiones salientes al nombre del puerto de definición de la tarea, el nombre de detección de servicios o el nombre de alias del cliente de servicio y el número de puerto del alias de cliente.

**Para crear el servicio web con Service Connect**

1. Registre una definición de tarea que sea compatible con Fargate y utilice el `awsvpc` en modo de red. Siga estos pasos:

   1. Cree un archivo denominado `service-connect-nginx.json` con los contenidos de la siguiente definición de tareas.

      Esta definición de tarea configura Service Connect al agregar los parámetros `name` y `appProtocol` a la asignación de puertos. El nombre del puerto hace que este sea más identificable en la configuración del servicio cuando se utilizan varios puertos. El nombre del puerto también se usa de forma predeterminada como nombre detectable para que lo usen otras aplicaciones en el espacio de nombres.

      La definición de la tarea contiene el rol de IAM de la tarea porque el servicio tiene habilitado ECS Exec.
**importante**  
Esta definición de tarea usa una `logConfiguration` para enviar la salida de nginx desde `stdout` y `stderr` hacia los registros de Amazon CloudWatch. Este rol de ejecución de tareas no tiene los permisos adicionales necesarios para crear el grupo de registro de registros de CloudWatch. Cree el grupo de registro de registros de CloudWatch mediante la Consola de administración de AWS o la AWS CLI. Si no desea enviar los registros de nginx a registros de CloudWatch, puede eliminar la `logConfiguration`.  
Sustituya el ID de la Cuenta de AWS en el rol de ejecución de la tarea por el ID de su Cuenta de AWS.

      ```
      {
          "family": "service-connect-nginx",
          "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
          "taskRoleArn": "arn:aws:iam::123456789012:role/ecsTaskRole",
          "networkMode": "awsvpc",
          "containerDefinitions": [
              {
              "name": "webserver",
              "image": "public.ecr.aws/docker/library/nginx:latest",
              "cpu": 100,
              "portMappings": [
                  {
                      "name": "nginx",
                      "containerPort": 80,
                      "protocol": "tcp", 
                      "appProtocol": "http"
                  }
              ],
              "essential": true,
              "logConfiguration": {
                  "logDriver": "awslogs",
                  "options": {
                      "awslogs-group": "/ecs/service-connect-nginx",
                      "awslogs-region": "region", 
                      "awslogs-stream-prefix": "nginx"
                  }
              }
              }
          ],
          "cpu": "256",
          "memory": "512"
      }
      ```

   1. Registre la definición de tareas mediante el archivo `service-connect-nginx.json`:

      ```
      aws ecs register-task-definition --cli-input-json file://service-connect-nginx.json
      ```

1. Cree un servicio:

   1. Cree un archivo llamado `service-connect-nginx-service.json` con el contenido del servicio de Amazon ECS que va a crear. En este ejemplo se utiliza la definición de tareas creada en el paso anterior. Es necesario un `awsvpcConfiguration` porque el ejemplo de definición de tareas utiliza el modo de red `awsvpc`.

      Cuando cree el servicio de ECS, especifique Fargate y la versión `LATEST` de la plataforma que admite Service Connect. Los `securityGroups` y las `subnets` deben pertenecer a una VPC que cumpla los requisitos de uso de Amazon ECS. Puede obtener los ID de subred y grupos de seguridad en la consola de Amazon VPC. 

      Este servicio configura Service Connect al agregar el parámetro `serviceConnectConfiguration`. El espacio de nombres no es obligatorio porque el clúster tiene configurado un espacio de nombres predeterminado. Las aplicaciones de cliente que se ejecutan en ECS en el espacio de nombres se conectan a este servicio mediante `portName` y el puerto de `clientAliases`. Por ejemplo, se puede acceder a este servicio con `http://nginx:80/`, ya que nginx proporciona una página de bienvenida en la ubicación raíz `/`. Las aplicaciones externas que no se ejecutan en Amazon ECS o que no están en el mismo espacio de nombres pueden acceder a esta aplicación a través del proxy de Service Connect mediante la dirección IP de la tarea y el número de puerto de la definición de la tarea. Para su configuración de `tls`, agregue el certificado `arn` para su `awsPcaAuthorityArn` su `kmsKey`, y `roleArn` de su rol de IAM.

      Este servicio utiliza una `logConfiguration` para enviar la salida del proxy de Service Connect desde `stdout` y `stderr` hacia los registros de Amazon CloudWatch. Este rol de ejecución de tareas no tiene los permisos adicionales necesarios para crear el grupo de registro de registros de CloudWatch. Cree el grupo de registro de registros de CloudWatch mediante la Consola de administración de AWS o la AWS CLI. Le recomendamos que cree este grupo de registro y almacene los registros de proxy en registros de CloudWatch. Si no desea enviar los registros de proxy a registros de CloudWatch, puede eliminar la `logConfiguration`.

      ```
      {
          "cluster": "tutorial",
          "deploymentConfiguration": {
              "maximumPercent": 200,
              "minimumHealthyPercent": 0
          },
          "deploymentController": {
              "type": "ECS"
          },
          "desiredCount": 1,
          "enableECSManagedTags": true,
          "enableExecuteCommand": true,
          "launchType": "FARGATE",
          "networkConfiguration": {
              "awsvpcConfiguration": {
                  "assignPublicIp": "ENABLED",
                  "securityGroups": [
                      "sg-EXAMPLE"
                  ],
                  "subnets": [
                      "subnet-EXAMPLE",
                      "subnet-EXAMPLE",
                      "subnet-EXAMPLE"
                  ]
                 }
          },
          "platformVersion": "LATEST",
          "propagateTags": "SERVICE",
          "serviceName": "service-connect-nginx-service",
          "serviceConnectConfiguration": {
              "enabled": true,
              "services": [
                  {
                      "portName": "nginx",
                      "clientAliases": [
                          {
                              "port": 80
                          }
                      ],
                      "tls": {
                         "issuerCertificateAuthority": {
                            "awsPcaAuthorityArn": "certificateArn"
                         }, 
                         "kmsKey": "kmsKey", 
                         "roleArn": "iamRoleArn"
                      }
                  }
              ],
              "logConfiguration": {
                  "logDriver": "awslogs",
                  "options": {
                      "awslogs-group": "/ecs/service-connect-proxy",
                      "awslogs-region": "region",
                      "awslogs-stream-prefix": "service-connect-proxy"
                  }
              }
          },
          "taskDefinition": "service-connect-nginx"
      }
      ```

   1. Cree un servicio mediante el archivo `service-connect-nginx-service.json`:

      ```
      aws ecs create-service --cluster tutorial --cli-input-json file://service-connect-nginx-service.json
      ```

      Salida:

      ```
      {
          "service": {
              "serviceArn": "arn:aws:ecs:us-west-2:123456789012:service/tutorial/service-connect-nginx-service",
              "serviceName": "service-connect-nginx-service",
              "clusterArn": "arn:aws:ecs:us-west-2:123456789012:cluster/tutorial",
              "loadBalancers": [],
              "serviceRegistries": [],
              "status": "ACTIVE",
              "desiredCount": 1,
              "runningCount": 0,
              "pendingCount": 0,
              "launchType": "FARGATE",
              "platformVersion": "LATEST",
              "platformFamily": "Linux",
              "taskDefinition": "arn:aws:ecs:us-west-2:123456789012:task-definition/service-connect-nginx:1",
              "deploymentConfiguration": {
                  "deploymentCircuitBreaker": {
                      "enable": false,
                      "rollback": false
                  },
                  "maximumPercent": 200,
                  "minimumHealthyPercent": 0
              },
              "deployments": [
                  {
                      "id": "ecs-svc/3763308422771520962",
                      "status": "PRIMARY",
                      "taskDefinition": "arn:aws:ecs:us-west-2:123456789012:task-definition/service-connect-nginx:1",
                      "desiredCount": 1,
                      "pendingCount": 0,
                      "runningCount": 0,
                      "failedTasks": 0,
                      "createdAt": 1661210032.602,
                      "updatedAt": 1661210032.602,
                      "launchType": "FARGATE",
                      "platformVersion": "1.4.0",
                      "platformFamily": "Linux",
                      "networkConfiguration": {
                          "awsvpcConfiguration": {
                              "assignPublicIp": "ENABLED",
                              "securityGroups": [
                                  "sg-EXAMPLE"
                              ],
                              "subnets": [
                                  "subnet-EXAMPLEf",
                                  "subnet-EXAMPLE",
                                  "subnet-EXAMPLE"
                              ]
                          }
                      },
                      "rolloutState": "IN_PROGRESS",
                      "rolloutStateReason": "ECS deployment ecs-svc/3763308422771520962 in progress.",
                      "failedLaunchTaskCount": 0,
                      "replacedTaskCount": 0,
                      "serviceConnectConfiguration": {
                          "enabled": true,
                          "namespace": "service-connect",
                          "services": [
                              {
                                  "portName": "nginx",
                                  "clientAliases": [
                                      {
                                          "port": 80
                                      }
                                  ]
                              }
                          ],
                          "logConfiguration": {
                              "logDriver": "awslogs",
                              "options": {
                                  "awslogs-group": "/ecs/service-connect-proxy",
                                  "awslogs-region": "us-west-2",
                                  "awslogs-stream-prefix": "service-connect-proxy"
                              },
                              "secretOptions": []
                          }
                      },
                      "serviceConnectResources": [
                          {
                              "discoveryName": "nginx",
                              "discoveryArn": "arn:aws:servicediscovery:us-west-2:123456789012:service/srv-EXAMPLE"
                          }
                      ]
                  }
              ],
              "roleArn": "arn:aws:iam::123456789012:role/aws-service-role/ecs.amazonaws.com/AWSServiceRoleForECS",
              "version": 0,
              "events": [],
              "createdAt": 1661210032.602,
              "placementConstraints": [],
              "placementStrategy": [],
              "networkConfiguration": {
                  "awsvpcConfiguration": {
                      "assignPublicIp": "ENABLED",
                      "securityGroups": [
                          "sg-EXAMPLE"
                      ],
                      "subnets": [
                          "subnet-EXAMPLE",
                          "subnet-EXAMPLE",
                          "subnet-EXAMPLE"
                      ]
                  }
              },
              "schedulingStrategy": "REPLICA",
              "enableECSManagedTags": true,
              "propagateTags": "SERVICE",
              "enableExecuteCommand": true
          }
      }
      ```

      La `serviceConnectConfiguration` que ha proporcionado aparece dentro de la primera *implementación* de la salida. A medida que hace cambios en el servicio de ECS de manera que es necesario realizar cambios en las tareas, Amazon ECS crea una nueva implementación.

## Paso 3: Comprobar que puede conectarse
<a name="create-service-connect-verify"></a>

Para comprobar que Service Connect está configurado y funciona, siga estos pasos para conectarse al servicio web desde una aplicación externa. A continuación, consulte las métricas adicionales en CloudWatch que crea el proxy de Service Connect.

**Para conectarse al servicio web desde una aplicación externa**
+ Conéctese a la dirección IP de la tarea y al puerto del contenedor mediante la dirección IP de la tarea

  Utilice la AWS CLI para obtener el ID de la tarea, mediante el `aws ecs list-tasks --cluster tutorial`.

  Si las subredes y el grupo de seguridad permiten el tráfico de la Internet pública en el puerto de la definición de la tarea, puede conectarse a la IP pública desde su equipo. Sin embargo, la IP pública no está disponible en “describe-tasks”, por lo que los pasos incluyen ir a la Consola de administración de AWS o la AWS CLI de Amazon EC2 para obtener los detalles de la interfaz de red elástica.

  En este ejemplo, una instancia de Amazon EC2 de la misma VPC usa la IP privada de la tarea. La aplicación es nginx, pero el encabezado `server: envoy` muestra que se utiliza el proxy de Service Connect. El proxy de Service Connect escucha el puerto del contenedor de la definición de la tarea.

  ```
  $ curl -v 10.0.19.50:80/
  *   Trying 10.0.19.50:80...
  * Connected to 10.0.19.50 (10.0.19.50) port 80 (#0)
  > GET / HTTP/1.1
  > Host: 10.0.19.50
  > User-Agent: curl/7.79.1
  > Accept: */*
  >
  * Mark bundle as not supporting multiuse
  < HTTP/1.1 200 OK
  < server: envoy
  < date: Tue, 23 Aug 2022 03:53:06 GMT
  < content-type: text/html
  < content-length: 612
  < last-modified: Tue, 16 Apr 2019 13:08:19 GMT
  < etag: "5cb5d3c3-264"
  < accept-ranges: bytes
  < x-envoy-upstream-service-time: 0
  <
  <!DOCTYPE html>
  <html>
  <head>
  <title>Welcome to nginx!</title>
  <style>
      body {
          width: 35em;
          margin: 0 auto;
          font-family: Tahoma, Verdana, Arial, sans-serif;
      }
  </style>
  </head>
  <body>
  <h1>Welcome to nginx!</h1>
  <p>If you see this page, the nginx web server is successfully installed and
  working. Further configuration is required.</p>
  
  <p>For online documentation and support please refer to
  <a href="http://nginx.org/">nginx.org</a>.<br/>
  Commercial support is available at
  <a href="http://nginx.com/">nginx.com</a>.</p>
  
  <p><em>Thank you for using nginx.</em></p>
  </body>
  </html>
  ```

**Para ver las métricas de Service Connect**  
El proxy de Service Connect crea métricas de aplicaciones (conexión HTTP, HTTP2, gRPC o TCP) en las métricas de CloudWatch. Cuando utilice la consola de CloudWatch, consulte las dimensiones de métricas adicionales de **DiscoveryName**, (**DiscoveryName, ServiceName, ClusterName**), **TargetDiscoveryName** y (**TargetDiscoveryName, ServiceName, ClusterName**) en el espacio de nombres de Amazon ECS. Para obtener más información acerca de estas métricas y sus dimensiones, consulte [View Available Metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/viewing_metrics_with_cloudwatch.html) en la Guía del usuario de Registros de Amazon CloudWatch.

# Uso de la detección de servicios para conectar los servicios de Amazon ECS con nombres de DNS
<a name="service-discovery"></a>

Su servicio de Amazon ECS también puede configurarse para utilizar la detección de servicios de Amazon ECS. La detección de servicios utiliza acciones de la API de AWS Cloud Map para administrar los espacios de nombres de DNS y HTTP para sus servicios de Amazon ECS. Para obtener más información, consulte [¿Qué es AWS Cloud Map?](https://docs.aws.amazon.com/cloud-map/latest/dg/Welcome.html) en la *Guía para desarrolladores de AWS Cloud Map*.

La detección de servicios se encuentra disponible en las siguientes regiones de AWS:


| Nombre de la región | Región | 
| --- | --- | 
|  Este de EE. UU. (Norte de Virginia)  |  us-east-1  | 
|  Este de EE. UU. (Ohio)  |  us-east-2  | 
|  Oeste de EE. UU. (Norte de California)  |  us-west-1  | 
|  Oeste de EE. UU. (Oregón)  |  us-west-2  | 
|  África (Ciudad del Cabo)  |  af-south-1  | 
|  Asia-Pacífico (Hong Kong)  |  ap-east-1  | 
|  Asia-Pacífico (Taipéi)  |  ap-east-2  | 
|  Asia-Pacífico (Mumbai)  |  ap-south-1  | 
|  Asia-Pacífico (Hyderabad)  |  ap-south-2  | 
|  Asia-Pacífico (Tokio)  |  ap-northeast-1  | 
|  Asia-Pacífico (Seúl)  |  ap-northeast-2  | 
|  Asia-Pacífico (Osaka)  |  ap-northeast-3  | 
|  Asia-Pacífico (Singapur)  |  ap-southeast-1  | 
|  Asia-Pacífico (Sídney)  |  ap-southeast-2  | 
|  Asia-Pacífico (Yakarta)  |  ap-southeast-3  | 
|  Asia-Pacífico (Melbourne)  |  ap-southeast-4  | 
|  Asia-Pacífico (Malasia)  |  ap-southeast-5  | 
|  Asia-Pacífico (Nueva Zelanda)  |  ap-southeast-6  | 
|  Asia-Pacífico (Tailandia)  |  ap-southeast-7  | 
|  Canadá (centro)  |  ca-central-1  | 
|  Oeste de Canadá (Calgary)  |  ca-west-1  | 
|  China (Pekín)  |  cn-north-1  | 
|  China (Ningxia)  |  cn-northwest-1  | 
|  Europe (Frankfurt)  |  eu-central-1  | 
|  Europa (Zúrich)  |  eu-central-2  | 
|  Europa (Irlanda)  |  eu-west-1  | 
|  Europa (Londres)  |  eu-west-2  | 
|  Europa (París)  |  eu-west-3  | 
|  Europa (Milán)  |  eu-south-1  | 
|  Europa (Estocolmo)  |  eu-north-1  | 
|  Israel (Tel Aviv)  |  il-central-1  | 
|  Europa (España)  |  eu-south-2  | 
|  Medio Oriente (EAU)  |  me-central-1  | 
|  México (centro)  |  mx-central-1  | 
|  Medio Oriente (Baréin)  |  me-south-1  | 
|  América del Sur (São Paulo)  |  sa-east-1  | 
|  AWS GovCloud (Este de EE. UU.)  |  us-gov-east-1  | 
|  AWS GovCloud (Oeste de EE. UU.)  |  us-gov-west-1  | 

## Conceptos sobre la detección de servicios
<a name="service-discovery-concepts"></a>

La detección de servicios consta de los siguientes componentes:
+ **Espacio de nombres de detección de servicios**: grupo lógico de servicios de detección de servicios que comparten el mismo nombre de dominio, como `example.com`, que es adónde quiere dirigir el tráfico. Puede crear un espacio de nombres con una llamada al comando `aws servicediscovery create-private-dns-namespace` o en la consola de Amazon ECS. Puede utilizar el comando `aws servicediscovery list-namespaces` para ver la información de resumen de los espacios de nombres creados por la cuenta corriente. Para obtener más información acerca de los comandos de detección de servicios, consulte `[create-private-dns-namespace](https://docs.aws.amazon.com/cli/latest/reference/servicediscovery/create-private-dns-namespace.html)` y `[list-namespaces](https://docs.aws.amazon.com/cli/latest/reference/servicediscovery/list-namespaces.html)` en la *Guía de referencia de AWS Cloud Map (detección de servicios) de la AWS CLI*.
+ **Service discovery service** (Servicio de detección de servicios): existe dentro del espacio de nombres de detección de servicios y consta del nombre del servicio y la configuración de DNS para el espacio de nombres. Proporciona los siguientes componentes principales:
  + **Registro de servicios**: permite buscar un servicio mediante DNS o con las acciones de la API de AWS Cloud Map y recuperar uno o varios puntos de enlace disponibles que se pueden utilizar para conectarse al servicio.
+ **Service discovery instance** (Instancia de detección de servicios): existe dentro del servicio de detección de servicios y consiste en atributos asociados a cada servicio de Amazon ECS del directorio de servicios.
  + **Instance attributes** (Atributos de instancia): se agregan los siguientes metadatos como atributos personalizados para cada servicio de Amazon ECS que se configura para utilizar la detección de servicios:
    + **`AWS_INSTANCE_IPV4`**: en el caso de un registro `A`, la dirección IPv4 que Route 53 devuelve en respuesta a consultas de DNS y AWS Cloud Map devuelve al detectar detalles de la instancia, por ejemplo, `192.0.2.44`.
    + **`AWS_INSTANCE_IPV6`**: en el caso de un registro `AAAA`, la dirección IPv6 que Route 53 devuelve en respuesta a consultas de DNS y AWS Cloud Map devuelve al detectar detalles de la instancia; por ejemplo, ` 2001:0db8:85a3:0000:0000:abcd:0001:2345`. Tanto `AWS_INSTANCE_IPv4` como `AWS_INSTANCE_IPv6` se agregan para los servicios de doble pila de Amazon ECS. Solo `AWS_INSTANCE_IPv6` se agrega para los servicios de solo IPv6 de Amazon ECS.
    + **`AWS_INSTANCE_PORT`** – el valor del puerto asociado al servicio de detección de servicios.
    + **`AVAILABILITY_ZONE`** – la zona de disponibilidad en la que se lanzó la tarea. En el caso de las tareas que usan EC2, esta es la zona de disponibilidad en la que existe la instancia de contenedor. En el caso de las tareas que utilizan Fargate, esta es la zona de disponibilidad en la que existe la interfaz de red elástica.
    + **`REGION`** – la región en la que existe la tarea.
    + **`ECS_SERVICE_NAME`** – el nombre del servicio de Amazon ECS al que pertenece la tarea.
    + **`ECS_CLUSTER_NAME`** – el nombre del clúster de Amazon ECS al que pertenece la tarea.
    + **`EC2_INSTANCE_ID`** – el ID de la instancia de contenedor en el que se colocó la tarea. Este atributo personalizado no se agrega si la tarea utiliza Fargate.
    + **`ECS_TASK_DEFINITION_FAMILY`** – la familia de definición de tareas que utiliza la tarea.
    + **`ECS_TASK_SET_EXTERNAL_ID`**: si se crea un conjunto de tareas para una implementación externa y se asocia a un registro de detección de servicios, el atributo `ECS_TASK_SET_EXTERNAL_ID` contendrá el ID externo del conjunto de tareas.
+ **Amazon ECS health checks** (Comprobaciones de estado de Amazon ECS): Amazon ECS realiza comprobaciones de estado periódicas en el nivel de contenedor. Si un punto de enlace no supera la comprobación de estado, se elimina del direccionamiento de DNS y se marca como en mal estado.

## Consideraciones sobre la detección de servicios
<a name="service-discovery-considerations"></a>

Al utilizar la detección de servicios, se debe tener en cuenta lo siguiente:
+ La detección de servicios es compatible con tareas alojadas en Fargate que utilizan la versión 1.1.0 de la plataforma o una posterior. Para obtener más información, consulte [Versiones de la plataforma Fargate para Amazon ECS](platform-fargate.md).
+ Los servicios configurados para utilizar la detección de servicios tienen un límite de 1000 tareas por servicio. Esto se debe a una cuota de servicio de Route 53.
+ El flujo de trabajo de creación de servicio en la consola de Amazon ECS solo es admite el registro de servicios en espacios de nombres de DNS privado. Cuando se crea un espacio de nombres de DNS privado de AWS Cloud Map, se creará automáticamente una zona alojada privada de Route 53.
+ Los atributos de DNS de la VPC deben estar configurados para una resolución de DNS correcta. Para obtener información acerca de cómo configurar los atributos, consulte [Compatibilidad de la VPC con DNS](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-support) en la *Guía del usuario de Amazon VPC*.
+ Amazon ECS no admite el registro de servicios en espacios de nombres de AWS Cloud Map compartidos.
+ Los registros de DNS creados para un servicio de detección de servicios se registran siempre con la dirección IP privada de la tarea, en lugar de la dirección IP pública, incluso cuando se utilizan espacios de nombres públicos.
+ La detección de servicios requiere que las tareas especifiquen el modo de red `awsvpc`, `bridge` o `host` (`none` no se admite).
+ Si la definición de tarea de servicio usa el modo de red `awsvpc`, puede crear cualquier combinación de registros `A` o `SRV` para cada tarea de servicio. Si utiliza los registros `SRV`, se necesita un puerto. También puede crear registros `AAAA` si el servicio utiliza subredes de doble pila. Si el servicio utiliza subredes de solo IPv6, no puede crear registros `A`.
+ Si la definición de tarea de servicio usa el modo de red `bridge` o `host`, el único tipo de registro de DNS admitido es un registro SRV. Cree un registro SRV para cada tarea de servicio. El registro SRV debe especificar una combinación de nombre y puerto de contenedor en la definición de tarea.
+ Los registros de DNS de un servicio de detección de servicios se pueden consultar dentro de la VPC. Utilizan el siguiente formato .: `<service-discovery-service-name>.<service-discovery-namespace>`.
+ Al realizar una consulta de DNS en el nombre del servicio, los registros `A` y `AAAA` devuelven un conjunto de direcciones IP que corresponden a las tareas. Los registros `SRV` devuelven un conjunto de direcciones IP y puertos para cada tarea.
+ Si tiene ocho registros o menos en buen estado, Route 53 responde a todas las consultas de DNS con todos los registros en buen estado.
+ Cuando todos los registros están en mal estado, Route 53 responde a las consultas de DNS con hasta ocho registros en mal estado.
+ Puede configurar la detección de servicios para un servicio que se encuentre detrás de un equilibrador de carga, pero el tráfico de la detección de servicios siempre se dirige a la tarea, no al equilibrador de carga.
+ La detección de servicios no admite el uso del equilibrador de carga clásico.
+ Se recomienda utilizar las comprobaciones de estado de nivel de contenedor administradas por Amazon ECS para el servicio de detección de servicios.
  + **HealthCheckCustomConfig**: Amazon ECS administra las comprobaciones de estado en su nombre. Amazon ECS utiliza información del contenedor y de las comprobaciones de estado, además del estado de la tarea, para actualizar el estado mediante AWS Cloud Map. Esto se especifica a través del parámetro `--health-check-custom-config` cuando se crea el servicio de detección de servicios. Para obtener más información, consulte [HealthCheckCustomConfig](https://docs.aws.amazon.com/cloud-map/latest/api/API_HealthCheckCustomConfig.html) en la *Referencia de la API de AWS Cloud Map*.
+ Los recursos de AWS Cloud Map que se crean cuando se utiliza la detección de servicios se deben limpiar manualmente.
+ Las tareas y las instancias se registran como `UNHEALTHY` hasta que las comprobaciones de estado del contenedor devuelvan un valor. Si se pasan las comprobaciones de estado, el estado se actualiza a `HEALTHY`. Si las comprobaciones de estado del contenedor fallan, se anula el registro de la instancia de detección de servicios.

## Precios de la detección de servicios
<a name="service-discovery-pricing"></a>

Los clientes que utilizan la detección de servicios de Amazon ECS deben pagar cargos por los recursos de Route 53 y las operaciones de la API de detección de AWS Cloud Map. Se cobran costos por crear zonas alojadas en Route 53 y por las consultas al registro de servicios. Para obtener más información, consulte [Precios de AWS Cloud Map](https://docs.aws.amazon.com/cloud-map/latest/dg/cloud-map-pricing.html) en la *Guía para desarrolladores de AWS Cloud Map*.

Amazon ECS realiza comprobaciones de estado en el nivel de contenedor y las expone a operaciones de la API de comprobación de estado personalizada de AWS Cloud Map. Actualmente, esto está a disposición de los clientes sin ningún costo adicional. Si configura las comprobaciones de estado de red adicionales para tareas expuestas de forma pública, se le cobrará por dichas comprobaciones de estado.

# Creación de un servicio de Amazon ECS que utilice la detección de servicios
<a name="create-service-discovery"></a>

Obtenga información sobre cómo crear un servicio que contenga una tarea de Fargate que utilice la detección de servicios a través de la AWS CLI.

Para obtener una lista de Regiones de AWS que admiten la detección de servicios, consulte [Uso de la detección de servicios para conectar los servicios de Amazon ECS con nombres de DNS](service-discovery.md).

Para obtener información acerca de las regiones que admiten Fargate, consulte [Regiones compatibles con Amazon ECS en AWS Fargate](AWS_Fargate-Regions.md).

**nota**  
Puede utilizar puntos de conexión de servicio de doble pila para interactuar con Amazon ECS desde la 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).

## Requisitos previos
<a name="create-service-discovery-prereqs"></a>

Antes de empezar este tutorial, asegúrese de que se cumplen los siguientes requisitos previos:
+ La última versión de la AWS CLI está instalada y configurada. Para obtener más información, 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).
+ Los pasos descritos en [Configuración para utilizar Amazon ECS](get-set-up-for-amazon-ecs.md) están completos.
+ 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.
+ Ha creado al menos una VPC y un grupo de seguridad. 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 los recursos para la detección de servicios en AWS Cloud Map
<a name="create-service-discovery-namespace"></a>

Siga estos pasos para crear el espacio de nombres para la detección de servicios y el servicio de detección de servicios:

1. Cree un espacio de nombres de detección de servicios de Cloud Map privado. Este ejemplo crea un espacio de nombres denominado `tutorial`. Reemplace *vpc-abcd1234* con el ID de una de las VPC existentes. 

   ```
   aws servicediscovery create-private-dns-namespace \
         --name tutorial \
         --vpc vpc-abcd1234
   ```

   A continuación se muestra la salida de este comando.

   ```
   {
       "OperationId": "h2qe3s6dxftvvt7riu6lfy2f6c3jlhf4-je6chs2e"
   }
   ```

1. Mediante el `OperationId` de la salida del paso anterior, compruebe que el espacio de nombres privado se haya creado correctamente. Anote el ID del espacio de nombres porque lo utilizará en los comandos posteriores.

   ```
   aws servicediscovery get-operation \
         --operation-id h2qe3s6dxftvvt7riu6lfy2f6c3jlhf4-je6chs2e
   ```

   El resultado es el siguiente.

   ```
   {
       "Operation": {
           "Id": "h2qe3s6dxftvvt7riu6lfy2f6c3jlhf4-je6chs2e",
           "Type": "CREATE_NAMESPACE",
           "Status": "SUCCESS",
           "CreateDate": 1519777852.502,
           "UpdateDate": 1519777856.086,
           "Targets": {
              "NAMESPACE": "ns-uejictsjen2i4eeg"
           }
       }
   }
   ```

1. Mediante el ID de `NAMESPACE` de la salida del paso anterior, cree un servicio de detección de servicios. En este ejemplo, se crea un servicio denominado `myapplication`. Anote el ID de servicio y el ARN porque los utilizará en comandos posteriores.

   ```
   aws servicediscovery create-service \
         --name myapplication \
         --dns-config "NamespaceId="ns-uejictsjen2i4eeg",DnsRecords=[{Type="A",TTL="300"}]" \
         --health-check-custom-config FailureThreshold=1
   ```

   El resultado es el siguiente.

   ```
   {
       "Service": {
          "Id": "srv-utcrh6wavdkggqtk",
           "Arn": "arn:aws:servicediscovery:region:aws_account_id:service/srv-utcrh6wavdkggqtk",
           "Name": "myapplication",
           "DnsConfig": {
               "NamespaceId": "ns-uejictsjen2i4eeg",
               "DnsRecords": [
                   {
                       "Type": "A",
                       "TTL": 300
                   }
               ]
           },
           "HealthCheckCustomConfig": {
               "FailureThreshold": 1
           },
           "CreatorRequestId": "e49a8797-b735-481b-a657-b74d1d6734eb"
       }
   }
   ```

## Paso 2: Crear los recursos de Amazon ECS
<a name="create-service-discovery-cluster"></a>

Siga estos pasos para crear el clúster, la definición de tareas y el servicio de Amazon ECS:

1. Cree un clúster de Amazon ECS. Este ejemplo crea un clúster denominado `tutorial`. 

   ```
   aws ecs create-cluster \
         --cluster-name tutorial
   ```

1. Registre una definición de tarea que sea compatible con Fargate y utilice el `awsvpc` en modo de red. Siga estos pasos:

   1. Cree un archivo denominado `fargate-task.json` con los contenidos de la siguiente definición de tareas.

      ```
      {
          "family": "tutorial-task-def",
              "networkMode": "awsvpc",
              "containerDefinitions": [
                  {
                      "name": "sample-app",
                      "image": "public.ecr.aws/docker/library/httpd:2.4",
                      "portMappings": [
                          {
                              "containerPort": 80,
                              "hostPort": 80,
                              "protocol": "tcp"
                          }
                      ],
                      "essential": true,
                      "entryPoint": [
                          "sh",
                          "-c"
                      ],
                      "command": [
                          "/bin/sh -c \"echo '<html> <head> <title>Amazon ECS Sample App</title> <style>body {margin-top: 40px; background-color: #333;} </style> </head><body> <div style=color:white;text-align:center> <h1>Amazon ECS Sample App</h1> <h2>Congratulations!</h2> <p>Your application is now running on a container in Amazon ECS.</p> </div></body></html>' >  /usr/local/apache2/htdocs/index.html && httpd-foreground\""
                      ]
                  }
              ],
              "requiresCompatibilities": [
                  "FARGATE"
              ],
              "cpu": "256",
              "memory": "512"
      }
      ```

   1. Registre la definición de tareas mediante `fargate-task.json`.

      ```
      aws ecs register-task-definition \
            --cli-input-json file://fargate-task.json
      ```

1. Cree un servicio de ECS siguiendo estos pasos:

   1. Cree un archivo llamado `ecs-service-discovery.json` con el contenido del servicio de ECS que va a crear. En este ejemplo se utiliza la definición de tareas creada en el paso anterior. Es necesario un `awsvpcConfiguration` porque el ejemplo de definición de tareas utiliza el modo de red `awsvpc`. 

      Cuando cree el servicio de ECS, especifique Fargate y la versión `LATEST` de la plataforma que admite la detección de servicios. Cuando se crea el servicio de detección de servicios en AWS Cloud Map, `registryArn` es el ARN devuelto. Los `securityGroups` y las `subnets` deben pertenecer a la VPC que se usa para crear el espacio de nombres de Cloud Map. Puede obtener los ID de subred y grupos de seguridad en la consola de Amazon VPC.

      ```
      {
          "cluster": "tutorial",
          "serviceName": "ecs-service-discovery",
          "taskDefinition": "tutorial-task-def",
          "serviceRegistries": [
             {
                "registryArn": "arn:aws:servicediscovery:region:aws_account_id:service/srv-utcrh6wavdkggqtk"
             }
          ],
          "launchType": "FARGATE",
          "platformVersion": "LATEST",
          "networkConfiguration": {
             "awsvpcConfiguration": {
                "assignPublicIp": "ENABLED",
                "securityGroups": [ "sg-abcd1234" ],
                "subnets": [ "subnet-abcd1234" ]
             }
          },
          "desiredCount": 1
      }
      ```

   1. Cree el servicio de ECS mediante `ecs-service-discovery.json`.

      ```
      aws ecs create-service \
            --cli-input-json file://ecs-service-discovery.json
      ```

## Paso 3: verificar la detección de servicios en AWS Cloud Map
<a name="create-service-discovery-verify"></a>

Puede comprobar que todo se haya creado de forma correcta al consultar la información de detección de servicios. Una vez configurada la detección de servicios, puede usar las operaciones de la API de AWS Cloud Map o llamar a `dig` desde una instancia de la VPC. Siga estos pasos:

1. Mediante el ID del servicio de detección de servicios, enumere las instancias de detección de servicios. Anote el ID de la instancia (marcado en negrita) para la limpieza de recursos. 

   ```
    aws servicediscovery list-instances \
          --service-id srv-utcrh6wavdkggqtk
   ```

   El resultado es el siguiente.

   ```
   {
       "Instances": [
           {
               "Id": "16becc26-8558-4af1-9fbd-f81be062a266",
               "Attributes": {
                   "AWS_INSTANCE_IPV4": "172.31.87.2"
                   "AWS_INSTANCE_PORT": "80", 
                   "AVAILABILITY_ZONE": "us-east-1a", 
                   "REGION": "us-east-1", 
                   "ECS_SERVICE_NAME": "ecs-service-discovery", 
                   "ECS_CLUSTER_NAME": "tutorial", 
                   "ECS_TASK_DEFINITION_FAMILY": "tutorial-task-def"
               }
           }
       ]
   }
   ```

1. Utilice el espacio de nombres de detección de servicios, el servicio y los parámetros adicionales, como el nombre del clúster ECS, para consultar los detalles de las instancias de detección de servicios.

   ```
   aws servicediscovery discover-instances \
         --namespace-name tutorial \
         --service-name myapplication \
         --query-parameters ECS_CLUSTER_NAME=tutorial
   ```

1. Los registros de DNS que se crearon en la zona alojada de Route 53 para el servicio de detección de servicios se pueden consultar mediante los siguientes comandos de la AWS CLI:

   1. Mediante el ID de espacio de nombres, obtenga información acerca del espacio de nombres, lo que incluye el ID de la zona alojada de Route 53.

      ```
      aws servicediscovery \
            get-namespace --id ns-uejictsjen2i4eeg
      ```

      El resultado es el siguiente.

      ```
      {
          "Namespace": {
              "Id": "ns-uejictsjen2i4eeg",
              "Arn": "arn:aws:servicediscovery:region:aws_account_id:namespace/ns-uejictsjen2i4eeg",
              "Name": "tutorial",
              "Type": "DNS_PRIVATE",
              "Properties": {
                   "DnsProperties": {
                      "HostedZoneId": "Z35JQ4ZFDRYPLV"
                  }
              },
              "CreateDate": 1519777852.502,
              "CreatorRequestId": "9049a1d5-25e4-4115-8625-96dbda9a6093"
          }
      }
      ```

   1. Mediante el ID de la zona alojada de Route 53 del paso anterior, obtenga el conjunto de registros de recursos de la zona alojada. 

      ```
      aws route53 list-resource-record-sets \
            --hosted-zone-id Z35JQ4ZFDRYPLV
      ```

1. También puede consultar el DNS desde una instancia de la VPC con `dig`.

   ```
   dig +short myapplication.tutorial
   ```

## Paso 4: Limpiar
<a name="create-service-discovery-cleanup"></a>

Cuando termine este tutorial, debe limpiar los recursos asociados para evitar incurrir en cargos generados por recursos sin utilizar. Siga estos pasos:

1. Anule el registro de las instancias del servicio de descubrimiento de servicios con el ID de servicio y el ID de instancia que anotó con anterioridad.

   ```
   aws servicediscovery deregister-instance \
         --service-id srv-utcrh6wavdkggqtk \
         --instance-id 16becc26-8558-4af1-9fbd-f81be062a266
   ```

   El resultado es el siguiente.

   ```
   {
       "OperationId": "xhu73bsertlyffhm3faqi7kumsmx274n-jh0zimzv"
   }
   ```

1. Con el `OperationId` del resultado del paso anterior, verifique que las instancias de servicio de detección de servicios fueron dadas de baja con éxito.

   ```
   aws servicediscovery get-operation \ 
         --operation-id xhu73bsertlyffhm3faqi7kumsmx274n-jh0zimzv
   ```

   ```
   {
     "Operation": {
           "Id": "xhu73bsertlyffhm3faqi7kumsmx274n-jh0zimzv",
           "Type": "DEREGISTER_INSTANCE",
           "Status": "SUCCESS",
           "CreateDate": 1525984073.707,
           "UpdateDate": 1525984076.426,
           "Targets": {
               "INSTANCE": "16becc26-8558-4af1-9fbd-f81be062a266",
               "ROUTE_53_CHANGE_ID": "C5NSRG1J4I1FH",
               "SERVICE": "srv-utcrh6wavdkggqtk"
           }
       }
   }
   ```

1. Elimine el servicio de detección de servicios mediante el ID de servicio.

   ```
   aws servicediscovery delete-service \ 
         --id srv-utcrh6wavdkggqtk
   ```

1. Elimine el espacio de nombres de detección de servicios mediante el ID del espacio de nombres.

   ```
   aws servicediscovery delete-namespace \ 
         --id ns-uejictsjen2i4eeg
   ```

   El resultado es el siguiente.

   ```
   {
       "OperationId": "c3ncqglftesw4ibgj5baz6ktaoh6cg4t-jh0ztysj"
   }
   ```

1. Con el `OperationId` del resultado del paso anterior, compruebe que el espacio de nombres de la detección de servicios se haya eliminado correctamente.

   ```
   aws servicediscovery get-operation \ 
         --operation-id c3ncqglftesw4ibgj5baz6ktaoh6cg4t-jh0ztysj
   ```

   El resultado es el siguiente.

   ```
   {
       "Operation": {
           "Id": "c3ncqglftesw4ibgj5baz6ktaoh6cg4t-jh0ztysj",
           "Type": "DELETE_NAMESPACE",
           "Status": "SUCCESS",
           "CreateDate": 1525984602.211,
           "UpdateDate": 1525984602.558,
           "Targets": {
               "NAMESPACE": "ns-rymlehshst7hhukh",
               "ROUTE_53_CHANGE_ID": "CJP2A2M86XW3O"
           }
       }
   }
   ```

1. Actualice el recuento deseado para el servicio Amazon ECS para`0`. Debe hacerlo para eliminar el servicio en el siguiente paso.

   ```
   aws ecs update-service \
         --cluster tutorial \
         --service ecs-service-discovery \
         --desired-count 0
   ```

1. Elimine el servicio Amazon ECS.

   ```
   aws ecs delete-service \
         --cluster tutorial \
         --service ecs-service-discovery
   ```

1. Elimine el clúster de Amazon ECS.

   ```
   aws ecs delete-cluster \
         --cluster tutorial
   ```

# Uso de Amazon VPC Lattice para conectar, observar y proteger los servicios de Amazon ECS
<a name="ecs-vpc-lattice"></a>

Amazon VPC Lattice es un servicio de redes de aplicaciones completamente administrado que utilizan los clientes de Amazon ECS para observar, proteger y monitorear las aplicaciones creadas en servicios de computación, VPC y cuentas de AWS sin tener que modificar su código.

VPC Lattice usa grupos de destino, que son un conjunto de recursos de computación. Estos destinos ejecutan la aplicación o servicio y pueden ser instancias de Amazon EC2, direcciones IP, funciones de Lambda y equilibradores de carga de aplicación. Al asociar sus servicios de Amazon ECS a un grupo de destino de VPC Lattice, los clientes ahora pueden habilitar las tareas de Amazon ECS como destinos de IP en VPC Lattice. Amazon ECS registra automáticamente las tareas en el grupo de destino de VPC Lattice cuando se lanzan las tareas del servicio registrado.

**nota**  
Cuando se utilizan cinco configuraciones de VPC Lattice, el tiempo de implementación puede ser un poco más que cuando se utilizan menos configuraciones.

Se utiliza una regla de oyente para reenviar el tráfico a un grupo de destino específico cuando se cumplen las condiciones. Un oyente comprueba las solicitudes de conexión mediante el protocolo en el puerto que haya configurado. Un servicio dirige las solicitudes a sus destinos registrados en función de las reglas que haya definido al configurar el oyente.

Amazon ECS también reemplaza automáticamente una tarea si no funciona correctamente según las comprobaciones de estado de VPC Lattice. Una vez asociados a VPC Lattice, los clientes de Amazon ECS también pueden aprovechar muchas otras características de conectividad, seguridad y observabilidad entre cómputos de VPC Lattice, como la conexión a servicios entre clústeres, VPC y cuentas con AWS Resource Access Manager, integración de IAM para autorización y autenticación y características avanzadas de administración del tráfico.

Los clientes de Amazon ECS pueden beneficiarse de VPC Lattice de las siguientes formas.
+ Aumento de la productividad de los desarrolladores: VPC Lattice aumenta la productividad de los desarrolladores al permitir centrarse en la creación de características, mientras que VPC Lattice gestiona los desafíos de redes, seguridad y observabilidad de manera uniforme en todas las plataformas de computación.
+ Mejor postura de seguridad: VPC Lattice permite a los desarrolladores autenticar y proteger fácilmente la comunicación entre aplicaciones y plataformas de computación, aplicar el cifrado en tránsito y aplicar controles de acceso detallados con políticas de autenticación de VPC Lattice. Esto le permite adoptar una postura de seguridad más sólida que cumpla con los requisitos normativos y de cumplimiento líderes del sector.
+ Mejora de la escalabilidad y resiliencia de las aplicaciones: VPC Lattice le permite crear una red de aplicaciones implementadas con característica como enrutamiento, autenticación, autorización y monitoreo basados en rutas, encabezados y métodos. Estas ventajas se proporcionan sin sobrecargar los recursos de las cargas de trabajo y permiten hacer implementaciones de varios clústeres que generan millones de solicitudes por segundo sin agregar una latencia significativa.
+ Flexibilidad de implementación con una infraestructura heterogénea: VPC Lattice proporciona características uniformes en todos los servicios de computación, como Amazon ECS, Fargate, Amazon EC2, Amazon EKS y Lambda, y le da a su organización la flexibilidad de elegir la infraestructura adecuada para cada aplicación.

## Funcionamiento de VPC Lattice con otros servicios de Amazon ECS
<a name="ecs-lattice-compatibility"></a>

El uso de VPC Lattice con Amazon ECS puede cambiar la forma en que utiliza otros servicios de Amazon ECS, mientras que otros seguirán siendo los mismos.

**Equilibradores de carga de aplicación**  
Ya no es necesario crear un equilibrador de carga de aplicación específico para usarlo con el tipo de grupo de destino del equilibrador de carga de aplicación en VPC Lattice, que luego se vincula al servicio de Amazon ECS. En su lugar, solo tiene que configurar el servicio de Amazon ECS con un grupo de destino de VPC Lattice. También puede optar por utilizar el equilibrador de carga de aplicación con Amazon ECS al mismo tiempo.

**Implementaciones continuas de Amazon ECS**  
Solo las implementaciones continuas de Amazon ECS funcionan con VPC Lattice, y Amazon ECS incorpora las tareas a los servicios y las elimina de forma segura durante la implementación. No se admiten la implementación de código ni las implementaciones azul/verde.

Para obtener más información sobre VPC Lattice, consulte la [Guía del usuario de Amazon VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/what-is-vpc-lattice.html).

# Creación de un servicio que utilice VPC Lattice
<a name="ecs-vpc-lattice-create-service"></a>

Puede usar la Consola de administración de AWS o la AWS CLI para crear un servicio con VPC Lattice.

## Requisitos previos
<a name="create-ecs-vpc-lattice-prereqs"></a>

Antes de empezar este tutorial, asegúrese de que se cumplen los siguientes requisitos previos:
+ La última versión de la AWS CLI está instalada y configurada. Para obtener más información, consulte [Instalación de la AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html).
**nota**  
Puede utilizar puntos de conexión de servicio de doble pila para interactuar con Amazon ECS desde la 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).
+ Los pasos descritos en [Configuración para utilizar Amazon ECS](get-set-up-for-amazon-ecs.md) están completos.
+ 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.

## Creación de un servicio que utiliza VPC Lattice con la Consola de administración de AWS
<a name="ecs-lattice-create-console"></a>

Siga estos pasos para crear un servicio con VPC Lattice mediante la 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, elija **Clústeres**.

1. En la página **Clústeres**, seleccione el clúster en el que va a crear el servicio.

1. En la pestaña **Services** (Servicios), elija **Create** (Crear).

   Si nunca antes ha creado un servicio, siga los pasos que se indican en [Creación de un servicio de Amazon ECS mediante la consola](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-service-console-v2.html) y, a continuación, continúe con estos pasos cuando llegue a la sección de VPC Lattice.

1. Marque el botón para elegir **Activar VPC Lattice**.

1. A fin de utilizar un rol existente para el **rol de infraestructura de ECS para Amazon ECS**, elija uno que ya haya creado para usarlo al crear el grupo de destino de VPC Lattice. Para crear un nuevo rol, **cree un rol de infraestructura de ECS**.

1. Elija la **VPC**.

   La **VPC** depende del modo de red que haya seleccionado al registrar la definición de la tarea. Si utiliza el modo `host` o `network` con EC2, elija su VPC. 

   Si utiliza el modo `awsvpc`, la VPC se selecciona automáticamente en función de la VPC que haya elegido en **Redes** y no se podrá cambiar.

1. En **Grupos de destino**, elija el grupo o grupos de destino. Debe elegir un mínimo de un grupo de destino y un máximo de cinco. Elija **Agregar grupo de destino** para agregar grupos de destino adicionales. Elija el **nombre del puerto**, el **protocolo** y el **puerto** para cada grupo de destino que elija. Para eliminar un grupo de destino, elija **Eliminar**.
**nota**  
Si quiere agregar grupos de destino existentes, debe utilizar la AWS CLI. Para obtener instrucciones sobre cómo agregar grupos de destino mediante la AWS CLI, consulte [register-targets](https://docs.aws.amazon.com/cli/latest/reference/vpc-lattice/register-targets.html) en la *Referencia de AWS Command Line Interface*.
Si bien un servicio de VPC Lattice puede tener varios grupos de destino, cada grupo de destino solo se puede agregar a un servicio.
Para crear un servicio en una configuración de solo IPv6, elija grupos de destino con un tipo de dirección IP de `IPv6`.

1. En este punto, vaya a la consola de VPC Lattice para continuar con la configuración. Aquí es donde se incluyen los nuevos grupos de destino en la acción predeterminada del oyente o en las reglas de un servicio de VPC Lattice existente. 

   Para obtener más información, consulte [Reglas de oyente para el servicio de VPC Lattice](https://docs.aws.amazon.com/vpc-lattice/latest/ug/listener-rules.html).

**importante**  
Debe permitir el prefijo `vpc-lattice` de la regla entrante en su grupo de seguridad o tareas y se puede producir un error en las comprobaciones de estado. 

## Creación de un servicio que utiliza VPC Lattice con la AWS CLI
<a name="ecs-lattice-create-cli"></a>

Utilice la AWS CLI para crear un servicio con VPC Lattice. Reemplace cada *marcador de posición de entrada del usuario* con información propia.

1. Cree un archivo de configuración de grupo de destino. El siguiente ejemplo se denomina `tg-config.json`

   ```
   {
       "ipAddressType": "IPV4",
       "port": 443,
       "protocol": "HTTPS",
       "protocolVersion": "HTTP1",
       "vpcIdentifier": "vpc-f1663d9868EXAMPLE"
   }
   ```

1. Utilice el siguiente comando para crear un grupo de destino de VPC Lattice.

   ```
   aws vpc-lattice create-target-group \
       --name my-lattice-target-group-ip \
       --type IP \
       --config file://tg-config.json
   ```
**nota**  
Para crear un servicio en una configuración de solo IPv6, cree grupos de destino con un tipo de dirección IP de `IPv6`. Para obtener más información, consulte [create-target-group](https://docs.aws.amazon.com/cli/latest/reference/vpc-lattice/create-target-group.html) en la *Referencia de comandos de la AWS CLI*.

   Ejemplo de código de salida:

   ```
   {
       "arn": "arn:aws:vpc-lattice:us-east-2:123456789012:targetgroup/tg-0eaa4b9ab4EXAMPLE",
       "config": {
           "healthCheck": {
               "enabled": true,
               "healthCheckIntervalSeconds": 30,
               "healthCheckTimeoutSeconds": 5,
               "healthyThresholdCount": 5,
               "matcher": {
                   "httpCode": "200"
               },
               "path": "/",
               "protocol": "HTTPS",
               "protocolVersion": "HTTP1",
               "unhealthyThresholdCount": 2
           },
           "ipAddressType": "IPV4",
           "port": 443,
           "protocol": "HTTPS",
           "protocolVersion": "HTTP1",
           "vpcIdentifier": "vpc-f1663d9868EXAMPLE"
       },
       "id": "tg-0eaa4b9ab4EXAMPLE",
       "name": "my-lattice-target-group-ip",
       "status": "CREATE_IN_PROGRESS",
       "type": "IP"
   }
   ```

1. El siguiente archivo JSON denominado *ecs-service-vpc-lattice.json* es un ejemplo que se utiliza para adjuntar un servicio de Amazon ECS a un grupo de destino de VPC Lattice. El `portName` en el ejemplo que aparece a continuación es el mismo que definió en el campo `name` de la propiedad `portMappings` de la definición de la tarea.

   ```
   {
       "serviceName": "ecs-service-vpc-lattice",
       "taskDefinition": "ecs-task-def",
           "vpcLatticeConfigurations": [
           {
               "targetGroupArn": "arn:aws:vpc-lattice:us-west-2:123456789012:targetgroup/tg-0eaa4b9ab4EXAMPLE",
               "portName": "testvpclattice",
               "roleArn": "arn:aws:iam::123456789012:role/ecsInfrastructureRoleVpcLattice"
           }
       ],
       "desiredCount": 5,
       "role": "ecsServiceRole"
   }
   ```

   Utilice el siguiente comando para crear un servicio de Amazon ECS y adjuntarlo al grupo de destino de VPC Lattice mediante el ejemplo de json anterior.

   ```
   aws ecs create-service \
       --cluster clusterName \
       --serviceName ecs-service-vpc-lattice \
       --cli-input-json file://ecs-service-vpc-lattice.json
   ```

**nota**  
VPC Lattice no es compatible con Amazon ECS Anywhere.

# Proteja sus tareas de Amazon ECS para que no se den por terminadas por eventos de reducción horizontal
<a name="task-scale-in-protection"></a>

Puede usar la protección de reducción horizontal de tareas de Amazon ECS para proteger sus tareas y evitar que finalicen 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 ejecuta servidores de juegos como tareas de Amazon ECS que deben seguir ejecutándose 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="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](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="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.
+ La protección de reducción horizontal es compatible con el agente de contenedor de Amazon ECS `1.65.0` o una posterior. Puede agregar compatibilidad con esta característica en instancias de Amazon EC2 que utilizan versiones anteriores del agente de contenedor de Amazon ECS si actualiza el agente a la versión más reciente. Para obtener más información, consulte [Actualización del agente de contenedor de Amazon ECS](ecs-agent-update.md).
+ 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 se aplica una actualización azul/verde, la implementación azul con tareas protegidas no se eliminará si las tareas tienen `protectionEnabled`. El tráfico se desviará a las nuevas tareas que surjan y las tareas más antiguas solo se eliminarán cuando `protectionEnabled` se desactive o caduque. Según el tiempo de espera de las actualizaciones de CodeDeploy o CloudFormation, es posible que se agote el tiempo de espera de la implementación y que las tareas azules más antiguas sigan presentes.
  + 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="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="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="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}'      
```

**Ejemplos de contenedores de Windows**

Para los contenedores de Windows, puede usar el cmdlet `Invoke-RestMethod` de PowerShell en lugar de curl. En los ejemplos siguientes se muestran los equivalentes en PowerShell de los comandos curl anteriores.

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

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

```
Invoke-RestMethod -Uri $env:ECS_AGENT_URI/task-protection/v1/state -Method Put -Body '{"ProtectionEnabled":true}' -ContentType 'application/json'
```

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

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

```
Invoke-RestMethod -Uri $env:ECS_AGENT_URI/task-protection/v1/state -Method Put -Body '{"ProtectionEnabled":true,"ExpiresInMinutes":60}' -ContentType 'application/json'
```

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

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

```
Invoke-RestMethod -Uri $env:ECS_AGENT_URI/task-protection/v1/state -Method Put -Body '{"ProtectionEnabled":true,"ExpiresInMinutes":1440}' -ContentType 'application/json'
```

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="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
```

Para los contenedores de Windows, utilice el siguiente comando de PowerShell para obtener el estado de protección:

```
Invoke-RestMethod -Uri $env:ECS_AGENT_URI/task-protection/v1/state -Method Get
```

```
{
    "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"
  }
}
```

# Utilice la inyección de errores con las cargas de trabajo de Amazon ECS y Fargate
<a name="fault-injection"></a>

Los clientes pueden utilizar la inyección de errores con Amazon ECS tanto en Amazon EC2 como en Fargate para probar de qué manera la aplicación responde a determinados escenarios de deterioro. Estas pruebas proporcionan información útil para optimizar el rendimiento y la resiliencia de la aplicación.

Cuando la inyección de errores está habilitada, el agente de contenedores de Amazon ECS permite que las tareas accedan a nuevos puntos de conexión de inyección de errores. Debe optar por utilizar la inyección de errores. Para ello, configure el valor del parámetro de definición de la tarea `enableFaultInjection` en `true`. El valor predeterminado es `false`. 

```
{
    ...
   "enableFaultInjection": true
}
```

**nota**  
La inyección de errores solo funciona con tareas que utilicen los modos de red `awsvpc` o `host`.  
La inyección de errores no está disponible en Windows.

Para obtener información sobre cómo habilitar la inyección de errores en la Consola de administración de AWS, consulte [Creación de una definición de tarea de Amazon ECS mediante la consola](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-task-definition.html).

Tendrá que habilitar la característica para las pruebas en AWS Fault Injection Service. Para obtener más información, consulte [Uso de las acciones aws:ecs:task de AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/ecs-task-actions.html).

**nota**  
Si no utiliza las nuevas AMI optimizadas para Amazon ECS o tiene una AMI personalizada, instale las siguientes dependencias:  
`tc`
Módulo de kernel de `sch_netem`

# Puntos de conexión de inyección de errores de Amazon ECS
<a name="fault-injection-endpoints"></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. Cada punto de conexión incluye un punto de conexión de `/start`, `/stop` y `/status` Los puntos de conexión solo aceptan solicitudes de tareas que tengan habilitada la inyección de errores, y cada punto de conexión tiene un límite de velocidad de **1** solicitud cada **5** segundos por contenedor. Si se supera el límite, se produce un error.

**nota**  
Se requiere el agente de Amazon ECS `version 1.88.0+` para utilizar los puntos de conexión de inyección de errores.

Los tres puntos de conexión que se utilizan con la inyección de errores son:
+ [Punto de conexión del puerto blackhole de la red](#fis-endpoint-blackhole-ports)
+ [Punto de conexión de pérdida de paquetes de red](#fis-endpoint-packet-loss)
+ [Punto de conexión de latencia de red](#fis-endpoint-latency)

Si la solicitud se realiza correctamente, se obtiene un código de respuesta `200` con un mensaje de `running` cuando se llama al punto de conexión de `/start`, `stopped` para el punto de conexión de `/stop` y `running` o `not-running` para el punto de conexión de `/status`.

```
{
    "Status": <string>
}
```

Si la solicitud no se realiza correctamente, se devuelve uno de los siguientes códigos de error:
+ `400`: solicitud errónea
+ `409`: la solicitud de inyección de errores entra en conflicto con otro error de ejecución
+ `429`: la solicitud se ha limitado
+ `500`: se presentó un error inesperado en el servidor

```
{
	"Error":  <string message> 
}
```

**nota**  
Se puede inyectar un error de latencia de red o un error de pérdida de paquetes de red cada vez. Si se intenta inyectar más de uno, se rechazará la solicitud.

## Punto de conexión del puerto blackhole de la red
<a name="fis-endpoint-blackhole-ports"></a>

El punto de conexión de `{ECS_AGENT_URI}/fault/v1/network-blackhole-port` descarta el tráfico entrante o saliente para un puerto y protocolo específicos en el espacio de nombres de red de una tarea y es compatible con dos modos:
+ **awsvp**: los cambios se aplican al espacio de nombres de la red de la tarea
+ **host**: los cambios se aplican a la instancia de contenedor de espacio de nombres de red predeterminada

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-blackhole-port/start
<a name="fis-endpoint-blackhole-ports-start"></a>

Este punto de conexión inicia las inyecciones de errores en el puerto blackhole de la red y tiene los siguientes parámetros:

**Puerto**  
El puerto especificado que se utilizará para la inyección de errores del puerto blackhole.

Tipo: número entero

Obligatorio: sí

**Protocolo**  
El protocolo que se utilizará para la inyección de errores en el puerto blackhole.

Tipo: cadena

Valores válidos: `tcp | udp`

Obligatorio: sí

**TrafficType**  
El tipo de tráfico que la inyección de errores utiliza.

Tipo: cadena

Valores válidos: `ingress | egress`

Obligatorio: sí

**SourcesToFilter**  
Una matriz JSON de direcciones IPv4 o IPv6 o bloques de CIDR que están protegidos frente al error.

Tipo: matriz de cadenas

Obligatorio: no

A continuación, se muestra un ejemplo de solicitud para utilizar el punto de conexión de `start` (sustituya los valores en *rojo* por valores propios):

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-blackhole-port/start

Http method:POST

Request payload: 
{
    "Port": 1234,
    "Protocol": "tcp|udp",
    "TrafficType": "ingress|egress"
    "SourcesToFilter": ["${IP1}", "${IP2}", ...],
}
```

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-blackhole-port/stop
<a name="fis-endpoint-blackhole-ports-stop"></a>

Este punto de conexión detiene el error especificado en la solicitud. Este punto de conexión tiene los siguientes parámetros:

**Puerto**  
El puerto afectado por el error que se debe detener.

Tipo: número entero

Obligatorio: sí

**Protocolo**  
El protocolo que se utilizará para detener el error.

Tipo: cadena

Valores válidos: `tcp | udp`

Obligatorio: sí

**TrafficType**  
El tipo de tráfico que la inyección de errores utiliza.

Tipo: cadena

Valores válidos: `ingress | egress`

Obligatorio: sí

A continuación, se muestra un ejemplo de solicitud para utilizar el punto de conexión de `stop` (sustituya los valores en *rojo* por valores propios):

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-blackhole-port/stop

Http method: POST

Request payload: 
{
    "Port": 1234,
    "Protocol": "tcp|udp",
    "TrafficType": "ingress|egress", 
}
```

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-blackhole-port/status
<a name="fis-endpoint-blackhole-ports-status"></a>

Este punto de conexión se utiliza para comprobar el estado de la inyección de errores. Este punto de conexión tiene los siguientes parámetros:

**Puerto**  
El puerto afectado para comprobar el estado del error.

Tipo: número entero

Obligatorio: sí

**Protocolo**  
El protocolo que se utilizará al comprobar el estado del error.

Tipo: cadena

Valores válidos: `tcp | udp`

Obligatorio: sí

**TrafficType**  
El tipo de tráfico que la inyección de errores utiliza.

Tipo: cadena

Valores válidos: `ingress | egress`

Obligatorio: sí

A continuación, se muestra un ejemplo de solicitud para utilizar el punto de conexión de `status` (sustituya los valores en *rojo* por valores propios):

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-blackhole-port/status

Http method: POST

Request payload: 
{
   "Port": 1234,
   "Protocol": "tcp|udp",
   "TrafficType": "ingress|egress",
}
```

## Punto de conexión de latencia de red
<a name="fis-endpoint-latency"></a>

El punto de conexión de `{ECS_AGENT_URI}/fault/v1/network-latency` agrega retardo y fluctuación a la interfaz de red de la tarea para el tráfico a determinados orígenes. El punto de conexión es compatible con dos modos:
+ **awsvpc**: los cambios se aplican a la interfaz de red de la tarea
+ **host**: los cambios se aplican a la interfaz de red predeterminada

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-latency/start
<a name="fis-endpoint-latency-start"></a>

Este punto de conexión de `/start` inicia la inyección de errores de latencia de la red y tiene los siguientes parámetros:

**DelayMilliseconds**  
La cantidad de milisegundos de retardo que se agregarán a la interfaz de red que se utilizará para la inyección de errores.

Tipo: número entero

Obligatorio: sí

**JitterMilliseconds**  
La cantidad de milisegundos de fluctuación que se agregarán a la interfaz de red que se utilizará para la inyección de errores.

Tipo: número entero

Obligatorio: sí

**Orígenes**  
Una matriz JSON de direcciones IPv4 o IPv6 o bloques de CIDR que son destino para su uso con inyección de errores.

Tipo: matriz de cadenas

Obligatorio: sí

**SourcesToFilter**  
Una matriz JSON de direcciones IPv4 o IPv6 o bloques de CIDR protegidos frente al error. `SourcesToFilter` tiene prioridad sobre `Sources`.

Tipo: matriz de cadenas

Obligatorio: no

A continuación, se muestra un ejemplo de solicitud para utilizar el punto de conexión de `/start` (sustituya los valores en *rojo* por valores propios):

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-latency/start

Http method: POST

Request payload: 
{
    "DelayMilliseconds": 123,
    "JitterMilliseconds": 123,
    "Sources": ["${IP1}", "${IP2}", ...],
    "SourcesToFilter": ["${IP1}", "${IP2}", ...],
}
```

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-latency/stop and /status
<a name="fis-endpoint-latency-stop-status"></a>

El punto de conexión de `{ECS_AGENT_URI}/fault/v1/network-latency/stop` detiene el error, mientras que `{ECS_AGENT_URI}/fault/v1/network-latency/status` comprueba el estado del error.

Los siguientes son dos ejemplos de solicitudes para utilizar los puntos de conexión de `/stop` y `/status`. Ambos utilizan el método `POST HTTP`.

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-latency/stop
```

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-latency/status
```

## Punto de conexión de pérdida de paquetes de red
<a name="fis-endpoint-packet-loss"></a>

El punto de conexión de `{ECS_AGENT_URI}/fault/v1/network-packet-loss` agrega la pérdida de paquetes a la interfaz de red dada. Este punto de conexión es compatible con dos modos:
+ **awsvpc**: los cambios se aplican a la interfaz de red de la tarea
+ **host**: los cambios se aplican a la interfaz de red predeterminada

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-packet-loss/start
<a name="fis-endpoint-packet-loss-start"></a>

Este punto de conexión de `/start` inicia la inyección de errores de pérdida de paquetes de red y tiene los siguientes parámetros:

**LossPercent**  
El porcentaje de pérdida de paquetes

Tipo: número entero

Obligatorio: sí

**Orígenes**  
Una matriz JSON de direcciones IPv4 o IPv6 o bloques de CIDR a utilizar para las pruebas de inyección de errores.

Tipo: matriz de cadenas

Obligatorio: sí

**SourcesToFilter**  
Una matriz JSON de direcciones IPv4 o IPv6 o bloques de CIDR protegidos frente al error. `SourcesToFilter` tiene prioridad sobre `Sources`.

Tipo: matriz de cadenas

Obligatorio: no

A continuación, se muestra un ejemplo de solicitud para utilizar el punto de conexión de `start` (sustituya los valores en *rojo* por valores propios):

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-packet-loss/start

Http method: POST

{
    "LossPercent": 6,  
    "Sources": ["${IP1}", "${IP2}", ...],
    "SourcesToFilter": ["${IP1}", "${IP2}", ...],
}
```

### \$1ECS\$1AGENT\$1URI\$1/fault/v1/network-packet-loss/stop y /status
<a name="fis-endpoint-packet-loss-stop-status"></a>

El punto de conexión de `{ECS_AGENT_URI}/fault/v1/network-packet-loss/stop` detiene el error, mientras que `{ECS_AGENT_URI}/fault/v1/network-packet-loss/status` comprueba el estado del error. Solo se admite uno de cada tipo de error a la vez.

Los siguientes son dos ejemplos de solicitudes para utilizar los puntos de conexión de `/stop` y `/status`. Ambos utilizan el método `POST HTTP`.

```
Endpoint: ${ECS_AGENT_URI}/fault/v1/network-packet-loss/stop
```

```
Endpoint: ${{ECS_AGENT_URI}/fault/v1/network-packet-loss/status
```

# Actualización de los parámetros de servicio de Amazon ECS
<a name="update-service-parameters"></a>

Después de crear un servicio, hay ocasiones en las que puede que necesite actualizar sus parámetros, por ejemplo, el número de tareas.

Cuando el programador de servicios lanza nuevas tareas, determina la ubicación de ellas en el clúster con la siguiente lógica.
+ Determine cuál de las instancias de contenedor de su clúster puede admitir la definición de tarea de su servicio. Por ejemplo, si tienen la CPU, la memoria, los puertos y los atributos de instancia de contenedor requeridos.
+ De forma predeterminada, el programador de servicios intenta equilibrar las tareas entre las zonas de disponibilidad de esta manera, aunque puede elegir una estrategia de ubicación diferente.
  + Ordene las instancias de contenedor válidas por el número menor de tareas en ejecución para este servicio en la misma zona de disponibilidad que la instancia. Por ejemplo, si la zona A tiene una tarea de servicio en ejecución y las zonas B y C tienen cero cada una, las instancias de contenedor válidas en la zona B o C se consideran óptimas para colocación.
  + Coloque la nueva tarea de servicio en una instancia de contenedor válida en una zona de disponibilidad óptima (basada en los pasos anteriores), favoreciendo las instancias de contenedor con el número más bajo de tareas en ejecución para este servicio.

Cuando el programador de servicios detiene las tareas en ejecución, intenta mantener un balance entre las zonas de disponibilidad del clúster usando la siguiente lógica: 
+ Ordene las instancias de contenedor por el número mayor de tareas en ejecución para este servicio en la misma zona de disponibilidad que la instancia. Por ejemplo, si la zona A tiene una tarea de servicio en ejecución y las zonas B y C tienen dos cada una, las instancias de contenedor en la zona B o C se consideran óptimas para terminación.
+ Pare la tarea en una instancia de contenedor en una zona de disponibilidad óptima (basada en los pasos anteriores), favoreciendo las instancias de contenedor con el número mayor de tareas en ejecución para este servicio.

Use la lista para determinar si puede cambiar el parámetro de servicio.

**Reequilibrio de la zona de disponibilidad**  
Indica si se debe utilizar el reequilibrio de zonas de disponibilidad para el servicio.  
Puede cambiar este parámetro para las implementaciones continuas.

**Estrategia de proveedores de capacidad**  
Los detalles de una estrategia de proveedor de capacidad. Puede establecer un proveedor de capacidad cuando crea un clúster, ejecuta una tarea o actualiza un servicio.  
Cuando usa Fargate, los proveedores de capacidad son `FARGATE` o `FARGATE_SPOT`.  
Cuando utiliza Amazon EC2, los proveedores de capacidad son grupos de escalado automático.  
Puede cambiar los proveedores de capacidad para implementaciones continuas e implementaciones azul/verde.  
En la siguiente lista, se indican las transiciones válidas:  
+ Actualización de Fargate a un proveedor de capacidad de grupo de escalado automático.
+ Actualización EC2 a un proveedor de capacidad de Fargate.
+ Actualización del proveedor de capacidad de Fargate a un proveedor de capacidad de grupo de escalado automático.
+ Actualización del proveedor de capacidad de Amazon EC2 a un proveedor de capacidad de Fargate. 
+ Actualización del grupo de escalado automático o el proveedor de capacidad de Fargate de vuelta al tipo de lanzamiento. Cuando usa la CLI o la API, pasa una lista vacía en el parámetro `capacityProviderStrategy`.

**Clúster**  
No puede modificar el nombre del clúster.

**Configuración de implementación**  
La configuración de implementación incluye las alarmas de CloudWatch y el disyuntor utilizados para detectar fallos, así como la configuración requerida.  
El disyuntor de implementación determina si una implementación de servicio fallará cuando el servicio no pueda alcanzar un estado estable. Si usa el disyuntor de implementación, una implementación de servicio pasará a un estado fallido y dejará de iniciar nuevas tareas. Si usa la opción de restauración, cuando se produce un error en la implementación de un servicio, este se restaura a la última implementación que se haya completado de forma correcta.  
Cuando actualiza un servicio que utiliza un interruptor de Amazon ECS, Amazon ECS crea una implementación y una revisión de servicios. Estos recursos le permiten ver información detallada sobre el historial del servicio. Para obtener más información, consulte [Visualización del historial de servicios mediante las implementaciones de servicios de Amazon ECS](service-deployment.md).  
El programador de servicio utiliza los parámetros de porcentaje máximo y porcentaje mínimo en buen estado (en la configuración de implementación del servicio) para determinar la estrategia de implementación.  
Si un servicio utiliza el tipo de implementación de actualizaciones continuas (`ECS`), el **porcentaje mínimo en buen estado** representa un límite inferior en el número de las tareas en un servicio que deben permanecer en el estado `RUNNING` durante una implementación, como un porcentaje del número de tareas deseado (redondeado al entero superior más próximo). El parámetro también se aplica mientras haya instancias de contenedor en el estado `DRAINING` si el servicio contiene tareas que utilizan EC2. Utilice este parámetro para efectuar implementaciones sin utilizar capacidad de clúster adicional. Por ejemplo, si su servicio tiene un número deseado de cuatro tareas y un porcentaje mínimo de estado del 50 %, el programador puede detener dos tareas existentes para liberar la capacidad del clúster antes de iniciar dos nuevas tareas. El servicio considera que las tareas están en buen estado para servicios que no utilizan un equilibrador de carga si están en el estado `RUNNING`. El servicio considera que las tareas están en buen estado para servicios que no usan un equilibrador de carga si están en el estado `RUNNING` y el equilibrador de carga notifica que están en buen estado. El valor predeterminado del porcentaje mínimo de estado es el 100 %.  
Si un servicio utiliza el tipo de implementación de actualizaciones continuas (`ECS`), el parámetro **porcentaje máximo** representa un límite superior en el número de las tareas en un servicio que pueden permanecer en el estado `PENDING`, `RUNNING` o `STOPPING` durante una implementación, como un porcentaje del número de tareas deseado (redondeado al entero inferior más próximo). El parámetro también se aplica mientras haya instancias de contenedor en el estado `DRAINING` si el servicio contiene tareas que utilizan EC2. Utilice este parámetro para definir el tamaño del lote de implementación. Por ejemplo, si su servicio tiene un número deseado de cuatro tareas y un valor porcentual máximo del 200 %, el programador puede iniciar cuatro nuevas tareas antes de detener las cuatro más antiguas. Esto es siempre que los recursos del clúster requeridos para hacer esto estén disponibles. El valor predeterminado para el porcentaje máximo es el 200 %.  
Cuando el programador de servicio sustituye una tarea durante una actualización, el servicio elimina primero la tarea del balanceador de carga (si se usa) y espera a que las conexiones se vacíen. A continuación, se emite el equivalente de **docker stop** a los contenedores que ejecutan la tarea. Esto da lugar a una señal `SIGTERM` y a un tiempo de espera de 30 segundos, tras el cual se envía `SIGKILL` y los contenedores se paran por la fuerza. Si el contenedor gestiona la señal `SIGTERM` correctamente y sale antes de los 30 segundos de haberla recibido, no se envía la señal `SIGKILL`. El programador de servicio inicia y para tareas definidas por la configuración de porcentaje en buen estado mínimo y porcentaje máximo.  
El programador de servicios también reemplaza las tareas que se determina que están en mal estado después de que se produzca un error en una comprobación de estado del contenedor o en una comprobación de estado del grupo de destino del equilibrador de cargas. Este reemplazo depende de los parámetros de definición del servicio `maximumPercent` y `desiredCount`. Si una tarea está marcada como en mal estado, el programador de servicios iniciará primero una tarea de reemplazo. Luego, ocurrirá lo siguiente.  
+ Si la tarea de reemplazo tiene un estado de `HEALTHY`, el programador de servicios detiene la tarea en mal estado.
+ Si la tarea de reemplazo tiene un estado de `UNHEALTHY`, el programador detendrá la tarea de reemplazo en mal estado o la tarea existente en mal estado para igualar el recuento total de tareas en `desiredCount`.
Si el parámetro `maximumPercent` impide que el programador inicie primero una tarea de reemplazo, detendrá las tareas en mal estado de forma aleatoria de una en una para liberar capacidad y, a continuación, iniciará una tarea de reemplazo. El proceso de inicio y parada continúa hasta que todas las tareas en mal estado se sustituyan por tareas en buen estado. Una vez que se hayan reemplazado todas las tareas en mal estado y solo se estén ejecutando las tareas en buen estado, si el recuento total de tareas supera el límite de `desiredCount`, las tareas en buen estado se detienen aleatoriamente hasta que el recuento total de tareas sea igual a `desiredCount`. Para obtener más información sobre `maximumPercent` y `desiredCount`, consulte [Parámetros de definición de servicios](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html).

**Controlador de implementación**  
El controlador de implementación que utilizar para el servicio. Existen tres tipos de controlador de implementación disponibles:  
+ `ECS`
+ `EXTERNAL`
+ `CODE_DEPLOY`
Al actualizar un servicio, puede actualizar el controlador de implementación que utiliza. En la siguiente lista, se indican las transiciones válidas:  
+ Actualice las implementaciones azul/verde de CodeDeploy (`CODE_DEPLOY`) a las implementaciones continuas o implementaciones azul/verde de ECS (`ECS`).
+ Actualice las implementaciones azul/verde de CodeDeploy (`CODE_DEPLOY`) a las implementaciones externas (`EXTERNAL`).
+ Actualice desde implementaciones continuas de ECS o implementaciones azul/verde (`ECS`) a implementaciones externas (`EXTERNAL`).
+ Actualice desde implementaciones externas (`EXTERNAL`) a implementaciones continuas de ECS o azul/verde (`ECS`).
Tenga en cuenta lo siguiente al actualizar el controlador de implementación de un servicio:  
+ No puede actualizar el controlador de implementación de un servicio desde el controlador de implementación `ECS` a ningún otro controlador si utiliza VPC Lattice o Amazon ECS Service Connect.
+ No puede actualizar el controlador de implementación de un servicio durante una implementación de servicio en curso.
+ No puede actualizar el controlador de implementación de un servicio a `CODE_DEPLOY` si no hay equilibradores de carga en el servicio.
+ No puede actualizar el controlador de implementación de un servicio de `ECS` a ningún otro controlador si la `deploymentConfiguration` incluye alarmas, un interruptor de circuito de implementación o una estrategia de implementación `BLUE_GREEN`. Para obtener más información, consulte [Estrategias y controladores de implementación de servicios de Amazon ECS](ecs_service-options.md).
+ Amazon ECS no utilizará el valor que especifique para `versionConsistency` en la definición del contenedor si actualiza el controlador de implementación del servicio de `ECS` a cualquiera de los demás controladores. 
+ Si actualiza el controlador de implementación de un servicio desde `ECS` a uno de los demás controladores, las respuestas `UpdateService` y `DescribeService` de la API seguirán devolviendo `deployments` en lugar de `taskSets`. Para más información acerca de `UpdateService` y `CreateService`, consulte [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Service.html) y [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Service.html) en la *Referencia de la API de Amazon ECS*.
+ Si un servicio utiliza una estrategia de implementación de actualizaciones continuas, la actualización del controlador de implementación desde `ECS` a cualquiera de los demás controladores cambiará la forma en que el valor `maximumPercent` se utiliza en el `deploymentConfiguration`. En lugar de únicamente limitar el total de tareas en una implementación de actualizaciones continuas, `maximumPercent` se utiliza para reemplazar las tareas que no funcionan correctamente. Para más información sobre cómo el programador sustituye las tareas en mal estado, consulte [Servicios de Amazon ECS](ecs_services.md).
+ Si actualiza el controlador de implementación de un servicio desde `ECS` a uno de los demás controladores de implementación, se ignorará cualquier `advancedConfiguration` que especifique en la configuración del equilibrador de carga. Para más información, consulte [LoadBalancer](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LoadBalancer.html) y [AdvancedConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_AdvancedConfiguration.html) en la *Referencia de la API de Amazon ECS*.
Al actualizar el controlador de implementación de un servicio mediante CloudFormation, tenga en cuenta lo siguiente en función del tipo de migración que vaya a realizar.  
+ Si tiene una plantilla de CloudFormation que contiene la información de controlador de implementación `EXTERNAL` y los recursos `TaskSet` y `PrimaryTaskSet`, y elimina los recursos del conjunto de tareas de la plantilla al actualizar de `EXTERNAL` a `ECS`, las llamadas `DescribeTaskSet` y `DeleteTaskSet` de la API devolverán un error 400 una vez que se actualice el controlador de implementación a `ECS`. Esto provoca un error al eliminar CloudFormation en los recursos del conjunto de tareas, aunque la pila de CloudFormation pase al estado `UPDATE_COMPLETE`. Para más información, consulte [Recurso eliminado de la pila pero no borrado](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors-resource-removed-not-deleted) en la Guía del usuario de AWS CloudFormation. Para solucionar este problema, elimine los conjuntos de tareas directamente mediante la API `DeleteTaskSet` de Amazon ECS. Para más información sobre cómo eliminar un conjunto de tareas, consulte [DeleteTaskSet](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DeleteTaskSet.html) en la *Referencia de la API* de *Amazon Elastic Container Service*.
+ Si está migrando de `CODE_DEPLOY` a `ECS` con una nueva definición de tarea y CloudFormation realiza una operación de reversión, la solicitud `UpdateService` de Amazon ECS falla y muestra el siguiente error:

  ```
  Resource handler returned message: "Invalid request provided: Unable to update 
  task definition on services with a CODE_DEPLOY deployment controller. Use AWS 
  CodeDeploy to trigger a new deployment. (Service: Ecs, Status Code: 400, 
  Request ID: 0abda1e2-f7b3-4e96-b6e9-c8bc585181ac) (SDK Attempt Count: 1)" 
  (RequestToken: ba8767eb-c99e-efed-6ec8-25011d9473f0, HandlerErrorCode: InvalidRequest)
  ```
+ Tras una migración correcta de `ECS` a un controlador de implementación `EXTERNAL`, debe eliminar manualmente el conjunto de tareas `ACTIVE`, ya que Amazon ECS ya no administra la implementación. Para obtener información acerca de cómo eliminar un conjunto de tareas, consulte [DeleteTaskSet](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_DeleteTaskSet.html) en la *Referencia de la API* de Amazon Elastic Container Service.

**Recuento deseado de tareas**  
El número de instancias de la tarea para ubicar y seguir ejecutando en el servicio.  
Si desea detener temporalmente el servicio, establezca este valor en 0. A continuación, cuando lo tenga todo listo para iniciar el servicio, actualícelo con el valor original.  
Puede cambiar este parámetro para las implementaciones continuas y las implementaciones azul/verde.

**Habilitación de las etiquetas administradas**  
Determina si se activan las etiquetas administradas por Amazon ECS para las tareas del servicio.  
Solo reflejarán la actualización las tareas iniciadas después de que se realice. Para actualizar las etiquetas de todas las tareas, use la opción de implementación forzada.  
Puede cambiar este parámetro para las implementaciones continuas y las implementaciones azul/verde.

**Habilitación de ECS Exec**  
Determina si se utiliza Amazon ECS Exec.  
Si no desea anular el valor que se estableció cuando se creó el servicio, puede establecerlo en “null” al realizar esta acción.  
Puede cambiar este parámetro para las implementaciones continuas.

**Periodo de gracia de la comprobación de estado**  
El periodo de tiempo, en segundos, que el programador de servicio de Amazon ECS ignora las comprobaciones de estado en mal estado de Elastic Load Balancing, VPC Lattice y del contenedor después de que se haya iniciado una tarea por primera vez. Si no se especifica ningún valor para el periodo de gracia de comprobación de estado, se utiliza el valor predeterminado `0`. Si no se utiliza ninguna de las comprobaciones de estado, entonces `healthCheckGracePeriodSeconds` no se utilizará.  
Si las tareas del servicio tardan mucho en iniciarse y en responder a las comprobaciones de estado, se puede especificar un periodo de gracia de hasta 2 147 483 647 segundos (aproximadamente 69 años). Durante este periodo, el programador de servicio de Amazon ECS hará caso omiso del resultado de las comprobaciones de estado. Este periodo de gracia puede evitar que el programador de servicio interprete que las tareas están en mal estado y las detenga antes de que tengan tiempo de iniciarse.  
Puede cambiar este parámetro para las implementaciones continuas y las implementaciones azul/verde.

**Equilibradores de carga**  
Debe utilizar un rol vinculado a un servicio al actualizar un equilibrador de carga.  
Una lista de objetos de equilibrador de carga de Elastic Load Balancing. Contiene el nombre del equilibrador de carga, el nombre del contenedor y el puerto del contenedor para acceder desde el equilibrador de carga. El nombre del contenedor es el que aparece en una definición de contenedor.  
Amazon ECS no actualiza automáticamente los grupos de seguridad asociados a los balanceadores de carga de Elastic Load Balancing ni a las instancias de contenedor de Amazon ECS.  
Cuando agrega, actualiza o elimina una configuración de equilibrador de carga, Amazon ECS inicia nuevas tareas con la configuración actualizada de Elastic Load Balancing y detiene las tareas antiguas cuando se ejecutan las nuevas.  
Para los servicios que utilizan actualizaciones continuas, puede agregar, actualizar o eliminar grupos de destino de Elastic Load Balancing. Puede actualizar de un único grupo de destino a varios grupos de destino y de varios grupos de destino a un único grupo de destino.  
Para los servicios que utilizan implementaciones azul/verde, puede actualizar los grupos de destino de Elastic Load Balancing mediante `[CreateDeployment](https://docs.aws.amazon.com/codedeploy/latest/APIReference/API_CreateDeployment.html)` a través de CodeDeploy. Tenga en cuenta que no se admiten varios grupos de destino en las implementaciones azul/verde. Para obtener más información, consulte [Registrar varios grupos de destino con un servicio](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/register-multiple-targetgroups.html).   
Para los servicios que utilizan el controlador de implementación externo, puede agregar, actualizar o eliminar equilibradores de carga mediante [CreateTaskSet](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateTaskSet.html). Tenga en cuenta que no se admiten varios grupos de destino en las implementaciones externas. Para obtener más información, consulte [Registrar varios grupos de destino con un servicio](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/register-multiple-targetgroups.html).   
Pase una lista vacía para eliminar los equilibradores de carga.  
Puede cambiar este parámetro para las implementaciones continuas.

**Configuración de red**  
La configuración de red del servicio.   
Puede cambiar este parámetro para las implementaciones continuas.

**Restricciones para la ubicación**  
Una matriz de objetos de restricción de ubicación de la tarea para actualizar el servicio que se usará. Si no se especifica ningún valor, las restricciones de ubicación existentes para el servicio permanecerán sin cambios. Si se especifica este valor, anulará cualquier restricción de ubicación existente definida para el servicio. Para eliminar todas las restricciones de ubicación existentes, especifique una matriz vacía.  
Puede especificar 10 restricciones como máximo para cada tarea. Este límite incluye las restricciones en la definición de tareas y las especificadas en el tiempo de puesta en marcha.  
Puede cambiar este parámetro para las implementaciones continuas y las implementaciones azul/verde.

**Estrategias de ubicación**  
Los objetos de la estrategia de colocación de tareas para actualizar el servicio que se usará. Si no se especifica ningún valor, la estrategia de ubicación existente para el servicio permanecerá sin cambios. Si se especifica este valor, anulará la estrategia de ubicación existente definida para el servicio. Para eliminar una estrategia de ubicación existente, especifique un objeto vacío.  
Puede cambiar este parámetro para las implementaciones continuas y las implementaciones azul/verde.

**Versión de la plataforma**  
La versión de la plataforma Fargate en la que se ejecuta su servicio.  
Un servicio que utiliza una versión de la plataforma Linux no se puede actualizar para utilizar una versión de la plataforma Windows y viceversa.  
Puede cambiar este parámetro para las implementaciones continuas.

**Propagación de etiquetas**  
Determina si se deben propagar las etiquetas de la definición de tareas o el servicio para la tarea. Si no se especifica ningún valor, las etiquetas no se propagan.  
Solo reflejarán la actualización las tareas iniciadas después de que se realice. Para actualizar las etiquetas de todas las tareas, configure `forceNewDeployment` en `true`, de modo que Amazon ECS inicie nuevas tareas con las etiquetas actualizadas.  
Puede cambiar este parámetro para las implementaciones continuas y las implementaciones azul/verde.

**Configuración de Service Connect**  
La configuración de Amazon ECS Service Connect. Este parámetro determina cómo se conecta el servicio a otros servicios de la aplicación.  
Puede cambiar este parámetro para las implementaciones continuas.

**Registros de servicios**  
Debe utilizar un rol vinculado a un servicio al actualizar los registros de servicios.  
Los detalles de los registros de detección de servicios que se deben asignar a este servicio. Para obtener más información, consulte [Detección de servicios](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html).  
Cuando agrega, actualiza o elimina la configuración de los registros de servicio, Amazon ECS inicia nuevas tareas con la configuración actualizada de los registros de servicio y detiene las tareas antiguas cuando se ejecutan las nuevas.  
Pase una lista vacía para eliminar los registros de servicios.  
Puede cambiar este parámetro para las implementaciones continuas.

**Definición de tarea**  
La definición y la revisión de la tarea que se va a utilizar en el servicio.  
Si cambia los puertos utilizados por los contenedores en una definición de tarea, es posible que tenga que actualizar los grupos de seguridad de las instancias del contenedor para que funcionen con los puertos actualizados.  
Si actualiza la definición de la tarea del servicio, el nombre y el puerto del contenedor que se especificaron en la configuración del equilibrador de carga deben permanecer en la definición de la tarea.   
El comportamiento de extracción de imágenes del contenedor varía según las opciones de computación. Para obtener más información, consulte una de las siguientes:  
+ [Arquitectura para AWS Fargate Amazon ECS](AWS_Fargate.md)
+ [Arquitectura para la capacidad de EC2 para Amazon ECS](launch-type-ec2.md)
+ [Instancias externas (Amazon ECS Anywhere) para Amazon ECS](launch-type-external.md)
Puede cambiar este parámetro para las implementaciones continuas.

**Configuraciones de volúmenes**  
Los detalles del volumen que era `configuredAtLaunch`. Cuando `configuredAtLaunch` se establece como `true` en la definición de la tarea, este parámetro de servicio configura un volumen de Amazon EBS para cada tarea del servicio que se va a crear y adjuntar durante la implementación. Puede configurar el tamaño, el volumeType, el IOPS, el rendimiento, las instantáneas y el cifrado en [ServiceManagedEBSVolumeConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ServiceManagedEBSVolumeConfiguration.html). El `name` del volumen debe coincidir con el `name` de la definición de la tarea. Si se establece como nulo, no se activa ninguna nueva implementación. De lo contrario, si esta configuración difiere de la existente, se activa una nueva implementación.  
Puede cambiar este parámetro para las implementaciones continuas.

**Configuración de VPC Lattice**  
La configuración de VPC Lattice para su servicio. Esto define la forma en que su servicio se integra con VPC Lattice para la comunicación de servicio a servicio.  
Puede cambiar este parámetro para las implementaciones continuas.

## AWS CDKConsideraciones sobre
<a name="cdk-considerations"></a>

El AWS CDK no rastrea los estados de los recursos. No sabe si está creando o actualizando un servicio. Los clientes deben usar la escotilla de escape para acceder directamente al constructo ecs `Service` L1. 

Para obtener información sobre las escotillas de escape, consulte [Personalice los constructos desde la Biblioteca de constructos de AWS](https://docs.aws.amazon.com/cdk/v2/guide/cfn-layer.html#develop-customize-escape) en la *Guía para desarrolladores de AWS Cloud Development Kit (AWS CDK) v2*. 

Para migrar su servicio existente al constructo `ecs.Service`, haga lo siguiente:

1. Use la escotilla de escape para acceder al constructo `Service` L1. 

1. Establezca manualmente las siguientes propiedades en el constructo `Service` L1. 

   Si su servicio utiliza capacidad de Amazon EC2:
   + `daemon?`
   + `placementConstraints?`
   + `placementStrategies?`
   + Si utiliza el modo de red `awsvpc`, debe configurar los constructos `vpcSubnets?` y `securityGroups?`.

   Si su servicio usa Fargate:
   + `FargatePlatformVersion`
   + Los constructos `vpcSubnets?` y `securityGroups?`.

1. Configure el `launchType` como se indica a continuación:

   ```
   const cfnEcsService = service.node.findChild('Service') as ecs.CfnService;
   cfnEcsService.launchType = "FARGATE";
   ```

Para migrar de un tipo de lanzamiento a un proveedor de capacidad, haga lo siguiente:

1. Use la escotilla de escape para acceder al constructo `Service` L1. 

1. Agregue el constructo `capacityProviderStrategies?`.

1. Implemente el servicio.

# Actualización de un servicio de Amazon ECS
<a name="update-service-console-v2"></a>

Después de crear un servicio, hay ocasiones en las que puede que necesite actualizar sus parámetros, por ejemplo, el número de tareas.

Cuando actualiza un servicio que utiliza un interruptor de Amazon ECS, Amazon ECS crea una implementación y una revisión de servicios. Estos recursos le permiten ver información detallada sobre el historial del servicio. Para obtener más información, consulte [Visualización del historial de servicios mediante las implementaciones de servicios de Amazon ECS](service-deployment.md).

## Requisitos previos
<a name="update-service-prerequisites"></a>

Antes de actualizar un servicio, compruebe qué parámetros del servicio se pueden cambiar para su tipo de implementación. Para obtener una lista completa de parámetros que se pueden modificar, consulte [Actualización de los parámetros de servicio de Amazon ECS](update-service-parameters.md).

## Procedimiento
<a name="update-service-procedure"></a>

------
#### [ Console ]

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 de detalles del clúster, en la sección **Servicios**, seleccione la casilla de verificación situada junto al servicio y, a continuación, seleccione **Actualizar**.

1. Para que su servicio inicie una nueva implementación, seleccione **Force new deployment** (Forzar una nueva implementación).

1. En **Definición de tareas**, elija la familia y la revisión de definiciones de tareas.
**importante**  
La consola valida que la familia y la revisión de definiciones de tareas seleccionadas sean compatibles con la configuración de cómputos definida. Si recibe una advertencia, compruebe la compatibilidad de la definición de tarea y la configuración de cómputos seleccionada.

1. Si eligió **Replica** (Réplica), en **Desired tasks** (Tareas deseadas), ingrese el número de tareas que se lanzarán y mantendrán en el servicio.

1. Si eligió **Réplica** para que Amazon ECS supervise la distribución de las tareas entre las zonas de disponibilidad y las redistribuya cuando haya un desequilibrio, en **Reequilibrio del servicio de zonas de disponibilidad**, seleccione **Reequilibrio del servicio de zonas de disponibilidad**.

1. En **Max running tasks** (Máximo de tareas en ejecución), ingrese el límite máximo del número de tareas del servicio que se permiten en el estado `RUNNING` durante una implementación, como porcentaje del número de tareas deseado del servicio (redondeado al entero inferior más próximo). Para obtener más información, consulte [Configuración de la implementación](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html#sd-deploymentconfiguration).

1. En **Max running tasks** (Máximo de tareas en ejecución), ingrese el límite máximo del número de tareas del servicio que se permiten en el estado `RUNNING` o `PENDING` durante una implementación, como porcentaje del número de tareas deseado del servicio (redondeado al entero inferior más próximo).

1. Para configurar cómo se implementan las tareas para su servicio, expanda **Opciones de implementación** y, a continuación, configure sus opciones.

   1. En **Tipo de controlador de implementación**, especifique el controlador de implementación del servicio. La consola de Amazon ECS admite los siguientes tipos de controladores: `ECS`.

   1. En **Estrategia de implementación**, elija la estrategia que haya utilizado Amazon ECS para implementar nuevas versiones del servicio.

   1. Dependiendo de la **estrategia de implementación** que elija, haga lo siguiente:    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/update-service-console-v2.html)

   1. Para ejecutar las funciones de Lambda en una etapa del ciclo de vida, en **Enlaces de ciclo de vida de la implementación**, haga lo siguiente para cada función de Lambda única:

      1. Elija **Agregar**.

         Repita este procedimiento para cada función única que desee ejecutar.

      1. En **Función de Lambda**, ingrese el nombre de la función.

      1. En **Rol**, elija el rol que creó en los requisitos previos con los permisos azul/verde.

         Para obtener más información, consulte [Permisos necesarios para las funciones de Lambda en las implementaciones azul/verde de Amazon ECS](blue-green-permissions.md).

      1. En **Etapas del ciclo de vida**, seleccione las etapas que ejecuta la función de Lambda.

      1.  (Opcional) En **Detalles del enlace**, introduzca un par clave-valor que proporcione información sobre el enlace.

1. Para configurar el modo en que Amazon ECS detecta y gestiona los errores de implementación, expanda **Deployment failure detection** (Detección de errores de implementación) y, a continuación, elija sus opciones. 

   1. Para detener una implementación cuando las tareas no puedan iniciarse, seleccione **Use the Amazon ECS deployment circuit breaker** (Utilizar el interruptor de circuito de implementación de Amazon ECS).

      Para que el software restaure automáticamente la implementación a su último estado completado cuando el disyuntor de implementación establezca un estado con error, seleccione **Restauración en caso de error**.

   1. Para detener una implementación en función de las métricas de la aplicación, seleccione **Use CloudWatch alarms**. A continuación, elija las alarmas en **Nombre de la alarma de CloudWatch**. Para crear una alarma nueva, vaya a la consola de CloudWatch.

      Para que el software restaure automáticamente la implementación a su último estado de implementación completada cuando una alarma de CloudWatch establezca un estado con error, seleccione **Restauración en caso de error**.

1. Para cambiar las opciones de computación, expanda **Configuración de computación** y, a continuación, haga lo siguiente: 

   1. Para los servicios en AWS Fargate, en **Platform version** (Versión de la plataforma), elija la nueva versión.

   1. Para los servicios que utilizan una estrategia de proveedor de capacidad, en **Estrategia de proveedor de capacidad**, haga lo siguiente:
      + Para agregar un proveedor de capacidad adicional, seleccione **Agregar más**. A continuación, en **Proveedor de capacidad**, seleccione el proveedor de capacidad.
      + Para eliminar un proveedor de capacidad, a la derecha del proveedor de capacidad, seleccione **Eliminar**.

      Un servicio que utiliza un proveedor de capacidad de grupos de escalado automático no se puede actualizar para que utilice un proveedor de capacidad de Fargate. Un servicio que utiliza un proveedor de capacidad de Fargate no puede actualizarse para utilizar un proveedor de capacidad de grupo de escalado automático.

1. (Opcional) Para configurar el escalado automático de servicios, expanda **Escalado automático de servicios** y, a continuación, especifique los siguientes parámetros. Para utilizar el escalado automático predictivo, que analiza los datos de cargas anteriores de los flujos de tráfico, configúrelo después de crear el servicio. Para obtener más información, consulte [Uso de patrones históricos para escalar los servicios de Amazon ECS con escalado predictivo](predictive-auto-scaling.md).

   1. Para utilizar el escalado automático de servicios, seleccione **Service auto scaling** (Escalado automático de servicios).

   1. En **Cantidad mínima de tareas**, ingrese el límite mínimo del número de tareas que se va a utilizar para el escalado automático del servicio. El recuento deseado no será inferior a este recuento.

   1. En **Cantidad máxima de tareas**, ingrese el límite máximo del número de tareas que se va a utilizar para el escalado automático del servicio. El recuento deseado no será superior a este recuento.

   1. Elija el tipo de política. En **Tipo de política de escalado**, elija una de las siguientes opciones.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/update-service-console-v2.html)

1. (Opcional) Para usar Service Connect, seleccione **Turn on Service Connect** (Activar Service Connect) y, a continuación, especifique lo siguiente:

   1. En **Service Connect configuration** (Configuración de Service Connect), especifique el modo cliente.
      + Si su servicio ejecuta una aplicación cliente de red que solo necesita conectarse a otros servicios del espacio de nombres, elija **Solo en el lado del cliente**.
      + Si su servicio ejecuta una aplicación de servicio web o red y necesita proporcionar puntos de conexión para este servicio y se conecta a otros servicios del espacio de nombres, elija **Client and server** (Cliente y servidor).

   1. Para usar un espacio de nombres que no sea el espacio de nombres predeterminado del clúster, en **Namespace** (Espacio de nombres), elija el espacio de nombres del servicio. Puede ser un espacio de nombres creado por separado en la misma Región de AWS de su Cuenta de AWS o un espacio de nombres en la misma región que se comparta con su cuenta mediante AWS Resource Access Manager (AWS RAM). Para obtener más información sobre los espacios de nombres de AWS Cloud Map compartidos, consulte [Cross-account AWS Cloud Map namespace sharing](https://docs.aws.amazon.com/cloud-map/latest/dg/sharing-namespaces.html) en la *Guía para desarrolladores de AWS Cloud Map*.

   1. (Opcional) Especifique una configuración de registro. Seleccione **Utilizar colección de registros**. La opción predeterminada envía registros de contenedor a los Registros de CloudWatch. Las demás opciones del controlador de registro se configuran mediante AWS FireLens. Para obtener más información, consulte [Envío de registros de Amazon ECS a un servicio de AWS o AWS Partner](using_firelens.md).

      A continuación, se describe con más detalle cada uno de los destinos de registro de contenedor.
      + **Amazon CloudWatch**: configure la tarea para enviar registros de contenedor a CloudWatch Logs. Se proporcionan las opciones de controlador de registro predeterminadas que crean un grupo de registros de CloudWatch en su nombre. Para especificar otro nombre de grupo de registros, cambie los valores de las opciones del controlador.
      + **Amazon Data Firehose**: configure la tarea para enviar registros de contenedor a Firehose. Se proporcionan las opciones de controlador de registro predeterminadas que envían registros a un flujo de entrega de Firehose. Para especificar un nombre de flujo de entrega distinto, cambie los valores de las opciones del controlador.
      + **Amazon Kinesis Data Streams**: configure la tarea para enviar registros de contenedores a Kinesis Data Streams. Se proporcionan las opciones de controlador de registro predeterminadas que envían registros a un flujo de Kinesis Data Streams. Para especificar otro nombre de transmisión, cambie los valores de las opciones del controlador.
      + **Amazon OpenSearch Service**: configure la tarea para enviar registros de contenedor a un dominio de OpenSearch Service. Se deben proporcionar las opciones del controlador de registros. 
      + **Amazon S3**: configure la tarea para enviar registros de contenedor a un bucket de Amazon S3. Se proporcionan las opciones de controlador de registro predeterminadas, pero debe especificar un nombre de bucket de Amazon S3 válido.

   1. Para habilitar los registros de acceso, siga estos pasos:

      1. Amplíe **Configuración del registro de acceso**. En **Formato**, elija **JSON** o `TEXT`.

      1. Para incluir los parámetros de consulta en los registros de acceso, seleccione **Incluir parámetros de consulta**.
**nota**  
Para deshabilitar los registros de acceso, en **Formato**, seleccione **Ninguno**.

1. Si su tarea usa un volumen de datos compatible con la configuración en el momento de la implementación, puede expandir **Volume** para configurar el volumen.

   El nombre y el tipo de volumen se configuran cuando crea una revisión de la definición de la tarea y no se pueden cambiar cuando se actualiza un servicio. Para actualizar el nombre y el tipo de volumen, debe crear una nueva revisión de la definición de la tarea y actualizar el servicio con la nueva revisión.    
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/AmazonECS/latest/developerguide/update-service-console-v2.html)

1. (Opcional) Para ayudar a identificar su servicio, expanda la sección **Tags** (Etiquetas) y, a continuación, configure sus etiquetas.
   + [Agregar una etiqueta] Elija **Agregar etiqueta** y haga lo siguiente:
     + En **Clave**, escriba el nombre de la clave.
     + En **Valor**, escriba el valor de la clave.
   + [Eliminar una etiqueta] Junto a la etiqueta, elija **Remove tag (Quitar etiqueta)**.

1. Elija **Actualizar**.

------
#### [ AWS CLI ]
+ Ejecuta `update-service`. Para obtener información sobre la ejecución del comando, consulte [update-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html) en la Referencia de AWS Command Line Interface. 

  En el siguiente ejemplo de `update-service`, se actualiza el recuento de tareas deseado del servicio `my-http-service` a 2.

  Sustituya las *entradas del usuario* por sus valores.

  ```
  aws ecs update-service \
      --cluster MyCluster \
      --service my-http-service \
      --desired-count 2
  ```

------

## Siguientes pasos
<a name="update-service-next-steps"></a>

Haga un seguimiento de la implementación y consulte el historial de los servicios que utiliza el interruptor de Amazon ECS. Para obtener más información, consulte [Visualización del historial de servicios mediante las implementaciones de servicios de Amazon ECS](service-deployment.md).

# Actualización de un servicio de Amazon ECS para utilizar un proveedor de capacidad
<a name="update-service-managed-instances"></a>

Si tiene un servicio existente que usa el tipo de inicialización de Amazon EC2 o Fargate y quiere usar instancias administradas de Amazon ECS, debe actualizar el servicio para usar el proveedor de capacidad de instancias administradas de Amazon ECS.

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

Cree un proveedor de capacidad para instancias administradas de Amazon ECS. Para obtener más información, consulte [Creación de un proveedor de capacidad de instancias administradas de Amazon ECS](create-capacity-provider-managed-instances.md).

## Procedimiento
<a name="update-service-managed-instances-procedure"></a>

------
#### [ Console ]

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 de detalles del clúster, en la sección **Servicios**, seleccione la casilla de verificación situada junto al servicio y, a continuación, seleccione **Actualizar**.

1. Seleccione **Forzar una nueva implementación**.

1. En **Configuración de computación**, elija la estrategia del proveedor de capacidad. A continuación, elija una de las siguientes opciones:
   + Si el proveedor de capacidad de instancias administradas de Amazon ECS es el proveedor de capacidad predeterminado, elija **Utilizar clúster predeterminado**.
   + Si el proveedor de capacidad de instancias administradas de Amazon ECS no es el proveedor de capacidad predeterminado, elija **Utilizar personalizado (avanzado)**. Seleccione el proveedor de capacidad de instancias administradas de Amazon ECS y, a continuación, en **Peso**, seleccione 1.

1. Elija **Actualizar**.

------
#### [ AWS CLI ]
+ Ejecuta `update-service`. Para obtener información sobre la ejecución del comando, consulte [update-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html) en la Referencia de AWS Command Line Interface. 

  Sustituya las *entradas del usuario* por sus valores.

  ```
  aws ecs update-service \
      --cluster my-cluster \
      --service my-service \
      --capacity-provider-strategy capacityProvider=my-managed-instance-capacity-provider,weight=1 \
      --force-new-deployment
  ```

------

# Eliminación de un servicio de Amazon ECS mediante la consola
<a name="delete-service-v2"></a>

Los siguientes son algunos de los motivos por los que eliminaría un servicio:
+ Ya no se necesita la aplicación
+ Va a migrar el servicio a un nuevo entorno
+ La aplicación no se utiliza activamente
+ La aplicación utiliza más recursos de los necesarios y usted está intentando optimizar sus costos

El servicio se reduce verticalmente a cero de forma automática antes de eliminarse. Los recursos del equilibrador de carga o la detección del servicio con recursos asociados al servicio no se ven afectados por la eliminación del servicio. Para eliminar los recursos de Elastic Load Balancing, consulte uno de los siguientes temas, según el tipo de balanceador de carga: [Eliminación de un Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-delete.html) o [Eliminación de un Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-delete.html). 

Al eliminar un servicio, Amazon ECS elimina todas las implementaciones y revisiones del servicio.

Cuando se elimina un servicio, si todavía hay tareas en ejecución que requieren limpieza, el estado del servicio pasa de `ACTIVE` a `DRAINING` y deja de estar visible en la consola o en la operación de la API de `ListServices`. Unas vez que las tareas tengan el estado `STOPPING` o `STOPPED`, el estado del servicio cambia de `DRAINING` a `INACTIVE`. Los servicios en el estado `DRAINING` o `INACTIVE` se pueden seguir viendo la operación `DescribeServices` de la API. 

**importante**  
Si intenta crear un nuevo servicio con el mismo nombre que un servicio existente en cualquiera de los estados `ACTIVE` o `DRAINING`, recibirá un mensaje de error.

**Procedimiento**

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), seleccione el clúster para el servicio.

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

1. En la página de **Cluster: *name*** (Clúster: nombre), elija la pestaña de **Services** (Servicios). 

1. Seleccione los servicios y, a continuación, elija **Delete** (Eliminar).

1. Para eliminar un servicio aunque no se haya reducido a cero tareas, seleccione **Force delete service** (Forzar la eliminación del servicio).

1. En la pregunta de confirmación, escriba **delete** (eliminar) y, a continuación, elija **Eliminar**. 

# Migración de un ARN de servicio corto de Amazon ECS a un ARN largo
<a name="service-arn-migration"></a>

Amazon ECS asigna un nombre de recurso de Amazon (ARN) único a cada servicio. Los servicios que se crearon antes de 2021 tienen un formato de ARN corto:

 `arn:aws:ecs:region:aws_account_id:service/service-name`

Amazon ECS cambió el formato del ARN para incluir el nombre del clúster. Este es un formato de ARN largo:

`arn:aws:ecs:region:aws_account_id:service/cluster-name/service-name`

Su servicio debe tener el formato de ARN largo para poder etiquetarlo. 

Puede migrar un servicio con un formato de ARN corto al formato de ARN largo sin tener que volver a crear el servicio. Puede utilizar la API, la CLI o la consola. No puede deshacer una operación de migración.

El proceso de migración es fluido y garantiza que su servicio no tenga ningún tiempo de inactividad. Durante la migración:
+ **Disponibilidad del servicio**: su servicio sigue funcionando con normalidad sin interrumpir el tráfico ni la funcionalidad.
+ **Tareas en ejecución**: las tareas existentes siguen ejecutándose sin interrupciones. Las nuevas tareas que se inicien después de la migración utilizarán el formato de ARN largo si la configuración de la cuenta `taskLongArnFormat` está habilitada.
+ **Instancias de contenedor**: las instancias de contenedor no se ven afectadas por la migración del ARN del servicio y siguen funcionando con normalidad.
+ **Configuración del servicio**: todos los ajustes del servicio, incluidas las configuraciones de definición de tareas, redes y equilibrador de carga permanecen sin cambios.

Si desea utilizar CloudFormation para etiquetar un servicio con un formato de ARN corto, debe migrar el servicio mediante la API, la CLI o la consola. Una vez completada la migración, puede usar CloudFormation para etiquetar el servicio.

Si desea utilizar Terraform para etiquetar un servicio con un formato de ARN corto, debe migrar el servicio mediante la API, la CLI o la consola. Una vez completada la migración, puede usar Terraform para etiquetar el servicio.

Después de completar la migración, el servicio presenta los siguientes cambios:
+ Formato de ARN largo

  `arn:aws:ecs:region:aws_account_id:service/cluster-name/service-name`
+ Al migrar mediante la consola, Amazon ECS agrega una etiqueta al servicio con la clave establecida en “ecs:serviceArnMigratedAt” y el valor establecido en la marca de tiempo de la migración (formato UTC).

  Esta etiqueta se tiene en cuenta para su cuota de etiquetas.
+ Cuando el valor de `PhysicalResourceId` en una pila de CloudFormation representa un ARN de servicio, el valor no cambia y seguirá siendo el ARN de servicio corto. 

## Requisitos previos
<a name="migrate-service-arn-prerequisite"></a>

Realice las siguientes operaciones antes de migrar el ARN de servicio.

1. Para comprobar si tiene un ARN de servicio corto, consulte los detalles del servicio en la consola de Amazon ECS (verá una advertencia cuando el servicio tenga el formato de ARN corto) o el parámetro de devolución `serviceARN` de `describe-services`. Si el ARN no incluye el nombre del clúster, tiene un ARN corto. A continuación se muestra el formato de un ARN corto:

    `arn:aws:ecs:region:aws_account_id:service/service-name`

1. Tenga en cuenta la fecha de creación.

1.  Si tiene políticas de IAM que utilizan el formato de ARN corto, actualícelas al formato de ARN largo.

   Reemplace cada *marcador de posición de entrada del usuario* con información propia.

    `arn:aws:ecs:region:aws_account_id:service/cluster-name/service-name`

   Para obtener más información, consulta [Políticas de IAM de edición](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html) en la *Guía del usuario de AWS Identity and Access Management*.

1.  Si tiene herramientas que utilizan el formato de ARN corto, actualícelas al formato de ARN largo.

   Reemplace cada *marcador de posición de entrada del usuario* con información propia.

    `arn:aws:ecs:region:aws_account_id:service/cluster-name/service-name`

1. Active el formato de ARN largo del servicio. Ejecute `put-account-setting` con la opción `serviceLongArnFormat` establecida en `enabled`. Para obtener más información, consulte [put-account-setting](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting.html) en la *Referencia de la API de Amazon Elastic Container Service*.

   Ejecute el comando como Usuario raíz cuando el servicio tenga un valor de fecha desconocido para `createdAt`.

   ```
   aws ecs put-account-setting --name serviceLongArnFormat --value enabled
   ```

   Ejemplo de resultado

   ```
   {
       "setting": {
           "name": "serviceLongArnFormat",
           "value": "enabled",
           "principalArn": "arn:aws:iam::123456789012:role/your-role",
           "type": user
       }
   }
   ```

1. Active el formato de ARN largo de la tarea. Esta configuración de cuenta controla el formato de ARN de las nuevas tareas que se inician una vez finalizada la migración del servicio. Ejecute `put-account-setting` con la opción `taskLongArnFormat` establecida en `enabled`. Para obtener más información, consulte [put-account-setting](https://docs.aws.amazon.com/cli/latest/reference/ecs/put-account-setting.html) en la *Referencia de la API de Amazon Elastic Container Service*.

   Ejecute el comando como Usuario raíz cuando el servicio tenga un valor de fecha desconocido para `createdAt`.

   ```
   aws ecs put-account-setting --name taskLongArnFormat --value enabled
   ```

   Ejemplo de resultado

   ```
   {
       "setting": {
           "name": "taskLongArnFormat",
           "value": "enabled",
           "principalArn": "arn:aws:iam::123456789012:role/your-role",
           "type": user
       }
   }
   ```
**nota**  
La configuración `taskLongArnFormat` no migra directamente las tareas existentes. Solo afecta al formato del ARN de las nuevas tareas que se crean después de habilitar la configuración. Las tareas en ejecución existentes retienen su formato de ARN actual hasta que se sustituyan mediante las operaciones de servicio normales (como las implementaciones o las actividades de escalado).

## Procedimiento
<a name="migrate-service-arn-procedure"></a>

Utilice lo siguiente para migrar el ARN de su servicio.

### Consola
<a name="migrate-service-arn-procedure-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 sección **Servicios**, elija un servicio que tenga una advertencia en la columna ARN.

   Se abrirá la página de detalles del servicio.

1. Elija **Migrar a un ARN largo**.

   Aparecerá el cuadro de diálogo del servicio de migración.

1. Seleccione **Migrar**.

### CLI
<a name="migrate-service-arn-procedure-cli"></a>

Después de completar los requisitos previos, puede etiquetar su servicio. Use el siguiente comando:

Amazon ECS considera la posibilidad de transferir el formato de ARN largo a una solicitud de API `tag-resource` para un servicio con un ARN corto como señal para migrar el servicio y usar el formato de ARN largo.

```
aws ecs tag-resource \
    --resource-arn arn:aws:ecs:region:aws_account_id:service/cluster-name/service-name
    --tags key=key1,value=value1
```

El siguiente ejemplo etiqueta MyService con una etiqueta que tiene una clave establecida en “TestService” y un valor establecido en “WebServers:

```
aws ecs tag-resource \
    --resource-arn arn:aws:ecs:us-east-1:123456789012:service/MyCluster/MyService
    --tags key=TestService1,value=WebServers
```

### Terraform
<a name="migrate-service-arn-procedure-terraform"></a>

Después de completar los requisitos previos, puede etiquetar su servicio. Cree un recurso `aws_ecs_service` y establezca la referencia `tags`. Para obtener más información, consulte [Resource: aws\$1ecs\$1service](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/ecs_service) en la documentación de Terraform.

```
resource "aws_ecs_service" "MyService" {
  name    = "example"
  cluster = aws_ecs_cluster.MyService.id

 tags = {
 "Name"  =  "MyService"
 "Environment"  =  "Production"
 "Department"  =  "QualityAssurance"
  }
}
```

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

Puede agregar etiquetas al servicio. Para obtener más información, consulte [Adición de etiquetas a los recursos de Amazon ECS](tag-resources-console.md).

Si desea que Amazon ECS propague las etiquetas desde la definición de tareas o el servicio a la tarea, ejecute `update-service` con el parámetro `propagateTags`. Para obtener más información, consulte [update-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/update-service.html) en *Referencia de la AWS Command Line Interface*.

## Solución de problemas
<a name="troubleshooting-arn-migration"></a>

 Algunos usuarios pueden encontrar el siguiente error al migrar del formato ARN corto al formato ARN largo. 

`There was an error while migrating the ARN of service service-name. The specified account does not have serviceLongArnFormat or taskLongArnFormat account settings enabled. Add account settings in order to enable tagging.` 

 Si ya ha activado la configuración de la cuenta de `serviceLongArnFormat`, pero sigue apareciendo este error, puede que se deba a que la configuración de la cuenta para el formato ARN largo no esté activada para la entidad principal de IAM específica que creó originalmente el servicio. 

1.  Identifica la entidad principal que creó el servicio.

   1. En la consola, esta información está disponible en el campo **Creado por** de la pestaña **Configuración y redes**, dentro de la página de detalles del servicio de la consola de Amazon ECS. 

   1. En el caso de la AWS CLI, ejecute el siguiente comando:

      Sustituya las *entradas del usuario* por sus valores.

      ```
      aws ecs describe-services --cluster cluster-name --services service-name --query 'services[0].{createdBy: createdBy}'
      ```

1. Active la configuración de cuenta requerida para esa entidad principal específica. Puedes hacerlo de una de las siguientes formas: 

   1.  Asuma el usuario o el rol de IAM para esa entidad principal. A continuación, ejecute `put-account-setting`. 

   1.  Utilice el usuario raíz para ejecutar el comando y, al mismo tiempo, especifique la creación de la entidad principal con `principal-arn`. 

      Ejemplo.

      Reemplace el valor de *principal-arn* por el valor del paso 1.

      ```
      aws ecs put-account-setting --name serviceLongArnFormat --value enabled --principal-arn arn:aws:iam::123456789012:role/jdoe
      ```

 Ambos métodos permiten la configuración de cuenta de `serviceLongArnFormat` requerida en la entidad principal que creó el servicio, de modo que se puede continuar con la migración del ARN. 

# Lógica de limitación controlada de servicios de Amazon ECS
<a name="service-throttle-logic"></a>

El programador de servicios de Amazon ECS incluye una lógica de protección que limita la frecuencia con la que se lanzan las tareas del servicio si no pueden iniciarse tras varios intentos. Esto ayuda a evitar el consumo innecesario de recursos y reduce los costos.

Cuando las tareas de un servicio no pasan del estado `PENDING` a `RUNNING` y, en lugar de ello, pasan directamente a `STOPPED`, el programador:
+ Aumenta gradualmente el tiempo entre los intentos de reinicio
+ Sigue aumentando los retrasos hasta un máximo de 27 minutos entre intentos
+ Genera un mensaje de evento de servicio para notificarle el problema

**nota**  
El periodo máximo de retraso de 27 minutos puede cambiar en futuras actualizaciones.

Cuando se active la limitación, recibirá este mensaje de evento de servicio:

```
(service service-name) is unable to consistently start tasks successfully.
```

Características importantes de la lógica de limitación:
+ Los servicios continúan reintentándolo indefinidamente
+ La única modificación es el aumento del tiempo entre reinicios
+ No hay parámetros configurables por el usuario

## Resolución de problemas de limitación
<a name="resolving-throttling"></a>

Para resolver un problema de limitación, puede hacer lo siguiente:
+ Actualice el servicio para utilizar una nueva definición de tarea, que inmediatamente devuelve el servicio a una operación normal, sin limitaciones. Para obtener más información, consulte [Actualización de un servicio de Amazon ECS](update-service-console-v2.md).
+ Aborde la causa subyacente de los errores en las tareas.

Entre las causas más comunes de los errores en las tareas que provocan la limitación se incluyen las siguientes:
+ Recursos de clúster insuficientes (puertos, memoria o CPU)
  + Lo indica un [mensaje de evento de servicio de recursos insuficientes](service-event-messages-list.md#service-event-messages-1)
+ Fallos al extraer la imagen del contenedor
  + Puede deberse a nombres o etiquetas de imagen no válidos o a permisos insuficientes
  + Da como resultado `CannotPullContainerError` en [Visualización de los errores de las tareas detenidas de Amazon ECS](stopped-task-errors.md)
+ Espacio en disco insuficiente
  + Da como resultado `CannotCreateContainerError` en [errores de tareas detenidas](stopped-task-errors.md)
  + Para ver los pasos de resolución, consulte [Solución del problema de Docker `API error (500): devmapper` en Amazon ECS](CannotCreateContainerError.md)

**importante**  
Los siguientes escenarios NO activan la lógica de limitación:  
Tareas que se detienen después de alcanzar el estado `RUNNING`
Se detuvieron tareas debido a comprobaciones de estado de Elastic Load Balancing con errores
Tareas en las que el comando de contenedor se cierra con un código distinto de cero después de alcanzar el estado `RUNNING`

# Parámetros de definición de servicio de Amazon ECS
<a name="service_definition_parameters"></a>

Una definición de servicio define cómo ejecutar el servicio de Amazon ECS. Los siguientes parámetros se pueden especificar en una definición de servicio.

## Tipo de lanzamiento
<a name="sd-launchtype"></a>

`launchType`  
Tipo: cadena  
Valores válidos: `EC2` \$1 `FARGATE` \$1 `EXTERNAL`  
Obligatorio: no  
El tipo de lanzamiento en el que ejecutar su servicio. Si no se especifica ningún tipo de lanzamiento, se usará `capacityProviderStrategy` de forma predeterminada.  
Al actualizar un servicio, este parámetro desencadena la implementación de un nuevo servicio.  
Si se especifica `launchType`, se debe omitir el parámetro `capacityProviderStrategy`.

## Estrategia de proveedores de capacidad
<a name="sd-capacityproviderstrategy"></a>

`capacityProviderStrategy`  
Tipo: matriz de objetos   
Obligatorio: no  
La estrategia de proveedores de capacidad que se utilizará para el servicio.  
Al actualizar un servicio, este parámetro no desencadena la implementación de un nuevo servicio.  
Una estrategia de proveedores de capacidad consiste en uno o más proveedores de capacidad junto con la `base` y `weight` que se les asigne. Un proveedor de capacidad debe estar asociado con el clúster que se utilizará en una estrategia de proveedores de capacidad. La API PutClusterCapacityProviders se utiliza para asociar un proveedor de capacidad a un clúster. Solo se pueden utilizar los proveedores de capacidad con un estado `ACTIVE` o `UPDATING`.  
Si se especifica `capacityProviderStrategy`, se debe omitir el parámetro `launchType`. Si no se especifica `capacityProviderStrategy` o `launchType`, se utiliza `defaultCapacityProviderStrategy` para el clúster.  
Si desea especificar un proveedor de capacidad que utiliza un grupo de escalado automático, el proveedor de capacidad debe estar ya creado. Se pueden crear nuevos proveedores de capacidad con la operación CreateCapacityProvider de la API.  
Para utilizar un proveedor de capacidad de Fargate de AWS, especifique los proveedores de capacidad `FARGATE` o `FARGATE_SPOT`. Los proveedores de capacidad de AWS Fargate están disponibles para todas las cuentas y solo necesitan estar asociados al clúster que se va a utilizar.  
La operación PutClusterCapacityProviders de la API se utiliza para actualizar la lista de proveedores de capacidad disponibles para un clúster después de que se haya creado el clúster.    
`capacityProvider`  <a name="capacityProvider"></a>
Tipo: cadena  
Obligatorio: sí  
El apodo o el nombre de recurso de Amazon (ARN) del proveedor de capacidad.  
`weight`  <a name="weight"></a>
Tipo: número entero  
Rango válido: números enteros entre 0 y 1000.  
Obligatorio: no  
El valor peso designa el porcentaje relativo del número total de tareas lanzadas que utiliza el proveedor de capacidad especificado.  
Por ejemplo, suponga que tiene una estrategia que contiene dos proveedores de capacidad y ambos tienen una ponderación de uno. Cuando se completa la base, las tareas se dividen en partes iguales entre los dos proveedores de capacidad. Con la misma lógica, suponga que especifica un peso de 1 para *capacityProviderA* y un peso de 4 para *capacityProviderB*. Luego, para cada tarea que se ejecute con *capacityProviderA*, cuatro tareas utilizan *capacityProviderB*.  
`base`  <a name="base"></a>
Tipo: número entero  
Rango válido: números enteros entre 0 y 100 000.  
Obligatorio: no  
El valor de base designa cuántas tareas, como mínimo, se ejecutarán en el proveedor de capacidad especificado. Solo se puede definir una base para uno de los proveedores de capacidad de una estrategia de proveedores de capacidad.

## Definición de tarea
<a name="sd-taskdefinition"></a>

`taskDefinition`  
Tipo: cadena  
Requerido: no  
La `family` y `revision` (`family:revision`) o el nombre de recurso de Amazon (ARN) completo de la definición de tareas que se va a ejecutar en el servicio. Si no se especifica una `revision`, se utiliza la última revisión `ACTIVE` de la familia especificada.  
Al actualizar un servicio, este parámetro desencadena la implementación de un nuevo servicio.  
Debe especificarse una definición de tarea cuando se utiliza el controlador de implementación de actualización continua (`ECS`).

## Sistema operativo de la plataforma
<a name="platform-os"></a>

`platformFamily`  
Tipo: String  
Obligatorio: condicional  
Predeterminado: Linux  
Este parámetro es necesario para los servicios de Amazon ECS alojados en Fargate.  
Este parámetro se ignora para los servicios de Amazon ECS alojados en Amazon EC2.  
El sistema operativo de los contenedores que ejecuta el servicio. Los valores válidos son `LINUX`, `WINDOWS_SERVER_2019_FULL`, `WINDOWS_SERVER_2019_CORE`, `WINDOWS_SERVER_2022_FULL` y `WINDOWS_SERVER_2022_CORE`.  
El valor `platformFamily` para cada tarea que especifique para el servicio debe coincidir con el servicio del valor `platformFamily`. Por ejemplo, si configuró el `platformFamily` a `WINDOWS_SERVER_2019_FULL`, el valor `platformFamily` para todas las tareas debe ser `WINDOWS_SERVER_2019_FULL`.

## Versión de la plataforma
<a name="sd-platformversion"></a>

`platformVersion`  
Tipo: cadena  
Requerido: no  
La versión de la plataforma en la que se ejecutan sus tareas en el servicio. La versión de la plataforma solo se especifica para las tareas que utilizan el tipo de lanzamiento de Fargate. Si no se especifica ninguna, se usará la versión más reciente (`LATEST`) de forma predeterminada.  
Al actualizar un servicio, este parámetro desencadena la implementación de un nuevo servicio.  
AWSLas versiones de la plataforma de Fargate se utilizan para hacer referencia a un entorno en tiempo de ejecución específico para la infraestructura de tareas de Fargate. Cuando se especifica la versión de la plataforma `LATEST` al ejecutar una tarea o crear un servicio, se obtiene la versión más actual de la plataforma disponible para las tareas. Cuando se escala un servicio, esas tareas reciben la versión de la plataforma especificada en la implementación actual del servicio. Para obtener más información, consulte [Versiones de la plataforma Fargate para Amazon ECS](platform-fargate.md).  
No se especifican las versiones de la plataforma para las tareas que utilizan el tipo de lanzamiento de EC2.

## Clúster
<a name="sd-cluster"></a>

`cluster`  
Tipo: cadena  
Requerido: no  
El nombre abreviado o nombre de recurso de Amazon (ARN) completo del clúster en el que ejecutar el servicio. Si no especifica un clúster, se supone el clúster `default`.

## Nombre del servicio
<a name="sd-servicename"></a>

`serviceName`  
Tipo: cadena  
Obligatorio: sí  
El nombre de su servicio. Se admiten hasta 255 letras (mayúsculas y minúsculas), números, guiones y caracteres de subrayado. Los nombres de servicio deben ser únicos dentro de un clúster, pero puede tener servicios con el mismo nombre en varios clústeres dentro de una región o en varias regiones.

## Estrategia de programación
<a name="sd-schedulingstrategy"></a>

`schedulingStrategy`  
Tipo: cadena  
Valores válidos: `REPLICA` \$1 `DAEMON`  
Obligatorio: no  
La estrategia de programación que se va a utilizar. Si no se especifica ninguna estrategia de programación, se utiliza la estrategia de `REPLICA`. Para obtener más información, consulte [Servicios de Amazon ECS](ecs_services.md).  
Existen dos estrategias del programador de servicio:  
+ `REPLICA`: la estrategia de programación de réplicas sitúa y mantiene en el clúster el número de tareas deseado. De forma predeterminada, el programador de servicio distribuye las tareas en zonas de disponibilidad. Puede utilizar estrategias y restricciones de ubicación de tareas para personalizar las decisiones de ubicación de las tareas. Para obtener más información, consulte [Estrategia de programación de réplicas](ecs_service-options.md#service_scheduler_replica).
+ `DAEMON`: la estrategia de programación del daemon implementa exactamente una tarea en cada instancia de contenedor activa que cumpla todas las restricciones de ubicación de tareas que se especifiquen para el clúster. Cuando se utiliza esta estrategia, no es necesario especificar un número deseado de tareas, ni una estrategia de ubicación de tareas ni utilizar políticas de Auto Scaling de servicios. Para obtener más información, consulte [Estrategia de programación de daemon](ecs_service-options.md#service_scheduler_daemon).
**nota**  
Las tareas de Fargate no admiten la estrategia de programación de `DAEMON`.

## Recuento deseado
<a name="sd-desiredcount"></a>

`desiredCount`  
Tipo: entero  
Obligatorio: no  
El número de instancias de la definición de tarea especificada para ubicar y seguir ejecutando en el servicio.  
Al actualizar un servicio, este parámetro no desencadena la implementación de un nuevo servicio.  
Este parámetro es necesario si se utiliza la estrategia de programación de `REPLICA`. Si el servicio utiliza la estrategia de programación de `DAEMON`, este parámetro es opcional.  
Cuando usa el escalado automático de servicios, si actualiza un servicio que se está ejecutando actualmente con un valor de `desiredCount` inferior al número de tareas que se están ejecutando actualmente, el servicio se reduce verticalmente al valor de `desiredCount` especificado. 

## Configuración de implementación
<a name="sd-deploymentconfiguration"></a>

`deploymentConfiguration`  
Tipo: objeto  
Obligatorio: no  
Parámetros de implementación opcionales que controlan cuántas tareas se ejecutan durante la implementación y la ordenación de tareas de parada e inicio.  
Al actualizar un servicio, este parámetro no desencadena la implementación de un nuevo servicio.    
`maximumPercent`  <a name="maximumPercent"></a>
Tipo: entero  
Obligatorio: no  
Si un servicio utiliza el tipo de implementación de actualización continua (`ECS`), el parámetro `maximumPercent` representa un límite superior en el número de tareas de servicio que se permiten en el estado `RUNNING`, `STOPPING` o `PENDING` durante una implementación. Se expresa como un porcentaje de `desiredCount` que se redondea al número entero más cercano. Puede utilizar este parámetro para definir el tamaño del lote de implementación. Por ejemplo, si el servicio utiliza el programador de servicios `REPLICA` y tiene un `desiredCount` de cuatro tareas y un valor `maximumPercent` de 200 %, el programador inicia cuatro nuevas tareas antes de detener las cuatro tareas más antiguas. Esto es siempre que los recursos del clúster requeridos para hacer esto estén disponibles. El valor `maximumPercent` predeterminado para un servicio que utiliza el programador de servicio `REPLICA` es 200 %.  
El programador de Amazon ECS usa este parámetro para reemplazar las tareas en mal estado. Para ello, inicia primero las tareas de reemplazo y, luego, las detiene, siempre que haya recursos del clúster disponibles para iniciar las tareas de reemplazo. Para obtener más información sobre cómo el programador reemplaza las tareas en mal estado, consulte [Servicios de Amazon ECS](ecs_services.md).  
Si el servicio utiliza el tipo de programador de servicio `DAEMON`, el `maximumPercent` debería permanecer al 100 %. Este es el valor predeterminado.  
El número máximo de tareas durante una implementación es el `desiredCount` multiplicado por el `maximumPercent`/100, redondeado al valor del entero inferior más próximo.  
Si un servicio está utilizando el tipo de implementación blue/green (`CODE_DEPLOY`) o `EXTERNAL` y tareas que usan el tipo de lanzamiento EC2, el valor de **porcentaje máximo** se establece en el valor predeterminado. El valor se usa para definir el límite superior del número de las tareas en el servicio que permanecen en el estado `RUNNING` al mismo tiempo que las instancias de contenedor se encuentran en el estado `DRAINING`.  
No puede especificar un valor `maximumPercent` personalizado para un servicio que utilice los tipos de implementación azul/verde (`CODE_DEPLOY`) o `EXTERNAL` y que tenga tareas que utilicen EC2.
Si el servicio utiliza los tipos de implementación azul/verde (`CODE_DEPLOY`) o `EXTERNAL`, y las tareas del servicio utilizan Fargate, no se utilizará el valor porcentual máximo. El valor aún se devuelve al describir el servicio.  
`minimumHealthyPercent`  <a name="minimumHealthyPercent"></a>
Tipo: entero  
Obligatorio: no  
Si un servicio utiliza el tipo de implementación de actualización continua (`ECS`), el parámetro `minimumHealthyPercent` representa un límite inferior en el número de tareas de servicio que permanecen en el estado `RUNNING` durante una implementación. Se expresa como un porcentaje de `desiredCount` que se redondea al número entero más cercano. Puede utilizar este parámetro para implementar sin utilizar capacidad de clúster adicional.  
Por ejemplo, si el servicio tiene un parámetro `desiredCount` de cuatro tareas, un parámetro `minimumHealthyPercent` del 50 % y un parámetro `maximumPercent` del 100 %, el programador de servicio detiene dos tareas existentes para liberar capacidad de clúster antes de iniciar dos nuevas tareas.   
 Si alguna tarea se encuentra en mal estado y `maximumPercent` no permite que el programador de Amazon ECS inicie tareas de reemplazo, el programador detiene las tareas en mal estado una por una (y utiliza `minimumHealthyPercent` como una restricción) para liberar capacidad y lanzar tareas de reemplazo. Para obtener más información sobre cómo el programador reemplaza las tareas en mal estado, consulte [Servicios de Amazon ECS](ecs_services.md).  
Para los servicios que *no* utilizan un equilibrador de carga, tenga en cuenta lo siguiente:  
+ Se considera que un servicio está en buen estado si todos los contenedores esenciales dentro de las tareas del servicio superan sus comprobaciones de estado.
+ Si una tarea no tiene contenedores esenciales con una comprobación de estado definida, el programador de servicios esperará 40 segundos después de que una tarea alcance un estado de `RUNNING` antes de que la tarea se cuente hacia el porcentaje total mínimo de buen estado.
+ Si una tarea tiene uno o más contenedores esenciales con una comprobación de estado definida, el programador de servicios esperará a que la tarea alcance un buen estado antes de contarla hacia el porcentaje total mínimo de buen estado. Se considera que una tarea está en buen estado cuando todos los contenedores esenciales de la tarea han superado sus comprobaciones de estado. El tiempo que puede esperar el programador de servicios viene determinado por la configuración de comprobación de estado del contenedor. Para obtener más información, consulte [Comprobación de estado](task_definition_parameters.md#container_definition_healthcheck). 
Para los servicios que *sí* utilizan un equilibrador de carga, tenga en cuenta lo siguiente:  
+ Si una tarea no tiene contenedores esenciales con una comprobación de estado definida, el programador de servicios esperará a que la comprobación de estado del grupo de destino del equilibrador de carga devuelva un “buen estado” antes de contar la tarea hacia el porcentaje total mínimo del estado correcto.
+ Si una tarea tiene un contenedor esencial con una comprobación de estado definida, el programador de servicios esperará a que la tarea alcance un buen estado y a que la comprobación de estado del grupo de destino del equilibrador de carga devuelva un “buen estado” antes de contar la tarea hacia el porcentaje total mínimo del estado correcto.
El valor predeterminado para un servicio de réplica de `minimumHealthyPercent` es del 100%. El valor `minimumHealthyPercent` predeterminado para un servicio que utiliza el programador de servicios `DAEMON` es del 0 % para la AWS CLI, los SDK de AWS y las API, y del 50 % para la Consola de administración de AWS.  
El número mínimo de tareas en buen estado durante una implementación es el `desiredCount` multiplicado por el `minimumHealthyPercent`/100, redondeado al valor del entero superior más próximo.  
Si un servicio utiliza el tipo de implementación azul/verde (`CODE_DEPLOY`) o `EXTERNAL` y pone en marcha tareas que usan EC2, el valor de **porcentaje mínimo en buen estado** se establece en el valor predeterminado. El valor se usa para definir el límite inferior del número de las tareas en el servicio que permanecen en el estado `RUNNING` al mismo tiempo que las instancias de contenedor se encuentran en el estado `DRAINING`.  
No puede especificar un valor `maximumPercent` personalizado para un servicio que utilice los tipos de implementación azul/verde (`CODE_DEPLOY`) o `EXTERNAL` y que tenga tareas que utilicen EC2.
Si un servicio utiliza los tipos de implementación azul/verde (`CODE_DEPLOY`) o `EXTERNAL` y pone en marcha tareas que utilizan Fargate, el valor de porcentaje mínimo en buen estado no se utiliza, aunque se devuelva al describir el servicio.

## Controlador de implementación
<a name="sd-deploymentcontroller"></a>

`deploymentController`  
Tipo: objeto  
Obligatorio: no  
El controlador de implementación que utilizar para el servicio. Si no se especifica ningún controlador de implementación, se utiliza el controlador `ECS`. Para obtener más información, consulte [Servicios de Amazon ECS](ecs_services.md).  
Al actualizar un servicio, este parámetro no desencadena la implementación de un nuevo servicio.    
`type`  
Tipo: cadena  
Valores válidos: `ECS` \$1 `CODE_DEPLOY` \$1 `EXTERNAL`  
Obligatorio: sí  
El tipo de controlador de implementación que se va a utilizar. Existen tres tipos de controlador de implementación disponibles:    
`ECS`  
El controlador de implementación de Amazon ECS admite varias estrategias de implementación: actualización continua, azul/verde, lineal y canario. El tipo de implementación de actualización continua implica la sustitución de la versión en marcha actual del contenedor por la versión más reciente. Las implementaciones azul/verde crean un nuevo entorno y cambian el tráfico de una sola vez. Las implementaciones lineales cambian gradualmente el tráfico en incrementos porcentuales iguales. Las implementaciones canario cambian primero un pequeño porcentaje del tráfico y, a continuación, cambian el resto del tráfico. Para controlar el número de contenedores que Amazon ECS agrega o elimina del servicio durante una actualización acumulativa, se ajusta el número mínimo y máximo de tareas en estado correcto permitidas durante una implementación de servicio, tal y como se especifica en [deploymentConfiguration](#deploymentConfiguration).  
`CODE_DEPLOY`  
El tipo de implementación “blue/green” (`CODE_DEPLOY`) utiliza el modelo de implementación “blue/green” (azul/verde) con tecnología de CodeDeploy, que le permite verificar una nueva implementación de un servicio antes de enviarle tráfico de producción.  
`EXTERNAL`  
Utilice el tipo de implementación externa cuando quiera usar cualquier controlador de implementación de terceros para tener un control completo del proceso de implementación de un servicio de Amazon ECS.

## Ubicación de tareas
<a name="sd-taskplacement"></a>

`placementConstraints`  
Tipo: matriz de objetos   
Obligatorio: no  
Una matriz de objetos de restricción de colocación que utilizar para tareas en su servicio. Puede especificar 10 restricciones como máximo por tarea. Este límite incluye restricciones en la definición de tareas y las especificadas en tiempo de ejecución. Si usa Fargate, no se admiten las restricciones de ubicación de tareas.  
Al actualizar un servicio, este parámetro no desencadena la implementación de un nuevo servicio.    
`type`  
Tipo: cadena  
Requerido: no  
El tipo de restricción. Para garantizar que cada tarea de un determinado grupo se ejecute en una instancia de contenedor diferente, utilice `distinctInstance`. Utilice `memberOf` para restringir la selección a un grupo de candidatos válidos. El valor `distinctInstance` no se admite en las definiciones de tareas.  
`expression`  
Tipo: cadena  
Requerido: no  
Una expresión de lenguaje de consulte de clúster que aplicar a la restricción. No puede especificar una expresión si el tipo de restricción es `distinctInstance`. Para obtener más información, consulte [Creación de expresiones para definir instancias de contenedor para las tareas de Amazon ECS](cluster-query-language.md).

`placementStrategy`  
Tipo: matriz de objetos   
Obligatorio: no  
Los objetos de estrategia colocación que utilizar para tareas en su servicio. Puede especificar un máximo de cuatro reglas de estrategia por servicio.  
Al actualizar un servicio, este parámetro no desencadena la implementación de un nuevo servicio.    
`type`  
Tipo: cadena  
Valores válidos: `random` \$1 `spread` \$1 `binpack`  
Obligatorio: no  
Es el tipo de estrategia de colocación. La estrategia de colocación `random` coloca las tareas aleatoriamente en los candidatos disponibles. La estrategia de ubicación `spread` distribuye la ubicación entre los candidatos disponibles de manera uniforme en función del parámetro `field`. La estrategia `binpack` ubica las tareas en los candidatos disponibles que tengan la menor cantidad disponible del recurso que se especifica con el parámetro `field`. Por ejemplo, si aplica dicha estrategia en la memoria, se coloca una tarea en la instancia con la menor cantidad de memoria restante, pero suficiente para ejecutar la tarea.  
`field`  
Tipo: cadena  
Requerido: no  
El campo en el que aplicar la estrategia de ubicación. Para la estrategia de ubicación `spread`, los valores válidos son `instanceId` (o `host`, que tiene el mismo efecto) o cualquier plataforma o atributo personalizado que se aplique a una instancia de contenedor, como por ejemplo `attribute:ecs.availability-zone`. Para la estrategia de colocación `binpack`, los valores válidos son `cpu` y `memory`. Para la estrategia de colocación `random`, este campo no se utiliza.

## Etiquetas
<a name="sd-tags"></a>

`tags`  
Tipo: matriz de objetos   
Obligatorio: no  
Los metadatos que se aplican al servicio para ayudarle a categorizarlas y organizarlas. Cada etiqueta está formada por una clave y un valor opcional, ambos definidos por el usuario. Cuando se elimina un servicio, también se eliminan las etiquetas. Se puede aplicar un máximo de 50 etiquetas al servicio. Para obtener más información, consulte [Etiquetado de los recursos de Amazon ECS](ecs-using-tags.md).  
Al actualizar un servicio, este parámetro no desencadena la implementación de un nuevo servicio.    
`key`  
Tipo: cadena  
Limitaciones de longitud: longitud mínima de 1. Longitud máxima de 128.  
Obligatorio: no  
Una parte de un par clave-valor que compone una etiqueta. Un clave es una etiqueta general que actúa como una categoría para valores de etiqueta más específicos.  
`value`  
Tipo: cadena  
Limitaciones de longitud: longitud mínima de 0. La longitud máxima es de 256 caracteres.  
Obligatorio: no  
La parte opcional de un par clave-valor que compone una etiqueta. Un valor actúa como un descriptor en una categoría de etiquetas (clave).

`enableECSManagedTags`  
Tipo: booleano  
Valores válidos: `true` \$1 `false`  
Obligatorio: no  
Especifica si se deben usar etiquetas administradas por Amazon ECS para las tareas del servicio. El valor predeterminado es si no se especifica ningún valor `false`. Para obtener más información, consulte [Uso de etiquetas para facturación](ecs-using-tags.md#tag-resources-for-billing).  
Al actualizar un servicio, este parámetro no desencadena la implementación de un nuevo servicio.

`propagateTags`  
Tipo: cadena  
Valores válidos: `TASK_DEFINITION` \$1 `SERVICE`  
Obligatorio: no  
Especifica si se deben copiar las etiquetas de la definición de tareas o el servicio en las tareas del servicio. Si no se especifica ningún valor, las etiquetas no se copian. Solo se pueden copiar las etiquetas en las tareas del servicio durante la creación del servicio. Para agregar etiquetas a una tarea tras la creación del servicio, utilice la acción de la API `TagResource`.  
Al actualizar un servicio, este parámetro no desencadena la implementación de un nuevo servicio.

## Configuración de red
<a name="sd-networkconfiguration"></a>

`networkConfiguration`  
Tipo: objeto  
Obligatorio: no  
La configuración de red del servicio. Este parámetro es necesario para definiciones de tareas que usan el modo de red `awsvpc` para recibir su propia interfaz de red elástica y no se admite para otros modos de red. Si usa Fargate, es necesario el modo de red `awsvpc`. Para obtener más información acerca de las redes para EC2, consulte [Opciones de red de tareas de Amazon ECS para EC2](task-networking.md). Para obtener más información acerca de las redes para Fargate, consulte [Opciones de redes de tareas de Amazon ECS para Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-task-networking.html).  
Al actualizar un servicio, este parámetro desencadena la implementación de un nuevo servicio.    
`awsvpcConfiguration`  
Tipo: objeto  
Obligatorio: no  
Un objeto que representa las subredes y los grupos de seguridad para una tarea o servicio.    
`subnets`  
Tipo: matriz de cadenas  
Obligatorio: sí  
Las subredes asociadas a la tarea o servicio. Existe un límite de 16 subredes que se pueden especificar según `awsvpcConfiguration`.  
`securityGroups`  
Tipo: matriz de cadenas  
Obligatorio: no  
Los grupos de seguridad asociados a la tarea o servicio. Si no se especifica un grupo de seguridad, se usará el grupo de seguridad predeterminado para la VPC. Existe un límite de cinco grupos de seguridad que se puede especificar en función de `awsvpcConfiguration`.  
`assignPublicIP`  
Tipo: cadena  
Valores válidos: `ENABLED` \$1 `DISABLED`  
Obligatorio: no  
Indica si la interfaz de red elástica de la tarea recibe una dirección IP pública. Si no se especifica ningún valor, se utiliza el valor predeterminado `DISABLED`.

`healthCheckGracePeriodSeconds`  
Tipo: entero  
Obligatorio: no  
El periodo de tiempo, en segundos, que el programador de servicio de Amazon ECS ignora las comprobaciones de estado en mal estado de Elastic Load Balancing, VPC Lattice y del contenedor después de que se haya iniciado una tarea por primera vez. Si no se especifica ningún valor para el período de gracia de comprobación de estado, se utiliza el valor predeterminado: 0. Si no se utiliza ninguna de las comprobaciones de estado, entonces `healthCheckGracePeriodSeconds` no se utilizará.  
Si las tareas del servicio tardan mucho en iniciarse y en responder, se puede especificar un periodo de gracia para las comprobaciones de estado de hasta 2 147 483 647 segundos (aproximadamente 69 años). Durante este periodo, el programador de servicio de Amazon ECS hará caso omiso del estado de las comprobaciones de estado. Este periodo de gracia puede evitar que el programador de servicio interprete que las tareas están en mal estado y las detenga antes de que tengan tiempo de iniciarse.  
Al actualizar un servicio, este parámetro no desencadena la implementación de un nuevo servicio.

`loadBalancers`  
Tipo: matriz de objetos   
Obligatorio: no  
Un objeto de balanceador de carga que representa los balanceadores de carga que utilizar con su servicio. En el caso de los servicios que utilizan un equilibrador de carga de aplicación o un equilibrador de carga de red, existe un límite de cinco grupos de destino que puede asociar a un servicio.  
Al actualizar un servicio, este parámetro desencadena la implementación de un nuevo servicio.  
Después de crear un servicio, la configuración del equilibrador de carga no se puede cambiar desde la Consola de administración de AWS. Puede usar el Copiloto de AWS, AWS CloudFormation, AWS CLI o SDK para modificar la configuración del equilibrador de carga solo del controlador de implementación progresiva `ECS`, no AWS CodeDeploy azul/verde o exterior. Cuando agrega, actualiza o elimina una configuración de equilibrador de carga, Amazon ECS inicia una nueva implementación con la configuración actualizada de Elastic Load Balancing. Esto hace que las tareas se registren y eliminen el registro de los equilibradores de carga. Le recomendamos que lo verifique en un entorno de prueba antes de actualizar la configuración de Elastic Load Balancing. Para obtener más información acerca de cómo modificar la configuración, consulte [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) en la *Referencia de la API de Amazon Elastic Container Service*.  
En el caso de los balanceadores de carga de aplicacione y los balanceadores de carga de red, este objeto debe contener el ARN del grupo de destino del balanceador de carga, el nombre del contenedor (tal como aparece en la definición de contenedor) y el puerto del contenedor para obtener acceso desde el balanceador de carga. Cuando una tarea de este servicio se ubica en la instancia de contenedor, la combinación de instancia y puerto se registran como un destino en el grupo de destino especificado.    
`targetGroupArn`  
Tipo: cadena  
Requerido: no  
El nombre de recurso de Amazon (ARN) completo del grupo o grupos de destino del equilibrador de carga elástico asociados a un servicio.  
Un ARN del grupo de destino solo se especifica cuando se utiliza un Application Load Balancer o un Network Load Balancer.  
`loadBalancerName`  
Tipo: cadena  
Requerido: no  
El nombre del balanceador de carga que se va a asociar con el servicio.  
Si utiliza un equilibrador de carga de aplicación o un equilibrador de carga de red, se debe omitir el parámetro del nombre del equilibrador de carga.  
`containerName`  
Tipo: cadena  
Requerido: no  
El nombre del contenedor (tal como aparece en una definición de contenedor) para asociar al balanceador de carga.  
`containerPort`  
Tipo: entero  
Obligatorio: no  
El puerto en el contenedor para asociar al balanceador de carga. Este puerto debe corresponderse con un `containerPort` en la definición de tarea que utilizan las tareas del servicio. En el caso de las tareas que utilizan EC2, la instancia de contenedor debe permitir el tráfico de entrada en el puerto `hostPort` de la asignación de puertos.

`role`  
Tipo: cadena  
Requerido: no  
El nombre abreviado o el ARN completo del rol de IAM que permite a Amazon ECS realizar llamadas al balanceador de carga en su nombre. Este parámetro solo se permite si utiliza un balanceador de carga con un solo grupo de destino para el servicio y su definición de tareas no utiliza el modo de red `awsvpc`. Si especifica el parámetro `role`, también debe especificar un objeto de balanceador de carga con el parámetro `loadBalancers`.  
Al actualizar un servicio, este parámetro no desencadena la implementación de un nuevo servicio.  
Si el rol especificado tiene una ruta distinta de `/`, entonces debe especificar el ARN de rol completo (se recomienda esto) o prefijar el nombre del rol con la ruta. Por ejemplo, si un rol con el nombre `bar` tiene una ruta `/foo/` debería especificar `/foo/bar` como nombre del rol. Para obtener más información, consulte [Nombres fáciles de recordar y rutas](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-friendly-names) en la *Guía del usuario de IAM*.  
Si su cuenta ya ha creado el rol vinculado al servicio Amazon ECS, se usa ese rol de forma predeterminada para su servicio, a menos que especifique un rol aquí. El rol vinculado al servicio es necesario si su definición de tarea usa el modo de red awsvpc, en cuyo caso no debe especificar un rol aquí. Para obtener más información, consulte [Uso de roles vinculados al servicio para Amazon ECS](using-service-linked-roles.md).

`serviceConnectConfiguration`  
Tipo: objeto  
Obligatorio: no  
La configuración para que este servicio detecte otros servicios y se conecte a ellos, y para que otros servicios dentro de un espacio de nombres lo detecten y se conecten a él.  
Al actualizar un servicio, este parámetro desencadena la implementación de un nuevo servicio.  
Para obtener más información, consulte [Uso de Service Connect para conectar los servicios de Amazon ECS con nombres abreviados](service-connect.md).    
`enabled`  
Tipo: booleano  
Obligatorio: sí  
Especifica si se debe utilizar Service Connect con este servicio.   
`namespace`  
Tipo: cadena  
Requerido: no  
El nombre corto o el nombre de recurso de Amazon (ARN) completo del espacio de nombres de AWS Cloud Map para su uso con Service Connect. El espacio de nombres debe estar en la misma Región de AWS que el servicio y el clúster de Amazon ECS. El tipo de espacio de nombres no afecta a Service Connect. Para obtener más información acerca de AWS Cloud Map, consulte [Trabajo con los servicios](https://docs.aws.amazon.com/cloud-map/latest/dg/working-with-services.html) en la *Guía para desarrolladores de AWS Cloud Map*.  
`services`  
Tipo: matriz de objetos   
Obligatorio: no  
Una serie de objetos de servicio de Service Connect. Se trata de nombres y alias (también conocidos como puntos de conexión) que utilizan otros servicios de Amazon ECS para conectarse a este servicio.  
Este campo no es obligatorio para que un servicio de “cliente” de Amazon ECS, miembro de un espacio de nombres, solo se conecte a otros servicios dentro del espacio de nombres. Un ejemplo es una aplicación frontend que acepta solicitudes entrantes de un equilibrador de carga que está asociado al servicio o por otros medios.  
Un objeto selecciona un puerto de la definición de tarea, asigna un nombre para el servicio de AWS Cloud Map y una serie de alias (también conocidos como puntos de conexión) y puertos para que las aplicaciones de cliente hagan referencia a este servicio.    
`portName`  
Tipo: cadena  
Obligatorio: sí  
El `portName` debe coincidir con el `name` de una de las `portMappings` de todos los contenedores en la definición de tareas de este servicio de Amazon ECS.  
`discoveryName`  
Tipo: cadena  
Requerido: no  
`discoveryName` es el nombre del servicio nuevo de AWS Cloud Map que Amazon ECS crea para este servicio de Amazon ECS. Debe ser único dentro del espacio de nombres de AWS Cloud Map.  
Si este campo no está especificado, se utiliza `portName`.  
`clientAliases`  
Tipo: matriz de objetos   
Obligatorio: no  
La lista de alias de clientes para este servicio de Service Connect. Se utilizan para asignar nombres que pueden utilizar las aplicaciones de cliente. El número máximo de alias de cliente que puede tener en esta lista es 1.  
Cada alias (“punto de conexión”) es un nombre de DNS y un número de puerto que otros servicios de Amazon ECS (“clientes”) pueden usar para conectarse a este servicio.  
Cada combinación de nombre y de puerto debe ser única en el espacio de nombres.  
Estos nombres se configuran dentro de cada tarea del servicio de cliente, no en AWS Cloud Map. Las solicitudes de DNS para resolver estos nombres no abandonan la tarea y no se cuentan para la cuota de solicitudes de DNS por segundo por interfaz de red elástica.    
`port`  
Tipo: número entero  
Obligatorio: sí  
El número de puerto de escucha para el proxy de Service Connect. Este puerto está disponible dentro de todas las tareas del mismo espacio de nombres.  
Para evitar cambiar las aplicaciones en los servicios de cliente de Amazon ECS, configúrelo con el mismo puerto que la aplicación de cliente utiliza de forma predeterminada.  
`dnsName`  
Tipo: cadena  
Requerido: no  
`dnsName` es el nombre que se utiliza en las aplicaciones de tareas del cliente para conectarse al servicio. El nombre debe ser una etiqueta de DNS válida.  
Si no se especifica este campo, el valor se establece de forma predeterminada en `discoveryName.namespace`. Si el `discoveryName` no se especifica, se utiliza el `portName` de la definición de la tarea.  
Para evitar cambiar las aplicaciones en los servicios de cliente de Amazon ECS, configúrelo con el mismo nombre que la aplicación de cliente utiliza de forma predeterminada. Por ejemplo, algunos nombres comunes son `database`, `db` o el nombre en minúsculas de una base de datos, como `mysql` o `redis`.  
`ingressPortOverride`  
Tipo: entero  
Obligatorio: no  
(Opcional) El número de puerto en el que se escuchará el proxy de Service Connect.  
Utilice el valor de este campo para omitir el proxy para el tráfico en el número de puerto especificado en la `portMapping` denominada en la definición de tarea de esta aplicación y luego utilícelo en los grupos de seguridad de Amazon VPC para permitir el tráfico en el proxy para este servicio de Amazon ECS.  
En el modo `awsvpc`, el valor predeterminado es el número de puerto del contenedor que se especifica en la `portMapping` denominada de la definición de la tarea de esta aplicación. En el modo `bridge`, el valor predeterminado es el puerto efímero dinámico del proxy de Service Connect.  
`logConfiguration`  
Tipo: objeto [LogConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html)  
Obligatorio: no  
Esto define dónde se publican los registros de proxy de Service Connect. Utilice los registros para depurar errores durante eventos inesperados. Esta configuración establece el parámetro `logConfiguration` en el contenedor del proxy de Service Connect en cada tarea de este servicio de Amazon ECS. El contenedor del proxy no se especifica en la definición de tarea.  
Le recomendamos que utilice la misma configuración de registro que los contenedores de aplicaciones de la definición de tareas para este servicio de Amazon ECS. Para FireLens, esta es la configuración de registro del contenedor de la aplicación. No es el contenedor del enrutador de registro de FireLens el que usa la imagen del contenedor `fluent-bit` o `fluentd `.  
`accessLogConfiguration`  
Tipo: objeto [ServiceConnectAccessLogConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_LogConfiguration.html)  
Obligatorio: no  
La configuración del registro de acceso de Service Connect, incluido el formato de registro y si los registros deben incluir cadenas de consulta. Los registros de acceso recopilan información detallada sobre las solicitudes realizadas al servicio, como los patrones de solicitud, el código de respuesta y los datos de tiempo. Para habilitar los registros de acceso, también debe especificar el parámetro `logConfiguration` en `serviceConnectConfiguration`.

`serviceRegistries`  
Tipo: matriz de objetos   
Obligatorio: no  
Los detalles de la configuración de detección de servicios para el servicio. Para obtener más información, consulte [Uso de la detección de servicios para conectar los servicios de Amazon ECS con nombres de DNS](service-discovery.md).  
Al actualizar un servicio, este parámetro desencadena la implementación de un nuevo servicio.    
`registryArn`  
Tipo: cadena  
Requerido: no  
El nombre de recurso de Amazon (ARN) del registro de servicios. El registro de servicios compatible actualmente es AWS Cloud Map. Para obtener más información, consulte [Utilización de servicios](https://docs.aws.amazon.com/cloud-map/latest/dg/working-with-services.html) en la *Guía para desarrolladores de AWS Cloud Map*.  
`port`  
Tipo: entero  
Obligatorio: no  
El valor del puerto utilizado si el servicio de detección de servicios se especifica en un registro de SRV. Este campo es obligatorio si se utilizan el modo de red `awsvpc` y los registros SRV.  
`containerName`  
Tipo: cadena  
Requerido: no  
El valor del nombre del contenedor que se va a utilizar para el servicio de detección de servicios. Este valor se especifica en la definición de tarea. Si la definición de tarea especificada por la tarea de servicio utiliza el modo de red `bridge` o `host`, se debe especificar una combinación de `containerName` y `containerPort` a partir de la definición de tarea. Si la definición de tarea especificada por la tarea de servicio usa el modo de red `awsvpc` y se utiliza un registro DNS de tipo SRV, se debe especificar una combinación de `containerName` y `containerPort` o un valor `port`, pero no ambos.  
`containerPort`  
Tipo: entero  
Obligatorio: no  
El valor del puerto que se va a utilizar para el servicio de detección de servicios. Este valor se especifica en la definición de tarea. Si la definición de tarea especificada por la tarea de servicio utiliza el modo de red `bridge` o `host`, se debe especificar una combinación de `containerName` y `containerPort` a partir de la definición de tarea. Si la definición de especificada por la tarea de servicio usa el modo de red `awsvpc` y se utiliza un registro DNS de tipo SRV, se debe especificar una combinación de `containerName` y `containerPort` o un valor de `port`, pero no ambos.

## Token de cliente
<a name="sd-clienttoken"></a>

`clientToken`  
Tipo: cadena  
Requerido: no  
Identificador único con distinción entre mayúsculas y minúsculas que se proporciona para garantizar la idempotencia de la solicitud. Puede tener hasta 32 caracteres ASCII.

## Reequilibrio de la zona de disponibilidad
<a name="sd-availability-zone-rebalancing"></a>

`availabilityZoneRebalancing`  
Tipo: cadena  
Requerido: no  
Indica si el servicio usa el reequilibrio de zonas de disponibilidad. Los valores válidos son `ENABLED` y `DISABLED`.  
Al actualizar un servicio, este parámetro no desencadena la implementación de un nuevo servicio.  
Comportamiento predeterminado:  
+ Para servicios nuevos: si no se especifica ningún valor, el valor predeterminado es `DISABLED`.
+ Para los servicios existentes: si no se especifica ningún valor, Amazon ECS establece el valor predeterminado en el valor existente. Si no se ha establecido un valor previamente, Amazon ECS establece el valor en `DISABLED`.
Para obtener más información acerca del reequilibrio de la zona de disponibilidad, consulte [Equilibrio de un servicio de Amazon ECS entre zonas de disponibilidad](service-rebalancing.md).

## Configuraciones de volúmenes
<a name="sd-volumeConfigurations"></a>

`volumeConfigurations`  
Tipo: objeto  
Obligatorio: no  
Configuración que se utilizará para crear volúmenes para las tareas que administra el servicio. Con este objeto, solo se pueden configurar los volúmenes marcados como `configuredAtLaunch` en la definición de la tarea.  
Al actualizar un servicio, este parámetro desencadena la implementación de un nuevo servicio.  
Este objeto es necesario para adjuntar volúmenes de Amazon EBS a las tareas que administra un servicio. Para obtener más información, consulte [Uso de volúmenes de Amazon EBS con Amazon ECS](ebs-volumes.md).    
`name`  
Tipo: cadena  
Obligatorio: sí  
Nombre de un volumen que se configura al crear o actualizar un servicio. Se permiten hasta 255 letras (mayúsculas y minúsculas), números, símbolos de subrayado (`_`) y guiones (`-`). Este valor debe coincidir con el nombre del volumen que se especifica en la definición de la tarea.  
`managedEBSVolume`  
Tipo: objeto  
Obligatorio: no  
Configuración de volúmenes utilizada para la creación de volúmenes de Amazon EBS que se adjuntan a las tareas que mantiene un servicio cuando se crea o actualiza un servicio. Se adjunta un volumen por tarea.    
`encrypted`  
Tipo: Booleano  
Obligatorio: no  
Valores válidos: `true`\$1`false`  
Especifica si se debe cifrar cada volumen de Amazon EBS que se crea. Si activó el cifrado de Amazon EBS de manera predeterminada para una Región de AWS particular para su Cuenta de AWS, pero configuró este parámetro como `false`, este parámetro se anulará y los volúmenes se cifrarán con la clave de KMS especificada para el cifrado de manera predeterminada. Para obtener más información acerca del cifrado de Amazon EBS de manera predeterminada, consulte [Activación del cifrado de Amazon EBS de manera predeterminada](https://docs.aws.amazon.com/ebs/latest/userguide/encryption-by-default.html) en la *Guía del usuario de Amazon EBS*. Para obtener más información sobre el cifrado de los volúmenes de Amazon EBS adjuntos a tareas de Amazon ECS, consulte [Datos cifrados almacenados en volúmenes de Amazon EBS adjuntos a tareas de Amazon ECS](ebs-kms-encryption.md).  
`kmsKeyId`  
Tipo: cadena  
Requerido: no  
El identificador de AWS Key Management Service (AWS KMS) para utilizar el cifrado de Amazon EBS. Si se especifica `kmsKeyId`, el estado de cifrado debe ser `true`.  
 La clave especificada con este parámetro anula la clave de KMS predeterminada de Amazon EBS o cualquier clave de KMS a nivel de clúster para el cifrado de almacenamiento administrado por Amazon ECS que haya especificado. Para obtener más información, consulte [Datos cifrados almacenados en volúmenes de Amazon EBS adjuntos a tareas de Amazon ECS](ebs-kms-encryption.md).   
Puede indicar la clave de KMS mediante alguno de los métodos siguientes:  
+ **Id. de la clave**: por ejemplo, `1234abcd-12ab-34cd-56ef-1234567890ab`.
+ **Alias de la clave**: por ejemplo, `alias/ExampleAlias`.
+ **ARN de la clave**: por ejemplo, `arn:aws:kms:us-east-1:012345678910:key/1234abcd-12ab-34cd-56ef-1234567890ab`.
+ **ARN del alias**: por ejemplo, `arn:aws:kms:us-east-1:012345678910:alias/ExampleAlias`.
AWS autentica la clave de KMS de manera asíncrona. Por lo tanto, si indica un id., alias o ARN que no es válido, puede parecer que la acción es correcta, pero eventualmente produce un error. Para más información, consulte [Troubleshooting Amazon EBS volume attachment issues](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshoot-ebs-volumes.html).  
`volumeType`  
Tipo: cadena  
Requerido: no  
Valores válidos: `gp2`\$1`gp3`\$1`io1`\$1`io2`\$1`sc1`\$1`st1`\$1`standard`  
El tipo de volumen de Amazon EBS. Para obtener más información acerca de los tipos de volúmenes, consulte [Tipos de volúmenes de Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html) en la *Guía del usuario de Amazon EBS*. El tipo de volumen predeterminado es `gp3`.  
El tipo de volumen `standard` no se admite para las tareas de Fargate.  
`sizeInGiB`  
Tipo: entero  
Obligatorio: no  
Rango válido: números enteros entre 1 y 16 384   
El tamaño del volumen de EBS en gibibytes (GiB). Si no proporciona un id. de instantánea para configurar un volumen para adjuntarlo, debe proporcionar un valor de tamaño. Si configura un volumen para adjuntarlo mediante una instantánea, el valor predeterminado es el tamaño de la instantánea. Puede indicar un tamaño superior o igual al tamaño de la instantánea.  
Para los tipos de volúmenes `gp2` y `gp3`, el rango válido es de 1 a 16 384.  
Para los tipos de volúmenes `io1` y `io2`, el rango válido es de 4 a 16 384.  
Para los tipos de volúmenes `st1` y `sc1`, el rango válido es de 125 a 16 384.  
Para el tipo de volúmenes `standard`, el rango válido es de 1 a 1024.  
`snapshotId`  
Tipo: cadena  
Requerido: no  
El ID de la instantánea de un volumen de Amazon EBS existente que Amazon ECS utiliza para crear nuevos volúmenes que se adjuntarán. Debe especificar un valor `snapshotId` o `sizeInGiB`.  
`volumeInitializationRate`  
Tipo: entero  
Obligatorio: no  
La velocidad, en MiB/s, a la que se obtienen los datos de una instantánea de un volumen de Amazon EBS existente para crear nuevos volúmenes que se adjuntarán. Esta propiedad solo se puede especificar si especifica un valor de `snapshotId`. Para obtener más información sobre la tasa de inicialización de volúmenes, incluidos consulte el rango de tasas compatibles con la inicialización, consulte [Inicialización de volúmenes de Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/initalize-volume.html) en la *Guía del usuario de Amazon EBS*.  
`iops`  
Tipo: entero  
Obligatorio: no  
Número de operaciones de E/S por segundo (IOPS). Para los volúmenes `gp3`, `io1` y `io2`, esto representa el número de IOPS aprovisionadas para el volumen. Para los volúmenes `gp2`, este valor representa el rendimiento de referencia del volumen y la velocidad a la que el volumen acumula créditos de E/S para ráfaga. Este parámetro es obligatorio para los volúmenes `io1` y `io2`. Este parámetro no es compatible con los volúmenes de `gp2`, `st1`, `sc1` o `standard`.   
Para los volúmenes de `gp3`, el rango de valores válido es de 3000 a 16 000.  
Para los volúmenes de `io1`, el rango de valores válido es de 100 a 64 000.  
Para los volúmenes de `io2`, el rango de valores válido es de 100 a 64 000.  
`throughput`  
Tipo: entero  
Obligatorio: no  
El rendimiento necesario para aprovisionar los volúmenes adjuntos a tareas que mantiene un servicio.  
Este parámetro solo es compatible solo con los volúmenes de `gp3`.  
`roleArn`  
Tipo: cadena  
Obligatorio: sí  
El ARN de recursos de Amazon (ARN) del rol de AWS Identity and Access Management (IAM) de la infraestructura que proporciona los permisos de Amazon ECS para administrar los recursos de Amazon EBS para las tareas. Para obtener más información, consulte [Rol de IAM de infraestructura de Amazon ECS](infrastructure_IAM_role.md).  
`tagSpecifications`  
Tipo: objeto  
Obligatorio: no  
Indicación para que las etiquetas se apliquen a cada volumen de Amazon EBS.    
`resourceType`  
Tipo: cadena  
Obligatorio: sí  
Valores válidos: -.: `volume`  
El tipo de recurso que se debe etiquetar en la creación.  
`tags`  
Tipo: matriz de objetos   
Obligatorio: no  
Los metadatos que se aplican a los volúmenes para categorizarlos y organizarlos. Cada etiqueta está formada por una clave y un valor opcional, ambos definidos por el usuario. `AmazonECSCreated` y `AmazonECSManaged` son etiquetas reservadas que Amazon ECS agrega en su nombre, por lo que puede indicar un máximo de 48 etiquetas propias. Cuando se elimina un volumen, también se eliminan las etiquetas. Para obtener más información, consulte [Etiquetado de los recursos de Amazon ECS](ecs-using-tags.md).    
`key`  
Tipo: cadena  
Limitaciones de longitud: longitud mínima de 1. Longitud máxima de 128.  
Obligatorio: no  
Una parte de un par clave-valor que compone una etiqueta. Un clave es una etiqueta general que actúa como una categoría para valores de etiqueta más específicos.  
`value`  
Tipo: cadena  
Limitaciones de longitud: longitud mínima de 0. La longitud máxima es de 256 caracteres.  
Obligatorio: no  
La parte opcional de un par clave-valor que compone una etiqueta. Un valor actúa como un descriptor en una categoría de etiquetas (clave).  
`propagateTags`  
Tipo: cadena  
Valores válidos: `TASK_DEFINITION` \$1 `SERVICE` \$1 `NONE`  
Obligatorio: no  
Indica si se deben copiar las etiquetas de la definición de tareas o el servicio en un volumen. Si se indica `NONE` o no se indica ningún valor, las etiquetas no se copian.  
`fileSystemType`  
Tipo: cadena  
Requerido: no  
Valores válidos: `xfs`\$1`ext3`\$1`ext4`\$1`NTFS`  
Tipo de sistema de archivos de un volumen. El tipo de sistema de archivos del volumen determina cómo se almacenan y recuperan los datos en el volumen. En el caso de los volúmenes creados a partir de una instantánea, debe especificar el mismo tipo de sistema de archivos que utilizaba el volumen cuando se creó la instantánea. Si hay un error de coincidencia con el tipo de sistema de archivos, la tarea no podrá iniciarse.   
Los valores válidos para Linux son `xfs`, ext3`, and ext4`. El valor predeterminado para los volúmenes adjuntos a las tareas de Linux es `XFS`.  
Los valores válidos para Windows son `NTFS`. El valor predeterminado para los volúmenes adjuntos a las tareas de Windows es `NTFS`.

# Plantilla de definición de servicio
<a name="sd-template"></a>

A continuación, se muestra la representación JSON de una definición de servicio de Amazon ECS.

EC2

```
{
    "cluster": "", 
    "serviceName": "", 
    "taskDefinition": "", 
    "loadBalancers": [
        {
            "targetGroupArn": "", 
            "loadBalancerName": "", 
            "containerName": "", 
            "containerPort": 0
        }
    ], 
    "serviceRegistries": [
        {
            "registryArn": "", 
            "port": 0, 
            "containerName": "", 
            "containerPort": 0
        }
    ], 
    "desiredCount": 0, 
    "clientToken": "", 
    "launchType": "EC2", 
    "capacityProviderStrategy": [
        {
            "capacityProvider": "", 
            "weight": 0, 
            "base": 0
        }
    ], 
    "platformVersion": "", 
    "role": "", 
    "deploymentConfiguration": {
        "deploymentCircuitBreaker": {
            "enable": true, 
            "rollback": true
        }, 
        "maximumPercent": 0, 
        "minimumHealthyPercent": 0, 
        "alarms": {
            "alarmNames": [
                ""
            ], 
            "enable": true, 
            "rollback": true
        }
    }, 
    "placementConstraints": [
        {
            "type": "distinctInstance", 
            "expression": ""
        }
    ], 
    "placementStrategy": [
        {
            "type": "binpack", 
            "field": ""
        }
    ], 
    "networkConfiguration": {
        "awsvpcConfiguration": {
            "subnets": [
                ""
            ], 
            "securityGroups": [
                ""
            ], 
            "assignPublicIp": "DISABLED"
        }
    }, 
    "healthCheckGracePeriodSeconds": 0, 
    "schedulingStrategy": "REPLICA", 
    "deploymentController": {
        "type": "EXTERNAL"
    }, 
    "tags": [
        {
            "key": "", 
            "value": ""
        }
    ], 
    "enableECSManagedTags": true, 
    "propagateTags": "TASK_DEFINITION", 
    "enableExecuteCommand": true, 
    "availabilityZoneRebalancing": "ENABLED",
    "serviceConnectConfiguration": {
        "enabled": true, 
        "namespace": "", 
        "services": [
            {
                "portName": "", 
                "discoveryName": "", 
                "clientAliases": [
                    {
                        "port": 0, 
                        "dnsName": ""
                    }
                ], 
                "ingressPortOverride": 0
            }
        ], 
        "logConfiguration": {
            "logDriver": "journald", 
            "options": {
                "KeyName": ""
            }, 
            "secretOptions": [
                {
                    "name": "", 
                    "valueFrom": ""
                }
            ]
        }
    }, 
    "volumeConfigurations": [
        {
            "name": "", 
            "managedEBSVolume": {
                "encrypted": true, 
                "kmsKeyId": "", 
                "volumeType": "", 
                "sizeInGiB": 0, 
                "snapshotId": "", 
                "volumeInitializationRate": 0,
                "iops": 0, 
                "throughput": 0, 
                "tagSpecifications": [
                    {
                        "resourceType": "volume", 
                        "tags": [
                            {
                                "key": "", 
                                "value": ""
                            }
                        ], 
                        "propagateTags": "NONE"
                    }
                ], 
                "roleArn": "", 
                "filesystemType": ""
            }
        }
    ]
}
```

Fargate

```
{
    "cluster": "", 
    "serviceName": "", 
    "taskDefinition": "", 
    "loadBalancers": [
        {
            "targetGroupArn": "", 
            "loadBalancerName": "", 
            "containerName": "", 
            "containerPort": 0
        }
    ], 
    "serviceRegistries": [
        {
            "registryArn": "", 
            "port": 0, 
            "containerName": "", 
            "containerPort": 0
        }
    ], 
    "desiredCount": 0, 
    "clientToken": "", 
    "launchType": "FARGATE", 
    "capacityProviderStrategy": [
        {
            "capacityProvider": "", 
            "weight": 0, 
            "base": 0
        }
    ], 
    "platformVersion": "", 
    "platformFamily": "",
    "role": "", 
    "deploymentConfiguration": {
        "deploymentCircuitBreaker": {
            "enable": true, 
            "rollback": true
        }, 
        "maximumPercent": 0, 
        "minimumHealthyPercent": 0, 
        "alarms": {
            "alarmNames": [
                ""
            ], 
            "enable": true, 
            "rollback": true
        }
    }, 
    "placementStrategy": [
        {
            "type": "binpack", 
            "field": ""
        }
    ], 
    "networkConfiguration": {
        "awsvpcConfiguration": {
            "subnets": [
                ""
            ], 
            "securityGroups": [
                ""
            ], 
            "assignPublicIp": "DISABLED"
        }
    }, 
    "healthCheckGracePeriodSeconds": 0, 
    "schedulingStrategy": "REPLICA", 
    "deploymentController": {
        "type": "EXTERNAL"
    }, 
    "tags": [
        {
            "key": "", 
            "value": ""
        }
    ], 
    "enableECSManagedTags": true, 
    "propagateTags": "TASK_DEFINITION", 
    "enableExecuteCommand": true, 
    "availabilityZoneRebalancing": "ENABLED",
    "serviceConnectConfiguration": {
        "enabled": true, 
        "namespace": "", 
        "services": [
            {
                "portName": "", 
                "discoveryName": "", 
                "clientAliases": [
                    {
                        "port": 0, 
                        "dnsName": ""
                    }
                ], 
                "ingressPortOverride": 0   
            }
        ], 
        "logConfiguration": {
            "logDriver": "journald", 
            "options": {
                "KeyName": ""
            }, 
            "secretOptions": [
                {
                    "name": "", 
                    "valueFrom": ""
                }
            ]
        }
    }, 
    "volumeConfigurations": [
        {
            "name": "", 
            "managedEBSVolume": {
                "encrypted": true, 
                "kmsKeyId": "", 
                "volumeType": "", 
                "sizeInGiB": 0, 
                "snapshotId": "", 
                "volumeInitializationRate": 0, 
                "iops": 0, 
                "throughput": 0, 
                "tagSpecifications": [
                    {
                        "resourceType": "volume", 
                        "tags": [
                            {
                                "key": "", 
                                "value": ""
                            }
                        ], 
                        "propagateTags": "NONE"
                    }
                ], 
                "roleArn": "", 
                "filesystemType": ""
            }
        }
    ]
}
```

Puede crear esta plantilla de definición de servicio mediante el siguiente comando de la AWS CLI.

```
aws ecs create-service --generate-cli-skeleton
```