En el dinámico mundo del cloud computing, la optimización continua es clave. Recientemente, en Hackmetrix, emprendimos una migración significativa en nuestra infraestructura de AWS: movimos nuestros clústeres de Amazon ECS, tanto en entornos productivos como de desarrollo, de un modelo basado en instancias EC2 a uno completamente serverless con AWS Fargate.
Este artículo detalla nuestro viaje, los desafíos que enfrentamos, las soluciones que implementamos y, lo más importante, los beneficios tangibles que obtuvimos, especialmente en términos de seguridad y costos.
El Punto de Partida: Los Retos de un Clúster ECS sobre EC2
Nuestra configuración anterior consistía en un clúster ECS que corría sobre 44 instancias EC2 t3.small. Estas máquinas alojaban aproximadamente 32 microservicios, cada uno con diversos requerimientos de CPU y memoria, resultando en una distribución de entre cero y dos tareas por instancia. Como equipo DevOps, esta arquitectura nos presentaba varios desafíos operativos y de gestión.
Gestión de Instancias
La gestión de nuestro clúster de ECS sobre instancias EC2 presentaba bastante carga operativa de nuestra parte. Mantener actualizadas las imágenes de máquina de AWS (AMIs) y los agentes de ECS en las 44 instancias era una tarea que solía estar constantemente en el backlog.
Además, la responsabilidad directa de aplicar parches de seguridad al sistema operativo de estas instancias consumía un tiempo considerable y aumentaba el riesgo de exposición a vulnerabilidades, algo que en nuestra posición sería inaceptable. Finalmente, gestionar la capacidad del clúster, ya fuera añadiendo o quitando instancias EC2, era un proceso bastante manual sobre la configuración de los Auto Scaling Groups, que operaba de forma separada al escalado propio de los servicios.
Sobrecarga Operacional
Esta necesidad de monitorizar, mantener y asegurar el parque de servidores EC2 generaba una carga operativa considerable que desviaba el foco del equipo de tareas que realmente entregan valor al negocio.
Escalabilidad Limitada por Servicio
Con instancias EC2 fijas, escalar servicios individualmente de forma eficiente era difícil. Frecuentemente, teníamos capacidad de instancia subutilizada o, por el contrario, cuellos de botella si un servicio demandaba más recursos de los que su instancia anfitriona podía ofrecer sin afectar a otros servicios en la misma.
Control de Costos Difuso
Aunque las t3.small son económicas, la granularidad para optimizar costos era baja. Pagar por la capacidad de la instancia, independientemente de si las tareas ECS la utilizaban al máximo o no, dificultaba una gestión financiera precisa. El “desperdicio” por instancias con cero tareas era una preocupación.
La Transición a Fargate: Simplificación y Enfoque en la Seguridad
Como empresa de ciberseguridad, la robustez y la reducción de la superficie de ataque son muy importantes. La propuesta de migrar a AWS Fargate se alineaba perfectamente con estos objetivos, además de prometer mejoras en escalabilidad y costos.
Fargate, al ser un motor de cómputo serverless para contenedores, nos abstrae completamente de la gestión de los servidores subyacentes. Esto significa que AWS se encarga del aprovisionamiento, parcheo y mantenimiento de la infraestructura base.
Beneficios Clave y Estrategias Implementadas con Fargate
Seguridad Mejorada por Diseño
La adopción de Fargate ha traído consigo mejoras significativas en nuestra postura de seguridad. Principalmente, la eliminación de la gestión de servidores significa que ya no tenemos que administrar AMIs, agentes ECS a nivel de instancia, ni aplicar parches de sistema operativo; AWS se encarga de la seguridad de la infraestructura subyacente, lo que nos permite concentrar nuestros esfuerzos en la seguridad de nuestras aplicaciones y contenedores.
Esto también conlleva una reducción considerable de la superficie de ataque, ya que al no gestionar las instancias, se elimina el acceso SSH directo, un vector de ataque común, y la seguridad se enfoca en la configuración de Docker y las definiciones de tarea de ECS. Además, el aislamiento por tarea inherente a Fargate, donde cada tarea se ejecuta en su propio entorno aislado, mejora nuestra postura de seguridad en comparación con el modelo anterior donde múltiples tareas compartían los recursos de una misma instancia EC2.
Escalabilidad Granular y Dinámica
Con Fargate, hemos optimizado significativamente la escalabilidad y los costos de nuestros servicios. La capacidad de definir políticas de autoscaling a nivel de servicio ECS nos permite que cada microservicio escale de forma independiente según su demanda específica de CPU o memoria, eliminando la preocupación por la capacidad de las instancias EC2 subyacentes. Además, hemos podido configurar fácilmente nuestros servicios para asegurar una alta disponibilidad con dos o más tareas durante las horas de mayor demanda, mientras reducimos la capacidad al mínimo —incluso a cero tareas para ciertos servicios de desarrollo— durante las horas no laborales, lo que ha resultado en una optimización considerable de los costos.
Optimización de Costos Inteligente
Para optimizar aún más nuestros costos en Fargate, hemos implementado dos estrategias clave:
Primero, utilizamos activamente las recomendaciones de AWS Cost Explorer para realizar un “rightsizing” adecuado, ajustando con precisión los recursos de CPU y memoria asignados a cada tarea y evitando así el sobreaprovisionamiento.
Segundo, para lograr una alta disponibilidad de manera costo-efectiva, hemos configurado un “capacity provider” que nos permite ejecutar las tareas base como Fargate bajo demanda, garantizando la disponibilidad mínima, mientras que las réplicas adicionales escalan utilizando Fargate Spot.
Esta combinación nos proporciona la resiliencia necesaria a un costo significativamente menor, especialmente para aquellas cargas de trabajo que pueden tolerar interrupciones.
Resultados Medibles
- Ambientes de Desarrollo: Al ejecutar la mayoría de las tareas como Fargate Spot, logramos una reducción de costos del 35% entre enero y abril.}
- Ambiente de Producción: Vimos una reducción del 20%, pero con un beneficio adicional importante: un amplio margen para el crecimiento y una drástica disminución de la dependencia operacional, lo que se traduce en ahorro de tiempo del equipo.
¿Por Qué Fargate y No Kubernetes?
Es una pregunta válida. Si bien Kubernetes es una plataforma de orquestación de contenedores extremadamente potente, también conlleva una curva de aprendizaje y una complejidad operativa significativamente mayores. Para nuestro equipo y nuestras necesidades actuales, Fargate ofrecía el equilibrio perfecto entre control, simplicidad y la capacidad de delegar la gestión de la infraestructura a AWS. Esta decisión nos permitió movernos más rápido y enfocarnos en los beneficios directos para nuestras aplicaciones y nuestra postura de seguridad.
Conclusión: Una Evolución Estratégica
La migración de nuestros clústeres ECS de EC2 a Fargate ha sido más que una simple actualización tecnológica; ha sido una evolución estratégica. Hemos logrado no solo optimizar costos y mejorar la escalabilidad, sino, fundamentalmente, fortalecer nuestra postura de seguridad al reducir la carga de gestión de infraestructura y la superficie de ataque.
Para todo aquel que lea esto y tenga alguna relación con la gestión o desarrollo en la nube, nuestra experiencia migrando a un modelo serverless como Fargate puede ilustrar una oportunidad valiosa. Esta transición permite que los equipos técnicos se enfoquen más en la innovación y la seguridad de las aplicaciones, y menos en el mantenimiento de la infraestructura subyacente.
La promesa de “no administrar servidores” es tangible y trae consigo eficiencias operativas y de seguridad que son relevantes para cualquier organización que busque optimizar sus recursos en el cloud. Para nosotros, como empresa de ciberseguridad, adoptar este paradigma es también una forma de reforzar nuestro compromiso con las mejores prácticas.
Otros artículos que pueden interesarte: