AWS ha lanzado recientemente ECS Managed Instances, una nueva opción de cómputo dentro de Amazon ECS (Elastic Container Service) que busca resolver un dilema clásico: elegir entre el control total de EC2 y la comodidad operativa de Fargate.
Hasta ahora, ECS ofrecía dos modos de ejecución muy distintos. Con EC2 launch type, los equipos gestionaban sus propias instancias, lo que daba máxima flexibilidad pero también conlleva más carga operativa. Con Fargate, AWS se ocupaba de todo, aunque a costa de perder visibilidad y capacidad de optimización sobre el hardware.
Managed Instances se posiciona justo entre las dos opciones existentes. Mantiene la base de EC2, pero delega en AWS la gestión del ciclo de vida de las instancias, el parcheo del sistema operativo y el escalado automático del clúster.
Características principales
ECS Managed Instances aprovisiona y escala las instancias de forma dinámica, consolidando tareas para aprovechar mejor los recursos y apagar los nodos inactivos. Teoricamente, esto permite mantener costes bajos y una utilización de CPU más eficiente.
La elección de instancias es flexible: puedes dejar que ECS seleccione automáticamente el tipo más rentable (ECS default) o definir tus propios criterios custom de hardware, red y arquitectura.
Además, el servicio se integra con el resto del ecosistema ECS sin cambios de configuración. Los servicios, tareas y despliegues funcionan igual que con EC2 o Fargate, lo que facilita su adopción en entornos existentes.
En cuanto a disponibilidad, la feature está ya desplegada en varias regiones, incluidas us-east-1, us-west-2 y eu-west-1, con expansión progresiva al resto de regiones comerciales.
¿Por qué usar esta opción?
El objetivo de ECS Managed Instances es claro: simplificar la operación de los entornos ECS sin renunciar al control del cómputo subyacente.
En lugar de tener que aprovisionar y mantener manualmente las instancias EC2, AWS se encarga de hacerlo por ti, eligiendo los tipos más eficientes según tus requisitos de CPU, memoria, arquitectura o incluso GPU.
Para entornos en los que Fargate resulta demasiado opaco, Managed Instances ofrece un punto de equilibrio muy interesante. Reduce la complejidad sin perder la posibilidad de afinar el rendimiento o aprovechar tus Savings Plans y reservas existentes de EC2.
Managed Instances tiene un enfoque muy elevado en la seguridad y el mantenimiento automático. Las instancias gestionadas utilizan Bottlerocket, el sistema operativo optimizado para contenedores de AWS, que se parchea y actualiza de forma continua, eliminando buena parte de las tareas rutinarias de mantenimiento.
¿Cuándo usar esta opción?
Managed Instances es ideal cuando necesitas personalizar el tipo de instancia (usar GPU, evitar instancias burstable, etc), pero no quieres invertir tiempo en gestionar un clúster de EC2. También cuando deseas aprovechar descuentos de EC2 o reducir los costes de Fargate sin asumir toda la complejidad operativa.
Por el contrario, si tus cargas son muy efímeras o totalmente desacopladas del hardware, Fargate seguirá siendo la opción más simple.
Prueba práctica con ECS Managed Instances
Para poner a prueba esta nueva funcionalidad, preparamos un entorno siguiendo la guía oficial de AWS.
La configuración inicial se realizó usando la opción ECS default para la selección de instancias, de modo que fuese el propio servicio quien eligiera automáticamente los tipos más adecuados en función de los requisitos definidos en la task definition.
Escenario de prueba y primeras ejecuciones
Creamos un servicio en ECS con una definición de tarea que incluía un único contenedor, configurado con 1 vCPU y 2 GB de RAM. El servicio estaba habilitado con Availability Zone Rebalancing, de forma que ECS pudiera distribuir las tareas de manera uniforme entre las dos zonas de disponibilidad seleccionadas.
A partir de ahí fuimos ajustando el número de tareas en ejecución (6, 5 y 4) para observar cómo el sistema gestionaba la capacidad y el aprovisionamiento de instancias.
En la imagen superior puede verse el resultado de la primera prueba. Con 6 tareas simultáneas, ECS seleccionó varios tipos de instancia (como c6a.xlarge, m7a.medium y m5a.large). La combinación no parece la más eficiente desde el punto de vista del coste y da margen a seleccionar mejor el tipo de instancia.
Al revisar una de las instancias gestionadas (ver imagen inferior) comprobamos que quedaban recursos disponibles no utilizados, especialmente memoria y CPU, lo que sugiere que la lógica de asignación automática aún tiene margen de mejora en este tipo de escenarios.
Ajuste de recursos y observaciones
En la prueba anterior observamos que en las instancias gestionadas no perdemos CPU a asignar a los contenedores pero si perdemos algo de memoria. Por este motivo, quisimos comprobar si el comportamiento de asignación de instancias cambiaba con cargas más pequeñas. Para ello, modificamos la task definition para usar 0,5 vCPU y 0,4 GB de RAM por contenedor. También modificamos el servicio para definir el número de tareas deseadas a 4.
Tras dichos cambios, el resultado fue similar al anterior. ECS volvió a crear nuevas instancias sin aprovechar del todo combinaciones que podrían haber resultado más eficientes económicamente.
En la imagen superior se observa cómo el sistema distribuye 4 tareas entre 3 instancias activas, manteniendo un equilibrio correcto a nivel operativo, aunque con cierta infrautilización de recursos. La realidad es que las cargas se podían ejecutar en 2 instancias del tipo c7a.medium, una en cada zona de disponibilidad, con el consiguiente ahorro al eliminar una instancia.
La visión de Cloudner
La experiencia nos deja una impresión agridulce, pero prometedora si se configura el tipo de instancia de forma custom.
Por un lado, ECS Managed Instances ha gestionado de forma completamente autónoma la creación y eliminación de instancias para adaptarse a la capacidad esperada. El escalado ha sido estable, rápido y sin intervención manual. Por otro, la selección de tipos de instancia podría afinarse más. El modo ECS default tiende a elegir combinaciones que funcionan correctamente, pero no siempre maximizan la eficiencia económica.
Por eso, aunque esta feature simplifica la operación, sigue siendo importante contar con una estrategia de optimización de costes y arquitectura, especialmente en entornos productivos.
Servicios como los que ofrecemos en Cloudner ayudan precisamente a analizar patrones de consumo, identificar ineficiencias y ajustar tanto la configuración de ECS Managed Instances como las reservas EC2 para alcanzar el equilibrio perfecto entre coste, rendimiento y resiliencia.
¿Quieres revisar cómo optimizar los costes de tu infraestructura en AWS? Hablemos.