Beaucoup d’équipes traitent l’AMI comme quelque chose qu’on crée une fois et qu’on oublie. Le problème apparaît des mois plus tard : des dizaines d’images sans étiquettes, des snapshots EBS dont personne ne sait s’ils peuvent être supprimés, et une facture qui grimpe sans explication. Gérer le cycle de vie d’une AMI, c’est la traiter comme un artefact logiciel avec une naissance, des versions, une maturité, une dépréciation et un retrait.
Une bonne gouvernance d’images réduit les coûts, améliore la sécurité —personne ne lance par erreur une image non corrigée d’il y a un an— et facilite les audits de conformité.
Phase 1 — Versionner avec du sens
Le versionnement est la colonne vertébrale. Sans lui, « la dernière bonne AMI » est une conversation de couloir, pas une donnée. Nous recommandons un schéma lisible et cohérent.
- Nom versionné : par exemple
imaxe-ubuntu22-nginx-2026.07.1, avec produit, base et version calendaire. - Tags obligatoires :
Version,GitCommit,BuildDate,Owner,Environment,CISLevel,Status. - Immuable : une version, un artefact. Ne modifiez jamais une AMI publiée ; créez une nouvelle version.
- Registre central : utilisez AWS Systems Manager Parameter Store pour stocker l’ID de « l’AMI de production actuelle » et que vos Launch Templates la lisent par référence.
Phase 2 — Chiffrement de bout en bout
Les données d’une AMI vivent dans des snapshots EBS. S’ils ne sont pas chiffrés, toute copie mal gouvernée est une fuite potentielle. Le chiffrement doit être la norme, pas l’exception.
- Chiffrement par défaut : activez EBS encryption by default au niveau du compte et de la région.
- Clés gérées par vous (CMK) : utilisez votre propre clé KMS au lieu de la clé AWS par défaut pour contrôler permissions et rotation.
- Copier, c’est rechiffrer : en copiant une AMI vers une autre région ou un autre compte, profitez-en pour la rechiffrer avec la clé de destination.
- Partagez avec des KMS grants : si vous distribuez l’AMI à d’autres comptes, accordez l’accès à la clé avec des politiques minimales.
Phase 3 — Dépréciation : prévenir avant de supprimer
AWS permet de marquer une AMI comme obsolète (deprecated) avec une date. À partir de là, elle cesse d’apparaître par défaut dans les recherches, mais continue de fonctionner pour qui la référence explicitement. C’est l’étape civilisée entre « en vigueur » et « supprimée » : vous prévenez, vous laissez le temps de migrer et vous ne cassez pas de déploiements.
Phase 4 — Nettoyage automatisé (et le coût caché des snapshots)
C’est là qu’est l’argent. Quand vous supprimez une AMI, ses snapshots EBS associés ne sont pas supprimés automatiquement. C’est la cause numéro un des factures de stockage qui grossissent mystérieusement. Une politique de retrait doit désenregistrer l’AMI puis supprimer ses snapshots orphelins.
- Politique de rétention : conservez N versions récentes (les trois dernières par exemple) et retirez le reste.
- Automatisez avec le cloud : Amazon Data Lifecycle Manager (DLM) peut gérer création et suppression d’images par politique.
- Chassez les snapshots orphelins : auditez périodiquement les snapshots sans AMI associée et supprimez-les.
- Ne supprimez jamais à l’aveugle : vérifiez qu’aucune instance ni Launch Template actif ne dépend de l’AMI avant de la retirer.
Tableau récapitulatif du cycle de vie
| Phase | Action clé | Outil ou service |
|---|---|---|
| Création | Build reproductible et étiquetage | Packer / EC2 Image Builder |
| Chiffrement | Snapshots chiffrés avec une CMK | AWS KMS + EBS default encryption |
| Distribution | Copie et rechiffrement multirégion ou multicompte | AMI copy / AWS RAM |
| En vigueur | Registre de l’ID actuel | SSM Parameter Store |
| Dépréciation | Marquer obsolète avec une date | ec2 enable-image-deprecation |
| Retrait | Désenregistrer et supprimer les snapshots | DLM / scripts planifiés |
Les six phases de la gouvernance d’une AMI et comment les automatiser.
Les métriques à surveiller
- Âge moyen des AMI en usage : plus il est bas, mieux c’est corrigé.
- Nombre de snapshots orphelins et leur coût mensuel.
- Pourcentage d’AMI chiffrées, avec un objectif de 100 %.
- Délai entre la CVE critique et la nouvelle image publiée, le MTTR des correctifs.
Questions fréquentes
Pourquoi ma facture EBS augmente-t-elle alors que j’ai supprimé les AMI ?
Parce que désenregistrer une AMI ne supprime pas ses snapshots. Vous devez les supprimer explicitement. Auditez régulièrement les snapshots orphelins ; c’est souvent le plus gros coût caché.
Est-il sûr de partager une AMI chiffrée avec un autre compte ?
Oui, à condition d’accorder l’accès à la clé KMS via un grant spécifique et des permissions minimales. Sans cet accès, le compte de destination ne pourra pas lancer l’image.
Combien de versions d’une AMI dois-je conserver ?
Cela dépend de vos besoins de rollback et de conformité, mais conserver entre deux et quatre versions récentes est en général un bon équilibre entre sécurité de retour arrière et coût.
Chez imaxe.cloud, nous concevons nos images avec versionnement et chiffrement dès l’origine, pour que leur cycle de vie soit prévisible et auditable.
