DEV Community: Rodolfo Henrique

The 3-2-1-1-0 backup rule. We had everything except the zero

Rodolfo Henrique — Wed, 07 Oct 2026 00:40:53 +0000

The 3-2-1-1-0 backup rule. We had everything except the zero

Backup looks simple until the day you need it.

In simple terms, a backup means making a copy of your data so it can be recovered if the original is lost, corrupted, or deleted.

But there is an important difference between having a backup and being able to recover your data from it.

Imagine that every day an automated process backs up your database. At the end, the system shows a big green mark: the process finished without errors.

You might think: "everything is protected."

But what does that green mark actually mean?

Only that the process was able to run the steps it was supposed to run. By itself, it does not guarantee that the copy is intact, that the data is consistent, or that you can recover it when you really need to.

This is where the 3-2-1-1-0 rule comes in.

It is a strategy to reduce the risk of losing data even when something goes wrong. The numbers describe how copies should be kept and protected:

3 copies of the data
2 different types of media or storage
1 copy kept off the primary environment
1 isolated or immutable copy
0 errors during the recovery test

The last number is the interesting one.

Zero is not another copy or another place to store backups. It is a requirement: when it is time to recover the data, the restore has to work.

Because a backup that has never been restored is, to a point, a hypothesis.

The scene below is the starting point for understanding that count, and especially the reasoning behind each number.

What fails when a number is missing

The rule only holds if each number covers a different failure. If two numbers break the same way, you do not have five controls. You have repetition.

Without the 3, production and the "backup" live in the same place. A retention mistake, a broad policy, or a compromised identity deletes the original and the copies together. Three names in one location are not three copies.

Without the 2, the copies use the same media or the same storage service. The failure repeats: corruption, quota, API, region. Two identical disks in the same account fail the same way.

Without the 1 off the primary environment, the incident in that environment takes the backup with it. Compromised account, single IdP, unavailable region. The copy has to sit where that incident cannot reach.

Without the 1 that is isolated or immutable, whoever reached production also reaches the backup delete. Isolation cuts the easy path. Immutability blocks the delete even when the path appears. Ransomware that hits production usually hits the backup repository next. Without that lock, the way back disappears with the original.

Without the 0, the job is green and the box will not open. The first four numbers say where the copy lives. The zero says whether it comes back.

That is failure engineering, not a poster. It is still incomplete until restore has been exercised.

The green job lies by omission

A successful backup job answers a narrow question: the writer persisted what was requested, to the configured destination, inside the window. It does not answer whether the incremental chain is intact. It does not answer whether the database was captured in a usable state (with a flush, a consistent snapshot, a native backup), or only as a disk in the middle of a write. It does not answer whether the KMS key for restore still exists, whether the identity doing the restore can read the vault, whether the destination engine accepts that version, or whether the time to return fits what the business calls acceptable.

Integrity means the backup is complete and coherent. Availability means you can reach it and apply it. Neither one is the job's exit code.

That is why the zero is not a quantity. It is not "one more vault". It is the acceptance criterion: restore on purpose, watch the data come back, measure how long it took, and only then call the design 3-2-1-1-0. Test the job. Test recoverability. Both. One without the other leaves a green check on a box that will not open.

What a recovery test has to show

The zero does not ask for a lab. It asks for four answers, obtained on purpose, without panic:

did the data come back?
did it come back consistent, in a state the application will accept?
could someone on the team run the restore without inventing permissions, keys, or a destination on the spot?
does the time to return fit what the business can stand?

If any answer is "the job was green", the test has not happened yet. A dashboard measures the writer. Recovery measures the way back.

Does the backup work when you need it?

"Do we have a backup?"

That sounds like the right question. In practice, it says little. Most environments can answer yes.

The question that actually matters is this one:

When was the last time someone restored that backup on purpose, in a real environment, and confirmed that the system came back up?

A dashboard can show that the backup finished successfully. It can show that the copy exists, that storage is healthy, and that the last job completed without errors.

None of those signals answers whether you can recover the system when you actually need to.

If the only evidence that the backup works is a green dashboard, you know you have a copy. You might already have the 3, the 2, and both 1s.

But you are still missing the zero.

The zero is proof that the way back works.

A regra de backup 3-2-1-1-0. Tínhamos tudo, menos o zero

Rodolfo Henrique — Wed, 07 Oct 2026 00:40:52 +0000

A regra de backup 3-2-1-1-0. Tínhamos tudo, menos o zero

Backup parece simples até o dia em que você precisa dele.

Em termos simples, fazer backup significa criar uma cópia dos seus dados para que eles possam ser recuperados caso o original seja perdido, corrompido ou apagado.

Mas existe uma diferença importante entre ter um backup e conseguir recuperar seus dados a partir dele.

Imagine que todos os dias um processo automatizado execute o backup do seu banco de dados. No final, o sistema mostra um grande sinal verde: o processo terminou sem erros.

Você pode pensar: "está tudo protegido".

Mas o que esse sinal verde realmente significa?

Apenas que o processo conseguiu executar as etapas previstas. Ele não garante, sozinho, que a cópia esteja íntegra, que os dados estejam consistentes ou que seja possível recuperá-los quando você realmente precisar.

É aqui que entra a regra 3-2-1-1-0.

Ela é uma estratégia para reduzir o risco de perder os dados mesmo quando alguma coisa dá errado. Os números representam como as cópias devem ser mantidas e protegidas:

3 cópias dos dados
2 tipos diferentes de mídia ou armazenamento
1 cópia mantida fora do ambiente principal
1 cópia isolada ou imutável
0 erros durante o teste de recuperação

O último número é o mais interessante.

O zero não representa mais uma cópia ou outro lugar para armazenar seus backups. Ele representa uma exigência: quando chegar a hora de recuperar os dados, o restore precisa funcionar.

Porque backup que nunca foi restaurado é, até certo ponto, uma hipótese.

A cena abaixo é o ponto de partida para entender essa conta e, principalmente, a lógica por trás de cada número.

O que falha quando falta um número

A regra só vale se cada número segura uma falha diferente. Se dois números quebram do mesmo jeito, você não tem cinco controles. Tem repetição.

Sem o 3, produção e “backup” moram no mesmo destino. Um erro de retenção, uma policy larga ou uma identidade comprometida apaga o original e as cópias juntas. Três nomes no mesmo lugar não são três cópias.

Sem o 2, as cópias usam o mesmo tipo de mídia ou o mesmo serviço de armazenamento. A falha se repete: corrupção, quota, API, região. Dois discos iguais, na mesma conta, falham do mesmo jeito.

Sem o 1 fora do ambiente principal, o incidente do ambiente leva o backup junto. Conta comprometida, IdP único, região indisponível. A cópia precisa estar onde esse incidente não alcança.

Sem o 1 isolado ou imutável, quem chegou na produção também chega no delete do backup. Isolamento corta o caminho fácil. Imutabilidade impede o delete mesmo quando o caminho aparece. Ransomware que mira produção costuma mirar o repositório de backup em seguida. Sem essa trava, a via de volta some com o original.

Sem o 0, o job está verde e a caixa não abre. Os quatro primeiros números respondem onde a cópia está. O zero responde se ela volta.

Isso é engenharia de falha, não poster. Ainda assim é incompleto enquanto o restore não for exercitado.

O job verde mente por omissão

Um job de backup bem-sucedido responde a uma pergunta estreita: o writer conseguiu persistir o que foi pedido, no destino configurado, dentro da janela. Ele não responde se a cadeia incremental está íntegra. Não responde se o banco foi capturado em estado aplicável (com flush, com snapshot consistente, com backup nativo), ou só como um disco no meio de um write. Não responde se a chave KMS do restore ainda existe, se a identity que restaura tem permissão no cofre, se o engine de destino aceita aquela versão, se o tempo de volta cabe no que o negócio chama de aceitável.

Integridade é o backup estar completo e coerente. Disponibilidade é conseguir acessá-lo e aplicá-lo. Nenhuma das duas é o exit code do job.

Por isso o zero não é quantidade. Não é “mais um vault”. É o critério de aceite: restaurar de propósito, ver o dado voltar, medir quanto tempo levou, e só então chamar o desenho de 3-2-1-1-0. Teste do job. Teste da recuperabilidade. Os dois. Um sem o outro deixa um check verde em cima de uma caixa que não abre.

O que o teste de recuperação precisa mostrar

O zero não pede um laboratório. Pede quatro respostas, obtidas de propósito, sem pânico:

o dado voltou?
voltou consistente, num estado que a aplicação aceita?
alguém do time conseguiu fazer o restore sem improvisar permissão, chave ou destino?
o tempo de volta cabe no que o negócio aguenta?

Se alguma resposta for “o job estava verde”, o teste ainda não aconteceu. Dashboard mede o writer. Recuperação mede o caminho de volta.

O backup funciona quando você precisa dele?

"Temos backup?"

Essa parece ser a pergunta certa. Mas, na prática, ela diz pouco. A maioria dos ambientes consegue responder que sim.

A pergunta que realmente importa é outra:

Quando foi a última vez que alguém restaurou esse backup de propósito, em um ambiente real, e confirmou que o sistema voltou a funcionar?

Um dashboard pode mostrar que o backup terminou com sucesso. Pode mostrar que a cópia existe, que o armazenamento está saudável e que o último job foi concluído sem erros.

Mas nenhum desses indicadores responde se você consegue recuperar o sistema quando realmente precisar.

Se a única evidência de que o backup funciona é um dashboard verde, você sabe que tem uma cópia. Talvez já tenha o 3, o 2 e os dois 1.

Mas ainda falta o zero.

O zero é a prova de que o caminho de volta funciona.

A classe mais barata do S3 é a que você nunca abre

Rodolfo Henrique — Mon, 28 Sep 2026 22:36:13 +0000

A classe mais barata do S3 é a que você nunca abre

Um time tira alguns milhões de objetos do S3 Standard. O armazenamento por gigabyte cai. O financeiro respira. Dois meses depois alguém roda um job que lê quase o prefixo inteiro. A fatura não ficou mais barata. Ficou uma taxa de retrieval com uma storage class colada.

Esse é o erro clássico do S3. A pessoa otimiza o preço de guardar o byte. A conta também cobra por tocar nele, por apagar cedo demais e por objeto menor do que a classe quer faturar.

Se você guardar uma coisa: escolha a classe pela frequência de leitura, pela velocidade que essa leitura precisa ter e por conseguir ou não reconstruir o objeto se uma zona sumir. O resto é casar essas três respostas com uma classe que a AWS já nomeou.

Referência oficial: Understanding and managing Amazon S3 storage classes. Preço fica em Amazon S3 pricing. Este artigo não cita valor em dólar. Isso muda por região e por data. O formato da troca não muda.

Frequência é o enredo inteiro

S3 Standard é o padrão. Sobe o objeto, não manda o header de storage class, você está em Standard. GET em milissegundo. Projetada para 99,99% de disponibilidade em pelo menos três Availability Zones. Sem duração mínima de armazenamento. Sem tamanho mínimo faturável. Você paga mais por GB guardado do que nas classes de arquivo, e não paga retrieval por GB numa leitura normal.

Use quando o objeto está no caminho da requisição: imagem de produto, artefato de sessão, o dataset que a API bate esta semana, qualquer coisa que você teria vergonha de restaurar de um arquivo enquanto o usuário espera.

Não use como sótão de dez anos. Tecnicamente dá. Você vai pagar Standard em dado que ninguém abre.

A armadilha do outro lado é jogar tudo numa classe infrequent ou Glacier porque a linha de storage é menor. Infrequent-access e Glacier somam cobrança de retrieval. Várias delas também faturam duração mínima e tamanho mínimo de objeto. Um prefixo cheio de arquivo miúdo que você reescreve toda semana é um encaixe ruim nessas classes, mesmo se você "quase nunca" pensa neles.

Quando você não conhece o padrão de acesso

S3 Intelligent-Tiering existe para a resposta honesta: "ainda não sei."

A AWS desenhou para acesso desconhecido, que muda, ou imprevisível. Ela observa os objetos e move entre tiers quando esfriam, e volta para Frequent Access se alguém lê de novo. Não tem taxa de retrieval dentro do Intelligent-Tiering. Você paga monitoramento e automação por objeto.

Tiers automáticos, pela documentação atual:

Frequent Access: onde o objeto novo começa.
Infrequent Access: depois de 30 dias seguidos sem acesso.
Archive Instant Access: depois de 90 dias seguidos sem acesso. Continua milissegundo, alto throughput.

Opcionais, só se a aplicação puder esperar:

Archive Access: assíncrono. Mesmo formato de performance do S3 Glacier Flexible Retrieval. Restore standard costuma levar de 3 a 5 horas.
Deep Archive Access: assíncrono. Mesmo formato de performance do S3 Glacier Deep Archive. Restore standard costuma ficar dentro de 12 horas.

Objeto menor que 128 KB não é monitorado. Fica em Frequent Access. Se o bucket é milhões de objetos miúdos, a taxa de monitoramento pode dominar e o auto-tiering nunca começa. Nesse caso Intelligent-Tiering é o default errado.

Encaixa bem: data lake, dump de analytics, prefixo de produto novo cujo padrão de leitura você só vai aprender em produção.

Encaixa mal: caminho quente que você já conhece (use Standard), ou arquivo conhecido que você não vai ler por anos (pule a taxa de monitoramento e coloque no Glacier de propósito).

Infrequent não é "Standard mais barato"

S3 Standard-IA e S3 One Zone-IA mantêm acesso em milissegundo, como o Standard. A AWS descreve como dado de vida longa que você toca mais ou menos uma vez por mês. As duas cobram retrieval por GB. As duas têm 30 dias de duração mínima e 128 KB de tamanho mínimo faturável. Apagar, sobrescrever ou transicionar antes de 30 dias ainda cobra o resto do mês, proporcional.

Por isso "mover para IA no segundo dia" pode sair mais caro do que deixar no Standard.

Standard-IA guarda o objeto em pelo menos três Availability Zones. Projetada para 99,9% de disponibilidade. Orientação da própria AWS: use para a cópia principal que você não consegue recriar. Backup que você pode precisar restaurar neste trimestre, dado antigo da aplicação que ainda precisa servir um GET em milissegundo, arquivo de compliance quieto mas não congelado.

One Zone-IA guarda o objeto numa Availability Zone só. Projetada para 99,5% de disponibilidade. Storage mais barato. Não aguenta a perda daquela zona. A AWS é explícita: use para dado que você reconstrói, ou para réplica, não como única cópia de algo que você não substitui.

Se o objeto é a única cópia das notas fiscais do ano passado, One Zone-IA é o tipo errado de barato.

Glacier são três produtos diferentes que compartilham o nome da montanha

Ainda se fala "joga no Glacier" como se fosse um botão. São três classes com três histórias de retrieval.

S3 Glacier Instant Retrieval. Preço de arquivo, GET em milissegundo. Feita para dado de vida longa que você talvez toque uma vez por trimestre. Mínimo de 90 dias. Mínimo faturável de 128 KB. Tem taxa de retrieval. O objeto fica disponível em tempo real. É a classe do "quase nunca abrimos, mas quando o jurídico pede, quer agora."

S3 Glacier Flexible Retrieval. O objeto está arquivado. Um GET normal não devolve os bytes até você restaurar. Mínimo de 90 dias. Metadado extra é cobrado por objeto (40 KB: 32 KB na tarifa Glacier Flexible, 8 KB na Standard, para o S3 ainda listar a key). Opções de retrieval na documentação atual de restore:

Opção	Tempo típico (Flexible Retrieval)
Expedited	1 a 5 minutos para objeto abaixo de 250 MB
Standard	3 a 5 horas (minutos a 5 horas com Batch Operations)
Bulk	5 a 12 horas, retrieve de menor custo

Bulk retrieval em objeto no Flexible Retrieval é gratuito. Expedited é caminho premium. Sem capacidade provisionada, Expedited pode ser recusado sob carga.

Use Flexible Retrieval para restore grande que você consegue planejar: dump anual, árvore de disaster recovery que você espera nunca tocar, arquivo em que "ainda hoje à tarde" serve.

S3 Glacier Deep Archive. Menor custo de storage desta família. Mínimo de 180 dias. Mesmo estilo de cobrança extra de metadado. Restaura primeiro, depois lê. Expedited não existe. Restore standard costuma ficar dentro de 12 horas (cerca de 9 a 12 horas com Batch Operations). Bulk costuma ficar dentro de 48 horas.

Use para dado que você guarda porque a política falou "sete anos", não porque um engenheiro vai dar curl numa terça.

Restore não é uma cópia sentada ao lado do arquivo para sempre. Você restaura por um número de dias, depois a cópia temporária expira. Se o runbook diz "é só dar GET no objeto", Deep Archive quebra esse runbook.

Uma decisão que cabe numa passada

Passe o objeto (ou o prefixo) por estas perguntas:

Alguma coisa trava neste GET? Requisição do usuário, API, etapa de pipeline. Fique no Standard, nos tiers instantâneos do Intelligent-Tiering, no Instant Retrieval ou no Express One Zone. Não coloque no Flexible Retrieval nem no Deep Archive.
Eu conheço o padrão de acesso? Não: Intelligent-Tiering, se o objeto for grande o bastante para monitorar. Sim, quente: Standard. Sim, frio mas instantâneo: Standard-IA ou Instant Retrieval. Sim, frio e assíncrono: Flexible Retrieval ou Deep Archive.
Consigo recriar se uma AZ sumir? Não: não use One Zone-IA (nem Express One Zone) como única cópia.
Quanto tempo vai viver, e qual o tamanho? Menos de 30 dias ou muitos objetos abaixo de 128 KB: IA e Instant Retrieval vão faturar como se o objeto fosse maior e mais velho do que é.
Quem paga se a gente ler o prefixo inteiro? Se um job mensal varre tudo, classe com preço de retrieval pode ganhar do Standard no storage e perder no job.

Classe	Acesso	Restore primeiro?	Duração mínima	Tamanho mínimo faturável	Zonas
Standard	Milissegundo, frequente	Não	Nenhuma	Nenhum	>= 3
Intelligent-Tiering	Milissegundo nos tiers automáticos	Só nos tiers opcionais de arquivo	Nenhuma	Nenhum (abaixo de 128 KB fica Frequent)	>= 3
Standard-IA	Milissegundo, infrequent	Não	30 dias	128 KB	>= 3
One Zone-IA	Milissegundo, infrequent	Não	30 dias	128 KB	1
Glacier Instant Retrieval	Milissegundo, raro	Não	90 dias	128 KB	>= 3
Glacier Flexible Retrieval	Minutos a horas	Sim	90 dias	Overhead de metadado	>= 3
Glacier Deep Archive	Horas	Sim	180 dias	Overhead de metadado	>= 3

A durabilidade projetada dessas classes é 99,999999999%, na mesma tabela de comparação. Disponibilidade não é o mesmo número. Standard e Flexible Retrieval (depois do restore) são projetadas para 99,99%. Standard-IA, Intelligent-Tiering e Instant Retrieval são projetadas para 99,9%. One Zone-IA é projetada para 99,5%.

Pilhas concretas de objeto

Lê todo dia. Thumbnail, config atual, working set de um serviço. S3 Standard. Lifecycle depois, não no primeiro dia.

Lê de vez em quando, ainda precisa de GET rápido. Relatório do trimestre passado, "baixar nota" de um pedido antigo. Standard-IA se o objeto for grande o bastante e for viver mais de 30 dias. Instant Retrieval se a leitura estiver mais perto de uma vez por trimestre do que uma vez por mês.

Backup. Se o restore é incêndio e precisa ser rápido, Standard-IA ou Instant Retrieval. Se o restore é um fim de semana planejado, Flexible Retrieval. Se o restore é "a gente guarda porque o audit pediu", Deep Archive. One Zone-IA só se outra região ou outro sistema já tiver uma cópia em que você confia.

Guardar por anos, quase nunca abrir. Deep Archive. Coloque um lifecycle no prefixo para não depender de alguém lembrar.

Job que pode varrer o prefixo. Prefira Standard ou Intelligent-Tiering. Taxa de retrieval em IA e Instant Retrieval é precificada para leitura rara, não para "reprocessamos o lake."

Acesso desconhecido, objeto que não é miúdo. Intelligent-Tiering como classe padrão no PutObject (x-amz-storage-class: INTELLIGENT_TIERING). Deixe os tiers opcionais assíncronos de arquivo desligados até a aplicação souber restaurar.

Mais uma classe se o problema de verdade for latência

A documentação atual também lista S3 Express One Zone: acesso em milissegundo de um dígito numa Availability Zone só, directory bucket, feito para compute sensível a latência perto do dado. Projetada para 99,95% de disponibilidade. Não substitui Standard numa API multi-AZ. Não é classe de arquivo. Se a dor é "Standard está lento demais neste loop apertado", leia aquela página. Se a dor é a fatura, é a página errada.

A AWS ainda documenta Reduced Redundancy Storage. A mesma página pede para não usar. Standard é o substituto.

Como o time costuma errar isso

Eles tratam uma classe como se fosse do bucket. Classe é por objeto. Regra de lifecycle move prefixo conforme envelhece: Standard por 30 dias, Standard-IA depois, Instant Retrieval ou Flexible Retrieval um ano mais tarde. Você não precisa de um bucket novo para cada classe.

Eles esquecem que overwrite e delete entram na duração mínima. Um prefixo "barato" de IA que é trocado a cada deploy não é infrequent. É Standard com taxa extra.

Eles tratam Glacier como pasta. O objeto continua no S3. Flexible Retrieval e Deep Archive só não fazem GET até o RestoreObject terminar.

Eles otimizam storage e ignoram listagem, monitoramento e restore. A taxa por objeto do Intelligent-Tiering e os bytes de metadado do Glacier são reais. Pesam mais quando o objeto é pequeno e numeroso.

Um default que você consegue defender

Caminho quente, conhecido: Standard.
Desconhecido, objeto que vale monitorar: Intelligent-Tiering, só os tiers automáticos.
Frio, precisa de GET agora, multi-AZ: Standard-IA ou Instant Retrieval, conforme a raridade da leitura.
Frio, precisa de GET agora, você reconstrói: One Zone-IA.
Frio, você aguenta esperar horas: Flexible Retrieval.
Frio, você aguenta esperar um dia, vai guardar por anos: Deep Archive.

Se ainda parecer chute, não chute Glacier. Chute Intelligent-Tiering ou Standard, e coloque um lifecycle quando tiver log de acesso de verdade. A classe cara é a que te surpreende quando alguém finalmente abre o objeto.

The cheapest S3 class is the one you never open

Rodolfo Henrique — Mon, 28 Sep 2026 22:32:20 +0000

A team moves a few million objects out of S3 Standard. Storage per gigabyte drops. Finance is happy. Two months later someone runs a job that reads most of the prefix. The invoice does not look cheaper. It looks like a retrieval fee with a storage class attached.

That is the usual S3 mistake. People optimize the price of keeping a byte. The bill also charges you for touching it, for deleting it too soon, and for objects that are smaller than the class wants to bill.

If you remember one thing: pick a class for how often the object is read, how fast the read must be, and whether you can rebuild the object if a zone disappears. The rest is matching those three answers to a class AWS already named.

Official reference: Understanding and managing Amazon S3 storage classes. Pricing lives on Amazon S3 pricing. This article does not quote dollar amounts. Those change by region and date. The shape of the trade-off does not.

Frequency is the whole plot

S3 Standard is the default. Upload an object, skip the storage-class header, you are in Standard. Millisecond GET. Designed for 99.99% availability across at least three Availability Zones. No minimum storage duration. No minimum billable object size. You pay more per GB stored than the archive classes, and you do not pay a per-GB retrieval fee for a normal read.

Use it when the object is part of the request path: product images, session artifacts, the dataset the API hits this week, anything you would be embarrassed to restore from an archive while a user waits.

Do not use it as a ten-year attic. You can, technically. You will pay Standard rates for data nobody opens.

The trap on the other side is dumping everything into an infrequent or Glacier class because the storage line is lower. Infrequent-access and Glacier classes add retrieval charges. Several of them also bill a minimum duration and a minimum object size. A prefix full of tiny files that you rewrite every week is a bad fit for those classes even if you "almost never" think about them.

When you do not know the access pattern

S3 Intelligent-Tiering exists for the honest answer: "I do not know yet."

AWS designed it for unknown, changing, or unpredictable access. It monitors objects and moves them between tiers as they go cold, then back to Frequent Access if they are read again. There are no retrieval fees inside Intelligent-Tiering. You pay a per-object monitoring and automation charge instead.

Automatic tiers, from the current docs:

Frequent Access: where new objects start.
Infrequent Access: after 30 consecutive days with no access.
Archive Instant Access: after 90 consecutive days with no access. Still millisecond, high-throughput access.

Optional, only if your app can wait:

Archive Access: asynchronous. Same performance shape as S3 Glacier Flexible Retrieval. Standard restore is typically 3 to 5 hours.
Deep Archive Access: asynchronous. Same performance shape as S3 Glacier Deep Archive. Standard restore is typically within 12 hours.

Objects smaller than 128 KB are not monitored. They stay in Frequent Access. If your bucket is millions of tiny objects, the monitoring fee can dominate and the auto-tiering never starts. In that case Intelligent-Tiering is the wrong default.

Good fit: a data lake, analytics dumps, a new product prefix whose read pattern you will only learn in production.

Bad fit: a well-known hot path (just use Standard), or a known archive you will not read for years (skip the monitoring fee and put it in Glacier on purpose).

Infrequent does not mean "cheaper Standard"

S3 Standard-IA and S3 One Zone-IA keep millisecond access, like Standard. AWS describes them as long-lived data you touch about once a month. Both charge a per-GB retrieval fee. Both have a 30-day minimum storage duration and a 128 KB minimum billable object size. Delete, overwrite, or transition before 30 days and you still pay the rest of the month, prorated.

That is why "move it to IA on day two" can cost more than leaving it in Standard.

Standard-IA stores the object across at least three Availability Zones. Designed for 99.9% availability. AWS's own guidance: use this for a primary copy you cannot recreate. Backups you might restore this quarter, older app data that still has to serve a GET in milliseconds, compliance files that are quiet but not frozen.

One Zone-IA stores the object in a single Availability Zone. Designed for 99.5% availability. Cheaper storage. It is not resilient to the loss of that zone. AWS is explicit: use it for data you can rebuild, or for replicas, not as the only copy of something you cannot replace.

If the object is the company's only copy of last year's invoices, One Zone-IA is the wrong kind of cheap.

Glacier is three different products that share a mountain name

People still say "put it in Glacier" as if that were one button. It is three classes with three retrieval stories.

S3 Glacier Instant Retrieval. Archive pricing, millisecond GET. Designed for long-lived data you might touch about once a quarter. 90-day minimum. 128 KB minimum billable size. Retrieval fees apply. The object is available in real time. This is the class for "we almost never open it, but when legal asks, they want it now."

S3 Glacier Flexible Retrieval. The object is archived. A normal GET does not return the bytes until you restore it. 90-day minimum. Extra metadata is billed per object (40 KB: 32 KB at the Glacier Flexible rate, 8 KB at Standard, so S3 can still list the key). Retrieval options from the current restore docs:

Option	Typical time (Flexible Retrieval)
Expedited	1 to 5 minutes for objects under 250 MB
Standard	3 to 5 hours (minutes to 5 hours with Batch Operations)
Bulk	5 to 12 hours, lowest-cost retrieve

Bulk retrievals are free for objects in Flexible Retrieval. Expedited is a premium path. Without provisioned capacity, Expedited can be refused under load.

Use Flexible Retrieval for large restores you can plan: yearly dumps, disaster-recovery trees you hope never to touch, archives where "this afternoon" is acceptable.

S3 Glacier Deep Archive. Lowest storage cost in this family. 180-day minimum. Same style of extra metadata billing. Restore first, then read. Expedited is not available. Standard restore is typically within 12 hours (about 9 to 12 hours with Batch Operations). Bulk is typically within 48 hours.

Use it for data you are keeping because a policy said "seven years," not because an engineer will curl it on a Tuesday.

A restore is not a copy sitting next to the archive forever. You restore for a number of days, then the temporary copy expires. If the runbook says "just GET the object," Deep Archive will fail that runbook.

A decision you can make in one pass

Walk the object (or the prefix) through these questions:

Will something block on this GET? User request, API, pipeline step. Stay in Standard, Intelligent-Tiering's instant tiers, Instant Retrieval, or Express One Zone. Do not put it in Flexible Retrieval or Deep Archive.
Do I know the access pattern? No: Intelligent-Tiering, if objects are large enough to monitor. Yes, hot: Standard. Yes, cold but instant: Standard-IA or Instant Retrieval. Yes, cold and async: Flexible Retrieval or Deep Archive.
Can I recreate it if one AZ is gone? No: do not use One Zone-IA (or Express One Zone) as the only copy.
How long will it live, and how big is it? Under 30 days or lots of sub-128 KB objects: IA and Instant Retrieval will bill you as if the objects were larger and older than they are.
Who pays if we read the whole prefix? If a monthly job scans everything, retrieval-priced classes can beat Standard on storage and lose on the job.

Class	Access	Restore first?	Min duration	Min billable size	Zones
Standard	Millisecond, frequent	No	None	None	>= 3
Intelligent-Tiering	Millisecond in the automatic tiers	Only in optional archive tiers	None	None (under 128 KB stays Frequent)	>= 3
Standard-IA	Millisecond, infrequent	No	30 days	128 KB	>= 3
One Zone-IA	Millisecond, infrequent	No	30 days	128 KB	1
Glacier Instant Retrieval	Millisecond, rare	No	90 days	128 KB	>= 3
Glacier Flexible Retrieval	Minutes to hours	Yes	90 days	Metadata overhead	>= 3
Glacier Deep Archive	Hours	Yes	180 days	Metadata overhead	>= 3

Designed-for durability for these classes is 99.999999999%, per the same comparison table. Availability is not the same number. Standard and Flexible Retrieval (after restore) are designed for 99.99%. Standard-IA, Intelligent-Tiering, and Instant Retrieval are designed for 99.9%. One Zone-IA is designed for 99.5%.

Concrete piles of objects

Read every day. Thumbnails, current config, the working set of a service. S3 Standard. Lifecycle later, not on day one.

Read now and then, still need a fast GET. Last quarter's reports, "download invoice" on an old order. Standard-IA if the objects are large enough and will live past 30 days. Instant Retrieval if the read is closer to once a quarter than once a month.

Backups. If restore is a fire drill and has to be fast, Standard-IA or Instant Retrieval. If restore is a planned weekend, Flexible Retrieval. If restore is "we keep this because audit said so," Deep Archive. One Zone-IA only if another region or another system already has a copy you trust.

Keep it for years, almost never open it. Deep Archive. Put a lifecycle on the prefix so you do not rely on a human remembering.

A job that might scan the prefix. Prefer Standard or Intelligent-Tiering. Retrieval fees on IA and Instant Retrieval are priced for rare reads, not for "we reprocessed the lake."

Unknown access, objects not tiny. Intelligent-Tiering as the default class on PutObject (x-amz-storage-class: INTELLIGENT_TIERING). Leave the optional async archive tiers off until the application can restore.

One more class if latency is the actual problem

The current docs also list S3 Express One Zone: single-digit millisecond access in one Availability Zone, directory buckets, built for latency-sensitive compute next to the data. Designed for 99.95% availability. Not a replacement for Standard in a multi-AZ API. Not an archive class. If the pain is "Standard is too slow for this tight loop," read that page. If the pain is the bill, it is the wrong page.

AWS still documents Reduced Redundancy Storage. The same page says not to use it. Standard is the replacement.

How teams usually get this wrong

They set one class on the bucket in their head. Classes are per object. Lifecycle rules move prefixes as they age: Standard for 30 days, Standard-IA after that, Instant Retrieval or Flexible Retrieval a year later. You do not need a new bucket for each class.

They forget that overwrite and delete count toward minimum duration. A "cheap" IA prefix that is replaced every deploy is not infrequent. It is Standard with extra fees.

They treat Glacier as a folder. The object stays in S3. Flexible Retrieval and Deep Archive just will not GET until RestoreObject finishes.

They optimize storage and ignore listing, monitoring, and restore. Intelligent-Tiering's per-object fee and Glacier's metadata bytes are real. They matter most when objects are small and numerous.

A default you can defend

Hot path, known: Standard.
Unknown, objects worth monitoring: Intelligent-Tiering, automatic tiers only.
Cold, must GET now, multi-AZ: Standard-IA or Instant Retrieval, depending on how rare the read is.
Cold, must GET now, you can rebuild it: One Zone-IA.
Cold, you can wait hours: Flexible Retrieval.
Cold, you can wait a day, you will keep it for years: Deep Archive.

If that still feels like a guess, do not guess Glacier. Guess Intelligent-Tiering or Standard, then add a lifecycle when you have a real access log. The expensive class is the one that surprises you when someone finally opens the object.

O mesmo pedido chegou quatro vezes. O SQS não estava errado

Rodolfo Henrique — Sun, 20 Sep 2026 21:09:28 +0000

Este artigo é a continuação do lab de visibility timeout no SQS.

No primeiro lab eu tentei fabricar uma duplicata atrasando o relógio da fila. Não funcionou. A Lambda estende o visibility timeout enquanto processa. O alvo era o relógio. O alvo errado.

O que ficou em aberto era outra coisa: o produtor. E se eu mesmo mandar o mesmo pedido duas, quatro, dez vezes?

Foi isso que eu fiz. Abaixo está o que subi, por que subi, e o que cada print mostra.

O que eu queria descobrir

O Amazon SQS (Simple Queue Service) é uma fila. Você coloca uma mensagem. Um consumidor tira a mensagem e trabalha.

Fila standard entrega pelo menos uma vez. A documentação da Lambda diz a mesma coisa do outro lado: o event source mapping (a ligação fila → função) também processa pelo menos uma vez. O código precisa ser idempotente: processar o mesmo pedido uma vez ou dez vezes deixa o mesmo resultado.

Isso cobre a mensagem. Não cobre o pedido.

Imagine o checkout. O usuário clica em pagar. A rede falha. Ele clica de novo. O backend manda duas mensagens. O SQS aceita as duas. Cada uma ganha um MessageId novo. Para a fila, são dois recados. Para o caixa, é o mesmo ORDER-003 de 150 reais.

Pergunta do lab:

Se várias mensagens representam o mesmo pedido, o worker cobra uma vez ou cobra cada mensagem?

Dois identificadores. Não misture.

Identificador	Quem cria	O que significa
`MessageId`	O SQS, a cada `SendMessage`	Aquela cópia na fila
`orderId`	Você, no JSON do body	O pedido de negócio

O MessageId nomeia a mensagem. O orderId nomeia o pedido. Idempotência neste lab trava o pedido, não a mensagem.

O que eu subi na AWS

Tudo em us-east-1. Sem fila FIFO. Sem gateway de pagamento. A "cobrança" é um log chamado charge_applied. Se esse log aparece, o lab considera que o caixa rodou.

PowerShell (send.ps1)
        |
        v
SQS standard: aws-lab-sqs-idempotency
        |
        |  uma mensagem por invocação (batch size 1)
        v
Lambda: aws-lab-sqs-idempotency-worker
        |
        +-- CloudWatch Logs  (o que aconteceu)
        +-- DynamoDB         (a trava do orderId)

Peça	Nome	Para que serve
Fila	`aws-lab-sqs-idempotency`	Recebe as cópias do pedido
Função	`aws-lab-sqs-idempotency-worker`	Lê a fila e "cobra"
Tabela	`aws-lab-sqs-idempotency`	Guarda o `orderId` com um write condicional
Logs	`/aws/lambda/aws-lab-sqs-idempotency-worker`	Evidência no Insights

A função tem um interruptor:

IDEMPOTENCY=0: chegou mensagem, cobra. Sem perguntar nada.
IDEMPOTENCY=1: antes de cobrar, tenta gravar o orderId no DynamoDB. Se o item já existe, não cobra.

Por que batch size 1: cada mensagem vira uma invocação. Assim duas cópias podem correr ao mesmo tempo, em vez de cair no mesmo lote.

Por que a guarda não é um `if`

Este código parece idempotência e não é:

if (exists) {
  return;
}

Duas Lambdas leem ao mesmo tempo. As duas veem "não existe". As duas cobram. As duas gravam depois. A verificação e a reserva precisam ser a mesma operação.

No DynamoDB isso é um PutItem com condição: "grave este orderId só se ele ainda não existir".

await ddb.send(
  new PutItemCommand({
    TableName: tableName,
    Item: {
      orderId: { S: orderId },
      status: { S: "CLAIMED" },
      messageId: { S: messageId },
      requestId: { S: requestId },
      claimedAt: { S: new Date().toISOString() },
    },
    ConditionExpression: "attribute_not_exists(orderId)",
  }),
);

Leitura do código, em português:

Tente criar o item com PK orderId e status CLAIMED.
Se ninguém gravou essa PK ainda, você ganhou (claim_won). Aí você cobra e marca COMPLETED.
Se a PK já existe, o DynamoDB recusa com ConditionalCheckFailedException. Você perdeu (claim_lost), loga skip_duplicate e não cobra.

CLAIMED é reserva, não recibo. Eu não marco COMPLETED antes de cobrar. Se eu marcasse "já processado" e a cobrança falhasse, o retry pularia um pedido que nunca saiu.

Experimento 1: interruptor desligado

O que eu fiz: subi o lab com IDEMPOTENCY=0 e mandei mensagens do mesmo pedido.

Por que: para ver o comportamento sem trava. Se o worker cobra cada mensagem, o Insights tem que mostrar mais cobranças do que pedidos.

O que eu vi no Logs Insights (Analytics de logs, visão Tabelas de pesquisa), numa janela em que só existem três tipos de evento:

eventType	O que significa	n
`process_start`	A Lambda começou a tratar a mensagem	4
`charge_applied`	O caixa rodou	4
`process_end`	A invocação terminou	4

Não tem claim_won nem skip_duplicate. A guarda estava desligada.

Olhe a tabela de baixo: três linhas, todas com 4. Quatro invocações, quatro cobranças.

Depois eu contei só o efeito. A consulta pega charge_applied e pergunta: quantas cobranças, quantos orderId distintos, quantos MessageId distintos?

fields @timestamp, @message
| filter @message like /"type":"charge_applied"/
| parse @message /"orderId":"(?<orderId>[^"]+)"/
| parse @message /"messageId":"(?<messageId>[^"]+)"/
| stats count(*) as charges, count_distinct(orderId) as pedidos, count_distinct(messageId) as mensagens

charges	pedidos	mensagens
4	1	4

Quatro MessageId. Um orderId. Quatro cobranças. A fila tratou quatro recados. O caixa tratou o mesmo pedido quatro vezes.

O mesmo número aparece em outro recorte da mesma consulta.

Para o SQS, o teste passou: quatro mensagens, quatro invocações, zero erro. Para o negócio, o cliente foi cobrado quatro vezes.

O que idempotência quis dizer aqui

Caminho que eu usei:

orderId (o pedido) → mensagem (MessageId) → Lambda → efeito (charge_applied)

Idempotente: aplicar ORDER-003 uma vez ou dez vezes deixa uma cobrança de 150.

Não é "o SQS joga a segunda mensagem fora". O SQS pode (e neste lab, deve) entregar as dez. O destino é que recusa o segundo efeito.

Experimento 2: interruptor ligado, dez cópias

O que eu fiz:

destroy do lab antigo e deploy de novo.
Esperei a Lambda ficar ativa e o event source mapping em Enabled, batch size 1.
.\set-idempotency.ps1 -Enabled 1. A variável da função ficou IDEMPOTENCY=1.
Mandei o mesmo pedido dez vezes:

.\send.ps1 -OrderId ORDER-003 -Copies 10

O body impresso:

{"orderId":"ORDER-003","customerId":"CUSTOMER-123","amount":150.00}

Dez linhas. Dez MessageId diferentes. orderId=ORDER-003 em todas.

O que observar: a fila não juntou nada. Dez recados. Um pedido.

Por que dez, e não duas: para forçar várias invocações no mesmo orderId com a guarda ligada.

O que o Insights mostrou nesse pedido

Filtrei orderId = "ORDER-003". Vieram 20 correspondências, nestes tipos:

process_start, claim_lost, skip_duplicate, process_end.

Leia assim: a mensagem chegou, tentou gravar a PK, perdeu, logou skip e encerrou. Sem nova cobrança nesse caminho.

A linha a linha é o mesmo filtro, evento por evento. Só ORDER-003. claim_lost e skip_duplicate andam juntos. Os MessageId mudam. O pedido não.

O que a tabela mostrou nesse pedido

O get-item de ORDER-003 devolveu um item:

Campo	Valor	Por que importa
`orderId`	`ORDER-003`	A chave do pedido
`status`	`COMPLETED`	A reserva virou recibo
`messageId` / `completedMessageId`	`73fca7ac-78e9-4ea4-a1bf-71a92e2fbda8`	É o envio 1/10 daquela corrida
`claimedAt`	`2026-09-20T20:58:23.240Z`	Quando a primeira cópia ganhou o PutItem
`completedAt`	`2026-09-20T20:58:28.142Z`	Cerca de 5 s depois. O worker espera 4 s (`WORK_MS=4000`) e então marca completed
scan	1 item	Não nasceu um item por mensagem

A fila aceitou dez MessageId. O destino ficou com um ORDER-003 em COMPLETED. As cópias no Insights perderam o claim e não cobraram.

Os prints do grupo inteiro (com a guarda já visível)

No log group sem filtrar orderId, numa janela em que os eventos de claim já existem:

eventType	n
`process_end`	6
`charge_applied`	5
`skip_duplicate`	1
`claim_lost`	2
`process_start`	2
`claim_won`	1

Isso mostra a guarda em ação no grupo: alguém ganhou o claim, alguém perdeu, alguém pulou a cobrança.

A consulta de cobranças no grupo inteiro, recorte mais largo: 7 charges, 3 pedidos, 7 mensagens. São vários orderId no mesmo log group.

Lado a lado

	Sem guarda	Com guarda, pedido `ORDER-003`
O que eu mandei	várias mensagens do mesmo pedido	10 `SendMessage` com o mesmo `ORDER-003`
O que a fila fez	aceitou cada `MessageId`	aceitou cada `MessageId`
O que o Insights mostrou	4 start, 4 charge, 4 end	20 eventos de start / `claim_lost` / `skip_duplicate` / end
O que a tabela mostrou	a guarda estava desligada	um item `ORDER-003` / `COMPLETED`
Efeito no caixa	4 cobranças para 1 `orderId`	um pedido reservado e concluído; as cópias visíveis não cobraram

A fila fez o trabalho dela nas duas vezes. A diferença está no destino.

O que este lab não promete

SQS standard não vira exactly-once porque você usou Lambda. Continua at-least-once.
if (exists) return não é a guarda. Duas leituras ao mesmo tempo furam isso.
FIFO com MessageDeduplicationId ajuda a não enviar a mesma mensagem de novo por alguns minutos. Não substitui a tabela no destino quando você quer enfileirar o mesmo pedido várias vezes.

O que eu levo

MessageId é a mensagem. orderId é o pedido. A trava vai no pedido.
Sem guarda, quatro mensagens do mesmo orderId foram quatro charge_applied.
A reserva é o PutItem com attribute_not_exists(orderId). Quem perde loga claim_lost e skip_duplicate e não cobra.
Idempotência neste desenho é: a fila pode entregar dez vezes; o caixa do pedido roda uma.

DEV Community: Rodolfo Henrique

The 3-2-1-1-0 backup rule. We had everything except the zero

The 3-2-1-1-0 backup rule. We had everything except the zero

What fails when a number is missing

The green job lies by omission

What a recovery test has to show

Does the backup work when you need it?

A regra de backup 3-2-1-1-0. Tínhamos tudo, menos o zero

A regra de backup 3-2-1-1-0. Tínhamos tudo, menos o zero

O que falha quando falta um número

O job verde mente por omissão

O que o teste de recuperação precisa mostrar

O backup funciona quando você precisa dele?

A classe mais barata do S3 é a que você nunca abre

A classe mais barata do S3 é a que você nunca abre

Frequência é o enredo inteiro

Quando você não conhece o padrão de acesso

Infrequent não é "Standard mais barato"

Glacier são três produtos diferentes que compartilham o nome da montanha

Uma decisão que cabe numa passada

Pilhas concretas de objeto

Mais uma classe se o problema de verdade for latência

Como o time costuma errar isso

Um default que você consegue defender

The cheapest S3 class is the one you never open

Frequency is the whole plot

When you do not know the access pattern

Infrequent does not mean "cheaper Standard"

Glacier is three different products that share a mountain name

A decision you can make in one pass

Concrete piles of objects

One more class if latency is the actual problem

How teams usually get this wrong

A default you can defend

O mesmo pedido chegou quatro vezes. O SQS não estava errado

O que eu queria descobrir

Dois identificadores. Não misture.

O que eu subi na AWS

Por que a guarda não é um if

Experimento 1: interruptor desligado

O que idempotência quis dizer aqui

Experimento 2: interruptor ligado, dez cópias

O que o Insights mostrou nesse pedido

O que a tabela mostrou nesse pedido

Os prints do grupo inteiro (com a guarda já visível)

Lado a lado

O que este lab não promete

O que eu levo

Por que a guarda não é um `if`