2.1.1.3. Lambda Deployment and Versioning
2.1.1.3. Lambda Deployment and Versioning
First Principle: Lambda deployments enable agile updates, while versioning and aliases ensure controlled rollouts and safe testing of new application code in production.
Lambda's versioning model lets you deploy updates safely ā but only if you understand the relationship between $LATEST, versions, and aliases.
When you update a function, you're editing $LATEST ā a mutable working copy. This is fine for development, but production should never point to $LATEST because any update immediately affects all callers. Instead, publish a version to create an immutable snapshot of your code and configuration. Version 1, version 2, version 3 ā each is frozen and gets its own ARN.
Aliases are the key abstraction. An alias like PROD points to a specific version (say, version 5). Your API Gateway integration points to the alias, not the version. When you deploy version 6, you update the alias ā and if something breaks, you point the alias back to version 5 instantly, without redeploying any code.
The real power comes with weighted aliases for traffic shifting. Instead of sending 100% of traffic to version 6, you send 10% (canary) and monitor errors. If CloudWatch alarms trigger, CodeDeploy automatically rolls back the alias. This is the Lambda deployment pattern the exam tests most heavily ā understand that traffic shifting requires aliases, not direct version references.
Scenario: You've developed a new version of your Lambda function and want to deploy it to production. You need to test it with a small percentage of user traffic first before a full rollout, and have the ability to quickly revert if issues arise.
ā ļø Exam Trap: A Lambda version is immutable ā you can't change its code or configuration. An alias points to a version and CAN be updated. Traffic shifting between versions requires aliases, not direct version references.
