KPL与Kinesis Aggregation对比：跨账号Kinesis流Lambda生产方案咨询

KPL与Kinesis Aggregator核心差异 #

• KPL（Kinesis Producer Library）：全功能生产者工具包，内置消息聚合、自动重试、异步发送、分片路由自适应等全套能力，属于重量级完整客户端，运行时会启动独立后台进程处理发送逻辑。优势是无需自行开发聚合、重试、流吞吐量适配逻辑，劣势是资源占用高、Lambda冷启动耗时长，跨账号权限配置相对繁琐。
• Kinesis Aggregator：轻量型消息聚合工具，仅负责将多条小记录打包为符合Kinesis聚合规范的单条记录，聚合完成后仍需调用标准Kinesis SDK的PutRecord/PutRecords接口完成发送。优势是轻量无额外进程开销、对Lambda冷启动几乎无影响、跨账号权限配置和标准SDK完全一致，劣势是需要自行实现发送重试、限流处理、批量发送逻辑。

你的场景选型建议 #

优先选择Kinesis Aggregator的场景 #

• Lambda对冷启动延迟要求高，或分配的内存/CPU资源较低（低于1GB）
• 仅需要做消息聚合转发，不需要KPL自带的复杂监控、重试能力
• 希望简化跨账号权限配置，直接复用标准SDK的跨账号角色Assume逻辑即可
• 业务需要自定义重试策略，对数据准确性要求极高需要自行控制错误处理逻辑

优先选择KPL的场景 #

• Lambda配置了预置并发，无冷启动顾虑，且分配的资源足够（建议1GB内存以上）
• 不想自行开发重试、限流、吞吐量适配逻辑，希望直接用KPL的成熟能力
• 目标账号Kinesis流吞吐量波动大，需要KPL自动调整发送速率避免触发流限流

落地注意事项 #

你参考的两份示例代码分别对应两种实现路径：

1. KPL示例代码为直接通过KPL完成聚合+全流程发送的实现
2. Aggregator示例代码为通过聚合工具打包后调用标准SDK发送的实现

• 两种方案都需要提前完成跨账号权限配置：要么Lambda执行角色有权限Assume目标账号的Kinesis写入角色，要么目标账号Kinesis流的资源策略直接开放写入权限给源账号的Lambda执行角色
• 选择Kinesis Aggregator时，要注意聚合后的单条记录大小不要超过Kinesis单条记录1MiB的上限
• Lambda的超时时间要配置足够覆盖发送重试的总耗时，建议至少设置为30秒以上

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