App Mesh is a fully managed service mesh and provides a logical boundary for network traffic between the services that reside within it. App Mesh standardizes how your services communicate, giving you end-to-end visibility and ensuring high availability for your applications. App Mesh, along with enabling a rich set of capabilities to manage east-west, inter-service communications, also provides ingress support and helps manage north-south traffic entering the mesh via virtual gateways and gateway routes. Virtual gateways provide access to resources outside your mesh, to resources within the mesh. Gateway routes specify rules for routing incoming traffic to services within the mesh.
In this blog post, we will discuss: existing App Mesh ingress functionalities as well as recent enhancements to the virtual gateway and gateway routes. Additionally, we will demonstrate how these capabilities enable developers to concentrate their efforts on rapidly building business functions while giving flexible controls to operators for customizing and directing incoming requests to the new functions.
Consider a sample Vinyl web store application to better understand the new functionalities. The image below depicts a frontend that powers a Vinyl web page or a mobile app user interface (vinyl-web-app). In order to complete its task, the frontend communicates with the backend’s gRPC-based data provider application (vinyl-data-app). The online shop may be able to interface with numerous marketplace sellers by using the same backend, gRPC data application (market-place-apps). Customers may use the Vinyl app to explore and purchase old and/or new records from thousands of different labels, genres, and artists. The checkout application (vinyl-checkout-app) drives purchasing functions and interfaces with third-party cloud payment services such as Stripe. These Vinyl apps may be microservices running on Amazon Elastic Kubernetes Service (Amazon EKS) or Amazon Elastic Container Service (Amazon ECS), or they may be deployed on EC2.
Before we get into the specifics of the enhancements, let’s go over the mesh logical constructs in relation to the Vinyl web store application. In addition, we will go through the App Mesh network flow and existing route capabilities. The diagram below depicts the logical flow of traffic across mesh components such as virtual nodes, virtual services, virtual routers, routes, and, finally, virtual gateways and gateway routes.
Let’s begin by working backwards given a sample Vinyl web store application and how inter-service communications is managed. A virtual node acts as a logical point of reference for a particular task group, such as an Amazon ECS or Kubernetes service. The next component is the virtual service. Virtual services act as virtual pointers to your applications and are the discoverable service names your applications use to reach the endpoints defined in your mesh. A virtual service represents an application, but an application can also have multiple versions. For example, you are planning to perform A/B tests and have deployed two different versions of Vinyl web applications, vinyl-web-app-v1 and vinyl-web-app-v2. Each version is represented by a separate virtual node. If a virtual service has multiple virtual nodes, you will define how traffic is routed between multiple virtual nodes using a virtual router. Virtual routers handle traffic routing based on specific rules; these rules are called routes. A virtual router needs to have at least one route. The routing logic can be based on different criteria such as HTTP headers, URL paths, or gRPC service and method names. If you are new to App Mesh, it may be beneficial to review the App Mesh user guide.
As mentioned earlier, ingress within App Mesh is configured through virtual gateways and gateway routes. Virtual gateways enable resources outside the mesh to communicate with services within the mesh by deploying a set of envoy proxies. All external traffic gets into the cluster through a load balancer, when configured (not must), that routes traffic to the envoy proxies. It acts as the gateway, and traffic is routed to the corresponding virtual services as defined in the gateway routes.
Gateway routes associated with the virtual gateway specify the HTTP/HTTP2/gRPC request path to be matched and on matching, the destination virtual service is picked. As shown in the image below, when the request arrives at gateway ‘/’, the request is routed to vinyl-web service. The same gateway endpoint can be used to call a vinyl-checkout service matching the prefix ‘/checkout’. For gRPC, the service name on the gateway route should match the service name on the route to reach the destination virtual node.
As seen in the image above, the Vinyl web store virtual gateway is configured with Amazon ALB and vinyls.buy.com. The web app can be accessed at ‘vinyls.buy.com/’. When the request arrives at the virtual gateway and gateway route, it undergoes two types of rewrites. The first is hostname: an incoming request ‘vinyls.buy.com/’ is matched with path ‘/‘, and service “vinyl-web”, and rewritten as ‘vinyl-web.discs.svc.cluster.local/’ when it arrives at a virtual router. The second is path: an incoming request to ‘vinyls.buy.com/checkout/payments’ is rewritten as ‘vinyl-checkout.discs.svc.cluster.local/payments’.
Ingress route enhancements
With that as context, let’s go into the virtual gateway and gateway route enhancements. The enhancements now allow more control on incoming request and configuring complex routing logic at gateway routes. This allows customers to scale without having to change the services to handle requests from multiple domains and paths. The enhancements are separated into two groups: the hostname and header match, and rewrite rules for hostname and path, utilizing hostname and header match features in rewriting rules.
Hostname and header match
The virtual gateway’s current gateway routes describe simply the path to be matched on an incoming request. Currently, this match criterion is based on the path for HTTP and HTTP2, as well as the service name for gRPC. The enhancements enable you to match requests on the basis of the hostname, the headers or metadata, and the method name.
Hostname
The hostname field allows you to match the hostname from an incoming request to route to the target virtual service. For a hostname, you can use exact, suffix, and prefix matches.You might choose to register your application under different domains, m.vinyls.buy.com and vinyls.buy.com. You can then use the hostname match field to route traffic to specific target virtual services.
HTTP/HTTP2 headers & gRPC metadata
The headers field allows you to match values for HTTP and HTTP2 headers, as well as metadata for gRPC requests based on service name. In a successful match, the incoming request is routed to the target virtual service.You can now use this feature to directly send requests to vinyl-mobile matched on the header user-agent. You can use either regex, prefix, suffix, exact, or range to match the values of a given header. To perform inverse actions, an invert flag can be applied to the headers match (e.g. route all non-mobile requests to vinyl-web).
You can expose data provided by the gRPC API vinyl-data-app to the marketplace vendor. You can now use service name and metadata fields to match incoming gRPC requests.
Method
The method field allows you to match the incoming HTTP/HTTP2 request method type. For example, you might want to route requests to vinyl-mobile-app labels update endpoint when you receive incoming requests from mobile devices to add a new label to the system.
Query parameters
The query parameters field enables you to match the name and value of a request query parameter. You can use the community string type parameter to rewrite the incoming requests for the path ‘/community’. You can rewrite the path to the destination ‘/media/groups’ endpoint of the vinyl-web-app for field name ‘type’, value ‘groups’. Similarly, destination path ‘/media/blogs’ for field name ‘type’ and value ‘blogs’. Please refer to the section Edit path based on query parameters on how query parameters are used in rewriting the path.
Priority based routing
Because currently we are matching on one condition, either path or service name, the ordering of rules is dictated by the length of the path prefix or service name (gRPC). A lengthier prefix is given more precedence, followed by an alphabetical ranking of prefixes of the same length. If there are numerous gateway routes with the same match criteria, the ranking is deterministic and based on alphabetical ordering of gateway route names. A new field called ‘priority’ has been introduced to improve the experience and allow you to assign an explicit priority and order for gateway routes to be assessed and implemented.
Rewrites for hostname and path
Along with hostname and header match, we are also introducing a new rewrite feature for hostname and path. The rewrite feature depends on the hostname and header match features.
Enable/disable auto rewrite of hostname
You may now enable/disable hostname rewrites for external HTTP/HTTP2/gRPC requests that reach the virtual gateway using this feature. You’ll see that auto rewrite is disabled in the following sample gateway route definition. As a result, the virtual router and, consequently, the virtual node will receive the incoming hostname ‘m.vinyls.buy.com’ rather than virtual service name ‘vinyl-mobile.discs.svc.cluster.local’.
---
apiVersion: appmesh.k8s.aws/v1beta2
kind: GatewayRoute
metadata:
name:vinyl-gw-route
namespace:discs
spec:
http:
match:
hostname:
exact: "m.vinyls.buy.com"
action:
rewrite:
hostname:
default_target_hostname: "disabled"
target:
virtualService:
virtualServiceRef:
name: vinyl-mobileJSON
Rewrite matched prefix and path to custom values
Furthermore, new features allow you to define HTTP and HTTP2 requests to rewrite matched paths and prefixes with custom values.
Add prefix:
In the example below, you might want to change the prefix for request matching hostname ‘vinyls.buy.com’, path ‘/list’, and query param ‘genre’ named ‘rocks’ to prefix ‘/explore/rocks’ for the target application named ‘vinyl-web-app’.
You may also use the rewrite improvement to remove the prefix, for example, if you want to rewrite ‘/checkout’ request to ‘/’ for the backend vinyl-checkout-app. At route ‘/,’ the checkout application only offers a single checkout function. By removing the prefix, you may redirect incoming ‘/checkout’ requests to the root prefix for vinyl-checkout-app, letting developers to focus on checkout functionality rather than designing the application to handle requests at multiple different endpoints alongside ‘/’.
Edit prefix:
In the Vinyl example below, you may like to change the request from ‘/list’ to ‘/explore/all/’. This can be accomplished by configuring prefix rewrite as follows.
Edit path:
You may choose to enable rewriting of the matched path ‘/pages/contact’ in HTTP/HTTP2 queries to the path ‘/contact’ in the Vinyl web store application’s virtual gateway route. Path rewriting can be configured as seen below.
Edit path based on query parameters:
You may configure route rewriting based on the query parameters in HTTP/HTTP2 requests. In the ‘vinyl-web-app’ example, you can use the query parameter ‘type’ with the value ‘groups’ for the incoming ‘/community’ to rewrite the route to ‘/media/groups’; similarly, for the same viny-web-app application, you can use the query parameter ‘type’ with the value ‘blogs’ for the path ‘/blogs’ to rewrite the route to ‘/media/blogs’. Later, refer to these paths in virtual routes for routing to different backend applications. Thus saving developer efforts to rewrite application to handle incoming request path and query parameters.
