Getting started with Lambda
How Lambda works
Practical Usage of Lambda
Start course

Executing code in response to specific event triggers is a common need. In fact, Event-Driven Programming has long been an important approach in Software Development. So if trigger response is useful within an operating system, why not for cloud-based web applications? To answer precisely that need, Amazon recently released Lambda. Lambda will launch AWS resources and execute snippets of code in response to predefined events, automating the management of all of necessary underlying infrastructure...and at a ridiculously low price.

In this course you'll get complete introduction to AWS Lambda. Lambda is not a particularly complex service, but setting IAM roles and security groups might be tricky. This tutorial, written by our expert Cloud Solutions Architect Kevin Felichko, will help you understand how to get started, and will also show you an interesting and practical use-case.


Who should take this course

Being an intermediate level course, you are expected to have at least some experience with AWS and its core services. Also, knowing programming and in particular the Javascript language will definitely help you following the practical part.

If you want to learn more about the AWS services being discussed here, check out our other AWS courses. Also, our Lambda quiz questions can serve as a nice follow up. You will be tested on what you learnt in this video, but will also learn more at the same time thanks to the documentation associated with each question.

Do you have questions on this course? Contact our cloud experts in our community forum.


In this lesson, we will show Lambda in action, using a custom application called the S3 restaurant. The S3 restaurant application is pretty simple. A customer using either an unseen mobile app or consumer facing website will place an order. The order will be uploaded to an S3 bucket in JSON format. This is where Lambda will enter the picture. S3 will push an event to our Lambda function that does two things. First, it writes the information to a DynamoDB orders table.

Second, it makes a call to our web application, letting it know that a new order has arrived. Our web application will push the order into elastacash and then publish the event to all listening web clients. When the order has been fulfilled, we mark the order as ready, which then executes a Lambda function that sends a message via SNS to a driver. The first Lambda function we create is responsible for processing the order that is uploaded to S3. When our function is invoked via an S3 event, we receive S3 specific arguments. We use the bucket name and key to get the contents of the uploaded file. Once retrieved, we add a unique identifier, build our content string, and write to our order's DynamoDB table. Remember, we are running under our execution role, that has been given permission to read from our S3 bucket, and write to our DynamoDB table. Therefore, we do not need to set up any access keys with our API. Once the order has been written to our table, we make the call to our web applications method, using the HTTP object. It would simplify our application if we could write and publish an entry directly into our elastocash cluster from Lambda. However, this is not possible. If you recall from our last lesson, Lambda functions run within a container that is not connected to our VPC. Lambda can only interact with internet connected resources. Elastacash is not one of them.

It is a resource that cannot be accessed from outside the VPC, unless we take some steps that require additional costs and resources. To solve this, we've created a web function to accept the order and publish to Elastacash. Finally, we instruct Lambda that we have completed our work via the context.done method call. A context object is one of the arguments sent into our function by Lambda. When calling context.done, we specified two arguments. The first argument indicates if a function was successful or not. A null value means success. Any other value tells Lambda that an error occurred. Any non-null value is included in the cloud watch log stream to help us determine what happened. The second argument is a string that will be written to the console, regardless of success or failure. This is optional. If we do not call context.done when our function is completed, our function may run longer than necessary, which will affect the pricing and our CPU share. Be sure to make the call at the earliest possible moment that does not negatively affect the work load. We have added a few libraries to assist with our workload. This means we will need to create a deployment package. Before we zip everything up, we need to run the NPM install command to add the dependencies to our local folder. Then we zip up the entire folder and upload it to Lambda.

Once uploaded, we need to specify the file to execute and our handler name. This tells Lambda what to execute. We assign the role in execution policy. Under advanced settings, we set the memory allocated to our function. We can also set the time out before Lambda terminates the execution of our function. Our options range from one second to one minute. After choosing our options, we save the function or save and invoke the function using a sample event. Our second Lambda function is responsible for publishing an SNS topic. This function will accept an order ID, build a message, and publish to SNS.

We will create this function with an inline editor, since we do not need any additional libraries. Once in the editor, we can change all the same settings, except for the file to execute, which is not necessary given the inline file setting. We save the function and now are ready to test our system. Before we can run our test, we have to let S3 know we want to invoke Lambda when an event occurs. Under the properties for the S3 bucket, we had a notification giving it a name, selecting the S3 event we want to trigger our function, select the Lambda recipient, and enter the ARN for the Lambda function to execute, and the invokation role. Here is our test JSON order file. Nothing special. We just upload it to S3 via the S3 console. Based on available resources, it might take some time before our Lambda function is invoked. Once it has been invoked, we will see a marker show up on our map and an entry in the orders table. We will now mark the order as ready to be delivered, which will push a message to our SNS topic. The web application will invoke the Lambda function via a call through the SDK. Upon completion of the Lambda function, our driver will be notified. In this example, it is just sent via email.

Here's the message to show that it was sent. What happens if we need to debug something that is not working as expected, or figure out why a Lambda function is failing.

About the Author

Kevin is a seasoned technologist with 15+ years experience mostly in software development.Recently, he has led several migrations from traditional data centers to AWS resulting in over $100K a year in savings. His new projects take advantage of cloud computing from the start which enables a faster time to market.

He enjoys sharing his experience and knowledge with others while constantly learning new things. He has been building elegant, high-performing software across many industries since high school. He currently writes apps in node.js and iOS apps in Objective C and designs complex architectures for AWS deployments.

Kevin currently serves as Chief Technology Officer for, where he leads a small, agile team.