By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post

Application Load Balancer : 504 / Timeout

0

Hello !

I'm having a problem that I can't solve despite everything I've read here and elsewhere.

Background: I'm creating my website using Django. I've configured Gunicorn in gunicorn.service so that the server is launched as soon as an application is started. I've created an AMI image of this server. When I run some tests (launching an AMI image with a public IP address), the website is immediately accessible just by entering the IP address. For example http://13.37.209.14/

My VPC is made up of two public subnets and two private subnets. An Internet gateway is linked to the public subnets, enabling access to the Internet.

Before creating my Application Load Balancer and Auto Scaling Group, I created my security groups.

Application Load Balancer

Inbound rules :

  • Source: 0.0.0.0/0 Port: 80 (HTTP)
  • Source: 0.0.0.0/0 Port: 443 (HTTPS)

Outbound rules :

  • Destination: auto-scaling-group-sg Port: 80 (HTTP)
  • Destination: auto-scaling-group-sg Port: 443 (HTTPS)
  • Destination: auto-scaling-group-sg Port: 8000 (Custom TCP)

Auto Scaling Group

Inbound rules :

  • Source: application-load-balancer-sg Port: 80 (HTTP)
  • Source: application-load-balancer-sg Port: 443 (HTTPS)
  • Source: application-load-balancer-sg Port: 8000 (Custom TCP)

Outbound rules :

  • Destination: 0.0.0.0/0 Port: All traffic.

I created my Auto Scaling Group via the same launch template used to create the instances, which work simply by entering the server's IP address.

I've read that it's recommended not to indicate "assign a public IP address" in the launch template. So I left it at "no", putting only the IAM role required for the instance.

In the Auto Scaling Group I used the VPC and chose the two public subnets for instance creation. At the same time, I chose to create the load balancer with a listener on port 80 for testing purposes.

Unfortunately, the health check systematically fails. With the message "Request timed out".

The load balancer returns a 504 error.

Do you know where this might be coming from?

Topics
Management & GovernanceCompute
Tags
AWS Auto ScalingAmazon EC2Application Load Balancer
Language
English
Geoffrey
asked 3 months ago284 views
2 Answers
1

Hello.

How about making the security group settings a little more loose to determine the cause?
For example, try setting the outbound rule of the security group configured in ALB to allow all traffic.
Also, if I use the EC2 inbound rule to allow connections from 0.0.0.0/0, will the health check succeed?

Is the correct EC2 security group attached?
Please check whether the launch template settings are incorrect and the wrong security group is attached.

profile picture
EXPERT
Riku_Kobayashi
answered 3 months ago
  • Geoffrey
    3 months ago

    Thank you for your answer.

    I may have found the source of the problem, which I find incomprehensible.

    Before making the AMI image, I put a security group on my EC2 instance allowing all traffic on ports 80 and 443. In tests, everything works.

    I now realize that each instance created from this AMI image is inaccessible if it has a different security group from the one used when the image was created. Even if the VPC and rules are IDENTICAL!

    On the other hand, if I set the same security group as the original instance: it works.

    What could be the cause of this? It looks like the instance and the AMI image are linked to the security group and not to the rules? Is this possible?

    I've tried changing the security group of the original instance, still with the same rules: the site becomes inaccessible! I've never encountered this

  • Riku_Kobayashi EXPERT
    3 months ago

    What could be the cause of this? It looks like the instance and the AMI image are linked to the security group and not to the rules? Is this possible?

    I've never seen such a situation either.
    For now, try allowing HTTP at 0.0.0.0/0 in the inbound rule of the security group set for EC2 and see if it succeeds.

  • Gary Mclean EXPERT
    3 months ago

    AMIs are not tied to security groups. Meaning the setting is not inherited. When you spin up an instance manually or in an ASG you still need to define the security group you want to use. Remember it will not work with a different security group even if the rules are identical because your ALB security group is referencing a security group on the outbound rules which is different.

0

I think you are over complicating the configuration with these outbound rules in ALB security group

Outbound rules :
    Destination: auto-scaling-group-sg Port: 80 (HTTP)
    Destination: auto-scaling-group-sg Port: 443 (HTTPS)
    Destination: auto-scaling-group-sg Port: 8000 (Custom TCP)

As Gary pointed above, this does bind your ALB and ASG sec. groups so if you create new group for ASG, it won't work before reference from ALB group is broken. I would allow all outbound connection from ALB sec.group as these are limited by your listener configuration anyways. ALB won't connect anywhere but to backend registered to it.

profile picture
EXPERT
Kallu
answered 3 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions

Relevant content