Building a Service Mesh with AWS App Mesh - Controlling and Observing Microservice Communication
Learn how to declaratively configure canary deployments, retry policies, and mTLS encryption using Envoy sidecars, and visualize service dependencies with X-Ray integration.
Overview of App Mesh and Service Discontinuation
App Mesh is a service mesh that controls and monitors communication between microservices. It deploys an Envoy proxy as a sidecar alongside each service, routing inter-service traffic through the proxies. Without modifying application code, you can configure traffic weighting, retries, timeouts, and circuit breakers. However, AWS announced in September 2024 that App Mesh is no longer accepting new customers and recommends existing users plan migration ahead of service end-of-life. For new projects, do not adopt App Mesh; instead choose ECS Service Connect or Amazon VPC Lattice. Existing users need to develop a migration plan before the service end date.
Traffic Control and Observability
Virtual routers let you configure traffic weighting for canary deployments, such as routing 10% of traffic to a new version. By gradually adjusting the weights (10% to 25% to 50% to 100%), you can safely migrate traffic. Retry policies allow you to declaratively define settings like retrying up to 3 times on HTTP 503 errors with exponential backoff. Circuit breakers use outlier detection to temporarily remove endpoints from the routing pool when their error rate exceeds a threshold. X-Ray integration enables Envoy proxies to automatically send trace data, visualizing call chains, latency, and error rates between services. CloudWatch metrics let you monitor request counts, latency, and error rates on a per-service basis.
mTLS and Access Control
App Mesh can encrypt communication between Envoy proxies using mTLS. When you configure certificates issued by ACM Private CA on virtual nodes, mutual authentication occurs during the proxy handshake, preventing impersonation. SDS (Secret Discovery Service) also automates certificate rotation. For access control, you explicitly define which services are allowed as backends for virtual nodes, blocking unintended inter-service communication. Envoy access logs can be sent to CloudWatch Logs to audit which services accessed which endpoints. To deepen your understanding of App Mesh network design, specialized books on Amazon can be helpful.
App Mesh Pricing and Optimization
App Mesh itself incurs no additional charges. Costs depend on the computing resources (CPU and memory) consumed by the Envoy proxies. Since they run as sidecars in ECS tasks or EKS Pods, it is important to properly size the resources allocated to the proxy in your task definition. A typical baseline is 256 MB of memory and 0.25 vCPU per proxy, though services with high traffic volumes may need more. When enabling X-Ray tracing, trace data storage costs apply, so adjust the sampling rate to balance cost and observability.
Migration Targets - ECS Service Connect and VPC Lattice
AWS recommends two migration targets from App Mesh: ECS Service Connect and Amazon VPC Lattice. ECS Service Connect specializes in inter-service communication within ECS and, like App Mesh, is Envoy-based but with significantly simplified control plane configuration. Virtual node and virtual router definitions are unnecessary; simply adding serviceConnectConfiguration to your ECS service definition enables service discovery, load balancing, and retries. VPC Lattice, on the other hand, provides inter-service communication across VPC boundaries, routing across different compute types including ECS, EKS, Lambda, and EC2. It requires no sidecar proxies like Envoy; joining a VPC Lattice service network establishes connectivity, dramatically reducing operational overhead. As a selection criterion, use Service Connect for communication confined within ECS, and VPC Lattice for multi-VPC or multi-account scenarios spanning heterogeneous compute types.
Migration Design Decisions and Considerations
The primary design decision when migrating from App Mesh is how to replicate existing canary deployments (traffic weighting). ECS Service Connect does not directly support weighted routing between services, so use CodeDeploy Blue/Green deployments (ECS native) as an alternative. VPC Lattice supports weighted target groups for traffic splitting, providing control similar to App Mesh virtual routers. For mTLS, ECS Service Connect automatically enables TLS but has limitations on specifying custom CAs for mutual authentication (mTLS). VPC Lattice natively provides inter-service authorization through IAM auth policies, achieving zero-trust communication control through a different approach than mTLS. Migration should be performed incrementally. The safe strategy is to build new services on the migration target first, maintain communication compatibility between existing services and App Mesh services, and switch over sequentially. Avoid migrating all services simultaneously as this carries high risk.
Summary
App Mesh is a service mesh that controls and monitors microservice communication through Envoy proxies. It enables canary deployments via traffic weighting, retry policies, and circuit breakers through declarative configuration, while encrypting communication with mTLS. However, since AWS has stopped accepting new customers and plans to end the service, new projects should choose ECS Service Connect (for intra-ECS communication) or Amazon VPC Lattice (for cross-VPC/cross-account communication), and existing users should develop migration plans early.