Skip to main content

AWS ELB Connectivity Troubleshooting Scenario

Hands-On Lab


Photo of Thomas Haslett

Thomas Haslett

Vice President of Product





Welcome to this hands-on AWS Learning Activity for troubleshooting EC2 connectivity issues. The goal of this activity is to fix the broken environment and achieve the goal as outlined below. The first video in this activity presents the scenario and the goal, while the second video provides the solution (if needed). Do your best to solve the connectivity issue without viewing the solution video. Goal: Fix the connectivity issue in the AWS environment so that you can view the Linux AMI/Apache test page of the provisioned EC2 instances via the ELB's DNS name. Note/Hint: If your Instances don't show "In-Service" after a bit, try toggling the check type to http then back to tcp port 80. Good luck!

What are Hands-On Labs?

Hands-On Labs are scenario-based learning environments where learners can practice without consequences. Don't compromise a system or waste money on expensive downloads. Practice real-world skills without the real-world risk, no assembly required.

AWS ELB Connectivity Troubleshooting Scenario


The goal of this hands-on lab is to fix the connectivity issue in the AWS environment so you can view the Linux AMI/Apache test page of the provisioned EC2 instances via the elastic load balancer's DNS name.

Log in to the AWS live environment via the cloud_user credentials provided. Please make sure you are working in the us-east-1 (N. Virginia) region.

First Attempt to Connect

Once inside AWS, navigate to EC2 and then head to the running instances. Copy and paste the public IP address of either one of the instances into a new browser tab to verify Apache has been correctly installed (which is confirmed by the browser displaying the test page).

Back in the AWS console, click Load Balancers in the sidebar. Copy and paste the DNS name listed for the existing load balancer into a new browser tab. Here, we'll see the test page isn't loading.

Let's pinpoint the problem and resolve it.

Understanding the Architecture

As we saw before, we have two running EC2 instances, which are both in public subnets with public IP addresses. We know we can take the public IP address of one of the instances and access the test page, so we know everything is working as far as security groups, network access control lists, etc. We also know there's a proper internet gateway, which has been attached with proper routing through the route table.

We also know, however, there's an issue with the elastic load balancer itself, since we weren't able to access the test page using its DNS name.

Let's take a look at the potential issues.

Issue #1

Back in the AWS console, head to the load balancer page. Make sure our load balancer is selected, and scroll to the Description section below. Under Security, click the listed security group.

On the security group page, click the Inbound tab. Here's a problem: The security group is only allowing traffic over port 22, but it should be HTTP over port 80.

Let's fix it.

Solution #1

Click Edit, change Type to HTTP, and click Save.

Now, copy and paste the elastic load balancer's DNS name into a browser tab again. Alas, we still don't see the test page. Let's continue our diagnosis.

Issue #2

Back in the load balancer page, click the Instances tab in the section below. Under Status, we'll see both instances are listed as OutOfService — which means there could be an issue with the health checks.

Click the Health Checks tab, where we'll see the issue: The Ping Target is set to TCP:8000. That's not a port we want to ping and test our health check against — it should be set to port 80.

Solution #2

Click Edit Health Check, change Ping Port to 80, and click Save.

Click the Instances tab again, where we should see their status has changed to InService.

Try the elastic load balancer's DNS name in the browser again. This time, we should successfully see the test page.


Congratulations on completing this lab!