Gestionar aplicaciones en producción implica mantener un estado de «siempre activo» pese a las interrupciones. En entornos a gran escala, las fallas en la infraestructura, la ralentización de dependencias o las particiones de red no son excepciones, sino una condición habitual. Por ello, resistir y recuperarse de estas incidencias no es opcional, sino esencial.
En la práctica, esto se traduce en momentos familiares para muchos: un cliente detecta una caída, se dispara una alerta, y las causas pueden ser muy variadas. Por ejemplo, una GPU que genera fallos de hardware afectando tareas en una instancia, un evento de red en una zona de disponibilidad, o un backend de registro que ralentiza el rendimiento de la aplicación. Estos escenarios no avisan previamente y requieren respuestas inmediatas, lo que puede resultar complicado para los equipos responsables.
Amazon Elastic Container Service (ECS) busca gestionar gran parte de estas incidencias de forma automática. La recuperación ante fallos es un eje fundamental en el diseño y desarrollo de ECS, de modo que no sea necesario que los usuarios creen complejas rutinas de detección y remediación para problemas que la plataforma ya puede enfrentar sola. Para situaciones menos claras o que dependen del tipo de carga, ECS ofrece herramientas para que los responsables decidan cómo actuar. 
Este enfoque se sustenta en principios de resiliencia que apuntamos en análisis previos, como estabilidad estática entre zonas de disponibilidad, preescalado de capacidad e aislamiento de cargas. Sobre estas bases, se añaden mecanismos de recuperación específicos con controles detallados para cada caso.
Según el modelo de responsabilidad compartida de AWS, la empresa responde por la resiliencia de la nube —la infraestructura subyacente—, mientras que el usuario debe asegurar la resiliencia en la nube, es decir, diseñar aplicaciones que toleren y se recuperen ante fallos. ECS toma lecciones y patrones del lado «de la nube» y los pone a disposición del usuario para facilitar la operación y reducir la carga manual.
Automatización en la recuperación de instancias dañadas
Los fallos más disruptivos pueden originarse en la instancia que hospeda las tareas. Si una instancia comienza a fallar, todas las tareas que ejecuta están en riesgo, y cuanto más tiempo permanezca defectuosa, mayor será el alcance del problema. Por tanto, es crucial detectar rápidamente un estado degradado y retirar la instancia para evitar propagación.
Un caso concreto es el de cargas de trabajo que utilizan GPUs para inferencia en flotas de instancias aceleradas. Si la GPU presenta errores ECC corregibles que derivan en fallos, las tareas se ralentizan o fallan. También pueden sufrirse eventos negativos por particiones de red, problemas térmicos, o degradación de volúmenes EBS, que afectan el rendimiento y ponen en peligro a las tareas activas.
Antes, detectar y manejar estas situaciones requería automatizaciones propias para monitorear instancias afectadas, descargar tareas y reiniciar instancias, manteniendo dicho sistema en escala. Ahora ECS realiza todo esto automáticamente. Para detectar fallos en GPUs, se integra con NVIDIA Data Center GPU Manager (DCGM) que identifica errores reales de hardware y separa esos problemas de advertencias no críticas.
Además, ECS supervisa la salud general de la instancia de plano de datos, incluyendo chequeos de EC2 y componentes internos como el agente ECS y el runtime de contenedores. Si el agente pierde conectividad prolongada con el plano de control, la instancia queda en estado «caja negra», dificultando detener y reemplazar tareas. ECS detecta esta desconexión y marca la instancia como degradada, reemplazándola según corresponda.
Este ciclo constante de vigilancia y reparación se ejecuta sin intervención y sin coste adicional, y puede monitorearse vía la API DescribeContainerInstances y eventos publicados en Amazon EventBridge, especialmente para instancias ECS en EC2 gestionadas por el usuario.
Gestión inteligente de zonas de disponibilidad comprometidas
Las zonas de disponibilidad proporcionan aislamiento de fallos dentro de una región, pero la ventaja solo se nota si la aplicación soporta la pérdida de una de ellas. Ante una zona degradada, las tareas restantes se acumulan en zonas sanas y el tráfico interzona puede aumentar el impacto. Rebalancear manualmente resulta lento y propenso a errores.
ECS supervisa continuamente la salud de las zonas y, ante señales como fallos al lanzar tareas o eventos de otros servicios, desvía automáticamente la colocación de nuevas tareas e instancias a otras zonas saludables hasta que la problemática se resuelva. Además, su mecanismo de rebalancing despliega nuevas tareas en zonas menos cargadas antes de detener tareas en las más saturadas para restaurar un reparto equitativo de cargas.
Por defecto, ECS distribuye las tareas de sus servicios uniformemente entre zonas de disponibilidad. Para mejorar aún más la resiliencia, se recomienda preescalar capacidad, garantizando suficiente margen en las zonas primarias para soportar la carga si una zona falla. Las aplicaciones que usan Service Connect pueden habilitar el enrutamiento consciente de zona, que dirige peticiones a puntos de conexión en la misma zona, minimizando el tráfico interzona y su exposición a problemas.
Recuperación eficiente de contenedores individuales
En ocasiones, la falla afecta a un único contenedor dentro de una tarea que está por lo demás sana. En tales casos, es preferible reiniciar solo ese contenedor sin reprogramar la tarea completa, evitando perder trabajo útil y reducir la carga sobre el planificador y la flota.
Por ejemplo, una tarea puede incluir un contenedor principal y varios secundarios (sidecars) como agentes de métricas o proxies. Si uno de los sidecars falla, ECS puede reiniciarlo automáticamente con una política de reinicio, manteniendo la tarea en línea y minimizando interrupciones. Se puede configurar cuáles contenedores son elegibles para reinicio y qué códigos de salida no deben reintentarse para evitar bucles de reinicios innecesarios.
Esta filosofía se extiende al lanzamiento de tareas: si la descarga de una imagen falla pero esta está ya cacheada en la instancia, ECS usa la copia local para iniciar la tarea, sortear caídas transitorias en el registro o la red y no perder capacidad.
Configuraciones predeterminadas más seguras y flexibles
Aunque la resiliencia de la aplicación es responsabilidad del usuario, ECS ha adoptado ciertos patrones óptimos para facilitar mejores prácticas sin necesidad de configuración adicional. Un ejemplo clave es el cambio en el comportamiento por defecto de la entrega de logs.
Antes, la emisión de logs usaba un modo bloqueante que podía afectar la disponibilidad si el backend de logging se ralentizaba o fallaba, ya que la aplicación quedaba bloqueada esperando la entrega. Para evitarlo, ECS introdujo la entrega no bloqueante que descarta logs no entregados en lugar de bloquear el contenedor, incrementando la disponibilidad a costa de perder algunos logs.
Este cambio se implementó gradualmente, permitiendo a aquellos que necesitan garantía total optar por el modo bloqueante. Hoy, el modo no bloqueante es la configuración por defecto, aplicada automáticamente a servicios existentes y nuevos, favoreciendo la disponibilidad general de las aplicaciones.
Otras configuraciones por defecto que impulsan la disponibilidad incluyen la distribución automática de tareas entre zonas, inicio de tareas de reemplazo antes de detener las existentes durante drenajes y despliegues, y la sustitución de tareas fallidas por versiones fiables ya existentes en vez de versiones nuevas potencialmente inestables.
Pruebas prácticas y personalización
ECS está integrado con el AWS Fault Injection Service (FIS) para que los usuarios puedan probar la resiliencia de sus aplicaciones mediante experimentos controlados de fallos. Esto incluye desde detener tareas hasta inyectar fallos en recursos y redes, permitiendo validar que mecanismos internos de recuperación respondan como se espera.
En particular, para fallos de red, es posible simular latencia, pérdida de paquetes o interrupciones completas, comprobando que tiempos de espera, reintentos y estrategias de contingencia estén adecuadamente configurados.
En resumen, ECS automatiza la gran mayoría del trabajo repetitivo y complejo de detección y recuperación ante fallos en instancias, GPUs, contenedores y zonas, dejando la decisión final en manos del usuario en los casos que requieren matices. Esto libera recursos para diseñar una resiliencia específica de cada aplicación y facilita poner a prueba esa resistencia antes de una incidencia real.
Para profundizar en los fundamentos de estas medidas, Amazon ofrece documentación extensa y composiciones técnicas detalladas que aconsejan aplicarlas como punto de partida, adaptándolas a las necesidades concretas de cada carga de trabajo.
