Lab: Gerenciamento de Armazenamento EBS
Objetivo do Lab
Neste lab, você vai aprender a gerenciar o armazenamento EBS: criação de volumes, anexação a instâncias, snapshots e boas práticas de gestão. É um exercício de análise e documentação.
Abordagem Pedagógica
Este lab combina teoria e análise de cenários. Você irá documentar suas respostas e justificativas.
Parte 1: Conceitos Fundamentais
Revisão dos Tipos de Volumes EBS
┌─────────────────────────────────────────────────────────────┐
│ TIPOS DE VOLUMES EBS │
├─────────────────────────────────────────────────────────────┤
│ │
│ TIPO │ USO │ IOPS │ CUSTO │
│ ────────────┼────────────────────┼───────────┼───────────│
│ gp3 │ Uso geral │ 3.000-16K │ $0.08/GB │
│ gp2 │ Uso geral │ 3.000 máx │ $0.10/GB │
│ io2 │ I/O intensivo │ 64.000 │ $0.125/GB │
│ st1 │ Big data, logs │ 500 │ $0.045/GB │
│ sc1 │ Arquivos frios │ 250 │ $0.025/GB │
│ │
│ Recomendação para iniciantes: │
│ • gp3 para todo uso geral │
│ • st1 para logs/dados sequenciais │
│ │
└─────────────────────────────────────────────────────────────┘
Exercício 1.1: Escolha do Tipo de Volume
Para cada cenário, escolha o tipo de volume EBS apropriado e justifique:
| Cenário | Sua Escolha | Justificativa |
|---|---|---|
| Banco de dados MySQL produção | ? | ? |
| Logs de aplicação (100GB) | ? | ? |
| Servidor web estático | ? | ? |
| Aplicação de trading de alta frequência | ? | ? |
| Arquivos de documentos (acesso raro) | ? | ? |
💡 Soluções
| Cenário | Escolha | Justificativa |
|---|---|---|
| Banco de dados MySQL produção | io2 | Necessário IOPS alto e consistente |
| Logs de aplicação (100GB) | st1 | Acesso sequencial, custo otimizado |
| Servidor web estático | gp3 | Bom equilíbrio custo/desempenho |
| Aplicação de trading | io2 | Latência mínima é crítica |
| Arquivos de documentos | sc1 | Acesso raro, custo mínimo |
Parte 2: Ciclo de Vida de um Volume EBS
Diagrama do Ciclo de Vida
┌─────────────────────────────────────────────────────────────┐
│ CICLO DE VIDA DE UM VOLUME EBS │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────┐ │
│ │ Criar │ │
│ │ Volume │ │
│ └──────┬──────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ Estado: │ │ Anexar │ │
│ │ available │───────►│ à EC2 │ │
│ └─────────────┘ └──────┬──────┘ │
│ ▲ │ │
│ │ ▼ │
│ ┌──────┴──────┐ ┌─────────────┐ │
│ │ Desanexar │◄───────│ Estado: │ │
│ │ de EC2 │ │ in-use │ │
│ └─────────────┘ └──────┬──────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ Snapshot │ │
│ │ (backup) │ │
│ └─────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ Excluir │ │
│ │ Volume │ │
│ └─────────────┘ │
│ │
│ ⚠️ Atenção: Excluir um volume apaga todos os dados! │
│ Sempre faça um snapshot antes. │
│ │
└─────────────────────────────────────────────────────────────┘
Exercício 2.1: Comandos CLI
Associe cada ação ao comando CLI correto:
| Ação | Comando |
|---|---|
| Criar um volume de 100GB | ? |
| Listar todos os volumes | ? |
| Anexar um volume a uma instância | ? |
| Criar um snapshot | ? |
| Desanexar um volume | ? |
💡 Soluções
# Criar um volume de 100GB
aws ec2 create-volume \
--size 100 \
--volume-type gp3 \
--availability-zone us-east-1a
# Listar todos os volumes
aws ec2 describe-volumes
# Anexar um volume a uma instância
aws ec2 attach-volume \
--volume-id vol-xxx \
--instance-id i-xxx \
--device /dev/sdf
# Criar um snapshot
aws ec2 create-snapshot \
--volume-id vol-xxx \
--description "Backup before maintenance"
# Desanexar um volume
aws ec2 detach-volume --volume-id vol-xxx
Parte 3: Cenários Práticos
Cenário A: Aumento de Capacidade
Contexto: O volume root do seu servidor de banco de dados (20GB) está quase cheio (95%). Você precisa aumentar a capacidade para 50GB sem downtime.
Perguntas:
- Qual método você usaria?
- Quais são os passos?
- Existe risco de perda de dados?
💡 Solução Cenário A
Método: Modificação do volume (EBS Elastic Volumes)
A AWS permite modificar o tamanho de um volume EBS a quente (sem parar a instância)!
Passos:
- Criar um snapshot (precaução)
aws ec2 create-snapshot --volume-id vol-xxx --description "Before resize"
- Modificar o tamanho do volume
aws ec2 modify-volume --volume-id vol-xxx --size 50
- Monitorar a modificação
aws ec2 describe-volumes-modifications --volume-id vol-xxx
# Esperar até o estado ser "completed"
- Expandir o sistema de arquivos (na instância)
# Para ext4
sudo resize2fs /dev/xvda1
# Para XFS
sudo xfs_growfs /
Riscos:
- Mínimo se o snapshot for feito antes
- O volume permanece acessível durante a modificação
- A expansão do filesystem é instantânea
Cenário B: Migração de Dados
Contexto: Você precisa migrar um banco de dados MySQL de uma instância EC2 (us-east-1a) para outra instância em uma AZ diferente (us-east-1b).
Perguntas:
- Você pode simplesmente desanexar e reanexar o volume?
- Qual é o procedimento correto?
- Como minimizar o downtime?
💡 Solução Cenário B
Resposta 1: NÃO! Um volume EBS só pode ser anexado a instâncias na mesma AZ.
Procedimento correto:
- Parar o MySQL corretamente (minimizar dados em trânsito)
sudo systemctl stop mysql
- Criar um snapshot do volume
aws ec2 create-snapshot --volume-id vol-xxx --description "Migration"
- Criar um novo volume a partir do snapshot na nova AZ
aws ec2 create-volume \
--snapshot-id snap-xxx \
--availability-zone us-east-1b \
--volume-type gp3
- Anexar o novo volume à nova instância
aws ec2 attach-volume \
--volume-id vol-new \
--instance-id i-new \
--device /dev/sdf
- Montar e iniciar o MySQL
sudo mount /dev/sdf /var/lib/mysql
sudo systemctl start mysql
Minimizar o downtime:
- Preparar a nova instância com antecedência
- Utilizar replicação MySQL antes da migração
- Realizar a migração durante uma janela de manutenção
Cenário C: Recuperação após Incidente
Contexto: Um desenvolvedor acidentalmente excluiu arquivos importantes em um volume. O volume tem 200GB e o último backup é de ontem.
Perguntas:
- Como recuperar os arquivos?
- Qual é o procedimento se o snapshot existir?
- Como evitar esse problema no futuro?
💡 Solução Cenário C
Recuperação via Snapshot:
- Identificar o snapshot mais recente
aws ec2 describe-snapshots \
--filters "Name=volume-id,Values=vol-xxx" \
--query 'Snapshots[*].[SnapshotId,StartTime]' \
--output table
- Criar um novo volume a partir do snapshot
aws ec2 create-volume \
--snapshot-id snap-xxx \
--availability-zone us-east-1a \
--volume-type gp3
- Anexar o volume de recuperação
aws ec2 attach-volume \
--volume-id vol-recovery \
--instance-id i-xxx \
--device /dev/sdg
- Montar e copiar os arquivos faltantes
sudo mkdir /mnt/recovery
sudo mount /dev/sdg /mnt/recovery
cp /mnt/recovery/path/to/files /path/to/restore/
- Limpar após a recuperação
sudo umount /mnt/recovery
aws ec2 detach-volume --volume-id vol-recovery
aws ec2 delete-volume --volume-id vol-recovery
Prevenção:
- Snapshots automáticos com Amazon Data Lifecycle Manager
- Backups regulares (horários para dados críticos)
- Permissões restritivas (IAM) para evitar exclusões acidentais
- Versionamento para S3 se aplicável
Parte 4: Boas Práticas
Checklist de Gerenciamento EBS
┌─────────────────────────────────────────────────────────────┐
│ CHECKLIST BOAS PRÁTICAS EBS │
├─────────────────────────────────────────────────────────────┤
│ │
│ SNAPSHOTS E BACKUPS │
│ ☐ Snapshots automáticos configurados (DLM) │
│ ☐ Retenção definida (mín. 7 dias para produção) │
│ ☐ Snapshots testados (restauração validada) │
│ ☐ Snapshots cross-region para DR │
│ │
│ DESEMPENHO │
│ ☐ Tipo de volume adequado ao uso │
│ ☐ IOPS provisionado se necessário (io2) │
│ ☐ Monitoramento CloudWatch ativado │
│ ☐ Alertas para uso > 80% │
│ │
│ SEGURANÇA │
│ ☐ Criptografia ativada (AES-256) │
│ ☐ Chaves KMS gerenciadas corretamente │
│ ☐ Permissões IAM restritivas │
│ │
│ CUSTOS │
│ ☐ Volumes não utilizados excluídos │
│ ☐ Snapshots antigos limpos │
│ ☐ Tipo gp3 preferido ao gp2 (melhor custo-benefício) │
│ │
│ TAGS │
│ ☐ Nome descritivo │
│ ☐ Ambiente (prod/dev/test) │
│ ☐ Aplicação associada │
│ ☐ Proprietário/equipe │
│ │
└─────────────────────────────────────────────────────────────┘
Data Lifecycle Manager (DLM)
┌─────────────────────────────────────────────────────────────┐
│ AMAZON DATA LIFECYCLE MANAGER │
├─────────────────────────────────────────────────────────────┤
│ │
│ Automatiza os snapshots EBS │
│ │
│ Exemplo de política: │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ Nome: daily-backup-policy │ │
│ │ │ │
│ │ Alvo: Volumes com tag "Backup=true" │ │
│ │ │ │
│ │ Agendamento: │ │
│ │ • Frequência: Todos os dias às 03:00 UTC │ │
│ │ • Retenção: 7 snapshots (1 semana) │ │
│ │ │ │
│ │ Opções: │ │
│ │ • Cópia cross-region: us-west-2 │ │
│ │ • Tags copiadas: Sim │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Configuração CLI: │
│ aws dlm create-lifecycle-policy \ │
│ --description "Daily EBS backup" \ │
│ --state ENABLED \ │
│ --execution-role-arn arn:aws:iam::xxx:role/dlm-role \ │
│ --policy-details file://policy.json │
│ │
└─────────────────────────────────────────────────────────────┘
Parte 5: Entregável
Documento a Produzir
Crie um documento "Plano de Gerenciamento EBS" para uma aplicação fictícia com:
-
Inventário dos volumes (tabela)
- Nome, tamanho, tipo, AZ, instância anexada
-
Política de snapshots
- Frequência por ambiente
- Retenção
- Testes de restauração
-
Procedimentos documentados
- Aumento de capacidade
- Migração entre AZs
- Recuperação após incidente
-
Estimativa de custos mensais
- Volumes
- Snapshots
- IOPS provisionado (se aplicável)
Critérios de Avaliação
| Critério | Pontos |
|---|---|
| Exercícios 1-3 corretamente completados | /40 |
| Inventário dos volumes | /15 |
| Política de snapshots clara | /15 |
| Procedimentos bem documentados | /20 |
| Estimativa de custos | /10 |
| Total | /100 |
Resumo
| Conceito | Pontos-Chave |
|---|---|
| Tipos de volumes | gp3 por padrão, io2 para IOPS |
| Snapshots | Incrementais, armazenados no S3 |
| Restrição de AZ | Volume = 1 AZ apenas |
| Migração | Via snapshot + novo volume |
| DLM | Automação de backups |
Voltar: Visão geral MÓDULO 4