Book Image

Mastering AWS Lambda

By : Yohan Wadia, Udita Gupta
Book Image

Mastering AWS Lambda

By: Yohan Wadia, Udita Gupta

Overview of this book

AWS is recognized as one of the biggest market leaders for cloud computing and why not? It has evolved a lot since the time it started out by providing just basic services such as EC2 and S3 and today; they go all the way from IoT to Machine Learning, Image recognition, Chatbot Frameworks, and much more! One of those recent services that is also gaining a lot of traction is AWS Lambda! Although seemingly simple and easy to use, Lambda is a highly effective and scalable compute service that provides developers with a powerful platform to design and develop Serverless event-driven systems and applications. The book begins with a high-level introduction into the world of Serverless computing and its advantages and use cases, followed by a deep dive into AWS Lambda! You’ll learn what services AWS Lambda provides to developers; how to design, write, and test Lambda functions; as well as monitor and troubleshoot them. The book is designed and accompanied with a vast variety of real-world examples, use cases, and code samples that will enable you to get started on your Serverless applications quickly. By the end of the book, you will have gained all the skills required to work with AWS Lambda services!
Table of Contents (11 chapters)

Introducing AWS Lambda

So, here we are, finally to the fun part! In this section, we will learn what Lambda is actually all about, what some of its salient features are, how it works and some steps on getting started with your very first Lambda invocation.

AWS Lambda was first introduced way back in 2014, at the yearly AWS re:Invent conference in Las Vegas. The idea back then, and which pretty much holds true even today, is that Lambda is a simple compute service that runs your code in response to certain events. These events can be anything, from an upload operation of an object to an S3 bucket, a record insertion in a DynamoDB table, or even some form of event triggered from your mobile app. The idea here is simple--you simply provide your code to AWS Lambda. Lambda will internally take care of provisioning and managing the underlying infrastructure resources, making sure your code gets deployed successfully; even things like your code's scalability and high availability are taken care of by Lambda itself! Now, that's neat!


Lambda was specially introduced by AWS to answer a very particular issue with EC2. Although EC2 still remains one of the most widely used core AWS services, it's still not designed to handle or respond to events; something that is required more often than not in today's applications. For example, a simple image upload activity to an S3 bucket triggers some form of operation, such as checking whether the object is actually a valid image, or whether it contains any viruses or unwanted malware. You can even have a requirement to create thumbnails of the uploaded image and put that up on your website. Now, imagine an EC2 instance doing all these activities for you. Firstly, you would have to program some mechanism for S3 to notify your EC2 instances to periodically perform checks on your S3 bucket, as EC2 has no way of telling when a new object has been uploaded.

Then again, you would have to manage the EC2 instance and handle all failovers, such as what happens if the EC2 instance fails to poll the S3 bucket, or what happens if the EC2 instance gets terminated for some reason. There's also the issue of scalability, right? Today you may be uploading just about 30-40 odd images, enough for a single EC2 instance to work on; but what happens when there is a large surge of upload operations? Will your EC2 instances scale effectively? And most important of all and by far the biggest issue for most enterprises--cost. Your EC2 instance will be running even on those days when there are no upload operations occurring in your S3 bucket. Sure there are many ways in which we can create workarounds for this, such as by creating a separate instance that polls continuously and by leveraging SQS or SNS as well, but isn't all that really overkill for something so simple? That's exactly the reason why Lambda is so popular and so widely used today. It just makes things simple!

How it works

Well, we do know for sure that Lambda powers your code on some form of container technology which explains how AWS is able to get it to spin up so quickly as compared to running your code on standard EC2 instances. These containers are spun up on underlying EC2 instances that are all created from a common image (Amazon Linux AMI: amzn-ami-hvm-2016.03.3.x86_64-gp2). Once again, we cannot control or see these containers or EC2 instances; they are managed by AWS itself.

There is a short latency between the time a Lambda function is invoked. This is primarily because AWS has to bootstrap the container that runs your code and provides the necessary resources for it to run as well. This latency is generally observed when the function is either invoked for the first time or when it is updated.

At the heart of the container is your code, which, as a rule of thumb, has to be written specifically to perform a single task or a few simple processes; similar to how you would write functions in your normal code. Each Lambda project that you deploy can thus be termed as a Lambda function, or just a function. At the time of writing this book, AWS supports Java, Python, Node.js, and even C# as programming languages for your functions. Each function can be invoked either on demand or invoked dynamically based on certain types of supported events. A few event examples are listed out as follows:

  • Amazon S3: Lambda functions can be triggered when an object is created, updated, or deleted in an S3 bucket
  • Amazon DynamoDB: Lambda functions are triggered when any updates are made to a particular DynamoDB table, such as row insertion, deletion, and so on
  • Amazon Simple Notification Service (SNS): Trigger a Lambda function when a message is published on a, SNS topic
  • Amazon CloudWatch Logs: Use Lambda functions to process CloudWatch Logs as feeds
  • Scheduled events: Run Lambda functions as scheduled events, just like a cron job
  • AWS CodeCommit: Execute Lambda functions whenever new code is pushed to an existing branch, and so on
For a complete list of the latest AWS services that are supported as Lambda invokers, refer to

When creating Lambda functions, you have to specify the amount of memory resource your function will require, as well as the approximate time it will take to execute before timing out. The memory can be set from 128 MB to 1.5 GB of RAM and the timeouts anywhere from one second to a max of 300 seconds. Both the memory and duration values are upper limits to your Lambda function, which means that if you have allocated 512 MB of RAM to your function, it doesn't mean the function will have to use all 512 MB, of it. It can work at any value up to 512 MB post which Lambda will simply throw you an error message stating that your function ran out of memory. The same applies for the duration of your function as well. You may set your function to timeout after 60 seconds and the function may only run for, say, 10 seconds. However, if your function fails to complete its processing by the 60th second, Lambda once again will time it out and pop you up an error message.

It is important to note, however, that varying the amount of memory for your function or the duration of the timeout also impacts the cost of your Lambda function. We will have a look at Lambda's pricing and limitations a bit later on in this chapter. For now, let us learn a bit more on how to actually get started with deploying Lambda functions using the AWS Management Console, as well as the AWS CLI.