🚀 Feature Request: Option to disable ZIP compression for faster Lambda packaging

[mungojam]

Describe the feature

Packaging Lambda functions with the AWS Extensions for .NET CLI currently uses Deflate ZIP compression, which can significantly slow down build times, particularly for large projects or in CI/CD workflows. Since AWS Lambda unpacks zipped archives upon deployment, the benefit of compression is mainly in transit, and build time is the primary concern for developers. An option to disable ZIP compression—using "store only"—would allow for much faster package creation with minimal trade-off for most users.

Use Case

Developers or CI/CD pipelines working with large Lambda deployments face long wait times due to compression, while upload size is rarely the bottleneck. This option helps speed up rapid iteration, making the build process more productive and responsive.

Proposed Solution

• Add a CLI option (--disable-zip-compression) to the packaging commands.
• In the Go zip utility (build-lambda-zip.go), add a flag that chooses zip.Store instead of zip.Deflate.
• Update C# methods in LambdaPackager.cs and CLI wrappers to thread the compression flag and pass it to the native zip CLI (-0 flag) and Go utility, as needed.
• Document clearly in helptext and CLI output.
• Default to current behavior unless the user opts in.

Other Information

Other Information

Relevant code files for maintainers:

• src/Amazon.Lambda.Tools/BuildLambdaZip/build-lambda-zip.go
• src/Amazon.Lambda.Tools/LambdaPackager.cs
• src/Amazon.Common. DotNetCli.Tools/Utilities.cs
• Command option definitions and parser updates (LambdaDefinedCommandOptions. cs and relevant command classes)

This feature is opt-in; backwards compatible

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

Targeted .NET platform

Any modern .NET version supported by the tool (.NET Core 3.1, .NET 6, .NET 8, etc.)

CLI extension version

5.13.2

Environment details (OS name and version, etc.)

All major platforms: Windows, Linux, macOS, Amazon Linux

[normj]

Do you have any data on how much it slows your CI? I would imagine given the usual size and number of files it would be pretty small.

A benefit of the compression you might be missing is if the zip is greater then 50 MB you can no longer directly upload to Lambda and instead need to upload to your own S3 bucket first and then reference to the S3 object when creating or updating the function. That makes the deployment process more complicated and you would pay for the storage in S3 for how long you keep there.

Another challenge you would need to do for this is we only use the Go program on Windows to maintain Linux file permissions. On non Windows platforms we rely on the zip cli command so we would have to have the same setting across both tools. It has been on my wish list of things to do is get rid of the Go program and the shell out to the zip cli. We should be able to use the newer .NET compressions APIs that didn't exist when we first wrote this code.

[mungojam]

Do you have any data on how much it slows your CI? I would imagine given the usual size and number of files it would be pretty small.

On a standard github actions runner, the zipping of a single lambda is currently taking about 7 seconds. When multiplied up by many lambdas this adds up to a sizeable proportion of our total build time. I think it's made worse by the fact that we are on .net 9 currently so doing the self-contained mode with a lot of the .net dlls. It will get quicker for a year when we got to .net 10 as we'll be able to use the official runtime.

A benefit of the compression you might be missing is if the zip is greater then 50 MB you can no longer directly upload to Lambda and instead need to upload to your own S3 bucket first and then reference to the S3 object when creating or updating the function.

We use serverless framework which I believe does this S3 route anyway so it wouldn't impact us.

We should be able to use the newer .NET compressions APIs that didn't exist when we first wrote this code.

Yeah I'd been wondering about doing that as a PR :)

Copilot did seem to know how to change both of the current methods to do no compression but it might have been hallucinating of course

[mungojam]

The permission change step takes another 1-2 seconds