Deploying Serverless Functions (Lambda, Cloud Functions)
Serverless deploys ship a code package and shift an alias to the new version.
Functions-as-a-service simplify deployment to packaging code and updating a function. This lesson covers deploying AWS Lambda and Google Cloud Functions from CI, with versioning and safe traffic shifting via aliases.
The serverless deploy model
You package the function (zip or container), upload it, and publish a new version. Production traffic points at an alias; you shift the alias to the new version when ready. This makes rollback as simple as pointing the alias back.
Deploying an AWS Lambda
Update the function code, publish a version, and move the live alias:
permissions: { id-token: write, contents: read }
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
aws-region: us-east-1
- run: zip -r function.zip .
- run: |
aws lambda update-function-code --function-name app --zip-file fileb://function.zip
VERSION=$(aws lambda publish-version --function-name app --query Version --output text)
aws lambda update-alias --function-name app --name live --function-version $VERSIONWatch for these pitfalls
- Cold starts: large packages and heavy init increase first-call latency.
- Concurrency limits: a deploy under load can hit throttling.
- Config drift: keep memory, timeout, and env vars in code, not the console.
- In-flight invocations: aliases let old and new versions run briefly together.
Gradual traffic shifting
Lambda aliases support weighted routing, so you can canary a new version by sending it a small percentage of traffic before fully shifting.
Key takeaways
- Serverless deploys publish a version and shift an alias to it.
- Alias-based routing makes rollback and canary traffic shifting simple.
- Watch cold starts, concurrency limits, and config drift.