The following macros are not currently supported in the header:
  • unmigrated-wiki-markup

Documentation for Tasks for AWS 2.10 – other releases are available in the Tasks for AWS Documentation Directory.
View

Unknown macro: {spacejump}

or visit the current documentation home.

Deploying to AWS Lambda

Owned by Steffen Opel [Utoolity]
Last updated: 27.10.2015Version comment

Components

The deployment of code to AWS Lambda involves several major components as follows:

  • Function – the custom code that processes events from an event source (see below) custom code in AWS Lambda is referred to as a Lambda function, which consists of code, associated dependencies, and configuration, see Lambda Function and Event Source
  • Event Source – publishes events that cause a Lambda function to be invoked, either by the event source in the "push" model, or by AWS Lambda in the "pull" model, see The Pull/Push Event Models

On this page:

Related Pages:

Workflow

The typical deployment workflow comprises one mandatory and two optional phases:

Create an AWS Lambda function

  1. upload the application source code (the 'Deployment Package') – see the Upload File(s) action of the Amazon S3 Object task
  2. create a function – see the Create Function action of the AWS Lambda Function task

  3. (optional) invoke the function – see the Invoke Function action of the AWS Lambda Function task

    Custom Bamboo task

    This effectively comprises a custom Bamboo task, which allows you to implement arbitrary functionality running in AWS Lambda instead of a dedicated task.

(Optional) Create an AWS Lambda Event Source Mapping (pull event model)

  1. (optional) create an appropriate event source via AWS CloudFormation, e.g. an Amazon Kinesis stream or an Amazon DynamoDB table – see the Create Stack action of the AWS CloudFormation Stack task

  2. create an event source mapping – see the Create Event Source Mapping action of the AWS Lambda Event Source Mapping task

    Disable until tested

    Kinesis and DynamoDB streams can create a huge amount of events in a short time, so you might want to create an event source mapping in the Disabled state and update it to Enabled explicitly at a later stage once the deployment is properly tested.
  3. (optional) update an event source mapping – see the Update Event Source Mapping action of the AWS Lambda Event Source Mapping task
    • the event source mapping can be adjusted at any time during its lifetime, for example to enable/disable it during maintenance

Illustration of the Lambda pull event model

(Optional) Add/Permit an AWS Lambda Event Source (push event model)

  1. (optional) create an appropriate event source via AWS CloudFormation, e.g. an Amazon S3 bucket or an Amazon SNS topic – see the Create Stack action of the AWS CloudFormation Stack task

  2. add appropriate permissions for the AWS resource to invoke the function – see the Add Permission action of the AWS Lambda Function task

  3. update the event source with an appropriate notification for the function, e.g. an Amazon SNS topic subscription – see the Update Stack action of the AWS CloudFormation Stack task

Illustration of the Lambda push event model

Illustration of the Lambda push event model

Alternative workflow via CloudFormation

As an alternative to using the AWS Lambda tasks built into Tasks for AWS, it is also possible to provision the Lambda components directly via the AWS CloudFormation Stack task and the corresponding CloudFormation resource types:

A typical workflow based on CloudFormation might look as follows:

  1. upload the application source code (the 'Deployment Package') – see the Upload File(s) action of the Amazon S3 Object task
  2. create/update the CloudFormation stack that provisions the Lambda function and optionally the associated permissions and/or event source mappings – see the Create Stack action of the AWS CloudFormation Stack task
    1. (lightbulb) You can use the Update stack, if it already exists option to reuse the same Bamboo job for both actions

Frequently Asked Questions (FAQ)