AWS App Mesh
Service mesh basado en el proxy Envoy que visualiza y controla la comunicación entre microservicios, aplicando gestión de tráfico y políticas de reintentos de forma centralizada
Descripción general
AWS App Mesh es un service mesh totalmente gestionado que utiliza el proxy Envoy como plano de datos. Intercepta de forma transparente la comunicación entre microservicios que se ejecutan en ECS, EKS y EC2, aplicando enrutamiento de tráfico, políticas de reintentos y timeouts, circuit breakers y cifrado mTLS sin modificar el código de la aplicación. La integración con X-Ray y CloudWatch permite visualizar en tiempo real la latencia, tasa de errores y volumen de solicitudes de la comunicación entre servicios.
Componentes del mesh y enrutamiento de tráfico
La configuración de App Mesh se compone de 4 elementos: mesh (límite lógico), virtual service (representación abstracta del servicio), virtual node (carga de trabajo real) y virtual router (reglas de enrutamiento). Definiendo rutas en el virtual router, es posible realizar enrutamiento condicional basado en encabezados HTTP, prefijos de ruta y métodos. Para despliegues canary, se configura enrutamiento ponderado enviando un 5% del tráfico al virtual node de la nueva versión, monitoreando la tasa de errores mientras se aumenta gradualmente la proporción. Las políticas de reintentos permiten definir el número máximo de reintentos y el intervalo de backoff para errores HTTP 503 o errores de conexión por virtual node, logrando recuperación automática de fallos temporales. También soporta nativamente el protocolo gRPC, permitiendo configurar enrutamiento y health checks basados en códigos de estado gRPC.
Comunicación zero-trust con mTLS y observabilidad
App Mesh cifra la comunicación entre proxies Envoy con mTLS (TLS mutuo), implementando comunicación zero-trust entre servicios. La gestión de certificados utiliza ACM Private CA o el SDS (Secret Discovery Service) de Envoy, automatizando también la rotación de certificados. En cuanto a observabilidad, las métricas generadas por Envoy (número de solicitudes, distribución de latencia, tasa de errores) se envían a CloudWatch, y el envío de datos de tracing a X-Ray visualiza las cadenas de llamadas entre servicios. También es posible configurar la salida de logs de acceso de Envoy a CloudWatch Logs o S3, útil para depuración a nivel de solicitud individual. Para la integración con Grafana o Prometheus, también se puede adoptar una configuración que hace scraping de métricas directamente desde el endpoint de stats de Envoy.
Patrones de implementación en entornos ECS/EKS y diseño operativo
En entornos ECS, se incorpora al App Mesh añadiendo un contenedor sidecar Envoy y proxyConfiguration a la definición de tarea. Utilizando App Mesh Controller for ECS, se automatiza la integración con service discovery (Cloud Map), registrando automáticamente nuevas tareas en el virtual node al iniciarse. En entornos EKS, App Mesh Controller for Kubernetes proporciona CRDs (Custom Resource Definitions), permitiendo gestionar declarativamente virtual services y virtual nodes con manifiestos de Kubernetes. Un Mutating Webhook que inyecta automáticamente el sidecar Envoy en los Pods facilita la adopción en cargas de trabajo existentes. Como consideración operativa, dado que el proxy Envoy consume recursos adicionales (CPU y memoria) por servicio, es necesario estimar previamente la asignación de recursos de tareas y Pods. En entornos a gran escala, la propagación de configuración de Envoy puede tener un retraso de varios segundos, por lo que es importante diseñar reintentos para inconsistencias de enrutamiento inmediatamente después del despliegue.