Migrate Amazon ECS workloads from AWS App Mesh to Amazon VPC Lattice

After careful consideration, we have made the decision to discontinue AWS App Mesh, effective September 30th, 2026. Until this date, existing AWS App Mesh customers will be able to use the service as normal, including creating new resources and onboarding new accounts via the AWS CLI and AWS CloudFormation. Additionally, AWS will continue to provide critical security and availability updates to AWS App Mesh during this period. However, starting from September 24th, 2024, new customers will be unable to onboard to AWS App Mesh.

As organizations embrace cloud-native architectures, the complexity of managing microservices has grown exponentially, creating a pressing need for sophisticated management tools. Initially, AWS App Mesh emerged as a managed service solution, offering streamlined traffic management and enhanced observability for microservices architectures. With the introduction of Amazon VPC Lattice at re:invent 2022, the landscape of service connectivity has evolved. This fully managed service represents a significant advancement in service-to-service communication, providing seamless connectivity, robust security, and comprehensive monitoring across a diverse ecosystem of AWS services, including Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), AWS Lambda, and Amazon Elastic Compute Cloud (Amazon EC2).

Amazon VPC Lattice distinguishes itself by offering a more integrated and simplified approach to service networking, eliminating many of the operational complexities that organizations face when managing microservices communication. While AWS App Mesh served its purpose effectively, Amazon VPC Lattice introduces a more streamlined and versatile solution for modern cloud architectures. In this blog post, we’ll guide you through the process of migrating from AWS App Mesh to Amazon VPC Lattice, highlighting key considerations and benefits that this transition offers for your cloud infrastructure. We’ll walk through the key architectural changes, migration considerations, and benefits of using Amazon VPC Lattice.

For Amazon EKS customers using AWS App Mesh, we recommend reading the post Migrating from AWS App Mesh to Amazon VPC Lattice.

Architecture Overview

For this post, we’ll use a sample IT Inventory Management System application that represents a typical microservices architecture deployed on Amazon ECS. The code in the sample repository uses AWS App Mesh for service-to-service communication and will be migrated to Amazon VPC Lattice.

Current Application Architecture

The application architecture consists of four interconnected microservices:

1. UI Component (frontend-ms): Frontend Service acts as the user interface layer, providing a React-based web application where employees can browse equipment and submit order requests.
2. User Service (user-ms): User Service handles all authentication and authorization workflows, verifying employee credentials before allowing the system to place an order.
3. Product Service (product-ms): Product Service maintains the equipment catalog and real-time inventory status, ensuring accurate availability of information for all order requests.
4. Order Service (order-ms): Order Service orchestrates the ordering process by coordinating between the User and Product services, only placing orders after confirming both user authentication and equipment availability.

The architecture uses Amazon Aurora as its database, where the Users and Products services maintain their respective data, including employee information and inventory details.

Figure 1: Current architecture with AWS App Mesh

Current Request Flow

Through the browser, the user can use the form to submit an equipment request. The browser then calls the frontend-ui micro-service via REST API. The frontend-ui container runs a nginx web server which analyzes the incoming URL path and routes the request to the appropriate containers, such as product-ms, user-ms or order-ms via App Mesh. Once we migrate to VPC Lattice, the nginx web server will need to route the API calls through VPC Lattice instead of AppMesh. Figure 2 shows the sample application frontend UI in the browser.

Figure 2: Sample Application instrumented with AWS App Mesh

The nginx web server uses environment variables to configure the locations of the backend micro-services. In our initial setup, these environment variables contained App Mesh endpoints for the respective backend services, all of which were located on the same cluster. However, Amazon VPC Lattice lets you connect to microservices regardless of whether they run in the same VPC, different VPCs, or even different AWS accounts. You just need to ensure the nginx container has the correct domains configured through environment variables.

Migration Strategy

Before diving into the migration process, it’s crucial to understand the available strategies and choose the most appropriate for your specific use case. VPC Lattice offers a fully managed service networking solution that can replace traditional service mesh implementations; providing similar traffic routing, security, and observability features without requiring sidecar proxies. Application migration from App Mesh to VPC Lattice can be accomplished through different deployment strategies:

The choice of migration strategy should align with specific organizational requirements, including downtime tolerance, rollback capabilities, operational complexity, and maintenance window constraints. Each approach offers different tradeoffs between risk, complexity, and resource utilization. Our solution uses ECS blue/green deployment for the frontend service with an Application Load Balancer (ALB), two listeners and two target groups. The ECS blue/green deployment strategy requires an IAM role to perform necessary ALB changes to target group weights during deployments. The Frontend ECS service deployment uses a Lambda function as a lifecycle hook for the POST_TEST_TRAFFIC_SHIFT stage, with IAM role permissions to invoke the Lambda function. In the POST_TEST_TRAFFIC_SHIFT stage, the tasks are added to the green target group, and the Lambda function accesses the API <ALB_ENDPOINT>/api/products on the test listener and verifies the response for "result": "true". A successful test with the Lambda function returns "hookStatus": "SUCCEEDED" and the ECS deployment proceeds with shifting production traffic to the new tasks. The ECS deployment controller rollbacks the deployment if the Lambda function returns "hookStatus": "FAILED".

To maintain availability and enable rollbacks during backend microservice migration from AppMesh to VPC Lattice, you create new ECS services alongside the existing ones. This approach allows us to simply redirect traffic back to the previous service if any issues arise during deployment, providing a safety net for our backend operations.

Target Application Architecture

The architectural flow begins at the Application Load Balancer (ALB), which serves as the entry point for all incoming requests. These requests are then directed to the frontend service, which communicates with the Amazon VPC Lattice service endpoints within the Virtual Private Cloud (VPC). Each request follows a specific flow pattern, with the Lattice service endpoints acting as secure intermediaries within the network.

Figure 3: Target architecture with the Amazon VPC Lattice

The Lattice service forwards requests to VPC Lattice target groups. The target groups handle traffic based on configured routing rules. Amazon ECS tasks register with these target groups to process incoming requests, functioning similarly as target groups associated to an Application Load Balancer (ALB). This setup forms the foundation for our migration process, which we will explore in detail throughout the following sections, including key considerations and necessary configuration adjustments.

Migration Walk Through

In this section, we outline the key steps to migrate an application from App Mesh to VPC Lattice. For detailed implementation instructions, refer to our GitHub repository.

Step 1: Deploy the Amazon ECS Cluster and sample application with AWS App Mesh

Before beginning the migration, ensure you have a working application with App Mesh. For this demonstration, we’ll use our sample application deployed on an Amazon ECS cluster with EC2 launch type. Verify that the application is functioning correctly before proceeding with the migration.

Step 2: Create a Task definition to incorporate Amazon VPC Lattice changes

The migration to VPC Lattice requires configuration changes to your ECS task definitions. The App Mesh enabled task definition includes an Envoy sidecar container, dependency conditions ensuring the application starts after the proxy is healthy, and proxy configuration for traffic interception. It also contains App Mesh-specific environment variables for service discovery and mesh configuration. To migrate to Lattice:

1. Remove the Envoy sidecar container configuration
2. Clean up AWS App Mesh-specific configurations which includes dependsOn condition and proxyConfiguration from the microservice
3. Update the environment variables for the new Amazon VPC Lattice endpoints

The VPC Lattice task definition is significantly simpler, requiring only the application container and environment variables for service endpoints. There’s no need for proxy configurations or container dependencies as VPC Lattice handles service discovery and routing. You can view the updated task definition, in GitHub.

Step 3: Create Amazon VPC Lattice resources

Now, we will create our Service Network. A Service Network in VPC Lattice serves as a logical boundary for service-to-service communication, allowing you to organize and manage your services in a unified namespace. It’s like a Service Mesh in AWS App Mesh, connecting and managing communications between your applications.

You can create a Service Network using the Amazon VPC console, AWS Command Line Interface (AWS CLI), or infrastructure as code (IaC) tools like AWS CloudFormation or AWS CDK. For this walkthrough, we’ll use the AWS CLI for its simplicity and to demonstrate command-line operations.

Let’s create our Service Network with the AWS CLI:

aws vpc-lattice create-service-network \
    --name inventory-network

Next we attach the service network to the VPC where our application resides by passing the service network identifier and VPC ID. This association enables services within the VPC to communicate with each other through the Amazon VPC Lattice service network.

aws vpc-lattice create-service-network-vpc-association \
    --service-network-identifier sn-1234567890 \
    --vpc-identifier vpc-112233445566

Step 4: Create a Amazon VPC Lattice Service and Lattice Target Group

Let us now create the VPC Lattice service for our microservices and associate it with the Lattice network. While we will set the authentication type to ‘None’ for simplicity, it’s worth noting that VPC Lattice offers robust authentication capabilities and allows you to implement fine-grained permission controls for your service. You also have the option to enable access logging for enhanced monitoring and auditing capabilities.

aws vpc-lattice create-service \
  --name product-ms-service \
  --auth-type NONE \
  --region us-west-2

aws vpc-lattice create-service-network-service-association \
  --service-network-identifier sn-1234567890 \
  --service-identifier svc-1234567890 \
  --region us-west-2

Once the Lattice service is provisioned, the details of the service can also be viewed in the VPC Lattice console under Lattice Services as shown. Make a note of the domain name from the service console. This domain name will be essential for validating the service setup.

Figure 4: Amazon VPC Lattice Service in AWS Console

A target group manages traffic routing and health monitoring for your service. When you configure a target group, you specify parameters such as the service port, health check paths, and response time thresholds to ensure reliable service delivery. The health check parameters are essential, as they determine how VPC Lattice identifies and responds to potential service issues.

aws vpc-lattice create-target-group \
  --name product-ms-tg \
  --type IP \
  --config '{
    "port": 5000,
    "protocol": "HTTP",
    "vpcIdentifier": "vpc-112233445566",
    "healthCheck": {
      "enabled": true,
      "protocol": "HTTP",
      "path": "/",
      "port": 5000,
      "healthCheckIntervalSeconds": 30,
      "healthCheckTimeoutSeconds": 5,
      "healthyThresholdCount": 5,
      "unhealthyThresholdCount": 2,
      "matcher": {
        "httpCode": "200-499"
      }
    }
  }' \
--region us-west-2

After creation, the target group will be visible in the VPC Lattice console (Figure 5) under the Target groups section.

Figure 5: VPC Lattice target groups in the AWS console

Step 5: Create new ECS service with Amazon VPC Lattice enabled

Rather than modifying the existing App Mesh service, we opted to create a new ECS service tailored for VPC Lattice; this approach allows for a side-by-side comparison and easy rollback if needed. To deploy your service, modify the provided task definition template by entering your specific resource values, including subnet IDs, security group ID, Amazon ECS infrastructure IAM role ARN , and target group ARN. You’ll also need to specify your existing ECS cluster name in the deployment configuration.

Create a new ECS service using the AWS CLI command below. The service configuration parameters are defined in the product-service-lattice.json file, which is available in our repository for reference.

aws ecs create-service \
  --cli-input-json file://product-service-lattice.json \
  --region us-west-2

ECS automatically handles the registration of tasks with the specified Amazon VPC Lattice target group when ECS service is created with the vpcLatticeConfigurations parameter. As a final validation step, execute a curl command from within the VPC using the service domain name obtained in step 4.

Figure 6: Amazon VPC Lattice service validation

For enhanced security of your Amazon VPC Lattice service, consider implementing HTTPS listeners. This process involves accessing the Amazon VPC Lattice console and navigating to your service’s Routing tab. Here, you’ll create a new HTTPS listener named ‘https-listener’, operating on port 443. You can choose between any existing AWS Certificate Manager (ACM) certificate or an existing default Amazon VPC Lattice certificate for SSL/TLS. Configure the listener to forward HTTPS traffic to your target group. VPC Lattice supports TLS termination at the service level through HTTPS listeners, which provides encryption between clients and the VPC Lattice service. If you require end-to-end encryption (from client all the way to your target applications), we recommend following the guidance in this article.

Step 6: Changes to the frontend UI container

Lastly, we update the frontend application to connect to the backend microservices through the VPC Lattice URLs. This requires modifying the frontend-ui task definition, specifically updating the environment variables to point to the new VPC Lattice service domain instead of the existing App Mesh endpoint. The lifecycle hook configured in the ECS blue/green deployment will test connectivity to the new tasks with VPC Lattice service domain backend, before shifting production traffic to the new tasks. Update the frontend service with the modified task definition.

aws ecs update-service \
    --cluster lattice-cluster \
    --service frontend-ui \
    --task-definition TASK_DEFINITION:REVISION \
    --region us-west-2
After updating and confirming that the frontend-ui service successfully routes production traffic through the VPC Lattice service domains to the backend services, you can safely remove the App Mesh-enabled backend services from your ECS cluster.
aws ecs delete-service \
  --cluster lattice-cluster \
  --service product-service \
  --force \
  --region us-west-2

Extending the Solution: Cross-VPC Database Access with VPC Lattice

A new capability in Amazon VPC Lattice was announced on December 2, 2024, with the introduction of TCP support for VPC resources. This feature proves particularly valuable for organizations managing multiple VPCs that need to connect various TCP based workloads. While database connectivity, such as Aurora, is one common use case, TCP support enables seamless communication for a wide range of applications. These include custom TCP applications, legacy systems with proprietary protocols, message brokers, file transfer services, and internal tools requiring TCP connectivity.

In our revised architecture, we can leverage this capability to relocate our Aurora database to a separate VPC. This strategic change delivers multiple benefits including improved resource isolation, enhanced security controls, simplified cross-VPC database access, and standardized connectivity patterns. The architecture diagram in Figure 7 illustrates how the Aurora database now resides in a different VPC while maintaining seamless connectivity through Amazon VPC Lattice’s TCP support.

Figure 7: Application with database in different VPC

Cleanup

To avoid charges, make sure to delete all resources created during this migration. Follow the cleanup instructions in our GitHub repository.

Conclusion

In this post, we demonstrated how Amazon VPC Lattice can transform your AWS infrastructure through simplified service networking capabilities. We demonstrated how VPC Lattice eliminates the operational overhead of managing Envoy proxies. The migration process from AWS App Mesh to VPC Lattice, as outlined in this post, provides a practical path forward for organizations looking to modernize their service networking. While our example focuses on migrating a single micro-service, you can apply the same steps to migrate your other backend services. We used product-ms as a representative example to keep the instructions concise and practical.

For enhanced security, VPC Lattice manages access control through auth policies attached to services and service networks, working alongside IAM identity-based policies. For more information about VPC Lattice authorization, see How authorization works.

This guide demonstrates how to successfully migrate your workloads from AWS App Mesh to Amazon VPC Lattice. For detailed configurations, you can explore the GitHub repository, which complements this blog with implementation scenarios and code samples.

For more information, refer to the following Amazon VPC Lattice resources and blogs:

• User guide
• API reference
• FAQs
• Pricing
• Quotas

About the authors

Piyush Shukla is a Senior Technical Account Manager at AWS with over 16 years of industry experience. His expertise spans on cloud operations for AWS users. He has more than 7 years of experience in Containers and focuses on its adoption across industry verticals. Outside of work, Piyush enjoys spending quality time with his family and two kids.

Ameet Naik is an AWS Senior Technical Account Manager and is responsible for solving engineering challenges for enterprises operating at scale in the startups and digital native business market segments. He comes from a software development background and has a Solutions Architect Professional and Security Specialty certifications. In addition, he holds a Master of Science in Computer Science degree along with a Bachelors degree in Computer Engineering.

Ravi Yalamanchili is a Senior Technical Account Manager at AWS. He is passionate about containers, automation, and cost optimization. Prior to joining AWS, Ravi worked as DevOps engineer managing container orchestration platforms (starting with LXC containers) and middleware components for web applications ranging from internal websites to mobile banking and fleet management solutions.