
What I like best is how quietly it takes the “where do I even reach that service?” headache away.
In my day-to-day I just give every micro-service a name—something plain like “user-profile” or “order-validator”—and Cloud Map keeps the latest IP/port, health status, and even a few custom attributes in one tiny record. After that, no matter how many times auto-scaling spins nodes up or down, the rest of the fleet finds them automatically. I stopped hard-coding IPs in config files, stopped juggling Route 53 entries by hand, and never had to tell the front-end team “wait, the endpoint changed again.” It feels like the service directory just looks after itself, so I can stay in the code instead of babysitting DNS. Review collected by and hosted on G2.com.
What still trips me up is how “split-brained” Cloud Map feels inside the AWS console. Half the controls are in Cloud Map itself, but the moment I want to attach a namespace to an ECS service or an EKS ingress, I’m suddenly clicking through three other services (ECS, EKS, App Mesh, even Route 53) just to view what are essentially the same records.
Debugging is the worst part. I’ll notice an instance that looks unhealthy in Cloud Map, but to figure out why I have to bounce over to ECS tasks, then into CloudWatch logs, and then back to Cloud Map to deregister the bad node. It ends up feeling like the service directory is supposed to be the single source of truth—except when it isn’t, and I’m still stuck hunting across tabs to piece everything together. Review collected by and hosted on G2.com.
At G2, we prefer fresh reviews and we like to follow up with reviewers. They may not have updated their review text, but have updated their review.
Validated through Google using a business email account
This reviewer was offered a nominal gift card as thank you for completing this review.
Invitation from G2. This reviewer was offered a nominal gift card as thank you for completing this review.



