Configuring Route53, ALB, and Fargate with a Flask web application

Question

I have a flask web app that I'm starting on port 80. I have a health check endpoint at /.

The flask app is inside a docker container with port 443 exposed.

I also have an ALB listening on

• port 80 redirecting to port 443
• port 443 with a SSL certificate I obtained from Amazon Certificate Manager after purchasing a domain name on Route53 and forwarding to my TargetGroup.

The SSL certificate is marked as "Issued" and "In Use".

The ALB's security group allows inbound and outbound traffic only on ports 80 (http) and 443 (https).

My Fargate cluster has an active service and the load balancer is in the TargetGroup and belongs to the same security group described above. The container port is 443.

I have one task associated with my service, and it is running.

At this point, I'm having trouble getting any response from my load balancer, which I've been trying to access through my browser. My registered domain name is also not responding, but I suspect it is because the load balancer isn't responding, so that's what I'm focusing on in this question.

I wasn't sure where to begin, so I used

nmap -p80 my-alb-xxxxxx.my-region.elb.amazonaws.com

But that tells me 0 hosts are up. I get the same result using port 443.

My understanding (help) is that my load balancer will accept traffic on 80 and 443, reroute to 443, which is the port my docker container exposes, and will reach my webapp running on 80.

This leads to the following questions:

1. Does my flask app need to know about the https handshake or ssl certificate?
2. Is my idea of exposing port 443 in my docker container connected to the outbound rule of my security group associated with the load balancer?
3. What else can I do to debug why my load balancer dnsname (my-alb-xxxxxx.my-region.elb.amazonaws.com) doesn't respond.

Answer 1

I'm going to answer the parts of this I can, using the experience I have.

1. No. I'm assuming you are encrypting the traffic between the outbound world and the LB. It sounds like the traffic from the LB to your Fargate cluster is unencrypted. This is fine. Think of the traffic is unaware of its journey from one segment to another. Right now encryption terminates at the LB. The redirect from port 80 to 443 is when clients attempt to connect without specifying a connection type, it will switch to 443.

2. If you do this, you must be able to encrypt the connection. For testing purposes, to make sure you have the signal path working, I would leave your fargate task listening on port 80, and forward traffic to port 80. (Load Balancer to Fargate). See these resources for more information: https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-troubleshooting.html

https://gist.github.com/jonashaag/4c01174c92ac71986e3dcc44cec6ad9c

https://docs.aws.amazon.com/AmazonECS/latest/userguide/service-load-balancing.html

3. So, unless you open the right ports (specifically) on the load balancer Security Groups, it won't respond to generalized ICMP requests. Please see this question/answer for more information:

Cannot ping AWS EC2 instance

• bottom line is that Security Groups act the same for ELBs as they do for instances.

Right now, I'd check the SG's and allowed ports between Fargate and the ALB. Remember:

• The ALB must forward the traffic to the same port the application is listening on in your app. If your application exposes port 5050 when it is listening - the elb must forward the traffic to 5050.
• That port must be authorized on the SG for the Fargate cluster
• If you have any ACLs, they must authorized the traffic in both directions (if you didn't set this up don't worry, it's not on by default)