Uma golden AMI (ou «imagem dourada») é uma Amazon Machine Image pré-configurada, endurecida e validada que serve de modelo único para lançar instâncias EC2 idênticas. Em vez de arrancar um servidor vazio e instalar dependências à mão de cada vez, coze («baking») tudo uma só vez —sistema operativo com patches, agentes, runtime, configuração e controlos de segurança— e reutiliza-o em cada implantação.
Esta abordagem é a base da infraestrutura imutável: não se aplicam patches a quente nos servidores, constrói-se uma imagem nova e substituem-se as instâncias. O resultado é menos deriva de configuração, arranques mais rápidos em autoescalamento e implantações auditáveis e reversíveis.
Golden AMI face ao bootstrapping no arranque
Existem duas filosofias. No bootstrapping, a instância configura-se ao arrancar (user-data, Ansible pull, cloud-init). É flexível mas lento e frágil: se um repositório de pacotes cair, o seu autoescalamento falha. No modelo golden AMI (baking) o trabalho pesado acontece uma só vez na pipeline; o arranque é quase instantâneo e determinista. A maioria das equipas maduras combina ambos: cozem o que é estável e deixam para o arranque apenas a configuração que muda por ambiente.
Porquê o Packer
O Packer, da HashiCorp, é a ferramenta padrão de facto para construir imagens de máquina de forma automatizada e multicloud a partir de um único template. Define a imagem como código (HCL2); lança uma instância temporária, aplica os seus provisioners, cria a AMI e destrói os recursos temporários. O mesmo template pode gerar imagens para AWS, Azure e GCP, o que o torna ideal se publica em várias nuvens.
- Reproduzível: a imagem é descrita num ficheiro versionado em Git.
- Multicloud: um único fluxo para AMI, Azure Managed Image e GCP Custom Image.
- Integrável: encaixa em CI/CD (GitHub Actions, GitLab CI, CodePipeline).
- Auditável: cada build fica registado, com o seu manifest e artefactos.
Anatomia de um template Packer (HCL2)
Um template moderno organiza-se em blocos. O bloco source define o builder (por
exemplo amazon-ebs), a AMI base, o tipo de instância e a região. O bloco build
encadeia os provisioners que instalam e configuram software. Os post-processors
geram artefactos como um manifest JSON com o ID da AMI resultante.
Exemplo mínimo comentado
source "amazon-ebs" "app" — parte de uma AMI base oficial procurada dinamicamente com
um data "amazon-ami" a filtrar por proprietário e padrão de nome, para não fixar um ID
que vai caducar.
provisioner "shell" — executa scripts de instalação e atualização (dnf update -y,
instalação do runtime, do agente CloudWatch, do agente SSM).
provisioner "ansible" — se já tem papéis de Ansible, reutilize-os para configurar a
imagem de forma idempotente.
post-processor "manifest" — escreve manifest.json com o artifact_id, que a sua
pipeline lê para saber que AMI nasceu.
O pipeline passo a passo
Este é o fluxo que recomendamos para levar uma golden AMI do commit à produção de forma segura e repetível:
| Passo | O que acontece | Ferramenta típica |
|---|---|---|
| 1. Commit | Altera o template ou os scripts e faz push para Git | Git / revisão de PR |
| 2. Validate | packer fmt + packer validate verificam a sintaxe | Packer, CI |
| 3. Build | O Packer lança instância temporária e aplica provisioners | Packer |
| 4. Harden | Aplica-se o benchmark CIS e limpam-se credenciais | Ansible / CIS |
| 5. Scan | Análise de vulnerabilidades e de segredos | Trivy, Inspector |
| 6. Test | Arranca-se uma instância e valida-se | InSpec / Goss |
| 7. Tag & version | Etiqueta-se a AMI (versão, commit, data) | AWS CLI |
| 8. Distribute | Partilha-se ou copia-se para outras regiões ou contas | AWS RAM / copy |
| 9. Deploy | A AMI é referenciada no Launch Template | Terraform / ASG |
Fluxo de referência de um pipeline de golden AMI em nove etapas.
Boas práticas que fazem a diferença
- Nunca fixe uma AMI base por ID: procure-a dinamicamente por owner e nome para herdar sempre os patches mais recentes.
- Versione a imagem com um esquema claro (por exemplo
app-2026.07.1) e guarde o commit de Git nas tags da AMI. - Limpe antes de selar: apague logs, históricos de shell, chaves SSH temporárias e caches de pacotes para não deixar escapar segredos.
- Analise sempre: integre Trivy ou Amazon Inspector para não publicar CVE conhecidos.
- Cifre os snapshots com uma chave KMS própria desde o primeiro minuto.
- Automatize a caducidade: marque as versões antigas como obsoletas e elimine-as para controlar custos.
Packer ou EC2 Image Builder: qual escolho?
Se trabalha exclusivamente na AWS e valoriza a integração nativa com o Inspector, os componentes CIS geridos e zero infraestrutura para manter, o EC2 Image Builder é uma opção sólida e sem custo de licença. Se precisa de construir para várias nuvens a partir do mesmo template, ou já tem ecossistema HashiCorp (Terraform, Vault), o Packer dar-lhe-á mais portabilidade. Não se excluem: muitas equipas usam Packer para a lógica multicloud e o Image Builder para pipelines internas de AWS.
Perguntas frequentes
De quanto em quanto tempo devo reconstruir a golden AMI?
No mínimo a cada ciclo de patches do sistema operativo (mensal costuma ser um bom ritmo) e sempre que surja um CVE crítico no seu stack. Uma pipeline automatizada permite reconstruir a pedido em minutos.
Posso usar o mesmo template Packer para AWS e Azure?
Sim. O Packer suporta múltiplos builders num mesmo build. Partilha os provisioners e muda apenas o bloco source de cada nuvem, produzindo em paralelo uma AMI, uma Managed Image e uma Custom Image.
Golden AMI ou contentores?
Não é uma ou outra. As golden AMIs são ideais para a camada de anfitrião e para cargas não containerizadas; os contentores vivem por cima. De facto, uma golden AMI endurecida é uma excelente base para os seus nós de Kubernetes.
Na imaxe.cloud construímos e mantemos imagens base endurecidas e atualizadas para que a sua pipeline arranque de uma base fiável.
