O Amazon Simple Storage Service (S3) é o serviço de armazenamento de objetos da AWS.
🎯 Para a certificação
Na SAA, o S3 aparece menos como uma pergunta sobre "o que é S3" e mais como parte de uma decisão arquitetural: qual combinação de armazenamento, segurança, acesso, durabilidade, performance e custo atende ao cenário apresentado?
Ele é usado quando precisamos armazenar e recuperar grandes volumes de dados sem administrar servidores ou discos diretamente.
Mais importante do que decorar suas funcionalidades é entender qual problema arquitetural o S3 resolve e como escolher entre suas diferentes opções.
Em uma frase: S3 é armazenamento de objetos altamente durável e escalável, organizado em buckets e objetos.
Resumo
Pense no S3 como um grande repositório de objetos.
Um objeto é identificado por uma key dentro de um bucket.
Bucket
│
├── documentos/contrato.pdf
├── imagens/logo.png
└── backups/2026/database.sql
A estrutura acima parece uma árvore de diretórios, mas o S3 não é um filesystem tradicional. documentos/contrato.pdf é a key do objeto.
O S3 é especialmente útil para:
- arquivos;
- imagens e vídeos;
- backups;
- logs;
- datasets;
- conteúdo estático;
- data lakes;
- objetos que precisam ser armazenados por longos períodos.
1. Como o S3 funciona
Os três conceitos fundamentais são:
| Conceito | O que representa |
|---|---|
| Bucket | Contêiner lógico dos objetos |
| Object | O dado armazenado |
| Key | Identificador do objeto dentro do bucket |
Podemos imaginar:
Bucket: leware-arquivos
Key: cursos/aws/s3/aula-01.pdf
Object:
conteúdo do arquivo
metadata
O endereço lógico do objeto é formado pelo bucket e pela key.
Importante
cursos/aws/s3/aula-01.pdf não significa que existem três diretórios.
É simplesmente a key do objeto.
2. S3 não é um filesystem
Essa distinção aparece muito em questões de arquitetura.
Em um filesystem tradicional:
diretório
└── subdiretório
└── arquivo
No S3:
bucket
├── key-a
├── key-b
└── key-c
Os / presentes nas keys são convenções de nomenclatura.
O console do S3 apresenta essas keys de uma maneira semelhante a diretórios, mas isso não transforma o S3 em um filesystem tradicional.
3. Durabilidade e disponibilidade
É importante não confundir:
- durabilidade: probabilidade de os dados não serem perdidos;
- disponibilidade: probabilidade de o serviço estar disponível para acesso.
S3 é projetado para altíssima durabilidade.
Isso não significa que devemos ignorar arquitetura de backup, versionamento ou requisitos de recuperação.
A decisão depende do tipo de dado e do impacto de uma perda.
4. Consistência
O S3 oferece strong read-after-write consistency para operações de objetos.
Isso significa que, após uma gravação bem-sucedida, leituras posteriores do objeto refletem a gravação.
Também existe consistência forte para alterações e exclusões de objetos.
Pegadinha de prova: material antigo pode afirmar que S3 possui consistência eventual para leitura de objetos. Essa descrição está desatualizada.
A documentação atual da AWS afirma que o S3 oferece consistência forte para PUT e DELETE de objetos.
5. Storage Classes
Uma das decisões mais importantes em S3 é escolher a classe de armazenamento adequada.
A escolha depende principalmente de:
- frequência de acesso;
- necessidade de recuperação rápida;
- duração do armazenamento;
- custo.
Principais classes
| Classe | Cenário típico |
|---|---|
| S3 Standard | Acesso frequente |
| S3 Intelligent-Tiering | Padrão de acesso desconhecido ou variável |
| S3 Standard-IA | Acesso infrequente, mas recuperação rápida |
| S3 One Zone-IA | Acesso infrequente e dados que podem ser recriados |
| S3 Glacier Instant Retrieval | Arquivo raramente acessado com recuperação imediata |
| S3 Glacier Flexible Retrieval | Arquivamento com recuperação que pode levar mais tempo |
| S3 Glacier Deep Archive | Arquivamento de longo prazo e menor custo de armazenamento |
Regra mental
Acesso frequente
↓
S3 Standard
Padrão desconhecido
↓
Intelligent-Tiering
Pouco acesso + recuperação rápida
↓
Standard-IA
Arquivo
↓
Glacier
A decisão correta depende sempre dos requisitos.
Não escolha uma classe apenas porque ela possui o menor preço de armazenamento.
6. Intelligent-Tiering
O S3 Intelligent-Tiering é útil quando o padrão de acesso aos objetos é desconhecido ou muda ao longo do tempo.
O S3 pode mover os objetos entre diferentes níveis de acesso para reduzir custos.
Cenário
Imagine uma empresa que armazena milhões de documentos.
Alguns são acessados frequentemente.
Outros deixam de ser acessados durante meses.
Se não sabemos antecipadamente quais objetos serão acessados, Intelligent-Tiering pode ser uma alternativa interessante.
Como pensar na prova: se o enunciado destaca padrão de acesso desconhecido ou imprevisível, pense em Intelligent-Tiering.
7. Lifecycle
O S3 Lifecycle permite automatizar a evolução dos objetos ao longo do tempo.
Por exemplo:
Upload
│
│ 30 dias
▼
Standard-IA
│
│ 90 dias
▼
Glacier
│
│ 365 dias
▼
Expiração
Uma política de Lifecycle pode definir:
- transição para outra storage class;
- expiração;
- exclusão de objetos;
- regras baseadas em prefixos ou tags.
Cenário clássico
Uma empresa armazena logs.
Os logs são muito acessados nos primeiros dias.
Depois praticamente não são consultados.
Uma política de Lifecycle pode reduzir automaticamente o custo conforme os dados envelhecem.
Palavra-chave de prova: "automaticamente mover objetos para uma classe mais barata conforme envelhecem".
8. Versioning
O S3 Versioning permite manter múltiplas versões de um mesmo objeto.
Sem versionamento:
documento.pdf
↓
novo upload
↓
versão anterior substituída
Com versionamento:
documento.pdf
│
├── versão 1
├── versão 2
└── versão 3
Isso é especialmente útil para proteção contra:
- sobrescrita acidental;
- exclusão acidental;
- alterações indesejadas.
Atenção
Versionamento não é backup completo por si só.
Ele ajuda a preservar versões dos objetos, mas a arquitetura de proteção de dados deve considerar os requisitos de recuperação.
9. Delete Marker
Quando o Versioning está habilitado, uma exclusão lógica pode resultar na criação de um delete marker.
Isso é importante porque a exclusão não significa necessariamente que todas as versões anteriores desapareceram.
Conceitualmente:
versão 1
versão 2
versão 3
delete marker
O delete marker passa a representar a exclusão corrente do objeto.
As versões anteriores podem continuar existindo.
10. Segurança
S3 é um dos serviços em que as questões de prova frequentemente misturam:
- IAM;
- bucket policy;
- Block Public Access;
- encryption;
- presigned URLs.
A primeira pergunta deve ser:
Quem precisa acessar o objeto e de que maneira?
10.1 IAM
IAM pode controlar quem possui permissão para realizar operações no S3.
Exemplo conceitual:
EC2
│
▼
IAM Role
│
▼
S3
A aplicação não precisa armazenar access keys no código.
Uma IAM Role pode conceder as permissões necessárias.
10.2 Bucket Policy
Uma bucket policy é uma política baseada em recurso.
Ela permite definir regras de acesso diretamente no bucket.
Pode ser usada para cenários como:
- permitir acesso de um determinado principal;
- restringir acesso;
- permitir acesso entre contas;
- controlar condições específicas.
10.3 Block Public Access
Quando um bucket não deve ser público, o S3 Block Public Access é uma importante camada de proteção.
Regra prática: se o cenário não exige acesso público, não torne o bucket público.
Questões de certificação frequentemente apresentam uma aplicação que precisa acessar S3 sem exigir que o bucket inteiro seja público.
Nesse caso, procure uma solução baseada em IAM, bucket policy ou presigned URL, dependendo do cenário.
11. Encryption
O S3 oferece criptografia no lado do servidor.
Atualmente, o S3 aplica SSE-S3 como nível base de criptografia para objetos novos.
Outras opções podem ser usadas quando requisitos específicos existem, incluindo:
- SSE-S3 — chaves gerenciadas pelo S3;
- SSE-KMS — integração com AWS KMS;
- SSE-C — chave fornecida pelo cliente, quando explicitamente habilitado.
SSE-S3
A AWS gerencia as chaves utilizadas para criptografar os objetos.
É uma solução simples quando não precisamos de controles específicos do KMS.
SSE-KMS
Utiliza o AWS KMS.
Pode ser escolhido quando precisamos de:
- controle adicional sobre chaves;
- políticas do KMS;
- integração com requisitos de auditoria;
- controle mais explícito sobre o ciclo de vida das chaves.
Como pensar na prova: se o requisito destaca integração com KMS ou controle de chaves, SSE-KMS costuma ser a opção relevante.
12. Presigned URLs
Uma presigned URL permite conceder acesso temporário a um objeto sem tornar o bucket público.
Exemplo:
Usuário
│
│ solicita download
▼
Aplicação
│
│ gera URL temporária
▼
Presigned URL
│
▼
S3
Isso é extremamente útil para aplicações web.
Exemplo
Uma aplicação possui documentos privados.
Não queremos:
S3 público
Também não queremos enviar o arquivo inteiro através do backend.
Podemos:
- autenticar o usuário;
- verificar sua autorização;
- gerar uma presigned URL;
- permitir que o cliente baixe diretamente do S3.
A URL possui validade limitada.
Palavra-chave: acesso temporário sem tornar o bucket público.
13. Upload direto para S3
O mesmo conceito pode ser usado para upload.
Browser
│
│ solicita autorização
▼
Backend
│
│ gera presigned URL
▼
Browser
│
│ upload direto
▼
S3
Isso reduz a carga sobre o backend.
Em vez de:
Browser → Backend → S3
podemos ter:
Browser → Backend
│
└── presigned URL
Browser ───────────────→ S3
Esse padrão aparece frequentemente em sistemas que recebem arquivos grandes.
14. Multipart Upload
Para objetos grandes, o S3 oferece Multipart Upload.
O arquivo pode ser dividido em partes:
arquivo
│
├── parte 1
├── parte 2
├── parte 3
└── parte 4
As partes podem ser carregadas separadamente.
Depois o S3 monta o objeto final.
Isso pode melhorar:
- desempenho;
- paralelismo;
- tolerância a falhas durante uploads grandes.
Se uma parte falhar, não é necessário necessariamente reenviar o objeto inteiro.
15. Static Website Hosting
S3 pode ser usado para hospedar conteúdo estático.
Exemplos:
- HTML;
- CSS;
- JavaScript;
- imagens.
Arquiteturas tradicionais podem utilizar:
Usuário
│
▼
CloudFront
│
▼
S3
CloudFront pode fornecer:
- distribuição global;
- cache;
- menor latência;
- integração com HTTPS.
Cuidado: "S3 hospeda site estático" não significa que S3 seja a melhor opção para qualquer aplicação web. Para uma aplicação com backend dinâmico, precisamos de outros componentes.
16. S3 + CloudFront
Um padrão arquitetural muito comum é:
┌──────────────┐
│ Usuário │
└──────┬───────┘
│
▼
┌──────────────┐
│ CloudFront │
└──────┬───────┘
│
▼
┌──────────────┐
│ S3 │
└──────────────┘
O CloudFront atua como CDN.
O S3 permanece como origem dos objetos.
Esse padrão é útil para conteúdo estático distribuído globalmente.
17. Storage Class x Lifecycle
Esses conceitos são frequentemente confundidos.
Storage Class
Define como o objeto é armazenado.
Lifecycle
Define quando uma ação deve acontecer com o objeto.
Exemplo:
Storage Class:
S3 Standard
e:
Lifecycle:
depois de 30 dias → Standard-IA
depois de 90 dias → Glacier
São conceitos diferentes, mas complementares.
18. Como escolher uma solução
Quando uma questão apresentar S3, procure primeiro o requisito.
| Requisito | Solução a considerar |
|---|---|
| Acesso frequente | S3 Standard |
| Acesso imprevisível | Intelligent-Tiering |
| Acesso infrequente + recuperação rápida | Standard-IA |
| Arquivamento | Glacier |
| Mover objetos automaticamente | Lifecycle |
| Recuperar versões anteriores | Versioning |
| Acesso temporário privado | Presigned URL |
| Criptografia com controle via KMS | SSE-KMS |
| Upload/download de arquivos grandes | Multipart Upload |
| Conteúdo estático global | S3 + CloudFront |
| Acesso de aplicação AWS | IAM Role |
19. Como Cai na Certificação
O S3 pode aparecer em diferentes domínios do SAA-C03 porque armazenamento participa de decisões de:
- segurança;
- resiliência;
- performance;
- custo.
O guia atual do exame organiza o conteúdo em quatro domínios:
- Design de arquiteturas seguras — 30%
- Design de arquiteturas resilientes — 26%
- Design de arquiteturas de alto desempenho — 24%
- Design de arquiteturas com custo otimizado — 20%
Storage aparece explicitamente entre as tecnologias e conceitos relevantes do exame.
Isso significa que estudar S3 não deve ser tratado como decorar uma lista de features.
A prova tende a avaliar decisão arquitetural.
20. Pegadinhas importantes
"Precisamos de acesso temporário a um objeto privado."
Não torne o bucket público.
Pense em:
Presigned URL.
"O padrão de acesso aos objetos é desconhecido."
Pense em:
S3 Intelligent-Tiering.
"Objetos antigos devem ficar mais baratos automaticamente."
Pense em:
S3 Lifecycle + Storage Classes.
"A aplicação precisa acessar S3."
Não coloque access keys no código.
Pense em:
IAM Role.
"Precisamos recuperar versões anteriores."
Pense em:
S3 Versioning.
"Precisamos de controle de chaves através do KMS."
Pense em:
SSE-KMS.
"O site possui conteúdo estático distribuído globalmente."
Pense em:
S3 + CloudFront.
21. Cenário Prático
Imagine uma aplicação que recebe documentos de clientes.
Os requisitos são:
- os documentos são privados;
- o backend autentica os usuários;
- alguns documentos são grandes;
- o usuário deve conseguir fazer upload diretamente;
- documentos antigos raramente são acessados;
- documentos precisam permanecer disponíveis para recuperação.
Uma arquitetura possível:
┌─────────────┐
│ Usuário │
└──────┬──────┘
│
▼
┌─────────────┐
│ Backend │
└──────┬──────┘
│
Presigned URL
│
▼
┌─────────────┐
│ S3 │
│ │
│ Versioning │
│ Lifecycle │
└─────────────┘
Para arquivos grandes, o upload pode utilizar Multipart Upload.
Para reduzir custos conforme os objetos envelhecem, Lifecycle pode movê-los para classes mais econômicas.
A aplicação não precisa transportar o conteúdo inteiro do arquivo pelo backend.
22. Laboratório Prático
Atenção: recursos da AWS podem gerar cobrança. Antes de executar qualquer laboratório, verifique os preços atuais e o Free Tier disponível para sua conta.
Objetivo
Criar um bucket S3, armazenar um objeto, habilitar versionamento e observar o comportamento das versões.
Pré-requisitos
- conta AWS;
- acesso ao console da AWS;
- região definida;
- atenção aos custos.
Passos
1. Criar um bucket
No console da AWS:
S3 → Create bucket
Escolha um nome globalmente único.
Mantenha o bloqueio de acesso público habilitado.
2. Enviar um arquivo
Crie um pequeno arquivo local, por exemplo:
s3-lab.txt
Faça upload para o bucket.
3. Habilitar Versioning
Abra as propriedades do bucket e habilite:
Bucket Versioning → Enable
4. Alterar o arquivo
Modifique o conteúdo de s3-lab.txt.
Faça upload novamente usando a mesma key.
5. Observar as versões
Verifique o objeto no console e habilite a visualização das versões.
Você deverá conseguir observar que o S3 mantém versões diferentes do objeto.
Resultado esperado
O mesmo objeto terá mais de uma versão armazenada.
Isso demonstra na prática que Versioning protege contra determinadas sobrescritas e exclusões acidentais.
Limpeza
Ao terminar:
- remova os objetos;
- remova todas as versões;
- remova delete markers, se existirem;
- exclua o bucket.
Não deixe recursos desnecessários ativos.