Introducción
Cualquier equipo que gestione despliegues en Amazon ECS con estrategias Canary o Blue/Green conoce el ritual: lanzás un servicio, abrí CloudWatch para seguir métricas de health checks, saltás a CloudTrail para verificar eventos de tareas, consultás el Application Load Balancer para confirmar la distribución de tráfico entre revisions, y cruzás todo con un dashboard propio en Grafana. Cuatro herramientas, tres pestañas, y un SRE intentando correlacionar en su cabeza si el circuit breaker está a punto de disparar mientras los tasks del target revision todavía no pasaron el bake time.
Amazon ECS resolvió ese fragmento del flujo de trabajo con una actualización que integra observabilidad de despliegue en tiempo real directamente en la consola del servicio. La funcionalidad cubre las tres estrategias nativas —Linear, Canary y Blue/Green— y concentra timeline, señales de salud, eventos de tareas y contexto de diagnóstico en una única vista operativa. No es un reemplazo de CloudWatch ni de un stack de observabilidad completo, pero elimina la fricción de tener que armar manualmente la correlación entre señales dispersas durante los minutos críticos de un rollout.
Qué ocurrió
AWS lanzó en septiembre de 2026 la capacidad de observabilidad en tiempo real para despliegues de servicios ECS dentro de la Amazon ECS Management Console. El acceso se realiza navegando a cualquier servicio ECS y seleccionando la pestaña Deployments. Desde ahí, el operador visualiza un timeline vivo que narra cada fase del despliegue conforme avanza: escalado de tareas, distribución progresiva de tráfico, hooks de ciclo de vida, y transiciones de estado de tasks individuales.
La actualización no introduce un nuevo servicio ni un nuevo agente. Se trata de una capa de visualización y correlación que consume datos que ECS ya generaba internamente —eventos de tasks, estado del circuit breaker, health checks del ALB y del contenedor, alarmas asociadas— y los presenta de forma unificada con contexto temporal. Para estrategias Blue/Green, el timeline muestra explícitamente en qué etapa está el despliegue: si está escalando tasks del target, si está esperando un lifecycle hook, o si está dentro del periodo de bake time antes de promover el tráfico. En Canary, la distribución de tráfico entre source revision y target revision se visualiza como un porcentaje en vivo que se actualiza a medida que avanzan los steps configurados.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
El impacto más inmediato es operativo: reduce el tiempo medio de detección (MTTD) durante despliegues fallidos. Antes, un SRE que recibía una alerta de task failure durante un Canary rollout necesitaba entre 3 y 8 minutos para abrir CloudWatch, identificar el alarm arn, correlacionar el timestamp con el step del despliegue, y verificar si el circuit breaker había alcanzado el umbral. Con la vista unificada, esa correlación es inmediata en el propio timeline.
Para equipos que gestionan múltiples servicios ECS en paralelo, el cambio reduce la carga cognitiva. Un despliegue Blue/Green con 200 tasks y tres lifecycle hooks (pre-traffic, post-traffic, rollback) genera decenas de eventos que antes se dispersaban entre DescribeService, ListTasks, DescribeTaskDefinition y los logs de CloudTrail. La consola ahora presenta esos eventos inline con deep links a los recursos específicos.
Desde la perspectiva de seguridad, la integración con CloudTrail en el contexto de fallas de tasks permite auditar rápidamente si un task falló por una condición de imagen no permitida, una policy de IAM insuficiente, o una vulnerabilidad detectada en el scan del contenedor. Esto acorta el ciclo de respuesta ante incidentes que involucran despliegues.
Detalles técnicos
La funcionalidad aplica a los tres deployment types nativos de ECS:
- Linear: progresión escalonada de tasks entre revisions con steps configurables.
- Canary: distribución porcentual de tráfico entre source y target revision, con alarmas que controlan la transición.
- Blue/Green: dos environments completos con promoción de tráfico tras un bake time y hooks de ciclo de vida.
Las señales que se muestran en la vista unificada incluyen:
Circuit breakerEstado en vivo, conteo de task failures, umbral configuradoDeployment alarmsEstado de cada alarma asociada al despliegue (OK / ALARM / INSUFFICIENT_DATA)Health checksResultado de health checks del contenedor y del ALB por taskLifecycle hooksEstado de cada hook (PENDING, EXECUTING, COMPLETED) con timestampsTask lifecycleEventos de PENDING, RUNNING, STOPPED, DEACTIVATING con códigos de salidaTraffic shiftPorcentaje de tráfico en source vs. target, actualizado en tiempo realLos eventos de tasks fallidas incluyen contexto diagnóstico: el stopCode y stopReason del task, junto con deep links directos a los eventos correspondientes en CloudTrail para trazabilidad completa.
El despliegue se visualiza siempre reflejando el estado actual del servicio, no un snapshot estático. Si un task entra en estado STOPPED con código EssentialContainerExited, el timeline lo marca en rojo con el código de salida del contenedor y un link al evento de CloudTrail.
Para habilitar la visualización, no se requiere configuración adicional más allá de tener el servicio ECS usando uno de los tres deployment types nativos. Los alarmas y health checks ya deben estar configurados como parte de la estrategia de despliegue:
# Verificar que el servicio usa un deployment type nativo con circuit breaker
aws ecs describe-services \
–cluster mi-cluster \
–services mi-servicio \
–query ‘services[0].deployments[0].{status:status,strategy:blueGreenDeployment}’ \
–output table
// Fragmento de deployment configuration con circuit breaker y alarms
{
«deploymentConfiguration»: {
«deploymentCircuitBreaker»: {
«enable»: true,
«rollback»: true
},
«deploymentController»: {
«type»: «CODE_DEPLOY»
}
}
}
La disponibilidad abarca todas las AWS commercial Regions y las AWS GovCloud (US) Regions. No tiene costo adicional: no se factura por la visualización, ni se generan eventos de CloudWatch adicionales que incrementen la factura.
Qué deberían hacer los administradores y equipos técnicos
Primero, validá que tus servicios ECS estén usando uno de los deployment types soportados (Linear, Canary o Blue/Green nativos). Los servicios con deployment type ECS (rolling update clásico sin circuit breaker) no se benefician de la nueva vista. Ejecutá:
aws ecs describe-services \
–cluster mi-cluster \
–services mi-servicio \
–query ‘services[*].{name:serviceName,deploymentController:deploymentController.type,circuitBreaker:deploymentConfiguration.deploymentCircuitBreaker.enable}’
Segundo, configurá health checks tanto a nivel de contenedor como de ALB. Sin health checks activos, la vista de despliegue no tiene datos de salud para correlacionar. En el target group del ALB:
aws elbv2 modify-target-group-attributes \
–target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/mi-tg/abc123 \
–attributes Key=health_check.enabled,Value=true Key=health_check.healthy_threshold_count,Value=3 Key=health_check.interval,Value=10
Tercero, asociá al menos una CloudWatch alarm al despliegue para que el circuit breaker tenga una señal externa que evaluar. Sin alarms, el circuit breaker solo monitorea task failures internos y la vista de observabilidad pierde una dimensión clave.
Cuarto, actualizá los runbooks de incidentes de despliegue. Los procedimientos que antes indicaban «abrir CloudWatch y buscar el alarm arn» ahora pueden referenciar la pestaña Deployments de la consola ECS como primera fuente de correlación. Esto reduce el tiempo de triage en despliegues fallidos.
Quinto, si usás Terraform o CloudFormation para gestionar servicios ECS, verificá que las definiciones incluyan deployment_circuit_breaker y las alarms asociadas, para que la nueva observabilidad tenga datos completos desde el primer despliegue.
Conclusión
La observabilidad de despliegue en tiempo real dentro de la consola ECS no reemplaza un stack de monitoreo completo —no es un reemplazo de Datadog, New Relic o un Prometheus federado—, pero elimina el 70-80% del contexto que un SRE necesita durante los primeros minutos de un rollout problemático. La integración de timeline, circuit breaker, health checks y deep links a CloudTrail en una sola vista reduce la latencia entre la detección de una anomalía y la decisión de rollback.
Para equipos que ya operan ECS con estrategias Canary o Blue/Green, el cambio es inmediato: no requiere migración, no requiere agentes, no requiere costo. La recomendación es incorporarlo como paso uno en los runbooks de despliegue y verificar que las señales de salud estén correctamente configuradas para que la vista tenga datos que mostrar.
Fuentes
- https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-ecs-console-deployment-observability/