Troubleshooting HTTPS on AWS ALB: Target Group Health Check Failing

Question

I'm having trouble setting up HTTPS for my AWS EC2 instance. In short, I'm running a program on an EC2 instance, and it's critical that I be able to transfer the data securely from clients to AWS.

What I've done so far:

On AWS:

• Launched an EC2 Instance (t2.micro, ubuntu). The instance is alive and well, and accessible through SSH.
• Created a public SSL certificate through Amazon's Certificate Manager, under www.ourdomain.com
• Created an internet-facing application load balancer with an HTTPS listener (on port 443), using the previous certificate
• Created a target group with our EC2 instance and added it to the load balancer
• For the load balancer security group, enabled inbound HTTPS from anywhere, and outbound HTTP and HTTPS to the security group of the EC2 instance
• For the instance security group, enabled inbound HTTPS from the load balancer security group

On GoDaddy:

• Created a CNAME record (host: www.ourdomain.com, value: load balancer DNS name)

Issues:

• Under the "Targets" tab for my target group, I see the following: "None of these Availability Zones contains a healthy target. Requests are being routed to all targets"
• Additionally, under the "Targets" tab of the target group, the info button for the instance says: "Health checks failed with these codes: [502]"
• If I check the domain on ssllabs.com, I get "Assessment failed: Unable to connect to the server"

I want to avoid using Route53 if possible, and unfortunately I can't find AWS documentation for this issue that doesn't involve Route53.

I'm not a networking or AWS expert, so it is entirely possible that something simple is missing. Any and all suggestions are greatly appreciated!

Solution 1

Apart from what @Jakub has mentioned, make sure that your health check APIs work fine. I've been using AWS Fargate and when the load balancer is created, the health check will have default '/' as health check API and when you create ECS service then it takes the service's name '/ecs-service'. You can check your health check APIs configured here as given in this link https://engineering.telia.no/blog/troubleshooting-fargate-health-check

AWS CLI Command: aws elbv2 modify-target-group --target-group-arn "" \ --health-check-timeout-seconds 30 \ --health-check-interval-seconds 200

If you are using ECS Fargate make sure you have these steps in place: 1) Whether the subnet ip address is accessible in your container 2) Are your docker container port exposed properly? 3) Does your health check API work properly?

Solution 2

Chupacabra has some good suggestions, have they not helped? I too have wasted too much time on this and summarize my tips here: AWS Fargate: Troubleshooting the dreaded 'service .. is unhealthy'

top tips:

1. Do requests for / return 200 OK?
2. Do they return quickly enough?
3. Does the service start responding quickly enough after a start?
4. Does the listener try to contact the service on a port where it is actually running, using the correct protocol? Does the service's security group allow the load balancer's security group to access the port?

See the blog post for details and more tips.

Comments

[payne]

Nowhere he mentions using Fargate.

[payne]

Why do they need to be in a separate subnet?