chore(s3-deployment): increase default memory limit from 128MB to 512MB

[ychjamie]

Issue # (if applicable)

Closes #35487.

Reason for this change

The BucketDeployment construct's Lambda custom resource uses a default memory limit of 128MB, which causes extremely poor S3 sync performance (10s of KB/s) and deployment timeouts. Users reported 15-minute timeouts when deploying typical static website assets, making the construct unreliable for production use without manual memory configuration.

Description of changes

Introduced a feature flag @aws-cdk/aws-s3-deployment:use512MbMemory to increase the default memory limit for BucketDeployment Lambda custom resource from 128MB to 512MB, providing dramatically improved S3 sync performance out of the box while maintaining backward compatibility.

Key Changes:

• Added feature flag @aws-cdk/aws-s3-deployment:use512MbMemory (enabled by default in recommended-feature-flags.json)
• When feature flag is enabled: uses 512MB explicit memory for optimal performance
• When feature flag is disabled: uses no explicit memory limit (Lambda's default 128MB for legacy behavior)
• Updated UUID generation logic to properly handle the new default for singleton behavior
• Added comprehensive unit tests to verify feature flag behavior:
  • no explicit memory limit when feature flag is disabled - verifies no MemorySize property is set
  • default memory limit is 512MB when feature flag is enabled - verifies MemorySize: 512
• Updated JSDoc documentation (default 512) and README.md to reflect new default
• Maintained full backward compatibility - existing explicit memory configurations unchanged

Describe any new or updated permissions being added

N/A - No IAM permissions or resource access changes. This is purely a Lambda memory configuration adjustment controlled by a feature flag.

Description of how you validated changes

Unit tests:

• Added "default memory limit is 512MB when feature flag is enabled" test that verifies CloudFormation template generation with correct MemorySize property
• Added "no explicit memory limit when feature flag is disabled" test for backward compatibility - verifies no MemorySize property is set when flag is disabled
• All existing tests continue to pass (79/79 pass in aws-s3-deployment module)

Integration tests:

• All aws-s3-deployment integration tests pass successfully with no regressions
• CloudFormation template generation verified to produce correct Lambda memory configuration with feature flag enabled/disabled

Feature flag testing:

• Verified behavior with feature flag enabled (512MB explicit memory)
• Verified behavior with feature flag disabled (no explicit memory, uses Lambda default 128MB)
• Confirmed UUID generation works correctly for singleton behavior in both modes

Build verification:

• Full TypeScript compilation, linting, and JSII build passes with no errors
• Cross-module testing: No regressions detected across all aws-cdk-lib modules

Performance validation:

• Issue reporter confirmed 100x performance improvement (KB/s → MB/s) with higher memory allocation
• Feature flag allows gradual rollout and easy rollback if needed

Implementation Details

The implementation follows the feature flag pattern where:

memorySize: props.memoryLimit ?? (FeatureFlags.of(this).isEnabled(cxapi.S3_DEPLOYMENT_USE_512MB_MEMORY) ? 512 : undefined)

• If memoryLimit is explicitly provided, use that value
• If not provided and feature flag is enabled, use 512MB
• If not provided and feature flag is disabled, use undefined (Lambda default 128MB)

This ensures backward compatibility while providing better defaults for new deployments.

Checklist

• My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[aws-cdk-automation]

(This review is outdated)

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

[github-actions]

Comments on closed issues and PRs are hard for our team to see.
If you need help, please open a new issue that references this one.

[pahud]

As discussed #35487 (comment) changing this default value would be a breaking change, I think we should introduce a feature flag for that.

[kaizencc]

Hi @ychjamie, I have a question on the necessity of a feature flag -- I know @pahud suggested it -- but I don't feel like its necessary here?

[kaizencc]

I'm confused why this needs to be hidden under a feature flag. Changing the memory limit does not require replacement in the lambda. Yes, the template will see a diff when a user updates but I don't consider that a breaking change. a user would be able to deploy without replacement and without failure in their custom resource right?

[pahud]

CI Error

@aws-cdk/aws-bedrock-alpha:   CHANGED    bedrock/agents/integ.api-schema 2.615s
@aws-cdk/aws-bedrock-alpha:       Resources
@aws-cdk/aws-bedrock-alpha:       [~] AWS::Lambda::Function CustomCDKBucketDeployment8693BB64968944B69AAFB0CC9EB8756C81C01536
@aws-cdk/aws-bedrock-alpha:        └─ [+] MemorySize
@aws-cdk/aws-bedrock-alpha:            └─ 512
@aws-cdk/aws-bedrock-alpha:       
@aws-cdk/aws-bedrock-alpha:       
@aws-cdk/aws-bedrock-alpha: Snapshot Results: 
@aws-cdk/aws-bedrock-alpha: Tests:    1 failed, 13 total
@aws-cdk/aws-bedrock-alpha: Failed: /codebuild/output/src750666806/src/actions-runner/_work/aws-cdk/aws-cdk/packages/@aws-cdk/aws-bedrock-alpha/test/bedrock/agents/integ.api-schema.js
aws-cdk-lib: PASS assertions/test/private/section.test.ts
@aws-cdk/aws-bedrock-alpha: Error: Some tests failed!
@aws-cdk/aws-bedrock-alpha: To re-run failed tests run: integ-runner --update-on-failed
@aws-cdk/aws-bedrock-alpha:     at main (/codebuild/output/src750666806/src/actions-runner/_work/aws-cdk/aws-cdk/node_modules/@aws-cdk/integ-runner/lib/index.js:10626:13)