S4 — Squished S3
Gateway transparent de compression S3 par GPU
Quand est-ce amorti ?
Exemple : 10 000 $/mois de stockage S3 compressible
Avec 10 000 $/mois de stockage S3 compressible, une réduction de 50–80% représente environ 5 000–8 000 $/mois de frais d’usage bruts évités — avant frais logiciels S4, compute d’exécution et différences de charge de travail.
Estimez vos économies
Saisissez vos dépenses ou votre usage mensuel pertinent — aucun transfert de facture requis.
AMI EC2 autonome du gateway S4 de compression S3 transparente avec codecs NVIDIA nvCOMP GPU préinstallés. Lancez-la sur une instance GPU (g4dn / g5 / g6), pointez vos clients S3 vers elle, et réduisez les octets de stockage S3 de 50–80% pour les données compressibles — sans aucune modification applicative.
S4 est un gateway compatible S3, remplaçable directement, qui compresse de façon transparente chaque objet en route vers votre bucket. L’AMI inclut Amazon Linux 2023, le driver NVIDIA, le runtime de conteneur et la build GPU de S4 (nvCOMP Bitcomp / zstd / GDeflate), préinstallés comme service systemd — aucune configuration CUDA, driver ou nvCOMP requise. Sur une instance GPU, il route les données entières et columnar (Parquet, ORC, postings, time-series) vers les codecs nvCOMP GPU, et les données texte ou logs vers CPU zstd, objet par objet. Les entrées déjà compressées passent sans modification.
Le problème
Votre facture de stockage S3 augmente linéairement avec le nombre d'octets que vous conservez, et la plupart de ces octets — logs, JSON, Parquet/ORC — sont hautement compressibles. Vos applications les écrivent sans compression car modifier leur méthode de stockage ne vaut pas l'effort d'ingénierie, vous payez donc pour stocker des octets dont vous n'avez pas réellement besoin. Le résultat est une facture qui grimpe chaque mois pour des données qui pourraient être 3× plus petites ou plus.
Fonctionnement
- 1
Lancer l'AMI GPU
Lancez l'AMI S4 — Amazon Linux 2023 avec le pilote NVIDIA et nvCOMP préinstallés et S4 s'exécutant en tant que service systemd — sur une instance g4dn, g5, g6 ou g6e au sein de votre propre VPC.
- 2
Rediriger vos clients S3
Modifiez uniquement l'URL d'endpoint de vos clients boto3 / aws-cli / Spark / Trino / DuckDB ; l'authentification SigV4, le multipart upload et le Range GET continuent de fonctionner sans modification.
- 3
Compresser de manière transparente en transit
À chaque PUT, le dispatcher échantillonne le payload et l'oriente vers le meilleur codec — CPU zstd pour le texte/logs, GPU nvCOMP Bitcomp pour les entiers colonnaires, passthrough pour les données déjà compressées — et GET renvoie les octets d'origine.
Points forts
Compression GPU préinstallée : driver NVIDIA + nvCOMP (Bitcomp / zstd / GDeflate) intégrés dans l’AMI. Lancez sur g4dn / g5 / g6 et S4 utilise automatiquement le GPU pour les données entières et columnar.
50–80% d’octets de stockage S3 en moins pour les données compressibles, avec reporting intégré des économies mesurées par bucket (s4 savings).
Aucune modification applicative et pas de lock-in : endpoint compatible S3 wire, et les objets restent lisibles sans le gateway via les outils Apache-2.0 CLI / Python / fsspec.
Ce qui est inclus
- Une AMI EC2 (Amazon Linux 2023) avec le pilote NVIDIA et nvCOMP préinstallés et S4 s'exécutant en tant que service systemd, facturée par heure d'instance sur votre facture AWS habituelle.
- Familles d'instances GPU prises en charge : g4dn, g5, g6 et g6e.
- Un endpoint compatible avec le protocole S3 — authentification SigV4 / SigV4a, multipart upload, Range GET et SSE — utilisable en drop-in par n'importe quel SDK ou outil S3.
- Dispatch de codecs par payload entre CPU zstd, GPU nvCOMP Bitcomp / zstd / GDeflate et passthrough — choisi automatiquement par échantillonnage de l'entropie et des magic-bytes, les entrées déjà compressées étant transmises sans modification.
- Rapport d'économies : s4 estimate projette les économies sur un bucket existant avant le déploiement, et le registre s4 savings indique les octets de stockage et les dollars réellement économisés, avec métriques Prometheus et tableau de bord Grafana inclus.
- Outils de lecture sans lock-in : la CLI s4-codec Apache-2.0, le package Python s4-codec, l'adaptateur fsspec s4fs (pandas / pyarrow / DuckDB) et un décodeur de navigateur WASM lisent tous les objets sans passerelle.
- Outils Day-2 : s4 migrate compresse rétroactivement les objets existants et s4 recompact re-compresse les données froides, tandis que le Range GET reste rapide grâce à un index de frame sidecar compatible avec les lecteurs Parquet/ORC.
Cas d'usage
Équipes ingérant de gros volumes de logs ou de JSON (logs d'accès nginx, logs d'application) dont la facture S3 is dominée par du texte hautement compressible.
Data lakes stockant des données Parquet/ORC et des entiers colonnaires (postings, séries temporelles) qui souhaitent réduire leur empreinte tout en maintenant la rapidité des analyses Range-GET.
Organisations ayant une facture mensuelle S3 supérieure à environ $3,000, ou exploitant déjà des instances GPU, où les économies de stockage couvrent largement le coût de calcul GPU.
Pipelines ETL / ML qui souhaitent implémenter la compression sans réécrire le code de l'application — il suffit de rediriger l'endpoint S3.
Études de cas et benchmarks
Compression du stockage pour le frozen tier d'Elasticsearch
Mesuré de bout en bout sur un cluster Elasticsearch 9.4.2 réel (ES → S4 → MinIO, index de logs de 4M de documents). La compression du repository de snapshots du frozen-tier avec le format par défaut zstd-3 a réduit le stockage de 27% (standard) / 22% (LogsDB) — jusqu'à 33% avec s4 recompact — tandis que les requêtes analytiques sur le frozen tier froid sont restées à ±1 ms de l'accès direct, sans augmentation mesurable du temps de snapshot. Combiné avec LogsDB, cela génère un repository 2.82× plus petit que la configuration standard par défaut.
Lire le benchmark completCompression du stockage pour les searchable-snapshots d'OpenSearch
Mesuré de bout en bout sur un cluster OpenSearch 2.19 réel (OpenSearch → S4 → MinIO, index de logs de 4M de documents). La compression du repository S3 de searchable-snapshots avec S4 a réduit le stockage de 28% (default) / 17% (best_compression / zstd / zstd_no_dict). Comme l'index.codec d'OpenSearch ne compresse que les champs stockés (stored fields), S4 économise tout de même ~17% de plus par rapport au codec zstd natif en compressant les doc-values et les postings. Lors de ce test local, la latence de recherche remote_snapshot est restée à ~1.5 ms près de l'accès direct (S4 étant équivalent ou plus rapide). Nécessite le flag --logical-etag de S4 pour repository-s3 (ajouté dans ce travail).
Lire le benchmark completCompression des chunks Grafana Loki
Mesuré de bout en bout sur une instance Grafana Loki 3.3.2 réelle (Loki → S4 → MinIO, 4M de lignes de logs). La re-compression des chunks snappy de Loki avec S4 zstd-3 a réduit le stockage du bucket de 18.4% (zstd-9 19.3%). En toute franchise : passer le chunk_encoding propre à Loki en zstd permet d'économiser 38% sur les nouveaux chunks — ce qui est supérieur à S4 —, la valeur ajoutée de S4 réside donc dans le backlog snappy immuable existant, et non sur le greenfield (complémentaire, et non un remplacement). Lectures : un GET de chunk complet via S4 coûte environ ~1.7 ms de plus (octets identiques ; coût de décompression, exécution locale). Contrairement à OpenSearch, --logical-etag n'est pas requis pour Loki (recommandé pour des ETags corrects).
Lire le benchmark completCompression du stockage hiérarchisé Kafka
Mesuré de bout en bout sur un cluster Apache Kafka 3.9.1 réel (KIP-405 tiered storage + le plugin Aiven → S4 → MinIO, 600k enregistrements/topic). La re-compression des segments de logs hiérarchisés avec S4 zstd-3 a réduit les octets stockés de 74.7% pour none (non compressé) / 22.6% pour snappy / 20.6% pour lz4 / 0.0% pour zstd, selon le compression.type du producer. En toute franchise : si le producer envoie du zstd, il réduit les segments à la source (43.9 MB — soit le même plancher que S4 atteint par rapport à none, 42.0 MB), et S4 n'ajoute quasiment rien sur les segments déjà au format zstd. La valeur de S4 réside donc dans les segments configurés en none/snappy/lz4 ou dans les cas où l'on ne peut pas modifier le producer (complémentaire, et non un remplacement). Aucun impact systématique de S4 sur la latence de fetch à distance à froid (exécution locale, échantillons uniques bruités). Contrairement à OpenSearch, --logical-etag n'est pas requis pour Kafka (recommandé pour des ETags corrects).
Lire le benchmark completRecompaction de Parquet froid
Mesuré localement par rapport à MinIO (un fichier Parquet de logs de style ECS de 2,000,000 de lignes, 13 colonnes). Une nouvelle sous-commande s4 parquet-recompact ré-encode les chunks de colonnes des fichiers Parquet froids du data-lake en zstd et réécrit un fichier Parquet NATIF — pyarrow / Spark / Trino / DuckDB le lisent directement, sans S4 dans le chemin de lecture. Par rapport à snappy (le format par défaut du data-lake), il a réduit le stockage de 36.6%, par rapport au format non compressé de 51.7%, à gzip de 3.8% et à zstd déjà existant de 0.0% (ignoré). Chaque sortie est identique valeur par valeur (pyarrow table.equals). En toute franchise : configurer le codec du writer sur zstd permet d'atteindre le même plancher à la source (79.4 MB), la valeur ajoutée de S4 réside donc dans le backlog existant de formats snappy/none/gzip pour lequel personne ne relance de tâche d'écriture (complémentaire, et non un remplacement). Chaque objet fait l'objet d'une validation de valeur par groupe de lignes (limite de mémoire fixe) avant l'écrasement sur place, et les objets non vérifiables ne sont jamais écrasés.
Lire le benchmark completFAQ
Si j'arrête d'exécuter S4, puis-je toujours lire mes données ?
Oui. Les objets compressés et leurs sidecars S4IX restent natifs S3 et peuvent être listés et téléchargés avec l'aws-cli ou boto3 standard. Pour récupérer le payload d'origine, vous utilisez la CLI s4-codec Apache-2.0, le package Python s4-codec, l'adaptateur fsspec s4fs (pandas / pyarrow / DuckDB) ou le décodeur de navigateur WASM — qui sont tous open source, réalisent un décodage pur, et ne nécessitent aucun runtime de passerelle (gateway).
Dois-je modifier mes applications ?
Non. S4 utilise le protocole S3 — même authentification SigV4, même multipart, même Range GET, mêmes appels SDK. Vous modifiez uniquement l'URL d'endpoint vers laquelle pointe votre client boto3 / aws-cli / Spark / Trino / DuckDB ; rien d'autre ne change.
Quelle partie de ma facture devient réellement moins chère ?
Octets de stockage uniquement. S4 réduit les octets stockés dans S3 de 50–80% pour les données compressibles — par exemple, 1 TiB de logs nginx se compresse à environ 6.6 GiB. Le coût des requêtes (PUT/GET), l'egress et le calcul GPU restent inchangés. En raison du coût de l'instance GPU, S4 est généralement rentable au-delà d'une facture S3 d'environ $1,000/mois (moins avec des instances spot ou si vous utilisez déjà des GPU).
Quelles instances GPU l'AMI prend-elle en charge ?
L'AMI EC2 (Amazon Linux 2023, driver NVIDIA + nvCOMP préinstallés) fonctionne sur les instances g4dn, g5, g6 et g6e, facturée par heure d'instance sur votre facture AWS habituelle. Il n'y a pas de clé de licence — la mesure de l'usage est gérée par AWS Marketplace.
Où fonctionne S4, et qui peut voir mes données ?
Vous lancez l'AMI dans votre propre compte AWS et VPC, et elle communique avec votre propre bucket S3 — aucune donnée ne quitte votre compte, et aucun service tiers n'intervient sur le chemin. Elle prend en charge TLS et le chiffrement côté serveur (SSE).
Pourquoi c'est moins cher
Hypothèse : 100 TB stockés sur S3 Standard (us-east-1), sur des données compressibles à ~3× (Parquet/ORC, JSON, etc.).
- Stockage S3 (100 TB)
- $2,300 / mois
- Total mensuel
- $2,300 / mois
- Stockage S3 (34 TB compressés)
- $800 / mois
- Instance S4 (g4dn.xlarge + frais logiciels)
- $385 / mois
- Total mensuel
- $1,185 / mois
Dimensionner l'instance S4 selon la charge d'écriture
| Charge d'écriture | Instance recommandée | Coût de l'instance S4 | Total avec 100 TB stockés |
|---|---|---|---|
| ~1 TB / jour | g4dn.xlarge | $385 / mois | $1,185 / mois (−49 %) |
| ~10 TB / jour | g6.xlarge | $590 / mois | $1,390 / mois (−40 %) |
| Haute concurrence / 100 TB / jour | g6.4xlarge | $965 / mois | $1,765 / mois (−23 %) |
Exemple à titre indicatif. Le stockage est calculé à partir du tarif publié S3 Standard (us-east-1) (0,023 $/Go-mois) et des prix à la demande EC2 pour g4dn / g6. Les frais logiciels S4 sont facturés à l'heure via AWS Marketplace, séparément du coût EC2 (un Savings Plan d'un an réduit généralement la part EC2 de 30–40 %). Les économies réelles dépendent de la compressibilité de vos données (Parquet, JSON ~3–5× ; logs texte ~4–10×) et des schémas de lecture/écriture.
Modèle de tarification
Frais logiciels horaires + le GPU EC2 de votre choix (g4dn / g5 / g6). Facturation à l’usage par type d’instance, option annuelle disponible, aucune clé de licence.
Autres produits S4
S4 Logs
Archiver CloudWatch Logs vers S3 zstd
S4 Metrics
Gouverner la cardinalité des métriques CloudWatch
S4 NAT
NAT optimisé en coût pour Amazon VPC