Armazenamento do EC2: armazenamento da instância versus EBS

As instâncias EC2 podem usar dois tipos de armazenamento local: Instance Store e Amazon EBS (Elastic Block Store). O Instance Store é fisicamente conectado ao servidor host, oferecendo IOPS e taxa de transferência muito altos, mas com uma ressalva crítica — os dados são perdidos quando a instância é parada ou encerrada. O EBS fornece armazenamento persistente em blocos conectado pela rede, que sobrevive à parada, inicialização e encerramento da instância. Entender quando usar cada opção é um tema recorrente na prova SAA-C03.

O Instance Store (também chamado de armazenamento efêmero) consiste em SSDs NVMe fisicamente conectados ao hardware host que executa sua instância EC2. Os dados no Instance Store são perdidos sempre que a instância é parada, colocada em hibernação ou encerrada, ou quando o hardware subjacente falha. No entanto, os dados persistem após uma reinicialização. O Instance Store é ideal para: dados de buffer, cache ou rascunho; arquivos temporários; e dados replicados em uma frota (por exemplo, nós Cassandra). Nem todos os tipos de instância incluem Instance Store; procure o sufixo d (por exemplo, i3.xlarge, m5d.large).

Os volumes do Amazon EBS são armazenamentos conectados pela rede que persistem independentemente do ciclo de vida da instância EC2. Um volume EBS existe em uma Availability Zone específica e pode ser anexado a uma instância EC2 por vez (exceto no caso de multi-anexação io1/io2). Quando você para e reinicia uma instância, o volume EBS retém todos os dados. Você pode desanexá-lo de uma instância e anexá-lo a outra na mesma AZ ou criar um snapshot para copiá-lo para outra AZ ou região.

AWS oferece quatro tipos de volume EBS. gp3 (SSD de uso geral): linha de base de 3.000 IOPS e 125 MB/s, configuráveis de forma independente até 16.000 IOPS e 1.000 MB/s — a opção padrão e mais econômica para a maioria das cargas de trabalho. gp2: SSD de uso geral mais antigo, em que as IOPS aumentam conforme o tamanho (3 IOPS/GB, máximo de 16.000) — está sendo substituído gradualmente pelo gp3. io2 Block Express: SSD com IOPS provisionadas de até 256.000 IOPS e 4.000 MB/s — para bancos de dados com I/O intensivo, como SAP HANA ou Oracle. io1: SSD legado com IOPS provisionadas.

Os dois tipos de EBS baseados em HDD são otimizados para taxa de transferência, não para IOPS. st1 (HDD otimizado para taxa de transferência): linha de base de 40 MB/s/TB, com picos de até 250 MB/s/TB — ideal para big data, processamento de logs e data warehouses com grandes leituras sequenciais. sc1 (HDD frio): linha de base de 12 MB/s/TB, com picos de até 80 MB/s/TB — a opção de EBS de menor custo para dados sequenciais acessados com pouca frequência. Volumes HDD não podem ser usados como volumes de inicialização (dispositivo raiz). Escolha st1 ou sc1 somente quando a taxa de transferência for mais importante que IOPS e o padrão de acesso aos dados envolver grandes leituras/gravações sequenciais.

Os snapshots do EBS são backups de um volume em determinado momento, armazenados de forma durável no Amazon S3 (embora sejam acessados pela API do EC2, e não diretamente pelo S3). Os snapshots são incrementais: o primeiro snapshot captura o volume completo, e os snapshots posteriores registram somente os blocos alterados desde o último snapshot, reduzindo o custo de armazenamento. Você pode criar um novo volume EBS a partir de qualquer snapshot em qualquer AZ da mesma Region ou copiar o snapshot para outra Region para recuperação de desastres entre regiões.

Volumes e snapshots do EBS podem ser criptografados usando chaves do AWS KMS. A criptografia é transparente para a instância: os dados são criptografados em trânsito entre a instância e o volume e em repouso no armazenamento. Você pode habilitar a criptografia padrão no nível da conta para que todo novo volume EBS criado na conta seja criptografado automaticamente, sem configuração por volume. Para criptografar um volume não criptografado, é necessário criar um snapshot, criar uma cópia criptografada do snapshot e, em seguida, criar um novo volume a partir do snapshot criptografado.

O EBS Multi-Attach permite que um volume io1 ou io2 seja anexado simultaneamente a até 16 instâncias EC2 na mesma Zona de Disponibilidade. Todas as instâncias anexadas têm acesso total de leitura/gravação. Esse recurso é usado para aplicações Linux em cluster, como Oracle RAC ou Teradata, que gerenciam a simultaneidade na camada de aplicação usando um sistema de arquivos compatível com clusters. Multi-Attach não substitui o EFS para sistemas de arquivos compartilhados: ele é específico para acesso em nível de bloco em clusters, com coordenação gerenciada pela aplicação.

Critérios principais para a decisão: É necessário persistir os dados? → Use EBS. Os dados podem ser recriados ou são replicados? → Instance Store é aceitável e oferece maior desempenho. Banco de dados com dados críticos? → Sempre EBS, com snapshots e criptografia. Espaço temporário de trabalho para treinamento de ML ou operações de ordenação? → Instance Store para obter a máxima taxa de transferência sem custo adicional. A prova frequentemente apresenta cenários em que você deve identificar se o armazenamento efêmero ou persistente é adequado para determinada carga de trabalho.

As instâncias otimizadas para EBS fornecem largura de banda de rede dedicada entre a instância EC2 e o EBS, separada da largura de banda geral da rede da instância. Isso evita a contenção de rede entre o tráfego da aplicação e o I/O de armazenamento. A maioria dos tipos de instância da geração atual já é otimizada para EBS por padrão, sem custo adicional. Tipos de instância mais antigos podem exigir que a otimização para EBS seja habilitada manualmente, mediante uma taxa adicional por hora. Para cargas de trabalho de banco de dados com alto I/O, sempre confirme que seu tipo de instância é otimizado para EBS para obter todas as IOPS provisionadas do volume.

O Amazon Data Lifecycle Manager (DLM) automatiza a criação, a retenção e a exclusão de snapshots do EBS e AMIs. Você define políticas de ciclo de vida que especificam quais volumes devem receber backup, por tag, com que frequência criar snapshots, a cada 1, 2, 3, 4, 6, 8 ou 12 horas, ou diariamente, e quantos snapshots manter. O DLM elimina a necessidade de scripts de backup personalizados e integra-se ao CloudWatch para monitorar a integridade das políticas. Para snapshots entre regiões, configure uma política de cópia na mesma definição do DLM.

Teste sua compreensão dos conceitos de AWS Solutions Architect (SAA-C03) desta lição.

Nesta lição, você aprendeu que: Instance Store oferece o maior desempenho de I/O local, mas é efêmero — os dados são perdidos quando a instância é interrompida ou encerrada, EBS fornece armazenamento persistente em blocos conectado pela rede, com quatro tipos de volume otimizados para IOPS (gp3, io2) ou taxa de transferência (st1, sc1) e os snapshots do EBS permitem backups em determinado momento armazenados no S3, que podem ser usados para recuperação entre AZs ou regiões. A seguir, exploraremos os fundamentos do armazenamento de objetos do S3.