S4 — Squished S3
Transparenter GPU S3-Komprimierungs-Gateway
Wann amortisiert sich das?
Beispiel: 10.000 $/Monat komprimierbarer S3-Speicher
Bei 10.000 $/Monat komprimierbarem S3-Speicher entspricht eine Reduktion von 50–80% grob 5.000–8.000 $/Monat brutto vermiedener Nutzungsgebühren — vor S4-Softwaregebühr, Laufzeit-Compute und Workload-Unterschieden.
Ihre Einsparung schätzen
Geben Sie relevante monatliche Ausgaben oder Nutzung ein — kein Rechnungs-Upload nötig.
Eigenständige EC2 AMI des transparenten S4 S3-Komprimierungs-Gateways mit vorinstallierten NVIDIA nvCOMP GPU-Codecs. Auf einer GPU-Instanz (g4dn / g5 / g6) starten, Ihre S3-Clients darauf ausrichten und S3-Speicherbytes für komprimierbare Daten um 50–80% reduzieren — ohne Änderungen an der Anwendung.
S4 ist ein drop-in, S3-kompatibler Gateway, der jedes Objekt auf dem Weg zu Ihrem Bucket transparent komprimiert. Die AMI enthält Amazon Linux 2023, den NVIDIA-Treiber, die Container-Runtime und den GPU-Build von S4 (nvCOMP Bitcomp / zstd / GDeflate), vorinstalliert als systemd-Service — kein CUDA-, Treiber- oder nvCOMP-Setup erforderlich. Auf einer GPU-Instanz leitet S4 Integer- und spaltenorientierte Daten (Parquet, ORC, Postings, Zeitreihen) objektweise an nvCOMP GPU-Codecs und Text- oder Log-Daten an CPU zstd weiter. Bereits komprimierte Eingaben werden unverändert durchgereicht.
Das Problem
Ihre S3-Speicherrechnung wächst linear mit der Menge der gespeicherten Bytes, obwohl die meisten dieser Daten — wie Logs, JSON, Parquet/ORC — hochgradig komprimierbar sind. Ihre Anwendungen schreiben diese unkomprimiert, weil sich der Entwicklungsaufwand für eine Änderung der Datenspeicherung nicht lohnt. Dadurch bezahlen Sie für Speicherplatz, den Sie eigentlich gar nicht benötigen. Das Ergebnis ist eine monatlich steigende Rechnung für Daten, die um das Dreifache oder mehr verkleinert werden könnten.
Funktionsweise
- 1
GPU-AMI starten
Starten Sie das S4-AMI — Amazon Linux 2023 mit vorinstalliertem NVIDIA-Treiber und nvCOMP sowie S4 als systemd-Dienst — auf einer g4dn-, g5-, g6- oder g6e-Instanz in Ihrer eigenen VPC.
- 2
S3-Clients umleiten
Ändern Sie lediglich die Endpunkt-URL auf Ihren boto3- / aws-cli- / Spark- / Trino- / DuckDB-Clients; SigV4-Authentifizierung, Multipart-Upload und Range-GETs funktionieren unverändert weiter.
- 3
Transparente Komprimierung bei der Übertragung
Bei jedem PUT analysiert der Dispatcher einen Teil der Payload (Sampling) und wählt den optimalen Codec — CPU-zstd für Text/Logs, GPU-nvCOMP Bitcomp für spaltenbasierte Integer, Passthrough für bereits komprimierte Daten — während GET die ursprünglichen Bytes zurückgibt.
Highlights
GPU-Komprimierung vorinstalliert: NVIDIA-Treiber + nvCOMP (Bitcomp / zstd / GDeflate) sind in die AMI integriert. Auf g4dn / g5 / g6 starten, und S4 nutzt die GPU automatisch für Integer- und spaltenorientierte Daten.
50–80% weniger S3-Speicherbytes für komprimierbare Daten, mit integrierter gemessener Savings-Auswertung pro Bucket (s4 savings).
Keine Anwendungsänderungen und kein Lock-in: S3 wire-kompatibler Endpoint, und Objekte bleiben auch ohne Gateway über Apache-2.0 CLI / Python / fsspec-Tools lesbar.
Lieferumfang
- Ein EC2-AMI (Amazon Linux 2023) mit vorinstalliertem NVIDIA-Treiber und nvCOMP, bei dem S4 als systemd-Dienst läuft. Die Abrechnung erfolgt pro Instanzstunde über Ihre reguläre AWS-Rechnung.
- Unterstützte GPU-Instanzfamilien: g4dn, g5, g6 und g6e.
- Ein S3-protokollkompatibler Endpunkt — unterstützt SigV4- / SigV4a-Authentifizierung, Multipart-Upload, Range-GET und SSE —, der von jedem S3-SDK oder Tool als Drop-in-Ersatz verwendet werden kann.
- Codec-Verteilung pro Payload über CPU-zstd, GPU-nvCOMP Bitcomp / zstd / GDeflate und Passthrough — automatische Auswahl durch Entropie- und Magic-Byte-Sampling, wobei bereits komprimierte Daten unverändert durchgelassen werden.
- Einsparungsberichte: s4 estimate prognostiert die Einsparungen in einem bestehenden Bucket vor der Bereitstellung, und das s4 savings-Hauptbuch erfasst die tatsächlich eingesparten Speicher-Bytes und Dollar. Prometheus-Metriken und ein Grafana-Dashboard sind im Lieferumfang enthalten.
- Lösungen zur Vermeidung von Lock-in: Die Apache-2.0 s4-codec CLI, das s4-codec Python-Paket, der s4fs fsspec-Adapter (pandas / pyarrow / DuckDB) und ein WASM-Browser-Decoder ermöglichen das Lesen von Objekten ganz ohne Gateway.
- Werkzeuge für den laufenden Betrieb (Day-2-Operations): s4 migrate komprimiert bestehende Objekte nachträglich, und s4 recompact komprimiert kalte Daten neu. Range-GET bleibt dank eines mit Parquet- und ORC-Readern kompatiblen Sidecar-Frame-Index schnell.
Anwendungsfälle
Teams, die große Mengen an Logs oder JSON (nginx-Zugriffslogs, Anwendungslogs) erfassen und deren S3-Rechnung hauptsächlich durch hochgradig komprimierbaren Text verursacht wird.
Data Lakes, die Parquet/ORC und spaltenbasierte Integer-Daten (Postings, Zeitreihen) speichern und ihren Speicherbedarf reduzieren möchten, während die Range-GET-Performance für Analysen hoch bleibt.
Unternehmen mit einer monatlichen S3-Rechnung von über ca. $3,000 oder solche, die bereits GPU-Instanzen betreiben, bei denen die Speichereinsparungen die GPU-Rechenkosten problemlos decken.
ETL- / ML-Pipelines, die eine Komprimierung ohne Umschreiben des Anwendungscodes implementieren möchten — es muss lediglich der S3-Endpunkt umgeleitet werden.
Fallstudien und Benchmarks
Speicherkomprimierung für Elasticsearch Frozen Tier
End-to-End-Messung auf einem echten Elasticsearch 9.4.2-Cluster (ES → S4 → MinIO, Log-Index mit 4 Mio. Dokumenten). Die Komprimierung des Frozen-Tier-Snapshot-Repositorys mit dem Standardwert zstd-3 senkte den Speicherbedarf um 27% (Standard) / 22% (LogsDB) — bis zu 33% mit s4 recompact —, während die Latenz kalter Frozen-Analyse-Abfragen innerhalb von ±1ms im Vergleich zum direkten Zugriff blieb und die Snapshot-Erstellung praktisch keine zusätzliche Zeit beanspruchte. In Kombination mit LogsDB ergibt sich ein Repository, das 2.82× kleiner ist als die Standard-Direktspeicherung.
Benchmark lesenSpeicherkomprimierung für OpenSearch Searchable Snapshots
End-to-End-Messung auf einem echten OpenSearch 2.19-Cluster (OpenSearch → S4 → MinIO, Log-Index mit 4 Mio. Dokumenten). Die Komprimierung des Searchable-Snapshot-S3-Repositorys mit S4 reduzierte den Speicherbedarf um 28% (default) / 17% (best_compression / zstd / zstd_no_dict). Da der index.codec von OpenSearch nur gespeicherte Felder komprimiert, spart S4 durch die Reduzierung von doc-values und postings selbst auf dem nativen zstd-Codec zusätzlich ~17% ein. In diesem lokalen Testlauf blieb die remote_snapshot-Suchlatenz innerhalb von ~1.5 ms im Vergleich zum direkten Zugriff (S4 gleich schnell oder schneller). Erfordert das Flag --logical-etag von S4 für repository-s3 (in dieser Version hinzugefügt).
Benchmark lesenGrafana Loki Chunk-Komprimierung
End-to-End-Messung auf einer echten Grafana Loki 3.3.2-Instanz (Loki → S4 → MinIO, 4 Mio. Logzeilen). Die Rekomprimierung der snappy-Chunks von Loki mit S4 zstd-3 reduzierte den Bucket-Speicherbedarf um 18.4% (zstd-9 19.3%). Offen gesagt: Das Umstellen von Lokis eigener chunk_encoding auf zstd spart bei neuen Chunks 38% — also mehr als S4. Der Nutzen von S4 liegt daher im bereits bestehenden, unveränderlichen snappy-Backlog, nicht in neuen Daten (Ergänzung, kein Ersatz). Lesezugriffe: Ein GET für einen vollständigen Chunk über S4 dauert ~1.7 ms länger (Byte-Identität; Dekomprimierungskosten, lokaler Testlauf). Im Gegensatz zu OpenSearch ist --logical-etag für Loki nicht zwingend erforderlich (wird jedoch für korrekte ETags empfohlen).
Benchmark lesenKafka Tiered-Storage-Komprimierung
End-to-End-Messung auf einem echten Apache Kafka 3.9.1-Cluster (KIP-405 Tiered Storage + Aiven-Plugin → S4 → MinIO, 600k Datensätze/Topic). Die Rekomprimierung der per Tiered Storage in S3 ausgelagerten Log-Segmente mit S4 zstd-3 reduzierte die gespeicherten Bytes je nach compression.type des Producers um 74.7% bei none (unkomprimiert) / 22.6% bei snappy / 20.6% bei lz4 / 0.0% bei zstd. Offen gesagt: Wenn der Producer zstd verwendet, werden die Segmente bereits an der Quelle komprimiert (43.9 MB — was dem Niveau von 42.0 MB entspricht, das S4 bei none erreicht) und S4 bringt bei bereits komprimierten zstd-Segmenten so gut wie keinen Mehrwert. Der Wert von S4 liegt daher in den Segmenten von none/snappy/lz4 oder in Fällen, in denen der Producer nicht geändert werden kann (Ergänzung, kein Ersatz). Kein konsistenter S4-Latenznachteil beim Abrufen kalter Remote-Daten (lokaler Testlauf, einzelne verrauschte Stichproben). Im Gegensatz zu OpenSearch ist --logical-etag für Kafka nicht zwingend erforderlich (wird jedoch für korrekte ETags empfohlen).
Benchmark lesenRekomprimierung von kaltem Parquet
Lokale Messung gegen MinIO (eine ECS-konforme Log-Parquet-Datei mit 2.000.000 Zeilen und 13 Spalten). Ein neuer Subbefehl s4 parquet-recompact codiert die Spalten-Chunks von kalten Data-Lake-Parquet-Dateien in zstd um und schreibt eine NATIVE Parquet-Datei zurück — pyarrow / Spark / Trino / DuckDB lesen diese direkt, ohne dass S4 im Lesepfad erforderlich ist. Im Vergleich zu snappy (dem Data-Lake-Standard) wurde der Speicherbedarf um 36.6% reduziert, im Vergleich zu unkomprimiert um 51.7%, bei gzip um 3.8% und bereits komprimiertes zstd wurde mit 0.0% übersprungen. Jeder Ausgabewert ist absolut identisch (pyarrow table.equals). Offen gesagt: Die Konfiguration des Writer-Codecs auf zstd erreicht an der Quelle dieselbe Untergrenze (79.4 MB). Der Nutzen von S4 liegt daher im bestehenden snappy-/none-/gzip-Backlog, für das niemand einen Writer-Job erneut ausführt (Ergänzung, kein Ersatz). Jedes Objekt wird vor dem In-Place-Überschreiben zeilenweise pro Zeilengruppe verifiziert (begrenzter Speicher), und nicht verifizierbare Objekte werden niemals überschrieben.
Benchmark lesenFAQ
Kann ich meine Daten weiterhin lesen, wenn ich S4 stoppe?
Ja. Die komprimierten Objekte und ihre S4IX-Sidecars bleiben S3-nativ und können weiterhin mit den standardmäßigen aws-cli oder boto3 aufgelistet und heruntergeladen werden. Um die Originaldaten wiederherzustellen, verwenden Sie die Apache-2.0 s4-codec CLI, das s4-codec Python-Paket, den s4fs fsspec-Adapter (pandas / pyarrow / DuckDB) oder den WASM-Browser-Decoder — allesamt Open Source, reine Decodierung und ohne dass eine laufende Gateway-Instanz erforderlich ist.
Muss ich meine Anwendungen anpassen?
Nein. S4 spricht das S3-Wire-Protokoll — gleiche SigV4-Authentifizierung, gleiche Multipart-Uploads, gleiche Range-GETs, gleiche SDK-Aufrufe. Sie ändern lediglich die Endpunkt-URL, auf die Ihr boto3-, aws-cli-, Spark-, Trino- oder DuckDB-Client verweist; alles andere bleibt unverändert.
Welcher Teil meiner Rechnung wird dadurch tatsächlich günstiger?
Nur Speicher-Bytes. S4 reduziert die in S3 gespeicherten Bytes für komprimierbare Daten um 50–80% — beispielsweise komprimiert 1 TiB nginx-Logs auf etwa 6,6 GiB. Anfragekosten (PUT/GET), Egress und GPU-Compute bleiben unverändert. Aufgrund der GPU-Instanzkosten lohnt sich S4 in der Regel ab einer S3-Rechnung von etwa $1,000/Monat (weniger bei Spot-Instanzen oder wenn Sie bereits GPUs betreiben).
Welche GPU-Instanzen unterstützt das AMI?
Das EC2-AMI (Amazon Linux 2023, NVIDIA-Treiber + nvCOMP vorinstalliert) läuft auf g4dn-, g5-, g6- und g6e-Instanzen und wird pro Instanzstunde auf Ihrer regulären AWS-Rechnung abgerechnet. Es gibt keinen Lizenzschlüssel — das Metering wird über den AWS Marketplace abgewickelt.
Wo läuft S4, und wer kann meine Daten sehen?
Sie starten das AMI in Ihrem eigenen AWS-Account und Ihrer VPC, und es kommuniziert mit Ihrem eigenen S3-Bucket — es verlassen keine Daten Ihren Account, und es befindet sich kein Drittanbieter-Dienst im Pfad. Es unterstützt TLS und serverseitige Verschlüsselung (SSE).
Warum es günstiger ist
Annahme: 100 TB auf S3 Standard (us-east-1), bei Daten mit etwa 3× Komprimierung (Parquet/ORC, JSON usw.).
- S3-Speicher (100 TB)
- $2,300 / Monat
- Monatssumme
- $2,300 / Monat
- S3-Speicher (34 TB nach Komprimierung)
- $800 / Monat
- S4-Instanz (g4dn.xlarge + Softwaregebühr)
- $385 / Monat
- Monatssumme
- $1,185 / Monat
S4-Instanz nach Schreiblast wählen
| Schreiblast | Empfohlene Instanz | S4-Instanzkosten | Gesamtkosten bei 100 TB Speicher |
|---|---|---|---|
| ~1 TB / Tag | g4dn.xlarge | $385 / Monat | $1,185 / Monat (−49 %) |
| ~10 TB / Tag | g6.xlarge | $590 / Monat | $1,390 / Monat (−40 %) |
| Hochparallel / 100 TB / Tag | g6.4xlarge | $965 / Monat | $1,765 / Monat (−23 %) |
Illustratives Beispiel. Die Speicherkosten basieren auf dem veröffentlichten S3-Standard-Tarif für us-east-1 (0,023 $/GB-Monat) und den On-Demand-Preisen für g4dn / g6 EC2. Die S4-Softwaregebühr wird stündlich über AWS Marketplace abgerechnet, getrennt von der EC2-Gebühr (ein 1-Jahres-Savings-Plan reduziert den EC2-Anteil typischerweise um 30–40 %). Die tatsächlichen Einsparungen hängen von der Komprimierbarkeit Ihrer Daten ab (Parquet, JSON ~3–5×; Textlogs ~4–10×) sowie von Lese-/Schreibmustern.
Preismodell
Stündliche Softwaregebühr + die von Ihnen gewählte GPU EC2 (g4dn / g5 / g6). Verbrauchsabhängig nach Instanztyp, Jahresoption verfügbar, keine Lizenzschlüssel.
Weitere S4-Produkte
S4 Logs
CloudWatch Logs nach zstd S3 archivieren
S4 Metrics
CloudWatch Metric-Cardinality steuern
S4 NAT
Kostenoptimiertes NAT für Amazon VPC