AWS retira App Mesh: así migraron 40 servicios a Istio

En pocas palabras: AWS discontinúa App Mesh el 30 de septiembre de 2026. Un equipo migró unos 40 microservicios en tres entornos y varias regiones a Istio Ambient Mesh combinado con Gateway API, separando la función de gateway y la de mesh, sin outage ni incidentes mayores.

AWS deja de dar soporte a App Mesh el 30 de septiembre de 2026. Un equipo migró 40 microservicios en tres entornos y varias regiones hacia Istio Ambient Mesh combinado con Gateway API, sin downtime ni incidentes mayores, según el caso documentado en este relato técnico publicado en dev.to.

La migración de AWS App Mesh a Istio es el proceso de reemplazar el service mesh gestionado de AWS, que pierde soporte el 30 de septiembre de 2026, por Istio Ambient Mesh, una arquitectura sin sidecar que usa un proxy por nodo llamado ztunnel para manejar mTLS. App Mesh usaba Envoy inyectado en cada pod para controlar tráfico entre microservicios en ECS, EKS y EC2.

¿Cuándo deja de funcionar AWS App Mesh y qué implica para tu infraestructura?

AWS discontinúa el soporte de App Mesh el 30 de septiembre de 2026. Así lo indica la documentación oficial: después de esa fecha no vas a poder acceder a la consola de App Mesh ni a sus recursos.

Ojo con esto: no es un aviso genérico de deprecación lejana. Quedan dos semanas: el soporte termina el 30 de septiembre de 2026. Si tu plataforma corre sobre App Mesh en producción, no hay margen para posponer la decisión.

El caso real que analizamos acá lo resume bien: “AWS is retiring App Mesh, with end of support in September 2026. Our whole platform ran on it, so we had no choice.” No había alternativa. Tocaba moverse.

¿Qué alternativas existen para reemplazar App Mesh?

Para cargas en Amazon ECS, AWS empuja hacia Amazon ECS Service Connect como camino nativo, según la propia documentación de App Mesh que redirige a esa migración. Para EKS no hay un reemplazo único impuesto por AWS, y ahí es donde el equipo del caso real tuvo que decidir por su cuenta.

No eligieron por corazonada. Armaron una lista de candidatos, acordaron criterios con peso específico cada uno, puntuaron cada opción y después construyeron una prueba de concepto solo para los finalistas. Istio Ambient Mesh ganó esa evaluación. Cubrimos ese tema en detalle en armar una arquitectura AWS de producción sólida.

Vale la aclaración: esto no es “Istio es superior en abstracto”. Es que para ese stack, con esos criterios, dio mejor puntaje. Otro equipo, con otras prioridades, podría terminar en Service Connect sin problema.

Armá tu propia matriz de decisión antes de elegir reemplazo

El método que usó el equipo del caso real —listar candidatos, ponderar criterios, puntuar y recién ahí construir una prueba de concepto— vale más que el resultado final al que llegaron. Ese resultado, Istio Ambient Mesh, responde al stack y los criterios puntuales de ese equipo. El tuyo puede ser distinto, y por eso conviene armar la matriz propia antes de copiar la conclusión ajena.

Estos son los criterios que, según lo que documentan las fuentes oficiales de AWS y el caso analizado, tiene sentido poner sobre la mesa antes de decidir:

Criterio	ECS Service Connect (nativo AWS)	Istio Ambient Mesh
Plataformas soportadas	Amazon ECS, según la ruta de migración que indica la propia documentación de App Mesh	ECS, EKS, EC2 y hasta AWS Lambda, según el blog de AWS Containers sobre Istio Ambient
Modelo de proxy	Gestionado directamente por AWS dentro de ECS	Sidecarless: un ztunnel por nodo en EC2, o como sidecar liviano en Fargate
Quién lo mantiene	AWS	Vos, o un partner como Solo.io si usás esa distribución
Portabilidad fuera de AWS	Ninguna: es un servicio propietario de ECS	Alta: Istio y Gateway API son estándares abiertos, no formato de un solo proveedor
Cuándo tiene más sentido	Si todo tu stack vive en ECS y el lock-in no es un problema para vos	Si tenés EKS, mezcla de cómputo, o querés evitar depender de un solo proveedor

Una aclaración honesta: si autorización L7 o mTLS punto a punto son tu prioridad, conviene validar esas capacidades directo contra la documentación de Service Connect antes de descartarlo por una comparación superficial. La tabla de arriba es un punto de partida, no un veredicto.

Lo que no cambia según el stack es la disciplina del proceso: poné los criterios por escrito, asigná un peso a cada uno antes de puntuar (para no terminar acomodando los números a la conclusión que ya tenías en la cabeza) y reservá la prueba de concepto para el final del proceso, no para el principio.

Por qué App Mesh hacía dos trabajos distintos sin que se notara

App Mesh combinaba dos funciones separadas bajo un mismo producto: el mesh interno (mTLS y reglas de quién puede llamar a quién) y el gateway de borde (tráfico externo entrando desde afuera). El equipo no vio esa separación hasta que tuvo que reemplazar la herramienta.

La cadena completa era API Gateway, después un VPC Link, después un NLB interno, después el Virtual Gateway de App Mesh, y recién ahí el servicio. Un solo producto resolvía las dos capas. Eso funcionó bien durante años, hasta que dejó de ser una opción.

La solución fue partir ese trabajo en dos productos independientes: Gateway API para el borde y Istio Ambient Mesh para el interior del clúster. Cada capa se puede actualizar o reemplazar sin tocar la otra, algo que con App Mesh era imposible.

Esto que parece un detalle arquitectónico es, en rigor, el motivo por el que muchos equipos van a subestimar el esfuerzo de esta migración. Si pensás en App Mesh como “una sola cosa que hay que reemplazar por otra cosa”, vas a buscar un sustituto uno a uno y no lo vas a encontrar, porque no existe una herramienta que combine esas dos funciones de la misma manera. El primer paso real no es elegir el reemplazo: es mapear qué funciones cumple tu App Mesh actual, por separado, antes de tocar nada.

Cómo migrar de AWS App Mesh a Istio sin downtime: la estrategia de dos fases

La migración se hizo en dos fases separadas, sin mezclarlas nunca. Primero el gateway, después el mesh interno, cada una con su propio rollback. Para más detalles técnicos, mirá desplegar servicios en AWS con Coolify.

• Fase 1, cutover del gateway: movieron el tráfico externo del Virtual Gateway de App Mesh a un gateway de Kubernetes basado en Gateway API, sin tocar ni un sidecar. El tráfico servicio a servicio quedó intacto.
• Fase 2, migración del mesh: cada servicio se movió de su sidecar de App Mesh a Istio Ambient Mesh, en oleadas, empezando por servicios “hoja” (sin nada dependiendo de ellos hacia adentro), siguiendo por servicios de base compartida, después capas intermedias, y cerrando con los núcleos centrales.

El servicio de autenticación quedó para el final, a propósito, porque un componente externo lo llamaba directo a través del gateway viejo. Migrarlo antes hubiera roto cada request de autorización del sistema entero.

Ejemplo hipotético: cómo se vería esto en un equipo más chico

Ejemplo hipotético e ilustrativo, no basado en un caso real: imaginemos un equipo con 8 microservicios en un único clúster EKS, sin múltiples regiones ni ambientes separados. La lógica de dos fases se mantiene, pero se comprime.

Fase 1 seguiría siendo mover el gateway de borde primero, verificando que el nuevo gateway responda correctamente en un endpoint interno antes de tocar el tráfico real. Fase 2 armaría el grafo de dependencias de esos 8 servicios: probablemente 2 o 3 sin nada que dependa de ellos hacia adentro (los primeros candidatos), 1 servicio de autenticación que un componente externo llama directo (el último, como en el caso real), y el resto en el medio.

La diferencia con un caso de 40 servicios no está en la lógica, está en el margen de error: con menos servicios, un problema durante la ventana en modo PERMISSIVE afecta a una porción proporcionalmente mayor del tráfico total. Eso no cambia la estrategia, pero sí sugiere acortar el soak period o arrancar por el servicio de menor criticidad, no necesariamente por el más simple de mover.

Los problemas técnicos reales al convivir dos service meshes

El problema central es que las dos CA no confían entre sí. App Mesh autentica con certificados propios; Istio Ambient usa identidades SPIFFE envueltas en un túnel HTTP/2 llamado HBONE. Una conexión entre un Envoy de App Mesh y un ztunnel de Istio falla el handshake TLS directamente.

Eso significa que no existe la opción de “correr los dos meshes en paralelo y mover tráfico de a poco” para un mismo servicio. Cada servicio flipea de una: mesh viejo apagado, mesh nuevo prendido, en el mismo instante.

Mientras tanto, servicios viejos y nuevos tenían que hablarse igual. La solución fue el modo PERMISSIVE en ambas direcciones: del lado nuevo, ztunnel acepta tanto HBONE como TCP plano; del lado viejo, los listeners de Envoy se configuraron para aceptar su propio TLS y TCP plano también. Esa ventana sin mTLS estricto se mantuvo chica a propósito, acotada a pares de servicios en medio de un flip, por uno o dos días como máximo.

Vale marcarlo sin vueltas: ese modo PERMISSIVE es, durante la ventana que dura, una relajación real de la seguridad del tráfico interno, no un truco que resuelve el problema sin costo. Es una decisión consciente de aceptar un riesgo acotado a cambio de evitar un cutover simultáneo de 40 servicios. Si tu política de seguridad interna no tolera ningún tramo sin mTLS estricto, este enfoque específico no te sirve tal cual, y vas a necesitar otra estrategia, probablemente con ventanas de mantenimiento más grandes y menos margen de paralelismo.

Hubo un tercer problema que casi genera un incidente. Istio permite políticas de autorización L4 que solo dejan pasar identidades SPIFFE específicas, y esas políticas son deny by default: lo que no matchea una regla, se rechaza. Los servicios que todavía estaban en App Mesh no tenían identidad SPIFFE, así que no matcheaban nada y quedaban bloqueados, incluso en modo PERMISSIVE, porque PERMISSIVE controla el cifrado, no la autorización. La regla que siguieron fue simple: nada de políticas de autorización mientras haya algún caller en el mesh viejo. Recién las activaron todas juntas, al final, cuando cada servicio ya tenía identidad SPIFFE. Te puede servir nuestra cobertura de los checks de seguridad en tu pipeline AWS.

Qué aprender de esta migración de 40 microservicios sin incidentes

La lección que más pesó fue escribir el plan antes de tocar nada. No una idea suelta en la cabeza de alguien, sino un documento revisado por el equipo, con el orden exacto de cada servicio, qué tiene que estar listo antes, y el punto exacto donde ya no hay vuelta atrás.

Casi todos los problemas de este caso se encontraron planificando, no en producción. Encontrarlos en papel sale mucho más barato.

Otras dos ideas se repiten en el relato: cambiar una capa a la vez (gateway primero, mesh después) y usar soak periods de 48 a 72 horas por servicio antes de avanzar a la próxima oleada. Si tu equipo administra infraestructura propia además de AWS, conviene tener un entorno de staging confiable para probar este tipo de cambios sin arriesgar producción.

Errores comunes al migrar de App Mesh

• Mezclar el cutover del gateway con la migración del mesh: tratarlos como un solo cambio multiplica el radio de impacto si algo sale mal. Separarlos, con rollback independiente cada uno, fue lo que permitió cero outages en el caso real.
• Crear políticas de autorización SPIFFE antes de terminar la migración: una política ALLOW en Istio es deny by default, y los servicios sin identidad SPIFFE quedan bloqueados aunque estén en modo PERMISSIVE. Activá esas políticas recién cuando todos los callers tengan identidad.
• Dejar direcciones hardcodeadas sin resolver antes de migrar: si los servicios apuntan a nombres de Cloud Map guardados en un parameter store, cambialos a DNS de Kubernetes antes de tocar el mesh. Y no te olvides: los consumidores necesitan reiniciar para tomar el valor nuevo, algo fácil de pasar por alto.
• Migrar el servicio de autenticación temprano en la secuencia: si un componente externo lo llama directo, migrarlo antes de actualizar ese componente rompe la autorización de todo el sistema. Va al final, en ventana de mantenimiento.

Preguntas Frecuentes

¿Cuándo termina el soporte de AWS App Mesh?

El soporte de AWS App Mesh termina el 30 de septiembre de 2026, según la documentación oficial de AWS. Después de esa fecha no vas a poder acceder a la consola ni a los recursos de App Mesh.

¿A qué reemplazo migrar desde AWS App Mesh?

Para ECS, AWS orienta hacia Amazon ECS Service Connect como reemplazo nativo. Para EKS no hay un camino único impuesto, y un caso real documentado eligió Istio Ambient Mesh tras evaluar varias opciones con criterios ponderados y una prueba de concepto. Lo explicamos a fondo en cómo responder ante una clave AWS comprometida.

¿Cómo migrar de AWS App Mesh a Istio sin tener downtime?

Separando la migración en dos fases independientes: primero el gateway de borde (de Virtual Gateway a Gateway API), después el mesh interno servicio por servicio en oleadas. Cada fase tiene su propio rollback, y eso fue clave para llegar a cero outages en un caso de 40 servicios.

¿Qué es Istio Ambient Mesh y en qué se diferencia de un service mesh con sidecar?

Istio Ambient Mesh es un modo de Istio que elimina el sidecar Envoy por pod y usa un proxy compartido por nodo llamado ztunnel, que maneja mTLS con identidades SPIFFE para todos los pods de ese nodo. Esto reduce el uso duplicado de CPU y memoria que generaba tener un Envoy dentro de cada pod.

¿Qué alternativas recomienda AWS para reemplazar App Mesh en ECS y EKS?

Para ECS, la documentación de AWS App Mesh dirige explícitamente a la migración hacia Amazon ECS Service Connect. Para EKS, AWS no impone un reemplazo oficial único, por lo que equipos con clústeres EKS suelen evaluar opciones como Istio, incluyendo su modo Ambient Mesh sin sidecar.

Conclusión

Quedan dos semanas: el soporte termina el 30 de septiembre de 2026. Si tu plataforma todavía corre sobre esa herramienta, la decisión ya no es si migrar, sino con qué criterio y en qué orden. El caso de los 40 microservicios muestra que el tiempo que se invierte en el plan, no en el código, es lo que termina evitando el incidente.

Lo concreto para vos: definí primero qué hace realmente tu App Mesh actual (¿solo mesh interno, o también gateway de borde?), armá una matriz de criterios propia antes de elegir reemplazo usando la tabla de más arriba como punto de partida, y probá el flip de un solo servicio antes de tocar el resto. Ese único servicio de prueba te va a mostrar buena parte de los problemas que vas a encontrar en los otros que te queden.

Fuentes

• AWS App Mesh User Guide – aviso oficial de fin de soporte, 30 de septiembre de 2026
• AWS Is Retiring App Mesh. Here Is How We Moved 40 Services – caso real de migración de 40 microservicios
• AWS App Mesh FAQs – documentación oficial de funcionalidades
• Transforming Istio into an enterprise-ready service mesh for Amazon ECS – blog oficial de AWS sobre Istio Ambient Mesh