Orquestación de contenedores con Amazon ECS - Definición de tareas y diseño de servicios
Presentamos sistemáticamente desde el diseño de definiciones de tareas hasta estrategias de despliegue de servicios, diferenciación entre Fargate y EC2, y patrones de configuración de Auto Scaling.
Definición de tareas y diseño de clúster
La definición de tareas de ECS es una plantilla que describe las especificaciones de ejecución del contenedor en JSON. Una definición de tarea puede incluir múltiples contenedores, colocando contenedores de recolección de logs o proxy en la misma tarea con el patrón sidecar. Los tipos de lanzamiento son 2: EC2 y Fargate. Con el tipo de lanzamiento EC2 se requiere gestión de instancias pero se pueden utilizar GPU y AMIs personalizadas. Con el tipo de lanzamiento Fargate no se requiere gestión de infraestructura y se puede ejecutar solo especificando CPU y memoria por tarea. La gestión de revisiones de definiciones de tareas facilita el rollback a versiones anteriores. Las definiciones de tareas admiten ephemeralStorage (hasta 200 GiB) para expandir el almacenamiento temporal, útil para trabajos batch que generan grandes volúmenes de datos intermedios. Además, separar el rol de tarea (taskRoleArn) del rol de ejecución de tarea (executionRoleArn) permite gestionar independientemente los permisos de API de AWS del contenedor y los permisos de pull de imágenes/salida de logs siguiendo el principio de mínimo privilegio.
Servicios y estrategias de despliegue
Los servicios ECS mantienen el número deseado de tareas y reinician automáticamente las tareas que terminan anormalmente. Al integrarse con target groups de ALB, las tareas que fallan el health check se drenan automáticamente y se reemplazan con nuevas tareas. En rolling update se configuran minimumHealthyPercent y maximumPercent para reemplazar tareas gradualmente. Por ejemplo, con minimumHealthyPercent=50 y maximumPercent=200, se mantiene la mitad de las tareas existentes mientras se lanzan las nuevas, deteniendo las antiguas tras pasar el health check. En el despliegue Blue/Green con integración de CodeDeploy, se crea un nuevo task set de la nueva versión y se cambia el tráfico gradualmente, logrando despliegue con cero tiempo de inactividad. En producción, se recomienda usar hooks de CodeDeploy (BeforeAllowTraffic / AfterAllowTraffic) para ejecutar tests automatizados y auto-rollback a la versión anterior en 5 minutos si fallan. ECS Service Connect proporciona descubrimiento de servicios y balanceo de carga nativo entre servicios en ECS, eliminando la necesidad de configurar App Mesh o Cloud Map por separado.
Diferenciación entre Fargate y EC2
Fargate es un motor de cómputo serverless que no requiere gestión de instancias EC2. Se especifica vCPU y memoria por tarea, cobrando solo por el tiempo de ejecución. El tipo de lanzamiento EC2 es adecuado cuando se necesita selección de instancias, uso de GPU o AMIs personalizadas. Fargate Spot es para procesamiento por lotes y cargas de trabajo tolerantes a fallos, hasta un 70% más barato que Fargate normal. Con ECS Exec se puede iniciar un shell interactivo en un contenedor dentro de una tarea para depuración y resolución de problemas. Desde 2024, Fargate soporta hasta 16 vCPU / 120 GB de memoria por tarea, proporcionando capacidad suficiente para la mayoría de aplicaciones web y procesamiento de datos. El tipo de lanzamiento EC2 debe reservarse para cargas que requieren hardware especializado, como inferencia ML en instancias p5 con GPU NVIDIA H100 o uso de AWS Inferentia2 en instancias inf2. Para aprender exhaustivamente sobre orquestación de contenedores, consulte libros técnicos (Amazon).
Optimización de costos de ECS
Los precios de Fargate son de pago por uso de vCPU (aproximadamente 0.04048 dólares por hora) y memoria (aproximadamente 0.004445 dólares por GB-hora). Se aplican descuentos de hasta 50% con Compute Savings Plans. Con el tipo de lanzamiento EC2 se aprovechan instancias Spot y se maximiza la utilización de instancias con la estrategia de colocación de tareas (binpack). Se optimiza la CPU y memoria de la definición de tareas basándose en métricas de Container Insights, reduciendo la asignación excesiva de recursos. Se configura una política de seguimiento de objetivo en Auto Scaling del servicio para ajustar automáticamente el número de tareas basándose en la utilización de CPU. Un factor de costo frecuentemente ignorado son los cargos de ingesta de datos de CloudWatch Logs. Si los contenedores producen grandes volúmenes de logs, controle los niveles de log a través del driver awslogs o use FireLens (Fluent Bit) para filtrar logs innecesarios antes de enviarlos a CloudWatch, lo que puede ahorrar decenas de dólares al mes.
Mejores prácticas de diseño y trampas comunes
Al configurar healthCheck en una definición de tarea, no establecer un startPeriod (periodo de gracia) suficiente causa que aplicaciones con tiempos de inicio lentos entren en un ciclo de reinicio inmediatamente después del lanzamiento por fallo del health check. Para lenguajes que requieren calentamiento JIT como Java o .NET, establecer startPeriod en 60-120 segundos es práctico. Para comunicación entre tareas, se recomienda el modo de red awsvpc porque cada tarea obtiene su propia ENI, permitiendo control de acceso a nivel de tarea mediante security groups. Sin embargo, tenga en cuenta los límites de densidad de ENI (límites de ENI por tipo de instancia) que impiden empaquetar muchas tareas en instancias pequeñas. Para gestión de secretos, referencie valores de Secrets Manager o SSM Parameter Store directamente en el campo secrets de la definición de tarea en lugar de codificarlos en variables de entorno. Además, habilitar execute-command descuidadamente en producción permite ejecución de comandos arbitrarios vía sesiones SSM, por lo que restrinja estrictamente los usuarios mediante políticas IAM.
ECS vs. EKS - Elegir el orquestador adecuado
ECS es un orquestador nativo de AWS mientras que EKS es la oferta de Kubernetes gestionado. Si su equipo carece de experiencia operativa en Kubernetes y valora la integración estrecha con AWS (integración nativa con ALB sin ALB Controller, definiciones nativas en CloudFormation/SAM), ECS es apropiado. Por el contrario, si necesita portabilidad multi-cloud u on-premises, o desea aprovechar el ecosistema de herramientas OSS publicadas como Helm charts (Argo CD, Istio, Prometheus Operator, etc.), EKS tiene ventaja. Desde la perspectiva de carga operativa, ECS + Fargate tiene tanto el plano de control como el plano de datos gestionados por AWS con bajo costo de aprendizaje de YAML, ideal para equipos pequeños. EKS tiene un plano de control gestionado, pero aún aplican operaciones específicas de Kubernetes como actualizaciones de grupos de nodos, gestión de versiones de addons, diseño de RBAC y gestión de NetworkPolicy. En cuanto a costos, EKS tiene una tarifa de cluster de $0.10/hora (aproximadamente $74/mes) para el plano de control, mientras que ECS no tiene este costo fijo. Elija según las características de su carga de trabajo y las habilidades de su equipo.
Resumen
ECS proporciona gestión declarativa de contenedores mediante definiciones de tareas y recuperación automática y escalado mediante servicios. Ejecuta contenedores de forma serverless con Fargate y logra hasta 70% de reducción de costos con Fargate Spot. Realiza releases con cero tiempo de inactividad con rolling update y despliegue Blue/Green, y visualiza el rendimiento con Container Insights. Comprender trampas prácticas como el startPeriod del healthCheck y los límites de densidad de ENI, y simplificar la comunicación entre servicios con ECS Service Connect, son claves para operaciones estables en producción.