AMIs y EC2 Image Builder

Un grupo de Auto Scaling agrega una instancia durante un pico de tráfico. La instancia arranca en unos 40 segundos, y después pasa 8 minutos más en user data: parchando el sistema operativo, bajando tres agentes y compilando una dependencia. Para cuando pasa su health check, el pico ya terminó. Peor todavía: la instancia que se lanzó el martes pasado instaló versiones de paquetes apenas distintas de las que instaló la de hoy, porque las dos resolvieron "latest" contra un repositorio que se movió en el medio.

Los dos problemas tienen el mismo arreglo. Haz ese trabajo una vez, antes del lanzamiento, y guarda el resultado como una imagen.

Qué es realmente una AMI

Una Amazon Machine Image no es un archivo que puedas descargar. Es un registro dentro de EC2 que apunta a uno o más snapshots de EBS y carga los metadatos necesarios para convertir esos snapshots en una instancia arrancable:

• El block device mapping: qué snapshot se vuelve el volumen raíz, de qué tamaño es, qué volúmenes adicionales se adjuntan y si se borran al terminar la instancia.
• Los metadatos de arranque y plataforma: arquitectura (x86_64 o arm64), tipo de virtualización, tipo de dispositivo raíz y boot mode.
• Los launch permissions: qué cuentas, organizaciones u OUs pueden lanzar desde ella.

De esa estructura salen dos consecuencias, y las dos aparecen en el examen.

Una AMI es regional. Los snapshots viven en una región, así que el AMI ID solo tiene sentido en esa región. Para lanzar la misma imagen en una segunda región la copias, y la copia recibe un AMI ID distinto. Por eso un template de CloudFormation que deja el AMI ID escrito a mano se rompe apenas alguien lo despliega en otro lado.

No pagas por la AMI, pagas por sus snapshots. El registro de la AMI en sí es gratis. Cada AMI que creaste alguna vez te está cobrando en silencio el almacenamiento de los snapshots que tiene detrás, y por eso la sección de limpieza al final de esta lección importa más de lo que parece.

Una AMI también queda fija en esas propiedades. No puedes convertir una AMI x86_64 en una arm64, ni una AMI respaldada por instance store en una respaldada por EBS. Cuando necesitas otra combinación, construyes una imagen nueva.

Hornear o bootstrapear: la decisión que define todo lo demás

Cada pieza de configuración que necesita un servidor puede llegar por dos caminos. Hornear (bake) la pone en la imagen al construirla. Bootstrapear la aplica al lanzar, mediante user data, una asociación de Systems Manager o una herramienta de gestión de configuración.

Nada te obliga a elegir uno solo. La pregunta útil es qué mitad de tu configuración va en cada lado.

De esa tabla sale la regla de decisión: hornea lo lento y estable, bootstrapea lo rápido y variable. Los parches del sistema operativo, los agentes, los runtimes y las dependencias compiladas son lentos y estables, así que van en la imagen. El endpoint de la base de datos, el nombre del ambiente y el rol de la instancia dentro del cluster son rápidos y cambian en cada despliegue, así que van en user data o en Parameter Store.

Una imagen construida así se suele llamar AMI dorada (golden AMI): una base endurecida, parchada y precargada desde la que lanza cada carga de trabajo de la organización.

Aquí está la confusión que esta sección existe para matar: "AMI dorada significa que todo está en la imagen". Llévalo tan lejos y terminas reconstruyendo una imagen para cambiar un nivel de log, y manteniendo una imagen por ambiente por aplicación. La imagen es una línea de salida, no un servidor terminado.

Por qué las AMIs doradas hechas a mano dejan de funcionar

La primera AMI dorada es fácil. Lanzas una instancia, la parchas, instalas lo que necesitas, corres create-image y anotas el AMI ID en una página de wiki.

El segundo mes es donde se cae. Aparecen CVEs nuevos, así que la imagen necesita otro build, y la persona que la armó está de licencia y nunca escribió el paso 4. Nadie probó la imagen nueva antes de que un grupo de Auto Scaling empezara a lanzar desde ella. La imagen existe solo en us-east-1, y la región de DR también la necesita. No hay registro de qué cambió entre la versión 3 y la versión 4.

Esas fallas no son un problema de descuido. Son lo que pasa cuando un proceso de build vive en la memoria de alguien en vez de vivir en un archivo. EC2 Image Builder existe para moverlo a archivos.

Los cinco recursos de Image Builder

Image Builder parte un build de imagen en cinco recursos, y apenas ves qué le toca a cada uno, el servicio deja de sentirse grande.

Dos de estos merecen una mirada más de cerca.

Los components son donde vive tu personalización de verdad. Un component es un documento YAML plano que AWSTOE corre sobre la instancia de build, y viene en dos sabores: los build components personalizan la instancia antes del snapshot, y los test components la validan después. AWS publica components administrados para trabajos comunes, incluidos update-linux y los sets de endurecimiento STIG y CIS, y tú escribes los tuyos para todo lo que sea específico de tu organización.

name: InstallAndVerifyNginx
description: Instala nginx y confirma que responde en el puerto 80
schemaVersion: 1.0
phases:
  - name: build
    steps:
      - name: InstallNginx
        action: ExecuteBash
        inputs:
          commands:
            - dnf install -y nginx
            - systemctl enable nginx
  - name: validate
    steps:
      - name: ConfirmBinary
        action: ExecuteBash
        inputs:
          commands:
            - nginx -v

Los nombres de las fases no son decoración. Image Builder decide cuándo corre un component según qué fases define: un component corre en la etapa de build si define build o validate, y corre en la etapa de test si define test y nada más. Un component no puede pisar las dos etapas, y no puedes encadenar un valor producido en build hacia un paso de test, porque esas etapas corren en instancias distintas.

La infrastructure configuration es el recurso que todos olvidan hasta que un build falla. La instancia de build corre dentro de tu VPC, así que necesita una subnet con ruta para alcanzar los repositorios de paquetes, un security group que permita ese tráfico y un instance profile con los permisos de Image Builder. También es donde vive el interruptor de diagnóstico: por defecto la instancia de build se termina cuando el build falla, y apagar esa opción la deja viva para que entres a leer los logs de AWSTOE.

Qué hace realmente una corrida de pipeline

Recorre un build de punta a punta, porque el orden explica varias respuestas del examen.

1. Etapa de build. Image Builder lanza una instancia EC2 desde la imagen base, dentro de la subnet de tu infrastructure configuration. AWSTOE corre la fase build de cada build component en el orden de la recipe, y después la fase validate de cada uno. Si algún paso falla, el build se detiene aquí.
2. Snapshot. Con las personalizaciones aplicadas, Image Builder detiene la instancia y toma un snapshot, que produce la imagen candidata.
3. Etapa de test. Para un flujo de AMI, Image Builder lanza una instancia nueva desde esa imagen candidata y corre la fase test de cada component de la recipe. Es un lanzamiento real del artefacto real, no una revisión de la instancia de build, y por eso atrapa un servicio que falla en el primer arranque.
4. Distribución. Solo si todos los tests pasaron, Image Builder copia la AMI a cada región de tus distribution settings, aplica la llave KMS configurada, fija los launch permissions y, si lo pediste, actualiza un launch template para que apunte al nuevo AMI ID.

Esa última opción merece una pausa. La distribución puede escribir el nuevo AMI ID en una versión específica de un launch template de EC2, así que un grupo de Auto Scaling apuntado a la versión $Latest o $Default de ese template toma la imagen nueva sin que nadie edite nada.

El servicio en sí es gratis. Pagas por las instancias EC2 de build y test mientras corren, por los snapshots de EBS que ocupan las imágenes, por los logs en S3, por Amazon Inspector si activas el escaneo de vulnerabilidades durante el build, y por el almacenamiento en ECR cuando la salida es una imagen de contenedor.

Schedule: construir por reloj, o construir por cambio

Un pipeline puede correr a demanda, con un schedule tipo cron, o en respuesta a una regla de EventBridge. El schedule tiene un segundo ajuste que carga casi todo el valor, y es un blanco frecuente del examen.

• Correr siempre en el horario agendado. Cada franja agendada produce un build, haya cambiado algo upstream o no. Obtienes una imagen fresca a cadencia fija y pagas un build cada vez.
• Correr en el horario agendado solo si hay actualizaciones de dependencias. Image Builder revisa si la imagen base o algún component tiene una versión semántica más nueva, y se salta el build si nada se movió.

La segunda opción solo funciona si tu recipe usa versionado semántico para la imagen base y los components, que en la consola significa elegir "usar la última versión de OS disponible" y "usar la última versión disponible" en vez de fijar una versión exacta. Si fijas todo a versiones exactas, Image Builder no tiene nada que comparar, así que reconstruye siempre o nunca detecta una actualización, según cómo esté escrita la recipe.

Un pipeline semanal configurado para construir solo cuando hay actualizaciones de dependencias es la forma que quieren la mayoría de los equipos: nada de builds inútiles en una semana tranquila, y una imagen parchada apenas AWS publica una AMI base nueva.

Distribuir y compartir el resultado

Las distribution settings resuelven el trabajo entre regiones y entre cuentas que si no la gente hace a mano.

Dentro de tu propia cuenta, la distribución copia la AMI a cada región destino. Entre cuentas tienes dos opciones distintas, y la diferencia es de propiedad:

• Los launch permissions dejan que otra cuenta lance desde tu AMI. Tú sigues siendo el dueño de la imagen, tú sigues pagando los snapshots, y la otra cuenta paga solo las instancias que lanza. Revocas el permiso y sus lanzamientos futuros se detienen.
• Las cuentas y OUs destino crean una copia de la AMI en cada cuenta destino. Esa cuenta es dueña de su copia y paga sus snapshots, y la copia sobrevive a cualquier cosa que le hagas al original.

El cifrado agrega un requisito que tumba a más gente que ninguna otra parte del sharing de AMIs. Una AMI cuyos snapshots están cifrados con la llave administrada por AWS no se puede compartir de ninguna forma, porque no puedes editar la policy de esa llave. Compartir una AMI cifrada significa cifrar sus snapshots con una llave KMS administrada por el cliente y darle a las cuentas destino permiso para usar esa llave. El arreglo habitual es una copia: copias la AMI sobre sí misma indicando tu propia llave KMS, y compartes la copia.

Dos comportamientos menores que conviene saber. No hace falta compartir los snapshots por separado, porque EC2 otorga el acceso de lanzamiento en tu nombre. Y tus tags definidos por el usuario no viajan con una AMI compartida, así que la cuenta receptora ve una imagen sin tags.

Retirar una imagen: tres verbos que no son sinónimos

Una organización que construye una AMI dorada semanal tiene 52 imágenes al año, por región y por sistema operativo. Limpiarlas es una tarea operativa real, y AWS te da tres acciones distintas que los estudiantes mezclan sin parar.

Lee esa tabla como una escalera. Deprecar es una señal: dejen de elegir esta imagen, pero nada se rompe. Deshabilitar es un freno: los lanzamientos fallan, y puedes deshacerlo. Deregistrar es borrar.

Los números que AWS pregunta directo: puedes fijar una fecha de deprecación hasta 10 años adelante para una AMI privada, las AMIs públicas se deprecan por defecto 2 años después de su creación, y la única forma de correr hacia adelante la deprecación de una AMI pública es volverla privada compartiéndola con cuentas específicas.

Después está la trampa de costo. Deregistrar una AMI no borra los snapshots que la respaldan por defecto. Un equipo que deregistra 40 AMIs viejas y espera que baje la factura de almacenamiento se va a llevar una sorpresa, porque los snapshots siguen ahí. Pasa --delete-associated-snapshots en la llamada de deregistro, o límpialos después. Un snapshot referenciado por más de una AMI se conserva igual.

Nada de esto tienes que hacerlo a mano. Las lifecycle policies de Image Builder aplican acciones de deprecar, deshabilitar y borrar sobre las imágenes que produjo un pipeline, con reglas por antigüedad y por cantidad, más reglas de exclusión para proteger las imágenes que tienes que conservar. Amazon Data Lifecycle Manager cubre el mismo terreno para AMIs respaldadas por EBS en general, incluidas las que no construiste con Image Builder.

Consejos para el examen

• "Detener los lanzamientos ahora, y poder deshacerlo después" es deshabilitar. "Marcarla como obsoleta pero que siga funcionando" es deprecar. "Borrarla" es deregistrar. Las opciones que mezclan los efectos son los distractores.
• Si un enunciado dice que un grupo de Auto Scaling sigue lanzando desde una imagen vieja después de que el equipo la deprecó, eso es el comportamiento esperado, no un bug. Deprecar oculta una AMI de los listados; nunca bloquea un lanzamiento por ID.
• Deregistrar no corta la factura de snapshots por sí solo. Cualquier respuesta que trate la deregistración como una limpieza completa está mal.
• Compartir una AMI cifrada exige una llave KMS administrada por el cliente más un permiso para la cuenta destino. Si el enunciado menciona la llave administrada por AWS, el sharing no puede funcionar, y la respuesta pasa por copiar con tu propia llave.
• Un pipeline de Image Builder que falla sus tests no distribuye nada. Si una pregunta plantea por qué nunca apareció una AMI nueva en la región de DR, un test component fallido es el sospechoso principal, junto con que la región simplemente no esté en las distribution settings.
• "Construir solo cuando la imagen base se parcha" es el ajuste de actualizaciones de dependencias del schedule, y depende del versionado semántico en la recipe.
• Image Builder en sí es gratis. Los cargos vienen de las instancias de build y test, los snapshots, los logs, Inspector y ECR.
• Presta atención al reparto entre hornear y bootstrapear en los enunciados de escenario. Tiempos de arranque largos apuntan a hornear; configuración por ambiente apunta a bootstrapear.

La idea que conviene llevarse es que una imagen es un artefacto de build con versión, suite de tests y fecha de vencimiento, no un servidor que alguien configuró alguna vez. Ese encuadre es lo que vuelve coherente al dominio entero: la imagen se construye desde un archivo, se prueba antes de salir, se distribuye por política y se retira con un calendario.

Todo en esta lección asumió que la unidad que despachas es una máquina. La próxima lección cambia ese supuesto. Cuando la máquina ya existe y lo único que cambia es la aplicación, despachas una imagen de contenedor, y casi todas las ideas de aquí reaparecen en una forma más chica y más rápida.