I have a /catalogue API running on AWS Lambda, currently using version v1 behind API Gateway. As part of my CI/CD pipeline, I publish the OpenAPI definition and Lambda deployment package to Amazon S3. I want to release a new Lambda version, v2, while keeping the API available and minimizing risk during the transition. What deployment pattern should I use to move traffic from v1 to v2 smoothly?
3 Answers
A typical CI/CD sequence is: build the Lambda package, deploy it, publish an immutable Lambda version, send a small percentage of traffic to it, monitor CloudWatch metrics, and then continue with larger traffic shifts. You can add manual approval gates between stages—for example, 10%, 50%, and finally 100%. Once v2 is fully validated, make it the alias target and retain v1 temporarily for quick rollback.
For a safer rollout, use a canary deployment. Publish v2, keep the production alias pointed at v1, and gradually shift a small percentage of alias traffic to v2. Monitor errors, latency, throttles, and business metrics before increasing the percentage. If anything looks wrong, roll the alias traffic back to v1.
Publish the new Lambda code as a numbered version, then point an alias such as ACTIVE_VERSION at the version you want serving production traffic. Configure API Gateway to invoke the alias rather than an unqualified Lambda function. Your pipeline can deploy v2, validate it, and then update the alias from v1 to v2 without changing the API Gateway integration or causing downtime.
That makes sense—I had missed that API Gateway should target the alias instead of the function directly. Thanks!
A canary is especially useful here because it limits the number of users affected if the new version has a problem.