Construcción de service mesh con AWS App Mesh - Control de comunicación entre microservicios y observabilidad
Presentamos cómo configurar de forma declarativa despliegues canary con sidecar Envoy, políticas de reintento y cifrado mTLS, y cómo visualizar las dependencias entre servicios con la integración de X-Ray.
Descripcion general de App Mesh y discontinuacion del servicio
App Mesh es un service mesh que controla y monitorea la comunicacion entre microservicios. Coloca proxies Envoy como sidecar en cada servicio y enruta el trafico entre servicios a traves del proxy. Sin modificar el codigo de la aplicacion, se pueden configurar pesos de trafico, reintentos, timeouts y circuit breakers. Sin embargo, AWS anuncio en septiembre de 2024 que App Mesh ya no acepta nuevos clientes y recomienda a los usuarios existentes planificar la migracion antes del fin del servicio. Para proyectos nuevos, no adopte App Mesh; en su lugar elija ECS Service Connect o Amazon VPC Lattice. Los usuarios existentes deben desarrollar un plan de migracion antes de la fecha de fin del servicio.
Control de trafico y observabilidad
Con el enrutador virtual se configuran pesos de trafico, permitiendo controles como enviar el 10% del trafico a una nueva version en un despliegue canary. Cambiando los pesos gradualmente (10% -> 25% -> 50% -> 100%), se puede migrar el trafico de forma segura. Las politicas de reintento se definen de forma declarativa, configurando hasta 3 reintentos con backoff exponencial ante errores HTTP 503. El circuit breaker se implementa mediante deteccion de valores atipicos, excluyendo temporalmente del enrutamiento los endpoints cuya tasa de error supera el umbral. Con la integracion de X-Ray, el proxy Envoy envia automaticamente datos de rastreo, permitiendo visualizar las cadenas de llamadas entre servicios, la latencia y las tasas de error. Con las metricas de CloudWatch se puede monitorear el numero de solicitudes, la latencia y la tasa de error por servicio.
mTLS y control de acceso
App Mesh puede cifrar la comunicacion entre proxies Envoy con mTLS. Al configurar certificados emitidos por ACM Private CA en los nodos virtuales, se realiza autenticacion mutua en el handshake entre proxies, previniendo la suplantacion de identidad. Mediante SDS (Secret Discovery Service), la rotacion de certificados tambien se automatiza. En el control de acceso, se definen explicitamente los servicios permitidos como backend de los nodos virtuales, bloqueando comunicaciones no intencionadas entre servicios. Los registros de acceso de Envoy se envian a CloudWatch Logs, permitiendo auditar que servicio accedio a que endpoint. Para comprender en profundidad el diseno de redes de App Mesh, los libros especializados (Amazon) son utiles.
Estructura de precios y optimizacion de App Mesh
App Mesh en si no genera cargos adicionales. El costo depende de los recursos de computo (CPU y memoria) consumidos por el proxy Envoy. Como funciona como sidecar de tareas ECS o Pods EKS, es importante dimensionar adecuadamente los recursos asignados al proxy en la definicion de tarea. La referencia es 256 MB de memoria y 0.25 vCPU por proxy, pero los servicios con alto volumen de trafico pueden requerir mas. Si se habilita el rastreo con X-Ray, se generan costos de almacenamiento de datos de rastreo, por lo que se ajusta la tasa de muestreo para equilibrar costos y observabilidad.
Destinos de migracion - ECS Service Connect y VPC Lattice
AWS recomienda dos destinos de migracion desde App Mesh: ECS Service Connect y Amazon VPC Lattice. ECS Service Connect se especializa en comunicacion entre servicios dentro de ECS y, como App Mesh, esta basado en Envoy pero con configuracion del plano de control significativamente simplificada. No se necesitan definiciones de nodos virtuales ni enrutadores virtuales; simplemente agregar serviceConnectConfiguration a la definicion del servicio ECS habilita descubrimiento de servicios, balanceo de carga y reintentos. VPC Lattice proporciona comunicacion entre servicios a traves de limites de VPC, enrutando entre diferentes tipos de computo incluyendo ECS, EKS, Lambda y EC2. No requiere proxies sidecar como Envoy; unirse a una red de servicios VPC Lattice establece la conectividad, reduciendo dramaticamente la carga operativa. Como criterio de seleccion, use Service Connect para comunicacion confinada dentro de ECS, y VPC Lattice para escenarios multi-VPC o multi-cuenta con tipos de computo heterogeneos.
Decisiones de diseno y consideraciones en la migracion
La decision de diseno principal al migrar desde App Mesh es como replicar los despliegues canary existentes (pesos de trafico). ECS Service Connect no soporta directamente enrutamiento ponderado entre servicios, asi que use despliegues Blue/Green de CodeDeploy (nativo de ECS) como alternativa. VPC Lattice soporta target groups ponderados para division de trafico, proporcionando control similar a los enrutadores virtuales de App Mesh. Para mTLS, ECS Service Connect habilita TLS automaticamente pero tiene limitaciones para especificar CAs personalizadas para autenticacion mutua (mTLS). VPC Lattice proporciona nativamente autorizacion entre servicios a traves de politicas de autenticacion IAM, logrando control de comunicacion zero-trust mediante un enfoque diferente al mTLS. La migracion debe realizarse incrementalmente. La estrategia segura es construir primero los nuevos servicios en el destino de migracion, mantener compatibilidad de comunicacion entre los servicios existentes y los servicios de App Mesh, y cambiar secuencialmente. Evite migrar todos los servicios simultaneamente ya que conlleva alto riesgo.
Resumen
App Mesh es un service mesh que controla y monitorea la comunicacion entre microservicios con proxies Envoy. Configura de forma declarativa despliegues canary con pesos de trafico, politicas de reintento y circuit breakers, y cifra las comunicaciones con mTLS. Sin embargo, dado que AWS ha dejado de aceptar nuevos clientes y planea finalizar el servicio, los proyectos nuevos deben elegir ECS Service Connect (para comunicacion intra-ECS) o Amazon VPC Lattice (para comunicacion cross-VPC/cross-account), y los usuarios existentes deben desarrollar planes de migracion tempranamente.