6

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!

pixel-drinker
  • 61
  • 1
  • 1
  • 2
  • I have precisely the same problem. Did you solve it? – payne Mar 26 '20 at 17:21
  • Possible related: https://stackoverflow.com/questions/76975848/aws-alb-target-group-health-checks-failing-for-ec2-instances-http2-vs-http1 I appear to have fixed my case of this issue by using HTTP1 instead of HTTP2. I have no idea why that works though. – Frikster Aug 26 '23 at 06:31

3 Answers3

1

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.

Jakub Holý
  • 393
  • 1
  • 4
  • 15
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?

0

502 is a bad gateway, you have some routing issues. More than likely it's your security group or routing table.

Your alb/elb and ec2 instance should be in separate subnets in the same VPC.

Your elb should accept connections on port 80 and redirect them to port 443, and your EC2 instance should accept connections on port 80 from the subnet where the elb lives.

Create a target group that points to the subnet where the EC2 instance lives on port 80 but you have to make sure that your instance is actually listening on that port.

Then create an ELB that that uses that target group.

For your port 80 listener rule, make sure that it redirects to https://www.ourdomain.com:443/? , status code http_301.

For your port 443 listener rule, forward to your target group.