CDK BucketDeployment上传大文件触发SIGKILL错误，求解决方案

问题背景 #

目标 #

• 使用CDK构建运行Python应用的栈，EC2承载应用、RDS PostgreSQL做数据库，所有资源部署在自定义VPC内
• 将本地PostgreSQL的pg_dump备份文件上传到指定S3桶，已通过CDK创建S3桶并尝试上传

现象 #

• 小于1MB的小文件上传正常
• 160MB开发环境备份文件上传失败，报错如下：

Received response status [FAILED] from custom resource. Message returned: Command '['/opt/awscli/aws', 's3', 'cp', 's3://cdk-<some-hash>.zip', '/tmp/tmpjtgcib_f/<some-hash>']' died with <Signals.SIGKILL: 9>.

❌ SomeStack failed: Error: The stack named SomeStack failed creation, it may need to be manually deleted from the AWS console: ROLLBACK_COMPLETE: Received response status [FAILED] from custom resource. Message returned: Command '['/opt/awscli/aws', 's3', 'cp', 's3://cdk-<some-hash>.zip', '/tmp/tmpjtgcib_f/<some-hash>']' died with <Signals.SIGKILL: 9>.

原因分析 #

CDK的BucketDeployment底层依赖Lambda函数执行文件上传、解压等操作。你当前配置的Lambda内存仅128MB，处理160MB压缩文件（尤其是解压过程）时内存资源耗尽，导致Lambda进程被系统强制终止（SIGKILL信号）。Lambda的内存配置同时关联CPU和网络带宽，内存越低，处理大文件的效率和能力越弱。

解决方案 #

1. 提升Lambda内存与临时存储 #

修改BucketDeployment配置，调高内存限制和临时存储大小，给Lambda足够资源处理大文件：

const deployment = new s3d.BucketDeployment(this, "DatabaseDump", {
  destinationBucket: dataImportBucket,
  extract: true,
  // 调大临时存储到10GB（Lambda最大支持值），应对1GB压缩包的解压需求
  ephemeralStorageSize: cdk.Size.gibibytes(10),
  logRetention: 7,
  // 内存至少调到1024MB，处理1GB文件建议用2048MB
  memoryLimit: 2048,
  retainOnDelete: false,
  sources: [s3d.Source.asset(dataImportPath)],
});

2. 关闭自动提取（如果不需要） #

如果pg_dump文件不需要在S3中解压存储，将extract设为false，避免Lambda执行解压操作，大幅降低资源消耗：

extract: false,

3. 替代方案：跳过CDK部署，直接用AWS CLI上传 #

对于1GB级别的超大文件，不建议通过CDK的BucketDeployment处理（Lambda最大执行时间为15分钟），可以直接在本地用AWS CLI上传：

aws s3 cp ./assets/your-dump.tar.gz s3://ch-data-import-bucket/

这种方式绕开Lambda的资源限制，更适合大文件传输。

4. 拆分大文件（可选） #

如果必须通过CDK上传，可将大备份文件拆分为多个小文件，上传后再在S3或后续流程中合并，但会增加额外的处理步骤。

内容的提问来源于stack exchange，提问作者PirateApp