AWS Backup leva vaults logicamente isolados ao Amazon EBS Snapshots Archive

O que mudou

O AWS Backup agora permite arquivar, no Amazon EBS Snapshots Archive, backups de volumes do Amazon EBS que estão guardados em um logically air-gapped vault. Esse tipo de vault do AWS Backup já existia para armazenar backups imutáveis, bloqueados por padrão e isolados por criptografia (com chaves gerenciadas pela AWS ou chaves gerenciadas pelo cliente), permitindo compartilhamento seguro entre contas e entre contas de uma AWS Organizations, com restauração direta para reduzir o tempo de recuperação após um incidente de perda de dados.

Até este anúncio, segundo o texto da AWS, o vault logicamente isolado guardava snapshots do EBS apenas em armazenamento "warm" (quente), sem a opção de movê-los para o tier Archive. Agora é possível fazer essa transição, o que combina a imutabilidade do logically air-gapped vault com o custo de armazenamento mais baixo do EBS Snapshots Archive, voltado a snapshots raramente acessados.

Onde está disponível

O suporte está em todas as regiões da AWS onde o logically air-gapped vault e o Amazon EBS Snapshots Archive existem simultaneamente. O post não lista essas regiões nem confirma explicitamente a região América do Sul (São Paulo), sa-east-1: a própria AWS direciona quem quer a lista exata para a documentação do AWS Backup, que traz a disponibilidade regional atualizada.

Antes de desenhar um plano de retenção que dependa desse recurso, vale checar essa documentação para confirmar se sa-east-1 já tem os dois recursos habilitados. Arquiteto que opera com conta multi-região para DR não pode assumir paridade de recursos entre regiões sem essa confirmação.

Quanto custa

O anúncio não traz valores de preço: ele aponta para a página de pricing do AWS Backup para custos do vault logicamente isolado e, implicitamente, para a tabela de preços do Amazon EBS para o tier Snapshots Archive, cobrado por GB-mês de dados arquivados. Como a fonte não informa números, não há como citar valor em dólar ou convertido para real com cotação e data confiáveis aqui.

O ponto prático para quem orça: o custo final de um plano de backup com arquivamento passa a ter pelo menos três componentes a somar: armazenamento no tier warm do vault, armazenamento no tier Archive e, possivelmente, custo de restauração quando o snapshot arquivado precisar ser usado. Esse último item é característica histórica do EBS Snapshots Archive, já documentada pela AWS para esse tier antes deste anúncio, e continua valendo para os snapshots movidos a partir do logically air-gapped vault.

Como começar

A configuração acontece dentro de um backup plan do AWS Backup, via console, AWS CLI ou SDKs. Os passos, conforme descritos no anúncio:

• Criar ou editar uma regra de backup que rode mensalmente ou com frequência menor;
• Definir um logically air-gapped vault como destino primário do backup ou como destino de uma regra de cópia (copy rule);
• Habilitar a opção Archive Amazon EBS snapshots no ciclo de vida (lifecycle) da regra de backup ou no ciclo de vida da cópia;
• Configurar o tempo em armazenamento warm antes de o backup transicionar para o Archive.

A restrição de frequência mensal (ou menor) no backup plan é a mesma já aplicada hoje ao EBS Snapshots Archive fora do contexto de vault isolado: o tier Archive não foi pensado para dados que mudam de warm para cold com frequência diária.

O que muda para quem já usa

Quem já desenha ambientes de disaster recovery com logically air-gapped vault, tipicamente para cenários de ransomware em que é preciso um ponto de restauração isolado de contas comprometidas, ganha uma alavanca de custo que antes não existia: dados de retenção longa e compliance podem sair do armazenamento warm, mais caro, sem abrir mão do isolamento lógico e da imutabilidade do vault.

O trade-off a considerar no runbook de recuperação é o tempo de restauração. Snapshot arquivado no Amazon EBS Snapshots Archive exige um passo de restauração antes de virar volume utilizável, diferente de um snapshot que ainda está em warm storage. Isso significa revisar o RTO (recovery time objective) documentado para cada classe de dado: snapshot de produção crítico provavelmente continua em warm, enquanto backup de retenção regulatória de longo prazo, pouco provável de ser restaurado com urgência, é candidato natural ao Archive dentro do mesmo vault isolado.

Para quem segue o pilar de confiabilidade do AWS Well-Architected Framework, o recurso dá um motivo a mais para separar, no plano de backup, o que precisa de RPO/RTO agressivo do que precisa apenas de retenção auditável e barata, em vez de tratar todo snapshot do mesmo jeito dentro do vault isolado.

Fonte: AWS What's New