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.

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

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.