我们有一个AWS Kinesis流，每秒接收大约15条小二进制消息。作为最后的数据恢复策略，我们希望转储S3存储桶中具有1-2周TTL的所有消息。
我们可以使用Lambda函数将每个Kinesis消息转储到S3中的新文件中。但是许多小型PUT都很昂贵，特别是因为该数据将不经常被访问（如果是这样，则通常是手动访问的）。
或者，AWS Firehose将为我们聚合消息并将其作为单个S3对象推送到S3。但是据我了解-请纠正我-Firehose只是连接记录，因此对于二进制和逻辑上分开的消息（与日志文件中的行不同），这是行不通的。
我目前的想法是使用附加到Firehose的Lambda函数，因此Firehose在X分钟内聚合记录，然后我们将其压缩/压缩，为每个记录创建一个文件，并作为单个存档发送到S3。
这合适吗？如果是这样，我们如何使用Lambda汇总记录？我们处理多对一，所以我不确定要把什么结果/状态代码传回Firehose。 （AWS生态系统对我来说是非常新的，所以我想我可能错过了显而易见的解决方案。）
答案 0 :(得分：1)
如果您可以接受1周的TTL，则可以增加流的data retention period，而不必担心任何其他存储机制。
如果您愿意每天支付86,400个PUT（0.43美元），则可以购买stream trigger your Lambda function。请注意，实际上您可能会被更频繁地调用，因为每个事件都有一个最大的大小，并且每个分片都是分别调用的。
如果您想进一步控制，建议您从CloudWatch Scheduled Event调用Lambda函数。我相信最小间隔是一分钟。但是，如果执行此操作，则还需要保留分片偏移（例如，在DynamoDB中），并为重新分片做好准备。
如您所述，Firehose不支持多对一转换。但是，您可以使用Lambda来获取输入记录，对它们进行base-64编码，然后添加换行符（请注意，您对Base64进行了两次编码：一次是记录转换，一次是为Firehose准备结果）。