Una golden AMI (o «immagine dorata») è una Amazon Machine Image preconfigurata, irrobustita e validata che funge da unico modello per lanciare istanze EC2 identiche. Invece di avviare ogni volta un server vuoto e installare le dipendenze a mano, cuoci («baking») tutto una volta sola —sistema operativo aggiornato, agenti, runtime, configurazione e controlli di sicurezza— e lo riusi a ogni rilascio.
Questo approccio è la base dell’infrastruttura immutabile: non applichi patch a caldo ai server, ma costruisci un’immagine nuova e sostituisci le istanze. Il risultato è meno deriva di configurazione, avvii più rapidi in autoscaling e rilasci verificabili e reversibili.
Golden AMI contro bootstrapping all’avvio
Esistono due filosofie. Nel bootstrapping l’istanza si configura all’avvio (user-data, Ansible pull, cloud-init). È flessibile ma lento e fragile: se cade un repository di pacchetti, il tuo autoscaling fallisce. Nel modello golden AMI (baking) il lavoro pesante avviene una sola volta nella pipeline; l’avvio è quasi istantaneo e deterministico. La maggior parte dei team maturi combina i due: cuoce ciò che è stabile e lascia all’avvio solo la configurazione che cambia per ambiente.
Perché Packer
Packer, di HashiCorp, è lo strumento standard di fatto per costruire immagini di macchina in modo automatizzato e multicloud da un unico template. Definisci l’immagine come codice (HCL2); Packer lancia un’istanza temporanea, applica i tuoi provisioner, crea la AMI e distrugge le risorse temporanee. Lo stesso template può generare immagini per AWS, Azure e GCP, il che lo rende ideale se pubblichi su più cloud.
- Riproducibile: l’immagine è descritta in un file versionato in Git.
- Multicloud: un solo flusso per AMI, Azure Managed Image e GCP Custom Image.
- Integrabile: si inserisce in CI/CD (GitHub Actions, GitLab CI, CodePipeline).
- Verificabile: ogni build resta registrato, con il suo manifest e gli artefatti.
Anatomia di un template Packer (HCL2)
Un template moderno è organizzato in blocchi. Il blocco source definisce il builder
(per esempio amazon-ebs), la AMI base, il tipo di istanza e la regione. Il blocco
build concatena i provisioner che installano e configurano il software. I
post-processor generano artefatti come un manifest JSON con l’ID della AMI risultante.
Esempio minimo commentato
source "amazon-ebs" "app" — parte da una AMI base ufficiale cercata dinamicamente con
un data "amazon-ami" che filtra per proprietario e schema di nome, per non fissare un ID
destinato a scadere.
provisioner "shell" — esegue script di installazione e aggiornamento (dnf update -y,
installazione del runtime, dell’agente CloudWatch, dell’agente SSM).
provisioner "ansible" — se hai già ruoli Ansible, riusali per configurare l’immagine in
modo idempotente.
post-processor "manifest" — scrive manifest.json con l’artifact_id, che la tua
pipeline legge per sapere quale AMI è nata.
La pipeline passo dopo passo
Questo è il flusso che consigliamo per portare una golden AMI dal commit alla produzione in modo sicuro e ripetibile:
| Passo | Cosa succede | Strumento tipico |
|---|---|---|
| 1. Commit | Modifichi il template o gli script e fai push su Git | Git / revisione PR |
| 2. Validate | packer fmt + packer validate verificano la sintassi | Packer, CI |
| 3. Build | Packer lancia un’istanza temporanea e applica i provisioner | Packer |
| 4. Harden | Si applica il benchmark CIS e si ripuliscono le credenziali | Ansible / CIS |
| 5. Scan | Scansione di vulnerabilità e segreti | Trivy, Inspector |
| 6. Test | Si avvia un’istanza e si valida | InSpec / Goss |
| 7. Tag & version | Si etichetta la AMI (versione, commit, data) | AWS CLI |
| 8. Distribute | Si condivide o si copia in altre regioni o account | AWS RAM / copy |
| 9. Deploy | La AMI viene referenziata nel Launch Template | Terraform / ASG |
Flusso di riferimento di una pipeline di golden AMI in nove tappe.
Buone pratiche che fanno la differenza
- Non fissare mai una AMI base per ID: cercala dinamicamente per proprietario e nome per ereditare sempre le patch più recenti.
- Versiona l’immagine con uno schema chiaro (per esempio
app-2026.07.1) e salva il commit Git nei tag della AMI. - Pulisci prima di sigillare: cancella log, cronologie di shell, chiavi SSH temporanee e cache dei pacchetti per non far trapelare segreti.
- Scansiona sempre: integra Trivy o Amazon Inspector per non pubblicare CVE note.
- Cifra gli snapshot con una chiave KMS propria dal primo minuto.
- Automatizza la scadenza: marca come deprecate le versioni vecchie ed eliminale per tenere sotto controllo i costi.
Packer o EC2 Image Builder: quale scelgo?
Se lavori solo su AWS e apprezzi l’integrazione nativa con Inspector, i componenti CIS gestiti e nessuna infrastruttura da mantenere, EC2 Image Builder è un’opzione solida e senza costo di licenza. Se devi costruire per più cloud dallo stesso template, o hai già l’ecosistema HashiCorp (Terraform, Vault), Packer ti darà più portabilità. Non si escludono: molti team usano Packer per la logica multicloud e Image Builder per le pipeline interne di AWS.
Domande frequenti
Ogni quanto devo ricostruire la golden AMI?
Come minimo a ogni ciclo di patch del sistema operativo (mensile è di solito un buon ritmo) e ogni volta che esce un CVE critico nel tuo stack. Una pipeline automatizzata consente di ricostruire su richiesta in pochi minuti.
Posso usare lo stesso template Packer per AWS e Azure?
Sì. Packer supporta più builder in uno stesso build. Condividi i provisioner e cambi solo il blocco source di ciascun cloud, producendo in parallelo una AMI, una Managed Image e una Custom Image.
Golden AMI o container?
Non è l’uno o l’altro. Le golden AMI sono ideali per il livello host e per carichi non containerizzati; i container vivono sopra. Anzi, una golden AMI irrobustita è un’ottima base per i tuoi nodi Kubernetes.
In imaxe.cloud costruiamo e manteniamo immagini base irrobustite e aggiornate, così la tua pipeline parte da una base affidabile.
