The course is part of these learning paths
Learn and be able to implement solutions and applications using a serverless architecture with this AWS Lambda Course from Cloud Academy. By running your enterprise with this feature in mind you will be able to operate a more efficient environment and reduce overall costs. Gain an insight into the key compute serverless services used by AWS and understand the configuration and management involved.
This course is made up of 6 lectures, including a 24-minute demo video on how to configure a function.
For more related training content, try out the Learning Paths below.
- 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
- This course has been designed for those who are new to AWS Lambda, but are keen to understand how serverless architectures can help with their solutions.
- If you are a developer or responsible for maintaining and managing your serverless environments then this course would be advantageous.
- If you are studying for the AWS Certified Developer - Associate certification then this course is also recommended as AWS Lambda is covered heavily.
- As a prerequisite of this course, it is recommended that you have an understanding of what is meant by serverless architectures.
- If you are unfamiliar with this term, then please take our existing course ‘What is Serverless computing’ within our ‘Getting Started with Serverless Computing on AWS’ Learning Path.
- You should also be familiar with a programming language supported by AWS Lambda, these include:
- C# (.NET Core)
Related Training Content
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 100 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. That now brings me to the end of this lecture. Coming up next I shall be providing a summarized overview of the key points made throughout this course.
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 80+ courses relating to Cloud reaching over 100,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.