AWS Compute Fundamentals
AWS Elastic Beanstalk
The course is part of this learning path
This course provides detail on the AWS Compute services relevant to the Developer - Associate exam. We shall be looking at Amazon EC2, AWS Elastic Beanstalk, and AWS Lambda.
- Understand when you use Amazon EC2
- Learn about the components of Amazon EC2
- How to create and deploy EC2 services
- Understand what EC2 auto scaling is
- Be able to configure auto-scaling launch configurations, launch templates, and auto-scaling groups
- The ability to explain what AWS Elastic Beanstalk is and what it is used for
- The knowledge of the different environments that Elastic Beanstalk provides, allowing you to select the most appropriate option for your needs
- An explanation of how to configure the service and some of the parameters that you can alter to meet your application requirements
- The knowledge of the different monitoring options available for assessing your environment and resources health
- Be able to explain what AWS Lambda is and what its uses are
- Define the components used within Lambda
- Explain the different elements of a Lambda function through its creation
- Understand the key differences between policies used within Lambda
- Recognize how event sources and event mappings are managed for both synchronous and asynchronous invocations
- Discover how Amazon CloudWatch can monitor metrics and logs to isolate issues with your functions
- Learn how to check for common errors that might be causing your functions to fail
Hello and welcome to this lecture, where I shall be looking at how Elastic Beanstalk performance monitoring in both your web and work environments. As we just saw in the demonstration in a previous lecture, there are a number of configurable elements when setting up your environment that will affect what monitoring and logging takes place. There are two different levels of monitoring within Elastic Beanstalk that you can choose from. This being basic health reporting and then enhanced health reporting and monitoring. Let's look at both of them to see how they differ.
Starting with basic health reporting, as expected, basic health reporting will not provide as granular measures as enhanced health reporting and monitoring would. However, it does still provide information and data to relay to you a high-level overview of how your environment is performing. Any resources running in your environment will send metrics to Amazon Cloudwatch in five minute intervals, as if there would be if you'd deployed them without Elastic Beanstalk. These metrics would cover a range of resources. For example, if you are running a Web Tier, it would include metrics on EC2 or ELB request rates. If you were running in a Worker Tier, then you would have metrics associated to SQS. However, these Cloudwatch metrics collated are not actually used in the process to determine how healthy the environment is. The health of the environment is actually determined by other checks, as I'll explain. And results of these checks are presented by four colors within the Elastic Beanstalk dashboard as shown. For an environment using Elastic Low Balances, typically a Web Tier, then every 10 seconds, the ELB will send a health check request to every instance in the Auto Scaling group and wait for a response to confirm its health. If a response is received, the instance is considered healthy. For environments that do not necessarily have an ELB, for example, an environment with a single instance or Worker Tier, then the health of its instance is determined by its EC2 instance status check.
These status checks are controlled by EC2 and used to check the health of the status of your EC2 instance. And understanding what common faults could trigger these checks to fail can help you troubleshoot issues with your resources. There are two types of status checks. Firstly, the system status check. If this fails, then it's likely to be an issue with the underlying host, rather than a configuration issue with your EC2 instance itself. Common issues that trigger system status checks to fail are loss of power, loss of network connectivity, and hardware and software issues on the underlying host. Basically, a system status check failure is out of our control, but the fault lies with components that are managed by AWS. The best way to resolve this would be to stop the instance and restart it. This is likely to cause the instance to launch on another physical host, resolving the issue. And then we have the instance status check. Now these differ from the system status checks, as if this fails, then it would likely require our input to help resolve the issue. This check looks at the EC2 instance itself, rather than focusing on the underlying host. Common issues that trigger this check to fail are incorrect network configuration, corrupt file systems, exhausted memory, or an incompatible kernel. And these faults will require you to troubleshoot and resolve the issue. For example, changing the network configuration.
Elastic Beanstalk also provides high-level monitoring of your other resources as well that might have been identified as red. Elastic Beanstalk will ensure that in a web environment, if an Auto Scaling group is being used, that it is operational and it has a minimum of one instance running that is healthy. It will also ensure that the correct settings in Route 53 are being used, ensuring that the C name is redirected to the correct ELB. Finally, it will check to ensure that the security group for your EC2 instances allows port AT inbound and for work environments, Elastic Beanstalk will check to make sure that the SQS queue being used is being pulled every three minutes at a minimum. Let me now look at enhanced health reporting and monitoring. The color index signifying the health of the environment when using enhanced health reporting has a different meaning to the color index used in basic monitoring. As a recap, basic health reporting looks as follows. Whereas enhanced can be summarized as shown. As you can see, the enhanced health monitoring displays additional information to that over the basic. In addition to this, where environments are configured for enhanced monitoring, the AMIs used for your EC2 instances also have a health agent installed and running, where supported, while a platform's selected. And this allows Elastic Beanstalk to capture additional information, such as system metrics and web server logs. This allows Elastic Beanstalk to determine at a deeper level the overall health of the environment, while correlating it with data, also taken from the ELBs and Auto Scaling groups. These additional metrics captured by Elastic Beanstalk can also be sent to Cloudwatch as custom metrics. However, this feature does incur an additional cost.
By sending data to Amazon Cloudwatch, it allows you to view the health of your environment over time and also allows you to set thresholds and notifications that you would with any other Cloudwatch metric. For more information on Amazon Cloudwatch, please see our existing course here. The health agent is simply a demon or service installed onto your deployed EC2 instances, with a sole purpose of reporting statistics and metrics from your instance RS and applications running on that instance. The main difference between the metrics of the health agent and those that Cloudwatch collect is that the health agent probes the instance at a deeper level and more frequently over Cloudwatch. In fact, Elastic Beanstalk gets data from its resources every 10 seconds and assesses the results to determine the health of the instances, based on the color indicators I explained earlier.
That now brings me to the end of this lecture. Coming up next, I shall be providing an overview of some of the key points taken throughout the previous lectures.
Stuart has been working within the IT industry for two decades covering a huge range of topic areas and technologies, from data center and network infrastructure design, to cloud architecture and implementation.
To date, Stuart has created 150+ courses relating to Cloud reaching over 180,000 students, mostly within the AWS category and with a heavy focus on security and compliance.
Stuart is a member of the AWS Community Builders Program for his contributions towards AWS.
He is AWS certified and accredited in addition to being a published author covering topics across the AWS landscape.
In January 2016 Stuart was awarded ‘Expert of the Year Award 2015’ from Experts Exchange for his knowledge share within cloud services to the community.
Stuart enjoys writing about cloud technologies and you will find many of his articles within our blog pages.