All you get from this is a pretty CNAME alias for your ELB hostname. Since you're (manually) creating an ELB for each service, you might as well copy & paste th

All you get from this is a pretty CNAME alias for your ELB hostname. Since you're (manually) creating an ELB for each service, you might as well copy & paste the ELB hostname to your app's config. I wish Amazon did more to improve their ELB offering: 1) A single ELB costs $18/mo, regardless of the number of backend hosts. This might be OK if you're using ELB to front HTTP traffic from users, but it's crazy expensive for internal service discovery. If your app has 5 micro-services, that's $90/month just for having a basic mechanism to access your ECS services. 2) ELB requires all backend hosts to expose the same port for load balancing. You can't balance to the same EC2 instance on different ports. 3) As a consequence of (2), you can't have multiple containers on the same EC2 host behind a load balancer. Many popular programming languages have a global interpreter lock; you usually have to spawn multiple processes to make use of more CPU cores. People do that with things like gunicorn inside the container or with multiple containers + a haproxy load balancing container. It would be so much easier if ELB did all this instead. 4) ELB doesn't support URL maps. (i.e. different sets of backend hosts for different URL paths) The Google Cloud Platform load balancer supports this, and it's a tremendously useful. """[...] without the need for “sidecar” containers or expensive code change.""" People use "sidecar" and "ambassador" containers precisely because ELB is lacking functionality. Improving ELB will go a long way towards making service discovery easier on AWS.