NLB, Target Groups, Fargate Services and Tasks, and containers with multiple ports
I'm new to AWS and trying to move some of our on-prem services to Fargate. I started with a simple Nginx VM that just redirects a vanity domain to a URL in Sharepoint. I have SSL terminated on the container (we redirect port 80 to 443 with a 301 in Nginx) so there are two ports that need to be open. I have a diagram below.
From some of the docs I've read, I have to:
- Define two Target Groups for port 80 and 443 (using TCP protocol, not HTTP/S)
- Define a Network Load Balancer and assign an Elastic IP addresses to each TG (TCP port 80 and port 443)
- Point on-prem DNS to the NLB IP addresses (either an A record, or CNAME alias to NLB DNS name) using RRDNS
- Define a fargate service for each Target Group (80 and 443 - cannot assign multiple TG to one service)
- Spin up the desired number of tasks in fg1-80-service and fg1-443-service (below) to serve requests
After getting this set up, I realized I could only connect to one EIP on port 80 and the other only on 443. I went back and looked over the NLB config and realized that's exactly what I told it to do since the Listener gets the EIP, and not the NLB interface.
I don't see a way to get this done so I must be missing something. Is there a way to define multiple ports in the Target Group, using the same EIP, that I'm not seeing? Maybe some documentation that's a little more detailed in setting this all up? Thanks for any info!
- Newest
- Most votes
- Most comments
So, unless there is a specific reason to use NLB, you could use an ALB and create a rule that will deal with the redirect for you. One less thing to think about. Also, you could let then the ALB deal with TLS termination, one less thing again to think about for your NGINX, unless you need/want ALB to NGINX SSL termination (pro-tip, you can use self-signed certs for that).
As for your issue, with NLB, don't forget that these do not have a security group, so the Security Groups that need to be updated are the ones of your ECS services. Also, by default, NLB does not do cross-az traffic, so you'd have to enable that "on top" and implement a better healtheck in route53 so that if a zone is not working, it does not show up in the DNS responses.
Otherwise, for what you are trying to do, I'd recommend to follow this example : this uses Traefik, but you can replace it easily with NGINX/your app. This will automatically deal with everything for you: security groups, ingress, task & service definitions, IAM policies, and so on. You can use your existing infrastructure (VPC) by using the Lookup. It can also deal with route53 & ACM for you.
Hope this helps!
Relevant content
- asked 2 years ago
- asked 6 months ago
- Accepted Answerasked a year ago
AWS OFFICIALUpdated a year ago- AWS OFFICIALUpdated 6 months ago
- AWS OFFICIALUpdated 4 years ago
- AWS OFFICIALUpdated 9 months ago
Thanks for all the info! The NLB came about from reading some docs about Fargate and EIP. I went with the NLB for that reason. I guess an Accelerator + EIP on an ALB will achieve the same thing but not sure I want to add another layer on here. Doesn't Route53 require domain delegation to work correctly (was told that in another discussion)? Not sure that'll fly. I'll take a closer look at that link you posted. Thanks again.