AWS Lambda now allows developers to reference deployment packages stored directly in their own Amazon S3 buckets, a change that removes the per-Region code storage quota and increases the default managed storage limit from 75 GB to 300 GB. The update, announced by AWS on August 28, 2024, addresses a longstanding limitation for serverless computing users who manage large numbers of functions or frequently update code artifacts.
Previously, Lambda enforced a per-Region storage cap of 75 GB for all function code and layers combined. Customers who exceeded this limit had to request quota increases or delete old versions. With the new self-managed storage option, AWS no longer counts deployment packages stored in the customer’s S3 bucket toward the account quota. Instead, the 75 GB default has been raised to 300 GB, reserved exclusively for code stored within AWS Lambda’s internal system.
How the New Storage Model Works
Under the updated architecture, a Lambda function can reference an S3 object as its deployment package via the Amazon Resource Name (ARN) of the bucket and object. The function retrieves the code on demand during invocation, reducing the need to upload large packages directly to Lambda. This change is particularly relevant for teams that deploy large machine learning models, video processing binaries, or aggregated microservices.
While the self-managed storage addresses the per-Region quota, AWS has not altered the per-function size limit. The maximum deployment package size remains 50 MB for zip archives uploaded directly and 250 MB for container images, regardless of the storage method. Additionally, after replacing or updating an object in the S3 bucket, developers must still call the UpdateFunctionCode API to synchronize the function with the new code. AWS emphasizes that the system does not automatically detect changes to S3 objects.
Current Support and Tooling
As of the announcement, AWS Lambda supports S3-referenced code through the AWS Management Console, AWS Command Line Interface (CLI), and SDKs. However, the Terraform provider maintained by HashiCorp does not yet support the new feature. An open enhancement request on the Terraform GitHub repository tracks community demand for integration. Developers using infrastructure-as-code workflows may need to rely on temporary workarounds, such as the AWS CLI or custom scripts, until official support arrives.
AWS has published documentation detailing the required IAM permissions, which include s3:GetObject and s3:GetObjectVersion access for the Lambda execution role, as well as kms:Decrypt if the S3 bucket uses customer-managed AWS Key Management Service (KMS) keys. The feature is available in all commercial AWS Regions where Lambda operates, with no additional charge for referencing S3 objects.
Analysts note that the update lowers operational overhead for users who previously managed storage quotas through manual requests or third-party automation. By removing the quota count for S3-referenced packages, AWS gives developers more flexibility to maintain multiple versions of functions or store large assets without administrative intervention. The change does not affect Lambda’s pricing model, which charges based on compute time and requests, but it may reduce costs related to storage overage fees.
Looking ahead, AWS plans to continue evaluating community feedback regarding the UpdateFunctionCode requirement and potential automatic synchronization. The company has not announced a timeline for Terraform provider support or further increases to the per-function size limit. Developers are encouraged to test the new workflow in non-production environments and adjust their deployment pipelines accordingly.
