AWS Lambda+API Gateway大文件ffmpeg转码超时及后台执行问题

问题根源 #

你碰到的FileNotFoundError本质是Lambda的资源回收机制导致的：当你给ffmpeg命令加&让它后台跑，函数提前返回响应后，Lambda会立刻清理执行环境的临时文件系统（包括/tmp目录里的output_audio.aac），后台的ffmpeg进程自然找不到文件。而且Lambda函数结束后，后台进程随时会被强制终止，就算转码没完成也会被kill，完全不可靠。

靠谱的解决方案 #

1. 异步架构（首选） #

彻底绕开API Gateway的29秒超时，用「API Gateway + S3 + 消息队列 + 转码Lambda」的流程：

• API Gateway接收到请求后，先把视频文件上传到S3存储桶。
• 向SQS或者SNS发送一条转码任务消息（包含S3文件路径、用户通知方式等信息）。
• 立刻返回用户JSON响应：{"status": "started", "message": "转码已启动，预计数分钟完成，完成后将通知您"}。
• 配置另一个Lambda函数作为消息队列的触发器，这个Lambda专门负责跑ffmpeg转码——它的执行时间可以设到15分钟上限，足够处理大文件。转码完成后把音频文件存回S3，再通过邮件、Webhook等方式通知用户。

2. 硬要后台执行的临时方案（不推荐） #

如果暂时不想改架构，必须在原Lambda里后台跑，得做这两点：

• 放弃Lambda临时存储：不要用/tmp目录，所有输入输出都用S3。可以用s3fs把S3挂载到Lambda本地，或者直接让ffmpeg通过AWS CLI读写S3（需要给Lambda配置S3读写权限）。
• 修正命令路径，比如：

  ffmpeg -i s3://your-input-bucket/video.mp4 -vn -acodec copy s3://your-output-bucket/audio.aac > /dev/null 2>&1 &
  

  但要注意：就算这么做，Lambda还是可能在函数返回后终止后台进程，转码大概率会失败，所以只适合临时测试，不能用于生产环境。

重要提醒 #

• Lambda的/tmp是临时目录，函数一结束就会被清空，绝对不能用来存后台进程需要的文件。
• API Gateway的29秒超时是硬限制，没法修改，异步架构是唯一能稳定处理大文件转码的方式。

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