Desglose de la estructura de costos de ECS on Fargate - Combinación práctica de Spot, ARM y escalado
Desglosamos la estructura de precios de ECS on Fargate en 3 ejes: CPU, memoria y almacenamiento, y explicamos técnicas prácticas de optimización de costos combinando Fargate Spot, Graviton (ARM) y Service Auto Scaling.
Comprender con precisión la estructura de precios de Fargate
La optimización de costos de Fargate comienza con la comprensión precisa de la estructura de precios. La facturación de Fargate se calcula en 2 ejes: segundos de vCPU y segundos de GB de memoria. Los precios unitarios varían según la región y están sujetos a revisiones, por lo que conviene consultar el precio por vCPU y por memoria de la región objetivo en la página oficial de precios de Fargate de AWS. Lo que se suele pasar por alto es que las combinaciones de CPU y memoria especificadas en la definición de tarea tienen restricciones. Por ejemplo, si se selecciona 0.25 vCPU, la memoria solo puede ser 0.5GB, 1GB o 2GB. Para 1 vCPU, el rango es de 2GB a 8GB (la tabla de combinaciones está en la documentación oficial de AWS, a septiembre de 2026). Si la carga de trabajo real necesita 0.3 vCPU y 1.5GB de memoria, se debe elegir la combinación 0.5 vCPU + 2GB, desperdiciando aproximadamente 40% de los recursos. Si no se es consciente de este costo de redondeo al diseñar definiciones de tareas, se generan cargos superiores a los esperados. El almacenamiento efímero incluye 20GB por tarea sin cargo adicional (página oficial de precios de Fargate de AWS, a septiembre de 2026), y solo se cobra la parte configurada por encima de 20GB, hasta un máximo de 200GiB (AWS anunció el soporte de hasta 200GiB en abril de 2021 y la documentación oficial mantiene el mismo límite a septiembre de 2026). Para cargas de trabajo que manejan grandes cantidades de archivos temporales, es necesario comparar con el montaje de EFS.
Lograr hasta 70% de reducción de costos con Fargate Spot
Fargate Spot es un mecanismo que ejecuta tareas Fargate con hasta 70% de descuento (cifra indicada en la página oficial de precios de Fargate de AWS, a septiembre de 2026) utilizando la capacidad excedente de AWS. Similar a las instancias EC2 Spot, cuando la capacidad es insuficiente, las tareas se interrumpen con 2 minutos de aviso. Para utilizar Fargate Spot efectivamente, es necesario evaluar correctamente la tolerancia a interrupciones de la carga de trabajo. Los candidatos óptimos son cargas de trabajo que pueden re-ejecutarse si se interrumpen, como procesamiento por lotes, pipelines de transformación de datos, trabajos de build CI/CD y entornos de desarrollo/pruebas. En servicios ECS, se puede controlar la proporción entre Fargate y Fargate Spot con la estrategia de proveedor de capacidad. Por ejemplo, configurando base en 2 (mínimo 2 tareas aseguradas con Fargate normal), weight de Fargate Spot en 3 y weight de Fargate normal en 1, se garantiza la operación estable de las 2 tareas base mientras el 75% del escalado se cubre con Spot. Incluso en servicios web de producción, con esta estrategia de Fargate normal para la línea base y Spot para tareas adicionales en picos, se contienen los costos de los picos manteniendo la disponibilidad. En el ejemplo anterior, el 75% del escalado se ejecuta en Spot, por lo que si se aplica el descuento máximo del 70%, el costo de las tareas adicionales baja a menos de la mitad.
Ejecutar la misma configuración un 20% más barato con Graviton (ARM)
Fargate soporta la arquitectura Graviton (ARM64) desde 2021 (el soporte de Graviton2 para ECS on Fargate se anunció en el blog oficial de AWS en noviembre de 2021). Las tareas Fargate basadas en Graviton son aproximadamente 20% más baratas comparadas con x86, según la cifra de 20% menos de costo que AWS indicó en ese anuncio de noviembre de 2021; la diferencia de precio unitario actual se consulta en la página oficial de precios. El rendimiento real varía según las características de la carga de trabajo, por lo que conviene medir y comparar en el propio entorno antes de migrar. La barrera de migración es la necesidad de construir imágenes de contenedor para ARM64. Lenguajes como Go, Node.js, Python y Java facilitan la compilación cruzada y builds multi-arquitectura, y con docker buildx se pueden generar imágenes tanto AMD64 como ARM64 desde un solo Dockerfile. Si hay bibliotecas que dependen de extensiones nativas C/C++, se necesita build y pruebas en entorno ARM64. Solo especificando cpuArchitecture como ARM64 en runtimePlatform de la definición de tarea, se ejecuta sobre Graviton. Fargate Spot y Graviton se pueden usar juntos (la página oficial de precios de Fargate de AWS publica tarifas de Fargate Spot para Linux/ARM a septiembre de 2026; las combinaciones disponibles se consultan en la documentación oficial de AWS). Aplicando ambos se superponen el descuento de aproximadamente 20% de Graviton y el descuento de hasta 70% de Spot, aunque la tasa de descuento de Spot varía según la situación de la capacidad.
Patrones de diseño de Service Auto Scaling
Lo más pasado por alto en la optimización de costos de Fargate es la configuración apropiada de Service Auto Scaling. Si el escalado es demasiado lento, el rendimiento se degrada en picos; si es demasiado rápido, se inician tareas innecesarias aumentando costos. ECS Service Auto Scaling soporta escalado de seguimiento de objetivo, escalado por pasos y escalado basado en programación, además del escalado predictivo basado en patrones históricos (documentación oficial de AWS, a septiembre de 2026). El primero que conviene considerar es el escalado de seguimiento de objetivo. Configurando 70% de utilización de CPU como objetivo, ECS ajusta automáticamente el número de tareas para mantener el valor objetivo. Sin embargo, el período de enfriamiento de scale-in del escalado de seguimiento de objetivo en servicios ECS es por defecto 300 segundos (5 minutos, según la documentación oficial de Application Auto Scaling a septiembre de 2026), manteniendo las tareas durante 5 minutos después de que el tráfico disminuya abruptamente. Para priorizar costos se puede acortar el período de enfriamiento a 120 segundos, pero hay riesgo de flapping (repetición frecuente de scale-in/out) en cargas de trabajo con tráfico muy variable. Para patrones de tráfico predecibles, es efectivo combinar con escalado basado en programación, elevando el número mínimo de tareas durante horario laboral y reduciéndolo por la noche.
Prioridad de optimización de costos y pasos prácticos
La optimización de costos de Fargate es racional aplicando las medidas de mayor efecto primero. El primer paso es revisar la configuración de CPU y memoria de la definición de tarea. Se verifica la utilización real de recursos con CloudWatch Container Insights y se cambian las tareas sobreaprovisionadas al tamaño apropiado. La magnitud de la reducción depende de cuánto se esté redondeando hacia arriba actualmente (en este artículo se toma un 20-40% como referencia, que no es una cifra publicada por AWS). El segundo paso es la migración a Graviton. Agregando el build ARM64 de la imagen de contenedor y cambiando cpuArchitecture en la definición de tarea, la diferencia de precio unitario de Graviton se aplica directamente. El tercer paso es introducir Service Auto Scaling. Si se opera con número fijo de tareas, se generan costos innecesarios durante los valles de tráfico. Configurando el escalado de seguimiento de objetivo, el número de tareas se ajusta automáticamente según la demanda y se elimina el desperdicio de los valles (en este artículo la referencia es 20-30%; el efecto real es proporcional a la amplitud de variación del tráfico). Como cuarto paso, se aplica Fargate Spot a cargas de trabajo tolerantes a interrupciones. Las tasas de descuento que AWS publica oficialmente son hasta 70% para Fargate Spot (página de precios, a septiembre de 2026) y aproximadamente 20% para Graviton (cifra del anuncio de noviembre de 2021); las otras dos medidas dependen de cuánto exceso actual se pueda recortar. Como la reducción total varía mucho según la configuración, lo seguro es comparar el antes y el después en Cost Explorer cada vez que se aplica una medida, confirmando su efecto antes de continuar.
Referencias (recursos oficiales de AWS)
Las fuentes primarias de esta página son el sitio web y la documentación oficiales de AWS. Consulta las páginas oficiales siguientes para conocer las especificaciones y los precios más recientes.
Si esta página y la documentación oficial difieren, prevalece la documentación oficial.