ESP-32水浸检测器：AWS IoT选DynamoDB还是CloudWatch？

一、CloudWatch更匹配你的核心需求 #

• 存储成本与生命周期管控：CloudWatch支持自定义数据保留周期（最短1天，最长15个月），刚好契合你“无需长期存储”的要求，不用像DynamoDB那样手动编写清理过期数据的逻辑，能显著降低居家高频脉冲数据的存储开支。
• 时段化告警实现：CloudWatch Alarms可基于脉冲数据的频率阈值（比如单位时间内脉冲数超出正常范围）配置告警，再结合EventBridge（原CloudWatch Events）就能实现仅在你预设的外出时段激活告警规则，完美覆盖核心功能需求。
• 快速搭建监控仪表盘：CloudWatch自带的Dashboard功能可以直接对接IoT传入的脉冲指标，快速配置实时趋势图、时段统计图表等，无需额外开发数据查询和可视化逻辑。

二、决策时容易遗漏的关键要点 #

• IoT到CloudWatch的数据流转配置：AWS IoT无法直接将消息写入CloudWatch指标，需要通过两种中转方式实现：
  • 方式1：配置IoT规则触发Lambda函数，将脉冲数据转换为CloudWatch指标格式后上报
  • 方式2：通过IoT规则转发消息到Kinesis Data Firehose，再由Firehose推送到CloudWatch Metrics
    两种方式都需要额外配置，复杂度不高，但要提前评估开发和维护成本。
• 原始数据的回溯需求：CloudWatch Metrics存储的是聚合后的数据（比如每分钟/每小时的统计值），无法保留单条脉冲的原始记录。如果你的场景偶尔需要查看具体时间点的脉冲细节，建议搭配CloudWatch Logs存储原始IoT消息，并设置较短的保留周期（比如7天），兼顾成本和回溯需求。
• 告警通知的灵活性：CloudWatch Alarms默认支持邮件、SNS、Lambda等通知渠道，但如果需要微信、短信等更灵活的触达方式，需要通过SNS对接第三方服务，这部分要提前规划。
• 多设备扩展的维度规划：如果后续要增加多个检测设备，CloudWatch的指标命名空间和维度（比如按设备ID区分）能很好支持多设备的聚合监控，而DynamoDB需要额外编写多设备查询逻辑。但要提前规划指标维度，避免后续出现指标混乱的问题。

三、补充建议 #

如果你的场景仅需统计脉冲频率、实现时段告警和基础监控，CloudWatch是最优选择；如果偶尔需要回溯单条脉冲的时间点，可以搭配短保留期的CloudWatch Logs存储原始数据，同时用Metrics做监控和告警，平衡成本和需求。

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