Please note - this course has been removed our content library and replaced with a new course: https://cloudacademy.com/course/understanding-aws-lambda-run-scale-your-code-4006/introduction/
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.
Learning Objectives
- 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
Intended Audience
- 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.
Prerequisites
- 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:
- Node.js
- Python
- Java
- C# (.NET Core)
- Go
- Ruby
Related Training Content
Hello, and welcome to this lecture on event sources. I covered event sources and event source mappings in the previous lecture, but now I want to expand a little further on these elements. So let me clarify what an event source is and what an event source mapping is. An event source is an AWS service that produce the events that your Lambda function responds to by invoking it. For a comprehensive list of these event sources, please see the following URL. Event sources can either be poll or push-based. At the time of writing this course, the current poll-based event sources are Amazon Kinesis, Amazon SQS, and DynamoDB. When using these services as an event source, Lambda actually polls the service looking for particular events. For example, Lambda will poll the message queue for SQS and then Lambda will synchronously invoke the associative function when a matching event is found. Push-based event sources cover all the remaining supported event sources. Services using this push model publish events in addition to actually invoking your Lambda function. That's one of the key differences.
The event source service invokes the function instead of Lambda, which is what happens for poll-based event sources. Event source mappings. Simply put, an event source mapping is the configuration that links your event source to your Lambda function. It's what links the events generated from your event source to invoke your Lambda function. However, depending on if the event source is push or poll-based, determines where this event source mapping is configured and stored. For push-based event sources, the mapping is maintained within the event source. Using the appropriate API calls for the event source service, you are able to create and configure the relevant mappings. For example, using the API for S3 bucket notifications, you can specify which events to publish within that bucket and which of your Lambda function to invoke based on those notifications. This will require specific access to allow your event source to invoke the function. And this access is granted through the Lambda function policy, which we discussed in the previous lecture. Poll-based event source mappings are sightly different in that the configuration of the mappings are held within your Lambda function instead. Using the CreateEventSourceMapping API, you can set up the relevant event source mapping for your poll-based service.
Again, permissions will be required, but this time, instead of the permissions being modified within the function policy, permission is required in the Execution role policy, as it will be the function that will be polled in the service, looking for a match relating to the mapping. For more information regarding the CreateEventSourceMapping API, please visit the following URL. When I explained what event sources were, I mentioned synchronous invocation. But what's the difference between a synchronous and asynchronous invocation, and what controls which option? When you manually invoke a Lambda function or when your custom-built application invokes it, you have the ability to use the invoke option, which allows you to specify if the function should be invoked synchronously or asynchronously. More information on this option can be found here. When a function is invoked synchronously, it enables you to assess the result before moving onto the next operation required. You may need to know the outcome of one function before using the value or result within another function.
If you want to control the flow of your functions, then synchronous invocations can help you maintain an order. If these points are not of concern to you or your function, then invoking functions asynchronously would be the preferable option. When using event sources to call and invoke your function, then the ability to select an invocation type is removed. In this case, the invocation type is very dependent on the actual service itself. For poll-based event sources, the invocation type is always synchronous. For push-based event sources, it varies on the service. As you can see from this table, AWS CloudFormation always invokes functions synchronously and AWS Config asynchronously. That now brings me to the end of this lecture covering event sources and event source mappings. Coming up in the next lecture, I shall be covering techniques to help you troubleshoot your Lambda functions.
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.