What Is Amazon App Mesh?

Service mesh – A service mesh is a logical boundary for network traffic between the services that reside within it. In the example, the mesh is named apps, and it contains all other resources for the mesh. For more information, see Service Meshes.

Virtual services – A virtual service is an abstraction of an actual service that is provided by a virtual node, directly or indirectly, by means of a virtual router. In the illustration, two virtual services represent the two actual services. The names of the virtual services are the discoverable names of the actual services. When a virtual service and an actual service have the same name, multiple services can communicate with each other using the same names that they used before App Mesh was implemented. For more information, see Virtual services.

Virtual nodes – A virtual node acts as a logical pointer to a discoverable service, such as an Amazon ECS or Kubernetes service. For each virtual service, you will have at least one virtual node. In the illustration, the servicea.apps.local virtual service gets configuration information for the virtual node named serviceA. The serviceA virtual node is configured with the servicea.apps.local name for service discovery. The serviceb.apps.local virtual service is configured to route traffic to the serviceB and serviceBv2 virtual nodes through a virtual router named serviceB. For more information, see Virtual nodes.

Virtual routers and routes – Virtual routers handle traffic for one or more virtual services within your mesh. A route is associated to a virtual router. The route is used to match requests for the virtual router and to distribute traffic to its associated virtual nodes. In the previous illustration, the serviceB virtual router has a route that directs a percentage of traffic to the serviceB virtual node, and a percentage of traffic to the serviceBv2 virtual node. You can set the percentage of traffic routed to a particular virtual node and change it over time. You can route traffic based on criteria such as HTTP headers, URL paths, or gRPC service and method names. You can configure retry policies to retry a connection if there is an error in the response. For example, in the illustration, the retry policy for the route can specify that a connection to serviceb.apps.local is retried five times, with ten seconds between retry attempts, if serviceb.apps.local returns specific types of errors. For more information, see Virtual routers and Routes.

Proxy – You configure your services to use the proxy after you create your mesh and its resources. The proxy reads the App Mesh configuration and directs traffic appropriately. In the illustration, all communication from servicea.apps.local to serviceb.apps.local goes through the proxy deployed with each service. The services communicate with each other using the same service discovery names that they used before introducing App Mesh. Because the proxy reads the App Mesh configuration, you can control how the two services communicate with each other. When you want change the App Mesh configuration, you don’t need to change or redeploy the services themselves or the proxies. For more information, see Envoy image.

Getting Started with App Mesh and Amazon ECS

Getting Started with App Mesh and Kubernetes

Getting Started with App Mesh and Amazon EC2