Lambda supports triggers from almost any AWS service, including, but not limited to, the following:

• Amazon S3
• Amazon Kinesis
• Amazon SNS, SQS, and SES
• Amazon Cognito
• AWS CloudFormation and AWS Config
• Amazon CloudWatch Logs and Events (supports scheduled events)
• Amazon API Gateway (including custom invocations through HTTP links)
• AWS CodeCommit, CodeBuild, IoT Button, Alexa, Lex, CloudFront, and so on

There are two types of invocations supported for the Lambda service:

• Push: An event in an AWS service or a custom event can invoke the lambda function
• Pull: The Lambda service polls an AWS services stream or queue and retrieves tasks

An example of a push-based Lambda invocation would be an image-processing app. The users would upload files to an S3 bucket, and the event of the S3 file being uploaded can trigger a Lambda function. That Lambda function can then pick up an image, extract the metadata from the image, and output the information (such as size, type of image, date, and S3 location) to a DynamoDB table. In this case, we need to also provide the appropriate invocation permissions to the S3 bucket to be able to invoke the Lambda, and of course provide Lambda with the appropriate role with permissions to write to DynamoDB.

An example of a pull-based Lambda invocation would be the second part of the same image processing app. Once the first Lambda function records the metadata in the DynamoDB table, a second Lambda function that listens to the DynamoDB stream will pick up the changes and create a static website file in S3 with the information from the DynamoDB table, so that the image will be served on the static website. In the pull scenario, we need to allow the lambda to read the DynamoDB stream by providing permission in the Lambda execution role.