AWS released a GitHub Action for Lambda function deployment
Introduction
Last week, AWS officially released an action for AWS Lambda deployment provided by the official AWS organization aws-actions.
Until now, to deploy Lambda functions with GitHub Actions, it was necessary to implement your own processes using AWS CLI or incorporate third-party deployment actions.
In terms of simplifying Lambda function deployment, using the AWS SAM CLI is also an option, but this requires using SAM templates for function configuration, which demands additional knowledge. If you don't want to expose these settings to application developers, you need the extra step of placing them elsewhere and retrieving them.
With the newly provided action, you can deploy while hiding Lambda function information from developers by configuring only the minimum necessary information.
One of its attractions is that by specifying optional parameters, you can flexibly update only specific parameters, allowing you to control which aspects are managed by the application side.
If maximized, it's possible to create functions themselves without requiring as much prior knowledge as SAM, making it suitable for quickly setting up and managing everything when needed.
Implementation
I've set up sample code below. I'm using the application code that was initially generated with SAM as is.
├── .github
│ └── workflows
│ └── deploy.yml
├── hello_world
│ ├── __init__.py
│ ├── app.py
│ └── requirements.txt
├── README.md
└── templates
└── iam.yml ## CloudFormation template for creating IAM roles for GitHub Actions and Lambda functions
Besides the application code and deployment workflow, you'll need roles for executing the Lambda function and for GitHub Actions to use.
For this sample, I've placed everything in the same repository, but if you don't want to show it to application developers, it's better to place it in a separate repository and pass the role ARNs via Secrets to properly separate concerns.## Workflow File Excerpt
Here is an excerpt from the deployment workflow file of the repository that will be the focus of this discussion.
Currently (v1.0.1), aws-actions/aws-lambda-deploy only has the functionality to deploy the specified file as is, so you need to separately write the switch role process for the role used for deployment (in this case using aws-actions/configure-aws-credentials@v4) and the application build process.
This might be somewhat troublesome, but it offers high flexibility in terms of reusing existing build processes and incorporating procedures that comply with organizational policies.
name: Deploy
on:
workflow_dispatch: {}
permissions:
id-token: write
contents: read
defaults:
run:
working-directory: "./hello_world"
env:
PYTHON_VERSION: 3.13
function-name: sample-actions-deploy-function
jobs:
main:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Setup python
uses: actions/setup-python@v5
with:
python-version: ${{ env.PYTHON_VERSION }}
- name: Build
run: pip install -r requirements.txt
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: ${{ secrets.deploy-role }}
aws-region: ap-northeast-1
- name: Deploy
uses: aws-actions/aws-lambda-deploy@v1.0.1
with:
function-name: ${{ env.function-name }}
## Explicitly specified because it was being evaluated relative to the repository root, not the working-directory
code-artifacts-dir: ./hello_world
handler: app.lambda_handler
runtime: python${{ env.PYTHON_VERSION }}
role: ${{ secrets.LAMBDA_ROLE_ARN }}
The required parameters for aws-actions/aws-lambda-deploy are only the target function name (function-name), the root directory location of the files to be deployed (code-artifacts-dir), the handler name to be executed when called (handler), and the function runtime (runtime).
To make preparation easier this time, we've included the role specification (role) used by the Lambda function, but this is only required if you want to create a function with this action; otherwise, it's optional.
(If not specified and the function doesn't exist at runtime, it will fail with a Not Found status)
Function configuration will be updated using the UpdateFunctionConfiguration API if configuration values differ from the deployed Lambda function's configuration.
As a first step, GetFunctionConfiguration is called to perform a diff between the provided configuration parameters and the configuration of the currently deployed function. If there is no change, UpdateFunctionConfiguration will not be called.
For Lambda function configuration updates, only parameters specified in the with section that differ from the actual function will be updated, so you can include parameters you want to manage in your application here, and omit those you don't want to be touched.
Since IAM roles cannot control update permissions at the parameter level, administrator review before merging may be insufficient. If you need to strictly ensure that unnecessary parameters are not added, you would need to implement additional measures such as incorporating pre-merge verification processes.
In addition to various Lambda function configuration values, parameters that can be specified with with include options that enable uploading through S3 rather than direct ZIP uploads. Please refer to the following link for more details.
https://github.com/aws-actions/aws-lambda-deploy/tree/main## Execution
The execution itself doesn't involve anything special as it's just running the workflow, but the log from aws-actions/aws-lambda-deploy is as follows.
When S3 path is not specified, the internal process appears to copy files to the working directory before compressing them into a ZIP and uploading.
Run aws-actions/aws-lambda-deploy@v1.0.1
Setting custom user agent: LambdaGitHubAction/1.0.0
Checking if sample-actions-deploy-function exists
Packaging code artifacts from ./hello_world
Copying artifacts from /home/runner/work/sample-deploy-lambda-action/sample-deploy-lambda-action/hello_world to /tmp/lambda-temp-1755073961919
Found 3 files/directories to copy
Copying /home/runner/work/sample-deploy-lambda-action/sample-deploy-lambda-action/hello_world/__init__.py to /tmp/lambda-temp-1755073961919/__init__.py
Copying /home/runner/work/sample-deploy-lambda-action/sample-deploy-lambda-action/hello_world/app.py to /tmp/lambda-temp-1755073961919/app.py
Copying /home/runner/work/sample-deploy-lambda-action/sample-deploy-lambda-action/hello_world/requirements.txt to /tmp/lambda-temp-1755073961919/requirements.txt
Creating ZIP file with standard options
Adding file: __init__.py
Adding file: app.py
Adding file: requirements.txt
Writing ZIP file with standard options
Generated ZIP file size: 712 bytes
ZIP verification passed - contains 3 entries:
1. __init__.py (0 bytes)
2. app.py (886 bytes)
3. requirements.txt (8 bytes)
Getting current configuration for function sample-actions-deploy-function
Updating function configuration for sample-actions-deploy-function
Waiting for function update to complete. Will wait for 5 minutes
Function update completed successfully
Updating function code for sample-actions-deploy-function with /tmp/lambda-function-1755073961919.zip
Original buffer length: 712 bytes
Lambda function deployment completed successfully
This shouldn't be an issue for small projects like this sample, but for something like nodejs projects which tend to have many small files, the "copying" step could take significant time.
If this becomes a concern, it might be better to implement your own ZIP processing and S3 upload before deployment.## In Conclusion
This time, I tried using the new Lambda function deployment action officially provided by AWS.
Personally, for verification work or hobby systems, I feel that SAM, which can manage infrastructure together, is more user-friendly since it handles various things nicely for you.
Since this action focuses only on code updates (+ some configuration changes), I think it would be useful in situations where you need flexibility - such as when you want to separate the management boundaries of larger-scale infrastructure and applications, or when you need to write custom processes to align with organizational policies.
