Cambiar la AMI que usan tus instancias equivale a cambiar el cimiento de tu servicio mientras sigue funcionando. Hacerlo mal significa cortes; hacerlo bien es casi invisible para el usuario. La buena noticia: existen patrones probados que hacen esta migración segura y reversible.
La base común es no editar instancias vivas, sino lanzar instancias nuevas con la AMI nueva y trasladar el tráfico de forma controlada.
Antes de migrar: prepara el terreno
- Prueba la nueva AMI en un entorno de staging idéntico a producción.
- Health checks fiables: define comprobaciones que confirmen que una instancia nueva está realmente sana.
- Plan de rollback: ten lista la versión anterior y el procedimiento para volver a ella.
- Observabilidad: métricas y alertas para detectar regresiones al instante.
Estrategias de migración sin downtime
| Estrategia | Cómo funciona | Ideal para |
|---|---|---|
| Rolling update | Reemplaza instancias por lotes, poco a poco | Servicios en Auto Scaling Group |
| Blue/Green | Levantas un entorno nuevo y cambias el tráfico de golpe | Migraciones con rollback instantáneo |
| Canary | Envías un porcentaje pequeño de tráfico a la versión nueva | Validar en producción con bajo riesgo |
Tres patrones para cambiar de AMI sin interrumpir el servicio.
Rolling update
Actualizas el Launch Template con la nueva AMI y el Auto Scaling Group reemplaza las instancias por tandas: lanza nuevas, espera a que pasen el health check y retira las antiguas. Sencillo y sin infraestructura extra, aunque durante un rato conviven ambas versiones.
Blue/Green
Levantas un entorno paralelo (green) con la nueva AMI mientras el actual (blue) sigue sirviendo. Cuando green está validado, rediriges el tráfico en el balanceador o en el DNS. Si algo falla, vuelves a blue en segundos. Es el patrón con rollback más rápido, a cambio de duplicar recursos temporalmente.
Canary
Envías una pequeña fracción del tráfico a instancias con la nueva AMI y observas. Si las métricas se mantienen, aumentas el porcentaje progresivamente hasta el 100 %. Minimiza el radio de impacto de un problema inesperado.
Después de migrar
- Vigila métricas y logs durante un tiempo prudencial antes de dar por buena la migración.
- Marca la AMI antigua como obsoleta para que no se relance por error.
- Documenta la versión desplegada y el motivo del cambio.
- No borres la imagen anterior de inmediato: consérvala por si necesitas rollback.
Preguntas frecuentes
¿Qué estrategia es mejor para cero downtime?
Blue/Green ofrece el rollback más rápido; rolling update es más sencillo y económico; canary minimiza el riesgo validando en producción. La elección depende de tu tolerancia al riesgo y de tu presupuesto de infraestructura.
¿Necesito duplicar la infraestructura para migrar?
Solo con blue/green, y de forma temporal. Con rolling update o canary reutilizas el mismo grupo y vas reemplazando instancias, sin duplicar todo el entorno.
¿Cómo garantizo poder volver atrás?
Conserva la AMI anterior y su Launch Template, define health checks fiables y ten el procedimiento de rollback probado antes de empezar la migración.
En imaxe.cloud versionamos nuestras imágenes para que migrar entre versiones sea predecible y reversible.
