Custos de S3: storage, API e egress

⏱ 9 min de leitura

"O armazenamento custa centavos por GB." Essa frase, verdadeira e enganosa ao mesmo tempo, é a origem de muitas faturas de nuvem que vêm bem maiores do que o esperado. O preço de armazenamento é só uma parte da conta de object storage, e quase nunca é a parte que mais pesa.

Este artigo disseca a anatomia da fatura de object storage: os componentes que a compõem (armazenamento, requisições, egress, recuperação), onde o custo realmente cresce e como evitar as surpresas mais comuns.

A anatomia da fatura de object storage

Custos de object storage S3 O custo de object storage na nuvem pública é a soma de vários componentes cobrados separadamente, não um valor único. Os principais são: armazenamento (cobrado por GB ao mês, variando conforme a classe de storage), requisições de API (operações como PUT, COPY, POST e LIST custam um valor por mil requisições, e GET custa menos por mil), transferência de saída ou egress (cada GB que sai para a internet é cobrado, podendo chegar a cerca de US$ 0,09 por GB), recuperação de classes frias (recuperar dados de Glacier ou Infrequent Access tem custo por GB recuperado) e taxas extras (como monitoramento do Intelligent-Tiering). O preço de armazenamento anunciado é apenas uma parte da conta; a maior surpresa nas faturas costuma vir das requisições e, principalmente, do egress, que cresce com o uso e pode representar fatia enorme do custo total. Por isso, aplicações com muito tráfego de saída ou muitas operações por segundo custam mais do que a conta simples de GB sugere. Alguns provedores de object storage compatível com S3 adotam modelos de preço único sem egress fee e sem cobrança por API, eliminando as maiores fontes de imprevisibilidade.

A primeira coisa a entender sobre custo de object storage na nuvem pública é que não existe "um preço". A fatura é a soma de componentes que cobram de formas diferentes, e entender cada um é o que separa quem estima custo com precisão de quem leva susto no fim do mês.

Os componentes principais são quatro: armazenamento, requisições de API, egress (transferência de saída) e recuperação de classes frias. Mais algumas taxas menores. Vamos por partes, porque cada um tem uma lógica própria de cobrança. Para entender a API cujas operações geram parte desses custos, vale o conteúdo sobre a API S3.

Componente 1: armazenamento

Este é o componente mais óbvio e o único que a maioria das pessoas considera: quanto você paga para guardar os dados, cobrado por GB ao mês.

O custo de armazenamento varia conforme a classe de storage. Dados em classe quente (Standard) custam mais por GB; dados em classes frias (Glacier, Deep Archive) custam bem menos. É o componente que o tiering busca otimizar, movendo dados frios para classes baratas. Para entender as classes, vale o conteúdo sobre classes de storage e tiering no S3.

O armazenamento é previsível e proporcional: mais dados, mais custo, de forma linear. É também, geralmente, o componente mais barato por unidade. O problema é que muita gente para de pensar aqui, esquecendo que o armazenamento é só o primeiro dos componentes. A conta real só fecha quando você soma os outros três.

Componente 2: requisições de API

Aqui começa a parte que pega muita gente de surpresa. Cada operação que você faz no object storage é uma requisição de API, e as requisições são cobradas.

O modelo típico da nuvem pública cobra por mil requisições, com preços diferentes por tipo de operação:

• Requisições de escrita e listagem (PUT, COPY, POST, LIST): mais caras por mil, porque envolvem mais processamento.
• Requisições de leitura (GET): mais baratas por mil, mas ainda cobradas.

Para a maioria das cargas, isso parece irrelevante: o que são alguns centavos por mil requisições? O problema aparece em escala. Uma aplicação que faz milhões de operações por dia (um site movimentado servindo objetos, um sistema que lista buckets constantemente, um pipeline que grava milhares de objetos pequenos) acumula um volume de requisições que pode pesar significativamente na fatura. Object storage cobrando por requisição penaliza padrões de acesso com muitas operações pequenas.

Componente 3: egress (transferência de saída)

Este é o grande vilão das faturas de nuvem, e merece atenção especial. Egress é o custo de transferir dados para fora da nuvem, ou seja, cada GB que sai do object storage em direção à internet ou a outra região.

No modelo da nuvem pública, você pode usar toda a banda que precisar, mas paga pelos dados que saem, com valores que podem chegar a cerca de US$ 0,09 por GB. A lógica do provedor é que mover dados exige infraestrutura e muitas vezes trafega por redes de terceiros, o que gera custo que é repassado.

O egress é traiçoeiro por três razões. Primeiro, é imprevisível: depende de quanto seus usuários baixam, o que você nem sempre controla. Segundo, escala com o sucesso: quanto mais sua aplicação é usada, mais dados saem, maior o custo. Terceiro, e mais grave, ele prende você: migrar para fora de um provedor significa mover (baixar) todos os seus dados, o que pode custar uma fortuna em egress, desincentivando a saída. O egress é, em muitos casos, o maior componente da fatura de object storage, e o que mais distorce o cálculo de quem só considerou o preço de armazenamento. Este tema é tão central que merece aprofundamento próprio: vale o conteúdo dedicado sobre tráfego de saída de dados (egress traffic) e como minimizar custos.

Componente 4: recuperação de classes frias

Se você usa classes frias de arquivamento (Glacier, Infrequent Access) para economizar no armazenamento, há um custo que entra em cena quando precisa dos dados de volta: a taxa de recuperação.

Classes frias cobram por GB recuperado, e algumas têm também tempo de espera. O raciocínio é o inverso do armazenamento: você economiza guardando barato, mas paga (em dinheiro e tempo) para acessar. Se subestimar a frequência de recuperação, a economia da classe fria pode virar prejuízo. Esse trade-off é detalhado no artigo sobre classes de storage, mas vale registrar aqui como componente da fatura: recuperação não é grátis quando os dados estão em arquivamento.

Some-se a isso as taxas extras: monitoramento do Intelligent-Tiering (cobrado por objeto monitorado), custo de transição entre classes via lifecycle, e period mínimo de armazenamento das classes frias (apagar antes do prazo cobra a diferença). São valores menores individualmente, mas que somam.

Onde a fatura realmente cresce

Juntando os componentes, fica claro o padrão: a surpresa nas faturas de object storage quase nunca vem do armazenamento. Vem das requisições e, principalmente, do egress.

Pense em dois cenários com o mesmo volume de dados armazenado:

Cenário A (arquivo morto): 10 TB de backups que ficam guardados e quase nunca são acessados. Aqui, o armazenamento domina a conta, e o egress e as requisições são mínimos. A fatura é próxima do "preço de GB".

Cenário B (conteúdo servido): 10 TB de mídias servidas a usuários, com tráfego de saída intenso e milhões de requisições por dia. Aqui, o armazenamento é a menor parte: egress e requisições dominam, e a fatura pode ser várias vezes maior que a do Cenário A, com o mesmo volume armazenado.

Essa é a lição central: o custo de object storage depende muito mais do padrão de uso (quanto sai, quantas operações) do que do volume armazenado. Estimar custo só pelo preço de GB é o erro que gera as faturas surpresa. Para o contexto mais amplo de desperdício, vale o conteúdo sobre o custo da nuvem não planejada.

O modelo de custo do Object Storage S3 da EVEO

O Object Storage S3 da EVEO foi desenhado para atacar exatamente as fontes de imprevisibilidade da fatura de object storage. Em vez de cinco componentes variáveis, o modelo é simples e transparente:

• Preço único de R$ 0,05 por GB: o armazenamento tem um valor único, sem variação por classe, sem complexidade de tiering.
• Sem egress fee: a transferência de saída é gratuita. A EVEO sustenta isso com um backbone robusto e banda flat, sem repassar o custo de saída ao cliente. O maior vilão da fatura simplesmente não existe.
• Sem cobrança por API: as operações PUT, COPY, POST e GET não têm custo adicional. O volume de requisições não pesa na conta.
• Sem taxa de recuperação: como não há classes frias com pedágio de acesso, recuperar dados não gera custo extra.
• Soberania e suporte: data centers Tier III no Brasil (Cotia/SP, Osasco/SP, Curitiba/PR, Fortaleza/CE) mais Miami/FL, fatura em reais e suporte em português 24/7.

O resultado é uma fatura que você consegue prever com precisão: volume armazenado vezes R$ 0,05 por GB, ponto. Sem surpresa de egress, sem susto de requisições. Para empresas que armazenam grandes volumes e servem muito tráfego, essa previsibilidade, combinada à ausência de egress fee, pode representar economia de até 80% em relação à nuvem global, além de eliminar a volatilidade do dólar.

No fim, entender o custo de object storage é entender que a fatura tem múltiplos componentes, e que o armazenamento por GB é o menor e mais previsível deles. As surpresas moram nas requisições e no egress, que crescem com o uso e escapam ao controle. Quem estima custo considerando todos os componentes evita o susto; quem escolhe um modelo que elimina os componentes voláteis troca a imprevisibilidade por uma conta simples e fechada.

Perguntas frequentes sobre custos de S3

Como é composta a fatura de object storage S3?

A fatura é a soma de vários componentes: armazenamento (por GB ao mês, variando por classe), requisições de API (operações como PUT, COPY, POST e LIST por mil requisições; GET mais barato), transferência de saída ou egress (por GB que sai para a internet, podendo chegar a US$ 0,09 por GB), recuperação de classes frias (por GB recuperado de Glacier ou IA) e taxas extras. O preço de armazenamento anunciado é só uma parte da conta.

Por que minha fatura de S3 veio maior que o esperado?

Na maioria dos casos, porque você considerou apenas o custo de armazenamento, mas a fatura cresceu por causa das requisições e, principalmente, do egress. Aplicações com muito tráfego de saída ou muitas operações por segundo acumulam custos que não aparecem na conta simples de GB. A surpresa quase nunca vem do armazenamento base, e sim desses componentes que escalam com o uso.

O que é egress fee no object storage?

Egress fee é a taxa cobrada por transferir dados para fora da nuvem, ou seja, cada GB que sai do storage em direção à internet ou a outra região. Pode chegar a cerca de US$ 0,09 por GB na nuvem pública. É um dos maiores componentes da fatura de object storage, é imprevisível (depende de quanto os usuários baixam) e dificulta a migração para fora, já que mover os dados gera custo de egress. Alguns provedores não cobram egress.

Por que muitos objetos pequenos custam mais?

Porque as requisições são cobradas por operação, não por volume. Gravar e ler um milhão de objetos de 1 KB gera um milhão de requisições, custando muito mais que armazenar o mesmo volume em poucos objetos grandes, mesmo com o total em GB idêntico. Quando há custo por requisição, agrupar dados em objetos maiores reduz o número de operações e, portanto, o custo. É uma otimização que não aparece na conta de armazenamento.

Como tornar o custo de object storage previsível?

A previsibilidade aumenta ao eliminar os componentes voláteis da fatura: egress e requisições. Modelos de preço único, sem egress fee e sem cobrança por API, reduzem a conta ao componente previsível e linear (armazenamento por GB). Assim, o custo passa a ser simplesmente o volume armazenado vezes o preço por GB, sem surpresa de tráfego de saída ou de número de operações, o que facilita o planejamento financeiro.