Service Discovery - Automating Microservice Connections with AWS Cloud Map

The Challenges of Service Discovery

In a microservices architecture, how to resolve the communication destinations between services is an important challenge. In a monolithic application, communication destinations are fixed, but in microservices, IP addresses change dynamically due to container starts / stops, Auto Scaling, and deployments. There is also the approach of placing a load balancer (ALB) in front of each service, but as the number of services grows, cost and management complexity increase. AWS Cloud Map is a service discovery service that centrally manages microservice endpoints in namespaces. It registers each service's instances (IP address, port, custom attributes) in a registry, and other services can look up connection destinations by name. It provides two discovery methods, DNS-based and API-based, and you can choose according to your use case.

Registering Namespaces and Services

Cloud Map manages resources in a three-layer structure: namespace → service → instance. There are two kinds of namespaces: DNS-based (public DNS or private DNS) and API-based (HTTP). In a DNS namespace, service names are registered as DNS records, and you can resolve connection destinations with standard DNS queries. For example, you can obtain the IP address of the payment service with the DNS name payment.myapp.local. In an API namespace, you search for services with the DiscoverInstances API, and filtering by custom attributes (version, environment, region, and so on) is possible.

# Create a private DNS namespace
aws servicediscovery create-private-dns-namespace \
  --name myapp.local \
  --vpc vpc-12345 \
  --region ap-northeast-1

# Register the service
aws servicediscovery create-service \
  --name payment \
  --namespace-id ns-xxxx \
  --dns-config '{"DnsRecords":[{"Type":"A","TTL":10}]}'

Instance registration / deregistration is done manually (API calls) or automatically through integration with ECS/EKS.

ECS Integration and Health Checks

With the native integration between Cloud Map and ECS, when a task of an ECS service starts, an instance is automatically registered in Cloud Map, and when the task stops, it is automatically deregistered. The integration is complete simply by specifying serviceRegistries in the ECS service definition. This lets services resolve task IP addresses directly with Cloud Map DNS names and communicate with each other without going through an ALB. You can reduce ALB costs (from about $22/month per unit), and latency is also reduced (as of August 2026). Two kinds of health checks are supported. Route 53 health checks run HTTP/HTTPS/TCP health checks against instances that have public IPs. Custom health checks report health status by calling the UpdateInstanceCustomHealthStatus API from the application side. In the case of ECS integration, because it is linked with ECS task health checks, additional health check configuration is usually unnecessary.

Working with App Mesh and Pricing

AWS App Mesh (a service mesh) used Cloud Map as its service discovery backend, but AWS ended support for App Mesh on September 30, 2026 (after that date, you cannot access the App Mesh console or resources). By associating a Cloud Map service with an App Mesh virtual service, the Envoy proxy automatically obtained endpoints from Cloud Map and applied mesh features such as traffic routing, retries, and circuit breakers. In EKS environments, you can use AWS Cloud Map Controller for Kubernetes to automatically synchronize Kubernetes Service resources with Cloud Map. Pricing is $0.10/month per namespace, $0.10 per 1,000 instance registrations, and $1.00 per 1 million DiscoverInstances API queries. DNS queries are charged at Route 53 pricing ($0.40 per 1 million queries). In small to medium-sized microservice environments, you can use it for a few dollars or so per month.

Choosing Between DNS-Based and API-Based

Service discovery in Cloud Map has a method that resolves names with DNS and a method that retrieves a list of services with an API. The DNS method has the advantage of being easy to adopt without changing code, because existing applications can keep using their mechanism of accessing by host name. The API method, on the other hand, lets you narrow down by the custom attributes assigned to services, so finer-grained control is possible, such as choosing connection destinations based on conditions like version or environment. You choose the method according to how the application is built and how fine-grained the control you need is. Understanding the characteristics of both and using each appropriately leads to an effective service discovery design.

Practice in Dynamic Environments

In microservices, instances frequently increase and decrease through auto scaling. Because Cloud Map can automate the registration / deregistration of services in step with container starts / stops, it can always keep the latest connection destinations even in such dynamic environments. Clients combine this with load balancing to distribute traffic to healthy instances. Even in situations such as switching to a new version in stages, you can manage the migration of traffic by controlling which instances are registered. In environments where instances change at a dizzying pace, a mechanism that makes connection destinations follow automatically supports stable service-to-service communication.

Summary - Guidelines for Making Use of Cloud Map

AWS Cloud Map is a service discovery service that centrally manages microservice endpoints. Its main strengths are the two discovery methods, DNS-based and API-based, native integration with ECS, and the automatic exclusion of unhealthy instances through health checks. When you operate microservices on ECS, by adopting Cloud Map instead of using an ALB for service-to-service communication, you can achieve cost reduction and lower latency.