如何不通过CloudWatch将AWS Lambda日志导出至S3存储桶

Lambda默认会将函数所有stdout/stderr输出路由到CloudWatch Logs，只要你在Lambda执行角色的权限策略中移除logs:CreateLogStream、logs:PutLogEvents等CloudWatch Logs写权限，就能彻底阻断日志流向CloudWatch的默认链路，以下是几种可落地的替代实现路径，全程不依赖CloudWatch服务：

• 业务代码层自定义日志Appender直传S3
  直接在函数代码中替换默认日志组件的输出目标，不依赖运行时默认的stdout收集逻辑。不同运行时都有成熟的实现方式：Python可以给标准logging模块开发S3处理器，Java可以用Logback/Log4j2的S3插件，Node.js可以给Winston/Pino配置S3传输器。
  实现时不要单条日志发一次S3请求（会产生极高的API调用成本），要在内存中攒批：比如攒够500-1000条、或者间隔20-30秒、或者在handler执行完成的finally逻辑中，将批次日志拼接为JSON行/纯文本格式，统一调用S3 PutObject接口写入，对象键建议按函数名/日期/请求ID/分片序号.log规则命名，方便后续检索。
  注意要在函数返回响应前完成当前批次日志的flush操作，不要依赖后台异步线程上传——Lambda会在handler返回后冻结进程，未完成的异步上传会直接中断导致日志丢失。

• Lambda Extension旁路采集上传
  这个方案完全不需要修改业务代码，利用Lambda原生的Extensions能力实现sidecar式日志采集：自己写个轻量Lambda扩展，启动时通过Lambda Logs API注册订阅，就能拿到函数全量日志，包括初始化日志、stdout/stderr输出、运行时报错信息，扩展进程独立完成日志攒批、压缩后定期上传到S3即可。
  这个方案的适配性最强，不管函数用什么语言开发都能统一接入，还可以在扩展层统一做敏感字段脱敏、日志格式转码（比如转成Parquet格式降低S3存储成本）。需要注意扩展会占用函数运行环境的内存、CPU配额，要根据业务资源剩余量调整批大小和上传间隔，避免影响主业务逻辑。

• 自定义运行时全链路接管日志流
  如果使用Lambda自定义运行时，可以直接在运行时启动脚本中将所有进程的stdout/stderr重定向到本地命名管道，启动一个常驻的轻量上传进程读取管道内容，攒批后上传到S3。这个方案灵活度最高，从运行时层就切断了日志流向Lambda默认日志收集组件的路径，你可以根据需求在上传前加任意自定义处理逻辑，比如日志过滤、字段富化、告警触发等。

落地注意事项：

1. 确认Lambda执行角色没有任何CloudWatch Logs的写权限，同时关闭Lambda控制台的自动创建日志组、X-Ray活跃追踪关联日志配置，避免系统级日志意外流入CloudWatch。
2. 直传S3时建议配置S3生命周期规则，比如热日志存标准存储30天后自动转低频存储/归档存储，到期自动删除，控制长期存储成本。
3. 做好上传失败兜底：如果S3上传失败，可将未上传成功的日志临时写入Lambda /tmp临时目录，下次函数启动、或者下一次日志flush时重试上传，避免日志丢失。

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