Service Discovery with AWS Cloud Map - Dynamic Name Resolution for Microservices

Dynamically discover microservice endpoints using DNS-based and API-based approaches. Learn how to automate service registration and deregistration through integration with ECS and EKS.

Overview of Cloud Map

Cloud Map is a service that provides service discovery for application resources. In a microservices architecture, when Service A needs to call Service B, instead of hardcoding Service B's endpoint, it queries Cloud Map for dynamic resolution. Cloud Map offers two discovery methods (DNS-based and API-based) and integrates with ECS and EKS to automate service registration and deregistration.

DNS and API Discovery

A DNS namespace registers services as DNS records, resolving them via DNS names like service-b.my-namespace.local. Existing applications can discover services through DNS queries without any code changes. An HTTP namespace retrieves service instances via the DiscoverInstances API, with filtering by custom attributes (version=v2, environment=prod). ECS service discovery automatically registers instances in Cloud Map when tasks launch and deregisters them when tasks stop. Route 53 health checks detect unhealthy instances and exclude them from discovery results.

Integration with ECS and EKS

When you enable Cloud Map on an ECS service, service instances are automatically registered and deregistered as tasks start and stop. With DNS-based discovery, SRV or A records are created in Route 53, and clients resolve services by DNS name. With API-based discovery, the DiscoverInstances API returns a list of health-checked instances, and clients implement load balancing on their side. In EKS, the AWS Cloud Map MCS Controller automatically syncs Kubernetes Services to Cloud Map. For health checks, you can choose between Route 53 health checks or custom health checks (where the application calls the UpdateInstanceCustomHealthStatus API).

Cloud Map Pricing and Operations

Cloud Map pricing is based on the number of registered resources and API calls. DNS queries are charged at standard Route 53 rates, and the DiscoverInstances API costs USD 1 per million requests (as of August 2026). In auto-scaling environments where instance registration and deregistration occur frequently, API call volume increases, so implementing client-side caching helps control costs. For namespace design, separate namespaces by environment (dev/staging/prod) and keep service names consistent across environments to eliminate environment-specific dependencies in application code. Monitor DiscoverInstances call counts and latency with CloudWatch metrics to detect abnormal increases.

Role as a Service Registry

Cloud Map functions as a registry that records which services are running where. In a microservices architecture, service instances increase and decrease and their placement also changes dynamically, so you cannot assume fixed endpoints. If you register the currently running instances in Cloud Map, callers can always query and resolve the latest location. Even when combining it with a higher-level mechanism such as a service mesh, this registry serves as the foundation. Managing service locations centrally achieves stable calls even in dynamic environments.

Designing Health Checks

If unhealthy instances are mixed into discovery results, calls end up failing. Cloud Map works with health checks and can be designed to return only healthy instances. There are methods that check status over the network and methods in which the application itself reports its own health, and you choose between them according to the requirements. In container environments, registration and deregistration are automated in step with task starts and stops, so you can prevent the accident of routing to a stopped instance. Set the health criteria and check interval appropriately so that they can be cut off quickly when a failure occurs.

Use Beyond Containers and in Hybrid Environments

Integration with ECS and EKS is easy with Cloud Map, but you can also register other resources. With the API, you can register EC2 instances, on-premises servers, and external endpoints manually or programmatically, and make them targets of name resolution through the same mechanism. This means you can handle service locations centrally even in environments where containers and traditional servers coexist. Being able to discover new and old components in a unified way in systems undergoing migration or in applications with hybrid configurations helps advance gradual modernization.

Behavior During Failures and Design Considerations

When using service discovery, pay attention to the balance between caching resolution results and their freshness. When resolving with DNS, if the TTL is too long, old instance information remains, and there is a risk of trying to connect to destinations that have already stopped. Conversely, if it is too short, queries increase, which affects cost and latency. The key point is a design that caches appropriately on the client side while quickly excluding anomalies with health checks. In auto-scaling environments with frequent registration and deregistration, API calls increase, so devise a caching strategy to keep load and cost down and maintain stable inter-service communication.

Summary

The easiest entry point for introducing Cloud Map is integration with ECS service discovery. Simply enabling Cloud Map on an ECS service automates service registration in sync with task starts and stops. A DNS namespace is the choice when existing applications resolve names via DNS, and an HTTP namespace is the choice when filtering by custom attributes is needed. For namespace design, we recommend separating by environment (dev/staging/prod) and keeping service names consistent across environments.

References (Official AWS Resources)

The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.

If this page and the official documentation disagree, treat the official documentation as authoritative.

Share