AWS Lambda大文件处理场景下EBS与EFS选型问询

你找不到Lambda+EBS落地实践的根本原因是：Lambda服务本身就不支持挂载EBS卷，不存在EBS和EFS二选一的空间，EFS是目前Lambda扩展临时存储的官方原生方案，完全适配你的大体积视频处理需求。

• 底层架构适配逻辑完全不同
  EBS是块级存储，设计定位就是给EC2实例提供直连的块存储，同一时间只能挂载到1台EC2实例上，依赖EC2实例的底层虚拟化驱动才能工作，和实例的网络、硬件路由强绑定。而Lambda是AWS托管的Serverless运行环境，用户没有权限访问底层虚拟化层，官方也从未开放过EBS挂载的相关接口，根本没有办法直接把EBS挂到Lambda运行目录下。
  EFS是基于NFS协议的弹性网络文件系统，通过VPC内网提供文件访问能力，不需要和计算节点做硬件层面的绑定，是Lambda官方原生支持的扩展存储选项，配置完成后可以像访问本地磁盘一样读写，单文件大小没有限制，完全能突破原生/tmp目录512MB的容量限制，满足大视频的临时存储要求。
• 并发场景支持能力天差地别
  你的视频处理流程是S3事件触发Lambda，一旦短时间内有多个视频上传，会同时拉起多个Lambda并发执行实例。EBS同一时间只能被1个计算节点挂载，完全没法支撑多并发实例同时读写的需求；就算你想绕路，先把EBS挂到EC2上再通过NFS共享给Lambda，不仅会把架构搞的异常复杂，还会引入EC2单点故障，一旦中转EC2挂掉所有视频处理任务都会失败。
  EFS原生支持上千个计算客户端同时并发读写，选择弹性吞吐量配置的话，最高可以支撑每秒数GB的读写带宽，完全能扛住多并发下ffmpeg转码、S3上传下载的IO需求，不会出现存储层的性能瓶颈。
• 运维和使用成本差距极大
  硬要凑EBS方案的话，你需要自己维护一组做存储中转的EC2节点，自己搞高可用、自动扩缩容、系统补丁、安全组配置，还要自己处理多实例下的存储一致性问题，运维成本非常高。
  用Lambda+EFS的方案只需要三步配置：给Lambda开启VPC访问权限、创建EFS访问点、在Lambda配置页关联EFS访问点和本地挂载路径，剩下的可用性、性能扩缩全是AWS托管，不需要你维护额外的计算资源。成本上EFS按实际存储量计费，你处理完视频后直接删除临时文件，不会产生闲置存储开销，比长期跑EC2中转的方案成本低70%以上。

针对你用ffmpeg处理大视频的场景，给个实操建议：把EFS挂载到/mnt/efs路径，执行ffmpeg时通过-temp_dir参数把临时文件目录指定到该路径下；Lambda内存尽量配到2GB以上，内存越高分配的CPU、网络带宽上限越高，能大幅缩短转码和文件传输的耗时；任务执行完成后记得主动删除EFS上的源文件和转码中间文件，避免产生不必要的存储费用。

内容的提问来源于stack exchange，提问作者Osama Bin Saleem