AWS Lambda Versioning and Aliases
Jun 08, 2023 • 6 Minute Read
As I detailed in a previous blog post, I’m continuing to update the Linux Academy AWS DevOps Pro certification course. The course has three new sections (and Lambda Versioning and Aliases plays an important part in the Lambda section):
The screenshot above shows the Lambda management console with a newly created Lambda function. By clicking the ‘Qualifiers’ dropdown, we are presented with the Versions for our Lambda function and the Aliases (which we will talk about momentarily). Now if we want to publish a new version of our Lambda function, we would simply make the changes we want to the function, go to the ‘Actions’ dropdown and select ‘Publish new version’:
Now at this point you might be thinking that the $Latest version and your new version (version 1) would be the same. You would be correct. But remember, only the $Latest version can be changed. So when you decide you need a second version, you would make changes to $Latest and then publish that new version (version 2). Your latest version will then match version 2 until you decide to make further changes to your $Latest version. In this way, you can create as many versions as you like and all your numbered versions will be different from each other. Let’s assume that version 3 is our Prod version. We have identified a change that needs to be made in our code. We would then make the updates to $Latest and publish a new version. This new version could initially be in our dev environment. We don’t want to dump it right out to prod and hope for the best. We could do some testing on it in dev, move it to beta, test some more, and then finally move it out to our prod environment.Lambda AliasesNow we also saw in the Lambda console that there is support for aliases. What can we do with aliases? AWS Lambda supports creating aliases for each of your Lambda function versions. The alias is simply a pointer to a specific Lambda function version. Each alias also has a unique ARN. One key difference between aliases and functions is that you can change aliases. You can change aliases to point to different versions of your functions. Think about the power at your hands with that capability! If you have a prod alias, for example, you can change that alias to point to a different version of your function. That function magically becomes your prod function just by pointing the prod alias to it. It’s a little more complicated than that, but not too much. Remember, all Lambda functions need an event source, whether it be an S3 bucket, an API, a DynamoDB table or any other event source. Let’s assume that we are working directly with our Lambda function. So in our event source (S3 bucket for example), you identify the Lambda function ARN that S3 can invoke (an example invocation would be uploading a file to S3 trigger Lambda function). The problem is that our Lambda function versions are immutable! So every time we promote a version to prod, we have to go to S3 and enter the new ARN. So how can we abstract the process of promoting Lambda functions, so that we don’t have to change our invocation settings in S3 every time? We can use aliases! In S3, we can enter the alias ARN for our prod alias. If we have a new version for our Lambda function that we want to be our prod version, so what! We can change our prod alias in Lambda to point to the new version. The configuration in S3 never has to be touched. Prod will always be prod. Whatever function we point our prod alias to will be our prod function.So that’s a look at how we can use Lambda function versions and aliases to simplify and streamline our function deployment process. The easier and more flexible this process, the less prone to error it becomes. I have been updating my AWS DevOps Professional Certification course and Lambda versioning and aliases is one of the new areas of focus. But there is much more that has been added and updated, so check out the updated AWS Certified DevOps Engineer - Professional Level course here!
- Deployment Pipelines
- AWS Lambda, and
- AWS API Gateway
The screenshot above shows the Lambda management console with a newly created Lambda function. By clicking the ‘Qualifiers’ dropdown, we are presented with the Versions for our Lambda function and the Aliases (which we will talk about momentarily). Now if we want to publish a new version of our Lambda function, we would simply make the changes we want to the function, go to the ‘Actions’ dropdown and select ‘Publish new version’:
Now at this point you might be thinking that the $Latest version and your new version (version 1) would be the same. You would be correct. But remember, only the $Latest version can be changed. So when you decide you need a second version, you would make changes to $Latest and then publish that new version (version 2). Your latest version will then match version 2 until you decide to make further changes to your $Latest version. In this way, you can create as many versions as you like and all your numbered versions will be different from each other. Let’s assume that version 3 is our Prod version. We have identified a change that needs to be made in our code. We would then make the updates to $Latest and publish a new version. This new version could initially be in our dev environment. We don’t want to dump it right out to prod and hope for the best. We could do some testing on it in dev, move it to beta, test some more, and then finally move it out to our prod environment.Lambda AliasesNow we also saw in the Lambda console that there is support for aliases. What can we do with aliases? AWS Lambda supports creating aliases for each of your Lambda function versions. The alias is simply a pointer to a specific Lambda function version. Each alias also has a unique ARN. One key difference between aliases and functions is that you can change aliases. You can change aliases to point to different versions of your functions. Think about the power at your hands with that capability! If you have a prod alias, for example, you can change that alias to point to a different version of your function. That function magically becomes your prod function just by pointing the prod alias to it. It’s a little more complicated than that, but not too much. Remember, all Lambda functions need an event source, whether it be an S3 bucket, an API, a DynamoDB table or any other event source. Let’s assume that we are working directly with our Lambda function. So in our event source (S3 bucket for example), you identify the Lambda function ARN that S3 can invoke (an example invocation would be uploading a file to S3 trigger Lambda function). The problem is that our Lambda function versions are immutable! So every time we promote a version to prod, we have to go to S3 and enter the new ARN. So how can we abstract the process of promoting Lambda functions, so that we don’t have to change our invocation settings in S3 every time? We can use aliases! In S3, we can enter the alias ARN for our prod alias. If we have a new version for our Lambda function that we want to be our prod version, so what! We can change our prod alias in Lambda to point to the new version. The configuration in S3 never has to be touched. Prod will always be prod. Whatever function we point our prod alias to will be our prod function.So that’s a look at how we can use Lambda function versions and aliases to simplify and streamline our function deployment process. The easier and more flexible this process, the less prone to error it becomes. I have been updating my AWS DevOps Professional Certification course and Lambda versioning and aliases is one of the new areas of focus. But there is much more that has been added and updated, so check out the updated AWS Certified DevOps Engineer - Professional Level course here!