S4 — Squished S3
Gateway transparente de compressão S3 com GPU
Quando isso se paga?
Exemplo: US$ 10.000/mês em armazenamento S3 compressível
Com US$ 10.000/mês em armazenamento S3 compressível, uma redução de 50–80% equivale a cerca de US$ 5.000–8.000/mês de cobrança bruta de uso evitada — antes da taxa de software S4, computação de execução e diferenças de workload.
Estime sua economia
Informe seu gasto ou uso mensal relevante para uma estimativa aproximada — sem upload de fatura.
AMI EC2 autônoma do gateway S4 de compressão transparente para S3, com codecs NVIDIA nvCOMP GPU pré-instalados. Inicie em uma instância GPU (g4dn / g5 / g6), aponte seus clientes S3 para ela e reduza os bytes de armazenamento S3 em 50–80% para dados compressíveis — sem nenhuma alteração na aplicação.
S4 é um gateway drop-in compatível com S3 que comprime de forma transparente todos os objetos a caminho do seu bucket. A AMI inclui Amazon Linux 2023, driver NVIDIA, runtime de containers e a build GPU do S4 (nvCOMP Bitcomp / zstd / GDeflate) pré-instalados como serviço systemd — sem necessidade de configurar CUDA, driver ou nvCOMP. Em uma instância GPU, ele roteia dados inteiros e colunares (Parquet, ORC, postings, séries temporais) para codecs nvCOMP GPU e dados de texto ou logs para CPU zstd, por objeto. Entradas já comprimidas passam sem alteração.
O problema
Sua fatura de armazenamento do S3 cresce linearmente com os bytes que você mantém, e a maioria desses bytes — logs, JSON, Parquet/ORC — é altamente compressível. Suas aplicações os gravam sem compressão porque alterar a forma como armazenam os dados não vale o esforço de engenharia, então você paga para armazenar bytes que realmente não precisa. O resultado é uma fatura que sobe a cada mês para dados que poderiam ser 3× menores ou mais.
Como funciona
- 1
Iniciar a AMI de GPU
Inicie a AMI do S4 — Amazon Linux 2023 com driver NVIDIA e nvCOMP pré-instalados e o S4 executando como um serviço systemd — em uma instância g4dn, g5, g6 ou g6e dentro da sua própria VPC.
- 2
Redirecione seus clientes do S3
Altere apenas a URL do endpoint nos seus clientes boto3 / aws-cli / Spark / Trino / DuckDB; a autenticação SigV4, o upload multipart e o Range GET continuam funcionando sem alterações.
- 3
Comprima de forma transparente em trânsito
A cada PUT, o dispatcher analisa uma amostra do payload e o direciona para o melhor codec — CPU zstd para texto/logs, GPU nvCOMP Bitcomp para inteiros colunares, passthrough para dados já compactados — e o GET retorna os bytes originais.
Destaques
Compressão GPU pré-instalada: driver NVIDIA + nvCOMP (Bitcomp / zstd / GDeflate) incorporados à AMI. Inicie em g4dn / g5 / g6 e o S4 usa a GPU automaticamente para dados inteiros e colunares.
50–80% menos bytes de armazenamento S3 para dados compressíveis, com relatório integrado de economia medida por bucket (s4 savings).
Zero alterações na aplicação e sem lock-in: endpoint compatível com o protocolo S3, e os objetos continuam legíveis sem o gateway por meio de ferramentas Apache-2.0 CLI / Python / fsspec.
O que está incluído
- Uma AMI do EC2 (Amazon Linux 2023) com o driver NVIDIA e nvCOMP pré-instalados e o S4 executando como um serviço systemd, faturada por hora de instância em sua fatura normal da AWS.
- Famílias de instâncias de GPU suportadas: g4dn, g5, g6 e g6e.
- Um endpoint compatível com o protocolo S3 — autenticação SigV4 / SigV4a, upload multipart, Range GET e SSE — utilizável como um substituto drop-in por qualquer SDK ou ferramenta S3.
- Direcionamento de codec por payload entre CPU zstd, GPU nvCOMP Bitcomp / zstd / GDeflate e passthrough — escolhido de forma automática por amostragem de entropia e magic-bytes, com entradas já compactadas passando sem alterações.
- Relatório de economia: o s4 estimate projeta a economia em um bucket existente antes da implantação, e o ledger s4 savings relata os bytes de armazenamento e os dólares realmente economizados, com métricas do Prometheus e um dashboard do Grafana inclusos.
- Ferramentas de leitura sem lock-in: a CLI s4-codec Apache-2.0, o pacote Python s4-codec, o adaptador fsspec s4fs (pandas / pyarrow / DuckDB) e um decodificador WASM para navegador leem objetos sem a necessidade do gateway.
- Ferramentas de Dia 2: o s4 migrate comprime retrospectivamente objetos existentes e o s4 recompact recomprime dados frios, enquanto o Range GET permanece rápido por meio de um índice de frames sidecar compatível com leitores Parquet/ORC.
Casos de uso
Equipes que ingerem grandes volumes de logs ou JSON (logs de acesso do nginx, logs de aplicação) cuja fatura do S3 é dominada por texto altamente compressível.
Data lakes que armazenam Parquet/ORC e dados de inteiros colunares (postings, séries temporais) e que desejam um footprint menor enquanto mantêm as consultas analíticas de Range GET rápidas.
Organizações com uma fatura mensal do S3 superior a aproximadamente $3,000, ou que já executam instâncias de GPU, onde a economia de armazenamento cobre confortavelmente o custo de computação da GPU.
Pipelines de ETL / ML que desejam compressão sem reescrever o código da aplicação — basta redirecionar o endpoint do S3.
Estudos de caso e benchmarks
Compressão de armazenamento do Elasticsearch frozen-tier
Medido de ponta a ponta em um cluster real do Elasticsearch 9.4.2 (ES → S4 → MinIO, índice de logs de 4M de documentos). A compressão do repositório de snapshots frozen-tier no padrão zstd-3 reduziu o armazenamento em 27% (standard) / 22% (LogsDB) — até 33% com o s4 recompact —, enquanto as consultas analíticas frias em dados frozen permaneceram dentro de ±1 ms em relação ao acesso direto, e os snapshots não sofreram aumento no tempo de relógio real (~no wall-clock). Combinado com o LogsDB, ele resulta em um repositório 2.82× menor do que o padrão standard nativo.
Ler o benchmark completoCompressão de armazenamento do OpenSearch searchable-snapshot
Medido de ponta a ponta em um cluster real do OpenSearch 2.19 (OpenSearch → S4 → MinIO, índice de logs de 4M de documentos). A compressão do repositório S3 de searchable-snapshots com o S4 reduziu o armazenamento em 28% (default) / 17% (best_compression / zstd / zstd_no_dict). Como o index.codec do OpenSearch comprime apenas stored fields, o S4 ainda economiza ~17% além do codec zstd nativo ao compactar doc-values e postings. Nesta execução local, a latência de busca do remote_snapshot permaneceu dentro de ~1.5 ms em relação ao acesso direto (S4 igual ou mais rápido). Requer a flag --logical-etag do S4 para repository-s3 (adicionada neste trabalho).
Ler o benchmark completoCompressão de chunks do Grafana Loki
Medido de ponta a ponta em uma instância real do Grafana Loki 3.3.2 (Loki → S4 → MinIO, 4M de linhas de log). A recompressão dos chunks snappy do Loki com S4 zstd-3 reduziu o armazenamento do bucket em 18.4% (zstd-9 19.3%). Sendo honesto: alterar o chunk_encoding do próprio Loki para zstd economiza 38% em novos chunks — mais do que o S4 —, então o diferencial do S4 é o backlog snappy imutável (forward-only), não ambientes greenfield (complementar, não um substituto). Leituras: um GET de chunk completo através do S4 custa ~1.7 ms a mais (bytes idênticos; custo de descompressão, execução local). Ao contrário do OpenSearch, a flag --logical-etag não é obrigatória para o Loki (recomendada para ETags corretos).
Ler o benchmark completoCompressão de armazenamento em camadas do Kafka
Medido de ponta a ponta em um cluster real do Apache Kafka 3.9.1 (armazenamento em camadas KIP-405 + plugin Aiven → S4 → MinIO, 600k registros/tópico). A recompressão dos segmentos de log em camadas com S4 zstd-3 reduziu os bytes armazenados em 74.7% para none (não comprimido) / 22.6% para snappy / 20.6% para lz4 / 0.0% para zstd, conforme o compression.type do producer. Sendo honesto: se o producer enviar zstd, ele encolhe os segmentos na origem (43.9 MB — o mesmo patamar que o S4 atinge em comparação ao none, 42.0 MB), e o S4 não adiciona praticamente nada em segmentos que já estão em zstd. Portanto, o valor do S4 está nos segmentos de casos com none/snappy/lz4 ou quando não se pode alterar o producer (complementar, não um substituto). Sem penalidade consistente de busca remota fria (cold remote-fetch) com o S4 (execução local, amostras únicas com ruído). Ao contrário do OpenSearch, a flag --logical-etag não é obrigatória para o Kafka (recomendada para ETags corretos).
Ler o benchmark completoRecompactação de Parquet frio
Medido localmente contra o MinIO (um arquivo Parquet de logs no estilo ECS de 2.000.000 de linhas, 13 colunas). Um novo subcomando s4 parquet-recompact recodifica chunks de colunas Parquet frias de data lakes para zstd e grava de volta um Parquet NATIVO — pyarrow / Spark / Trino / DuckDB o leem diretamente, sem o S4 no caminho de leitura. Sobre o snappy (o padrão do data lake), reduziu o armazenamento em 36.6%, sobre não comprimido em 51.7%, gzip 3.8% e já em zstd 0.0% (pulado). Cada saída é idêntica valor por valor (pyarrow table.equals). Sendo honesto: definir o codec do gravador (writer) para zstd atinge o mesmo patamar na origem (79.4 MB), então o diferencial do S4 é o backlog existente de snappy/none/gzip para o qual ninguém executa novamente uma tarefa de gravação (complementar, não um substituto). Cada objeto é verificado por valor por grupo de linhas (row group) (memória limitada) antes da sobrescrita in-place, e objetos não verificáveis nunca são sobrescritos.
Ler o benchmark completoFAQ
Se eu parar de executar o S4, ainda poderei ler meus dados?
Sim. Os objetos compactados e seus sidecars S4IX continuam nativos do S3 e permanecem listáveis e baixáveis com o aws-cli ou boto3 padrão. Para recuperar o payload original, você usa a CLI s4-codec Apache-2.0, o pacote Python s4-codec, o adaptador fsspec s4fs (pandas / pyarrow / DuckDB) ou o decodificador WASM para navegador — todos de código aberto, decodificação pura, sem necessidade de tempo de execução do gateway.
Preciso alterar minhas aplicações?
Não. O S4 fala o protocolo S3 — mesma autenticação SigV4, mesmo multipart, mesmo Range GET, mesmas chamadas de SDK. Você altera apenas a URL do endpoint para a qual seu cliente boto3 / aws-cli / Spark / Trino / DuckDB aponta; nada mais muda.
Qual parte da minha fatura realmente fica mais barata?
Apenas bytes de armazenamento. O S4 reduz os bytes armazenados no S3 em 50–80% para dados compactáveis — por exemplo, 1 TiB de logs do nginx é compactado para cerca de 6.6 GiB. O custo de requisição (PUT/GET), egress e computação de GPU permanecem inalterados. Devido ao custo da instância de GPU, o S4 geralmente se paga acima de uma fatura de S3 de aproximadamente $1,000/mês (menos em instâncias spot ou se você já executa GPUs).
Quais instâncias de GPU a AMI suporta?
A AMI de EC2 (Amazon Linux 2023, driver NVIDIA + nvCOMP pré-instalados) roda em instâncias g4dn, g5, g6 e g6e, cobrada por hora de instância na sua fatura regular da AWS. Não há chave de licença — a medição é gerenciada pelo AWS Marketplace.
Onde o S4 é executado e quem pode ver meus dados?
Você inicia a AMI em sua própria conta AWS e VPC, e ela se comunica com o seu próprio bucket do S3 — nenhum dado sai da sua conta e não há serviços de terceiros no caminho. Ela suporta TLS e criptografia no lado do servidor (SSE).
Por que é mais barato
Pressuposto: 100 TB armazenados no S3 Standard (us-east-1), com dados que comprimem ~3× (Parquet/ORC, JSON, etc.).
- Armazenamento S3 (100 TB)
- $2,300 / mês
- Total mensal
- $2,300 / mês
- Armazenamento S3 (34 TB comprimidos)
- $800 / mês
- Instância S4 (g4dn.xlarge + taxa de software)
- $385 / mês
- Total mensal
- $1,185 / mês
Dimensionar a instância S4 conforme a carga de escrita
| Carga de escrita | Instância recomendada | Custo da instância S4 | Total com 100 TB armazenados |
|---|---|---|---|
| ~1 TB / dia | g4dn.xlarge | $385 / mês | $1,185 / mês (−49 %) |
| ~10 TB / dia | g6.xlarge | $590 / mês | $1,390 / mês (−40 %) |
| Alta concorrência / 100 TB / dia | g6.4xlarge | $965 / mês | $1,765 / mês (−23 %) |
Exemplo ilustrativo. O armazenamento é calculado pela tarifa publicada do S3 Standard (us-east-1) (US$ 0,023/GB-mês) e pelos preços sob demanda do EC2 para g4dn / g6. A taxa de software do S4 é cobrada por hora via AWS Marketplace, separadamente do custo do EC2 (um Savings Plan de 1 ano normalmente reduz a parte do EC2 em 30–40 %). A economia real depende da compressibilidade dos dados (Parquet, JSON ~3–5×; logs de texto ~4–10×) e dos padrões de leitura/escrita.
Modelo de precificação
Taxa de software por hora + o GPU EC2 que você escolher (g4dn / g5 / g6). Medição por tipo de instância, opção anual disponível, sem chaves de licença.
Outros produtos S4
S4 Logs
Arquive CloudWatch Logs em S3 com zstd
S4 Metrics
Controle a cardinalidade de métricas do CloudWatch
S4 NAT
NAT com custo otimizado para Amazon VPC