Score:0

How to add a domain name to an ECS container (ECS Service) without a load balancer?

ss flag

I'm searching for a way to add a domain name to an ECS service (containers) without a load balancer.

The particular type of service I want to do this for is itself a load balancer with capabilities outside of AWS's offering. We need this to be redundant across availability zones with similar setups in multiple isolated VPCs. I'm really loathed to spend $2000 per year to put in enough loadbalancers to fulfil this simple requirement.

To be clear I'm looking for a solution which resolves an FQDN to an external IP address attached to the container so A or AAAA name (possibly CNAME if its weighted and points to an A or AAAA). It doesn't matter to me which network mode this works for. The container can be placed in any of host, bridge, awsvpc if the solution works!

So far I've found this frustratingly limited:

  • Service Discovery will only add SRV records for host and bridge type network containers
  • Service Discovery will create A and AAAA records for awsvpc network type containers, but awsvpc tasks can't be placed on ECS EC2 instances and still have a public IP address.
  • Running the same tasks in fargate would cost as much or more than the load balancers.
  • Route53 has no good mechanism for adding A and AAAA name records to EC2 instances in an autoscaling group so even if I put an instance of this task on every node I still won't be able to reference it by domain name.

How to add a domain name to an ECS container without a load balancer?

Score:0
nl flag

I am not clear about the question. Service Discovery does support a domain name (namespace). It's actually mandatory as far as I can tell. In other words if you want to use SD for an ECS service called myservice you have to refer to it as myservice.<domain> where <domain> is an arbitrary namespace you have to define (such as .local or .my.domain). Here is an example of a stack that uses SD.

Note that all this is internal to the cluster and how internal service discovery works (e.g. how an ECS service discovers another ECS service).

[Edit] IF you want to expose your ECS services but DO NOT want to use a load balancer another option would be to use API GW as described in this blog post. In general you do not want to register random public IP addresses of Fargate tasks in R53 because they are ephemeral and you'd need to build complex mechanism to keep them aligned when Fargate tasks come and go. Have you also considered App Runner?

ss flag
This only creates DNS SRV records as far as I know. Wen browsers and many other clients do not look for SRV records and don't know how to use them. ...Unless you run on fargate.
mreferre avatar
nl flag
Yes. That is what I meant by "Internal to the cluster". I have updated my answer.
ss flag
"*because they are ephemeral and you'd need to build complex mechanism to keep them aligned when Fargate tasks*" the same is true of internal IP address on an ECS EC2 cluster. Containers can get torn down and placed on a new host. With an autoscaling group the hosts themselves get torn down and brought back up. That's why "Service Discovery" exists AFAIK. Having a solution which tracks the changing IP of the service is kinda the point of the question.
ss flag
I'd assumed stating "domain name" inferred something external; but you're right there are such things as internal domain names too. I've edited the question to make it explicit.
mreferre avatar
nl flag
"Having a solution which tracks the changing IP of the service is kinda the point of the question" <- yes agreed. That solution is Service Discovery for internal service discovery and ELB / APIGW+CloudMap (see blog I linked) for external customer facing services. I don't think there are other solutions for that (other than exposing Fargate tasks with public IPs and build a reconciliation loop with Route53).
ss flag
*"We heard you liked load balancers so we forced you to put a load balancer on your load balancer so you can..."* /sigh. Thanks for your thoughts. It's good to know I'm not missing something obvious.
ss flag
I've run into this same rock again and again with slightly different angles every time. Service discovery has never yet been a viable solution because either it creates SRV records which are practically useless (existing software largely doesn't understand them) and A/AAAA name records can only be added to service discovery with `AWSVPC` networking. If you are running EC2, not fargate, then that's not a practical option because you are then limited to 1-2 containers per host.
vn flag
@PhilipCouling You are not limited to 1-2 containers per host; you can run up to 498 tasks on certain instance types. https://docs.aws.amazon.com/AmazonECS/latest/developerguide/container-instance-eni.html
ss flag
@ceejayoz I'll look into interface trunking is it may help. Though this doesn't appear to be a drop in solution. It needs to be enabled on the account (I have no idea what the impact of that is) and it seems to add other limitations as well as limiting instance tyes. The comparison is not correct either. Those instance types that can run 498 with trunking were already capable of running 9 tasks and are very expensive. The 1-3 task instances only achieve 10-40 with trunking.
vn flag
@PhilipCouling Impacts of enabling it are negligible in most cases and detailed at https://aws.amazon.com/fr/blogs/compute/optimizing-amazon-ecs-task-density-using-awsvpc-network-mode/; 10x as many tasks per instance is nothing to sneer at.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.