Migrating from AWS App Mesh to Amazon ECS Service Connect

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.

At re:Invent 2022, AWS introduced Amazon ECS Service Connect, a new way to connect microservices within Amazon Elastic Container Service (Amazon ECS). This post dives deep into Service Connect and discusses strategies for migrating from AWS App Mesh to Service Connect. Service Connect improves the reliability of containerized microservices through built-in health checks, outlier detection, and retry mechanisms. It also enhances observability by sending application-level networking metrics to Amazon CloudWatch. By using a managed networking data plane, Service Connect eliminates the undifferentiated heavy lifting associated with managing sidecar proxies.

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

Comparing App Mesh to Service Connect

Service meshes implement routing rules, add security layers, and provide observability through abstraction layers. Before undertaking a migration, it is crucial to understand the abstraction layers of Service Connect and compare them to those of App Mesh. This section shows these abstractions using a multi-tiered application deployed on Amazon ECS.

The following diagram depicts the sample application before implementing a service mesh. It consists of a Frontend service and two backend APIs: User and Stock. The three services are deployed on Amazon ECS as long-running services comprising one or more Tasks. An Elastic Load Balancer provides resilience and distributes traffic across the Tasks for each service in the architecture.

Diagram 1: Sample Application Architecture with Elastic Load Balancers

When transforming this architecture to run on App Mesh, abstractions are used to implement routing rules and security boundaries. Each microservice is encapsulated in an App Mesh Virtual Service. Within a Virtual Service, there may be multiple versions of the application, called App Mesh Virtual Nodes, with an App Mesh Virtual Router implementing the routing rules between the Virtual Nodes.

The following diagram shows the sample application implemented with App Mesh. Although there are still three Amazon ECS Services, a self-managed Envoy Proxy is deployed as a sidecar container within each Task. This proxy implements App Mesh’s routing, reliability, and observability features. It also provides client-side routing between services, reducing the number of Elastic Load Balancers needed. An AWS Cloud Map namespace is used for service discovery, and the resources are attached to a App Mesh Mesh, the logical boundary of resources.

Diagram 2: Sample Application Architecture instrumented with App Mesh

Service Connect streamlines these abstractions, and the Envoy proxy, known as the Service Connect Proxy, is fully managed by AWS. Service Connect abstractions include “Client” and “Server” services. A “Server” service may also function as a “Client” if it communicates with downstream microservices, in which case it is referred to as a “Client/Server” service. An AWS Cloud Map namespace provides service discovery and defines the logical boundary of resources.

The following diagram shows the architecture of the sample application with Service Connect. The Frontend application has become a “Client” service and is part of the AWS Cloud Map namespace, but it doesn’t expose endpoints. The User and Stock APIs are both “Server” services, attached to the Namespace, and exposing endpoints for “Clients” to connect to.

Diagram 3: Sample Application Architecture instrumented with Service Connect

Migrating from App Mesh to Service Connect

An Amazon ECS Service can’t simultaneously be part of both an App Mesh Mesh and a Service Connect Namespace. Therefore, to perform a migration, the Amazon ECS Services must be recreated. To avoid downtime during this process you can implement a blue/green migration strategy. This approach involves creating duplicate copies of each Amazon ECS service and gradually transferring traffic between the two environments. There are several methods to granularly shift traffic within a blue/green migration, such as Amazon Route53 Weighted Routing, Amazon CloudFront continuous deployment, and routing between multiple Target Groups in an Application Load Balancer.

The following diagram illustrates the migration of an application from App Mesh to Service Connect. End users are gradually migrated from the App Mesh environment to the Service Connect environment through Amazon Route 53 weighted routes. Service Connect provides application-level networking metrics as free CloudWatch metrics. During this migration, the amount of traffic sent to the Service Connect environment is slowly increased by adjusting the weights of the weighted records. By using the out-of-the-box Service Connect metrics, administrators can monitor the increased load to detect misconfigurations.

Diagram 4: Sample Application Architecture deployed with App Mesh and Service Connect

There is no cross-environment networking between the environments, because each service mesh has separate service discovery implementations. An end-user connection remains within its respective service mesh. For example, if traffic is sent to the Frontend running on App Mesh, the backend APIs accessed would be those deployed within the mesh. The Frontend deployed on App Mesh can’t communicate with backend services in the Service Connect environment.

Feature comparison

Service Connect eliminates the overhead of managing a service mesh, removing the proxy management and multiple layers of abstraction. AWS is investing heavily in Service Connect and it has a strong roadmap, however not all Envoy Proxy features are currently available in Service Connect. In this section, we highlight the feature differences between Service Connect and App Mesh.

Increased Network Reliability: Both App Mesh and Service Connect use Envoy’s outlier detection, health checking, and retry mechanisms to improve reliability between services. With App Mesh these variables can be fine-tuned, whereas with Service Connect there are opinionated defaults with only timeouts being configurable.

Advanced Traffic Routing­: In App Mesh, through the Virtual Routing mechanism, you can granularly route traffic between versions of a microservice with multiple Virtual Nodes and a Virtual Router. Advanced traffic routing is not available for Service Connect.

Observability: With App Mesh it is your responsibility to capture traffic metrics, ship them to a monitoring service, and create observability dashboards. Service Connect provides free application-level traffic metrics sent to CloudWatch, and these metrics are visible in the CloudWatch console and Amazon ECS console.

Security: Both App Mesh and Service Connect support TLS to encrypt communication between services. With App Mesh, you can leverage AWS Private Certificate Authority (AWS PCA) general purpose certificates. On the other hand, Service Connect simplifies the configuration and you can use lower-cost AWS PCA short lived certificates. Additionally, when using App Mesh you have the ability to implement two-way peer authentication using mutual TLS (mTLS), a feature not yet available for Service Connect.

Sharing Resources: AWS Resource Access Manager (AWS RAM) allows an App Mesh Mesh to be shared across multiple AWS accounts. This allows an application to be distributed across accounts while belonging to the same logical boundary of the Mesh. In Service Connect, the AWS Cloud Map namespace can’t be shared across multiple AWS Accounts, thus at this time all tiers of the application need to be deployed into the same AWS Account.

Conclusion

In this post, we explored the migration from App Mesh to Amazon ECS Service Connect and showed the key differences between the two services. We discussed the streamlined abstractions and managed networking data plane that Service Connect provides, and the considerations around traffic routing, observability, security, and resource sharing.

If you’re using App Mesh and are interested in migrating to Service Connect, we recommend reviewing the blue/green migration strategy outlined in this post. To learn more about Service Connect, check out the Amazon ECS documentation and the Amazon ECS Immersion Day workshop, where you can deploy a sample retail application and get hands-on experience with the service.