GuardDuty运行时监控并入Security Hub计费：费用归属改变，检测代理无需重配
2026年10月2日，AWS宣布Amazon GuardDuty Runtime Monitoring纳入AWS Security Hub的Threat Analytics计划。对已在某个账户和区域启用Security Hub的用户，这部分运行时监控费用将由Security Hub归集，不再单独列为该账户、该区域的GuardDuty运行时监控收费。
同一项防护，账单入口发生变化
Runtime Monitoring观察操作系统、网络及文件活动，用于发现容器逃逸、权限提升和挖矿等威胁，覆盖Amazon EC2、Amazon EKS以及运行在AWS Fargate上的Amazon ECS任务。新计费把这些资源上的运行时监控归为一种用量类型，改变此前按资源类型分别收费的呈现方式。
AWS特别说明，检测覆盖、发现类型和GuardDuty安全代理保持原状，用户无需重新配置。因此，看到GuardDuty对应费用下降时，首先应查是否转入Security Hub，而不是直接判断监控已关闭；看到Security Hub费用上升，也应先核对是否只是归属变化。
AI模型生成的概念插图：多类计算资源的防护费用汇入同一账单入口；不是AWS控制台，也不代表真实账单金额或检测结果。
试用计划和实际用量要分别看
这次调整没有为Runtime Monitoring再增加一轮免费试用。Threat Analytics的免费试用与Security Hub Essentials的免费试用仍然分开，不能因为启用了基础计划，就假定新增归集的所有安全用量都处于免费期。
官方定价页面把Essentials作为基础，把Threat Analytics列为附加计划。没有纳入Security Hub计划的其他安全服务能力，仍按原服务计费。这说明变化不等于“GuardDuty整个账单全部消失”，也不能据此把同一账户中其他GuardDuty费用判成重复收费。
当前公告没有给出适用于所有账户的统一节省百分比。费用是否下降，取决于原有用量、区域、计划和实际计价条件。最直接的检查对象应是同一批受保护资源在同一时间长度内的总费用，而不是两个服务名称旁边各自的环比变化。
让成本报表接住新的服务归属
以下为本文建议。先列出正在使用运行时监控的账户与区域，再标出哪些已启用Security Hub。这个范围应与成本查询保持一致；若只按整个组织聚合，一些区域完成归集、另一些仍按原方式收费时，容易把混合结果当成异常。
随后，在Cost Explorer或Security Hub用量页面检查对应日期的变化，并更新依赖服务名称或用量类型的预算、成本分摊和内部报表。如果旧报表只抓GuardDuty项，即使实际防护持续运行，也可能显示“安全支出骤减”，让后续预算讨论基于错误分母。
验收时可以保留一组基准：账户、区域、资源覆盖、观察时段和运行时监控费用。新账单出来后，按相同范围对照，同时检查安全代理健康状态与发现是否正常进入处理流程。费用核对与检测核对要彼此关联，但不要把其中一个当成另一个的替代证据。
跨团队交接也需要写清楚谁负责新归属下的预算提醒。过去由GuardDuty报表负责人处理的异常，若迁到Security Hub却没有相应接手人，告警可能仍然存在，费用变化却没人解释。此次更新最值得立即处理的，是这类报表和责任入口，而非重新安装已经正常运行的代理。
区域可用性应按Security Hub官方区域列表核对。本文依据10月2日公告解释归集变化，不推断具体账户的生效时刻，也不把公开定价页上的其他计划或合作伙伴报价套用到运行时监控。
来源与核对时间
资料核对：2026年10月3日（北京时间）。本文未读取任何用户账单，未对费用变化进行实测。
