AWS Cloud Map
A service that provides service discovery for microservices, resolving service locations via DNS or API
Overview
AWS Cloud Map is a fully managed service that provides service discovery for cloud resources. In microservices architectures, it dynamically resolves service IP addresses and port numbers to enable inter-service communication. It offers two discovery methods - DNS-based discovery (integrated with Route 53) and API-based discovery - and can manage services running on different compute platforms such as containers, Lambda, and EC2 in a unified way. Deep integration with ECS and EKS ensures the service registry is automatically updated during container deployments and scaling events.
Namespaces and the Service Registration Mechanism
A Cloud Map namespace is a container that logically groups services. There are three types of namespaces: HTTP namespaces (API-based discovery only), public DNS namespaces, and private DNS namespaces. Private DNS namespaces are most commonly used for inter-service communication within a VPC, creating internal domains such as internal.myapp.local. Services are registered under a namespace, and instances (actual endpoints) are associated with each service. Instances can be configured with IP addresses, port numbers, and custom attributes (version, environment, region, etc.). Custom attributes are leveraged in API-based discovery, enabling filtering such as "retrieve only instances where version=v2 and region=ap-northeast-1." Service registration and deregistration are performed via API, and when using ECS or EKS service discovery integration, instances are automatically registered and deregistered in sync with task and pod lifecycles. There are soft limits on the number of services and instances per namespace, and limit increase requests may be needed in large-scale environments.
DNS-Based vs. API-Based Discovery
DNS-based discovery resolves service endpoints through standard DNS queries. Cloud Map automatically manages records in a Route 53 private hosted zone, allowing services to be accessed via DNS names like payment.internal.myapp.local. It supports A records (IP addresses) and SRV records (IP + port), with SRV records enabling dynamic port resolution. The advantage of DNS-based discovery is that no client-side changes are required - existing applications can call services using DNS names as-is. However, DNS cache TTL (minimum 10 seconds) introduces a delay before instance changes are reflected. API-based discovery calls the DiscoverInstances API directly, retrieving real-time instance information without being affected by DNS caching. It is suited for cases requiring custom attribute filtering or immediate reflection of health check status. However, it requires embedding AWS SDK call code in the application. The DiscoverInstances API has a built-in region-level cache, responding with low latency even under high-frequency calls.
ECS and EKS Integration with Health Checks
When Cloud Map service discovery is enabled on an ECS service, instances are automatically registered when tasks start and deregistered when tasks stop. In ECS's awsvpc network mode, each task is assigned a dedicated ENI (IP address), so accurate IPs are registered in Cloud Map. When combined with Fargate, the service registry updates in real time as tasks scale, enabling direct inter-service communication without a load balancer. In EKS environments, a common configuration uses the ExternalDNS controller to synchronize Kubernetes Service resources with Cloud Map. Health checks come in two types: Route 53 health checks (for DNS namespaces) and custom health checks (manually reported via API). Route 53 health checks monitor HTTP/HTTPS/TCP endpoints and automatically exclude unhealthy instances from DNS responses. Custom health checks implement application-specific health logic (database connectivity verification, dependent service response checks, etc.) and report status via the UpdateInstanceCustomHealthStatus API. Pricing is usage-based, charged per instance registration count and DiscoverInstances API call volume, typically amounting to just a few dollars per month for small-scale configurations.