Please point me to the documentation where AWS defines $LATEST of the lambda version, or suggest that it is how AWS uses a terminology without defining it.
Clearly AWS lambda documents say $LATEST is a version.
AWS Lambda Function Versions
If you haven't published a version of the selected function, the Versions panel lists only the $LATEST version.
Initially I thought it is like HEAD tag pointing to the latest commit in a Git branch. Git commit is immutable, but lambda version is not.
AWS Lambda Function Versions
A version can be published one which is persistent.
The system creates a new version of your Lambda function each time that you publish the function. ... When you publish a version, the code and most of the settings are locked to ensure a consistent experience for users of that version.
But also it can be unpublished that can be changed and saved.
You can change the function code and settings only on the unpublished version of a function.
So I guess is, since I could not find the definition by AWS, that $LATEST is a temporary snapshot of code+runtime+setting which someone has saved at some point in an AWS account, and has not yet been updated and saved.
I suppose it is like work-in-progress transient artifact in a local git repository. We would not know what the code is because someone may be saving it, and we never know what we are executing if we do not use a published, hence immutable, version as the qualifier at invocation.
And personally believe a version should be immutable. It should not be mutable like Lambda $LATEST. Version 1 as of March 19 3PM or version 1 as of March 20 1PM do not make any sense to me. Version 1 must be unique. If change is made, the it must be version 1.1 or 2.0.
Invoke
POST /2015-03-31/functions/FunctionName/invocations?Qualifier=Qualifier HTTP/1.1
Please advise if this is correct understanding, and we should not use $LATEST for invocation unless only one person is working on and testing.
And if it is so, I suppose having $LATEST serves no practical purpose in a proper engineering where we should be able to consistently identify a revision of a code and reproduce the same result if we re-do the same procedure on the revision.
Update
Currently I believe my confusion was because of the inconsistent and possibly wrong naming by AWS.
Version is immutable if published but mutable if not published in which case called $LATEST.
Version can be a snapshot of a lambda function but it can be a integer number.
$LATEST is pointing to the last saved lambda function which can be changed anytime, hence we cannot know for certain what we are executing or looking at if we use $LATEST. $LATEST I see could be different from what someone else sees. It looks to me working on $LATEST is working on a moving target.
AWS has so many strange "gotchas" like ECS capacity provider is immutable and cannot delete once created and if the ECS cluster is deleted, that capacity provider remains there and invisible, causing errors when trying to create a new capacity provider for a new ECS cluster with the same name (the bug which called "as designed" finally fixed though). I believe $LATEST is one of them.
Based on the comments, the following helped to clarify the issues:
When you refer to "version" in lambda you usually mean "published version" (e.g., 1, 2, 3) which is immutable. $LATEST is simply most recent "unpublished version" which you can change at will. You keep working/testing on $LATEST till you are satisfied with it. Once you are happy, you can "freeze" it by publishing it. At the time it becomes immutable version no. 1, for instance.
Since versions are immutable, aliases are normally used in your clients code. The aliases can be changed to point to different versions whenever you publish new version of your function. If versions were mutable, or could somehow be "unpublished", aliases would be rather pointless.
Related
How can I update the $LATEST version of a lambda to a previous one, including all configurations?
Exporting the lambda version and uploading it, indeed update the code but not all configurations, e.g., Layers, File systems, etc.
When I'm in AWS --> Lambda > Functions > myFunctionName, whenever I edit the Code and then run the Test (clicking on Test button to Left of Deploy), it is running the test on the old (deployed) version of the code. This happens whether or not I File > Save first.
This is easy to confirm by just adding a console.log("blah"); and seeing that it does not appear in the Test output.
The Test > Execution Results also confirm the test is running on $LATEST (see bolded section):
Response
null
Function Logs
START RequestId: <snip> Version: $LATEST
<snip>
Of course I can test my version by deploying it, but isn't there any way to test BEFORE I deploy? (Sorry if this is an ignorant question - I feel I'm missing something dead obvious...)
Assuming you are doing it via AWS Console.
In the console, only LATEST is available for editing.
And for testing the function you need to deploy a version.
Lambda function versions
You can change the function code and settings only on the unpublished version of a function. When you publish a version, the code and most of the settings are locked to maintain a consistent experience for users of that version
You can test separately by publishing versions Lambda function versions
You can Lambda function aliases
for better handling these versions.
Configuring functions in the console
I have AWS Bot with some intents and Lamda function. I need a seperate platform for stage and production release.
When I change any intent or lamda function it can't affect in production BOT Build,only affect in stage build.
How it possible?
How can manage the Lamda function?
I have tried with the AWS BOT Alias and version. But don't know how to handle Lamda function
Lex Versioning and Aliases
A version is a numbered snapshot of your work that you can publish for use in different parts of your workflow, such as development, beta deployment, and production.
An alias is a pointer to a specific version of a bot. With an alias, you can easily update the version that your client applications are using. For example, you can point an alias to version 1 of your bot. When you are ready to update the bot, you publish version 2 and change the alias to point to the new version.
When you version an Amazon Lex resource you create a snapshot of the resource so that you can use the resource as it existed when the version was made. Once you've created a version it will stay the same while you continue to work on your application.
$LATEST is the working copy of your resource. You can update only the $LATEST version and until you publish your first version, $LATEST is the only version of the resource that you have.
So you create a Lex Bot and are always working on the LATEST version.
Any changes you make only affect the LATEST version.
You cannot make changes to older versions of your Bot.
When you build the bot, a new version is automatically created, incrementing the version number by 1.
When you publish the bot, you will be able to select which Alias should be updated to this new version.
You can create an Alias and set or change the Version number in the Settings tab.
Lambda Function Versioning and Aliases
Conceptually, an AWS Lambda alias is a pointer to a specific Lambda function version.
When you publish a version, AWS Lambda makes a snapshot copy of the Lambda function code (and configuration) in the $LATEST version. A published version is immutable. That is, you can't change the code or configuration information.
Each time you publish a version, AWS Lambda copies $LATEST version (code and configuration information) to create a new version.
Match Lex Version to Lambda Version
Back in the Lex Console, you are able to specify by a dropdown menu which version or alias of the Lambda Function the Bot intents should use.
So keep your In-Development alias in $LATEST versions of both. Then also create a Production alias for both the Bot and Lambda and keep your Production bot pointed to your Production Lambda alias.
Simple question:
Does SAM Lambda auto-versioning using AutoPublishAlias work for AWS::Serverless::Function when code CodeUri changes but the actual code that it points to doesn't?
Background
We are deploying several Lambda#Edge functions using the SAM AWS::Serverless::Function resource type.
Our deployment runs via dropping code into an S3 bucket and then triggering a CloudFormation stack update. Our stack contains other things in addition to these Lambdas.
With this, we often have deployments that occur where the lambda code doesn't change.
Every deployment, however, the code URI changes to our newest deployment's bucket which, as intended, triggers a new version attempted to be published which is inline with note in SAM documentation (pasted below for context)
NOTE: AutoPublishAlias will publish a new version only when the CodeUri changes. Updates to other configuration (ex: MemorySize, Timeout) etc will not publish a new version. Hence your Alias will continue to point to old version that uses the old configurations.
The reason I am asking is because we've had some transient CloudFormation deployment issues that I've been trying to root cause that may be related to this. The error we get on the SAM generated version in the CloudFormation stack update is as follows:
A version for this Lambda function exists ( {some number} ). Modify the function to create a new version.
I've taken a look at the SAM code where the version is created and most of their documentation but couldn't find a clear answer.
We could likely manually create the AWS::Lambda::Function and AWS::Lambda::Version with a different logical ID on the version each time which should(?) fix the issue but we were trying to utilize SAM for auto-versioning of our Lambdas.
Any help is appreciated!
Yes, SAM will create a new version when CodeUri changes, however, Lambda will not allow you to create a new version if there have been no changes.
To workaround on that, I have a hack which is to create a NOUNCE environment variable with a random value that changes for every deploy. So CloudFormation believes that's a change on the code and deploy a new version of that Lambda and we have no more that version error.
By default, AWS uses the LATEST alias for the latest lambda version updated and I assume the below step.
Now, LATEST alias points version 5.
User deploys the new version of the lambda.
While deploying the new version, LATEST alias still points version 5.
When the deploying is complete, Lambda just switches LATEST alias to version 6.
Through the steps, lambda seems to have almost 0 downtime.
However, It is just an assumption.
Is there any document explicitly mentioning about the downtime while deploying the new version?
I just want to know how much AWS guarantee downtime while deploying the new version.
I also found similar question here, however not clear for my question.
AWS Lambda uses containers for deployment. If I had to guess, AWS is spinning up Version 6 while Version 5 is still active, then once Version 6 is ready, it applies whatever changes necessary to point traffic to the now live Version 6. The below article mentions somewhat the AWS Lambda container lifecycle:
https://aws.amazon.com/blogs/compute/container-reuse-in-lambda/