Microservices Service Discovery with AWS Cloud Map

Managing service-to-service communication in a microservices architecture is challenging. After building a transport management system with 7 microservices, here's how AWS Cloud Map solved our service discovery problems.

The Service Discovery Problem

In a microservices architecture, services need to find and communicate with each other. Traditional approaches like hardcoded endpoints or load balancer DNS don't scale well:

• Hardcoded IPs break when containers restart or scale
• Load balancer per service adds cost and latency
• DNS TTL caching causes stale routing during deployments
• No health awareness means traffic goes to unhealthy instances

Why AWS Cloud Map

AWS Cloud Map provides DNS-based and API-based service discovery with health checking built in. Key benefits for our ECS workloads:

• Native ECS integration - services automatically register/deregister
• Health-aware routing - only healthy instances receive traffic
• Private DNS namespace - services resolve via internal DNS
• No additional infrastructure - managed service, no Consul/Eureka to maintain

Implementation Architecture

Our transport management system consists of 7 services that need to communicate:

1. API Gateway - external traffic entry point
2. Order Service - shipment order management
3. Routing Service - route optimization
4. Tracking Service - real-time GPS tracking
5. Notification Service - SMS/email alerts
6. Billing Service - invoicing and payments
7. Analytics Service - reporting and dashboards

Each service registers with Cloud Map using a private DNS namespace (e.g., tms.local), allowing services to reach each other via DNS names like order-service.tms.local.

ECS Service Configuration

Enabling Cloud Map for an ECS service requires adding a service registry configuration. In Terraform:

The key settings are the service_registries block that links ECS to Cloud Map, and setting dns_records with type A for direct IP resolution or SRV for port information.

Health Checking Strategy

Cloud Map supports three health check types:

• Route 53 health checks - for public endpoints
• ECS container health checks - leverages existing task health
• Custom health checks - via API for complex scenarios

For our ECS services, we use container health checks with the HEALTHCHECK_CUSTOM_CONFIG routing policy, ensuring Cloud Map only returns healthy instances.

Service-to-Service Communication

With Cloud Map configured, services communicate using simple DNS names. The Order Service calling the Routing Service:

Example endpoint: http://routing-service.tms.local:8080/api/optimize

DNS resolution happens automatically within the VPC, returning only healthy instance IPs. No service mesh or sidecar required for basic service discovery.

Operational Benefits

After migrating to Cloud Map, we observed:

• Zero configuration drift - service endpoints managed automatically
• Faster deployments - no DNS propagation delays
• Improved reliability - unhealthy instances automatically excluded
• Simplified debugging - service registry provides clear view of running instances
• Cost savings - eliminated per-service load balancers

Key Takeaways

AWS Cloud Map is an excellent choice for ECS-based microservices that need service discovery without the complexity of a full service mesh. Start with DNS-based discovery and only add complexity (like App Mesh) when you need advanced traffic management features like circuit breaking or mutual TLS.