How can I use Elastic Load Balancing to troubleshoot the reason that my website can't be accessed?

Last updated: 2022-04-07

My website can't be accessed. How can I use Elastic Load Balancing (ELB) to understand why end users can't access my website?

Short description

There are a number of reasons that you might not be able to reach your website. To find the best path to troubleshoot, first answer these questions:

  • Can the website not be reached, and are you getting a browser default timeout page?
  • Is the issue intermittent?
  • Is the page loading after a delay?
  • Is the page showing an error like HTTP 5XX?

Resolution

Do a DNS lookup and comparison

Confirm that the domain that is facing this issue is correctly resolving to the IP address of the load balancer nodes. This makes sure that the connection attempt that clients are trying is sent to the correct IP address.

1.    Do a DNS lookup:

dig <affected domain>

or

nslookup <affected domain>

2.    Now, do a DNS lookup against the DNS of the load balancer for comparison. For example:

dig lb-xxxxxxxxxx.us-east-1.elb.amazonaws.com

This check is successful if the list of IP addresses match. If the load balancer is in a scale-out state, then there might be more IP addresses than a single DNS response can show. In this use case, this comparison might not be sufficient. You might need to run multiple DNS queries to get all the IPs listed.

Check the status of backend/targets

Check the backend/target health check status. Load balancers have a configured health check that they use to check the status of backend/targets. Depending on the type of load balancer, unhealthy backend/targets can affect routing. Check the health of your load balancer depending on the type:

Note:

  • Enabling or disabling cross-zone can impact how requests are routed with NLB and CLBs.
  • You can configure health checks on ports other than traffic ports. In this case, even if the target/backed is healthy, the target might not respond to traffic sent to it.

If the health check shows the targets as unhealthy, then the service might down at the target/backend instances. Or, the load balancers can't get a response from the target/backend instances.

Connect to the nodes of the load balancer directly

Connect to the nodes of the load balancer directly. This test confirms if all the IP addresses of the load balancer that were DNS resolved previously are reachable. This test also confirms whether the issue is happening only with a specific Availability Zone's (AZ) subnet.

Note the IP addresses of the load balancer, and then attempt a connection to these IP addresses, one at a time. Using a browser for this test might not work due to certificate validations and the host header. Instead, it's a best practice to use the curl tool to perform this check with this format. Note that you must replace <protocol>, <ELB IP Address>, <port>, <path>, and <domain name> with the correct values from your web setup.

curl -lvk <protocol>://<ELB IP Address>:<port>/<path> -H "Host: <domain name>"

For example:

Eg: curl -lvk https://3.2.1.1:443/test -H "Host: example.com"

If your attempt gets a response, then check whether this is the expected response or an error. If the response is satisfactory, then check the next IP address.

Check the load balancer for backend/target issues

If you confirm connectivity to all IP addresses used by the load balancer, then confirm the load balancer's communication status with the target/backend.

1.    First, check the security groups, network ACL, and routing.

2.    If they are allowing access, then log in to the target/backend. After you establish access, confirm that the web service is listening on the configured port using this command. Replace “port" with the listening port of the target/backend. This is the port used when registering the target/backend to the load balancer.

Windows:

netstat -an | findstr "LISTEN" | findstr "port"

Linux:

netstat -an | grep LISTEN | grep "port"

3.    If you don’t see anything listed after mentioning the expected listening port, then the web service is down. Continue to troubleshoot the service status.

4.    If the response shows that the port is listening, then try to connect to it using curl. Replace <protocol> with the listening application service and <port> with the localhost port:

curl -lvk <protocol>://localhost:<port>

If you get a response from this command, then your web service is functioning. During this phase of testing, you can initiate a connection from another Amazon Elastic Compute Cloud (Amazon EC2) instance in the same Amazon Virtual Private Cloud (Amazon VPC). Check if this connection attempt reaches and gets a response from the web service. This response also shows what's received by the load balancer when you attempt to connect to the target/backend.


Did this article help?


Do you need billing or technical support?