Una golden AMI (o «imagen dorada») es una Amazon Machine Image preconfigurada, endurecida y validada que sirve como plantilla única para lanzar instancias EC2 idénticas. En lugar de arrancar un servidor vacío e instalar dependencias a mano cada vez, horneas («baking») todo una sola vez —sistema operativo parcheado, agentes, runtime, configuración y controles de seguridad— y lo reutilizas en cada despliegue.
Este enfoque es la base de la infraestructura inmutable: no parcheas servidores en caliente, sino que construyes una imagen nueva y reemplazas las instancias. El resultado es menos deriva de configuración (configuration drift), arranques más rápidos en autoescalado y despliegues que puedes auditar y revertir.
Golden AMI frente a bootstrapping en el arranque
Existen dos filosofías. En el bootstrapping la instancia se configura al arrancar (user-data, Ansible pull, cloud-init). Es flexible pero lento y frágil: si un repositorio de paquetes cae, tu autoescalado falla. En el modelo golden AMI (baking) el trabajo pesado ocurre una sola vez en el pipeline; el arranque es casi instantáneo y determinista. La mayoría de equipos maduros combinan ambos: hornean lo estable y dejan al arranque solo la configuración que cambia por entorno.
Por qué Packer
Packer, de HashiCorp, es la herramienta estándar de facto para construir imágenes de máquina de forma automatizada y multinube desde una única plantilla. Define la imagen como código (HCL2), lanza una instancia temporal, aplica tus provisioners, crea la AMI y destruye los recursos temporales. La misma plantilla puede generar imágenes para AWS, Azure y GCP, lo que lo hace ideal si publicas en varias nubes.
- Reproducible: la imagen se describe en un fichero versionado en Git.
- Multinube: un solo flujo para AMI, Azure Managed Image y GCP Custom Image.
- Integrable: encaja en CI/CD (GitHub Actions, GitLab CI, CodePipeline).
- Auditable: cada build queda registrado, con su manifest y sus artefactos.
Anatomía de una plantilla Packer (HCL2)
Una plantilla moderna se organiza en bloques. El bloque source define el builder
(por ejemplo amazon-ebs), la AMI base, el tipo de instancia y la región. El bloque
build encadena los provisioners que instalan y configuran software. Los
post-processors generan artefactos como un manifest JSON con el ID de la AMI
resultante.
Ejemplo mínimo comentado
source "amazon-ebs" "app" — parte de una AMI base oficial buscada dinámicamente con
un data "amazon-ami" filtrando por propietario y patrón de nombre, para no clavar un
ID que caducará.
provisioner "shell" — ejecuta scripts de instalación y actualización (dnf update -y, instalación del runtime, del agente de CloudWatch, del agente SSM).
provisioner "ansible" — si ya tienes roles de Ansible, reutilízalos para configurar
la imagen de forma idempotente.
post-processor "manifest" — escribe manifest.json con el artifact_id, que tu
pipeline lee para saber qué AMI ha nacido.
El pipeline paso a paso
Este es el flujo que recomendamos para llevar una golden AMI de commit a producción de forma segura y repetible:
| Paso | Qué ocurre | Herramienta típica |
|---|---|---|
| 1. Commit | Cambias la plantilla o los scripts y haces push a Git | Git / revisión de PR |
| 2. Validate | packer fmt + packer validate comprueban sintaxis | Packer, CI |
| 3. Build | Packer lanza instancia temporal y aplica provisioners | Packer |
| 4. Harden | Se aplica el benchmark CIS y se limpian credenciales | Ansible / CIS |
| 5. Scan | Escaneo de vulnerabilidades y de secretos | Trivy, Inspector |
| 6. Test | Se arranca una instancia y se valida | InSpec / Goss |
| 7. Tag & version | Se etiqueta la AMI (versión, commit, fecha) | AWS CLI |
| 8. Distribute | Se comparte o copia a otras regiones o cuentas | AWS RAM / copy |
| 9. Deploy | La AMI se referencia en el Launch Template | Terraform / ASG |
Flujo de referencia de un pipeline de golden AMI en nueve etapas.
Buenas prácticas que marcan la diferencia
- Nunca fijes una AMI base por ID: búscala dinámicamente por owner y nombre para heredar siempre los parches más recientes.
- Versiona la imagen con un esquema claro (por ejemplo
app-2026.07.1) y guarda el commit de Git en las tags de la AMI. - Limpia antes de sellar: borra logs, historiales de shell, llaves SSH temporales y cachés de paquetes para no filtrar secretos.
- Escanea siempre: integra Trivy o Amazon Inspector para no publicar CVE conocidas.
- Cifra los snapshots con una clave KMS propia desde el minuto uno.
- Automatiza la caducidad: marca como obsoletas las versiones antiguas y elimínalas para controlar costes.
Packer o EC2 Image Builder: ¿cuál elijo?
Si trabajas exclusivamente en AWS y valoras la integración nativa con Inspector, los componentes CIS gestionados y cero infraestructura que mantener, EC2 Image Builder es una opción sólida y sin coste de licencia. Si necesitas construir para varias nubes desde una misma plantilla, o ya tienes ecosistema HashiCorp (Terraform, Vault), Packer te dará más portabilidad. No son excluyentes: muchos equipos usan Packer para la lógica multinube e Image Builder para pipelines internos de AWS.
Preguntas frecuentes
¿Cada cuánto debo reconstruir la golden AMI?
Como mínimo con cada ciclo de parches del sistema operativo (mensual suele ser un buen ritmo) y siempre que se publique un CVE crítico en tu stack. Un pipeline automatizado permite reconstruir bajo demanda en minutos.
¿Puedo usar la misma plantilla Packer para AWS y Azure?
Sí. Packer soporta múltiples builders en un mismo build. Compartes los provisioners y cambias solo el bloque source de cada nube, produciendo una AMI, una Managed Image y una Custom Image en paralelo.
¿Golden AMI o contenedores?
No es una u otra. Las golden AMIs son ideales para la capa de host y para cargas que no están contenerizadas; los contenedores viven encima. De hecho, una golden AMI endurecida es una excelente base para tus nodos de Kubernetes.
En imaxe.cloud construimos y mantenemos imágenes base endurecidas y actualizadas para que tu pipeline arranque desde una base fiable.
