{"id":79257,"date":"2026-05-24T14:56:48","date_gmt":"2026-05-24T09:26:48","guid":{"rendered":"https:\/\/tothenewco.pro\/blog\/?p=79257"},"modified":"2026-06-08T18:40:43","modified_gmt":"2026-06-08T13:10:43","slug":"ecs-service-discovery-vs-service-connect","status":"publish","type":"post","link":"https:\/\/tothenewco.pro\/blog\/ecs-service-discovery-vs-service-connect\/","title":{"rendered":"ECS Service Discovery VS Service Connect"},"content":{"rendered":"

Introduction<\/h2>\n

In early microservices architectures on AWS, communication between services relied on infrastructure components like load balancers. There was no native, built-in way for services to discover each other dynamically.<\/p>\n

A common architecture looked like this:<\/p>\n

Public DNS \u2192 Amazon Application Load Balancer \u2192 Frontend Service \u2192 Private ALB \u2192 Backend Service<\/pre>\n
\"Service
Service-to-Service Communication<\/p><\/div>\n
While this approach worked, it introduced several practical challenges:<\/p>\n
    \n
  • Multiple hops between services increased the latency<\/li>\n
  • Higher operational overhead in managing multiple load balancers<\/li>\n
  • Increased cost due to additional ALBs<\/li>\n
  • Static configuration of endpoints (hardcoding or manual updates)<\/li>\n
  • Scaling complexity, since every new service required routing rules<\/li>\n<\/ul>\n
    To improve external access and routing flexibility, teams often introduced an API Gateway layer using Amazon API Gateway:<\/p>\n
    Client \u2192 API Gateway \u2192 Services (via host\/path-based routing)<\/pre>\n
    \"Traffic
    Service-to-Service Communication via API Gateway<\/p><\/div>\n
    This helped centralise routing for incoming traffic, but internal service-to-service communication remained complex. Services still needed a way to:<\/p>\n
      \n
    • Discover each other dynamically<\/li>\n
    • Avoid hardcoded endpoints<\/li>\n
    • Scale without manual intervention<\/li>\n<\/ul>\n
      This led to the evolution of native AWS solutions like ECS Service Discovery and later Service Connect, which simplify internal communication without requiring load balancers.<\/p>\n
      \n
      ECS Service to Service Communication: Without ELBs<\/h2>\n
      Before these features, ECS services typically relied on:<\/p>\n
        \n
      • Internal load balancers<\/li>\n
      • Static DNS entries<\/li>\n
      • Environment variables with hardcoded service URLs<\/li>\n<\/ul>\n
        These approaches worked but did not scale well in dynamic environments where tasks are frequently created and destroyed.<\/p>\n
        To address this, AWS introduced two key approaches:<\/p>\n
          \n
        • Service Discovery<\/strong> (Cloud Map-based DNS resolution)<\/li>\n
        • Service Connect<\/strong> (proxy-based service communication abstraction)
          \n
          \n<\/li>\n<\/ul>\n
          Service Discovery<\/h3>\n
          Service Discovery is built on AWS Cloud Map and integrates with Amazon Route 53 to enable services to find each other using DNS names rather than static IP addresses.<\/p>\n
          Here is how it works:<\/p>\n
            \n
          1. When an ECS service starts, it registers itself with Cloud Map<\/li>\n
          2. Cloud Map maintains a registry of running tasks (IP + port)<\/li>\n
          3. A DNS record is created\/updated in Route 53<\/li>\n
          4. Other services resolve the DNS name to get the IP address<\/li>\n
          5. Requests are sent directly to the resolved endpoint<\/li>\n<\/ol>\n
            Example:<\/p>\n
            backend.service.local \u2192 10.0.2.45<\/pre>\n
            A frontend service can call:<\/p>\n
            http:\/\/backend.service.local:8080<\/pre>\n
            \"Service
            Service Discovery Working<\/p><\/div>\n
            Key Concepts:<\/strong><\/p>\n
              \n
            • Namespace<\/strong>: A logical grouping of services under a domain (e.g., service.local)<\/li>\n
            • Service Registry<\/strong>: Keeps track of healthy tasks and their endpoints<\/li>\n
            • DNS Records<\/strong>: Automatically managed records that map service names to IP addresses<\/li>\n<\/ul>\n
              What is CloudMap Namespace?<\/strong><\/p>\n
                \n
              • It is a Private Registry for MicroServices.<\/li>\n
              • If we define a namespace in a microservice, it is registered in the CloudMap.<\/li>\n
              • The DNS is created like this: <discovery name>.<namespace><\/strong><\/li>\n
              • There are two types of Namespaces\n
                  \n
                1. API Only<\/strong> (No R53 record is created, and the application code manages the DNS routing) – Hard to Manage<\/strong><\/li>\n
                2. API + DNS<\/strong> (This creates an R53 entry, and the services use this DNS to communicate internally\/externally) – Easy to Manage<\/strong><\/li>\n<\/ol>\n<\/li>\n<\/ul>\n
                  \"CloudMap
                  Types of CloudMap Namespaces<\/p><\/div>\n
                  \n
                  Service Connect<\/h3>\n
                  Service Connect is a more advanced and managed approach that builds on top of Service Discovery but introduces a service mesh-like experience without requiring complex setup.<\/p>\n
                  It uses a sidecar proxy (based on Envoy) inside each ECS task to manage communication between services (No need for the R53 records to manage DNS)<\/strong>. Inside the container \/etc\/hosts file<\/strong>, the IP and the SC endpoint mapping are auto-populated by the SC Envoy.<\/p>\n
                  Here is how it works:<\/p>\n
                    \n
                  1. Each task runs a sidecar proxy container<\/li>\n
                  2. Applications communicate with services using logical names<\/li>\n
                  3. The proxy handles:\n
                      \n
                    • Service discovery<\/li>\n
                    • Load balancing<\/li>\n
                    • Retries and timeouts<\/li>\n
                    • Traffic routing<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n
                      Example:<\/p>\n
                      http:\/\/backend:8080<\/pre>\n
                      No need to manage DNS records or endpoints manually.<\/p>\n
                      \"Service
                      Service Connect Flow<\/p><\/div>\n
                      Key Concepts:<\/strong><\/p>\n
                        \n
                      • Transparent service-to-service communication<\/li>\n
                      • Built-in load balancing across tasks<\/li>\n
                      • Automatic retries and failure handling<\/li>\n
                      • Centralised traffic management via proxy<\/li>\n
                      • Better observability (metrics, logs, tracing)<\/li>\n<\/ul>\n
                        Working Summary:<\/strong><\/p>\n
                          \n
                        1. The application sends a request to the local proxy<\/li>\n
                        2. Proxy resolves the service name internally<\/li>\n
                        3. Proxy routes the request to a healthy task<\/li>\n
                        4. Handles failures and retries automatically<\/li>\n<\/ol>\n
                          \n
                          Service Discovery Pros & Cons<\/h2>\n
                          Pros:<\/strong><\/p>\n
                            \n
                          • Simple architecture [name \u2192 DNS \u2192 IP \u2192 direct TCP\/HTTP connection].<\/li>\n
                          • No sidecar container.<\/li>\n
                          • Works well with any DNS\u2011capable client (Lambda, EC2, on\u2011prem, scripts).<\/li>\n
                          • Supports blue\/green and other patterns that depend on DNS\/Cloud Map records.\u200b<\/li>\n<\/ul>\n
                            Cons:<\/strong><\/p>\n
                              \n
                            • Failover speed depends on DNS TTL and client caching. Some clients keep using dead IPs for a while.<\/li>\n
                            • Client libraries must handle retries, timeouts, and load balancing themselves.\u200b<\/li>\n
                            • Limited built\u2011in observability. Only Route 53 metrics and app\u2011level logs.<\/li>\n<\/ul>\n
                              \n
                              Service Connect Pros and Cons<\/h2>\n
                              Pros:<\/strong><\/p>\n
                                \n
                              • Faster failover when a task dies, as Envoy maintains live endpoint lists instead of relying on DNS TTL.\u200b<\/li>\n
                              • Built\u2011in traffic features: retries, connection draining, and cross\u2011VPC service communication using logical names.\u200b<\/li>\n
                              • Better observability: ECS console shows service graph and real\u2011time network metrics; Envoy emits detailed logs and latency stats.\u200b<\/li>\n
                              • Simplified naming (short logical names with client aliases)<\/li>\n<\/ul>\n
                                Cons:<\/strong><\/p>\n
                                  \n
                                • Extra resource cost: an Envoy sidecar per task increases CPU and memory usage.\u200b<\/li>\n
                                • SC\u2011style names are really for SC\u2011enabled ECS tasks. External or legacy clients still need DNS\/Cloud Map or a load balancer in front.\u200b<\/li>\n<\/ul>\n
                                  \n
                                  Conclusion<\/h2>\n
                                  ECS service-to-service communication has evolved significantly from traditional load balancer-based architectures to more dynamic and scalable approaches.<\/p>\n
                                    \n
                                  • Service Discovery provides a DNS-based mechanism that allows services to locate each other without hardcoding endpoints. It is simple, cost-effective, and suitable for less complex systems.<\/li>\n
                                  • Service Connect takes this further by introducing a proxy-based architecture that abstracts networking complexities and provides built-in load balancing, retries, and observability.<\/li>\n<\/ul>\n
                                    For modern microservices on ECS, Service Connect is often the preferred choice due to its operational simplicity and production-grade features. However, Service Discovery remains relevant for simpler use cases or when fine-grained control is required.<\/p>\n
                                     <\/p>\n
                                     <\/p>\n","protected":false},"excerpt":{"rendered":"
                                    Introduction In early microservices architectures on AWS, communication between services relied on infrastructure components like load balancers. There was no native, built-in way for services to discover each other dynamically. A common architecture looked like this: Public DNS \u2192 Amazon Application Load Balancer \u2192 Frontend Service \u2192 Private ALB \u2192 Backend Service While this approach […]<\/p>\n","protected":false},"author":1644,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":54,"footnotes":""},"categories":[2348],"tags":[248,1892,3688],"class_list":["post-79257","post","type-post","status-publish","format-standard","hentry","category-devops-technology","tag-aws","tag-devops","tag-ecs"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t