The idea of a “service mesh” has become increasingly popular over the last couple of years and the number of alternatives available has risen. There are multiple service mesh open-source projects: Istio, Linkerd, Envoy and Conduit which can be deployed on any Kubernetes environment. The AWS App Mesh can be used with microservices running on Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Container Service for Kubernetes (Amazon EKS), and Kubernetes running on Amazon EC2. The significant difference between the other solutions and App Mesh is that AWS manages the control plane and users can attach any application to the mesh just by deploying the data plane with microservices.

Its functionality and integration’s are still under development and is available to use in preview. App Mesh sets up and manages a service mesh for microservices running on AWS. To do this, App Mesh runs the open source Envoy proxy alongside each microservice container and configures the proxy to handle all communications into and out of each container.

At the core, AWS App Mesh is a solution that uses Envoy proxy. It operates at layer 3 but has the intelligence to understand HTTP, HTTPS, GRPC, and other higher-level protocols. It was written to do one thing, proxy, and do that well. To use Envoy at scale (hundreds or thousands of connections), there is a need for an entity to manage Envoy, and that is the role App Mesh plays. App Mesh can be used with any compute service in AWS (ECS, EKS, EC2). In theory, any service that can talk to the Envoy management layer can be integrated, but this depends on the integration.

App Mesh Architecture

In a general scenario when using Istio or Linkerd for service mesh, users have to manage both control plane and data plane. With App Mesh Data plane is deployed within the application while the control plane is hidden from the users which is managed by Amazon. App Mesh control plane, like any other AWS managed service, is exposed through CLI and SDK.

Any Service Mesh architecture includes a control plane: the policy and set of configurations, which control traffic. It is the “how” behind the way in which decisions are implemented and a data plane: the actual actions performed by data (network packets) into and out of a microservice, using the capabilities listed above (routing, load balancing, security, etc.). As AWS masks the control plane components from the users below are the data-plane components that has to be configured by the user.

Components