Classes de Armazenamento S3 Explicadas: Escolhendo a Opção Certa para Custo

O Amazon Simple Storage Service (S3) é o armazenamento de objetos padrão para muitas cargas de trabalho da AWS porque escala bem e oferece várias classes de armazenamento para diferentes padrões de acesso. No entanto, nem todos os dados são acessados igualmente. Armazenar dados críticos de acesso frequente na mesma classe que dados de arquivamento de acesso infrequente pode levar a gastos significativos e desnecessários em nuvem. Entender as nuances entre as várias classes de armazenamento S3 é crucial para projetar uma arquitetura otimizada em custos.

Entendendo a Durabilidade e Disponibilidade do S3

Antes de mergulhar nas classes, é importante definir duas métricas principais para o S3:

Durabilidade: A probabilidade de que seus dados permaneçam intactos ao longo do tempo. O S3 é projetado para 99,999999999% (11 noves) de durabilidade em toda a infraestrutura usada para uma determinada classe.
Disponibilidade: A porcentagem de tempo que seus dados estão acessíveis para recuperação. Isso geralmente é medido anualmente (por exemplo, 99,9%).

Essas métricas variam ligeiramente dependendo da classe de armazenamento específica escolhida.

As Classes de Armazenamento S3 Principais: Uma Comparação Detalhada

A AWS oferece várias classes de armazenamento otimizadas para diferentes frequências de acesso e tolerância a tempo de inatividade. Aqui está uma visão detalhada das opções mais comuns.

1. S3 Standard

O S3 Standard é a classe de armazenamento padrão e de uso geral, mais adequada para dados acessados com frequência.

Caso de Uso: Dados ativos, distribuição de conteúdo, conteúdo gerado dinamicamente e aplicativos móveis/de jogos.
Durabilidade: 11 noves.
Disponibilidade: 99,99% (Alta disponibilidade).
Tempo de Recuperação: Milissegundos.
Precificação: Maior custo de armazenamento entre as camadas de acesso frequente, mas sem taxas de recuperação.

Melhor Prática: Use isso para dados que precisam de acesso imediato com latência mínima.

2. S3 Intelligent-Tiering (S3-IT)

O S3 Intelligent-Tiering é projetado para dados com padrões de acesso desconhecidos ou variáveis. Ele move automaticamente objetos entre duas ou mais camadas de acesso com base no uso, otimizando os custos de armazenamento sem sobrecarga operacional.

Caso de Uso: Data lakes, dados com padrões de acesso imprevisíveis ou quando você deseja garantir acesso imediato enquanto otimiza o custo ao longo do tempo.
Como Funciona: Ele monitora o acesso. Se um objeto não for acessado por 30 dias consecutivos, ele é movido para a camada de Acesso Infrequente (IA). Se acessado novamente, ele volta para a camada de Acesso Frequente.
Camadas Incluídas: Acesso Frequente, Acesso Infrequente, Acesso Instantâneo de Arquivo (opcional).
Fator de Custo: Inclui uma pequena taxa mensal de monitoramento e automação por objeto, além dos custos de armazenamento, que mudam com base na camada em que o objeto reside.

Dica Acionável: Se você não tem certeza de quantas vezes os dados serão acessados, o S3 Intelligent-Tiering geralmente oferece o melhor equilíbrio entre economia de custos e consistência de desempenho.

3. S3 One Zone-Infrequent Access (S3 One Zone-IA)

Esta classe é ideal para dados acessados com pouca frequência, mas que exigem recuperação rápida, semelhante ao S3 Standard-IA, mas com uma grande diferença na disponibilidade.

Caso de Uso: Backups secundários, dados recriáveis (por exemplo, dados que podem ser regenerados de uma fonte) ou armazenamento de dados que não são críticos para o negócio a ponto de justificar redundância multi-AZ.
Durabilidade: 11 noves.
Disponibilidade: 99,5% (Disponibilidade menor que o Standard).
Local de Armazenamento: Os dados são armazenados de forma redundante em uma única Zona de Disponibilidade (AZ) da AWS, ao contrário de outras classes que abrangem várias AZs.
Fator de Custo: Custo de armazenamento significativamente menor que o Standard, mas a recuperação de dados incorre em uma taxa.

⚠️ Aviso sobre One Zone-IA: Como os dados residem em apenas uma AZ, se essa AZ específica sofrer um evento catastrófico (por exemplo, uma grande falha de energia ou desastre natural), seus dados nesta camada podem ser perdidos. É por isso que é crucial apenas para dados não críticos e facilmente substituíveis.

4. Classes de Armazenamento S3 Glacier (Arquivamento)

As classes de armazenamento Glacier são otimizadas para arquivamento de longo prazo, onde tempos de recuperação de minutos a horas são aceitáveis.

S3 Glacier Instant Retrieval (S3 Glacier IR)

Isso preenche a lacuna entre o Acesso Infrequente e o arquivamento profundo.

Caso de Uso: Dados acessados uma vez por trimestre ou menos, mas que exigem recuperação em milissegundos quando necessário (por exemplo, imagens médicas, arquivos de mídia de notícias).
Tempo de Recuperação: Milissegundos (latência semelhante às classes IA).
Fator de Custo: Custo de armazenamento muito baixo, com taxas de recuperação.

S3 Glacier Flexible Retrieval (Anteriormente S3 Glacier)

Esta é uma opção de arquivamento de longo prazo quando a recuperação de minutos a horas é aceitável.

Caso de Uso: Arquivos de conformidade regulatória, dados de recuperação de desastres que raramente, ou nunca, são necessários.
Opções de Recuperação (e Latência):
- Acelerada: 1–5 minutos
- Padrão: 3–5 horas
- Em Massa: 5–12 horas
Fator de Custo: Custo de armazenamento extremamente baixo, mas as taxas de recuperação se aplicam e levam tempo.

S3 Glacier Deep Archive

A opção de armazenamento de custo mais baixo absoluto no AWS S3.

Caso de Uso: Dados que podem ser acessados apenas uma ou duas vezes por ano, normalmente para conformidade.
Opções de Recuperação (e Latência):
- Padrão: 12 horas
- Em Massa: 48 horas
Fator de Custo: Taxa de armazenamento mais baixa disponível, taxas de recuperação mais altas e janelas de recuperação mais longas exigidas.

Como Escolher: Um Framework de Decisão

Selecionar a classe certa depende de responder a três perguntas-chave sobre o ciclo de vida dos seus dados:

Pergunta	Consideração Principal	Caminho de Classe Recomendado
Com que frequência é acessado?	Frequência de Acesso	Frequente $\rightarrow$ Standard; Infrequente $\rightarrow$ IA ou Glacier
Qual é o tempo de inatividade/perda aceitável?	Durabilidade/Disponibilidade	Crítico $\rightarrow$ Standard/Intelligent-Tiering; Descartável $\rightarrow$ One Zone-IA
Com que rapidez devo recuperá-lo?	Requisito de Latência	Milissegundos $\rightarrow$ Standard/Intelligent-Tiering/Glacier IR; Horas $\rightarrow$ Glacier Flexible/Deep Archive

Exemplo de Cenário: Ativos de Mídia da Empresa

Uma equipe de marketing faz upload de centenas de arquivos de vídeo brutos diariamente:

Edições/promoções atuais (Últimos 30 dias): S3 Standard (Alto acesso, baixa latência).
Ativos mais antigos que precisam de revisão ocasional (30 dias a 1 ano): S3 Intelligent-Tiering (Para capturar economia de custos após o período inicial de alta atividade).
Masters finais concluídos e auditados (Mais de 1 ano): S3 Glacier Deep Archive (Menor custo, necessário apenas para auditorias de conformidade).

Exemplo de Cenário: Logs, Backups e Uploads de Usuários

Uma única empresa geralmente tem três padrões S3 muito diferentes.

Para logs de aplicação, dados recentes são valiosos porque os engenheiros os pesquisam durante incidentes. Após a janela de incidente passar, a maioria dos logs se torna dados de conformidade ou tendência. Um ciclo de vida razoável pode manter 30 a 90 dias em Standard ou Standard-IA, mover logs mais antigos para uma camada de arquivamento e expirar logs de depuração de baixo valor após um período de retenção fixo. Os números exatos devem vir da sua política de retenção e da frequência com que as pessoas realmente consultam prefixos antigos.

Para backups de banco de dados, a classe de armazenamento deve seguir a promessa de restauração. Se a equipe disser que uma restauração de produção deve começar em minutos, mantenha os backups mais recentes em uma classe com recuperação imediata. Cópias mensais ou anuais mais antigas podem ser movidas para camadas mais frias se estiverem lá para retenção de auditoria em vez de recuperação rápida. Teste as restaurações da classe escolhida; uma política de backup que nunca foi restaurada é principalmente uma regra de faturamento.

Para uploads de usuários, o acesso é mais difícil de prever. Uma foto de perfil pode ser pequena, mas buscada constantemente. Um vídeo original grande pode ser baixado uma vez, transcodificado e raramente tocado novamente. Armazene ativos derivados e originais sob prefixos separados para que as regras de ciclo de vida possam tratá-los de forma diferente. Não faça a política de miniaturas herdar a mesma regra de arquivamento que os originais de vários gigabytes, a menos que seja realmente o que o produto precisa.

Perguntas a fazer antes de alterar um bucket

Antes de adicionar uma regra de ciclo de vida, pergunte quem lê os dados, como eles os leem e o que acontece se a recuperação for atrasada. Os engenheiros geralmente conhecem melhor o caminho de gravação do que o caminho de leitura porque os uploads fazem parte do aplicativo, enquanto as leituras acontecem posteriormente por meio de análises, ferramentas de suporte, exportações de conformidade ou resposta manual a incidentes.

Procure por jobs em lote que examinam prefixos antigos. Um job noturno que lista todos os objetos, abre metadados ou amostra arquivos antigos pode eliminar parte da economia de uma classe mais fria. Se o job precisar apenas de um manifesto, o S3 Inventory pode ser melhor do que listar o bucket repetidamente. Se os analistas consultarem logs com Athena, considere o layout de partição e a compactação antes de mover dados para uma classe que exija etapas de restauração.

Preste atenção ao tamanho do objeto. Classes de armazenamento com tamanhos mínimos de objeto faturáveis podem ser inadequadas para grandes contagens de arquivos minúsculos. Nesses casos, compactar dados em objetos maiores, usar Parquet para análises ou expirar objetos desnecessários pode superar uma mudança de classe de armazenamento.

Finalmente, escreva regras de ciclo de vida de uma forma que você possa explicar durante um incidente. Uma regra de prefixo chamada arquivar-logs-antigos-apos-90-dias é mais fácil de raciocinar do que uma regra em todo o bucket que move silenciosamente tudo após 30 dias. A otimização de custos deve tornar o sistema mais barato sem tornar a recuperação misteriosa.

Mais uma verificação prática é a propriedade. Em contas reais, o proprietário do bucket, a conta de upload, a função de replicação e a conta de análise nem sempre são os mesmos. Antes de mover dados para uma classe de arquivamento, confirme quem pode restaurá-los e quem paga pela recuperação. Buckets entre contas com criptografia KMS podem falhar no momento da restauração se a função que precisa do objeto puder listar o bucket, mas não puder usar a chave. Essa é uma surpresa desagradável durante uma auditoria.

O versionamento também altera a matemática. As regras de ciclo de vida podem fazer a transição ou expirar versões atuais e não atuais de forma diferente. Se um aplicativo sobrescrever a mesma chave a cada hora, as versões não atuais podem se tornar a maior parte do bucket. Revise-as separadamente em vez de assumir que a contagem de objetos atual conta toda a história.

Implementando Políticas de Ciclo de Vida

Mover objetos manualmente entre classes é ineficiente. A maneira mais eficaz de gerenciar custos entre essas camadas é usando Políticas de Ciclo de Vida do S3.

As políticas de ciclo de vida permitem que você defina regras que fazem a transição automática de objetos para camadas de armazenamento mais frias ou os expiram permanentemente após um número definido de dias.

Exemplo de Regra de Ciclo de Vida (Transição):

<Rule>
    <ID>Mover_para_IA_Apos_30_Dias</ID>
    <Status>Habilitado</Status>
    <Filter>
        <Prefix>logs/</Prefix>
    </Filter>
    <Transition>
        <Days>30</Days>
        <StorageClass>GLACIER_IR</StorageClass>
    </Transition>
</Rule>

Esta configuração move automaticamente qualquer objeto no prefixo logs/ para o Glacier Instant Retrieval 30 dias após a criação, reduzindo significativamente os custos de armazenamento de longo prazo, mantendo capacidades de recuperação rápidas, se necessário.

Armadilhas de custo que as pessoas perdem

A decisão da classe de armazenamento não é apenas uma comparação mensal de GB. Encargos de recuperação, encargos de solicitação, duração mínima de armazenamento, tamanho mínimo de objeto faturável, replicação, solicitações de transição de ciclo de vida e taxas de monitoramento podem mudar a resposta. Um arquivo de objetos minúsculos com milhões de chaves pode se comportar de forma muito diferente de um pequeno número de grandes arquivos de backup.

Por exemplo, os logs de aplicação são frequentemente escritos uma vez e raramente lidos, então uma regra de ciclo de vida de Standard para Glacier Instant Retrieval ou Glacier Flexible Retrieval pode fazer sentido. Mas se o seu processo de incidente verifica frequentemente logs antigos com Athena, o arquivamento agressivo pode criar restaurações lentas e custos de recuperação surpresa. Nesse caso, particionar logs por data, expirar prefixos ruidosos de baixo valor e manter meses recentes em uma classe amigável para consultas pode economizar mais dinheiro do que mover cegamente tudo para o frio após 30 dias.

Os backups têm uma forma diferente. Um dump de banco de dados que você testa uma vez por mês precisa de um comportamento de restauração previsível. Se o seu objetivo de tempo de recuperação é medido em minutos, o Deep Archive é provavelmente o lugar errado para a única cópia restaurável, mesmo que seja barato em repouso. Se o mesmo dump for a terceira cópia mantida apenas para retenção de auditoria, o Deep Archive pode ser razoável.

As equipes de mídia geralmente precisam de ativos antigos de forma imprevisível. O Intelligent-Tiering pode ser um bom padrão para esses padrões desconhecidos, especialmente quando os objetos são grandes o suficiente para que a taxa de monitoramento não seja o fator decisivo. Para um grande número de miniaturas minúsculas, a taxa e o comportamento de tamanho mínimo do objeto merecem uma olhada mais de perto antes de ativá-lo em todos os lugares.

Uma maneira prática de escolher é amostrar um bucket, exportar o S3 Inventory, agrupar por prefixo, contagem de objetos, bytes totais, data da última modificação e padrão de acesso conhecido, depois escrever regras de ciclo de vida por prefixo. Evite uma regra para todo o bucket, a menos que o bucket realmente contenha um tipo de dado.