I love AWS Lambda because I can run my code on Amazon's servers without having to manage servers, operating systems, scaling, provisioning, or even deployment.

HOW IT WORKS

If you visit the Lambda Console on AWS and create a new function, you will see something like this.

exports.handler = (event, context, callback) => {
    var key1 = (event.key1 === undefined ? "Default Key 1" : event.key1)
    var key2 = (event.key2 === undefined ? "Default Key 2" : event.key2)

    // TODO implement
    callback(null, 'Hello from Lambda ' + key1 + " " + key2);
};

Every lambda function has two attributes: event and context.

Event

The event parameter will contain any object we pass into our function.

Context

The context object allows you to specify when the function (or any callbacks) have completed execution.

Context offers a few extra methods you can use to manage your function.

The method or callback succeeded.

context.succeed();

If the method or callback fails.

context.fail();

Done combines both succeed and fail with error as the first parameter.

context.done(null, { "response": xyz });

Callback

If you want to return information back to the call, you can include the optional callback.

Source

MANAGING SECURITY

Everything in Amazon Web Services revolves around users, groups, roles and policies. Lambda is no different. There are two core security permissions you must manage when working with lambda.

Execution permissions

Execution permissions define what your lambda function can do.

Execution permissions are required by Lambda to interact with other AWS resources (such as S3 or DynamoDB).

Invocation permissions

Invocation permissions define who can ask your lambda function to execute.

Invocation permissions are required by the event source to trigger your Lambda function. For example, maybe there's an event that occurs within your S3 bucket that triggers your lambda function.

Policy Files

As I mentioned above, execution permissions and invocation permissions help you define what your lambda function will do and who can ask it to do it. You can set those permissions using policy files.

The examples below show you how to create policy files that will enable you to write logs to CloudWatch.

Execution Policy

This execution policy will create a log group, create a log stream and put log events inside of CloudWatch.

{
  "Version": "2012-10-17",
  "Statement": [
    "Effect": "Allow",
    "Action": [
      "logs:CreateLogGroup",
      "logs:CreateLogStream",
      "logs:PutLogEvents"
    ],
    "Resource": "arn:aws:logs:*:*:*"
  ]
}

Invocation Policy

This invocation policy will allow Lambda to invoke a function. The invocation is restricted to a "SourceArn" within the API gateway ("Principal"). The policy also restricts the source account to "account-id".

{
  "StatementId": "Id-1",
  "Action": "lambda:InvokeFunction",
  "Principal": "apigateway.amazonaws.com",
  "SourceArn": "arn:aws:execute-api:api_specific_resource_path",
  "SourceAccount": "account-id"
}

More