- Newest
- Most votes
- Most comments
To address your follow-up question first: ECS Service Discovery is not being sunset. While App Mesh is retiring, Service Discovery is backed by AWS Cloud Map and Route 53 (core AWS services) and remains fully supported. You will absolutely still need it for clients operating outside the Service Connect proxy mesh, such as your standalone batch tasks.
Adding one crucial technical detail to the previous answer regarding running both configurations simultaneously: Because both traditional Service Discovery and Service Connect use AWS Cloud Map under the hood, they cannot register the exact same discovery name in the same namespace.
When adding the serviceConnectConfiguration to your existing ECS service, ensure you define a different clientAlias or discoveryName (for example, by adding a -sc suffix) than the one currently used in your serviceRegistries block. This prevents Cloud Map naming conflicts during deployment. Your batch tasks can then continue using the legacy DNS name, while your other ECS services communicate via the new Service Connect alias.
Reference on how Service Connect manages Cloud Map namespaces: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-connect-concepts.html
Yes, you can retain Service Discovery alongside Service Connect for your ECS services. These two features can coexist and serve different purposes in your architecture.
Service Connect and Service Discovery are independent features that can be configured simultaneously on the same ECS service. Service Connect creates its own AWS Cloud Map services automatically and provides DNS names that work within the Service Connect mesh (between tasks running with Service Connect enabled). However, this doesn't prevent you from also configuring traditional Service Discovery on your service.
For your use case with batch jobs that run as standalone tasks (without Service Connect enabled), you can maintain your existing Service Discovery configuration. This allows your batch job tasks to continue using the Service Discovery DNS names to reach your services, while your Service Connect-enabled services can communicate with each other using Service Connect's client aliases.
When configuring your services, you would:
- Keep your existing
serviceRegistriesconfiguration for Service Discovery - Add the
serviceConnectConfigurationfor Service Connect functionality
This dual configuration approach allows you to support both your batch jobs (which use Service Discovery URLs) and your Service Connect-enabled services (which use Service Connect DNS names) during your migration period. The Service Discovery endpoints will continue to work as they did before, providing the hosted zone URLs your batch jobs depend on.
One important note: Service Connect automatically creates its own AWS Cloud Map services. You should avoid manually modifying these Service Connect-created Cloud Map resources, as doing so may lead to unexpected behavior. Keep your manually managed Service Discovery resources separate from the ones Service Connect creates automatically.
Sources
Amazon ECS Service Connect configuration overview - Amazon Elastic Container Service
ServiceConnectServiceResource (AWS SDK for Java - 2.42.38)
ServiceConnectServiceResource - Amazon Elastic Container Service
Is this ECS Service - service discovery feature going to sunset like App Mesh ? as in the AWS ECS service discovery it recommends to use service connect , but service connect alone cannot satisfy our requirement (we need the url be able to used not only ECS service zone)
Relevant content
asked 20 days ago
asked 2 years ago
asked 3 years ago
- AWS OFFICIALUpdated 2 years ago
