In this video, Jeff Winesett demonstrates accessing a newly created EC2 instance via http.
- [Instructor] Okay, now that I have the load balancer in place, and launched the instance in the target group associated with the load balancer, I can attempt to access the server via HTTP. As a reminder, since I took advantage of Cloudanet and added bash commands to the user data to configure the instance as an Apache web server, I expect to see the default Apache test page when attempting to access the instance via http. So I can do that by going back into EC2.
Getting back down to my load balancers. Choosing the appropriate one, which, we only have one. And grabbing the DNS name, from the descriptions tab. If I copy that, go into a new tab, paste that in. Drumroll please. There it is. Great. It looks like the Cloudanet bash commands worked. They were launched when the instance was launched, Apache was installed and configured, and accessible.
This demonstrates that the server has been bootstrapped as a lamp stack server. Now, one thing I'd like to point out here is that the default Apache web page actually returns an HTTP error code 403 in this response. Even though we're seeing a good page, it's actually saying 403 in terms of the HTTP response. This is because there are no files to execute a return in the default document route for Apache. Which happens to be slash bar slash ww slash html on the web server.
And because the server is returning a 403 error code, the load balancer continues to see the instance as unhealthy. Let's check this out. If I go back over here to the load balancer and I go into the target groups, and I look at my targets, I see a warning that tells me none of the availability zones contains a healthy target. So requests are being routed to all targets. So in this case when the load balancer has no healthy target from which to choose, it just sends the traffic onward to each of the unhealthy instances.
That's only the case when every single one happens to be unhealthy. 'Cause it doesn't really know what else to do with the request. So we see here, we've still got an unhealthy instance and we've got our error code 403, if I hover over that tool tip it tells me, health checks failed with the error code 403. And this is because the default Apache document route has nothing to serve. And let me quickly also explain why 403 is being recognized as unhealthy by the load balancer. This is something that you can configure.
If I go into health checks and I look at the information here, I can see the success codes down here, and it says the HTTP codes to use when checking for a successful response from a target, and I can specify the values. Right now the range is from 200 to 299. Let me go into edit real quick, and you can specify a range. In this case it's automatically set up to just expect 200 back from the web server. Since it's getting a 403 it's being recognized as unhealthy.
So what I'm gonna do next is fix this. I'm gonna add an application file to the document route and in the process, I'll demonstrate how to SSH into the instance.
- Benefits of cloud services
- Making architectures scalable
- Examining cloud constraints
- Virtual servers, EC2, and Elastic IP
- Using the Amazon machine image
- Elastic load balancing
- Using CloudWatch for monitoring
- Security Models
- Elastic block storage
- S3, CloudFront, and Elastic Beanstalk
- Handling queues, workflows, and notifications
- Caching options and services
- Identity and access management
- Creating a custom server image
- Application deployment strategies
- Serverless architectures