Microservices on AWS
AWS Whitepaper

Service Discovery

One of the primary challenges with microservices architectures is allowing services to discover and interact with each other. The distributed characteristics of microservices architectures not only make it harder for services to communicate, but they also present challenges, such as checking the health of those systems and announcing when new applications come online. In addition, you must decide how and where to store meta-store information, such as configuration data that can be used by applications. Here we explore several techniques for performing service discovery on AWS for microservices-based architectures.

Client Side-Service Discovery

The most simplistic approach for connecting different tiers or services is to hardcode the IP address of the target as part of the configuration of the

communication source. This configuration can be stored in Domain Name System (DNS) or application configuration and leveraged whenever systems need to communicate with each other. Obviously, this solution doesn’t work well when your application scales. It isn’t recommended for microservices architectures due to the dynamic nature of target properties. Every time the target system changes its properties—regardless of whether it’s the IP address or port information—the source system has to update the configuration.

Application Load Balancer-Based Service Discovery

One of the advantages of Application Load Balancing is that it provides health checks and automatic registration/de-registration of backend services in failure cases. The Application Load Balancer also offers path- and host-based routing approaches. Combining these features with DNS capabilities, it’s possible to build a simple service discovery solution with minimum efforts and low cost.

You can configure a custom domain name for each microservice and associate the domain name with the Application Load Balancer’s DNS name using a CNAME entry. The DNS names of the service endpoints are then published across other applications that need access.

DNS-Based Service Discovery

Amazon Route 53 could be another source for holding service discovery information.


Route 53 is a highly available and scalable cloud DNS web service.

Route 53 provides several features that can be leveraged for service discovery. The private hosted zones feature allows it to hold DNS record sets for a domain or subdomains and restrict access to specific virtual private clouds (VPCs). You register IP addresses, hostnames, and port information as service records (SRV records) for a specific microservice and restrict access to the VPCs of the relevant client microservices. You can also configure health checks that regularly verify the status of the application and potentially trigger a failover among resource records.

Service Discovery Using Amazon ECS Event Stream

A different approach to implementing Route 53-based service discovery is to leverage the capabilities of the Amazon ECS event stream feature.

You can use Amazon ECS event stream for CloudWatch events to receive near real-time notifications regarding the current state of both the container instances within an Amazon ECS cluster and the current state of all tasks running on those container instances. It is possible to use CloudWatch rules to filter on specific changes within the ECS cluster (e.g., start, stop) and use that information to update the DNS entries in Route 53.

Service Discovery Using Configuration Management

Using Configuration Management tools (like Chef, Puppet, or Ansible) is another way to implement service discovery. Agents running on EC2 instances can register configuration information during server start. This information can be stored either on hosts or a centralized store along with other configuration management information.

One of the challenges of using configuration management tools is the frequency of updating health check information. Configuration of clients must be done thoroughly to retrieve the health of the application and to propagate updates immediately to prevent stale status information.

The following figure shows a service discovery mechanism using the configuration management system AWS OpsWorks.


OpsWorks is a configuration management service that uses Chef, an automation platform that treats server configurations as code. OpsWorks uses Chef to automate how servers are configured, deployed, and managed across your EC2 instances or on-premises compute environments.

Service Discovery Using Key Value Store

You can also use a key-value store for discovery of microservices. Although it takes longer to build this approach compared to other approaches, it provides more flexibility and extensibility and doesn’t encounter DNS caching issues. It also works well with client-side load-balancing techniques such as Netflix Ribbon. Client-side load balancing can help eliminate bottlenecks and simplify management.

The following figure shows an architecture that leverages Amazon DynamoDB as a key- value store and Amazon DynamoDB Streams to propagate status changes to other microservices.

Third Party Software

A different approach to implementing service discovery is using third-party software like HashiCorp Consul, etcd, or Netflix Eureka. All three examples are distributed, reliable key-value stores. For HashiCorp Consul, there is an AWS Quick Start that sets up a flexible, scalable AWS Cloud environment and launches HashiCorp Consul automatically into a configuration of your choice.