AWS SAA-C03/03 - Computação2 min
EBS e Instance Store
Perguntas-guia
Responda com suas palavras antes de ler o resto da nota.
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off (custo, latência, operação)?
- Que sinal no enunciado aponta pra isso?
- Com o que isso é confundido na prova?
Conceito
Duas formas de dar disco a uma EC2, com propriedades opostas.
| EBS | Instance Store | |
|---|---|---|
| Natureza | Volume de rede | Disco físico no host |
| Persistência | Sobrevive ao stop/terminate (se configurado) | Some no stop/terminate |
| Performance | Alta | Máxima possível |
| Snapshot | Sim, pro S3 | Não |
| Redimensionar | Sim, a quente | Não |
| Escopo | Uma AZ | A instância |
Tipos de volume EBS
| Tipo | Mídia | IOPS máx | Throughput | Use para |
|---|---|---|---|---|
| gp3 | SSD | 16.000 | 1.000 MB/s | Padrão. IOPS e throughput independem do tamanho |
| gp2 | SSD | 16.000 (3 IOPS/GB) | 250 MB/s | Legado — pra ter IOPS você precisa aumentar o disco |
| io2 Block Express | SSD | 256.000 | 4.000 MB/s | Banco crítico, Multi-Attach, 99,999% durabilidade |
| io1 / io2 | SSD | 64.000 | 1.000 MB/s | IOPS provisionado |
| st1 | HDD | 500 | 500 MB/s | Throughput sequencial: big data, log |
| sc1 | HDD | 250 | 250 MB/s | Arquivo frio, menor custo por GB |
HDD (st1/sc1) não pode ser volume de boot.
Fatos que caem
- EBS vive em uma AZ. Pra mover: snapshot → restaurar na outra AZ. Pra outra região: copiar o snapshot.
- Snapshot é incremental e guardado no S3 (invisível pra você).
- Multi-Attach: só io1/io2, mesma AZ, até 16 instâncias, e exige filesystem que suporte acesso concorrente.
- Criptografia: liga na criação. Snapshot de volume criptografado → volume criptografado. Não há caminho de volta pro claro.
DeleteOnTermination: true por padrão no volume raiz, false nos demais.- EBS-optimized separa o tráfego de disco do tráfego de rede.
Trade-offs
gp3 desacoplou IOPS do tamanho e por isso tornou gp2 obsoleto: em gp2 você comprava 1 TB só pra ter 3.000 IOPS. io2 custa bem mais e só se justifica quando o requisito de IOPS é explícito e alto. Instance store entrega a maior performance possível e transfere pra você todo o risco de perda — só serve pra cache, buffer, scratch e dado recriável.
Sinais de prova
- "Maior IOPS possível, dado temporário" → Instance Store
- "Banco de dados com IOPS provisionado" → io2 / io2 Block Express
- "Reduzir custo de volume superdimensionado em gp2" → migrar pra gp3
- "Log sequencial de grande volume, barato" → st1
- "Mover volume entre AZs" → snapshot e restore
- "Dados sumiram depois de parar a instância" → era instance store
- "Vários EC2 no mesmo filesystem" → EFS, não EBS (exceto io2 Multi-Attach na mesma AZ)
Relacionado
Parte de 03 - MOC Computação · Documentação AWS