Lambda Deployments

Updated 3 days ago by Michael Cretzman

Harness has first class support for AWS Lambda deployments, enabling you to deploy your functions without having to worry about compute constraints or complexity. Setting up a Lambda deployment is as simple as adding your function zip file, configuring function compute settings, and adding aliases and tags. Harness takes care of the rest of the deployment, making it consistent, reusable, and safe with automatic rollback.

This guide contains the following sections:

Deployment Summary

For a general overview of how Harness works, see Harness Architecture and Application Components.

Basically, the Harness setup for Lambda is akin to using the AWS CLI aws lambda create-function, update-function-code, and update-function-configuration commands, as well as the many other commands that are needed.

The benefit with Harness is that you can set your Lambda deployment up once with no scripting and then have your Lambda functions deployed automatically as they are updated in your AWS S3 bucket. You can even templatize the deployment Environment and Workflow for use by other devops and developers in your team.

Furthermore, Harness manages Lambda function versioning to perform rollback when needed.

The following list describes the major steps we will cover in this guide:

  1. Delegate - Install the Harness Shell Script or ECS Delegate in your AWS VPC.
  2. AWS Cloud Provider - Add the AWS Cloud Provider. This is a connection to your AWS account. The AWS Cloud Provider can use your user account or the IAM role assigned to the Delegate host.
    The AWS Cloud Provider is used to connect Harness to your Lambda deployment environment and to Amazon S3 to obtain your Lambda code files. You can also use a Custom Artifact Repository, as described in Custom Artifact Source.
  3. Harness Application - Create the Harness Application for your Lambda CD pipeline. The Harness Application represents your Lambda code and functional spec, their deployment pipelines, and all the building blocks for those pipelines. Harness represents your Lambda deployment using a logical group of one or more entities: Services, Environments, Workflows, Pipelines, Triggers, and Infrastructure Provisioners. Applications organize all of the entities and configurations in Harness CD.
  4. Harness Service - Create the Harness Service using the Lambda type.
    1. Set up your Lambda code artifact source, Lambda Function Specification, and any config variables and files.
  5. Harness Environment - Create the Harness Environment containing the Service Infrastructure definition of your AWS deployment environment, and any overrides of Service settings.
  6. Harness Workflow - Create the Basic deployment Harness Workflow. This Workflow will deploy the Service (your Lambda code) to the Environment (your AWS Lambda functions for the region).
    You can also add your Lambda Aliases and Tags as part of the Workflow.
  7. Deploy the Workflow.
  8. Advanced options not covered in this guide:
    1. Harness Pipeline - Create a Harness Pipeline for your deployment, including Workflows and Approval steps. Typically, Harness customers will deploy Lambda Pipelines with a Workflow for Dev, QA, Stage, etc:
      This example doesn't show Approval steps between Pipeline stages, which are also common. For more information, see Pipelines.
    2. Harness Trigger - Create a Harness Trigger to automatically deploy your Workflows or Pipeline according to your criteria. Typically, customers use a Trigger to execute a Lambda Pipeline using the Trigger's On New Artifact condition. Each time the Lambda artifact, such as a zip file, is updated in the artifact repository (AWS S3), the Pipeline is executed and the new Lambda function is deployed.
      For more information, see Triggers.
    3. Harness Infrastructure Provisioners - Create Harness Infrastructure Provisioners, such as CloudFormation and Terraform, for your deployment environments. For more information, see Infrastructure Provisioners.
    4. Continuous Verification:
      1. Deployment Verification - Once you have successfully deployed you can add your APM and logging apps as Verification Providers, and then add Verify Steps to your Workflows. Harness will use its machine-learning to find anomalies in your deployments. For more information, see Continuous Verification.
      2. 24/7 Service Guard - Monitor your live applications, catching problems that surface minutes or hours following deployment. For more information, see 24/7 Service Guard.
Harness fully-integrates with AWS CloudWatch to apply Harness machine learning to CloudWatches monitoring and operational data. See CloudWatch Verification.

What Are We Going to Do?

This guide walks you through deploying a Lambda function to AWS Lambda using Harness. Basically, the Harness deployment does the following:

  1. Lambda function setup - Pull a zip file from AWS S3 and define the function-level settings, such as the function runtime, memory size, and handler.
  2. VPC settings - Define the VPC settings for the Lambda deployment.
  3. Versioning and tags - Add any aliases and tags to the Lambda function.
  4. Deploy - Deploy the Lambda function to an AWS VPC.

What Are We Not Going to Do?

This is a simple guide that covers the basics of deploying Lambda functions to AWS. It does not cover the following:

  • Teaching AWS Lambda.
  • Using all the Lambda runtimes. We will be using a Node.js example. The steps are the same for all the Lambda runtimes.

Before You Begin

The following are required:

  • AWS account - An AWS account you can connect to Harness.
  • Harness Delegate - A Harness Shell Script or ECS Delegate installed in your AWS VPC that can connect to your S3 bucket and Lambda.

We will walk you through the process of setting up Harness with a connection to AWS, and the Harness Delegate installation is summarized also.

Delegate Setup

The Harness Delegate runs in your AWS VPC and executes all deployment steps, such the artifact collection and commands. The Delegate makes outbound HTTPS connections to the Harness Manager only.

The simplest method is to install a Harness Shell Script or ECS Delegate in same AWS VPC as your Lambda functions and then set up the Harness AWS Cloud Provider to use the same IAM credentials as the installed Delegate. This is described in Add the Cloud Provider below.

For steps on installing a Delegate in your VPC, see Delegate Installation and Management.

IAM Roles

The AWS IAM Policy Simulator is a useful tool for evaluating policies and access.
IAM Read Access

Ensure that the IAM role assigned to the Delegate host has the IAMReadOnlyAccess (arn:aws:iam::aws:policy/IAMReadOnlyAccess) policy attached. The policy provides read-only access to IAM for the Delegate so that it can confirm that it has other required policies.

Amazon S3

The Lambda function metadata is pulled from an AWS S3 bucket and therefore the Delegate needs the AmazonS3ReadOnlyAccess (arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess) policy.

EC2 and ECS

The Delegate might be a Shell Script Delegate installed on an EC2 instance or an ECS Delegate installed on an ECS cluster. The required policies for the Delegate are described here:

AWS Lambda Policies

For the Delegate to perform operations with Lambda, it requires an IAM role with the following policies:

  • AWSLambdaFullAccess (arn:aws:iam::aws:policy/AWSLambdaFullAccess)
  • AWSLambdaRole (arn:aws:iam::aws:policy/service-role/AWSLambdaRole)

The IAM role attached to your EC2 Delegate host must have the AWSLambdaRole (arn:aws:iam::aws:policy/service-role/AWSLambdaRole) policy attached. The policy contains the lambda:InvokeFunction needed for Lambda deployments:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lambda:InvokeFunction"
],
"Resource": [
"*"
]
}
]
}

Attach the AWSLambdaRole (arn:aws:iam::aws:policy/service-role/AWSLambdaRole) policy to the IAM role for the Delegate host in EC2 or ECS.

For more information, see Identity-based IAM Policies for AWS Lambda from AWS.

Summary

If the IAM role assigned to the Delegate has the following roles you will encounter no related issues:

  • Shell Script Delegate on EC2 instance policies or ECS Delegate policies
  • IAMReadOnlyAccess
  • AWSLambdaRole
  • AWSLambdaFullAccess

Delegate Tag

To ensure the IAM role applied to the Delegate you installed in the AWS VPC is used by your AWS Cloud Provider, you add Tags to the Delegate and reference the Tag in the AWS Cloud Provider.

For steps on adding Tags, see Delegate Tags. Here is an example of a Tag added a Shell Script Delegate running on an EC2 instance:

Connectors and Providers Setup

In this section, we will add a Harness AWS Cloud Provider to your Harness account to connect to both AWS S3, Lambda, and the VPC. You can use a single or separate AWS Cloud Providers for the connections, but using a single AWS Cloud Provider is easiest.

As Harness provides first-class support for CloudWatch, you can also use the same AWS Cloud Provider for your CloudWatch connection.

Permissions

The AWS Cloud Provider in this example will assume the IAM Role associated with the Delegate you installed in your VPC. If you choose to use a AWS user account for the connection, apply the same policies to its IAM role described in IAM Roles above.

Add the Cloud Provider

For the AWS Cloud Provider in Harness, you can specify an AWS account or assume the IAM role used by the installed Harness Delegate (recommended).

AWS Cloud Provider

To set up an AWS Cloud Provider, do the following:

  1. In the Harness Manager, click Setup, and then click Cloud Providers.
  2. Click Add Cloud Provider. The Cloud Provider dialog appears.
  3. In Type, select Amazon Web Services.
  4. In Display Name, enter the name that you will use to refer to this Cloud Provider when setting up your Harness Application, such as AWS Cloud. You will use the name when setting up Harness Environments, Service Infrastructures, and other settings.
  5. In Credentials, select Assume IAM Role on Delegate (recommended) or Enter AWS Access Keys manually. If you selected Enter AWS Access Keys manually, enter your username and password.

    If you selected Assume IAM Role on Delegate, in Delegate Tag, select the Tag that you added to the Delegate installed in your VPC.

Harness Application Setup

The following procedure creates a Harness Application for a Lambda deployment.

An Application in Harness represents a logical group of one or more entities, including Services, Environments, Workflows, Pipelines, Triggers, and Infrastructure Provisioners. Applications organize all of the entities and configurations in Harness CI/CD. For more information, see Application Components.

To create the Harness Application, do the following:

  1. In Harness, click Setup.
  2. Click Add Application. The Application dialog appears.
  3. Give your Application a name that describes your microservice or app. For the purposes of this guide, we use the name ExampleApp.
  4. Click SUBMIT. The new Application is added.
  5. Click the Application name to open the Application. The Application entities are displayed.

Lambda Services

There are different types of Harness Services for different deployment platforms. The Lambda type includes Lambda-specific settings, including your function file and runtime and handler information.

To add the Lambda Service, do the following:

  1. In your new Application, click Services. The Services page appears.
  2. In the Services page, click Add Service. The Service dialog appears.
  3. In Name, enter a name for your Service, such as aws-lambda. You will use this name to select this Service when you set up a Harness Environment and Workflow.
  4. In Description, enter a description for your Service.
  5. In Artifact Type, select AWS Lambda.
  6. Click SUBMIT. The new Service is displayed.

Next, we will walk through how to set up the Lambda Function Specification and use the Service features.

Add Lambda Function File

An Artifact Source in a Lambda Service is the Lambda function file you want to deploy. The Artifact Source uses the AWS Cloud Provider you set up for your Harness account, as described in Connectors and Providers Setup.

To add an Artifact Source to this Service, do the following:

  1. In your Lambda Service, click Add Artifact Source, and then click Amazon S3. For information on using a Custom Artifact Source, see Custom Artifact Source. The Amazon S3 Artifact Source dialog appears.
  2. In Cloud Provider, select the AWS Cloud Provider you set up in Connectors and Providers Setup.
  3. In Bucket, select the S3 bucket containing the Lambda function zip file you want.
  4. In Artifact Path, select the Lambda function zip file containing your functions. Here is how your S3 bucket and file relate to the Artifact Source dialog:

The Meta-data Only option is selected by default. Harness will not copy the actual zip file. During runtime, Harness passes the metadata to Lambda where it is used to obtain the file.

  1. Click SUBMIT. The Lambda function file is added as an Artifact Source.

Lambda Function Specification

In Lambda Function Specification, you provide details about the Lambda functions in the zip file in Artifact Source.

Click Lambda Function Specification. The AWS Lambda Function Specifications dialog appears.

The details you provide are very similar to the options in the AWS CLI aws lambda create-function command. For more information, see create-function from AWS.

Some of the options are specified in Harness Environments and Workflows to help you reuse the Service with multiple Environments and Workflows.

By default, the AWS Lambda Function Specifications dialog displays a function. If you have multiple Lambda functions in the zip file in Artifact Source, click Add Function and provide details for each function.

For each function in the Functions section, enter the following function information:

  • Runtime - The Lambda runtime that executes your function. This is the runtime for all functions in this spec. AWS can change its runtime version support. For example, AWS no longer supports nodejs6.10.
  • Function Name - The name of your function. This name will become part of the function ARN in Lambda.
    Harness uses default variables for the name that include your Harness Application, Service, and Environment names (${app.name}_${service.name}_${env.name}). If you use these, you need to append a unique suffix to each function name, for example ${app.name}_${service.name}_${env.name}_my-function. Or you can replace the entire name.
  • Handler - The method that the runtime executes when your function is invoked. The format for this value varies per language. See Programming Model for more information.

For example, let's look at a Node.js function in a file named index.js:

exports.handler =  async function(event, context) {
console.log("EVENT: \n" + JSON.stringify(event, null, 2))
return context.logStreamName
}

The value of the Handler setting is the file name (index) and the name of the exported handler module, separated by a dot. In our example, the handler is index.handler. This indicates the handler module that's exported by index.js.

  • Memory Size - The amount of memory available to the function during execution. Choose an amount between 128 MB and 3,008 MB in 64 MB increments. There are two Execution Timeout settings. A default setting and a function-specific setting.
  • Execution Timeout - The amount of time that Lambda allows a function to run before stopping it. The default is 3 seconds. The maximum allowed value is 900 seconds. There are two Execution Timeout settings. A default setting and a function-specific setting.

When you are done, the AWS Lambda Function Specifications dialog will look something like this:

When you are done, click SUBMIT. You function is added to the Service.

Config Variables and Files

Config variables and files are available in all Harness Service types. For more information, see Configuration Variables and Files.

Lambda Environments

Once you've added a Lambda Service to your Application, you can define Environments where your Service can be deployed. In an Environment, you specify the following in the Service Infrastructure of an Environment:

An Environment can be a Dev, QA, Production, or other Environment. You can deploy one or many Services to each Environment by creating a Service Infrastructure in the Environment for each Service.

Create a New Harness Environment

The following procedure creates an Environment for the Lambda Service type set up in Lambda Services.

  1. In your Harness Application, click Environments. The Environments page appears.
  2. Click Add Environment. The Environment dialog appears.
  3. In Name, enter a name that describes the deployment environment, for example, Lambda.
  4. In Environment Type, select Non-Production.
  5. Click SUBMIT. The new Environment page appears.

Add a Service Infrastructure

You define the AWS VPC, subnets, and security groups to use for the Lambda deployment as a Service Infrastructure.

To add a service infrastructure, do the following:

  1. In the Harness Environment, click Add Service Infrastructure. The Service Infrastructure dialog appears.
  2. In Service, select the Harness Lambda Service you created in Lambda Services.
  3. In Cloud Provider, select the AWS Cloud Provider you added in Connectors and Providers Setup. The dialog will look something like this:

  1. Click Next. The Configuration section appears.
    The Configuration settings are similar to the --role and --vpc-config options in the aws lambda create-function command. For example:
$ aws lambda create-function --function-name ExampleApp-aws-lambda-Lambda-my-function \
--runtime nodejs8.10 --handler index.handler --zip-file lambda/function.zip \
--role execution-role-arn \
--vpc-config SubnetIds=comma-separated-vpc-subnet-ids,SecurityGroupIds=comma-separated-security-group-ids
  1. Configure the following settings:
    1. Already Provisioned/Dynamically Provisioned - If you have a Harness Infrastructure Provisioner configured, select Dynamically Provisioned, and select the provisioner. For more information, see Infrastructure Provisioners Overview. The setting below are for Already Provisioned.
    2. IAM Role - The IAM role that AWS Lambda assumes when it executes your function.
    3. Region - The AWS region where your function will be used.
    4. VPC - The VPC the function will connect to in your account. You connect your function to the VPC to access private resources during execution. Lambda runs your function code securely within a VPC by default. However, to enable your Lambda function to access resources inside your private VPC, you must provide additional VPC-specific configuration information that includes private subnet IDs and security group IDs. AWS Lambda uses this information to set up elastic network interfaces (ENIs) that enable your function to connect securely to other resources within your private VPC. For more information and guidelines, see Configuring a Lambda Function to Access Resources in an Amazon VPC from AWS.
    5. Subnets - The subnet IDs for the subnets in the VPC where the Lambda function will access resources. AWS recommends that you choose at least 2 subnets for Lambda to run your functions in high availability mode.
    6. Security Groups - The security group ID(s) for the Lambda function. When you set a VPC for your function to access, your Lambda function loses default Internet access. If you require external Internet access for your function, make sure that your security group allows outbound connections and that your VPC has a NAT gateway.
  2. When you are done, the dialog will look something like this:
  3. Click SUBMIT. The new Service Infrastructure is added to the Harness environment.

That is all you have to do to set up the deployment Environment in Harness. Now you can create the deployment Workflow in Harness.

Override Service Settings

Your Service Infrastructure can overwrite Service Config Variables, Config Files, and other settings. This enables you to have a Service keep its settings but have them changed when used with this Environment.

For more information, see Override a Service Configuration.

Lambda Workflows and Deployments

This section will walk through creating a Basic Workflow for Lambda and describe what the Workflow steps include.

By default, Harness Basic Workflows for Lambda have two steps:

  • AWS Lambda - This step deploys the function and also sets the Lambda aliases and tags for the function.
  • Rollback AWS Lambda - If a deployment fails, this step uses aliases to roll back to the last successful version of a Lambda function.

To create a Basic Workflow for Lambda, do the following:

  1. In your Application, click Workflows.
  2. Click Add Workflow. The Workflow dialog appears.
  3. In Name, enter a name for your Workflow, such as Lambda Basic.
  4. In Workflow Type, select Basic Deployment.
  5. In Environment, select the Environment you created for your Lambda deployment in Lambda Environments.
  6. In Service, select the Lambda Service you created in Lambda Services.
  7. In Service Infrastructure, select the Service Infrastructure you defined in Lambda Environments.
  8. Click SUBMIT. The new Basic Workflow is created and pre-configured with the AWS Lambda step.

Next, let's look at the pre-configured AWS Lambda step.

AWS Lambda Step

When you deploy the Workflow, the AWS Lambda step creates the Lambda functions defined in the Service you attached to the Workflow. This is the equivalent of the aws lambda create-function API command.

The next time you run the Workflow, manually or as the result of a Trigger, the AWS Lambda step updates the Lambda functions. This is the equivalent of the aws lambda update-function-configuration API command.

In the Workflow, click the AWS Lambda step. The AWS Lambda dialog appears.

The dialog provides settings for Lambda Aliases and Tags.

Versioning with Aliases
This guide assumes you are familiar with Lambda versioning.

Published Lambda functions are immutable objects (they cannot be changed), and are versioned with the latest always being published to $LATEST. These versions are made up of both code as well as configuration settings. Once the code and configuration are published, the function becomes immutable.

Continuous delivery on Lambda requires that Harness manage the versioning (via aliases) and rollbacks. Since each new version is immutably pushed to $LATEST, rolling back to a previous version becomes complicated.

Harness solves the complexity by keeping track of the aliases required to recreate the function, the code, and the configuration. An alias is a pointer to one or two versions.

Harness handles the burden of managing the code and configuration in order to properly version, tag, or recreate the previous version, thus allowing for fully-automated rollbacks based on prescriptive failure strategies.

The AWS Lambda step in the Workflow applies the alias just like you would using the AWS Lambda console:

By default, Harness names the alias with the name of the Environment by using the built-in Harness variable ${env.name}. You can replace this with whatever alias you want, or use other built-in Harness variables by entering $ and seeing what variables are available.

Once the Workflow is deployed and a Lambda function has been versioned using the alias in the AWS Lambda step, you can see the versioning in the AWS Lambda console:

Tags

Tags are key-value pairs that you attach to AWS resources to organize them. For Lambda functions, tags simplify the process of tracking the frequency and cost of each function invocation.

You can set the tags for your Lambda functions in the AWS Lambda step and, once deployed, you can see the tags in the AWS Lambda console:

Rollback AWS Lambda Step

In the Basic Workflow you can see the Rollback AWS Lambda step.

This step initiates rollback if the AWS Lambda step fails, or if a step elsewhere in the Workflow fails.

The best way to see what the Rollback AWS Lambda step does is to look at a log for a rollback.

In the following scenario, the previous, successful version of the function was version 2. When Harness fails to publish version 3 (we added an HTTP call that intentionally failed), it publishes the previous version as a new version and names it version 4. Version 3 is never deployed.

First, Harness gets the function configuration and VPC settings from the last successful version:

Begin command execution.
Deploying Lambda with following configuration
Function Name: ExampleApp-aws-lambda-Lambda-my-function
S3 Bucket: harness-example
Bucket Key: lambda/function.zip
Function handler: index.handler
Function runtime: nodejs8.10
Function memory: 128
Function execution timeout: 3
IAM role ARN: arn:aws:iam::00000000000:role/service-role/TestAwsLamdaRole
VPC: vpc-00a7e8ea4fd1ffd9d
Subnet: [subnet-0c945c814c09c9aed, subnet-05788710b1b06b6b1]
Security Groups: sg-05e7b8b9cad94b393

Next, Harness updates and publishes the previous version as version 4:

Function: [ExampleApp-aws-lambda-Lambda-my-function] exists. Update and Publish

Existing Lambda Function Code Sha256: [U+zi3X2Fu+ojXZzd58XXXXXXXXXXB05evN2U=].

New Lambda function code Sha256: [U+zi3X2Fu+ojXZzd58MIKDKXXXXXXXXXXAB05evN2U=]

Function code didn't change. Skip function code update

Updating function configuration

Function configuration updated successfully

Publishing new version

Published new version: [4]

Published function ARN: [arn:aws:lambda:us-east-1:00000000000:function:ExampleApp-aws-lambda-Lambda-my-function:4]

Untagging existing tags from the function: [arn:aws:lambda:us-east-1:00000000000:function:ExampleApp-aws-lambda-Lambda-my-function]

Executing tagging for function: [arn:aws:lambda:us-east-1:00000000000:function:ExampleApp-aws-lambda-Lambda-my-function]

Successfully deployed lambda function: [ExampleApp-aws-lambda-Lambda-my-function]

=================
Successfully completed AWS Lambda Deploy step

As you can see, the rollback succeeded and version 4 is published.

Lambda Workflow Deployment

Now that the Basic Workflow for Lambda is set up, you can click Deploy in the Workflow to deploy the Lambda functions in the Harness Service to your AWS Lambda environment.

In Start New Deployment, in Build / Version, select the zip file in the S3 bucket you set up as an Artifact Source for your Harness Lambda Service:

Click SUBMIT. The Workflow is deployed.

To see the completed deployment, log into your AWS Lambda console. The Lambda function is listed:

You can also log into AWS and use the aws lambda get-function command to view the function:

$ aws lambda get-function --function-name ExampleApp-aws-lambda-Lambda-my-function
{
"Code": {
"RepositoryType": "S3",
"Location": "https://prod-04-2014-tasks.s3.amazonaws.com/snapshots/..."
},
"Configuration": {
"TracingConfig": {
"Mode": "PassThrough"
},
"Version": "$LATEST",
"CodeSha256": "U+zi3X2Fu+ojXZzd58MIKDK56UaVASDA0KAB05evN2U=",
"FunctionName": "ExampleApp-aws-lambda-Lambda-my-function",
"VpcConfig": {
"SubnetIds": [
"subnet-05788710b1b06b6b1",
"subnet-0c945c814c09c9aed"
],
"VpcId": "vpc-00a7e8ea4fd1ffd9d",
"SecurityGroupIds": [
"sg-05e7b8b9cad94b393"
]
},
"MemorySize": 128,
"RevisionId": "4c3d4cfd-f72b-4f4c-9c0a-031d9cfe9e46",
"CodeSize": 761,
"FunctionArn": "arn:aws:lambda:us-east-1:00000000000:function:ExampleApp-aws-lambda-Lambda-my-function",
"Handler": "index.handler",
"Role": "arn:aws:iam::00000000000:role/service-role/TestAwsLamdaRole",
"Timeout": 3,
"LastModified": "2019-06-28T22:43:32.241+0000",
"Runtime": "nodejs8.10",
"Description": ""
},
"Tags": {
"Name": "docFunction"
}
}

Lambda Verifications

You can verify your live, production Lambda functions using Harness 24/7 Service Guard or your Lambda deployments using Deployment Verifications. In both cases, you use AWS CloudWatch.

For steps on setting up CloudWatch Verification in Harness, see CloudWatch Verification.

Troubleshooting

The following troubleshooting steps should help address common issues.

User is not authorized to perform: lambda:GetFunction

When you deploy your Workflow you might receive this error:

Exception: User: arn:aws:sts::XXXXXXXXXXXX:assumed-role/iamRole_forDelegate/i-XXXXXXXXXXXX 
is not authorized to perform: lambda:GetFunction on resource:
arn:aws:lambda:us-east-1:XXXXXXXXXXXX:function:ExampleApp-aws-lambda-Lambda-test
(Service: AWSLambda; Status Code: 403; Error Code: AccessDeniedException;
Request ID: 1e93ab96-985f-11e9-92b1-f7629978142c) while deploying function: ExampleApp-aws-lambda-Lambda-test

This error occurs because the IAM role attached to your EC2 or ECS Delegate host does not have the AWSLambdaRole (arn:aws:iam::aws:policy/service-role/AWSLambdaRole) role attached. The role contains the lambda:InvokeFunction needed:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lambda:InvokeFunction"
],
"Resource": [
"*"
]
}
]
}

Attach the AWSLambdaRole (arn:aws:iam::aws:policy/service-role/AWSLambdaRole) policy to the IAM role used by your Delegate host(s).

For more information, see Identity-based IAM Policies for AWS Lambda from AWS.

Exception: The runtime parameter of nodejs6.10 is no longer supported

If you choose Node,js version 6.10 as the runtime for your Lambda function, you might receive this error.

AWS Lambda no longer supports Node,js version 6.10. Use a newer version.

Next Steps

  • CloudWatch Verification - Learn how to use AWS CloudWatch to verify your deployments and monitor your production services.


How did we do?