Introducción
AWS App Runner dejará de aceptar nuevos clientes desde el 30 de abril de 2026. Aunque el servicio seguirá operativo para cuentas actuales, la guía oficial ya empuja una transición hacia ECS Express Mode. Para equipos DevOps, esto exige planificar migración, costos y controles antes de que la deuda técnica se vuelva urgencia.
El cambio no es menor: AWS confirmó que App Runner entra en etapa de mantenimiento para adopción, dentro de un paquete más amplio de ajustes de ciclo de vida en varios servicios. En lenguaje operativo, significa que el servicio no se apaga hoy, pero deja de ser una apuesta futura para nuevas cuentas y nuevos proyectos greenfield.
Cuando una plataforma administrada entra en esta fase, la prioridad para ingeniería no es solo “seguir funcionando”, sino decidir cuándo y cómo migrar con bajo riesgo. Ese trabajo incluye arquitectura, IAM, redes, observabilidad, seguridad y gestión de costos. También implica alinear a desarrollo, seguridad y operaciones bajo un mismo calendario técnico.
Qué ocurrió
La documentación oficial de AWS indica que App Runner no aceptará nuevos clientes a partir del 30 de abril de 2026. Los clientes existentes podrán continuar usando el servicio, incluyendo la creación de nuevos recursos, pero sin expectativa de nuevas funcionalidades.
En paralelo, AWS recomienda explícitamente una alternativa: Amazon ECS Express Mode. La guía de migración propone ejecutar ambos entornos en paralelo y mover tráfico progresivamente con DNS ponderado, en lugar de un corte directo.
Este aviso aparece en el contexto de una actualización más amplia de disponibilidad de servicios en AWS, con estados de maintenance, sunset y end of support para distintos productos y features. Dentro de ese paquete también aparecen cambios para SNS Message Data Protection y sunset de WorkMail, lo que refuerza el mensaje de que 2026 será un año de reordenamiento de portafolio en servicios administrados.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para equipos de plataforma, App Runner en mantenimiento cambia tres decisiones clave:
- Estandarización: deja de tener sentido impulsarlo como opción por defecto en nuevas cuentas o nuevos equipos.
- Gobernanza: hay que definir una política clara de “seguir operando” versus “migrar por oleadas”.
- Riesgo futuro: cuanto más tarde se migre, menor margen para validar rendimiento, seguridad y rollback.
Desde seguridad, el riesgo no es una brecha inmediata, sino la pérdida de evolución de controles y capacidades de integración. En compliance, también puede afectar auditorías si la organización exige plataformas con roadmap activo y soporte de largo plazo para nuevos requerimientos.
En SRE, la migración mal planificada puede introducir inestabilidad por diferencias de runtime, balanceo, health checks y observabilidad entre App Runner y ECS Express Mode. Además, cambiar de servicio suele modificar paneles, alertas y umbrales de error históricos; si eso no se ajusta de forma proactiva, el equipo puede perder visibilidad justo durante la transición.
También hay impacto en costos: mover servicios sin modelado previo puede subir gasto por sobredimensionamiento inicial de tareas, configuraciones conservadoras de escalado o uso poco optimizado de balanceadores y logs. Por eso, el análisis financiero debe formar parte de la migración desde el primer sprint.
Detalles técnicos
La guía de AWS propone una migración blue/green con coexistencia temporal:
- Inventariar parámetros de App Runner (imagen, puerto, variables, dominio, certificados).
- Crear servicio equivalente en ECS Express Mode.
- Configurar dominio y certificados en el ALB del nuevo servicio.
- Mover tráfico con Route 53 weighted routing en incrementos controlados (por ejemplo 10/90, 25/75, 50/50, 75/25, 100/0).
- Mantener App Runner 24-48 h como fallback antes del retiro definitivo.
Técnicamente, ECS Express conserva simplicidad de despliegue, pero expone más superficie operativa: roles IAM de ejecución e infraestructura, políticas de red, ALB, escalado y monitoreo. Eso ofrece más control, pero también mayor responsabilidad para el equipo.
Un aspecto sensible es la equivalencia funcional. No basta con que la aplicación “arranque”: hay que validar comportamiento bajo carga, tiempos de arranque, manejo de fallas, límites de concurrencia y trazabilidad extremo a extremo. Si la organización usa secretos administrados, políticas de egreso o inspección de tráfico, esos controles deben quedar explícitos en IaC para evitar drift entre entornos.
Otra diferencia práctica es la operación diaria. En App Runner gran parte de la complejidad estaba encapsulada; en ECS Express se simplifica el alta inicial, pero la observabilidad y la disciplina de cambios vuelven a depender mucho más del equipo. Runbooks, dashboards y automatizaciones de respuesta deben adaptarse al nuevo plano de ejecución para no degradar MTTR.
Qué deberían hacer los administradores o equipos técnicos
- Congelar nuevas implementaciones en App Runner para evitar ampliar la base a migrar.
- Crear inventario por servicio: dominios, dependencias, secretos, métricas, SLAs y costos.
- Definir una plantilla de migración repetible App Runner → ECS Express para reducir variabilidad.
- Medir equivalencia operativa: latencia, tasa de error, comportamiento de autoescalado y MTTR.
- Diseñar rollback real: pesos DNS reversibles, ventanas de observación y criterios de corte.
- Actualizar runbooks de incidentes y on-call con la nueva topología de servicio.
- Reportar riesgo ejecutivo con cronograma y costo estimado de no migrar.
Si hay ambientes regulados o contratos de disponibilidad exigentes, conviene iniciar la migración en cargas menos críticas para probar herramientas, automatizaciones y políticas de seguridad antes de mover workloads tier-1. Un enfoque por “oleadas” con criterios de salida claros (SLO, error budget, costo y seguridad) suele reducir sorpresas frente a migraciones masivas.
También es recomendable incorporar pruebas de caos y simulaciones de failover durante la etapa de coexistencia. Ese tipo de ensayo permite validar que el plan de retorno funciona de verdad y no solo en documentación.
Conclusión
App Runner no desaparece hoy, pero su cambio de disponibilidad redefine su rol estratégico. El momento óptimo para actuar es ahora: con tiempo para migrar por etapas, verificar comportamiento en producción y evitar decisiones forzadas cerca de fechas límite.
Para DevOps/SRE, la oportunidad es convertir este cambio en una mejora de plataforma: más estandarización, mejores controles y menos dependencia de servicios en ciclo de salida. Las organizaciones que arranquen temprano llegarán al cierre de ventana con menos riesgo, menos urgencia y mejor gobernanza técnica.