AWS para Iniciantes: Armazenamento essencial para o site (EBS e noções de S3)

EBS: o “disco” da sua instância EC2

Quando você cria uma instância EC2 para hospedar um site, ela precisa de um armazenamento em disco para o sistema operacional, arquivos do servidor web (ex.: Nginx/Apache), configurações e, às vezes, conteúdo do site. Na AWS, esse disco mais comum é o Amazon EBS (Elastic Block Store).

EBS é armazenamento em blocos: pense como um HD/SSD conectado à instância. Você cria um volume EBS e ele é anexado à EC2. O sistema operacional enxerga como um disco, você particiona/formata (quando necessário) e grava arquivos normalmente.

Persistência de dados vs. ciclo de vida da instância

Um ponto essencial para evitar perda de dados é entender o que “vive” e o que “morre” quando a instância muda de estado:

• Instância EC2: pode ser parada, iniciada, reiniciada ou até encerrada (terminada). O ciclo de vida dela é independente do volume EBS, mas existe uma configuração importante que pode apagar o volume ao terminar a instância.
• Volume EBS: é um recurso separado. Em geral, continua existindo mesmo se você parar e iniciar a instância. Porém, ao terminar a instância, o volume raiz pode ser apagado automaticamente dependendo da opção Delete on termination.

Regra prática: para um site simples, é comum manter o sistema e configurações no volume raiz EBS. Se você tiver dados que não podem sumir (uploads, arquivos gerados, backups locais), considere um volume EBS separado ou, melhor ainda, armazenar isso em S3.

O que impacta custo no EBS (tamanho e snapshots)

Dois fatores costumam pegar iniciantes de surpresa:

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

• Tamanho do volume: no EBS, você paga principalmente pela capacidade provisionada (GB). Se você cria um volume de 100 GB e usa 10 GB, o custo é do provisionado (100 GB).
• Snapshots: snapshot é um “backup” do volume EBS armazenado no S3 (gerenciado pela AWS). Você paga pelo armazenamento do snapshot. Ele é incremental: o primeiro snapshot tende a ser maior; os seguintes guardam apenas mudanças, mas ao longo do tempo podem acumular bastante se você fizer muitos snapshots e nunca limpar.

Snapshots: para que servem e como ajudam na recuperação

Snapshots são úteis para:

• Recuperação rápida: se uma atualização quebrar o site, você pode criar um novo volume a partir de um snapshot anterior e anexar em outra instância (ou substituir o volume).
• Clonagem: criar um volume “igual” para testar mudanças sem mexer no original.

Boa prática simples: antes de mudanças importantes (atualização do servidor web, troca de configuração crítica), crie um snapshot do volume. Depois, mantenha apenas os snapshots necessários (por exemplo, os últimos 3 ou 5), evitando acúmulo.

Checklist rápido: EBS com segurança e previsibilidade

• Verifique se o volume raiz está com Delete on termination conforme sua necessidade (para ambientes de teste pode ser ok; para algo mais persistente, avalie com cuidado).
• Não superdimensione o volume: comece menor e aumente quando necessário (aumentar é mais comum do que reduzir).
• Use snapshots antes de mudanças críticas e faça “limpeza” periódica dos antigos.

S3: armazenamento de objetos (ideal para arquivos do site, backups e logs)

O Amazon S3 (Simple Storage Service) é um armazenamento de objetos. Em vez de “discos” e partições, você trabalha com:

• Bucket: o “container” (como uma pasta raiz).
• Objetos: arquivos (cada objeto tem uma chave/nome, ex.: assets/logo.png).

Para sites, o S3 é muito usado para:

• Assets estáticos: imagens, CSS, JavaScript, PDFs, downloads.
• Backups: exportações do site, dumps de banco (se houver), cópias de configurações.
• Logs: guardar logs do servidor (após coletar/compactar) para auditoria e troubleshooting.

Diferença essencial: EBS vs S3

Cuidado crítico: exposição pública no S3

Um erro comum é deixar um bucket público sem querer. Para uso seguro:

• Mantenha Block Public Access habilitado.
• Evite políticas de bucket que liberem s3:GetObject para * (todo mundo).
• Se precisar compartilhar um arquivo, prefira métodos controlados (por exemplo, download autenticado). Neste capítulo, vamos manter o foco em uso privado e seguro.

Exercício prático: criar um bucket seguro e enviar/baixar um arquivo

Objetivo: criar um bucket S3 para guardar arquivos do site (assets) ou backups, garantindo que ele não fique público, enviar um arquivo e depois baixar para validar.

1) Criar o bucket

1. Acesse o Console da AWS e vá em S3.
2. Clique em Create bucket.
3. Em Bucket name, escolha um nome único globalmente, por exemplo: meu-site-iniciante-backup-12345.
4. Em AWS Region, escolha a mesma região onde você está trabalhando (para manter organização e evitar confusão).
5. Em Block Public Access settings for this bucket, mantenha todas as opções marcadas (recomendado).
6. Deixe o restante no padrão e clique em Create bucket.

Validação rápida: ao abrir o bucket recém-criado, você deve ver um aviso/indicador de que o acesso público está bloqueado.

2) (Reforço) Conferir o bloqueio de acesso público

1. Abra o bucket.
2. Vá em Permissions.
3. Em Block public access (bucket settings), confirme que está como On e com as opções de bloqueio habilitadas.

Isso reduz muito o risco de exposição acidental.

3) Enviar (upload) um arquivo

1. Dentro do bucket, vá em Objects.
2. Clique em Upload > Add files.
3. Escolha um arquivo simples para teste, por exemplo backup-teste.txt com algum conteúdo (ex.: “backup 2026-01-25”).
4. Clique em Upload.

Após o upload, o objeto deve aparecer na lista.

4) Baixar (download) e validar

1. Na lista de objetos, selecione o arquivo enviado (ex.: backup-teste.txt).
2. Clique em Download.
3. Abra o arquivo baixado no seu computador e confirme que o conteúdo está correto.

Validação adicional (permissões): ao clicar no objeto e olhar a aba Permissions, você não deve ver acesso público liberado. Se aparecer algo como “Publicly accessible”, pare e revise o bloqueio de acesso público e permissões.

Erros comuns e como evitar

• “Access Denied” ao tentar acessar por link: isso é esperado quando o bucket é privado. Para este exercício, use o botão Download no console (com seu usuário logado) para validar.
• Desmarcar Block Public Access “só para testar”: evite. É assim que buckets acabam expostos. Mantenha bloqueado e trabalhe sempre com acesso autenticado.
• Guardar dados sensíveis sem controle: trate backups como dados críticos. Mesmo em bucket privado, mantenha organização (prefixos/pastas) e acesso restrito apenas a quem precisa.

Aplicando no seu site: um fluxo simples e seguro

• EBS: mantém o sistema e o servidor web da EC2. Use snapshots antes de mudanças importantes e não exagere no tamanho do volume.
• S3: guarde assets e backups do site. Mantenha o bucket privado com Block Public Access ligado.
• Separação de responsabilidades: se a instância falhar ou precisar ser recriada, seus arquivos importantes podem estar no S3, reduzindo risco e acelerando recuperação.