AWS App Mesh
Overview
AWS App Mesh is used to monitor and control the application-level network. It is categorized under Network and Content Delivery Service. It helps the customers and developers control and streamline how their application services should communicate with other application services deployed on multiple compute infrastructure resources in AWS. AWS App Mesh can be used with AWS Fargate, Amazon Elastic Kubernetes Service (EKS), Amazon Elastic Compute Cloud (EC2), Amazon Elastic Container Service (ECS), and Kubernetes running on AWS.
Introduction to AWS App Mesh
Before learning about AWS App Mesh, we should know what service mesh is.
Service Mesh
In software engineering/architecture, the "service mesh" is defined as the dedicated infrastructure layer used for smoothing the communication between services or microservices by using a proxy.
Here, services may be an Apache server or Java service, etc. Microservices mean custom application codes made specifically to respond to one request.
Now back to AWS App Mesh,
AWS App Mesh helps customers who are following the service mesh architecture in their application's services or microservices.AWS App Mesh is a kind of service mesh that is used to control and monitor the applications or services deployed in the AWS Compute resources such as EC2, ECS, or EKS, etc.
Usually, one big distributed application is made of multiple decoupled application services. The customers and developers need to monitor and control every service running for the applications.
If any issue or error happens, they need to pinpoint the error and find the root cause for the error.
If any service is down, they need to reroute the traffic to the healthy node or service.
Before AWS AppMesh
The customer has to build their tool and leverage their team to manage these kinds of actions.
After AWS AppMesh
- AWS Appmesh will take care of the monitoring and network control of the application.
- It also helps customers easily pinpoint the error.
- It will automatically reroute the traffic if any failure or code change occurs.
AWS App Mesh Architecture
In terms of AWS App Mesh Architecture, the customer will create an AWS App Mesh resource via API or console, which will get translated into the proxy configuration by the control plane.
AWS Appmesh control plane will distribute the configuration out to all the running proxies. There are two parts to the AWS app mesh architecture.
They are
Proxy or Data plane
- Proxy is the thing that physically does the load balancing, traffic shifting, and generating logs and metrics for the application.
Control Plane
- AWS Appmesh is a highly available control plane. Each of the running proxies is connected to the control plane.
- The control plane is responsible for keeping the proxy configuration up-to-date.
As we can see in the architecture, each customer's deployed service has an envoy proxy running alongside it.
What is Envoy Proxy ?
- Envoy is an open-source edge and service proxy, designed for cloud-native applications
- Envoy is a high-performance C++ distributed proxy designed for single applications.
- It is a “universal data plane” designed for large microservice “service mesh” architectures.
Reference: Envoy Proxy
This implements the data plane of Envoy in the AWS App Mesh architecture. These envoy instances receive their configuration from the app mesh control plane based on the configuration customers provide. The proxies manage the traffic within the app mesh based on the customer’s configuration.
We can see integration with various external solutions, including other AWS services, partner solutions, and solutions chosen by customers to manage.
How Does It Work?
Recent software development architectures or practices follow modern cloud-native patterns such as microservices, CI/CD workflows, standardized at scale, infrastructure as code, polyglot languages, and runtimes, and scaled out on demand. AWS AppMesh will work well with those paradigms.
Polyglot programming is the ability to write in multiple programming languages to capture additional functionality and efficiency that would not be available in a single language.
As we discussed in the AWS app mesh architecture, There are two components involved. They are the control plane and the data plane.
Control Plane:
- Customers can use the app mesh API, CLI, SDK, or console to create meshes, virtual nodes, virtual routers and routes, and virtual services.
- Those are the app mesh resources that define the connectivity of the mesh.
Data Plane:
- The application will be configured and running in proxy resources such as ECS Tasks, EKS pods, or EC2 instances.
- AWS Service Discovery is used to configure CloudMap.
- The proxies are managed and monitored by AWS AppMesh.
Using CloudMap, customers can register their application resources, such as databases, microservices, queues, and many other cloud resources, with custom names.
AWS Appmesh enabled the relationship between the application service and envoys proxy instances. Customers can route the traffic to the application services as per their needs or requirements.
In a nutshell, all traffic bound for the application services flows through the AWS Appmesh data plane so that the traffic and data can be managed and observed by customers.
Example
Consider the below image, where we are having services A and Service B
Traffic flow will be
- The client sends the request, —> proxy intercepts (acts as middleware, i.e., it will log the request then forward it to the next endpoint) the traffic, —-> proxy routes the request to service A.
- Service A will route the request to the proxy lying in Service B —---> the proxy lying in service B intercepts the traffic and forwards it to service B
- Service B will respond to the proxy, and vice versa.
A proxy for service A and service B intercepts the traffic, and routing happens between them.
We can configure the proxy to route the traffic to different versions of the same service or different services, or we can drop the traffic.
AWS App Mesh Components
AWS AppMesh comprises the following components:
Service Mesh
- It represents the logical network boundary. So the traffic between the application services resides within this boundary.
Reference: AWS Documentation for Service Meshes
Virtual Nodes
- Virtual nodes will act as pointers to the compute resources, such as an ECS task group or an EKS deployment. we should specify the service discovery for the task group while creating the virtual nodes.
Reference: AWS Documentation for Virtual Nodes
Virtual Routers
- It will handle the traffic for the virtual services incorporated within the mesh.
Reference: AWS Documentation for Virtual Routers
Routes
- It is associated with a virtual router. It helps direct the traffic of the virtual nodes corresponding to the service name prefix.
Reference: AWS Documentation for Routes
Virtual Services
- An abstraction of a real service that is either provided by a virtual node directly or indirectly through a virtual router. This represents the real service abstraction (showing the visual flow by hiding the backend workflow configuration). This abstraction is provided by either a virtual node or a virtual router.
Reference: AWS Documentation for Virtual Services
Envoy Proxy
- Envoy proxy intercepts all the requests and responses from inside and outside the mesh through the application within the mesh. It will be running along with the application service resources such as ECS Task, EKS Pods, etc.
Reference: AWS Documentation for Envoy Proxy
Features of AWS App Mesh
Fully Managed
AWS AppMesh is managed by AWS. It is highly available. AWS Appmesh helps customers manage the communication between the application service and the backend without the need for installing any other software. AWS AppMesh is an application-level network mesh.
Open Source Proxy
AWS app mesh uses the open-source envoy proxy as a proxy or data plane in their architecture. This Envoy proxy configuration will be done automatically by AWS AppMesh while deploying the resources in the compute infrastructure.
Native Container Orchestration
Container services such as Amazon ECS and Amazon EKS work with the AWS App Mesh. All we need to do is include the configuration in the task definition in the case of Amazon ECS Fargate or Pod in Amazon EKS. AWS AppMesh also works with Kubernetes running on an EC2 instance.
Service-to-service authentication
mTLS stands for "mutual transport layer security. Communication for service-to-service identification will be validated by mTLS. It helps to identify the application components running within the mesh or outside the mesh. we can also use ACM to enable SSL authentication between the application service and the AWS app mesh.
Traffic routing
Using the AWS app mesh, customers can control routing. i.e., customers can route the traffic dynamically between the service without changing any code in the application service.
Client-side traffic policies
The proxies in the AWS app mesh automatically load balance the traffic to the healthy node from all the clients.
AWS App Mesh Pricing
There will be no charges incurred for using the AWS AppMesh service. However, we should pay for the utilized compute resources, such as EC2, ECS, and EKS, involved in the app mesh architecture.
For example,
Amazon ECS with EC2
- Charges will be incurred for the usage of the EC2 instance and EBS volumes.
Amazon ECS with Fargate
- Charges will accrue for the usage of the Vcpu and memory used by the ECS task.
Amazon EKS
- Charges of $0.10 per hour will be incurred for each Amazon EKS cluster. In addition to that, extra charges will be incurred for the usage of EC2 instances and EBS volumes as worker nodes to run Kubernetes.
Getting Started with AWS App Mesh
This example demo for the AWS AppMesh service is split into two parts
First Part
Deploying the necessary components of AWS AppMesh
Second Part
Update the configuration to reflect the changes in the AWS AppMesh architecture.
Scenario
Consider the customer who has two services named service A and service B. These two services are communicating with each other.
After some time, Service B version 2 or serviceBv2 is ready for deployment.
Customers are following a rolling deployment strategy in their CI/CD lifecycle.
So they decided to route 75 percent of traffic from service A to service B and the remaining 25 percent to service Bv2.
By leveraging the AWS Appmesh service, we can achieve this deployment without any downtime or changes to the existing application code.
Also, direct communication between service A and service B will be interpreted by an envoy proxy which will help for logging, monitoring, tracing, and troubleshooting purposes.
Demonstration
Before creating components of AWS Appmesh, log in to your AWS account as an IAM user with admin privileges, and then go to the AWS Cloushell service.
Configure the IAM user programmatically using the aws configure command.
How do I configure an IAM user programmatically?
Refer to the below documents.
Once the IAM user is successfully configured. Upload the below-mentioned file using the Cloudshell upload file option.
Files should be uploaded to the cloudshell.
- create-virtual-node-serviceb.json
- create-virtual-router.json
- create-route.json
- create-virtual-node-servicebv2.json
- create-virtual-node-servicea.json
- update-virtual-service.json
- update-route.json
- create-virtual-servicea.json
- ec2-trust-relationship.json
- virtual-node-policy.json
Once the files are uploaded, list the uploaded files by using the ls command to cross-check and ensure the files are correctly uploaded.
envoy-networking.sh
This file should be uploaded to the ec2 instance which we covered later in this demo.
Now, we can start with the first part.
First part
In this first part, we are going to create a mesh with their components. Their components are virtual service, virtual router, virtual routes, and virtual node.
Deploying the necessary components of AWS AppMesh
Step 1: Create a mesh named apps.
aws appmesh create-mesh --mesh-name apps
Step 2 : Create a virtual service named serviceb.apps.local
aws appmesh create-virtual-service --mesh-name apps --virtual-service-name serviceb.apps.local --spec {}
Step 3: Create a virtual node named serviceB.
aws appmesh create-virtual-node --cli-input-json file://create-virtual-node-serviceb.json
Step 4: Create a virtual router named serviceB.
aws appmesh create-virtual-router --cli-input-json file://create-virtual-router.json
Step 5: Create a virtual route named serviceB.
aws appmesh create-route --cli-input-json file://create-route.json
Now we have created all the necessary components required in the app mesh. Now we are going to proceed with the second part.
Second part
The second part comprises two subsequent parts.
- 2.1 Appmesh configuration
- 2.2 EC2 configuration
2.1 Appmesh Configuration
Step 1: Create a virtual node named serviceBv2
aws appmesh create-virtual-node --cli-input-json file://create-virtual-node-servicebv2.json
Step 2: Create a virtual node named serviceA
aws appmesh create-virtual-node --cli-input-json file://create-virtual-node-servicea.json
Step 3: The virtual service services.app.local has not been configured for traffic to flow through it yet. So we are going to update the virtual router named service B. So that virtual service services.app.local will send the traffic towards service B.
aws appmesh update-virtual-service --cli-input-json file://update-virtual-service.json
Step 4: Updating the router of ServiceB
aws appmesh update-route --cli-input-json file://update-route.json
Step 5: Create a virtual service named ServiceA. aws appmesh create-virtual-service --cli-input-json file://create-virtual-servicea.json
Appmesh Summary
So far, we have created all the appmesh components.
1. Two Virtual Services
- servicea.app.local
- serviceb.app.local
The envoy proxy sends all the traffic from servicea.app.local to serviceb.app.local via a virtual router named ServiceB.
2. Three Virtual Nodes
- serviceA
- serviceB
- serviceBv2
3. One Virtual Router
- serviceB
The virtual router instructs the envoy proxy to send 75 percent of traffic to the service virtual node and the remaining 25 percent of traffic to the serviceBv2 virtual node.
Now that we are finished with the app mesh configuration part, we can proceed with the EC2 configuration part.
2.2 EC2 Configuration
Configure the EC2 instance as a virtual node member.
Step 1: Create an IAM role named mesh-virtual-node-service-b.
aws iam create-role --role-name mesh-virtual-node-service-b --assume-role-policy-document file://ec2-trust-relationship.json
Step 2: Create an IAM policy named virtual-node-policy.
aws iam create-policy --policy-name virtual-node-policy --policy-document file://virtual-node-policy.json
Step 3: Attach the IAM policy to the role we created in step 1
aws iam attach-role-policy --policy-arn arn:aws:iam::111122223333
Note: Replace 111122223333 with your AWS account ID.
Step 4: Attach the AWS-managed policy named AmazonEC2ContainerRegistryReadOnly to the created role mesh-virtual-node-service-b.
aws iam attach-role-policy --policy-arn arn:aws:iam::aws
Step 5: Launch an amazon ec2 instance with the role we created and ssh into the instance.
Prerequisite: AWS CLI version 2 and Docker should be installed based on the operating system image you are choosing, and you should run the Docker service.
Step 6: Docker authentication and image pull from the repository
Note: For this example, we used the ap-south-1 region. If you are choosing any other region, kindly change the region code in the below commands.
Also, have a look at the supported region here.
AWS App Mesh endpoints and quotas - AWS General Reference
$aws ecr get-login-password
--region ap-south-1
| docker login
--username AWS
--password-stdin 840364872350.dkr.ecr.ap-south-1.amazonaws.com
Step 6: Run the below command to make the envoy proxy run on the deployed EC2 instance.
sudo docker run --detach --env APPMESH_RESOURCE_ARN=mesh/apps/virtualNode/serviceB
-u 1337 --network host 840364872350.dkr.ecr.region-code.amazonaws.com/aws-appmesh-envoy
Note: Replace the region code with the region where you deployed the appmesh.
Step 7: Create a file named envoy-networking.sh and fill the file with the below code.
In this file, one thing needs to be changed.
Application port - Replace port 8000 with the port that the application is running on.
Step 8: To route the traffic to the envoy-proxy. run the below command in the deployed EC2 instance.
sudo ./envoy-networking.sh
Step 9: Start your virtual node application code.
Appmesh with ECS and EKS
Like EC2 instances, EKS and ECS also support AWS App Mesh integration.
All we need to do is run a sidecar image as a task or pods alongside containers in the ECS and EKS clusters.
Sidecars are containers that run alongside the main container. They are typically used for logging, configuration, or proxying requests.
For more details, Kindly refer to the below documentation for AppMesh on EKS and ECS.
Benefits of AWS App Mesh
The main benefit of AWS App Mesh is that the configuration of the proxy is independent of the configuration of the business logic and applications.
End-to-End Visibility
- Appmesh captures all the traces, logs, and metrics of the application. Customers can use AWS native services such as Amazon Cloudwatch, AWS X-ray, or any other third-party tools to export those data and troubleshoot easily and quickly if any issue occurs.
High Availability
- AWS AppMesh is highly available and managed by AWS. Customers can choose how the traffic will flow or whether routing should happen within their application communication.
Streamline Operation
- Proxies will be configured and installed irrespective of the language-specific application running in the compute resource. AWS app mesh will configure that proxy for customers.
Enhance Architecture
- By leveraging AWS app mesh, customers or developers can decouple the installation and upgrade of the application resources without downtime. It also helps to configure the separation of business logic from operations. AWS app mesh also increased the stability and responsiveness of complex systems or distributed systems deployed in AWS.
End-to-end Encryption
- AWS app mesh uses an ACM certificate or a customer-provided certificate to encrypt the traffic between the application services deployed in different AWS components.
Minimize Inconsistencies
- AWS Appmesh minimizes the probability of getting inconsistencies irrespective of the computing platform and runtime versions in the SDLC and DevOps processes. The reason behind that is so that customers can run different applications using different programming languages while still having the same proxy installed on the computer resource.
Conclusion
- AWS AppMesh is a fully managed service mesh that makes it easy to monitor and control the communication between the application services.
- The main problem resolved by AWS Appmesh is managing the interservice traffic.
- AWS AppMesh Standardizes the application service communication by giving the end-end visibility and helping to achieve or ensure high availability for the customer's application.
- It provides consistent visibility and network traffic controls for every resource we add to it.
- It also provides support for applications running in ECS Fargate, EKS Pods, self-managed Kubernetes running on EC2, and applications running directly on EC2.