S3 Profundo: Classes, Lifecycle e Object Lock
- ⬜🎓 SAA-C03: Da Teoria à Arquitetura Real(AWS Solutions Architect Associate)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
S3 é o serviço mais antigo da AWS (2006) e, provavelmente, o mais cobrado no SAA-C03. Não é só “um bucket onde jogo arquivo”: é object store com 8 storage classes, lifecycle transitions, replicação cross-region/cross-account, WORM para compliance, 4 modos de criptografia e performance tuning. Saber escolher a classe certa pode reduzir o custo em 80% — e cair em pegadinha de classe errada é quase garantido na prova.
Modelo mental: S3 é object store, não file system
Cada objeto é um blob imutável com key (caminho completo tipo fotos/2026/abril/ana.jpg), metadados e tags. O “/” no nome é só visual — S3 não tem pastas reais, só prefixos. Você não edita objeto; você sobrescreve. E se Versioning estiver ligado, cada sobrescrita cria uma nova versão.
As 8 storage classes — a pegadinha mais comum do SAA
Decorar classes não é suficiente — você precisa saber quando cada uma ganha. Os vetores de decisão são: (1) frequência de acesso, (2) latência tolerada, (3) duração mínima cobrada, (4) custo de retrieval, (5) durabilidade multi-AZ ou single-AZ.
| Classe | Casos de uso | Latência | Mínimo cobrado | Custo armazenamento* |
|---|---|---|---|---|
| S3 Standard | Dados quentes, aplicações, conteúdo web | ms | Nenhum | $$$$ (0,023/GB) |
| S3 Intelligent-Tiering | Padrão de acesso desconhecido/mutável | ms | 30 dias | $$$ + $0,0025/1k obj monitor |
| S3 Standard-IA | Backups, DR secundário, acesso mensal | ms | 30 dias + 128KB | $$ (0,0125/GB) |
| S3 One Zone-IA | Réplica secundária de dados já replicados | ms | 30 dias + 128KB | $ (0,01/GB) — 1 AZ só |
| S3 Glacier Instant Retrieval | Imagens médicas, mídia acessada 1x/trimestre | ms | 90 dias + 128KB | $ (0,004/GB) |
| S3 Glacier Flexible Retrieval | Arquivamento, compliance com acesso mensal | 1min–12h | 90 dias + 40KB | $ (0,0036/GB) |
| S3 Glacier Deep Archive | Arquivamento long-term 7–10 anos | 12h ou 48h | 180 dias + 40KB | ¢ (0,00099/GB) |
| S3 Express One Zone | ML training, analytics high-IOPS single-AZ | sub-ms | Nenhum | $$$$$ — 10× mais rápido |
* Preços us-east-1 referência abril/2026, podem variar. Foco no ordenamento relativo, não no número absoluto.
Intelligent-Tiering: quando o padrão é imprevisível
Esta classe monitora acessos por objeto e move automaticamente entre tiers. Cobra um pequeno fee de monitoramento ($0,0025 por 1.000 objetos), mas elimina o risco de pagar Standard para dados frios. Tiers internos:
Lifecycle policies — automatize a redução de custo
Regras de lifecycle aplicam transições e expirações a objetos baseados em idade, tags ou prefixo. Você não paga pela transição de forma gratuita — cada transição entre classes tem um custo por 1.000 requisições (além do mínimo de dias da classe de destino). Por isso, transitions sem critério podem aumentar custo.
- → transição · 30d
- → quando o padrão é imprevisível
- → transição · 90d
- → transição · 90d
- → transição · 365d
- → versões acumulam custo
- → trava a exclusão
- Armazenamento
- Gestão e governança
A questão típica dá três informações: com que frequência o dado é acessado, em quanto tempo precisa estar disponível quando pedirem, e por quanto tempo precisa ser guardado. Essas três escolhem a classe — o preço é consequência, não critério.
- A regra é o padrão de acesso, não a idade. Lifecycle usa idade porque é o proxy fácil, mas a decisão real é frequência de acesso e tolerância de latência para recuperar. Objeto acessado uma vez por trimestre em Standard é dinheiro jogado fora.
- Intelligent-Tiering quando você não sabe. Ele monitora e move automaticamente, cobrando uma taxa pequena de monitoramento por objeto. É a resposta certa sempre que o enunciado disser "padrão de acesso imprevisível" ou "não sabemos qual dado será acessado".
- Os três Glacier são diferentes. Instant Retrieval recupera em milissegundos; Flexible leva minutos a horas; Deep Archive leva até 12h e é o mais barato. A questão sempre dá o tempo tolerado de recuperação — é ele que escolhe, não o preço.
- Cuidado com o mínimo de permanência. Standard-IA cobra mínimo de 30 dias, Glacier IR 90, Deep Archive 180. Mover objeto de vida curta para classe fria pode custar MAIS que deixá-lo em Standard — pegadinha frequente.
- Versioning multiplica a conta em silêncio. Com versioning ligado, cada sobrescrita cria uma versão que continua sendo cobrada. A regra de lifecycle precisa tratar versões não-atuais explicitamente. E Object Lock em modo compliance impede exclusão até por root — é o que atende exigência regulatória de WORM.
{
"Rules": [{
"ID": "arquivar-logs-antigos",
"Status": "Enabled",
"Filter": { "Prefix": "logs/" },
"Transitions": [
{ "Days": 30, "StorageClass": "STANDARD_IA" },
{ "Days": 90, "StorageClass": "GLACIER_IR" },
{ "Days": 365, "StorageClass": "DEEP_ARCHIVE" }
],
"Expiration": { "Days": 2555 },
"NoncurrentVersionExpiration": { "NoncurrentDays": 30 }
}]
}Pegadinha: você não pode pular direto de Standard para Glacier Flexible e depois voltar para IA — transitions são sempre “descendo” na hierarquia de custo. Também não faz sentido transitar para uma classe mais cara (e a API rejeita).
Versioning e Object Lock — duas camadas diferentes de proteção
| Recurso | Versioning | Object Lock |
|---|---|---|
| Objetivo | Recuperar sobrescrita/delete acidental | Compliance WORM, ninguém deleta |
| Delete | Cria delete marker; versão anterior acessível | Bloqueia delete até retention expirar |
| MFA Delete | Exige MFA para remover versão ou desligar | N/A |
| Pré-requisito | Opcional | Versioning obrigatório; bucket criado com Object Lock ON |
| Modos | N/A | Governance (admin pode override) ou Compliance (ninguém, nem root) |
| Holds | N/A | Legal Hold (indefinido) + Retention period |
| Uso típico | Qualquer bucket com dados importantes | SEC 17a-4, HIPAA, logs imutáveis |
Replication — CRR e SRR em profundidade
| Tipo | Descrição | Caso de uso |
|---|---|---|
| SRR (Same-Region) | Réplica no mesmo região, bucket diferente | Agregar logs de múltiplas contas em um bucket central |
| CRR (Cross-Region) | Réplica em outra região | DR, baixa latência de leitura em múltiplas geografias, compliance de localização de dados |
📋 Preciso atender compliance que exige cópia imutável em outra região + storage barato para DR
Cross-region cobre requisito geográfico; Object Lock garante imutabilidade; Glacier IR mantém leitura ms para recuperação rápida sem custo de Standard.
Alt: CRR + Standard-IA — mais barato que Standard mas sem imutabilidade garantida.
Alt: AWS Backup — abstração mais alta, mas menos controle sobre classes.
Criptografia — 4 modos com diferenças sutis
| Modo | Quem tem a chave | Quem criptografa | Auditoria |
|---|---|---|---|
| SSE-S3 (AES-256) | AWS (chave gerenciada por S3) | S3 server-side | Nenhuma visibilidade da chave |
| SSE-KMS | AWS KMS (CMK customer-managed ou aws-managed) | S3 server-side via KMS | CloudTrail loga cada Decrypt/Encrypt — controle granular |
| SSE-C (customer-provided) | Você envia a chave em cada request (header) | S3 server-side com sua chave | S3 não armazena a chave — você é responsável |
| CSE (Client-Side) | Você (S3 Encryption Client ou próprio) | Cliente antes do PUT | Objeto já chega criptografado em S3 |
Desde janeiro/2023: SSE-S3 é default para TODO bucket novo. Não existe mais objeto “em claro” em S3. Se você não especificar nada, AES-256 é aplicado. Para ter controle/auditoria via KMS, você precisa ativar SSE-KMS explicitamente.
SSE-KMS tem limite de TPS: cada GET/PUT em objeto SSE-KMS chama /. O limite default do KMS é 5.500–30.000 req/s dependendo da região — se você tem workload de altíssimo throughput em S3, ative S3 Bucket Keys (reduz chamadas KMS em ~99%) ou vá para SSE-S3.
# Subir com SSE-KMS usando CMK específica
aws s3 cp relatorio.pdf s3://meu-bucket/ \
--sse aws:kms \
--sse-kms-key-id arn:aws:kms:us-east-1:111111111111:key/abc-123
# Negar uploads sem SSE-KMS via bucket policy
# "Condition": { "StringNotEquals": { "s3:x-amz-server-side-encryption": "aws:kms" } }Documentos precisam ficar disponíveis para acesso imediato nos primeiros 30 dias, raramente depois disso, e por exigência legal precisam ser guardados 7 anos sem possibilidade de exclusão. Qual configuração?
Controle de acesso — as 4 camadas que somam (não substituem)
Performance — multipart, prefix parallelism e Transfer Acceleration
Padrão de alto throughput: prefixe a chave com um hash curto em vez de com data sequencial. Chave que começa por ano/mês/dia concentra a escrita num prefixo só; começar por três caracteres de hash do identificador espalha por vários prefixos e garante paralelismo horizontal no I/O interno do S3.
Eventos, inventário e observabilidade
Decisões arquiteturais típicas do SAA
📋 Website estático servido globalmente com latência baixa e HTTPS + domínio custom
S3 Static Website hosting sozinho não faz HTTPS com domínio custom. CloudFront resolve HTTPS, cache global, WAF opcional, e usa OAC para restringir o bucket a tráfego só via CF.
Alt: S3 Static Website direto — HTTP apenas, sem CDN. Não passa em exame moderno.
📋 Data lake com Parquet particionado — analistas rodam queries ad-hoc
Athena paga por TB escaneado. Parquet colunar + S3 Select reduzem scan. Intelligent-Tiering move partições frias sem quebrar queries.
Alt: Redshift — caro se queries são esporádicas; faz sentido em workload dedicado.
📋 Upload de 5TB on-prem para S3, link de 100 Mbps
5TB em 100Mbps = ~5 dias 24h contínuos. Snowball chega em 1 semana e transfere em horas. DataSync faz sentido se o link aguentar + agendamento incremental.
Alt: CLI com multipart + TA — viável para dezenas de GB, não TB sobre 100Mbps.
Armadilhas clássicas do exame
Standard-IA vs One Zone-IA: One Zone é single-AZ. Se a AZ for perdida, dados somem. Use SOMENTE para réplicas secundárias de dados já duráveis em outro lugar. Exame tenta te fazer escolher One Zone para “primário de backup” — é pegadinha, não passe.
Glacier ≠ S3 Glacier storage class: o exame ainda cita “S3 Glacier” como classe dentro de S3 (não o serviço standalone antigo). Glacier Flexible Retrieval = antigo “Glacier”. Glacier Instant Retrieval é classe nova com latência ms. Glacier Deep Archive é a mais barata com retrieval de horas.
Encryption in transit: S3 aceita HTTP e HTTPS por padrão. Para forçar HTTPS only, bucket policy com em Deny. Questões de compliance sempre esperam essa policy.
Bucket Names são globais: não pode ter dois buckets com o mesmo nome no mundo. Por isso não há namespace por conta. Exame pergunta sobre conflitos de nome quando alguém tenta recriar.
Q&A estilo exame
❓ A aplicação escreve 10.000 objetos/s em um único prefixo e está recebendo 503 SlowDown. Solução mais barata?
❓ Preciso que arquivos expirem automaticamente após 30 dias exceto os marcados com tag 'legal-hold'.
❓ Bucket privado tem public read via Block Public Access desligado e bucket policy allow *. Alguém consegue acessar?
Perguntas frequentes
❓ Como decidir a classe de armazenamento?
❓ Versionamento substitui backup?
❓ Para que serve o bloqueio de objeto?
Fixando
Um bucket com versionamento ativo teve o custo triplicado em seis meses, sem aumento no volume de dado novo. Qual é a causa mais provável?
Qual afirmação sobre mínimo de permanência das storage classes é correta?
Take-aways: (1) escolha de storage class = custo × latência × duração mínima; (2) Versioning + Object Lock + Replication são camadas independentes e combináveis; (3) SSE-KMS dá auditoria mas escala via Bucket Keys; (4) BPA é seu backstop; (5) multipart + prefix paralelism + Transfer Acceleration resolvem 95% dos casos de performance. Entenda esses cinco vetores e S3 deixa de ser pegadinha.
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…