Aller au contenu

AWS Mis à jour le 2026-07-04

AMI dorées sans dérive : bâtir des images EC2 qui restent fiables

Comment bâtir et maintenir un pipeline d'AMI dorées sur EC2 pour que chaque instance démarre identique — avec EC2 Image Builder, des images versionnées et le remplacement plutôt que le correctif en place.

Une AMI dorée est une image machine pré-assemblée avec le durcissement d’OS, les agents et l’environnement d’exécution déjà installés, pour que les instances démarrent prêtes à servir au lieu de rouler vingt minutes de scripts user-data. Elle ne reste dorée qu’à une condition : les instances lancées à partir d’elle ne sont jamais corrigées ni reconfigurées à la main — on reconstruit l’image et on remplace le parc. La dérive, c’est ce qui arrive quand cette discipline lâche, et c’est la raison pour laquelle la plupart des projets d’AMI dorées meurent discrètement en dedans d’un an.

Ce qui se passe

Une AMI est un instantané figé d’un volume racine plus des métadonnées de lancement. Dès qu’une instance démarre à partir d’elle, l’instance commence à diverger : un correctif de sécurité appliqué en SSH, un fichier de config modifié pendant un incident, un agent mis à jour par son propre mécanisme automatique. Six mois plus tard, « l’AMI » ne décrit plus aucune des machines en production, et la prochaine instance lancée se comporte différemment de ses sœurs. Cette divergence, c’est la dérive, et elle a deux sources : les instances qui s’éloignent de l’image, et l’image qui s’éloigne de la réalité parce que personne ne la reconstruit.

Le remède est un pipeline, pas une personne. EC2 Image Builder existe exactement pour ça : il prend une image parente, exécute vos composants de construction (paquets, durcissement, agents), exécute des composants de test, et produit une nouvelle AMI versionnée sur un horaire ou sur déclenchement. Combinez-le avec des modèles de lancement pointant vers la plus récente image testée, et un déploiement par groupe Auto Scaling remplace les anciennes instances par les nouvelles. Rien n’est corrigé en place; tout est remplacé.

Quoi vérifier en premier

  • Quand l’AMI de production actuelle a-t-elle été construite? Si CreationDate dépasse 30 à 45 jours, vous roulez des images sans correctifs et l’AMI dorée est déjà un passif.
  • Les instances en production correspondent-elles à l’image? Prenez une instance et comparez les versions de paquets installés avec un lancement frais de la même AMI. Toute différence est de la dérive.
  • Quelqu’un fait-il du SSH en production? Vérifiez CloudTrail pour StartSession et les journaux de votre bastion. L’accès interactif, c’est là que naît la dérive.
  • Le modèle de lancement pointe-t-il vers l’AMI que vous pensez? Les parcs roulent souvent une image deux versions en retard sur la version « courante ».
  • L’image de base est-elle épinglée ou flottante? Construire depuis « la dernière Amazon Linux 2023 » sans consigner l’ID de l’AMI source rend les constructions non reproductibles.

Comment vérifier

Listez vos propres AMI avec leur âge, les plus récentes en dernier :

aws ec2 describe-images --owners self \
  --query 'sort_by(Images,&CreationDate)[-10:].[ImageId,Name,CreationDate]' \
  --output table

Trouvez de quelle AMI provient réellement chaque instance en marche :

aws ec2 describe-instances \
  --filters "Name=instance-state-name,Values=running" \
  --query 'Reservations[].Instances[].[InstanceId,ImageId,LaunchTime]' \
  --output table

Vérifiez la santé du pipeline sous EC2 Image Builder > Image pipelines, ou :

aws imagebuilder list-image-pipelines \
  --query 'imagePipelineList[].[name,status,dateLastRun]' --output table

Pour la dérive sur un hôte en production, l’inventaire SSM est le témoin honnête — Systems Manager > Inventory montre les applications installées par instance, et un diff entre deux instances de la même AMI expose les changements faits à la main.

Le runbook

  1. Épinglez et consignez l’image parente. Résolvez l’AMI de base via le paramètre SSM public (par exemple /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64) au moment de la construction et inscrivez l’ID résolu dans les balises de l’image. Vous devez savoir exactement sur quoi vous avez bâti.
  2. Déplacez tout ce qui est répétable dans des composants de construction. Installation de paquets, durcissement CIS, agent CloudWatch, config de l’agent SSM, environnement d’exécution de l’application — tout ça appartient aux composants Image Builder (ou à Packer, si vous préférez; le principe est identique). Le user-data devrait se réduire au câblage propre à l’instance : récupérer les secrets, s’enregistrer auprès du répartiteur de charge.
  3. Ajoutez des composants de test qui auraient attrapé votre dernier incident. Démarrez l’image candidate, validez que le service part, que l’agent rapporte, que la disposition des disques est bonne. Une AMI dorée non testée n’est qu’une façon rapide de répliquer une erreur à l’échelle du parc.
  4. Versionnez et balisez chaque image produite. Balisez avec la date de construction, l’ID de l’AMI parente, la version du pipeline et une balise status (candidate, approved, retired). N’écrasez jamais; ne réutilisez jamais un nom de façon ambiguë.
  5. Planifiez des reconstructions au moins mensuelles, et déclenchez des constructions supplémentaires quand une CVE critique tombe. Image Builder supporte les horaires cron et peut reconstruire automatiquement quand l’image parente est mise à jour.
  6. Déployez par remplacement. Pointez le modèle de lancement vers la nouvelle AMI et utilisez un rafraîchissement d’instances de l’ASG — ou une bascule bleu/vert comme décrit dans déploiements bleu/vert sur groupes Auto Scaling EC2 — pour que les anciennes instances se vident et se terminent au lieu d’être corrigées.
  7. Dépréciez et désenregistrez les vieilles images sur un horaire. Gardez les deux ou trois dernières versions approuvées pour le retour arrière, désenregistrez le reste, et supprimez les instantanés EBS orphelins — le stockage d’instantanés est une ligne discrète et permanente sur la facture.

Quand c’est le mauvais choix

Si vous roulez trois serveurs choyés qui changent chaque semaine, un pipeline d’images complet est plus de machinerie que le problème n’en mérite — SSM Patch Manager plus un script user-data serré est un compromis honnête. Les AMI dorées cadrent aussi mal quand votre artefact de déploiement est déjà un conteneur immuable : assemblez une image d’hôte mince avec seulement l’exécution et les agents, et laissez le conteneur porter l’application. Et si votre équipe n’arrive pas encore à cesser de faire du SSH pour réparer des boîtes, corrigez cette habitude d’abord; un pipeline ne peut pas courir plus vite que la dérive faite à la main.

Erreurs fréquentes

  • Cuire des secrets ou des identifiants dans l’image. Tout ce qui est dans l’AMI est dans chaque instantané pour toujours. Récupérez les secrets au démarrage via un profil d’instance — voir les profils d’instance IAM bien faits.
  • Cuire l’identité de l’instance — noms d’hôte, ID de nœud, clés machine en cache — de sorte que chaque clone se prend pour l’original.
  • Laisser les mises à jour automatiques actives dans l’image, ce qui réintroduit la dérive que le pipeline devait éliminer.
  • Traiter l’AMI comme la copie de sauvegarde. C’est un artefact de lancement, pas une stratégie de protection des données; les données applicatives ont besoin de leur propre chemin de sauvegarde.

Garder le contrôle

  • Alarmez sur l’âge des images : une Lambda planifiée ou une règle Config qui signale tout modèle de lancement de production référençant une AMI de plus de 45 jours.
  • Rendez l’accès interactif exceptionnel et audité — Session Manager avec journalisation, pas de clés SSH permanentes.
  • Reconstruisez sur un calendrier, pas sur l’enthousiasme; le pipeline qui ne roule que quand quelqu’un y pense est déjà mort.
  • Comparez l’inventaire SSM entre instances du parc chaque trimestre pour attraper la dérive tôt.
  • Gardez les définitions de composants dans git pour que les changements d’image soient révisés comme du code.

Un pipeline d’AMI dorées est surtout un engagement de culture avec un peu d’automatisation autour : les images se reconstruisent, les instances se remplacent, personne ne répare un serveur à la main pour ensuite s’en aller. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.