Muchos equipos tratan la AMI como algo que se crea una vez y se olvida. El problema aparece meses después: decenas de imágenes sin etiquetar, snapshots EBS que nadie sabe si se pueden borrar, y una factura que crece sin explicación. Gestionar el ciclo de vida de una AMI significa tratarla como un artefacto de software con nacimiento, versiones, madurez, deprecación y retirada.
Un buen gobierno de imágenes reduce costes, mejora la seguridad —nadie arranca por error una imagen sin parchear de hace un año— y facilita las auditorías de cumplimiento.
Fase 1 — Versionado con significado
El versionado es la columna vertebral. Sin él, «la última AMI buena» es una conversación de pasillo, no un dato. Recomendamos un esquema legible y consistente.
- Nombre versionado: por ejemplo
imaxe-ubuntu22-nginx-2026.07.1, con producto, base y versión calendario. - Tags obligatorias:
Version,GitCommit,BuildDate,Owner,Environment,CISLevel,Status. - Inmutable: una versión, un artefacto. Nunca modifiques una AMI publicada; crea una nueva versión.
- Registro central: usa AWS Systems Manager Parameter Store para guardar el ID de «la AMI de producción actual» y que tus Launch Templates lo lean por referencia.
Fase 2 — Cifrado de extremo a extremo
Los datos de una AMI viven en snapshots EBS. Si no están cifrados, cualquier copia mal gobernada es una fuga potencial. El cifrado debe ser la norma, no la excepción.
- Cifrado por defecto: activa EBS encryption by default a nivel de cuenta y región.
- Claves gestionadas por ti (CMK): usa una clave KMS propia en lugar de la clave de AWS por defecto para controlar permisos y rotación.
- Copia igual a recifrado: al copiar una AMI a otra región o cuenta, aprovecha para recifrarla con la clave de destino.
- Comparte con KMS grants: si distribuyes la AMI a otras cuentas, otorga acceso a la clave con políticas mínimas.
Fase 3 — Deprecación: avisar antes de borrar
AWS permite marcar una AMI como obsoleta (deprecated) con una fecha. A partir de ese momento deja de aparecer por defecto en las búsquedas, pero sigue funcionando para quien la referencie explícitamente. Es el paso intermedio civilizado entre «vigente» y «borrada»: avisas, das margen de migración y evitas romper despliegues.
Fase 4 — Limpieza automatizada (y el coste oculto de los snapshots)
Aquí está el dinero. Cuando borras una AMI, sus snapshots EBS asociados no se eliminan automáticamente. Es la causa número uno de facturas de almacenamiento que crecen misteriosamente. Una política de retirada debe deregistrar la AMI y, después, borrar sus snapshots huérfanos.
- Política de retención: conserva N versiones recientes (por ejemplo las tres últimas) y retira el resto.
- Automatiza con la nube: Amazon Data Lifecycle Manager (DLM) puede gestionar creación y borrado de imágenes por política.
- Caza snapshots huérfanos: audita periódicamente los snapshots sin AMI asociada y elimínalos.
- Nunca borres a ciegas: comprueba que ninguna instancia ni Launch Template activo depende de la AMI antes de retirarla.
Tabla resumen del ciclo de vida
| Fase | Acción clave | Herramienta o servicio |
|---|---|---|
| Creación | Build reproducible y etiquetado | Packer / EC2 Image Builder |
| Cifrado | Snapshots cifrados con CMK | AWS KMS + EBS default encryption |
| Distribución | Copia y recifrado multirregión o multicuenta | AMI copy / AWS RAM |
| Vigencia | Registro del ID actual | SSM Parameter Store |
| Deprecación | Marcar obsoleta con fecha | ec2 enable-image-deprecation |
| Retirada | Deregister y borrado de snapshots | DLM / scripts programados |
Las seis fases del gobierno de una AMI y cómo automatizarlas.
Métricas que deberías vigilar
- Antigüedad media de las AMIs en uso: cuanto menor, más parcheado.
- Número de snapshots huérfanos y su coste mensual.
- Porcentaje de AMIs cifradas, con objetivo del 100 %.
- Tiempo desde el CVE crítico hasta la nueva imagen publicada, el MTTR de parches.
Preguntas frecuentes
¿Por qué sube mi factura de EBS si ya borré las AMIs?
Porque deregistrar una AMI no borra sus snapshots. Debes eliminarlos explícitamente. Audita snapshots huérfanos con regularidad; suelen ser el mayor coste oculto.
¿Es seguro compartir una AMI cifrada con otra cuenta?
Sí, siempre que otorgues acceso a la clave KMS con un grant específico y permisos mínimos. Sin ese acceso, la cuenta de destino no podrá lanzar la imagen.
¿Cuántas versiones de una AMI debo conservar?
Depende de tu necesidad de rollback y cumplimiento, pero conservar entre dos y cuatro versiones recientes suele ser un buen equilibrio entre seguridad de reversión y coste.
En imaxe.cloud diseñamos nuestras imágenes con versionado y cifrado desde el origen, para que su ciclo de vida sea predecible y auditable.
