Working with AWS Lambda functions in the AWS Cloud9 Integrated Development Environment (IDE)
You can use the AWS Cloud9 IDE to work with AWS Lambda functions and their related Amazon API Gateway APIs in an AWS Cloud9 development environment. For example, you can:
-
Create a new function from within your environment, uploading the local version of the function to Lambda, and optionally creating additional AWS resources to support the new function at the same time.
-
Run and debug a function and its related API in your environment, running the function and API completely within the environment.
-
Run the remote version of a function and its related API within your environment, running the remote version completely within Lambda and API Gateway.
-
Import an existing function in Lambda into your environment, so that you can run and debug the function and its related API, edit the code, or both.
-
Upload changes you make to the local version of the function code to the remote version in Lambda.
This topic assumes you already know about Lambda. For more information, see the AWS Lambda Developer Guide.
Completing these procedures might result in charges to your AWS account. These include
possible charges for services such as Lambda, API Gateway, and AWS services supported
by the
AWS Serverless Application Model (AWS SAM). For more information, see AWS Lambda Pricing
Topics
- Prepare to work with Lambda functions
- Create a Lambda function with the Create serverless application wizard
- Create and deploy Lambda functions with the AWS Serverless Application Repository
- Import a Lambda function
- Invoke a Lambda function
- Invoke a Lambda function that uses environment variables
- Working with Lambda functions that use versions, aliases, or layers
- Invoke an API Gateway API for a related Lambda function
- Response differences when invoking a Lambda function from API Gateway
- Add dependent code to a Lambda function
- Debug the local version of a Lambda function or its related API Gateway API
- Change code in a Lambda function
- Upload code for a Lambda function
- Convert a Lambda function to a serverless application
- Update configuration settings for a Lambda function
- Delete a Lambda function
Prepare to work with Lambda functions
Before you can work with Lambda functions in the AWS Cloud9 IDE, you must complete the following steps:
Topics
- Step 1: Set up your IAM group with required access permissions
- Step 2: Set up your Environment with your AWS access credentials
- Step 3: Create an execution role for your Lambda functions
- Step 4: Set your Environment to the correct AWS Region
- Step 5: Open the Lambda section of the AWS Resources window
Step 1: Set up your IAM group with required access permissions
If your AWS access credentials are associated with an IAM administrator user in your AWS account, and you want to use that user to work with Lambda functions, skip ahead to Step 2: Set up your Environment with your AWS access credentials.
Otherwise, complete the following instructions to use the IAM console to attach the
AWS managed policies named AWSLambdaFullAccess
, AmazonAPIGatewayAdministrator
,
AmazonAPIGatewayInvokeFullAccess
, and an additional inline policy, to an IAM group to which your user belongs.
-
Sign in to the AWS Management Console, if you're not already signed in.
For this step, we recommend you sign in using credentials for an IAM administrator in your AWS account. If you can't do this, check with your AWS account administrator.
-
Open the IAM console. To do this, in the console's navigation bar, choose Services. Then choose IAM.
-
Choose Groups.
-
Choose the group's name.
-
On the Permissions tab, for Managed Policies, choose Attach Policy.
-
In the list of policy names, choose the boxes next to AWSLambdaFullAccess, AmazonAPIGatewayAdministrator, and AmazonAPIGatewayInvokeFullAccess. (If you don't see any of these policy names in the list, type the policy name in the Search box to display it.)
-
Choose Attach Policy.
-
Download the following ZIP file to your local computer: Cloud9LambdaAccessGroup.zip. Then extract the AWS CloudFormation template file named
Cloud9LambdaAccessGroup.yaml
from the downloaded ZIP file. -
Open the AWS CloudFormation console. To do this, in the console's navigation bar, choose Services. Then choose CloudFormation.
-
Choose Create Stack.
-
On the Select Template page, for Choose a template, choose Upload a template to Amazon S3. Choose Browse, and then choose the AWS CloudFormation template file that you just extracted.
-
Choose Next.
-
On the Specify Details page, for Stack name, type a name for the stack (for example
AWSCloud9LambdaAccessStack
. If you type a different name, replace it throughout this procedure). -
For Parameters, for GroupName, type the name of the existing group in your AWS account you want to attach the access policy to.
-
Choose Next.
-
On the Options page, choose Next. (Do not change any of the default settings on the Options page.)
-
On the Review page, choose I acknowledge that AWS CloudFormation might create IAM resources.
-
Choose Create.
Wait until the AWSCloud9LambdaAccessStack stack shows CREATE_COMPLETE. This might take a few moments. Please be patient.
The access policy that AWS CloudFormation attaches to the group is named AWSCloud9LambdaGroupAccess
and has the following definition, where
ACCOUNT_ID
is your
AWS account ID.
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "cloudformation:CreateChangeSet", "cloudformation:CreateStack", "cloudformation:DescribeChangeSet", "cloudformation:DescribeStackEvents", "cloudformation:DescribeStacks", "cloudformation:ExecuteChangeSet", "cloudformation:ListStackResources", "cloudformation:UpdateStack", "iam:AttachRolePolicy", "iam:DetachRolePolicy", "iam:GetRole", "iam:GetUser", "iam:PassRole" ], "Resource": "*", "Effect": "Allow" }, { "Action": [ "iam:CreateRole", "iam:DeleteRole" ], "Resource": "arn:aws:iam::ACCOUNT_ID:role/cloud9-*", "Effect": "Allow" } ] }
Step 2: Set up your Environment with your AWS access credentials
The AWS Cloud9 IDE uses the AWS Command Line Interface (AWS CLI) in your AWS Cloud9 development environment to interact with Lambda and other supporting AWS services. Therefore, the AWS CLI in your environment needs access to your AWS access credentials.
Do one of the following to set up the AWS CLI in your environment:
-
If you have an EC2 environment, AWS managed temporary credentials are already set up in your environment for the AWS CLI to use, and you can skip ahead to Step 3: Create an execution role for your Lambda functions. AWS managed temporary credentials have permission to interact with most AWS services from your environment (provided the AWS entity that is using the environment also has those permissions). For more information, see AWS managed temporary credentials.
-
If you have an EC2 environment but AWS managed temporary credentials don't meet your needs, you can attach an IAM instance profile to the Amazon EC2 instance that connects to your environment. Or you can store your permanent AWS access credentials within the environment. For instructions, see Create and use an instance profile to manage temporary credentials or Create and store permanent access credentials in an Environment.
-
If you have an SSH environment, you can store your permanent AWS access credentials within the environment. For instructions, see Create and store permanent access credentials in an Environment.
Step 3: Create an execution role for your Lambda functions
If you want your Lambda functions to do things using AWS resources, you must specify an IAM role (execution role) that contains the necessary access permissions for your functions to use.
When you create a Lambda function, AWS Cloud9 can create an execution role for you. This execution role contains the permissions as described in Basic Lambda Permissions in the AWS Lambda Developer Guide.
If this execution role doesn't meet your needs, you must create an execution role on your own before you create your Lambda function. For more information, see the following:
-
AWS Lambda Permissions Model in the AWS Lambda Developer Guide
-
Creating a Role to Delegate Permissions to an AWS Service in the IAM User Guide
Step 4: Set your Environment to the correct AWS Region
You must set your AWS Cloud9 development environment to use the AWS Region where you want to create new Lambda functions in your AWS account, or where you want to import existing Lambda functions from your AWS account into your AWS Cloud9 development environment.
To do this:
-
In the AWS Cloud9 IDE, on the menu bar, choose AWS Cloud9, Preferences.
-
In the navigation pane of the Preferences tab, choose AWS Settings.
-
For AWS Region, select the AWS Region you want to use.
Step 5: Open the Lambda section of the AWS Resources window
Now you're ready to begin using the AWS Cloud9 IDE to work with Lambda functions. To do this, expand the Lambda section of the AWS Resources window, if it isn't already expanded.

If the AWS Resources window isn't visible, choose the AWS Resources button.
If you don't see the AWS Resources button, choose Window, AWS Resources on the menu bar to show it.
Create a Lambda function with the Create serverless application wizard
You can use the AWS Cloud9 IDE to create a new Lambda function. If you already have a Lambda function in your AWS account for the AWS Region you set earlier, skip ahead to Import a Lambda function.
This procedure describes how to use the Create serverless application wizard to create a single Lambda function based on function blueprints that are owned by AWS. To create multiple Lambda functions at the same time, Lambda functions along with supporting components at the same time, or Lambda functions that are owned by entities other than AWS, skip ahead to Create and deploy Lambda functions with the AWS Serverless Application Repository.
-
In the Lambda section of the AWS Resources window, choose where you want to create the function:
-
To create a single function by itself, choose the Local Functions heading.
-
To create a function and then add it to an existing group of one or more functions and related AWS resources (referred to as a serverless application), in the Local Functions list, choose the serverless application for the group (represented by the Lambda icon inside of a folder).
-
-
Do one of the following:
-
Choose Create a new Lambda function (the button with the Lambda icon).
-
Right-click the Local Functions heading or the serverless application folder you chose earlier, and then choose Create Here.
-
-
In the Create serverless application dialog box, specify the following settings for the function:
-
Function Name: A name for the function.
-
Application Name: The name of the new serverless application to be associated with the new function.
Important Both of these names must contain only alphanumeric characters and hyphens. Each name must start with an alphabetic character, and each name must not exceed 128 characters.
-
-
Choose Next.
-
Choose the function blueprint you want to start with. (Currently, only Node.js and Python function blueprints are available.)
To show blueprints for a specific runtime, for Select Runtime, choose the runtime. For example, to use the
hello-world
function blueprint for Node.js 6.10, choose Node.js 6.10 for Select Runtime, and then choose the hello-world blueprint for Select Blueprint. -
Choose Next.
-
Do one of the following:
-
To skip having an AWS service automatically trigger this function, leave Function Trigger set to none, choose Next, and then skip ahead to step 9 in this procedure.
-
To have an AWS resource in your account automatically trigger your function, for Function Trigger, select the name of the AWS service that will contain the resource. (Currently, only API Gateway is available.)
-
-
If you chose API Gateway for Function Trigger, specify the following for Trigger Settings:
-
For Resource Path, type the URL portion of the API to use to invoke the function. For example, type
/
to specify the resource root. -
For Security, choose the security mechanism for the API endpoint:
-
AWS_IAM: Require that callers provide IAM access credentials to be authenticated. See Control Access to API Gateway with IAM Permissions in the API Gateway Developer Guide.
-
NONE: Enable open access.
-
NONE_KEY: Require that callers provide an API key to be authenticated. See Set Up API Keys Using the API Gateway Console in the API Gateway Developer Guide.
-
-
-
Choose Next.
-
For Memory (MB), choose the amount of memory, in megabytes, that this function will use.
-
Do one of the following:
-
To have AWS Cloud9 create a new, basic IAM role (execution role) for this function to use, for Role, choose Automatically generate role. Then choose Next.
-
To have Lambda use an existing IAM role (execution role) in your AWS account, for Role, choose Choose an existing role. For Existing Role, choose the name of the role, and then choose Next.
-
-
Choose Next.
-
Choose Finish.
Compare your results to the following:

In the Lambda section of the AWS Resources window, AWS Cloud9 does the following:
-
If you chose to create a single function by itself:
-
AWS Cloud9 creates a serverless application with the name that you specified earlier. Then it adds a serverless application (represented by a Lambda icon inside of a folder) to the Local Functions list. Then it adds the Lambda function (represented by a Lambda icon by itself), to this serverless application.
-
AWS Cloud9 creates a remote version of the function in Lambda and adds it to the Remote Functions list. AWS Cloud9 gives the remote version a different name. For example, if you named the serverless application
myDemoServerlessApplication
and the functionmyDemoFunction
, the remote version name of your function would becloud9-myDemoServerlessApplication-myDemoFunction-RANDOM_ID
, whereRANDOM_ID
is a randomly determined ID. -
If you chose to have API Gateway automatically trigger the function, AWS Cloud9 creates an API in API Gateway with a name that corresponds to the function. For example, if you named the function
myDemoFunction
, the API name would becloud9-myDemoFunction
. AWS Cloud9 uses the value you specified in Resource Path to map the function to the API using theANY
method.
-
-
If you chose to create a single function and then add it to an existing serverless application:
-
AWS Cloud9 adds the Lambda function (represented by a Lambda icon by itself), to the existing serverless application (represented by a Lambda icon inside of a folder).
-
AWS Cloud9 creates a remote version of the function in Lambda and adds it to the Remote Functions list. AWS Cloud9 gives the remote version a different name. For example, if you named the function
myDemoFunction
and added it to a serverless application namedmyDemoServerlessApplication
, the remote version name would becloud9-myDemoServerlessApplication-myDemoFunction-RANDOM_ID
, whereRANDOM_ID
is a randomly determined ID. -
If you chose to have API Gateway automatically trigger your function, AWS Cloud9 creates an API in API Gateway with a name that corresponds to the related serverless application, if it doesn't already exist. For example, if the serverless application is named
myDemoServerlessApplication
, the API name would becloud9-myDemoServerlessApplication
. AWS Cloud9 uses the value you specified in Resource Path to map the function to the API using theANY
method.
-
In the Environment window, AWS Cloud9 does the following:
-
If you chose to create a single function by itself, AWS Cloud9 creates a folder with the same name as the serverless application and puts this folder in the root of the AWS Cloud9 development environment. AWS Cloud9 then adds the following files to the folder:
-
.application.json
: A hidden file used by AWS Cloud9 that contains JSON-formatted settings specific to the serverless application. -
.gitignore
: A hidden file that contains a list of files Git ignores, if you want to use Git to manage your source code for this function. -
template.yaml
: An AWS SAM template file that contains information about the Lambda function and any other related supported AWS resources. Whenever you update the local version of your function and then upload it to Lambda, AWS Cloud9 calls AWS SAM to use this template file to do the upload. For more information, see Using the AWS Serverless Application Model (AWS SAM) in the AWS Lambda Developer Guide.Note You can edit this file to create additional supporting AWS resources for your function. For more information, see the AWS Serverless Application Model (AWS SAM)
repository on GitHub. -
A subfolder with the same name as the function, containing a code file representing the function logic.
-
If the function uses Python, additional subfolders and files are added to the preceding subfolder to enable Python debugging:
-
.debug
: A subfolder that contains Python modules and files for debugging purposes. -
venv
: A standard Python virtualenv folder. This includes a module named ikpdb, which AWS Cloud9 uses to debug Python applications. -
__init__.py
: A standard Python package initialization file. -
requirements.txt
: A standard file for installing Python modules. -
AWS Cloud9 also adds a
CodeUri
property to thetemplate.yaml
file and sets this property to reference the.debug/
folder.
-
-
-
If you chose to create a single function and then add it to an existing serverless application, AWS Cloud9 does the following to the folder that represents the serverless application:
-
Updates the
template.yaml
file previously described to include information about the Lambda function and any other related supported AWS resources. -
A subfolder with the same name as the function, containing a code file representing the function logic.
-
If the function uses Python, additional subfolders and files are added to the preceding subfolder to enable Python debugging:
-
.debug
: A subfolder that contains Python modules and files for debugging purposes. -
venv
: A standard Python virtualenv folder. This includes a module named ikpdb, which AWS Cloud9 uses to debug Python applications. -
__init__.py
: A standard Python package initialization file. -
requirements.txt
: A standard file for installing Python modules. -
AWS Cloud9 also adds a
CodeUri
property to thetemplate.yaml
file and sets this property to reference the.debug/
folder.
-
-
The .application.json
and .gitignore
files (and the .debug
folder for Python) are hidden. To show hidden files or hide
them if they're shown, in the Environment window,
choose the gear icon, and then choose Show Hidden Files.

To invoke the function, see Invoke a Lambda function. If the function has a related API in API Gateway, to invoke the API, see Invoke an API Gateway API for a related Lambda function.
Create and deploy Lambda functions with the AWS Serverless Application Repository
You can use the AWS Cloud9 IDE and the AWS Serverless Application Repository
-
In a separate web browser tab, open the AWS Serverless Application Repository
. -
Find the serverless application you want to create, and then choose the title of the serverless application that you want inside of its card. (If the card isn't visible, begin typing information about the serverless application that you want in the Search applications by name, description, or labels box to show it.)
-
On the Application details page that appears, if a URL for a Git-based repository is displayed, copy that URL (for example,
https://github.com/USER_NAME/REPOSITORY_NAME
).Note If a URL isn't displayed, try choosing the Deploy button on the Application details page, and then look for a Source code URL value.
-
Back in the AWS Cloud9 IDE, open a terminal, if one isn't already open. (To open a terminal, on the menu bar, choose Window, New Terminal.)
-
In the terminal, change to the directory in your environment where you want to copy the serverless application's starter files (for example, by running the command
cd ~/environment
). -
Run the command
git clone
, followed by the Git URL you copied earlier (for example,git clone https://github.com/USER_NAME/REPOSITORY_NAME
). The IDE then adds the serverless application's functions to the Lambda section of the AWS Resources window.Note Running the
git clone
command with some of the URLs in the Application details pages or Source code URL values might not work as expected or might produce unexpected results. Alternatively, you can manually download the files you want from the desired repository to your local workstation. Then manually upload those files to the IDE by running File, Upload Local Files on the menu bar.When you clone the GitHub repository, the IDE uses the AWS Serverless Application Model (AWS SAM) template file in the repository to determine which of the serverless application's functions to display in the Lambda section of the AWS Resources window. The AWS SAM template file must follow the AWS Serverless Application Model (AWS SAM)
file format. If the repository doesn't contain an AWS SAM template file, or if the file doesn't follow the AWS SAM file format, the IDE won't display those functions. You also won't be able to run, debug, or deploy those functions or any of their associated API Gateway resources from the Lambda section of the AWS Resources window. -
You might need to complete some setup before you can run, debug, or deploy the serverless application from the IDE as expected. For setup instructions, see the Application details page that you opened earlier. Or look for any setup instructions within the serverless application's files that you cloned to your IDE.
To invoke the functions, see Invoke a Lambda function. If the functions have related APIs in API Gateway, to invoke the APIs, see
Invoke an API Gateway API for a related Lambda
function. When you invoke a function or API this way for the first time, AWS Cloud9
adds a hidden .application.json
file to the serverless application's
component files. This file is used by AWS Cloud9 and contains JSON-formatted settings
that are
specific to the serverless application.
If the serverless application requires parameters to be specified during deployment,
you
can deploy it from the IDE only by using the terminal. To see if parameters are required,
on the Application details page you opened earlier, choose the
Deploy button, and then see the Configure application
parameters card for any parameters. If there are any parameters, deploy the
serverless application from the terminal in the IDE by running the AWS CloudFormation
deploy
command, for example:
aws cloudformation deploy --template-file TEMPLATE_FILE_PATH --parameter-overrides "PARAMETER_KEY_1=PARAMETER_VALUE_1" "PARAMETER_KEY_N=PARAMETER_VALUE_N" --region REGION_ID
In the preceding command:
-
TEMPLATE_FILE_PATH
represents the path to the AWS SAM template file. -
PARAMETER_KEY_1
represents the name of the first parameter. -
PARAMETER_VALUE_1
represents the value of the first parameter. -
PARAMETER_KEY_N
represents the name of an additional parameter, and so on. -
PARAMETER_VALUE_N
represents the value of an additional parameter, and so on. -
REGION_ID
represents the ID of the AWS Region where you want to deploy the serverless application (for example,us-east-2
). -
Additional options might need to be specified, depending on the serverless application's requirements. For more information, see the Application details page that you opened earlier, or look for any setup instructions within the serverless application's files that you cloned to your IDE.
If you try to use the Lambda section of the AWS Resources window to deploy a serverless application that requires parameters, a message is displayed that required parameters are missing, and the serverless application is not deployed.
Import a Lambda function
If you have an existing Lambda function in your AWS account but not in your AWS Cloud9 development environment, you must import it before you can work with it in your environment.
If the Lambda function is part of an existing AWS CodeStar project, and the environment was created from within the project in the AWS CodeStar console, the function is already imported, so you do not need to import it again.
To confirm this behavior, look in the Local Functions list in the Lambda section of the AWS Resources window
for a serverless application (represented by a Lambda icon inside of a folder) with
the same name as the AWS CodeStar project, containing a Lambda function
(represented by a Lambda icon by itself) with the function's base name. Look also
in the Remote Functions list
for a Lambda function with a name in the format awscodestar-PROJECT_NAME-lambda-BASE_FUNCTION_NAME-RANDOM_ID
,
where PROJECT_NAME
is the AWS CodeStar project name, BASE_FUNCTION_NAME
is the function's base name, and RANDOM_ID
is a randomly determined ID.

Since the function is already imported, we do not recommend that you import the remote version of the function in the AWS CodeStar project. Otherwise, you will have two versions of the same function code in your Environment window but with different folder names, which could be confusing.
To import a Lambda function, do the following:
-
In the Environment window, choose where you want to import the function.
-
In the Lambda section of the AWS Resources window, choose the function's name in the Remote Functions list.
Note If you don't see your function in the Remote Functions list, choose the Refresh functions List button (the button with the circular arrow icon).
-
Do one of the following:
-
Double-click the function you just chose.
-
On the menu bar in the Lambda section, choose the Import the selected Lambda function button (the button with the arrow that faces down).
-
Right-click the function you just chose, and then choose Import.
Note You cannot import a Lambda function into a folder that represents either a serverless application or a Lambda function. If you try to do this, AWS Cloud9 will display a message that it will import the Lambda function into the environment's root location instead. To let AWS Cloud9 do this, choose Import. Otherwise, choose Cancel, choose a different folder to import the function (or create a new empty folder to import the function into), and then restart this procedure from the beginning.
-
-
When prompted to finish importing the function, choose OK.
AWS Cloud9 imports your function into a new folder in the root of your environment. (AWS Cloud9 also adds the function to the Local Functions list in the Lambda section of the AWS Resources window.) This folder has the same name as the function. AWS Cloud9 adds the following files to this folder:
-
.application.json
: A hidden file used by AWS Cloud9 that contains JSON-formatted settings specific to the function. -
.gitignore
: A hidden file that contains a list of files Git ignores, if you want to use Git to manage your source code for this function. -
template.yaml
: A file for AWS Cloud9 internal use.Note Although the
template.yaml
file is expressed in AWS SAM format, it isn't used by AWS SAM. Therefore, you cannot edit this file to create additional supporting AWS resources for your function. Do not modify this file. -
One or more code files containing the function logic.
The .application.json
and .gitignore
files are
hidden. To display or hide hidden files, in the Environment window,
choose the gear icon, and then choose Show Hidden Files.
To invoke the function, see Invoke a Lambda function.
Invoke a Lambda function
To invoke an existing Lambda function, you must first import the remote version of the function into your AWS Cloud9 development environment, if the function isn't already there. To do this, see Import a Lambda function.
-
In the Lambda section of the AWS Resources window, expand the Local Functions list, if it isn't already expanded.
-
Expand the serverless application folder that contains the function that you want to invoke.
-
Choose the function that you want to invoke, right-click it, and then choose Run.
-
Do one of the following:
-
To run the local version of the function within your environment, choose Run Local.
-
To run the remote version of the function within Lambda, choose Run Remote.
Note If nothing appears to happen, an invoke tab might already be open for the function. If so, choose Lambda (local) or Lambda (remote) in the open invoke tab.
-
-
In the Test payload pane of the invoke tab that is displayed, confirm any custom input data you want your function to use when you test it. For information about the input data format, see Step 2.2: Invoke the Lambda Function Manually and Verify Results, Logs, and Metrics in the AWS Lambda Developer Guide.
-
In the invoke tab, choose the Run button.
Note After you run the function for the first time, a
lambda-payloads.json
: file is added to the function's related serverless application folder in the Environment window. This file contains the contents of the custom input data.If you invoke an existing Lambda function and then try to invoke the same function code for its related API in API Gateway with the same custom input data, you might get an error or the code might not run as expected. For more information, see Response differences when invoking a Lambda function from API Gateway.
The invoke tab contains two panes:
-
The Test payload pane displays any custom input data that was supplied for the function.
-
The Execution results pane displays any output from the function and some information from the related Amazon CloudWatch Logs for the function.
Compare your results to the following:

For more information, see Step 2.2: Invoke the Lambda Function Manually and Verify Results, Logs, and Metrics in the AWS Lambda Developer Guide.
To upload the local version of any changed function code to the related remote version in Lambda, see Upload code for a Lambda function.
Invoke a Lambda function that uses environment variables
To invoke a Lambda function locally or remotely that uses environment variables, do one of the following.
- Invoke a Lambda function locally with predefined environment variables and their values
-
Add the predefined environment variable definitions to the function's
template.yaml
file if they are not already there, and then run the Run Local command for that function from the Lambda section of the AWS Resources window.For example, given the following Node.js function definition in a file named
index.js
:exports.handler = (event, context, callback) => { var result = { MY_ENV_VAR_1: process.env.MY_ENV_VAR_1, MY_ENV_VAR_2: process.env.MY_ENV_VAR_2 }; const response = { statusCode: 200, headers: { "Content-type": "application/json" }, body: result }; callback(null, response); };
And given the following addition to the function's
template.yaml
file one directory aboveindex.js
:... Resources: MyEnvVarsFunction: Type: 'AWS::Serverless::Function' Properties: ... Environment: Variables: MY_ENV_VAR_1: "This is my environment variable 1 value from the template.yaml file." MY_ENV_VAR_2: "This is my environment variable 2 value from the template.yaml file."
And running the Run Local command for that function from the Lambda section of the AWS Resources window, the following is output:
{ "statusCode": 200, "headers": { "Content-type": "application/json" }, "body": { "MY_ENV_VAR_1": "This is my environment variable 1 value from the template.yaml file.", "MY_ENV_VAR_2": "This is my environment variable 2 value from the template.yaml file." } }
- Invoke a Lambda function locally with environment variables and their values that the caller provides dynamically at run time
-
You cannot use the Run Local command for such a function from the Lambda section of the AWS Resources window.
Instead, add the predefined environment variable definitions to the function's
template.yaml
file if they are not already there. Then use the terminal in the IDE to run the AWS SAM CLI with the invoke command along with the --env-vars argument and a separate JSON file that contains the environment variable definitions and their values.For example, given the following Node.js function named
MyEnvVarsFunction
with its definition in a file namedindex.js
:exports.handler = (event, context, callback) => { var result = { MY_ENV_VAR_1: process.env.MY_ENV_VAR_1, MY_ENV_VAR_2: process.env.MY_ENV_VAR_2 }; const response = { statusCode: 200, headers: { "Content-type": "application/json" }, body: result }; callback(null, response); };
And given the following addition to the function's
template.yaml
file one directory aboveindex.js
:... Resources: MyEnvVarsFunction: Type: 'AWS::Serverless::Function' Properties: ... Environment: Variables: MY_ENV_VAR_1: "This is my environment variable 1 value from the template.yaml file." MY_ENV_VAR_2: "This is my environment variable 2 value from the template.yaml file."
And given the following file named
MyEnvVars.json
in the same directory asindex.js
:{ "MyEnvVarsFunction": { "MY_ENV_VAR_1": "This is my environment variable 1 value from the JSON file.", "MY_ENV_VAR_2": "This is my environment variable 2 value from the JSON file." } }
And running the following AWS SAM CLI command from the same directory as
index.js
:sam local invoke --event lambda-payloads.json --template ../template.yaml --env-vars MyEnvVars.json
The following is output:
{ "statusCode": 200, "headers": { "Content-type": "application/json" }, "body": { "MY_ENV_VAR_1": "This is my environment variable 1 value from the JSON file.", "MY_ENV_VAR_2": "This is my environment variable 2 value from the JSON file." } }
- Invoke a Lambda function remotely that already has predefined environment variable and their values
-
Run the Run Remote command for that function from the Lambda section of the AWS Resources window.
To view or change predefined environment variable values for an existing remote function before you invoke it remotely, see AWS Lambda Environment Variables in the AWS Lambda Developer Guide.
- Invoke a Lambda function remotely with environment variables and their values that the caller provides dynamically at run time
-
You cannot use the Run Remote command for such a function from the Lambda section of the AWS Resources window.
Instead, you can use the terminal in the IDE to run the AWS CLI with the lambda command's update-function-configuration action and the --environment argument with the environment variable definitions and their values. Then run the lambda command's invoke action.
For example, given the following Node.js function named
MyEnvVarsFunction
with the following definition and with predefined environment variables namedMY_ENV_VAR_1
andMY_ENV_VAR_2
:exports.handler = (event, context, callback) => { var result = { MY_ENV_VAR_1: process.env.MY_ENV_VAR_1, MY_ENV_VAR_2: process.env.MY_ENV_VAR_2 }; const response = { statusCode: 200, headers: { "Content-type": "application/json" }, body: result }; callback(null, response); };
And running the following AWS CLI commands, one at a time in the following order:
aws lambda update-function-configuration --function-name MyEnvVarsFunction --environment '{"Variables":{"MY_ENV_VAR_1":"This is my environment variable 1 value from the AWS CLI.","MY_ENV_VAR_2":"This is my environment variable 2 value from the AWS CLI."}}' aws lambda invoke --function-name MyEnvVarsFunction results.json
The following is output to a file named
results.json
:{ "statusCode": 200, "headers": { "Content-type": "application/json" }, "body": { "MY_ENV_VAR_1": "This is my environment variable 1 value from the AWS CLI.", "MY_ENV_VAR_2": "This is my environment variable 2 value from the AWS CLI." } }
For more details, see the discussion of update-function-configuration and invoke in Create the Lambda function and Test It in the AWS Lambda Developer Guide.
Working with Lambda functions that use versions, aliases, or layers
The Lambda section of the AWS Resources window currently does not provide any features for working with versions, aliases, or layers for Lambda functions. Instead, you can use the terminal in the IDE to run the AWS CLI and AWS SAM CLI with the corresponding commands, actions, and arguments. For details, see the following.
-
Introduction to AWS Lambda Versioning in the AWS Lambda Developer Guide
-
Introduction to AWS Lambda Aliases in the AWS Lambda Developer Guide
-
Managing Versioning Using the AWS Management Console, the AWS CLI, or Lambda API Operations in the AWS Lambda Developer Guide
-
AWS Lambda Layers in the AWS Lambda Developer Guide
-
Working with Layers in the AWS Serverless Application Model Developer Guide
-
AWS::Serverless::LayerVersion in the AWS Serverless Application Model Developer Guide
Invoke an API Gateway API for a related Lambda function
To invoke an API in API Gateway that is related to an existing Lambda function, you must first import the remote version of the function into your AWS Cloud9 development environment, if the function isn't already there. To do this, see Import a Lambda function.
You cannot debug the remote version of the API Gateway API in your environment. You can only invoke it. To debug the local version, see Debug the local version of a Lambda function or its related API Gateway API.
-
In the Lambda section of the AWS Resources window, expand the Local Functions list, if it isn't already expanded.
-
Expand the serverless application folder that contains the function whose API you want to invoke.
-
Choose the function, right-click it, and then choose Run.
-
Do one of the following:
-
To run the local version of the API within your environment, choose Run API Gateway Local.
-
To run the remote version of the function within Lambda, choose Run API Gateway Remote.
Note If nothing appears to happen, an invoke tab might already be open for the function. If so, choose API Gateway (local) or API Gateway (remote) in the open invoke tab.
-
-
In the Test payload pane of the invoke tab that is displayed, confirm the Function, Path, Method, Query String, and Body you want the API to use when you test it.
Note Some APIs might not support settings such as Body. For more information, consult the owner of the API.
-
On the invoke tab, choose the Run button.
Note If the API isn't connected to the function, a message appears that says an API Gateway trigger can't be found in the function's AWS SAM file. To use this AWS SAM file to connect an API in API Gateway to the function, see the AWS Serverless Application Model (AWS SAM)
repository on GitHub. If you invoke an API in API Gateway and then try to invoke the same code for its related function in Lambda with the same custom input data, you might get an error or the code might not run as expected. For more information, see Response differences when invoking a Lambda function from API Gateway.
The invoke tab contains two panes:
-
The Test payload pane displays settings and any custom input data that was supplied for the API.
-
The Execution results pane displays information such as the body, headers, and logs of the API response.
Compare your results to the following:

Response differences when invoking a Lambda function from API Gateway
When you invoke a Lambda function from an API in API Gateway and then try to parse
the response, you might get an error or the code might not run as expected. This is
because
Lambda and API Gateway use slightly different response formats. Specifically, API
Gateway wraps its response in a parent body
object. To address this issue, you can add code to a function
that checks to see if a parent body
exists in the response. If it does, you can then extract the data from that body
object.
For example, given the following Node.js function code:
'use strict'; exports.handler = function(event, context, callback) { if (event.body) { event = JSON.parse(event.body); } const message = "Your favorite fruit is " + event.fruit + ". " + "Your favorite vegetable is " + event.vegetable + "."; const response = { statusCode: 200, headers: { "Content-type": "application/json" }, body: JSON.stringify( { "message": message } ) }; callback(null, response); };
And given the following equivalent Python function code:
import json def lambda_handler(event, context): if 'body' in event: event = json.loads(event["body"]) message = ("Your favorite fruit is " + event["fruit"] + ". " + "Your favorite vegetable is " + event["vegetable"] + ".") response = { "statusCode": "200", "headers": { "Content-type": "application/json" }, "body": json.dumps({"message": message}) } return response
To invoke the preceding code, you use the following input payload (for Lambda) or input body (for API Gateway):
{ "fruit": "apple", "vegetable": "carrot" }
Which returns the following response for Lambda:
{ "statusCode": 200, "headers": { "Content-type": "application/json" }, "body": "{\"message\":\"Your favorite fruit is apple. Your favorite vegetable is carrot.\"}" }
And returns the following response for API Gateway (assuming a Path of / and a Method of POST):
{ "message": "Your favorite fruit is apple. Your favorite vegetable is carrot." }
If you do not include the if (event.body)
check for Node.js or the if 'body' in event
check for Python, then calling this function from API Gateway
might return an error or the API might not run as expected.
Add dependent code to a Lambda function
For Node.js, we support using Node Package Manager (npm) to add dependent packages
to Lambda functions in your environment. For Python, we support pip. For general information
about npm and pip, see
the npm
To depend on an npm package from a Node.js Lambda function, use for example the Node.js
require
statement. Then use npm to install the related npm package in the environment within
the
same directory as the function code. When you deploy the Lambda function as described
in Upload code for a Lambda function, AWS Cloud9 deploys both the function and its related packages to Lambda.
To demonstrate, the following example Node.js Lambda function code depends on the
lodash
package to sort the specified JSON input payload.
'use strict'; /* Assume the following payload is input: [ { "firstName": "Shirley", "lastName": "Rodriguez" }, { "firstName": "Jane", "lastName": "Doe" }, { "firstName": "Arnav", "lastName": "Desai" } ] The expected response is: { "statusCode": 200, "headers": { "Content-type": "application/json" }, "body": { "result": [ { "firstName": "Arnav", "lastName": "Desai" }, { "firstName": "Jane", "lastName": "Doe" }, { "firstName": "Shirley", "lastName": "Rodriguez" } ] } } */ exports.handler = (event, context, callback) => { var lodash = require('lodash'); var result = lodash.orderBy(event, ['firstName'], ['asc']); const response = { statusCode: 200, headers: { "Content-type": "application/json" }, body: JSON.stringify( { "result": result } ) }; callback(null, response); };
To install the lodash
package in the environment, use a terminal session in the IDE to change to the directory
containing the function code.
Then run the following two commands, in the following order. The first command creates
and configure a package.json
file in that directory to make sure when you
deploy the function to Lambda, the lodash
package is also deployed.
The second command installs the lodash
package in the same directory in the environment
as the function code and then updates the package.json
file in that directory accordingly.
npm init npm install lodash --save
For help with the npm init
command and the package.json
file, see
Working with package.json
From the IDE, invoke the local version of the Lambda function, as described in Invoke a Lambda function. Deploy the function as described in Upload code for a Lambda function, and then invoke the remote version of the function. The local and remote versions of the function should work as expected.
To depend on a pip package from a Python Lambda function, use for example the Python
import
statement. Then use pip to install the related pip package in the environment one directory above the
directory that contains the function code. When you deploy the Lambda function as
described in Upload code for a Lambda function, AWS Cloud9 deploys both the function and its related packages to Lambda.
To demonstrate, the following example Python Lambda function code depends on the requests
package to make an HTTP request and then return information about the related HTTP
response.
''' Assume the following payload is input: { "url": "https://aws.amazon.com" } The expected response is similar to the following: { "statusCode": "200", "headers": { "Content-type": "application/json" }, "body": { "statusCode": 200, "date": "Fri, 19 Jan 2018 17:57:48 GMT", "lastModified": "Thu, 18 Jan 2018 18:08:23 GMT" } } ''' import requests import json def lambda_handler(event, context): result = requests.get(event["url"]) response = { "statusCode": "200", "headers": { "Content-type": "application/json" }, "body": json.dumps( { "statusCode": result.status_code, "date": result.headers["Date"], "lastModified": result.headers["Last-Modified"] } ) } return response
To install the requests
package in the environment, use a terminal session in the IDE to change to the directory
containing the function code.
Then run the following command. This command installs the requests
package in the directory in the environment that is one directory above
the function code.
pip install requests --target ../
From the IDE, invoke the local version of the Lambda function, as described in Invoke a Lambda function. Deploy the function as described in Upload code for a Lambda function, and then invoke the remote version of the function. The local and remote versions of the function should work as expected.
For a Python Lambda function, to depend on code in a separate Python code file that
is in the same directory as the function, use the from
and import
statements.
When you deploy the Lambda function as described in Upload code for a Lambda function, AWS Cloud9 deploys to Lambda both the function and the separate Python code files
in the same directory as the function.
To demonstrate, take for example the following directory structure in the AWS Cloud9 IDE for a Python Lambda function:
myDemoServerlessApplication `- myDemoFunction |- lambda-payloads.json |- lambda_function.py `- myClasses.py
If the myClasses.py
file contains the definition of a class named MyClass1
, for example:
class MyClass1: # Class definition...
To reference the MyClass1
class from the lambda_function.py
file, add the following statement to the file:
from myDemoFunction.myClasses import MyClass1
Debug the local version of a Lambda function or its related API Gateway API
You can debug local Lambda function code or its related API Gateway API in your environment using common debugging aids such as breakpoints, stepping through code, and setting watch expressions.
You cannot debug the remote version of a Lambda function or its related API Gateway API in your environment. You can only invoke it.
To debug the local version of an existing Lambda function or its related API Gateway API, you must first import the remote version of the function into your AWS Cloud9 development environment, if the function isn't already there. See Import a Lambda function.
If you import the remote version of a Python function into your environment, you must choose one of the following options before you can debug it:
Option 1: If the Python function doesn't use venv, use pip to install IKPdb into the same directory as the function's template.yaml file.
Use a terminal session in the IDE to change to the directory containing the function's
template.yaml
file. Then run one of the following commands. This
command installs the Python debugger IKPdb in the same directory as the function's
template.yaml
file:
pip install ikpdb --target . # For a function that uses Python 2.7. pip-3.6 install ikp3db --target . # For a function that uses Python 3.6.
Option 2: If the Python function uses venv, use pip in venv to install IKPdb into the function's venv directory, and then add the CodeUri property to the function's template.yaml file.
-
Use a terminal session in the IDE to change to the directory containing the function's
template.yaml
file. From that folder, run one of the following commands. This command uses pip in the function'svenv/bin
directory to install the Python debugger IKPdb into the function'svenv/lib/pythonMAJOR.MINOR/dist-packages
directory:venv/bin/pip install ikpdb # For a function that uses Python 2.7. venv/bin/pip3.6 install ikp3db # For a function that uses Python 3.6.
-
In the Environment window, open the function's
template.yaml
file for editing. In theProperties
section for the function, add theCodeUri
property, set its value to.debug/
, and then save the file. For example:AWSTemplateFormatVersion: '2010-09-09' Transform: 'AWS::Serverless-2016-10-31' Description: An AWS Serverless Specification template describing your function. Resources: myDemoFunction: Type: 'AWS::Serverless::Function' Properties: CodeUri: .debug/ # ...
-
In the Environment window, open the file that contains the Lambda function's code you want to debug.
-
Set any breakpoints and watch expressions for your code. See Debug Your Code.
-
In the Lambda section of the AWS Resources window, expand the Local Functions list, if it isn't already expanded.
-
Expand the serverless application folder that contains the function you want to debug.
-
Choose the function to debug, right-click it, and then choose Run, Run Local or Run, Run API Gateway Local.
Note If nothing appears to happen, an invoke tab might already be open for the function. If so, go to the open invoke tab and choose Lambda (local) or API Gateway (local).
-
For a Lambda function, in the Test payload pane of the invoke tab that is displayed, confirm any custom input data you want your function to use when you test it. For information about the input data format, see Step 2.2: Invoke the Lambda Function Manually and Verify Results, Logs, and Metrics in the AWS Lambda Developer Guide.
-
For an API Gateway API, in the Test payload pane of the invoke tab that is displayed, confirm the Path, Method, Query String, and Body you want the API to use when you test it.
Note Some APIs might not support settings such as Body. For more information, consult the owner of the API.
-
Next to the Run button, choose Run in Debug Mode (the bug icon).
-
Choose the Run button.
-
Decide what to do whenever function execution pauses at a breakpoint. See Debug Your Code.

Compare your results to the following:

Change code in a Lambda function
To use the AWS Cloud9 IDE to change the code in a function, you must first import the related remote version of the function into your AWS Cloud9 development environment, if the function isn't already there. To do this, see Import a Lambda function. Then do the following:
-
In the Lambda section of the AWS Resources window, expand the Local Functions list, if it isn't already expanded.
-
Expand the serverless application folder that contains the function whose code you want to change.
-
Right-click the function, and then choose Edit Function.
-
Make the changes you want to the code, and then save the file.
To upload the local version of the changed function code to the related remote version in Lambda, see Upload code for a Lambda function.
Upload code for a Lambda function
To upload the local version of a Lambda function in your environment to the related remote version of the function in Lambda, follow one of these procedures, depending on how the function was created.
How was the function created? | Follow this procedure |
---|---|
By using the Create serverless application wizard in the IDE. |
Upload code for a Lambda function created by the Create serverless application wizard |
As part of an AWS CodeStar project. |
Upload code for a Lambda function that is part of an AWS CodeStar project |
By using the AWS Serverless Application Repository, and the serverless application requires parameters to be specified during deployment. |
|
Any other way. |
Upload code for a Lambda function created by the Create serverless application wizard
After you Create a Lambda function with the Create serverless application wizard in your environment, you can upload the local version of that function to the related remote version of the function in Lambda as follows.
-
In the Lambda section of the AWS Resources window, expand the Local Functions list, if it isn't already expanded.
-
Expand the serverless application folder that contains the function you want to upload.
-
Do one of the following:
-
Right-click the serverless application folder that you just chose, and then choose Deploy.
-
Right-click the function you want to upload, and then choose Deploy.
-
Choose the function you want to upload, and then choose Deploy the selected Lambda function (the button with the arrow that faces up).
-
Upload code for a Lambda function that is part of an AWS CodeStar project
As you are Working with AWS CodeStar Projects in the AWS Cloud9 Integrated Development Environment (IDE), you can upload the local version of that function in your environment to the related remote version of the function in Lambda as follows.
Use a terminal session in the IDE to run the
git push
command to push committed code changes to the repository for the AWS CodeStar project.
This instructs AWS CodeStar to upload
the local version of the Lambda function in your environment to the related remote
version of the function in Lambda.
If you do not follow this procedure, the error "Parameters: [ProjectId] must have values" will display, and the function will not deploy.
Upload code for a Lambda function that is part of an AWS Serverless Application Repository project with parameters
If you Create and deploy Lambda functions with the
AWS Serverless Application Repository, and that project requires you to specify parameters
during the upload, see coverage of the AWS CloudFormation deploy
command in Create and deploy Lambda functions with the
AWS Serverless Application Repository for upload instructions.
If you do not follow that procedure, an error will display that required parameters are missing, and the code will not upload.
Upload code for a Lambda function by using a specific AWS CloudFormation stack, function name, or both
To begin the upload process, AWS Cloud9 instructs AWS CloudFormation to create a stack with a specific name. AWS CloudFormation uses the information in this stack to complete the upload of the local version of the Lambda function in your environment to a specific function in Lambda. By default, the name of this stack and the name of the Lambda function is one of the following, which you can change if needed.
-
If a hidden
.application.json
file exists in the same folder as the local version of the Lambda function, and the file contains aStackName
value, the stack's name is the same as theStackName
value, and the Lambda function name iscloud9-APPLICATION_NAME-FUNCTION_NAME
. -
If there is no hidden
.application.json
file in the same folder as the local version of the Lambda function, or if theapplication.json
file exists but has noStackName
value, the stack's name iscloud9-FOLDER_NAME
, and the Lambda function name iscloud9-APPLICATION_NAME-FUNCTION_NAME
.
In the preceding stack and function names, FOLDER_NAME
is the name of
the related folder in the Environment window, while
APPLICATION_NAME
and FUNCTION_NAME
are the related values
as displayed in the Lambda section of the AWS
Resources window.
If you do not want to change the name of the default AWS CloudFormation stack or the default function name in Lambda, then skip ahead to the upload procedure at the end of this section.
To use or create a non-default AWS CloudFormation stack in your AWS account in the same AWS Region as displayed in the Lambda section of the AWS Resources window, do one of the following.
-
If you want to use an existing AWS CloudFormation stack to upload the code, then in the Lambda section of the AWS Resources window, right-click the serverless application folder that contains the Lambda function you want to upload the code to, choose Link to CloudFormation Stack, and follow the on-screen instructions to choose the existing stack to use.
Note You can only choose from existing stacks that are in the following AWS CloudFormation states.
-
CREATE_COMPLETE
-
CREATE_IN_PROGRESS
-
REVIEW_IN_PROGRESS
-
ROLLBACK_COMPLETE
-
ROLLBACK_IN_PROGRESS
-
UPDATE_COMPLETE
-
UPDATE_COMPLETE_CLEANUP_IN_PROGRESS
-
UPDATE_IN_PROGRESS
-
UPDATE_ROLLBACK_COMPLETE
-
UPDATE_ROLLBACK_COMPLETE_CLEANUP_IN_PROGRESS
-
UPDATE_ROLLBACK_IN_PROGRESS
-
-
If you want to create a new AWS CloudFormation stack with a name that you specify, then do one of the following:
-
If a hidden
.application.json
file exists in the same folder as the local version of the Lambda function, and the file contains aStackName
value, change theStackName
value in the.application.json
file to the name of the AWS CloudFormation stack you want to use, and then save the.application.json
file. -
If a hidden
.application.json
file exists in the same folder as the local version of the Lambda function, but the file does not contain aStackName
value, add aStackName
value to the beginning of the.application.json
file with the name of the new AWS CloudFormation stack you want to use, and then save the.application.json
file. For example, for a stack name ofMyDemoStack
, add the following value to the beginning of the file. (Do not type the ellipses. They are shown only to help you add the value to the correct location in the file.){ "StackName": "MyDemoStack", ... }
-
If a hidden
.application.json
file does not exist in the same folder as the local version of the Lambda function, then create a new.application.json
file in that folder, add aStackName
value to the.application.json
file with the name of the new AWS CloudFormation stack you want to use, and then save the.application.json
file. For example, for a stack name ofMyDemoStack
, add the following value to the file.{ "StackName": "MyDemoStack" }
-
To upload the code to a non-default Lambda function in your AWS account in the same
AWS Region as displayed in the Lambda section of the AWS Resources window,
add the function name as a FunctionName
value to the Properties
section of the Lambda function resource in the related
AWS SAM template file (for example, template.yaml
). For example, for a Lambda function resource named MyDemoFunction
, add a FunctionName
value of
MyDemoFunction
to upload the code to a Lambda function named MyDemoFunction
instead of cloud9-APPLICATION_NAME-FUNCTION_NAME
. (Do not type the ellipses. They are shown
only to help you add the value to the correct location in the file.)
... Resources: MyDemoFunction: Type: AWS::Serverless::Function Properties: FunctionName: MyDemoFunction ...
When you are ready to upload the code, do the following.
-
In the Lambda section of the AWS Resources window, expand the Local Functions list, if it isn't already expanded.
-
Expand the serverless application folder that contains the function you want to upload.
-
Do one of the following:
-
Right-click the serverless application folder that you just chose, and then choose Deploy.
-
Right-click the function you want to upload, and then choose Deploy.
-
Choose the function you want to upload, and then choose Deploy the selected Lambda function (the button with the arrow that faces up).
-
Convert a Lambda function to a serverless application
If the local version of an existing Lambda function in your AWS Cloud9 development
environment isn't already part
of a serverless application, you can use the AWS Cloud9 IDE to convert that function
into a
serverless application. You can then use the AWS SAM template file for that serverless
application to create additional supporting AWS resources for your function. For more
information, see the AWS Serverless Application Model (AWS SAM)
To convert the local version of an existing Lambda function into a serverless application, you must first import the remote version of the function into your AWS Cloud9 development environment, if the function isn't already there. See Import a Lambda function.
-
In the Lambda section of the AWS Resources window, expand the Local Functions list, if it isn't already expanded.
-
Right-click the function you want to convert, and then choose Convert to SAM.
AWS Cloud9 does the following:
-
In the function's folder in the Environment window, the
DeploymentMethod
setting in the.application.json
file changes fromlambda
tocloudformation
. This means that now AWS Cloud9 will instruct AWS SAM to use AWS CloudFormation whenever you use the IDE to upload the function's code as part of the serverless application. (lambda
means that AWS Cloud9 will instruct Lambda to deploy the function instead.) To upload the function code, see Upload code for a Lambda function. -
In the Lambda section of the AWS Resources window, in the Local Functions list, AWS Cloud9 adds the existing Lambda function to a new serverless application (represented by a Lambda icon inside of a folder). The serverless application has the same name as the function.
When you upload the function's code as described in Upload code for a Lambda function, because the function upload method is no longer Lambda but now AWS SAM using AWS
CloudFormation, AWS Cloud9 creates a new remote version of the function in Lambda
and adds it to the Remote Functions list.
AWS Cloud9 gives the remote version a name that is different from the original Lambda
function. For example,
if the serverless application and the function are both named myDemoFunction
, the remote version
name of your function would be cloud9-myDemoFunction-myDemoFunction-RANDOM_ID
,
where RANDOM_ID
is a randomly determined ID.
After you do the conversion, if you then use the IDE to make any changes to the function
code and then upload that code to Lambda,
only the remote version of the new function (for example, cloud9-myDemoFunction-myDemoFunction-RANDOM_ID
) will contain the change. The remote version of the original function (for example,
myDemoFunction
) will not change.
If you change your mind and want to enable the IDE to go back to uploading your code
changes to the remote version of the original function (for example, myDemoFunction
), do the following:
-
In the function's folder in the Environment window, change the
DeploymentMethod
setting in the.application.json
file fromcloudformation
back tolambda
, and then save the file. This removes the serverless application folder from the Local Functions list and causes AWS Cloud9 to go back to instructing Lambda to deploy the function. -
Upload the function code as described in Upload code for a Lambda function. Now, only the remote version of the original function (for example,
myDemoFunction
) will contain the change. The remote version of the new function (for example,cloud9-myDemoFunction-myDemoFunction-RANDOM_ID
) will not change. -
Because AWS Cloud9 will no longer upload code changes to the remote version of the new function (for example,
cloud9-myDemoFunction-myDemoFunction-RANDOM_ID
), if you want you can use the Lambda console to delete the new function (for example,cloud9-myDemoFunction-myDemoFunction-RANDOM_ID
).
Update configuration settings for a Lambda function
You can use the AWS Cloud9 IDE to change function settings such as the description, handler identifier, amount of memory the function will use, and existing execution role the function will use.
To change configuration settings, you must first import the related remote version of the function into your AWS Cloud9 development environment, if the function isn't already there. To do this, see Import a Lambda function. Then do the following.
-
In the Lambda section of the AWS Resources window, expand the Local Functions list, if it isn't already expanded.
-
Expand the serverless application folder that contains the function whose setting you want to change.
-
Right-click the function, and then choose Edit Config.
-
Make changes to the configuration settings, and then save the file.
Note By default, configuration settings are displayed in plain text. To change this behavior to display configuration settings in a visual editor by default, choose AWS Cloud9, Preferences on the menu bar. Choose AWS Settings, and then turn on Use AWS SAM visual editor. To use the visual editor, close the function's
template.yaml
file, and then right-click the function and choose Edit Config again. To switch back to using plain text by default, turn off the Use AWS SAM visual editor setting. To temporarily edit plain text, choose View with text editor (Ace) in the visual editor, and then choose View, Editors, Ace on the menu bar. -
Do one of the following:
-
On the configuration settings tab, in the simplified settings view, choose the Upload Settings to Lambda button.
-
Follow the instructions in Upload code for a Lambda function.
-
Delete a Lambda function
You can delete the local version of a Lambda function from your environment, delete the remote version of the function from Lambda, or both, as follows.
Topics
Delete the local version of a Lambda function
Use the Environment window in the AWS Cloud9 IDE to delete the directory that contains the function. (You cannot use the Lambda section of the AWS Resources window in the AWS Cloud9 IDE to delete the local version of a Lambda function.)
If you accidentally delete the local version of a Lambda function, the only way to add it back to your environment is to import the remote version of the function into your environment, if the remote version still exists. For instructions, see Import a Lambda function.
Delete the remote version of the Lambda function
To delete the remote version of the Lambda function, use the Lambda console, the AWS CloudFormation console, or code. (You cannot use the Lambda section of the AWS Resources window in the AWS Cloud9 IDE to delete the remote version of a Lambda function.)
To determine which approach to use to delete the remote version of a Lambda function,
in the AWS Cloud9 IDE, open the .application.json
file that is in the same directory
as the local version of the Lambda function. If the
DeploymentMethod
value is set to lambda
, you use Lambda to delete the function. If the DeploymentMethod
value is set to cloudformation
,
you should use AWS CloudFormation to delete the function.
If the DeploymentMethod
value is set to cloudformation
in the .application.json
file, we do not recommend using Lambda to delete the function. If you
use Lambda instead of AWS CloudFormation to delete the function in this case, then
you might leave some associated AWS resources still remaining. Those remaining resources
could result in ongoing
charges to your AWS account.
Topics
Use Lambda to delete the remote version of the function
Use the Lambda console or code to delete the function that has the same name as the
function in the
Lambda section of the AWS Resources window or the PhysicalId
value in the .application.json
file, as follows.
When you delete the remote version of a function, it is permanently deleted from Lambda. If you accidentally delete the remote version of a function and need to recover it, you can upload the local version of the function to Lambda, if the local version still exists. For instructions, see Upload code for a Lambda function.
-
To delete the function by using the Lambda console, do the following.
-
Open the Lambda console, at https://console.aws.amazon.com/lambda
. -
On the AWS navigation bar, if the AWS Region that contains the Lambda function is not displayed, then choose it.
-
If the list of functions is not displayed, then choose Functions in the service navigation pane.
-
Do one of the following.
-
Choose the radio button next to the name of the function that you want to delete. Then choose Actions, Delete. Confirm the deletion by choosing Delete.
-
Choose the name of the function that you want to delete. Then choose Actions, Delete Function. Confirm the deletion by choosing Delete.
-
-
-
To delete the function by using code, call the Lambda delete function operation, as follows.
AWS CLI
AWS SDK for C++
AWS SDK for Go
DeleteFunction, DeleteFunctionRequest, DeleteFunctionWithContext
AWS SDK for Java
AWS SDK for JavaScript
AWS SDK for .NET
AWS SDK for PHP
AWS SDK for Python (Boto)
AWS SDK for Ruby
AWS Tools for Windows PowerShell
Lambda API
Use AWS CloudFormation to delete the remote version of the function
Use the AWS CloudFormation console or code to delete the stack that has the same name
as
the StackName
value in the .application.json
file, as follows.
When you delete a stack, AWS CloudFormation deletes all AWS resources that are associated with that stack. This includes not only Lambda functions but could also include other related resources such as APIs in Amazon API Gateway. If you accidentally delete the remote version of a function and need to recover it, you can upload the local version of the function from the AWS Cloud9 IDE to Lambda, if the local version still exists. For instructions, see Upload code for a Lambda function. All of the stack's other resources are permanently deleted and cannot be recovered.
-
To delete the stack by using the AWS CloudFormation console, do the following.
-
Open the AWS CloudFormation console, at https://console.aws.amazon.com/cloudformation
. -
On the AWS navigation bar, if the AWS Region that contains the stack is not displayed, then choose it.
-
In the list of stacks, do one of the following.
-
Select the check box next to the name of the stack that you want to delete. Then choose Actions, Delete Stack. Confirm the deletion by choosing Yes, Delete.
-
Choose the name of the stack that you want to delete. Then choose Other Actions, Delete Stack. Confirm the deletion by choosing Yes, Delete.
-
-
-
To delete the stack by using code, call the AWS CloudFormation delete stack operation, as follows.
AWS CLI
AWS SDK for C++
AWS SDK for Go
AWS SDK for Java
AWS SDK for JavaScript
AWS SDK for .NET
AWS SDK for PHP
AWS SDK for Python (Boto)
AWS SDK for Ruby
AWS Tools for Windows PowerShell
AWS CloudFormation API