I can literally delete all but the most recent with impunity
Supondo que você não precisa de nenhum dado que já tenha sido excluído ou substituído no volume quando tirou o instantâneo mais recente, isso é verdade.
Os instantâneos do EBS são logicamente incrementais - não fisicamente incrementais. Aqui está a inteligência que explica a diferença:
Os instantâneos de volumes do EBS não contêm dados tecnicamente ... eles contêm listas de ponteiros para blocos de dados de backup, que o EBS armazena no S3 em seu nome (e cobra pelo armazenamento). A cada novo instantâneo, se forem encontrados blocos no volume que não foram alterados do instantâneo anterior e, portanto, já estiverem armazenados no S3 com o mesmo conteúdo, eles não serão armazenados novamente - o novo instantâneo apenas referencia os blocos já armazenados por outro trabalho instantâneo ... e é por isso que você provavelmente não tem uma conta de armazenamento estranha.
Isto é o que quero dizer com "logicamente" incremental. Os blocos alterados recentemente (desde o último snapshot) são preservados no S3, mas eles não estão realmente "no" snapshot mais recente - eles são referenciados por ele, e por qualquer snapshot futuro que seja feito, até que eles sejam alterados.
Os snapshots do EBS são completamente independentes do sistema de arquivos. Eles não têm idéia sobre como os blocos são usados, apenas que eles mudaram entre os instantâneos. Instantâneos são uma operação em nível de bloco (não em nível de arquivo), portanto, dentro de qualquer granularidade dos blocos, se apenas parte de um arquivo grande foi alterada, no lugar (sem mover o arquivo no disco), apenas a alteração parte do arquivo seria recém-backup. (Um exemplo simples seria um arquivo de log em crescimento contínuo).
Quando você exclui instantâneos, os blocos referenciados por esses instantâneos são eliminados do armazenamento do S3 (interrompendo o faturamento para armazenamento desses blocos) se, e somente se, nenhum outro instantâneo os referenciar. Caso contrário, é claro, eles são preservados, porque ainda são necessários.
Se você excluir todos os instantâneos, exceto os mais recentes, todos os blocos armazenados no S3 que não forem necessários para restaurar esse único instantâneo serão eliminados. Assim, o tamanho do armazenamento do instantâneo faturável será exatamente igual ao tamanho do volume. , porque somente esses blocos permaneceriam no armazenamento S3. (Tecnicamente, ele deve ser menor, pois o EBS aparentemente usa um algoritmo de compactação reversível em snapshots, mas os detalhes não são públicos, mas, em princípio, um volume de 8GB com exatamente um snapshot faz referência a exatamente 8GB de snapshots).
É por isso que os tamanhos de instantâneos sempre mostram o tamanho do volume no console e na API, em vez de algum tipo de tamanho "incremental" - um instantâneo não "contém" dados, mas contém ponteiros para dados de backup suficientes blocos para preencher o volume com conteúdo idêntico ao que existia no volume quando o trabalho de instantâneo foi iniciado. E é aí que entra a sua "impunidade".
Limpar todos os instantâneos antigos, removerá alguns dos blocos de backup e economizará algum dinheiro, dependendo de quanto o volume muda entre os instantâneos. Se ele mudar muito pouco, você terá muito pouco armazenamento de bloco de backup que seria liberado limpando-os, e eles não estão custando muito.
Devido ao risco de arquivos serem apagados, sobrescritos, etc., algum período de dias antes do problema ser notado ... parece sensato manter mais do que apenas um dia, mas esse raciocínio não está relacionado à forma como o EBS trabalho de instantâneos.
Minha política, implementada por meio de automação interna, é manter um diário todos os dias durante vários dias, reduzindo a retenção semanal de snapshots por várias semanas e, finalmente, retendo um instantâneo mensal para cada volume para sempre, ou menos. dependendo das políticas de retenção. (Minha automação usa tags "mágicas", nos volumes, para personalizar a retenção e o tempo em um nível por volume, mas essa política padrão é usada na maioria dos volumes.)
A propósito, com a conversa do S3, provavelmente é preciso esclarecer que o EBS é o "cliente" do S3 nessa configuração, não você - é por isso que você não consegue ver esses dados de backup no S3.¹ "qualquer que seja a granularidade dos blocos" - Por isso, quero dizer o tamanho de um "bloco de backup" da perspectiva do EBS. Este tamanho é, até onde eu sei, não documentado, mas minha suposição é que um "bloco" neste contexto é quase certamente maior que o "tamanho de bloco" do dispositivo apresentado ao sistema operacional, já que um tamanho de bloco de backup de KiB de um dígito resultaria em um número de grandes quantidades para bloquear, rastrear, armazenar e recarregar.