Reducir costos CloudWatch Logs con S4, gateway open source
Si administrás cargas en AWS que vomitan logs a lo loco y después nadie consulta, seguro notaste que la ingestión de CloudWatch te come el presupuesto. El proyecto S4, un gateway open source escrito en Rust con licencia Apache 2.0, ataca justo ese problema: permite drenar grupos de logs existentes a S3 con compresión zstd (Modo A) o evitar la ingestión costosa mediante un gateway que implementa la API de CloudWatch Logs y envía los logs directamente a S3 (Modo B).
S4 es un gateway de CloudWatch Logs que permite extraer eventos históricos y archivarlos comprimidos en S3, o interceptar la ingestión de logs para escribir directamente en S3. Lo armó Abyo Software pensando en cargas donde se escribe muchísimo y se lee casi nada, justo el patrón que hace que CloudWatch sea un agujero financiero.
En 30 segundos
- El problema de raíz: CloudWatch Logs cobra USD 0.50 por GB ingerido más 26 B de overhead por evento (precios us-east-1 a junio de 2026). Si escribís mucho y consultás poco, la ingestión se lleva la mayor tajada.
- S4 en dos modos: Modo A drena logs existentes de CloudWatch a S3 con compresión zstd RFC 8878, idempotente por ventanas horarias. Modo B es un gateway que implementa un subconjunto de la API de CloudWatch Logs, permitiendo bypassear la ingestión y almacenar los logs directamente en S3.
- Ahorro principal: se elimina el costo de ingestión de CloudWatch Logs (USD 0.50/GB) y se paga solo el almacenamiento en S3, que es mucho más económico.
- Integración simple: solo hay que cambiar el endpoint en Fluent Bit, CloudWatch Agent o cualquier SDK que hable el subconjunto de la API de CloudWatch Logs, sin modificar la aplicación.
¿Por qué CloudWatch Logs es tan caro para cargas de escritura intensiva?
Ponele que tenés una app que genera 200 GB de logs por mes con millones de eventos chiquitos. CloudWatch te cobra USD 0.50 por GB de ingestión más un fijo de 26 bytes por evento como overhead medido, según la lista de precios vigente en us-east-1 a junio de 2026. Ese overhead por evento es traicionero: si tus líneas de log pesan 100 B, los 26 B extra representan un 26% de sobrecosto invisible. Y si encima casi nunca consultás esos logs, estás pagando carísimo por escribir bytes que se van acumulando sin que nadie los mire.
La estructura de costos de CloudWatch castiga la escritura, no la lectura. El almacenamiento base cuesta centavos, pero la ingestión domina la factura en workloads write‑heavy. Ahí es donde S4 mete la tijera: en el Modo A drena los grupos existentes a S3, y en el Modo B evita la ingestión desde el principio.
¿Qué es S4 y cómo ayuda a reducir la factura?
S4 es un gateway open source escrito en Rust, con licencia Apache 2.0, que reduce los costos de CloudWatch Logs permitiendo drenar logs existentes a S3 con compresión zstd (RFC 8878) o evitar la ingestión mediante un gateway que implementa la API de CloudWatch Logs. Tiene dos modos de operación independientes: drenaje histórico (Modo A) y bypass de ingestión (Modo B). Ya lo cubrimos antes, como mencionamos en la comparativa de pipelines CI/CD.
Lo interesante es que no tenés que tocar ni una línea de tu código de aplicación. El Modo B funciona cambiando el endpoint del cliente de CloudWatch Logs (por ejemplo, en Fluent Bit o CloudWatch Agent) para que apunte al gateway S4, y listo — el resto es transparente.
Modo A: drenar CloudWatch Logs a S3 de forma idempotente
El Modo A resuelve el problema de “ya tengo un montón de logs en CloudWatch y quiero sacarlos de ahí sin perderlos”. S4 usa la API FilterLogEvents de CloudWatch para extraer los eventos y los escribe en S3 como frames zstd estándar (RFC 8878), con una línea JSON por evento. Todo el trabajo se organiza en ventanas alineadas a UTC — una hora por defecto, configurable con --window‑minutes — y cada ventana genera un manifiesto. Si re‑ejecutás el drenaje, las ventanas que ya tienen manifiesto se saltean: la operación es idempotente.
Con una línea podés probar en seco para ver cuánto vas a mover:
s4 drain --dry-run --log-group-prefix /aws/ --destination-bucket mi-bucket
Ojo con una cosa: hasta que no acortes la retención de CloudWatch, el Modo A te genera una copia archivada en S3 además del storage original. El ahorro neto en almacenamiento aparece recién cuando bajás la retención de CloudWatch (esa es la parte que duele si te olvidás). Pero incluso antes de eso ya estás blindado: los logs quedan en S3 comprimidos y podés borrar la data vieja de CloudWatch sin miedo. Cubrimos ese tema en detalle, como detallamos al comparar Jenkins y GitHub Actions.
Modo B: gateway de API de CloudWatch Logs que evita la ingestión
Acá es donde S4 brilla más. Desplegás un gateway que habla un subconjunto de la API de CloudWatch Logs (PutLogEvents, etc.) y actúa como endpoint para tus agentes de logs. Los eventos se escriben directamente en S3, eliminando por completo el costo de ingestión de CloudWatch. Podés configurar rutas para que algunos logs sigan yendo a CloudWatch y otros a S3, o ambos.
El setup es tan simple como cambiar el endpoint en tu configuración de Fluent Bit o CloudWatch Agent. Por ejemplo:
[OUTPUT]
Name cloudwatch_logs
Match *
Region us-east-1
Endpoint https://s4logs-gateway.internalCompatible con cualquier cliente que soporte el subconjunto de la API de CloudWatch Logs, lo que facilita la integración sin modificar la aplicación.
¿Cuánto se puede ahorrar realmente? Ejemplos medidos
Los números que publicó el equipo de Abyo Software en su artículo del 28 de junio de 2026 muestran que al evitar la ingestión, el costo se reduce al almacenamiento en S3, que es significativamente menor. En cargas con mucho volumen de escritura y poca lectura, la reducción en la factura puede ser drástica.
- Eliminación del costo de ingestión: pasás de pagar USD 0.50/GB de ingestión a solo el costo de S3 PUT y almacenamiento.
- Almacenamiento comprimido con zstd: los logs se guardan en S3 en formato comprimido, reduciendo aún más el tamaño ocupado.
¿Cuándo NO conviene usar S4?
No todo es color de rosa. Hay situaciones donde S4 no te va a servir, o directamente te va a hacer perder plata. Las enumero rápido: Lo explicamos a fondo en la guía de hreflang para SEO.
- Objetos chiquitos, menores a 16 KiB. El overhead del frame zstd más el sidecar de metadatos te come la ganancia. Si tu carga son puros objetos de 2 KiB, la “compresión” te los agranda.
- Latencia ultra baja. El proxy agrega una capa más en el camino de los datos. Si tu app necesita respuestas en menos de 5 ms, S4 probablemente no sea tu amigo.
- Volumen de logs muy bajo. Si tu factura de CloudWatch ya es chica, el ahorro puede no justificar el despliegue de un gateway adicional.
- Datos que van directo a Glacier o almacenamiento en frío. Ahí el costo de cómputo no se justifica; es mejor mandar los datos sin comprimir y que Glacier los archive como están.
Requisitos técnicos y despliegue básico
Para correr S4 necesitás tener Rust instalado. La instalación se realiza desde el repositorio oficial compilando con cargo build. El binario s4logs-gateway levanta un servidor HTTP que implementa el subconjunto de la API de CloudWatch Logs; lo configurás con el endpoint, la región y las credenciales de AWS.
Un ejemplo mínimo para Modo B:
s4logs-gateway --listen 0.0.0.0:9090 --region us-east-1
Después tu agente de logs apunta a http://localhost:9090 en vez del endpoint estándar de CloudWatch Logs y listo: cada lote de eventos se escribe directo en S3, sin pasar por la ingestión de CloudWatch.
| Característica | Modo A (Drenaje) | Modo B (Bypass ingest) |
|---|---|---|
| Función principal | Extraer logs de CloudWatch a S3 | Bypassear ingest de CloudWatch y escribir logs en S3 |
| Compresión | zstd RFC 8878 (CPU) | zstd (CPU) |
| Idempotencia | Sí, por ventanas horarias y manifiestos | No aplica (cada lote es único) |
| Cambio en app | Ninguno, opera offline | Solo cambiar endpoint de CloudWatch Logs |
| Ideal para | Limpiar acumulado histórico y reducir retención | Evitar ingestión en cargas nuevas |
| Ahorro típico | 80% una vez reducida la retención de CloudWatch | Elimina costo de ingestión; paga solo S3 |
Qué significa para empresas y equipos en Latinoamérica
En la región, donde los costos en USD duelen el doble y los equipos de infraestructura suelen ser chicos, S4 pega fuerte. No requiere reescribir aplicaciones, se despliega con un solo binario y el código es abierto — justo lo que necesitás cuando no tenés margen para licencias ni para rediseñar pipelines. Si tu empresa ya corre workloads en AWS y tiene logs a rolete, implementar el Modo B te puede bajar la factura en semanas. Y si estás migrando o complementando infraestructura local, donweb.com ofrece cloud hosting con datacenter en Buenos Aires que puede convivir con este tipo de soluciones híbridas sin fricción.
Errores comunes al usar S4
He visto varios tropezones predecibles cuando alguien prueba una herramienta así. Te dejo tres que aparecen en la práctica:
Creer que el Modo A baja la factura mágicamente sin tocar la retención de CloudWatch. Drenás los logs a S3 y pensás que ya está. Pero CloudWatch te sigue cobrando el almacenamiento de los logs viejos hasta que acortás el período de retención. Si no hacés ese segundo paso, tenés duplicado el storage y pagás dos veces. Te puede servir nuestra cobertura similar a la guía de agentes sin API.
Poner el proxy y no excluir los objetos ya comprimidos. S4 detecta formatos comprimidos y los pasa sin tocar, pero si por algún motivo tu pipeline les cambia la metadata o el content‑type, podés terminar comprimiendo dos veces algo que ya era chico. Resultado: más CPU y el mismo tamaño (o peor). Revisá el Content-Encoding de tus objetos.
No ajustar las reglas de ruteo en el Modo B. Si no configurás correctamente qué logs van a S3 y cuáles a CloudWatch, podés terminar duplicando el tráfico o perdiendo logs críticos. Revisá las reglas TOML antes de ponerlo en producción.
Preguntas Frecuentes
¿Qué es S4 exactamente?
S4 es un gateway open source en Rust que permite drenar logs históricos de CloudWatch a S3 con compresión zstd, o evitar la ingestión mediante un gateway que implementa la API de CloudWatch Logs. Funciona como un reemplazo transparente del endpoint de CloudWatch Logs.
¿Cómo funciona el Modo A de S4?
El Modo A usa la API FilterLogEvents de CloudWatch para extraer eventos, los escribe en S3 como frames zstd RFC 8878 con una línea JSON por evento y organiza el trabajo en ventanas horarias UTC con manifiestos. Si re-ejecutás el comando, las ventanas completadas se saltean automáticamente.
Si necesitás centralizar tus logs en Kubernetes, tenemos un artículo completo sobre Open-source log gateways.
¿Cómo funciona el Modo B de S4?
El Modo B levanta un gateway que implementa un subconjunto de la API de CloudWatch Logs. Los agentes envían los logs a este gateway, que los escribe directamente en S3, eliminando el costo de ingestión. Solo tenés que cambiar el endpoint en la configuración del agente.
¿Cuánto se ahorra realmente con S4?
El ahorro principal viene de eliminar el costo de ingestión de CloudWatch Logs (USD 0.50/GB). Adicionalmente, los logs se almacenan comprimidos en S3. El ahorro exacto depende del volumen de logs y la retención.
¿Necesito una GPU para usar S4?
No. S4 funciona completamente en CPU y no requiere GPU.
Conclusión
S4 no es un invento revolucionario — es más bien una idea sensata implementada con criterio y código abierto. Ataca un problema concreto (la ingestión de CloudWatch que se lleva presupuesto en cargas write‑heavy) con una solución pragmática, sin pedirte que cambies de proveedor ni que reescribas la app. Lo probás en seco, medís el ahorro y después decidís. Si tu factura de AWS te hace ruido y tenés logs que nunca mirás, vale la pena una tarde de prueba. Y si andás en Argentina con infraestructura mixta entre cloud y on‑premise, S4 encaja bárbaro porque no casa con ningún vendor: evita la ingestión costosa y comprime en S3.
