"Already exists in stack" error when attempting to re-deploy a service

I created a service a few weeks ago that’s been happily running on Lambda. Now, however, when I try to re-deploy it, I get the following error:

  An error occurred while provisioning your stack: AnalyzeLambdaFunction
 - gcode-analyzer-dev-analyze already exists in stack <xxxxx>.

I haven’t made any real changes to any of the .yml files, and I’ve tried sls deploy and sls deloy -f. It correctly packages, uploads, and checks cloudformation for the update, but fails every time because the function seems to already exist.

Any ideas on how to debug this issue? As I mentioned, this is pretty much the “out-of-the-box” configuration.

Are you sure you haven’t renamed anything? Does your sls info command show the right output for your existing deployment?

It sounds like something’s been renamed and a new stack is being deployed, but it’s still generating names for resources that match your existing deployment…

Were you able to solve this problem? Did you try deleting the Lambdas/CloudFormation templates/CloudWatch logs before re-deploying?

I had a similar problem which was fixed by removing the CloudWatch log groups for the relevant Lambda functions.


Apologies for the bump. I figure this might be helpful to others:

I had the same issue. It was caused by an earlier development stage where I’d created my s3 bucket manually. Removing the s3 bucket from aws allowed cloudformation to stand up the stack.

Hope this helps someone.



This worked for me as well. Thanks for the solution

This post saved my life but I wanted to share this other link which explains the root cause of the problem which is caused by changing cloudformation resources “logical id” without changing the “logical name”


1 Like

I’m also have this same error, although in my case it seems to be specific to the Function VERSION that already exists (arn) and NOT the logical id or name.

I can confirm:

  • Function assets are being uploaded to S3 with updated object key (date)
  • SLS is generating a pre-existing “CodeSha256”

So I have no idea why these two things would ever happen?

Had the same issue. Updating Serverless to version 2.33.1 fixed this for me

To date the latest serverless version is 3.22.0

Are you sure?