Costos CloudWatch Logs en ECS: cómo no pagar USD 400/mes

Si tu factura de AWS trepó a USD 400 este mes y CloudWatch aparece como el culpable, no estás solo. ECS, por defecto, te arma una trampa silenciosa: grupos de log sin fecha de vencimiento, level INFO en todos los contenedores y tres cargos distintos que se acumulan sin pedir permiso. La buena noticia es que con cuatro pasos concretos podés bajar ese costo entre un 60 y un 80% sin perder visibilidad real sobre tus servicios.

El driver awslogs en ECS es el mecanismo que manda cada stdout de tus contenedores directo a CloudWatch Logs. El problema central es que Amazon no configura retención automática cuando creás el servicio: el grupo de log nace con la política Never Expire, y todo lo que tus aplicaciones imprimen —incluidos health checks, stack traces y mensajes de debug— se almacena para siempre. Pagás tres veces por el mismo dato: ingestión (USD 0,50 por GB), almacenamiento (USD 0,03 por GB/mes) y consultas con Insights (USD 0,005 por GB escaneado). Sin un límite, los costos crecen cada mes que pasa, y el comportamiento predeterminado de ECS no te avisa.

¿Por qué los costos de CloudWatch Logs en ECS se disparan sin configuración?

Porque el driver awslogs —que ECS activa automáticamente si no especificás otro— captura la salida estándar de todos los contenedores y la manda a CloudWatch. En ese momento se crea un grupo de log que solo sirve para acumular datos. Sin política de retención, cada línea que tu aplicación escupe se queda ahí para siempre. El resultado es una boleta con tres líneas de cobro sobre los mismos datos:

• Ingestión: USD 0,50 por GB que entra. Si producís 3 GB por día, son USD 45 al mes (y eso que acá redondeamos para abajo; el ejemplo real de 15 servicios da más).
• Almacenamiento: USD 0,03 por GB por mes. Pero ojo, este número crece todos los meses porque los gigas viejos no se borran.
• Consultas con Insights: USD 0,005 por cada GB que escaneás cuando tirás una query de debug. Cinco consultas diarias sobre logs acumulados pueden sumar USD 36 al mes sin que te des cuenta.

El combo es letal: pagás lo que enviás, pagás lo que guardás y pagás lo que leés. Y ECS no pone ningún tope en ninguna de las tres puntas. ¿Alguien te avisó cuando creaste el cluster? No, porque no es un bug, es el default. Cubrimos ese tema en detalle en riesgos de seguridad en CI/CD.

¿Cuánto cuesta realmente tener logs sin retención en ECS?

Agarrá una flota típica de 15 servicios, cada uno corriendo con nivel INFO, y supongamos que generan 3 GB de logs por día entre todos (un número bastante común si tenés microservicios charlatanes). A junio de 2026, los números son estos:

Concepto	Costo mensual estimado	¿Crece cada mes?
Ingestión (3 GB/día × 30 días × USD 0,50/GB)	USD 45	Sí, si aumentan los GB
Almacenamiento (90 GB acumulados el primer mes × USD 0,03/GB)	USD 54 (primer mes)	Sí, los GB viejos se suman
Insights (5 consultas/día)	USD 36	Sí, si acumulás más logs

En el artículo original de dspv en dev.to, el autor reportó una factura real de USD 400 para un escenario similar, porque el almacenamiento iba creciendo mes a mes sin techo y las consultas de Insights pegaban sobre un volumen cada vez mayor. Si mantienes la política Never Expire, el costo de almacenamiento se multiplica con el tiempo. Y ni hablemos de lo que pasa si algún servicio se pone a loguear stack traces en cada request.

Primer paso: configurar la retención de logs en cada grupo (90% del impacto)

Este paso solo te puede ahorrar hasta el 80% del costo de almacenamiento. La idea es simple: poné retention_in_days = 30 en todos los grupos de log que ECS creó sin preguntar. AWS no ofrece un botón mágico para setearlo en masa desde la consola, pero tenés dos caminos:

• Con AWS CLI, grupo por grupo: primero listás los grupos sin retención con aws logs describe-log-groups --query 'logGroups[?!not_null(retentionInDays)]' y después aplicás aws logs put-retention-policy --log-group-name X --retention-in-days 30 en cada uno. Funciona, pero si tenés 50 grupos es un embole.
• Con la skill file de Claude Code: el autor publicó un agente en fortem.dev que escanea todos los grupos de tu cuenta, identifica los que sangran guita y aplica la retención solo con tu confirmación. Corre en local contra tu cuenta AWS; los datos nunca salen de tu máquina.

Si usás Terraform o CDK, también podés definir retention_in_days desde el día cero. Pero para lo que ya está corriendo en producción, la CLI o el agente son la salida rápida.

Segundo paso: filtrar logs por nivel y contenido (impacto adicional del 5%, pero fácil de implementar)

Una vez que la retención corta el crecimiento indefinido, el enemigo es el volumen ingerido. Acá la pregunta es: ¿de verdad necesitás INFO en producción todo el tiempo? La mayoría de las apps largan líneas de relleno, health checks de los balanceadores que golpean cada 5 segundos, y stack traces enteros cuando algo falla (que ya deberían estar en un sistema de tracing, no en stdout). Ya lo cubrimos antes en comparativa de pipelines CI/CD.

Configurar la app para que solo emita WARN y ERROR en producción, y mover los health checks a un endpoint separado que no genere logs, te baja el volumen ingerido sin tocar CloudWatch. Es un ajuste chico, pero si sumás 15 servicios, el ahorro en ingestión se nota.

Tercer paso: usar CloudWatch Logs Insights en lugar de streaming continuo

Mucha gente deja dashboards corriendo con streaming en vivo sobre grupos de log enormes. Eso dispara consultas que escanean todo el volumen almacenado, y a USD 0,005 por GB, duele. Insights cobra solo por lo que escanea cada consulta puntual, no por tener los logs ahí.

La clave está en acotar las queries con filter @timestamp >= now - 1h y apuntar solo al grupo de log específico que te interesa debuggear. Si necesitás monitoreo en tiempo real, usá métricas de CloudWatch (que son gratis en cierto tier) y dejá Insights solo para cuando algo explota. Esa diferencia de mentalidad —“busco cuando necesito” en vez de “miremos todo todo el tiempo”— baja el costo de consultas en escenarios similares al que vimos arriba.

Cuarto paso: identificar el servicio que más cuesta y ajustarlo

Con esta query de Insights podés encontrar al hablador de la familia:

stats sum(bytes) as totalBytes by @logStream | sort totalBytes desc | limit 5 Para más detalles técnicos, mirá diferencias entre Jenkins y GitHub Actions.

El resultado te muestra los streams que más volumen generan en los últimos días. Casi siempre encontrás uno de estos tres escenarios:

• Un servicio que imprime cada request completo con payload y headers: una animalada de bytes que no aporta nada en producción.
• Stack traces repetidos que nadie arregló: si cada error tira 200 líneas y el error ocurre 1000 veces por hora, estás regalando guita.
• Health checks no silenciados: el típico GET /health que aparece cada 5 segundos en los logs. Silenciarlo desde la app o configurar el load balancer para que no genere esos registros resuelve el 90% de los casos de alto volumen.

Atacar al servicio que más gasta te da un retorno inmediato y te obliga a revisar qué estás logueando realmente. (Spoiler: probablemente demasiado.)

¿Conviene exportar logs a S3 para archivo a largo plazo?

Si por compliance necesitás guardar logs por años, CloudWatch no es el lugar más barato. Exportar los grupos a S3 con aws logs create-export-task y después aplicar una política de ciclo de vida que mande todo a Glacier después de 90 días te baja el costo de almacenamiento a centavos por GB.

El procedimiento es:

• Creás un bucket S3 con versionado si querés.
• Lanzás la tarea de exportación desde CloudWatch a ese bucket (podés programar un Lambda para que dispare exportaciones cada 30 días).
• Configurás una regla de ciclo de vida en S3 que mueva los objetos a Glacier o Glacier Deep Archive tras N días.

Comparado con USD 0,03 por GB/mes en CloudWatch, el almacenamiento en Glacier es significativamente más barato. No es para todos los casos —si necesitás consultar logs viejos seguido, Glacier no es práctico—, pero para auditoría cada muerte de obispo, rinde. Esto se conecta con lo que analizamos en análisis de GPT-5 y Claude Code.

Errores comunes al gestionar costos CloudWatch en ECS

• Asumir que el default de ECS es suficiente: el Never Expire se aplica sin avisar y la factura llega sola. Siempre revisá los grupos de log apenas creás un servicio nuevo. Si automatizaste con Terraform, incluí retention_in_days en el módulo.
• Poner retención demasiado corta para todo: si seteás 7 días en servicios donde necesitás debuggear incidentes de la semana pasada, te quedás sin data cuando más la precisás. Separar grupos por criticidad (30 días para prod, 7 para staging) es más inteligente.
• No filtrar en la app porque “total después vemos”: la ingestión se paga aunque después borres los logs. Cuanto más callado esté tu código, más barato sale todo. Revisá qué niveles de log usás en cada entorno y silenciá los health checks de una vez.
• Usar Insights como si fuera un dashboard en vivo: si tirás consultas cada 5 minutos sobre el último mes de datos, el costo de escaneo se multiplica. Insights es para investigar, no para monitorear.

Preguntas Frecuentes

¿Cómo configurar la retención de logs en CloudWatch para ECS?

Desde la CLI, ejecutá aws logs put-retention-policy --log-group-name NOMBRE --retention-in-days 30 para cada grupo de log. También podés usar la skill file de Claude Code que escanea automáticamente los grupos sin retención y aplica el cambio con tu aprobación, sin mover datos fuera de tu cuenta AWS.

¿Cuánto cuesta almacenar logs sin retención en CloudWatch?

Amazon cobra USD 0,03 por GB por mes de almacenamiento. En un escenario de 15 servicios generando 3 GB diarios, pagás USD 54 mensuales de storage, y como los logs nunca expiran, ese costo crece cada mes, más ingestión y consultas.

¿Cómo reducir los costos de CloudWatch Logs en ECS?

Con cuatro acciones: 1) configurá retención de 30 días en todos los grupos (baja 60-80% el storage), 2) filtrá logs para emitir solo WARN/ERROR en producción, 3) usá CloudWatch Logs Insights con consultas acotadas en lugar de streaming continuo, y 4) identificá el servicio que más emite y silenciá health checks, stack traces o payloads innecesarios.

¿Qué es el driver awslogs en ECS y por qué encarece?

Es el driver de logs por defecto en ECS. Captura stdout de los contenedores y lo envía a CloudWatch Logs sin configurar un límite de retención. El resultado es que pagás ingestión, almacenamiento y consultas sobre datos que nunca expiran, acumulando costos todos los meses.

¿Cómo usar CloudWatch Logs Insights para ahorrar en costos?

Insights cobra solo por los GB escaneados en cada consulta (USD 0,005/GB), no por el almacenamiento. Para ahorrar, lanzá queries puntuales limitadas por tiempo (filter @timestamp >= now - 1h) y apuntá solo al grupo de log del servicio que querés inspeccionar, en vez de escanear todo el volumen almacenado cada cinco minutos.

Conclusión

El default de ECS con CloudWatch Logs es básicamente una suscripción sin tope a tres cargos distintos que crecen solos. La buena noticia es que con poner retención de 30 días ya recuperás el control, y si además afinás lo que tu aplicación emite y cómo consultás los logs, la factura vuelve a terreno razonable. Si estás en Argentina y tu infraestructura cloud va más allá de AWS, también vale la pena revisar proveedores locales como donweb.com para workloads que no necesariamente tienen que vivir en la nube pública y donde el costo en dólares pega fuerte. En cualquier caso, en 2026 no hay excusa para que un error de configuración te cueste cientos de dólares al mes.

Fuentes

• How to Control CloudWatch Logs Costs on ECS – dev.to: artículo original con el análisis de costos detallado y la skill file para Claude Code, publicado el 12 de junio de 2026.
• Knowledge Center de AWS: monitorización de logs ECS con CloudWatch: documentación oficial de AWS sobre configuración y monitoreo de logs en ECS.
• Claude Code Lab: uso de Claude Code con AWS CloudWatch: guía complementaria sobre cómo Claude Code puede automatizar tareas de CloudWatch en entornos AWS.