GitHub Actions + Terraform CI/CD for AWS Lambda with OIDC
My GitHub Actions pipeline for AWS Lambda and Terraform: OIDC deploys with no stored AWS keys, S3 state locking, a prod approval gate, and alias rollback.
Automated Deployment
Pipelines that build, test, and ship, without a checklist in someone's head.
What I do
Build and test on the pull request
A pull request builds and tests before anyone merges it.
Staging and production, same pipeline
The same pipeline ships to staging and production. No one retypes the steps.
Fix the slow pipeline first
If the pipeline is slow or flaky, I fix that before I add more stages.
What you get
The tools you already run
I use the CI you already have when it can do the job.
A pipeline for this repo
The stages match how this app is built, tested, and shipped.
Checks before production
Secrets stay out of the log, and a known-bad dependency fails the build.
From the notebook to production
The pipeline should still be obvious when a second service shows up.
How the work goes
Watch one release
I watch one release from commit to production and write down the manual steps.
Stages and a rollback
You get the stages, the checks, and where a rollback happens.
A real deploy
I wire it into the repo and run a real deploy, not a demo.
Notes next to the pipeline
I walk the team through a release and leave the notes next to the pipeline.
Tools I use
These show up when they fit the job.
Jenkins
GitLab CI
GitHub Actions
CircleCI
Travis CI
AWS CodePipeline
Azure DevOps
Docker
Kubernetes
Ansible
TerraformJenkinsGitLab CIGitHub ActionsCircleCITravis CIAWS CodePipelineAzure DevOpsDockerKubernetesAnsibleTerraformSituations I get called in for
Deploys run from one laptop
One person runs the deploy from their machine, with credentials only they have. When they're away, nothing ships. I move the deploy into the pipeline so anyone on the team can run it.
Nobody ships on Friday
A bad release takes hours to undo, so the team avoids releasing late in the week. I make rollback a step in the pipeline, and the team runs it once before they need it.
The pipeline is too slow to wait for
People batch changes because each run takes too long. I look at dependency caching, Docker layer order, test splitting, and which steps really need to run on every commit.
A migration breaks the release
The deploy fails halfway because new code expects a column that isn't there yet. I split schema changes so the old and new code can both run while the release rolls out.
What I check first
One artifact, promoted
Whether staging and production get the same build. If production rebuilds from source, what you tested is not what you shipped. I build one image, tag it with the commit SHA, and promote it.
How the pipeline gets cloud access
GitHub Actions and GitLab CI can both use OIDC to assume an AWS IAM role. Then there are no long-lived access keys sitting in CI secrets.
What counts as healthy
ECS, Kubernetes, and load balancers all decide on health checks. If the check only returns 200 from a static route, a broken release looks fine.
The way back
How to redeploy the previous image tag, and whether the migration that shipped with it can be reversed or has to roll forward.
Tests that fail at random
A flaky test teaches the team to hit rerun. Then a real failure gets rerun too. I fix or quarantine those before adding new stages.