Now that we have deployed an auto scaling group to contain our public instances, we can place an Elastic Load Balancer (ELB) in front of these public instances. This will allow for better traffic distribution across the group of public instances. Additionally, it provides for a much better user experience: an ELB can have a single DNS name, instead of having to manually navigate to the address of individual instances within the ASG.
Estimated time to complete: 45 minutes
Cost: Elastic Load Balancers incur a cost. Consult the ELB Pricing Website for complete information.
Perform the following from the Load Balancers section of the EC2 console.
- Create a new Classic Load Balancer
- Set the load balancer name to "Lab-ELB"
- Create the load balancer within your Lab VPC and public subnet
- Leave the load balancer and instance protocol and port set to HTTP/80
- Use the existing security group that permits web traffic from anywhere and SSH from your IP only
- Configure the health check with the following attributes:
- Ping path: /index.php
- Advanced details:
- Response timeout: 2
- Interval: 5
- Unhealthy threshold: 2
- Healthy threshold: 2
- Do not add any EC2 instances to the load balancer
- We will add the load balancer to the ASG in the next step
- Uncheck "enable connection draining"
- Create the ELB
Perform the following from the Auto Scaling Groups page of the EC2 console.
- Select the previously created ASG and choose "Edit" from the "Actions" menu
- Specify the newly created ELB as the load balancer for the group
- Save your changes
Now that we have an ELB deployed, we can begin to test it.
Perform the following.
- Navigate to the DNS name of the ELB
- The web app should load
- Navigate to the public IP address of the admin instance
- Navigate to the Admin page
- Add a new picture
- Navigate to the DNS name of the ELB and ensure that the new picture is visible
Now that we are confident in the basic functionality of the ELB, we want to ensure that it can handle instance failover situations. To accomplish this, we will simulate a failed instance.
Perform the following.
- Edit your ASG from the "Auto Scaling Groups" section of the EC2 Dashboard
- Change the number of Desired instances to 2
- This will cause the ASG to launch a total of 2 instances at all times
- Navigate to the "Load Balancers" section of the EC2 Dashboard and review the Instances tab for your load balancer
- You should see both instances from the ASG listed and InService
- This may take a few minutes
- Navigate to the DNS name of the ELB and ensure that the web app loads
- Simulate an instance failure by stopping (not terminating) one of the public instances from the "Instances" section of the EC2 Dashboard
- Review the Instances tab for the ELB. You should notice that the stopped instance is now marked OutOfService
- Navigate to the DNS name of the ELB and ensure that the web app still loads
Document the information below about your environment.
ELB Name | DNS Name |
---|---|
Lab-ELB | Lab-ELB-xxxxxxxxxx.us-east-1.elb.amazonaws.com |
You will incur fees if you do not delete the ELB instance created during this lab. The teardown process is below.
- Delete the ELB from the Load Balancers page of the EC2 console
-
Explain the differences between an Application Load Balancer and a Classic Load Balancer.
-
What is an internal load balancer?
-
What is the difference between the load balancer protocol and port, and the instance protocol and port?
-
During the lab, you changed the values of several load balancer timers. Explain the purpose of each timer:
- Response timeout
- Interval
- Unhealthy threshold
- Healthy threshold
-
What is connection draining? Why would it be useful?
-
What type of Route53 record would be necessary to point the zone apex at an elastic load balancer?