AWS Serverless | Code storage limit exceeded

Question

I have an error Code storage limit exceeded deploy the serverless application in AWS. Total size 409 B.

The error message says:

An error occurred: HelloLambdaFunction - Code storage limit exceeded. (Service: AWSLambda; Status Code: 400; Error Code: CodeStorageExceededException; Request ID: ...)

Tenstrike

Answer 1

Looking specifically for this problem related to serverless, I found https://github.com/serverless/serverless/issues/400. It is a known problem of the serverless framework. However, some enterprising individual created a solution to the problem with a plugin that is able to prune old versions: https://github.com/claygregory/serverless-prune-plugin. This allows you to clean up the old versions and code storage without deleting the entire stack.

For example, you can delete all but the last 10 versions using:

sls prune -n 10

There are further options for restricting by stage or region. Even better it is possible to integrate the plugin into the deploy to automatically remove all but x versions.

I used this plugin for my current serverless project and it delivered on the promise.

Communalism

Yes, it works. However, clearing the versions may take long if there are a number of functions with many versions E:\git\serverless>sls prune -n 20 Serverless: Prune: Querying for deployed function versions Serverless: Prune: dev-insertData has 116 additional versions published and 0 aliases, 96 versions selected for deletion Serverless: Prune: Deleting Function dev-insertData v118... Serverless: Prune: Deleting Function dev-insertData v117... . : Serverless: Prune: Deleting Function dev-insertData v23... . : – Dwightdwindle

This is true. The first prune will likely take a while if you've run out of code storage. Using the plugin it prunes with each deploy so it only ever has to clean up one version. So it is just the first prune that takes time. – Communalism

Answer 2

From PublishVersion - AWS Lambda, CodeStorageExceededException means:

You have exceeded your maximum total code size per account.

From AWS Lambda Limits - AWS Lambda:

• Total size of all the deployment packages that can be uploaded per region: 75 GB
• Lambda function deployment package size (compressed .zip/.jar file): 50 MB
• Size of code/dependencies that you can zip into a deployment package (uncompressed .zip/.jar size): 250 MB
• Total size of environment variables set: 4 KB

Hairdo

I know the limitation of Lambda, but I face this issues in my serverless framework. – Tenstrike

Answer 3

As already mentioned above Total size of all the deployment packages that can be uploaded per region: 75 GB . So if we set

By default, the framework creates function versions for every deploy. This behavior is optional, and can be turned off in cases where you don't invoke past versions by their qualifier. If you would like to do this, you can invoke your functions as arn:aws:lambda:....:function/myFunc:3 to invoke version 3 for example.

To turn off this feature, set the provider-level option versionFunctions.

provider: versionFunctions: false

Haines

Answer 4

I am Solve that issues, to delete cloud formation stack using sls remove and deploy serverless project using sls deploy command. that's work for me.

Tenstrike

Deleting your stack (possibly losing data in attached resources) is dangerous and an overkill for a problem that has much safer solutions (e.g. sls prune -n 10). – Siege

definitely agree that there should be more of a disclaimer here for what this command is doing – Ranchod

Answer 5

Requesting an AWS Lambda function and layer storage quota increase and calling aws cloudformation continue-update-rollback after the request is approved should remedy stacks stuck in UPDATE_ROLLBACK_FAILED due to CodeStorageExceededException

Lilithe

Answer 6

For anyone coming here (like myself) who's using Zappa and seeing this error, the solution is similar to sls prune but instead use "num_retained_versions": 10 (or whatever retained value you care for) in your zappa_settings.json. As has been mentioned, you have a certain quota of versions for your region and it's unclear when you'll hit it but when you do, it's a pain to work out the reason.

Cavit

Answer 7

Although this might be an old question, I've faced the same issue and struggled to find a solution. I tried using two Serverless Framework plugins, serverless-prune-plugin and serverless-prune-versions, but neither worked for me.

Ultimately, I resolved it by creating a script that deletes older Lambda versions, keeping only the 5 most recent ones. You can find the script here: https://github.com/jperocho/lver. Note that this script currently works only within the Serverless YAML file.

After running the script, I used the following CLI command to continue the CloudFormation rollback:

$ aws cloudformation continue-update-rollback --stack-name <your_stack_name>

Then, I retried building, and it worked.

Bicarbonate