CI/CD

Aliases, versions, traffic shifting, blue/green. Plain CLI → SAM → CDK → Terraform.

Versions and aliases

Versions are immutable snapshots of a function's code and configuration. When you publish a version (aws lambda publish-version), AWS creates an immutable ARN like arn:…:function:my-fn:7. $LATEST is the only mutable version — always reflects the most recent code upload.

Aliases are named pointers to a version. prod might point to version 7; staging might point to version 8. Event source mappings, API Gateway integrations, and Step Functions tasks should target aliases, not version ARNs — this decouples deployment (publishing a new version) from promotion (updating the alias).

Traffic shifting (blue/green)

An alias can split traffic across two versions with weighted routing:

aws lambda update-alias \
  --function-name my-fn \
  --name prod \
  --function-version 8 \
  --routing-config AdditionalVersionWeights={"7"=0.9}
# result: 10% of prod traffic goes to v8, 90% still to v7

Start at 10% canary, watch error rates in CloudWatch, shift to 50%, then 100%. Rollback is instant: point the alias back to the stable version. No instance drain, no connection draining — Lambda is stateless, cutover is atomic.

CodeDeploy integration

SAM and CDK can wire up CodeDeploy for automatic traffic shifting with automatic rollback on CloudWatch alarms. You declare the deployment preference in the template:

# SAM template.yaml
DeploymentPreference:
  Type: Canary10Percent5Minutes   # 10% for 5 min, then 100%
  Alarms:
    - !Ref ErrorRateAlarm          # rolls back if alarm triggers

CodeDeploy manages the alias weight changes and calls the rollback if the alarm fires — fully automated blue/green without manual traffic management.

Deployment tooling progression

Tool	Good for	Caveats
AWS CLI / SDK	One-off deployments, scripting, deep control	Verbose; no state management; drift-prone at scale
SAM (CloudFormation extension)	Lambda-first projects; built-in local testing; CodeDeploy integration	CloudFormation speed; YAML verbosity; AWS-only
CDK	Complex infra in TypeScript/Python; reusable constructs; type safety	Still compiles to CloudFormation; learning curve; bootstrapping required
Terraform (AWS provider)	Multi-cloud orgs; large existing Terraform estate; strong community modules	No built-in Lambda local testing; plan/apply cycle slower than SAM deploy
Serverless Framework	Multi-cloud serverless; plugin ecosystem	V3 → V4 became paid for teams; community plugins vary in quality

CI pipeline skeleton

# GitHub Actions example
jobs:
  deploy:
    steps:
      - uses: actions/checkout@v4
      - name: Build zip
        run: |
          docker run --rm -v $PWD:/var/task \
            public.ecr.aws/lambda/python:3.13 \
            pip install -r requirements.txt -t package/
          cd package && zip -r ../function.zip . && cd ..
          zip function.zip lambda_function.py
      - name: Deploy
        run: |
          aws lambda update-function-code \
            --function-name my-fn --zip-file fileb://function.zip
          aws lambda wait function-updated --function-name my-fn
          aws lambda publish-version --function-name my-fn
          aws lambda update-alias --function-name my-fn \
            --name prod --function-version $VERSION

The wait function-updated call is important — update-function-code is asynchronous and publish-version must wait for it to complete.

3.5 KiB Raw Blame History