Une golden AMI (ou « image dorée ») est une Amazon Machine Image préconfigurée, durcie et validée qui sert de modèle unique pour lancer des instances EC2 identiques. Au lieu de démarrer un serveur vide et d’installer les dépendances à la main chaque fois, vous cuisez (« baking ») tout une seule fois —système d’exploitation corrigé, agents, runtime, configuration et contrôles de sécurité— et vous le réutilisez à chaque déploiement.
Cette approche est la base de l’infrastructure immuable : on ne corrige pas les serveurs à chaud, on construit une image neuve et on remplace les instances. Résultat : moins de dérive de configuration, des démarrages plus rapides en autoscaling et des déploiements auditables et réversibles.
Golden AMI face au bootstrapping au démarrage
Il existe deux philosophies. Dans le bootstrapping, l’instance se configure au démarrage (user-data, Ansible pull, cloud-init). C’est flexible mais lent et fragile : si un dépôt de paquets tombe, votre autoscaling échoue. Dans le modèle golden AMI (baking), le gros du travail se fait une seule fois dans le pipeline ; le démarrage est quasi instantané et déterministe. La plupart des équipes mûres combinent les deux : elles cuisent le stable et laissent au démarrage la seule configuration qui varie par environnement.
Pourquoi Packer
Packer, de HashiCorp, est l’outil standard de fait pour construire des images machine de façon automatisée et multicloud depuis un modèle unique. Vous définissez l’image comme du code (HCL2) ; il lance une instance temporaire, applique vos provisioners, crée l’AMI et détruit les ressources temporaires. Le même modèle peut générer des images pour AWS, Azure et GCP, ce qui le rend idéal si vous publiez sur plusieurs clouds.
- Reproductible : l’image est décrite dans un fichier versionné dans Git.
- Multicloud : un seul flux pour AMI, Azure Managed Image et GCP Custom Image.
- Intégrable : il s’insère dans la CI/CD (GitHub Actions, GitLab CI, CodePipeline).
- Auditable : chaque build est consigné, avec son manifest et ses artefacts.
Anatomie d’un modèle Packer (HCL2)
Un modèle moderne s’organise en blocs. Le bloc source définit le builder (par exemple
amazon-ebs), l’AMI de base, le type d’instance et la région. Le bloc build enchaîne
les provisioners qui installent et configurent le logiciel. Les post-processors
génèrent des artefacts comme un manifest JSON contenant l’ID de l’AMI produite.
Exemple minimal commenté
source "amazon-ebs" "app" — part d’une AMI de base officielle recherchée dynamiquement
avec un data "amazon-ami" filtrant par propriétaire et motif de nom, pour ne pas figer
un ID qui expirera.
provisioner "shell" — exécute les scripts d’installation et de mise à jour (dnf update -y, installation du runtime, de l’agent CloudWatch, de l’agent SSM).
provisioner "ansible" — si vous avez déjà des rôles Ansible, réutilisez-les pour
configurer l’image de manière idempotente.
post-processor "manifest" — écrit manifest.json avec l’artifact_id, que votre
pipeline lit pour savoir quelle AMI est née.
Le pipeline pas à pas
Voici le flux que nous recommandons pour porter une golden AMI du commit à la production de manière sûre et répétable :
| Étape | Ce qui se passe | Outil typique |
|---|---|---|
| 1. Commit | Vous modifiez le modèle ou les scripts et poussez dans Git | Git / revue de PR |
| 2. Validate | packer fmt + packer validate vérifient la syntaxe | Packer, CI |
| 3. Build | Packer lance une instance temporaire et applique les provisioners | Packer |
| 4. Harden | Le benchmark CIS est appliqué et les identifiants nettoyés | Ansible / CIS |
| 5. Scan | Analyse de vulnérabilités et de secrets | Trivy, Inspector |
| 6. Test | Une instance est démarrée et validée | InSpec / Goss |
| 7. Tag & version | L’AMI est étiquetée (version, commit, date) | AWS CLI |
| 8. Distribute | Elle est partagée ou copiée vers d’autres régions ou comptes | AWS RAM / copy |
| 9. Deploy | L’AMI est référencée dans le Launch Template | Terraform / ASG |
Flux de référence d’un pipeline de golden AMI en neuf étapes.
Bonnes pratiques qui font la différence
- Ne figez jamais une AMI de base par son ID : recherchez-la dynamiquement par propriétaire et nom pour hériter toujours des correctifs les plus récents.
- Versionnez l’image avec un schéma clair (par exemple
app-2026.07.1) et conservez le commit Git dans les tags de l’AMI. - Nettoyez avant de sceller : supprimez logs, historiques de shell, clés SSH temporaires et caches de paquets pour ne pas laisser fuiter de secrets.
- Analysez toujours : intégrez Trivy ou Amazon Inspector pour ne pas publier de CVE connues.
- Chiffrez les snapshots avec votre propre clé KMS dès la première minute.
- Automatisez la péremption : marquez les anciennes versions comme obsolètes et supprimez-les pour maîtriser les coûts.
Packer ou EC2 Image Builder : lequel choisir ?
Si vous travaillez exclusivement sur AWS et appréciez l’intégration native avec Inspector, les composants CIS gérés et zéro infrastructure à maintenir, EC2 Image Builder est une option solide et sans coût de licence. S’il vous faut construire pour plusieurs clouds depuis un même modèle, ou si vous avez déjà l’écosystème HashiCorp (Terraform, Vault), Packer vous donnera plus de portabilité. Ils ne s’excluent pas : beaucoup d’équipes utilisent Packer pour la logique multicloud et Image Builder pour les pipelines internes AWS.
Questions fréquentes
À quelle fréquence dois-je reconstruire la golden AMI ?
Au minimum à chaque cycle de correctifs du système d’exploitation (le mensuel est souvent un bon rythme) et dès qu’une CVE critique touche votre stack. Un pipeline automatisé permet de reconstruire à la demande en quelques minutes.
Puis-je utiliser le même modèle Packer pour AWS et Azure ?
Oui. Packer prend en charge plusieurs builders dans un même build. Vous partagez les provisioners et ne changez que le bloc source de chaque cloud, produisant en parallèle une AMI, une Managed Image et une Custom Image.
Golden AMI ou conteneurs ?
Ce n’est pas l’un ou l’autre. Les golden AMI sont idéales pour la couche hôte et pour les charges non conteneurisées ; les conteneurs vivent au-dessus. De fait, une golden AMI durcie est une excellente base pour vos nœuds Kubernetes.
Chez imaxe.cloud, nous construisons et maintenons des images de base durcies et à jour pour que votre pipeline démarre d’un socle fiable.
