Search code examples
amazon-web-servicesflaskamazon-ecsaws-application-load-balancer

Flask containers on ECS Fargate are completely unresponsive


I have two tasks running in ECS Fargate, representing a basic Flask application that runs on port 5000. My application load balancer is deregistering these tasks due to failed health checks.

The ALB deregisters the tasks in spite of the following facts:

  • My ECS tasks are assigned public IP addresses.
  • My Flask application is running. I aws ecs execute-command'ed into one of them to confirm.
  • Port 5000 is called out explicitly in my ECS task definition's port mappings.
  • Port 5000 is called out explicitly in my ECS service's load balancer container port configuration.
  • My application load balancer is associated with a security group that allows TCP ingress on port 5000, and egress to 0.0.0.0/0 with ip_protocol="-1".
  • My application load balancer's target group allows for HTTP traffic on port 5000, with target_type=ip.
  • My application load balancer's listener is configured to route incoming traffic on port 80 to the target group referenced above.
  • My ECS tasks are deployed to public subnets with route table associations that link them to CIDR block 0.0.0.0/0.

When a task is up-and-running:

  • telnet and curl time out.
  • nmap -Pn reports that all 1,000 scanned ports are in ignored states.

Why are my ECS tasks completely unresponsive to any form of interaction whatsoever? How do I debug the issue?

EDIT: See Mark's answer below. The issue was that ECS tasks need security groups to communicate with the ALB (AWS will create useless ones for you if you don't specify them in the task definition). Then ECS needs to be able to communicate with ECR, which requires opening up egress on port 443 specifically if you don't want to use PrivateLink.


Solution

  • You need to have two security groups, one for the ALB and one for the ECS tasks, since they both need different ports open.

    The ECS task should have an inbound rule allowing traffic on port 5000 from the ALB's security group ID as the source.