Welcome to the CloudAcademy course on AWS Lambda. Lambda was introduced at the 2014 re:Invent Conference, and made available in preview mode to customers upon request. This course with detail what Lambda is, when it makes sense to use it, how we can use it, and metrics around monitoring our functions. What exactly is Lambda? Simply put, Lambda is a compute service that executes code. Instead of needing to provision an EC2 instance and getting it configured to run a few functions, we can upload just the code we want to execute. We can tie the execution to various Events, such as S3 file creation and Kinesis streams. At the time of this recording, the service is still in preview mode, meaning it has limitations.

For example, it only supports Node.js, it only responds to a few Events. Knowing how quickly AWS rolls out functionality, we can expect newer languages and more Events in the future. There are many reasons to consider using Lambda: it is very easy to deploy and administer functions, we don't have to worry about selecting and configuring the proper EC2 instances to run our code. Lambda helps us achieve scalable, high-available workloads right out of the box. As with all AWS services, security is a shared responsibility. AWS does its part to ensure our code runs in its own sandbox, away from all other processes. We are responsible for protecting our keys that interact through the AWS STK. Best of all, Lambda helps keep costs down by charging us only for the execution of our workloads, and not for idle resources like we do when using EC2. Like most services, AWS has a free tier for Lambda that is applied to both new and existing accounts. The free tier covers the first million requests, and up to 3.2 million seconds per month. That is a lot of processing that can be done before we get charged anything.

The number of seconds per month is dependent on the amount of memory we allocate for our code to run. 3.2 million is on the high end, using the lowest memory setting of 128MB. At the max memory of 1GB, the free tier allows 400,000 seconds per month before charging us. Once we exceed the first million requests, we are charged $0.20 for each additional batch of 1,000,000 requests. If we exceed our execution time, we are charged per 100 milliseconds of execution, with the amount determined, again, by the memory allocation for our function. These are charged at fractions of fractions of pennies per 100 milliseconds, very compelling pricing for many workloads.

Lambda is not designed for all workloads, some are better suited than others. Code that does not require human interaction is a prime example. That does not mean we cannot use it as part of a larger system.

This is something we will demonstrate in lesson three with our sample application. Functions should be independent of other functions, meaning we don't want to have it sitting around waiting for other functions to complete. That will waste execution time, and most likely exceed mandatory time-out settings. Our functions cannot be dependent on the underlying physical resources, as there's no guarantee it will be consistent across all executions. That means we cannot rely on state between executions, unless we are storing that state with other services such as DynamoDB or S3. Lambda also makes sense when we have no desire to manage compute resources. Now that we understand what Lambda is, let's turn our attention to how Lambda works.