Monitoring and Common Errors
Start course
2h 7m

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.

Want more? Try a lab playground or do a Lab Challenge!

Learning Objectives


  • 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

Amazon CloudWatch


Hello and welcome to this lecture covering the different methods to help you monitor and troubleshoot issues that you may experience with your Lambda functions. Thankfully, monitoring statistics related to your Lambda function within CloudWatch is by default already configured. This also includes monitoring your functions as they are running. CloudWatch has the following metrics that are automatically populated by Lambda. Invocations. This determines how many times a function has been invoked and will match the number of billed requests that you are charged. Errors. This metric counts the number of failed invocations of the function, for example, the result of a permissions error. DeadLetterErrors. This counts the number of times Lambda failed to write the dead letter queue, for example, due to misconfigured resources or permission issues. Duration. This metric simply measures how long the function runs for in milliseconds from the point of invocation to when it terminates its execution. Again, used for billing, however, Lambda billed requests are measured in per millisecond time frames. Throttles. This is to count as how many times the function was invoked and throttled due to the limit of concurrency having been reached. IteratorAge. This is only used for stream-based invocations such as Amazon Kinesis. It measures in time how long Lambda took to receive a batch of records to the time of the last record written to the stream. This IteratorAge is measured in milliseconds. ConcurrentExecutions. 

This is a combined metric for all of your Lambda functions that you have running within your AWS account in addition to functions with a custom concurrency limit. It calculates the total sum of concurrent executions at any point in time. UnreservedConcurrentExecutions. Again, this is also a combined metric for all of your functions in your account, and it calculates the sum of the concurrency of functions without a custom concurrency limit at any given time. By utilizing these metrics that are published into CloudWatch you are able to maintain an overview of your functions, and if you are experiencing any unexpected errors. Using the features of CloudWatch you can easily create a dashboard relating to your functions. For more information on CloudWatch and how to configure the service to get the most from your metrics, please see our existing course here. In addition to these metrics, CloudWatch also gathers log data sent by Lambda which are very useful to drill into if you are noticing erroneous patterns emerging from your CloudWatch metrics. For each function that you have running, CloudWatch will create a different log group. You can also add custom logging statements into your function code. As you can see here, CloudWatch has automatically created two different log groups, one for each function.

The log group name will be prefixed with aws and lambda. So in this example, we have the logs from functions MyNewFunction and Testing. You can also add custom logging statements into your function code, which are then used to ensure that your function is operating correctly. These logging statements are used to push data to CloudWatch logs automatically in addition to the managed messages that are sent by default. Depending on the language you are using your function will depend on the statements used. As an example, if using Node.js, the following statement can be used to generate custom logging statements. For more information on how to configure and set these logging statements up for each programming model, please see the following AWS link. When working with Lambda people often come across similar issues and I just want to spend a couple of minutes talking about these points to help you easily identify what might be causing the issue. Some of the common issues as to why your functions might not run relate to permissions. As we know, an AIM role is required for Lambda to assume and execute the code of your function.

In addition to this role, we also have to create a function policy which specifies which AWS resources are allowed to invoke your function. Having an error in either one of these components can cause your function to fail. If within the role execution policy, for example, you fail to add permissions to operate your function within a VPC to allow the creation of ENIs using the following permissions, then your function would fail. Alternatively, if your function policy does not include the correct permissions to allow your push-based event source to trigger the function required, then again you will receive a failure. Going back to CloudWatch and logs and how they are used by Lambda. Well, if the CloudWatch permissions were removed from the execution role, your logs would not be published to CloudWatch and would fail to be created. Permissions and access to resources from both your execution role and function policy are the most likely cause of issues as to why a function would fail. Be sure to check your policies and understand which policy is used for which purpose.

About the Author
Learning Paths

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.