Why you probably don't want to use AWS' new GitHub Actions Lambda Deployment

AWS Lambda has always had a Developer Experience (DX) problem. I called it out when I first wrote about serverless 9 years ago, and while better today in 2025 it’s still not solved. AWS have now released a custom Action for GitHub Actions that they say makes things easier. I’m here to tell you it doesn’t, and that you probably don’t want to use it.

Why Lambda deployment is a pain

The main problem for Lambda deployment is that the zero-to-production experience is complicated - especially in comparison with other platforms that have grown up since. But the issue isn’t really Lambda - it’s AWS in general. AWS are great at providing “cloud lego bricks”, but it’s up to you to figure out which ones go together, and how to align them just-so.

Specifically with Lambda the problem has been that in all but the most trivial cases you don’t just need to deploy a Lambda Function, you need to deploy other things too. So what you end up actually deploying is:

• The Lambda function configuration
• The Lambda function code
• The security role that the Lambda function uses to be able to access literally anything else in AWS
• The configuration for what is triggering the Lambda Function (e.g. API Gateway or S3)
• The permissions to allow what you want to trigger the Lambda Function to actually be able to do so

And that’s before we get on to logging, monitoring, the API Gateway configuration if you’re accessing Lambda via HTTP, etc.

Even when you’ve solved this for running from your own development machine you’ll then want to incorporate it into your test and production deployment. Most people these days drive this from a deployment automation, or “CI/CD”, tool and GitHub Actions is a common choice. So the next problem is taking your Lambda deployment, and automating it to production.

What GitHub Actions Lambda Deployment does

AWS have introduced the AWS Lambda Deploy GitHub Action, a new custom action that you can include in a GitHub Actions job. From the release notes, it “enables you to use GitHub Actions to automatically deploy Lambda functions … streamlining your continuous integration and continuous deployment (CI/CD) pipeline for serverless applications”.

What the GitHub Action does, specifically is:

• Deploys the Lambda Function configuration
• Deploys the Lambda Function code artifact

… and it does this via configuration within your GitHub Action YAML file.

Capability-wise, this is precisely the same as making a couple of calls to the AWS Lambda CLI - there’s nothing much more to the new Action than that. Although I will admit for most people it’s a little easier to read and write than shell script. But it only solves a small part of the problem.

What GitHub Actions Lambda Deployment doesn’t do

Simply put, the AWS Action doesn’t do everything else in my list above. You’re still going to need to configure and deploy roles and permissions, and you’re still going to need to deploy trigger configuration. And that’s before all the other things I skimmed!

Further, this Action doesn’t even build your Lambda function - it’s still on you to create a code artifact before running this new Action.

It also creates a unique snowflake

The other problem with deploying Lambda this way is it’s not the same way you’re going to deploy from a development environment. This problem isn’t specific to this Action, but it’s one of my rules-of-thumb for CI/CD in general - you want to put as little custom logic in your CI/CD tool’s configuration as possible, and instead rely on generic deployment tools that your CI/CD system delegates to. That way you can use the bulk of your deployment logic - which is generic to CI/CD - from any other environment, like your development machine.

If you use this new Action, however, and something goes wrong with it, you can’t just run the Action from your own machine. And further, because it’s not being run by developers on their own machine when something does change the problem won’t get caught until the workflow runs.

What to do instead

I understand why people have asked for this Action, and why AWS built it, but fundamentally it solves the wrong problem. Solving the actual Lambda DX problem requires either building a holistic abstraction on top of Lambda and all the things Lambda needs, or requires better deployment tools / frameworks.

There are people today building better abstractions, and there have been for years. But it’s not a strong area historically for AWS themselves (Amplify being the closest thing to it).

As for better deployment tools - AWS’ own SAM and CDK are much better than they used to be. Both of these tools help collapse the earlier list of needs by automatically configuring roles and upstream triggers. I’m perfectly happy using CDK for pretty much any use of Lambda these days, but I admit it’s not particularly beginner friendly. And further, lots of people are happy deploying Lambda with Terraform, Pulumi, etc.

So in the end today there’s no simple answer - you either need to look beyond AWS’ own capabilities; use a full infrastructure-as-code tool; or accept that using Lambda means getting used to all the different lego bricks. It’s fun when you know how, just try not to step on one when you start out!

Feedback + Questions

If you have any feedback or questions then feel free to email me at mike@symphonia.io, or contact me at @mikebroberts@hachyderm.io on Mastodon, or at @mikebroberts.com on BlueSky.