Monitoring and Common Errors


AWS Compute Fundamentals
What is Compute?
Amazon EC2
PREVIEW28m 26s
AWS Batch
EC2 Auto Scaling
ELB & Auto Scaling Summary
7m 37s
SAA-C02- Exam Prep
Start course
2h 55m

Please note that this course has been replaced with a new version that can be found here:


This section of the Solution Architect Associate learning path introduces you to the core computing concepts and services relevant to the SAA-C02 exam. We start with an introduction to the AWS compute services, understand the options available and learn how to select and apply AWS compute services to meet specific requirements. 

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

Learning Objectives

  • Learn the fundamentals of AWS compute services such as EC2, ECS, EKS, and AWS Batch
  • Understanding how load balancing and autoscaling can be used to optimize your workloads
  • Learn about the AWS serverless compute services and capabilities

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.