S4 — Squished S3
Gateway transparente de compresión S3 con GPU
¿Cuándo se amortiza?
Ejemplo: 10.000 $/mes en almacenamiento S3 comprimible
Con 10.000 $/mes en almacenamiento S3 comprimible, una reducción del 50–80% equivale aproximadamente a 5.000–8.000 $/mes de cargo bruto de uso evitado — antes de la tarifa de software de S4, cómputo de ejecución y diferencias de carga de trabajo.
Estime su ahorro
Introduzca su gasto o uso mensual relevante para una estimación aproximada — sin subir factura.
AMI EC2 autónoma del gateway S4 de compresión S3 transparente con códecs NVIDIA nvCOMP GPU preinstalados. Lánzala en una instancia GPU (g4dn / g5 / g6), apunta tus clientes S3 hacia ella y reduce los bytes de almacenamiento S3 un 50–80% para datos compresibles — sin cambios en la aplicación.
S4 es un gateway drop-in compatible con S3 que comprime de forma transparente cada objeto de camino a tu bucket. La AMI incluye Amazon Linux 2023, el driver NVIDIA, el runtime de contenedores y la compilación GPU de S4 (nvCOMP Bitcomp / zstd / GDeflate) preinstalados como servicio systemd — sin configurar CUDA, drivers ni nvCOMP. En una instancia GPU enruta los datos enteros y columnares (Parquet, ORC, postings, time-series) a códecs nvCOMP GPU y los datos de texto o logs a CPU zstd, por objeto. Las entradas ya comprimidas pasan sin cambios.
El problema
Tu factura de almacenamiento de S3 crece linealmente con los bytes que conservas, y la mayoría de esos bytes —logs, JSON, Parquet/ORC— son altamente compresibles. Tus aplicaciones los escriben sin comprimir porque cambiar cómo almacenan los datos no compensa el esfuerzo de ingeniería, por lo que pagas por almacenar bytes que realmente no necesitas. El resultado es una factura que aumenta cada mes por datos que podrían ser 3× más pequeños o más.
Cómo funciona
- 1
Lanzar la AMI de GPU
Lanza la AMI de S4 —Amazon Linux 2023 con el driver de NVIDIA y nvCOMP preinstalados y S4 ejecutándose como servicio de systemd— en una instancia g4dn, g5, g6 o g6e dentro de tu propia VPC.
- 2
Redirige tus clientes de S3
Cambia solo la URL del endpoint en tus clientes boto3 / aws-cli / Spark / Trino / DuckDB; la autenticación SigV4, la subida multipart y Range GET seguirán funcionando sin cambios.
- 3
Comprime de forma transparente en tránsito
En cada PUT, el dispatcher realiza un muestreo del payload y lo enruta al mejor códec —CPU zstd para texto/logs, GPU nvCOMP Bitcomp para enteros en columnas, passthrough para datos ya comprimidos— y GET devuelve los bytes originales.
Características destacadas
Compresión GPU preinstalada: driver NVIDIA + nvCOMP (Bitcomp / zstd / GDeflate) integrados en la AMI. Lánzala en g4dn / g5 / g6 y S4 usa la GPU automáticamente para datos enteros y columnares.
50–80% menos bytes de almacenamiento S3 para datos compresibles, con informes integrados de ahorro medido por bucket (s4 savings).
Cero cambios en la aplicación y sin lock-in: endpoint compatible con S3 a nivel de protocolo, y los objetos siguen siendo legibles sin el gateway mediante herramientas CLI / Python / fsspec Apache-2.0.
Qué incluye
- Una AMI de EC2 (Amazon Linux 2023) con el driver de NVIDIA y nvCOMP preinstalados y S4 ejecutándose como servicio de systemd, facturada por horas de instancia en tu factura habitual de AWS.
- Familias de instancias de GPU compatibles: g4dn, g5, g6 y g6e.
- Un endpoint compatible a nivel de protocolo con S3 —autenticación SigV4 / SigV4a, subida multipart, Range GET y SSE— utilizable como drop-in por cualquier SDK o herramienta de S3.
- Distribución de códecs por payload entre CPU zstd, GPU nvCOMP Bitcomp / zstd / GDeflate y passthrough, seleccionados automáticamente mediante muestreo de entropía y magic bytes, dejando pasar intactas las entradas ya comprimidas.
- Informes de ahorro: s4 estimate proyecta el ahorro en un bucket existente antes de realizar el despliegue, y el registro de s4 savings detalla los bytes de almacenamiento y los dólares reales ahorrados. Se incluyen métricas de Prometheus y un dashboard de Grafana.
- Herramientas de lectura sin lock-in: la CLI s4-codec con licencia Apache-2.0, el paquete Python s4-codec, el adaptador fsspec s4fs (pandas / pyarrow / DuckDB) y un decodificador WASM para navegador leen objetos directamente sin el gateway.
- Herramientas de día 2: s4 migrate comprime retroactivamente los objetos existentes y s4 recompact vuelve a comprimir los datos fríos, mientras que Range GET sigue siendo rápido gracias a un índice de frames sidecar compatible con lectores de Parquet/ORC.
Casos de uso
Equipos que ingieren grandes volúmenes de logs o JSON (logs de acceso de nginx, logs de aplicaciones) y cuya factura de S3 está dominada por texto altamente compresible.
Data lakes que almacenan Parquet/ORC y datos de enteros en columnas (postings, series temporales) y quieren reducir su huella de almacenamiento manteniendo la rapidez del análisis con Range GET.
Organizaciones con una factura mensual de S3 superior a aproximadamente $3,000, o que ya ejecutan instancias de GPU, donde el ahorro de almacenamiento cubre cómodamente el coste de computación de la GPU.
Pipelines de ETL / ML que quieren compresión sin reescribir el código de la aplicación —solo hay que redirigir el endpoint de S3.
Casos de estudio y benchmarks
Compresión de almacenamiento del frozen tier de Elasticsearch
Medido de extremo a extremo en un clúster real de Elasticsearch 9.4.2 (ES → S4 → MinIO, índice de logs de 4M de documentos). Comprimir el repositorio de snapshots del frozen tier con el valor predeterminado zstd-3 redujo el almacenamiento en un 27% (estándar) / 22% (LogsDB) —hasta un 33% con s4 recompact—, mientras que las consultas analíticas en frío del frozen tier se mantuvieron dentro de ±1 ms respecto al acceso directo y los snapshots apenas añadieron tiempo de ejecución. Combinado con LogsDB, se obtiene un repositorio 2.82× más pequeño que el estándar por defecto normal.
Leer el benchmark completoCompresión de almacenamiento de searchable-snapshot de OpenSearch
Medido de extremo a extremo en un clúster real de OpenSearch 2.19 (OpenSearch → S4 → MinIO, índice de logs de 4M de documentos). Comprimir con S4 el repositorio S3 de searchable-snapshot redujo el almacenamiento en un 28% (default) / 17% (best_compression / zstd / zstd_no_dict). Debido a que el index.codec de OpenSearch solo comprime los campos almacenados (stored fields), S4 sigue ahorrando un ~17% adicional por encima del códec zstd nativo al comprimir doc-values y postings. En esta ejecución local, la latencia de búsqueda de remote_snapshot se mantuvo dentro de ~1.5 ms respecto al acceso directo (con S4 igual o más rápido). Requiere el flag --logical-etag de S4 para repository-s3 (añadido en este trabajo).
Leer el benchmark completoCompresión de chunks de Grafana Loki
Medido de extremo a extremo en una instancia real de Grafana Loki 3.3.2 (Loki → S4 → MinIO, 4M de líneas de log). Volver a comprimir los chunks snappy de Loki con S4 zstd-3 redujo el almacenamiento del bucket en un 18.4% (zstd-9 19.3%). Siendo honestos: cambiar el propio chunk_encoding de Loki a zstd ahorra un 38% en los nuevos chunks —más que S4—, por lo que el valor de S4 se centra en el backlog de snappy inmutable (forward-only) existente y no en nuevos desarrollos (es complementario, no un reemplazo). Lecturas: un GET de chunk completo a través de S4 cuesta ~1.7 ms más (bytes idénticos; coste de descompresión, ejecución local). A diferencia de OpenSearch, --logical-etag no es obligatorio para Loki (se recomienda para obtener ETags correctos).
Leer el benchmark completoCompresión de tiered storage de Kafka
Medido de extremo a extremo en un clúster real de Apache Kafka 3.9.1 (almacenamiento por niveles KIP-405 + plugin de Aiven → S4 → MinIO, 600k registros/topic). Volver a comprimir los segmentos de log en niveles con S4 zstd-3 redujo los bytes almacenados en un 74.7% para none (sin comprimir) / 22.6% snappy / 20.6% lz4 / 0.0% zstd, según el compression.type del producer. Siendo honestos: si el producer envía zstd, reduce los segmentos en origen (43.9 MB, el mismo suelo que alcanza S4 sobre none, 42.0 MB), y S4 no añade prácticamente nada en segmentos que ya son zstd. Por tanto, el valor de S4 reside en los segmentos de none/snappy/lz4 o en casos donde no se puede cambiar el producer (es complementario, no un reemplazo). Sin penalización constante de S4 en el remote-fetch en frío (ejecución local, muestras individuales con ruido). A diferencia de OpenSearch, --logical-etag no es obligatorio para Kafka (se recomienda para obtener ETags correctos).
Leer el benchmark completoRecompactación de Parquet en frío
Medido localmente contra MinIO (un Parquet de logs de estilo ECS de 2,000,000 de filas, 13 columnas). Un nuevo subcomando s4 parquet-recompact vuelve a codificar en zstd los column chunks de Parquet fríos de data lake y vuelve a escribir un Parquet NATIVO —pyarrow / Spark / Trino / DuckDB lo leen directamente, sin S4 en la ruta de lectura—. Respecto a snappy (el valor predeterminado de data lake), redujo el almacenamiento en un 36.6%, respecto a datos sin comprimir un 51.7%, gzip un 3.8%, y ya comprimidos con zstd un 0.0% (omitido). Cada salida es idéntica valor por valor (pyarrow table.equals). Siendo honestos: configurar el códec del escritor en zstd alcanza el mismo suelo en origen (79.4 MB), por lo que el valor de S4 está en el backlog existente de snappy/none/gzip para el cual nadie vuelve a ejecutar una tarea de escritura (es complementario, no un reemplazo). Cada objeto se somete a una verificación de valor por grupo de filas (con memoria acotada) antes de la sobreescritura in situ, y los objetos no verificables nunca se sobreescriben.
Leer el benchmark completoPreguntas frecuentes
Si dejo de ejecutar S4, ¿puedo seguir leyendo mis datos?
Sí. Los objetos comprimidos y sus sidecars S4IX se mantienen nativos en S3 y se pueden listar y descargar con aws-cli o boto3 estándar. Para recuperar el payload original, puedes usar la CLI s4-codec con licencia Apache-2.0, el paquete Python s4-codec, el adaptador fsspec s4fs (pandas / pyarrow / DuckDB) o el decodificador de navegador WASM; todos ellos de código abierto, decodificación pura y sin necesidad de un entorno de ejecución de gateway.
¿Tengo que cambiar mis aplicaciones?
No. S4 utiliza el protocolo de red de S3 —misma autenticación SigV4, mismo multipart, mismo Range GET, mismas llamadas de SDK—. Solo tienes que cambiar la URL del endpoint a la que apunta tu cliente de boto3 / aws-cli / Spark / Trino / DuckDB; nada más cambia.
¿Qué parte de mi factura se reduce realmente?
Solo bytes de almacenamiento. S4 reduce los bytes almacenados en S3 en un 50–80% para datos comprimibles — por ejemplo, 1 TiB de logs de nginx se comprime a unos 6.6 GiB. El coste de las solicitudes (PUT/GET), el egress y el cómputo de GPU no cambian. Debido al coste de la instancia GPU, S4 suele ser rentable a partir de una factura mensual de S3 de unos $1,000 (menos en instancias spot o si ya ejecuta GPU).
¿Qué instancias GPU admite la AMI?
La AMI de EC2 (Amazon Linux 2023, driver de NVIDIA + nvCOMP preinstalados) se ejecuta en instancias g4dn, g5, g6 y g6e, facturada por hora de instancia en su factura habitual de AWS. No hay clave de licencia — la medición se gestiona a través de AWS Marketplace.
¿Dónde se ejecuta S4 y quién puede ver mis datos?
Inicia la AMI en su propia cuenta de AWS y VPC, y esta se comunica con su propio bucket de S3 — ningún dato sale de su cuenta y no hay servicios de terceros en la ruta. Admite TLS y cifrado del lado del servidor (SSE).
Por qué es más barato
Supone 100 TB almacenados en S3 Standard (us-east-1), con datos que se comprimen ~3× (Parquet/ORC, JSON, etc.).
- Almacenamiento S3 (100 TB)
- $2,300 / mes
- Total mensual
- $2,300 / mes
- Almacenamiento S3 (34 TB comprimidos)
- $800 / mes
- Instancia S4 (g4dn.xlarge + tarifa de software)
- $385 / mes
- Total mensual
- $1,185 / mes
Dimensionar la instancia S4 según la carga de escritura
| Carga de escritura | Instancia recomendada | Coste de la instancia S4 | Total con 100 TB almacenados |
|---|---|---|---|
| ~1 TB / día | g4dn.xlarge | $385 / mes | $1,185 / mes (−49 %) |
| ~10 TB / día | g6.xlarge | $590 / mes | $1,390 / mes (−40 %) |
| Alta concurrencia / 100 TB / día | g6.4xlarge | $965 / mes | $1,765 / mes (−23 %) |
Ejemplo ilustrativo. El almacenamiento se calcula con la tarifa publicada de S3 Standard (us-east-1) (0,023 $/GB-mes) y los precios bajo demanda de EC2 para g4dn / g6. La tarifa de software de S4 se factura por hora a través de AWS Marketplace, aparte del coste de EC2 (un Savings Plan de 1 año suele reducir la parte de EC2 un 30–40 %). El ahorro real depende de la compresibilidad de tus datos (Parquet, JSON ~3–5×; logs de texto ~4–10×) y de los patrones de lectura/escritura.
Modelo de precios
Tarifa de software por hora + la GPU EC2 que elijas (g4dn / g5 / g6). Medición por tipo de instancia, opción anual disponible, sin claves de licencia.
Otros productos S4
S4 Logs
Archiva CloudWatch Logs en S3 con zstd
S4 Metrics
Gobierna la cardinalidad de métricas de CloudWatch
S4 NAT
NAT optimizado en costes para Amazon VPC