Saving time and money are just two of many reasons why you should pay attention to Amazon ECS Service Discovery. ECS Service Discovery makes it easy for your containerized services to discover and connect with each other at a fraction of the cost (under $1/month for some workloads) when compared to other solutions.
Service discovery has been around for some time now, and it’s a must-have piece to any microservices architecture. Whether you’re making use of Amazon Elastic Container Service (ECS), Kubernetes, Apache Mesos, HashiCorp Nomad, or any other platform for scheduling microservices, you’ll want to ensure that service endpoints maintain discoverability during times of initialization, scaling, and failure response.
There are many questions that surround the concept and use of service discovery, and some of the common ones include “Should I use server-side, client-side, or both?”, “If client-side, should I make use of a solution such as Consul, ZooKeeper, Doozerd, Etcd, Eureka?”, “What are the costs?”, “Who manages the solution, and to what extent should HA be implemented?
It’s obvious that a person could spend significant time considering the merits of various solutions through different environments when it comes to service discovery, and this post is one that focuses on a client-side DNS based solution from AWS that is designed to quickly answer said questions.
Over the last couple of years, AWS has been quietly working to make client-side service discovery easier. In December 2017 AWS released the Amazon Route 53 Auto Naming API to allow automated registration of microservices in Amazon Route 53; the end result is a solution that simplifies the management of DNS records during microservices scaling. The addition of the Amazon Route 53 Auto Naming API was a great step forward for service discovery on AWS, and in March 2018 AWS released Amazon ECS Service Discovery. Amazon ECS is now integrated with the Amazon Route 53 Auto Naming API, and this allows service names to be automatically mapped to sets of DNS records for endpoint discovery.
Now that we have some background, let’s take a closer look at what makes up Amazon ECS Service Discovery.
Amazon Route 53 Auto Naming API: Provides the ability to automate the management of DNS namespaces, services, and instance records.
Service Discovery Instance: The Amazon Route 53 resource record, i.e. A or SRV records depending on network mode. If using the Amazon Route 53 Auto Naming API outside of ECS, then AAAA and CNAME records become options.
Service Discovery Private DNS Namespace: The private service discovery namespace for Amazon Route 53. Cannot make use of existing private zones and a new domain or subdomain must be created.
Service Discovery Public DNS Namespace: The public service discovery namespace for Amazon Route 53. Can make use of existing private zones.
Service Discovery Service: Service name and optional health checks that Amazon Route 53 should work with when registering instances, i.e. service-name.domain.tld.
When creating an Amazon ECS service the service discovery integration is listed as the second last section of the Configure network page. As illustrated in Figure 1.0, a new namespace called sd.abso.io is being created, along with a service name of hello-world. Whenever a client needs to communicate with the hello-worldservice, they’ll simply use hello-world.abso.io to resolve all service endpoints.
Amazon ECS task health propagation is enabled by default and should remain this way; doing so will ensure that Amazon Route 53 records are as consistent as possible.
The section right after service discovery is for establishing the Amazon Route 53 record types, AKA Service Discovery Instance; this is illustrated in Figure 1.1.
If a containerized application is configured to expose dynamic ports, then SRV records should be used in the Amazon ECS service configuration, and the application client can call for SRV records to get both the IP and Port information. It’s also possible to create both A and SRV record types for each instance by selecting Add DNS record.
If all is correctly configured and we launch the new hello-world service, we should soon be able to verify the correlating tasks are all running as illustrated in Figure 1.2.
Once we’ve verified the tasks are all running, we should be able to hop over to the Amazon Route 53 console to also verify the existence of records that support the AWS Fargate task instances.
If we then dig and curl the service using an instance in the same VPC, we get results as shown in Figure 1.4.
The architecture diagram above supports the configuration section. When new AWS Fargate resources are launched and images are deployed, Amazon ECS will add the AWS Fargate IPs to Amazon Route 53 using the Auto Naming API. When a client then queries Amazon Route 53 for the service name, it’ll get back the updated list of AWS Fargate IP addresses.
Amazon ECS Service Discovery is currently available in the following regions:
- us-east-1 (N. Virginia)
- us-east-2 (Ohio)
- us-west-2 (Oregon)
- eu-west-1 (Ireland)
It’s expected that support for many more regions will be added by the end of 2018. However, if DNS-based service discovery for Amazon ECS is required in a region that isn’t yet available, a custom event-based architecture will have to be developed.
Amazon ECS Service Discovery is charged based on Amazon Route 53 usage, and resources created by the Amazon Route 53 Auto Naming API. Items that are a part of the charges include the following:
- DNS queries
- Amazon Route 53 health checks
- Amazon Route 53 hosted zones
If you draw a baseline of having one Amazon Route 53 zone, and 1,000,000 standard queries in us-east-1 (up to 50 health checks are free), your cost would work out to be USD $0.90 for the month; this in contrast with the cost of running AWS ELBs or 3rd party solution would show a big delta in price.
If a clustered 3rd party solution were implemented for service discovery, a typical minimum of 3 t2.medium instances would be required for HA, and this would produce a cost of approximately USD $100.00 per month—over 100x the cost of Amazon ECS Service Discovery. This comparison is not exact, as some 3rd party solutions also provide other features, but if all you need is service discovery, then 100x is the mark. This cost also doesn’t take into consideration the time required to become knowledgeable enough to implement and manage a 3rd party solution, and this is something that increases the cost well beyond 100x.
There are a couple of important caveats when working with the Amazon Route 53 Auto Naming API:
- When creating service discovery namespaces, the correlating zone will be created in Amazon Route 53, i.e. domain.tld. Because this zone is created via the Amazon Route 53 Auto Naming API, it also has to be managed using the Amazon Route 53 Auto Naming API.
- Existing zones can be used in coordination with the Amazon Route 53 Auto Naming API, but they must be public. If you have an existing private zone, you will be required to create a secondary zone for the service discovery, i.e. sd.domain.tld.
AWS is enabling developers and providing them with an easier path to getting setup with DNS-based service discovery via the new Amazon Route 53 Auto Naming API. The API is consumable using the standard SDKs, CLIs, and CloudFormation, and this allows developers the ability to implement and manage DNS-based service discovery for custom microservices clusters.
AWS is also providing a direct path to DNS-based service discovery via the Amazon ECS service registry, which is built on top of the Amazon Route 53 Auto Naming API; this performs all of the Amazon Route 53 work for you based on your Amazon ECS service configuration.
The integration between Amazon ECS and Amazon Route 53 to provide Amazon ECS Service Discovery creates a fully managed HA implementation of DNS service discovery that removes the need for a 3rd party solution. Bonus: If you make use of Amazon ECS Service Discovery and SSM Parameter Store, you then also get the KV storage that many 3rd party solutions provide.
Amazon ECS Service Discovery provides immediate business value by dramatically reducing costs when compared with 3rd party solutions; it also provides technical value by simplifying and streamlining a highly available service discovery implementation.
If you’re looking for additional help with understanding or implementing Amazon ECS Service Discovery, or if you need assistance with a custom service discovery solution, please contact us and we’ll be sure to help.Get in touch