AWS App Mesh
An Envoy proxy-based service mesh that visualizes and controls inter-microservice communication, centrally applying traffic management and retry policies
Overview
AWS App Mesh is a fully managed service mesh that uses Envoy proxy as its data plane. It transparently intercepts communication between microservices running on ECS, EKS, and EC2, applying traffic routing, retry and timeout policies, circuit breakers, and mTLS encryption without application code changes. Integration with X-Ray and CloudWatch enables real-time visualization of latency, error rates, and request volume for inter-service communication.
Mesh Components and Traffic Routing
App Mesh architecture consists of four elements: meshes (logical boundaries), virtual services (abstract representations of services), virtual nodes (actual workloads), and virtual routers (routing rules). By defining routes on virtual routers, conditional routing based on HTTP headers, path prefixes, and methods becomes possible. For canary deployments, weighted routing directs 5% of traffic to a new version's virtual node while monitoring error rates and gradually increasing the ratio. Retry policies define maximum retry counts and backoff intervals per virtual node for HTTP 503 and connection errors, enabling automatic recovery from transient failures. Native gRPC protocol support allows routing and health checks based on gRPC status codes.
Zero-Trust Communication with mTLS and Observability
App Mesh encrypts communication between Envoy proxies using mTLS (mutual TLS), achieving zero-trust inter-service communication. Certificate management uses ACM Private CA or Envoy's SDS (Secret Discovery Service), with automated certificate rotation. For observability, metrics generated by Envoy (request counts, latency distributions, error rates) are sent to CloudWatch, and trace data sent to X-Ray visualizes inter-service call chains. Envoy access logs can be output to CloudWatch Logs or S3 for individual request-level debugging. For Grafana and Prometheus integration, metrics can be scraped directly from Envoy's stats endpoint.
Deployment Patterns and Operational Design for ECS and EKS
In ECS environments, services join App Mesh by adding an Envoy sidecar container and proxyConfiguration to the task definition. Using the App Mesh Controller for ECS automates integration with service discovery (Cloud Map), automatically registering new tasks to virtual nodes upon launch. In EKS environments, the App Mesh Controller for Kubernetes provides CRDs (Custom Resource Definitions) for declaratively managing virtual services and virtual nodes through Kubernetes manifests. A Mutating Webhook that auto-injects Envoy sidecars into Pods facilitates adoption for existing workloads. Operationally, note that Envoy proxy resource consumption (CPU and memory) is added per service, requiring advance estimation of task and Pod resource allocations. In large-scale environments, Envoy configuration propagation may lag by several seconds, making retry design important to handle routing inconsistencies immediately after deployments.