CloudFormation doesn't deploy changes to the lambda code

[amcinnes]

If I make a change to the lambda code, upload a new zip file into S3 with the new code (overwriting the old zip file), and then update my CloudFormation stack, CloudFormation will not detect that the code has changed, and thus will not deploy the new code.

A solution could be to use the aws cloudformation package command, which will give each version of the zip file a unique name in S3, and will produce a CloudFormation template file that refers to the objects in S3 by their unique name. Then a new version of the Lambda code will result in a change to the CloudFormation template so CloudFormation will update the Lambda correctly.

[ryanjshih]

Hi, amcinnes,

Have you solved this problem?

[gbisaga]

I don't really see a problem here. CF needs to know that some change has taken place, and if you don't change a parameter or the S3 package file name, CF can't tell there's a change.

[wspencer]

I don't understand gbisaga's statement. I've got the same problem. Do I have to delete the stack and re-create it every time I tweak the lambda code? This makes for a horribly slow development loop. I sure hope there's a better way!

[gbisaga]

No, I don't think so @wspencer - but you do have to change something that CF knows about. I believe the way serverless framework handles this is that it generates a different S3 package file name every time you re-deploy; then the updated CF template causes it to redeploy the lambda. It IS definitely a bit of a pain, requiring different S3 file names every time... but that's just one more reason serverless framework makes things easier.

[wspencer]

Thank you for your reply @gbisaga. I'm deploying more than 10MB from the desktop, so I have to copy a zip package for the lambda to S3 myself - I don't get the benefit of auto-magical S3 naming. But I did find one quicker path - use the cli to deploy an updated zip package to the function. This avoids colliding with Cloudformation's inability to notice the source code for the lambda changed.

The Serverless framework does make some things easier, but it's so poorly named that googling for answers is frustratingly hard. I used it on my last professional project and came away with mixed feelings, at best.

[nicc777]

I ran into the same issue. CloudFormation only checks for changes in the actual template - it doesn't really care about the actual changes in the function, even if you have that in S3. So right now I have to make my pipeline update a build ID in the template just to force an update. It's a crazy hack which I would argue goes a little against the grain of what this technology tries to achieve, and competing products like Terraform have solved this problem way back in 2016 already - on AWS Lambda function specifically.

[sedeh]

Here are the modifications I made in attempts to reflect changes. Still, aws cloudformation update-stack comes back with resource "already exists in stack".

• Included short git hash of the commit in the resource name (Logical ID), S3Key (zip filename)
• Populated the full git hash in a variable inside Environment

[QDeepSense]

What do you think of the approach that consists on deleting the stack everytime, and re-reploying after the deletion?