![\"Service](\"https:\/\/www.tothenew.com\/blog\/wp-ttn-blog\/uploads\/2026\/03\/ECS-Blog-1-1024x490.png\")
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](\"https:\/\/www.tothenew.com\/blog\/wp-ttn-blog\/uploads\/2026\/03\/ECS-Blog-2-1024x468.png\")
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
\nECS 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>\nService 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
- When an ECS service starts, it registers itself with Cloud Map<\/li>\n
- Cloud Map maintains a registry of running tasks (IP + port)<\/li>\n
- A DNS record is created\/updated in Route 53<\/li>\n
- Other services resolve the DNS name to get the IP address<\/li>\n
- 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](\"https:\/\/www.tothenew.com\/blog\/wp-ttn-blog\/uploads\/2026\/03\/ECS-Blog-4-1024x668.png\")
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
- API Only<\/strong> (No R53 record is created, and the application code manages the DNS routing) – Hard to Manage<\/strong><\/li>\n
- 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](\"https:\/\/www.tothenew.com\/blog\/wp-ttn-blog\/uploads\/2026\/03\/ECS-Blog-3-1024x179.png\")
Types of CloudMap Namespaces<\/p><\/div>\n
\nService 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
- Each task runs a sidecar proxy container<\/li>\n
- Applications communicate with services using logical names<\/li>\n
- 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](\"https:\/\/www.tothenew.com\/blog\/wp-ttn-blog\/uploads\/2026\/03\/ECS-Blog-5-1024x604.png\")
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
- The application sends a request to the local proxy<\/li>\n
- Proxy resolves the service name internally<\/li>\n
- Proxy routes the request to a healthy task<\/li>\n
- Handles failures and retries automatically<\/li>\n<\/ol>\n
\nService 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
\nService 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
\nConclusion<\/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":0},"categories":[2348],"tags":[248,1892,3688],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/79257"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/1644"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=79257"}],"version-history":[{"count":2,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/79257\/revisions"}],"predecessor-version":[{"id":79870,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/79257\/revisions\/79870"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=79257"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=79257"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=79257"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- 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
- There are two types of Namespaces\n
- Service Registry<\/strong>: Keeps track of healthy tasks and their endpoints<\/li>\n
- Namespace<\/strong>: A logical grouping of services under a domain (e.g., service.local)<\/li>\n
- Service Connect<\/strong> (proxy-based service communication abstraction)
- Service Discovery<\/strong> (Cloud Map-based DNS resolution)<\/li>\n