O Amazon Elastic Block Store (EBS) fornece volumes de armazenamento em bloco persistentes, que se anexam a instâncias EC2 como se fossem discos rígidos — só que gerenciados, redundantes dentro da própria AZ, e redimensionáveis sem desligar a instância.

🎯 Para a certificação

Questões sobre EBS testam se você sabe escolher o tipo de volume certo por cenário (gp3, io2/io1, st1, sc1), entende os limites numéricos de IOPS e throughput de cada um, sabe como funciona a natureza incremental dos snapshots, entende o problema de consistência ao snapshotar um volume em uso, e sabe quando EBS não é a resposta certa (compartilhamento entre instâncias, por exemplo).

---

Resumo

Pense no EBS como um HD externo de alta tecnologia: você "pluga" (anexa) um volume numa instância EC2, os dados persistem mesmo se a instância for desligada ou terminada (desde que você não delete o volume junto), e — diferente de um HD externo comum — você pode trocar o volume por um mais rápido, aumentar seu tamanho, ou clonar seu conteúdo inteiro (snapshot) sem nunca desconectar o cabo.

• O que é: armazenamento em bloco (não em arquivos, não em objetos) que vive dentro de uma única Availability Zone e se anexa a uma instância EC2.
• Tipos: SSD de uso geral (gp3/gp2), SSD de IOPS provisionadas (io2/io1) para bancos críticos, e HDD (st1/sc1) otimizados para throughput sequencial ou custo mínimo.
• Snapshots: cópias incrementais armazenadas no S3 (de forma gerenciada, não visível como um bucket comum), usadas para backup, DR e criação de novos volumes/AMIs.
• Limitação importante: por padrão, um volume EBS só pode ser anexado a uma instância por vez (exceto com Multi-Attach, um recurso específico para io1/io2).

---

1. O que é armazenamento em bloco, e por que isso importa

Antes de entrar nos tipos de volume, vale entender o que torna o EBS diferente de outras opções de storage da AWS — porque a prova adora testar "qual storage usar" comparando EBS com S3 e EFS.

Armazenamento em bloco divide os dados em blocos de tamanho fixo, cada um endereçável individualmente — é o mesmo modelo usado pelo disco rígido do seu computador. O sistema operacional formata o volume com um sistema de arquivos (ext4, XFS, NTFS) e enxerga o EBS exatamente como enxergaria um disco físico local. Isso tem duas implicações importantes:

• Baixíssima latência, adequado para bancos de dados e sistemas de arquivos que fazem muitas operações de leitura/escrita pequenas e aleatórias.
• Anexado a uma única instância por vez (na configuração padrão) — porque o sistema de arquivos no topo do volume não foi projetado para ser acessado simultaneamente por múltiplos "donos" sem coordenação, ao contrário de um sistema de arquivos de rede como o EFS.

💡 Para a prova: se o cenário fala em "IOPS", "banco de dados local à instância" ou "boot volume", pense EBS. Se fala em "acesso simultâneo por múltiplas instâncias" ou "compartilhamento via NFS", pense EFS, não EBS.

---

2. Tipos de volume — SSD vs HDD, e quando usar cada um

2.1 A diferença fundamental: gp3 vs gp2

O gp3 desacoplou IOPS e throughput do tamanho do volume — você escolhe cada um independentemente (até os limites da tabela), pagando só pelo que configurar. Já no gp2 (o tipo mais antigo), a performance é proporcional ao tamanho do volume: você ganha 3 IOPS por GiB provisionado, com um baseline mínimo de 100 IOPS e um teto de 16.000 IOPS (atingido só em volumes bem grandes). Isso significa que, no gp2, se você quisesse mais IOPS, muitas vezes precisava provisionar um volume maior do que realmente precisava em espaço, só para "comprar" mais performance — um desperdício de custo que o gp3 elimina.

💡 Para a prova: gp3 é hoje a recomendação padrão para a maioria dos novos deployments — mais barato por GB que gp2 e com performance configurável independentemente do tamanho.

2.2 io2 / io1 — quando IOPS previsíveis são inegociáveis

io2 e io1 existem para um cenário específico: bancos de dados transacionais críticos (OLTP) que não podem tolerar variação de performance. A diferença central para gp3 é a durabilidade e a consistência da IOPS entregue — io2 oferece 99,999% de durabilidade anual (contra 99,8%–99,9% do gp3), e sustenta a IOPS provisionada de forma muito mais previsível sob carga sustentada.

Exemplo numérico prático: um banco processando picos de milhares de transações por segundo, onde cada transação depende de operações de disco de baixa latência, se beneficia de io2 — mesmo custando mais por IOPS que gp3 — porque a aplicação não pode tolerar uma queda momentânea de performance em horário de pico.

2.3 st1 e sc1 — HDD, não SSD

Vale reforçar: st1 e sc1 são discos magnéticos (HDD), não SSD. Isso muda completamente o perfil de uso adequado — eles são otimizados para throughput em operações sequenciais grandes, não para IOPS aleatórias pequenas. Um pipeline que grava centenas de MB/s de logs sequencialmente se beneficia de st1 a um custo por GB muito menor que qualquer SSD; mas o mesmo st1 usado como boot volume ou banco de dados teria performance ruim, porque essas cargas de trabalho fazem muitas operações pequenas e aleatórias — exatamente o cenário em que HDD é fraco.

💡 Para a prova: st1/sc1 não podem ser usados como boot volume — essa é uma pegadinha clássica. Boot volumes precisam ser SSD (gp2, gp3, io1 ou io2).

---

3. Snapshots — como funcionam, por dentro

3.1 Natureza incremental

Um snapshot é uma cópia point-in-time do volume, armazenada de forma gerenciada no S3 (você não vê isso como um bucket comum na sua conta, mas o mecanismo por trás é comparável). A partir do segundo snapshot de um mesmo volume, apenas os blocos que mudaram desde o snapshot anterior são efetivamente copiados — não o volume inteiro.

Explicação didática: imagine um volume de 100 GB e um snapshot tirado ontem. Hoje, apenas 2 GB de dados mudaram. O próximo snapshot copia apenas esses 2 GB — não os 100 GB inteiros — mesmo que, ao restaurar, você tenha acesso ao volume completo de 100 GB (a AWS reconstrói o restante a partir do snapshot anterior automaticamente, de forma transparente para você). É por isso que snapshots frequentes custam relativamente pouco depois do primeiro: você paga pelo delta, não pelo volume inteiro a cada vez.

3.2 O problema da consistência

Esse é o ponto mais cobrado sobre snapshots na prova. Se um snapshot for tirado enquanto a instância está ativamente escrevendo no volume (por exemplo, um banco de dados no meio de uma transação), o snapshot pode capturar um estado inconsistente — como fotografar um documento no exato instante em que alguém está escrevendo nele, capturando metade de uma frase.

Estratégias para garantir consistência:

• Parar a instância antes do snapshot (mais simples, mas implica downtime).
• Quiesce/flush manual: coordenar a aplicação para descarregar buffers de escrita no disco antes do snapshot, sem necessariamente parar a instância.
• AWS Backup ou snapshots integrados via AMI (que já coordenam esse processo de forma mais confiável para determinados cenários).
• Para bancos de dados gerenciados (RDS), esse problema já é resolvido automaticamente pelo próprio serviço — é um cuidado que existe justamente porque, em EBS puro (EC2 auto-gerenciado), você é responsável por essa coordenação.

💡 Para a prova: se o enunciado descreve um snapshot tirado sem nenhuma coordenação de consistência num volume com banco de dados ativo, a resposta correta quase sempre menciona risco de estado inconsistente, não "sempre consistente" — snapshots não são transacionais por padrão.

3.3 Usos de um snapshot

• Restaurar um volume perdido ou corrompido.
• Criar um novo volume a partir do snapshot (inclusive em outra AZ, já que snapshots não têm a restrição de AZ que volumes têm).
• Criar uma AMI (Amazon Machine Image) para lançar novas instâncias EC2 já com aquele estado de disco.
• Copiar entre regiões, útil como parte de estratégia de disaster recovery multi-region.

---

4. Criptografia

Volumes EBS suportam criptografia em repouso via AWS KMS, de forma transparente — a criptografia/descriptografia acontece automaticamente entre a instância e o volume, sem impacto perceptível de performance na maioria dos casos.

Pontos que a prova costuma cobrar:

• Um volume não criptografado não pode ser "criptografado depois" diretamente — o caminho é criar um snapshot do volume original, copiar esse snapshot habilitando criptografia, e criar um novo volume a partir do snapshot criptografado.
• Snapshots de volumes criptografados são sempre criptografados automaticamente.
• É possível configurar a conta/região para que todo novo volume seja criptografado por padrão, evitando o erro humano de esquecer de habilitar a opção.

---

5. Redimensionamento e Elastic Volumes

Volumes EBS podem ser modificados sem downtime através do recurso Elastic Volumes: você pode aumentar o tamanho, mudar o tipo (ex: gp2 → gp3), ou ajustar IOPS/throughput provisionados de um volume já em uso, sem precisar desanexar ou parar a instância.

Uma ressalva importante: aumentar o volume não expande automaticamente o sistema de arquivos. Depois de expandir o volume no nível da AWS, ainda é necessário rodar um comando dentro do sistema operacional (ex: growpart + resize2fs no Linux, ou a extensão de partição no Windows) para que o sistema de arquivos realmente use o novo espaço disponível.

---

6. Limitação de AZ e Multi-Attach

Um volume EBS vive dentro de uma única Availability Zone e só pode ser anexado a instâncias dentro dessa mesma AZ. Isso é um ponto de dependência crítico ao desenhar arquiteturas de alta disponibilidade: se a instância precisa migrar para outra AZ (ex: um failover de Auto Scaling Group), o volume EBS original não vai junto — a estratégia típica é recriar o volume a partir de um snapshot na AZ de destino.

Por padrão, um volume só pode ser anexado a uma instância por vez. A exceção é o recurso Multi-Attach, disponível apenas para volumes io1/io2, que permite anexar um mesmo volume a até 16 instâncias na mesma AZ simultaneamente — mas isso exige que a aplicação (não a AWS) gerencie o acesso concorrente com um sistema de arquivos com cluster-awareness; um sistema de arquivos comum (ext4, NTFS) não é seguro para múltiplos escritores simultâneos, mesmo com Multi-Attach habilitado.

💡 Para a prova: se o cenário pede "compartilhar armazenamento em bloco entre múltiplas instâncias com leitura/escrita comum", a resposta raramente é EBS puro — geralmente é EFS (sistema de arquivos gerenciado via NFS) ou, em casos bem específicos de cluster com aplicação preparada, Multi-Attach em io1/io2.

---

7. EBS vs EFS vs Instance Store — cenários e comparações

💡 Para a prova: se a pergunta menciona dados que precisam sobreviver a um stop/restart da instância, Instance Store está descartado — é armazenamento efêmero, fisicamente vinculado ao hardware do host, e perdido nessas operações (diferente de EBS, que persiste).

---

8. Boas práticas

• Prefira gp3 como padrão para novos deployments — melhor custo/benefício que gp2, com IOPS e throughput configuráveis independentemente do tamanho.
• Reserve io2/io1 para cargas que realmente exigem IOPS consistentes e previsíveis (bancos OLTP críticos), não como padrão geral.
• Automatize snapshots com Amazon Data Lifecycle Manager ou AWS Backup, com política de expiração para não acumular custo indefinidamente.
• Monitore VolumeQueueLength, BurstBalance e métricas de IOPS/throughput no CloudWatch para identificar gargalos antes que afetem a aplicação.
• Habilite criptografia por padrão na conta/região para evitar volumes não criptografados criados por descuido.
• Nunca use st1/sc1 como boot volume ou para cargas de IOPS aleatória — são HDD otimizados para throughput sequencial.
• Lembre-se do escopo de AZ ao desenhar estratégias de failover: um volume não migra automaticamente entre AZs.

---

9. Como cai na certificação

• Cenário "banco de dados de produção com picos de IOPS que não podem variar" → io2/io1 com IOPS provisionadas.
• Cenário "novo deployment, uso geral, sem requisito extremo de performance" → gp3 (custo/benefício padrão).
• Cenário "processamento de logs ou big data com leitura/escrita sequencial grande" → st1.
• Cenário "dados acessados raramente, custo mínimo, sem exigência de performance" → sc1.
• Cenário "snapshot tirado sem coordenação, num volume com escrita ativa" → risco de inconsistência; recomendar quiesce, parar a instância, ou AWS Backup.
• Cenário "compartilhar armazenamento entre múltiplas instâncias com leitura/escrita simultânea" → EFS, não EBS puro (exceto casos raros de Multi-Attach com aplicação cluster-aware).
• Cenário "expandir volume sem downtime" → Elastic Volumes, lembrando que o sistema de arquivos ainda precisa ser expandido manualmente dentro do SO.
• Cenário "volume não criptografado precisa virar criptografado" → snapshot → copiar com criptografia habilitada → novo volume a partir do snapshot criptografado.
• Cenário "instância falha e precisa subir em outra AZ, mas o volume não acompanha" → reforça que EBS é limitado a uma AZ; a estratégia é recriar o volume via snapshot na AZ de destino.

---

10. Exercícios práticos

1. Compare cenários em que você escolheria gp3 vs io2 para um banco relacional de produção. Liste pelo menos três critérios de decisão.
2. Desenhe uma estratégia de backup baseada em snapshots para uma aplicação com RPO de 15 minutos e RTO de 1 hora, incluindo política de retenção.
3. Explique por que snapshots são incrementais e como isso afeta o custo ao longo do tempo, com um exemplo numérico.
4. Avalie se st1 é adequado para um sistema de arquivos com imagens de usuário acessadas aleatoriamente e com frequência ao longo do dia. Justifique.
5. Um volume não criptografado precisa passar a ser criptografado sem perder os dados existentes. Descreva o caminho correto, passo a passo.
6. Explique por que uma instância que falha numa AZ não consegue simplesmente "levar" seu volume EBS para outra AZ ao subir novamente, e qual é a estratégia correta nesse caso.

---

11. Questões de Revisão

Questão 1

Questão 2

Questão 3

Questão 4

Questão 5

Questão 6

Questão 7

Questão 8

Questão 9

Questão 10

Questão 11

Questão 12

Questão 13

Questão 14

Questão 15

Questão 16

Questão 17

Questão 18

Questão 19

Questão 20

Questão 21

Questão 22

Laboratório Prático

Objetivo: criar um volume EBS, observar o comportamento de um snapshot incremental, e praticar o redimensionamento sem downtime.

Pré-requisitos: conta AWS com permissão para EC2 e EBS; uma instância EC2 já em execução.

Tempo estimado: 25 minutos

Possíveis custos: baixo, dentro do free tier para volumes pequenos e poucas horas de uso.

Passos:

1. Crie um volume EBS gp3 de 8 GiB na mesma AZ de uma instância EC2 já existente, e anexe-o à instância.
2. Dentro da instância, formate e monte o volume, e grave alguns arquivos de teste nele.
3. Tire um primeiro snapshot do volume e observe, no console, o tamanho reportado.
4. Adicione mais alguns arquivos pequenos ao volume (uma fração pequena do tamanho total) e tire um segundo snapshot.
5. Compare os dois snapshots — observe que o segundo reflete apenas o delta de dados novos, não o volume inteiro novamente.
6. Use o recurso Elastic Volumes para aumentar o tamanho do volume (ex: de 8 GiB para 12 GiB) sem desanexar ou parar a instância.
7. Dentro da instância, rode o comando de expansão de partição e do sistema de arquivos (ex: growpart + resize2fs no Linux) e confirme que o novo espaço está disponível.

Resultado esperado: você observa na prática a natureza incremental dos snapshots e confirma que redimensionar o volume no nível da AWS não expande automaticamente o sistema de arquivos — um passo manual dentro do SO ainda é necessário.

Limpeza dos recursos: desanexe e delete o volume EBS de teste, e delete os snapshots criados durante o laboratório.

---

Referências:

• Amazon EBS User Guide: https://docs.aws.amazon.com/ebs/latest/userguide/what-is-ebs.html
• Tipos de volume EBS: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html
• Snapshots do Amazon EBS: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html
• Elastic Volumes: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/requesting-ebs-volume-modifications.html
• Criptografia no Amazon EBS: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html
• EBS Multi-Attach: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes-multi.html