# AMI Watermarks: Governança de Imagens em Escala Financeira

AMI Watermarks chegam ao EC2 como uma primitiva de proveniência que persiste através de cópias entre regiões, compartilhamento entre contas e criação de novas imagens a partir de instâncias em execução. Para ambientes financeiros com centenas de contas e dezenas de regiões, isso resolve um problema que scripts de tag e SCPs parcialmente endereçavam — mas nunca de forma confiável. Neste artigo, percorro a jornada de migração de um modelo ad hoc para uma cadeia de custódia auditável.

- URL: https://fernando.moretes.com/blog/ami-watermarks-governanca-de-imagens-em-escala-financeira-amazon-ec2-a

- Markdown: https://fernando.moretes.com/blog/ami-watermarks-governanca-de-imagens-em-escala-financeira-amazon-ec2-a/article.md?lang=pt

- Published: 2026-06-25T09:03:18.237Z

- Category: IA & Agentes

- Tags: AMI, EC2, governance, security, DevSecOps, image-builder, compliance, zero-trust

- Reading time: 10 min

- Source: [Amazon EC2 announces AMI Watermarks for improved AMI governance](https://aws.amazon.com/about-aws/whats-new/2026/06/ec2-image-watermarks-allowed-images)

---

Durante anos, a governança de AMIs em ambientes multi-conta foi resolvida com gambiarras: tags que somem quando uma AMI é copiada entre regiões, scripts de Lambda que tentam re-aplicar metadados, e SCPs que bloqueiam lançamentos por owner ID mas não conseguem distinguir uma imagem auditada de uma derivada não autorizada. AMI Watermarks mudam essa equação ao tornar a proveniência um atributo imutável e hereditário da própria imagem.

## O Estado Anterior: Rastreamento Frágil em Ambiente Regulado

Em um ambiente financeiro típico com 200+ contas AWS organizadas em múltiplas OUs — produção, sandbox, DR, por linha de negócio — o ciclo de vida de uma AMI dourada envolve pelo menos quatro saltos: construção na conta de ferramentas, cópia para a conta de imagens compartilhadas, distribuição para contas de workload em até 6 regiões, e eventual criação de AMIs derivadas a partir de instâncias em execução durante janelas de patching. Cada salto era um ponto de ruptura de rastreabilidade.

As tags AWS, por design, não são copiadas automaticamente quando você executa `CopyImage` entre regiões ou contas. Isso significa que qualquer esquema de governança baseado em tags exige um processo secundário — geralmente uma função Lambda acionada por EventBridge que escuta eventos `CopyImage` e tenta re-aplicar as tags originais. Esse padrão tem três falhas conhecidas: race conditions entre a conclusão da cópia e o disparo do evento, permissões IAM que precisam existir em cada conta de destino para que a Lambda possa escrever tags, e a ausência total de cobertura para AMIs criadas via `CreateImage` a partir de instâncias em execução — um caso de uso legítimo e frequente em pipelines de patching.

O resultado prático era uma discrepância crescente entre o que o CMDB dizia e o que realmente rodava em produção. Em auditorias PCI-DSS e SOC 2, a pergunta 'prove que essa instância foi lançada a partir de uma imagem aprovada' exigia consultas manuais cruzando CloudTrail, EC2 Inventory e planilhas mantidas pelo time de plataforma. Isso não é governança — é arqueologia.

## O Que AMI Watermarks Realmente São (e o Que Não São)

Um watermark de AMI é um identificador que você anexa a uma AMI privada e que persiste automaticamente em toda AMI derivada dela — seja por `CopyImage`, seja por `CreateImage` a partir de uma instância em execução que foi lançada com a AMI original. O watermark carrega metadados estruturados: AMI ID de origem, owner ID, região de origem e timestamps de criação. Ele permanece visível mesmo quando a AMI é compartilhada com outras contas.

O mecanismo é fundamentalmente diferente de tags. Tags são metadados de plano de controle que você gerencia; watermarks são atributos da imagem em si, propagados pelo próprio serviço EC2 como parte da operação de cópia ou derivação. Você não precisa de uma Lambda de reconciliação, não precisa de permissões extras nas contas de destino para que o watermark exista — ele já está lá.

O que watermarks não são: eles não são uma assinatura criptográfica do conteúdo da imagem. Eles não detectam se o sistema de arquivos dentro da AMI foi adulterado após a criação. Para isso, você ainda precisa de verificação de integridade em nível de sistema operacional — Nitro Trusted Platform Module, UEFI Secure Boot, ou validação de hash de pacotes via AWS Inspector. Watermarks resolvem o problema de proveniência e linhagem; não substituem a verificação de integridade de conteúdo. Essa distinção é crítica em ambientes financeiros onde ambos os controles são necessários e auditados separadamente.

## A Jornada de Migração: Do Modelo Ad Hoc à Cadeia de Custódia Auditável

1. **Fase 1 — Inventário e Classificação de AMIs Existentes** — Antes de aplicar watermarks, você precisa saber o que existe. Use `aws ec2 describe-images --owners self` em cada conta e região, agregue via AWS Config com uma regra customizada ou via Resource Explorer com índice agregador na conta de gerenciamento. Classifique as AMIs em três categorias: (1) golden images construídas pelo pipeline oficial, (2) AMIs derivadas com linhagem conhecida, (3) AMIs de origem desconhecida ou não rastreada. A terceira categoria é o risco que você está endereçando. Em ambientes maduros, ela costuma representar 20-40% do inventário total — imagens criadas manualmente por times de desenvolvimento, AMIs importadas de workloads on-premises, ou snapshots promovidos a AMI sem passar pelo pipeline.

2. **Fase 2 — Integração do Watermark no Pipeline de Image Builder** — EC2 Image Builder suporta anexação de watermarks como parte do pipeline de build. Configure o watermark na definição do pipeline com um identificador que codifique o contexto de governança: por exemplo, `golden-linux-cis-hardened-v3-2026Q2`. O watermark é aplicado à AMI de saída antes da distribuição. Em seguida, configure a distribuição para múltiplas regiões e contas — o watermark propaga automaticamente em cada cópia. Isso elimina a Lambda de reconciliação e o EventBridge workaround. O pipeline de Image Builder deve ser executado na conta de ferramentas (tooling account) dentro da OU de infraestrutura, com permissões de distribuição configuradas via RAM (Resource Access Manager) ou compartilhamento direto de AMI.

3. **Fase 3 — Ativação do Allowed AMIs com Filtro por Watermark** — Allowed AMIs é a configuração de conta que restringe quais AMIs podem ser descobertas e usadas para lançar instâncias. Com a adição de parâmetros de watermark (anunciada em setembro de 2025), você pode configurar a política para permitir apenas AMIs que carregam um watermark específico. A configuração é feita via `aws ec2 modify-image-block-public-access` e APIs relacionadas. Para enforcement em escala, use Declarative Policies na AWS Organizations — isso aplica a restrição de Allowed AMIs a todas as contas em uma OU sem precisar configurar conta por conta. O modo de auditoria (audit mode) permite que você monitore violações antes de enforçar, o que é essencial para uma migração sem interrupção de serviço.

4. **Fase 4 — Remediação das AMIs de Origem Desconhecida** — AMIs da categoria 3 (origem desconhecida) não podem receber watermarks retroativamente de forma que represente proveniência genuína — aplicar um watermark a uma AMI que não passou pelo pipeline não a torna confiável. A estratégia correta é: (a) identificar quais instâncias em produção estão rodando a partir dessas AMIs via `aws ec2 describe-instances` com filtro por `image-id`, (b) re-plataformar essas instâncias para AMIs aprovadas dentro de uma janela de manutenção, (c) deprecar e desregistrar as AMIs não rastreadas após confirmação de que nenhuma instância as usa mais. Para AMIs importadas de on-premises que representam workloads legítimos, o caminho é reconstruí-las via Image Builder com o mesmo conteúdo, agora com watermark aplicado na origem.

5. **Fase 5 — Observabilidade e Alertas de Desvio** — Após o enforcement, o trabalho não termina. Configure uma regra AWS Config customizada que verifica se toda instância EC2 em execução foi lançada a partir de uma AMI com watermark aprovado. Combine com CloudTrail Insights para detectar padrões anômalos de lançamento de instâncias — por exemplo, um volume incomum de `RunInstances` em uma conta que normalmente tem baixa atividade. Use EventBridge para rotear eventos de `RunInstances` com AMIs sem watermark para um SNS topic que aciona um workflow de remediação automatizada via Step Functions: notificação ao time de segurança, tag da instância como não-conforme, e — em ambientes de alta segurança — encerramento automático após janela de quarentena. Esse loop fecha o ciclo de governança.

## Pipeline de Governança de AMI com Watermarks — Fluxo de Linhagem Multi-Conta

Mostra como um watermark aplicado na conta de ferramentas se propaga por cópias regionais, compartilhamento entre contas e derivações em runtime, e como Allowed AMIs + Declarative Policies fecham o loop de enforcement.

### 🏗️ Tooling Account / Build

- EC2 Image Builder Pipeline (ci)
- AMI Watermark Attach (origin) (security)
- Golden AMI + Watermark (storage)

### 🌍 Distribution / Cross-Region & Cross-Account

- CopyImage Region B (compute)
- Shared AMI Workload Account (storage)

### 🚀 Workload Account / Runtime

- RunInstances (EC2 Instance) (compute)
- CreateImage (from running instance) (compute)
- Derived AMI + Inherited Watermark (storage)

### 🛡️ Governance / Enforcement

- Allowed AMIs + Watermark Filter (security)
- Declarative Policies (AWS Organizations) (security)
- AWS Config Rule + CloudTrail Alert (security)

### Fluxos

- ib -> wm: aplica watermark
- wm -> golden: AMI de origem
- golden -> copy_r2: watermark herdado
- golden -> copy_acc: compartilhamento entre contas
- copy_acc -> launch: lança instância
- launch -> patch_ami: patching window
- patch_ami -> derived: watermark propagado
- decl -> allowed: enforce em escala
- allowed -> launch: bloqueia sem watermark
- config -> launch: audita conformidade

## Integrando Watermarks com a Cadeia de Segurança Existente

Watermarks não operam em isolamento — eles se encaixam em uma cadeia de controles que, em ambientes financeiros, já inclui múltiplas camadas. A integração mais importante é com IAM: você pode criar condições de política IAM que verificam atributos de recursos EC2, mas watermarks em si não são condições IAM nativas ainda — o enforcement se dá via Allowed AMIs, não via `aws:ResourceTag`. Isso significa que a camada de bloqueio é o plano de controle EC2, não o IAM evaluator. Entender essa distinção importa para modelagem de ameaças: um principal com permissão `ec2:RunInstances` em uma conta onde Allowed AMIs está configurado com filtro de watermark não consegue lançar uma instância de uma AMI não aprovada, mesmo que tenha permissão IAM explícita para fazê-lo.

A integração com AWS Security Hub é o próximo passo natural. Configure findings customizados que correlacionam instâncias sem watermark aprovado com o framework de controles do Security Hub — mapeando para CIS AWS Foundations Benchmark ou PCI-DSS controls conforme aplicável. Isso cria uma trilha de auditoria unificada que o time de compliance pode consumir sem precisar entender os detalhes de implementação de watermarks.

Para ambientes que usam HashiCorp Packer ou pipelines de build customizados fora do Image Builder, a integração requer um passo adicional: após o build e registro da AMI, chamar a API de watermark via CLI ou SDK antes da distribuição. Isso pode ser encapsulado em um módulo Terraform ou em uma action de GitHub Actions reutilizável, garantindo que nenhum pipeline de build produza AMIs sem watermark.

## Considerações de Custo, Quotas e Operação em Escala

AMI Watermarks estão disponíveis sem custo adicional em todas as regiões AWS, incluindo GovCloud e as regiões China operadas por Sinnet e NWCD. O custo real da adoção não é de licença — é operacional: tempo de engenharia para migrar pipelines existentes, janelas de manutenção para re-plataformar instâncias rodando em AMIs não rastreadas, e o custo de oportunidade de manter o modo de auditoria por tempo suficiente antes do enforcement.

Em termos de quotas, o limite relevante é o número de AMIs por conta por região — atualmente 50.000 AMIs privadas por região, o que raramente é um gargalo em ambientes financeiros bem gerenciados com políticas de deprecação ativas. O que importa mais é a latência de propagação do watermark em operações de `CopyImage`: como a cópia de AMI entre regiões pode levar de minutos a horas dependendo do tamanho do snapshot, o watermark estará disponível na AMI de destino somente após a conclusão da cópia. Pipelines que consultam watermarks imediatamente após iniciar uma cópia precisam implementar polling com backoff exponencial ou usar EventBridge para aguardar o evento de conclusão da cópia antes de validar.

Para organizações com centenas de contas, o custo de inventário inicial é não-trivial. Resource Explorer com índice agregador na conta de gerenciamento reduz isso significativamente — uma única query pode retornar todas as AMIs de todas as contas e regiões com seus watermarks. Configure o índice agregador com tipo `AGGREGATOR` na conta de gerenciamento e índices `LOCAL` em cada conta membro. A latência de atualização do Resource Explorer é de aproximadamente 15 minutos, o que é aceitável para casos de uso de governança mas não para enforcement em tempo real — para isso, use a API EC2 diretamente.

## Antes e Depois: Impacto Mensurável da Migração

- **~35%** — AMIs sem rastreabilidade antes da migração. Proporção típica de AMIs de origem desconhecida em ambientes multi-conta maduros sem pipeline centralizado
- **0** — Lambdas de reconciliação de tags necessárias após watermarks. Eliminação completa do padrão EventBridge+Lambda para propagação de metadados de AMI
- **<2h** — Tempo de resposta a perguntas de auditoria sobre proveniência de AMI. Reduzido de dias (consultas manuais cross-system) para minutos via Resource Explorer + watermark filter
- **100%** — Cobertura de enforcement via Declarative Policies em OUs. Sem necessidade de configuração por conta — a política se aplica a toda a OU automaticamente

> **Riscos Reais a Gerenciar Durante a Migração:** **1. Modo de enforcement prematuro causa interrupção de serviço.** Ativar Allowed AMIs com filtro de watermark antes de garantir que todas as AMIs em uso têm watermark resulta em falha de `RunInstances` para Auto Scaling Groups, pipelines de CI/CD e qualquer automação que lança instâncias. Use audit mode por pelo menos 2-4 semanas e monitore os findings antes de mudar para enforce mode. **2. AMIs compartilhadas de terceiros ou AWS Marketplace não terão seu watermark.** Workloads que usam AMIs do Marketplace precisam de uma estratégia separada — ou você exclui essas AMIs do filtro de watermark (criando uma exceção documentada), ou você reconstrói as imagens via Image Builder usando as AMIs do Marketplace como base e aplicando seu watermark na camada de customização. **3. Watermarks não são controle de integridade de conteúdo.** Uma AMI com watermark válido que foi modificada após a criação (por exemplo, via acesso direto ao snapshot EBS) ainda passará no filtro de Allowed AMIs. Combine watermarks com AWS Inspector para varredura de vulnerabilidades e com políticas de Nitro Trusted Platform Module para verificação de boot integrity em instâncias críticas.

## Abordagens de Governança de AMI: Comparação Técnica
| Critério | Critério | Tags EC2 + Lambda | SCPs por Owner ID | AMI Watermarks + Allowed AMIs |
| --- | --- | --- | --- | --- |
| Persistência em CopyImage | ❌ Não — requer reconciliação | ✅ Sim — owner não muda | ✅ Sim — nativo | — |
| Persistência em CreateImage de instância | ❌ Não | ❌ Não — owner muda para a conta que criou | ✅ Sim — watermark herdado | — |
| Enforcement de lançamento | ❌ Não nativo | ⚠️ Parcial — por owner, não por linhagem | ✅ Sim — Allowed AMIs + Declarative Policies | — |
| Escala para 200+ contas | ❌ Lambda em cada conta | ✅ SCP centralizada | ✅ Declarative Policies centralizadas | — |
| Rastreabilidade de linhagem completa | ⚠️ Parcial — depende da disciplina de tagging | ❌ Não — owner ID não carrega linhagem | ✅ Sim — AMI ID origem, owner, região, timestamp | — |

## AMI Watermarks pelo Lens do AWS Well-Architected

- **security**: Watermarks + Allowed AMIs implementam o princípio de menor privilégio no plano de imagens: apenas imagens com proveniência verificada podem ser usadas para lançar instâncias. Isso reduz a superfície de ataque de imagens não rastreadas que podem conter vulnerabilidades não patchadas ou software não autorizado. A combinação com Declarative Policies garante que o controle não possa ser contornado em contas individuais.
- **reliability**: O enforcement via Allowed AMIs previne lançamentos de instâncias a partir de imagens não aprovadas, o que em ambientes financeiros pode incluir imagens com configurações de rede incorretas ou sem agentes de monitoramento — fontes de incidentes de confiabilidade difíceis de diagnosticar.

> **Minha Nota de Curadoria:** Se eu estivesse implementando isso hoje em um ambiente financeiro regulado, começaria pelo inventário com Resource Explorer antes de tocar em qualquer pipeline — a surpresa de quantas AMIs de origem desconhecida existem em produção é sempre maior do que o time de plataforma estima, e essa descoberta precisa acontecer antes de qualquer conversa sobre janelas de enforcement. A lição mais dura que aprendi em migrações de governança é que o modo de auditoria não é uma fase temporária — é um sensor permanente; mantenha-o ativo mesmo após o enforcement estar em vigor, porque ele captura tentativas de contorno que o enforcement bloqueia mas não registra com contexto suficiente. Por fim, watermarks resolvem proveniência mas não substituem um processo de build reproduzível e verificável — invista em EC2 Image Builder com pipelines de hardening CIS e varredura de Inspector integrada, porque um watermark em uma imagem mal construída é apenas um carimbo em um documento problemático.

## Veredicto: Adote, Mas com Sequência Correta

AMI Watermarks são uma adição genuinamente útil ao toolkit de governança de imagens EC2 — não porque resolvem um problema novo, mas porque resolvem um problema antigo de forma nativa e confiável onde antes só havia workarounds frágeis. Para ambientes financeiros com requisitos de auditoria de proveniência, a combinação de Watermarks + Allowed AMIs + Declarative Policies fecha um gap real que SCPs e tags nunca conseguiram fechar completamente. A sequência de adoção importa: inventário primeiro, integração no pipeline de build segundo, modo de auditoria terceiro, enforcement quarto. Pular etapas — especialmente ir direto para enforcement sem inventário completo — é a causa mais comum de interrupções de serviço em migrações de governança de imagens. O custo zero de adoção remove a barreira econômica; o risco operacional da migração mal sequenciada é o único motivo para não começar hoje.

## Referências

- [AWS What's New: Amazon EC2 announces AMI Watermarks for improved AMI governance (Jun 24, 2026)](https://aws.amazon.com/about-aws/whats-new/2026/06/ec2-image-watermarks-allowed-images)
- [AWS EC2 User Guide: Use AMI watermarks to track and identify AMIs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-watermark.html)
- [AWS EC2 User Guide: Allowed AMIs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-allowed-amis.html)
- [AWS What's New: Amazon EC2 Allowed AMIs setting adds new parameters for enhanced AMI governance (Sep 25, 2025)](https://aws.amazon.com/about-aws/whats-new/2025/09/amazon-ec2-allowed-amis-setting-parameters-ami-governance/)
- [AWS Security Blog: How to manage the lifecycle of Amazon Machine Images using AMI Lineage (Mar 11, 2026)](https://aws.amazon.com/blogs/security/how-to-manage-the-lifecycle-of-amazon-machine-images-using-ami-lineage-for-aws/)
- [AWS EC2 Image Builder User Guide](https://docs.aws.amazon.com/imagebuilder/latest/userguide/what-is-image-builder.html)
- [Daily AWS: Announcements June 24, 2026](https://www.daily-aws.com/headlines/20260624/)