This repository and layer is no longer receiving updates or support. I've been too busy to keep up with changes in the Lambda environment and this has fallen behind. Use at your own risk.
Run Bash in AWS Lambda via Layers. This Layer is 100% Bash and handles all communication with the Lambda Runtime API. This allows you to run full Bash scripts and commands inside of AWS Lambda. This Layer also includes common CLI tools used in Bash scripts.
See the How To section to understand how to use these layers. Also see the example-basic.sh file for an example of how to write a Bash script compatible with this Layer.
arn:aws:lambda:<region>:744348701589:layer:bash:8
Use custom runtime in function code or layer
. Layers
box.Add a layer
. Provide a layer version ARN
option, then copy/paste the Layer ARN for your region.Add
button.Save
in the upper right.provided
runtime and the Layer ARN for your region.$ aws lambda create-function \
--function-name bashFunction \
--role bashFunctionRole \
--handler index.handler \
--runtime provided \
--layers arn:aws:lambda:<region>:744348701589:layer:bash:8 \
--zip-file fileb://function.zip
Layers
box.Add a layer
. Provide a layer version ARN
option, then copy/paste the Layer ARN for your region.Add
button.Remove
.Save
in the upper right.$ aws lambda update-function-configuration \
--function-name bashFunction \
--layers arn:aws:lambda:<region>:744348701589:layer:bash:8
Like any other Lambda function code, your main script's name must match the first part of your handler. Inside your main script, you must define a function that matches the second part of the handler. You must have set -e
be the first line inside your function. Putting #!/bin/bash
at the top of your file is not necessary. So if your Lambda handler is index.handler
, your file and contents should look like:
$ cat index.sh
handler () {
set -e
...
}
The event
data is sent to your function as the first parameter. To access it, you should use $1
. So if you need the event
data, you should set it to a variable. For example, EVENT_DATA=$1
.
handler () {
set -e
EVENT_DATA=$1
}
All the pre-installed tools are already in your $PATH
so you can use them as expected. Any command output is automatically sent to CloudWatch, just like normal Lambda functions.
handler () {
set -e
EVENT_DATA=$1
aws s3 ls $(echo $EVENT_DATA | jq ."bucket")
}
If you need to send a response back, you should send the response to stderr
. (see the Caveats section for an explanation) To send output to stderr
you should use >&2
. This will be picked up and returned from the Lambda function.
handler () {
set -e
EVENT_DATA=$1
aws s3 ls $(echo $EVENT_DATA | jq ."bucket")
echo "{\"success\": true}" >&2
}
Bash behaves in ways unlike other programming languages. As such, there are some requirements on the user's end that must be done.
set -e
must be set inside your function
By default, a bash script won't exit when it encounters an error. In order for the layer to correctly catch the error and report it (as well as stop the script from executing), we must set the function to exit on error.
You must send your return value to stderr
Inside a normal Bash function, anything that is sent to stdout
is part of the return value for that function. In order to properly capture the user's return value and still send stdout
to CloudWatch, this Layer uses stderr
as the return value. To send something to stderr
simply append >&2
to the end of the command. See the example scripts for help.
$HOME
is set to /tmp
. This is because the Lambda filesystem is read-only except for the /tmp
directory. Some programs require $HOME
to be writeable (like the AWS CLI and some SSH commands), so this allows them to work without issue.
Files to configure the AWS CLI should be put in /tmp/.aws
. By default, the CLI uses the same region and IAM Role as your lambda function. If you need to set something different, you can use the /tmp/.aws/config
and /tmp/.aws/credentials
files accordingly.
When using curl, you should use the -s
flag. Without the silent flag, curl will send the progress bar of your request to stderr
. This will show up in your response. So it's usually best to disable the progress bar.
The AWS CLI appears to be much slower than most of the AWS SDKs. Take this into consideration when comparing Bash with another language and evaluating execution times.
If a command is logging unwanted messages to stderr
that are being picked up in your response, you can see if there is something similiar to a --silent
flag. If there is not, you can remove the messages to stderr
by redirecting to /dev/null (2>/dev/null
) or redirecting stderr
to stdout
for that command (2>&1
) to send them to CloudWatch.
With this method there is no context
in the function, only event
data. The event
data is sent to your function as the first parameter. So to access the event
data, use $1
, for example EVENT_DATA=$1
. In order to give some details that were availabe in the context
, I export a few additional variables.
AWS_LAMBDA_REQUEST_ID
- AWS Lambda Request ID
AWS_LAMBDA_DEADLINE_MS
- Time, in epoch, that your function must exit by
AWS_LAMBDA_FUNCTION_ARN
- Full AWS Lambda function ARN
AWS_LAMBDA_TRACE_ID
- The sampling decision, trace ID, and parent segment ID of AWS XRay
To build a layer, simply run make build
. This will create a zip archive of the layer in the export/
directory.
To publish the layer to the public, simply run make publish
. This will create a new version of the layer from the export/layer.zip
file (create from the Build step) and give it a global read permission.
Some executables are able to run by themselves and some require additional dependencies that are present on the server. It's hard to cover here case here, but if the executable run by itself it can easily be added. If it has dependencies, you must explore what those dependencies are and how to add them to the layer as well.
You can either add the executable from an Amazon Linux AMI or from the lambci/lambda:build-python3.6 Docker image.
Disclaimer: I usually don't add in executables from pull requests for security reasons. If you would like to see an executable in this layer make an issue and I'll try to add it.
$ aws
$ bc
$ git
$ jq
$ rsync
$ scp
$ sftp
$ ssh
$ sshpass
$ time
$ traceroute
$ tree
$ wget
$ vim
$ zip
$ unzip
Already included in the Lambda environment:
$ awk
$ cat
$ curl
$ cut
$ date
$ diff
$ grep
$ gzip
$ head
$ md5sum
$ pwd
$ sed
$ tar
$ tail
$ tee
$ xargs
If you would like to see more, please create an issue.
Shout-out to the LambCI team for their work on lambci/git-lambda-layer which some of the git
and ssh
build process was taken from.