服务对象与地域限制
PuppyIP 仅面向海外合规企业及其授权人员提供服务，不面向中国大陆地区开放或提供代理服务。本服务仅限用于中国大陆境外的合法业务活动，严禁在中国大陆境内使用本服务。
代理 IP 或服务器位于境外，不改变上述限制。不得通过中转、转接、共享或转售向中国大陆境内的最终使用者提供本服务。使用前请阅读用户服务协议。
本文要点
- LiveTaskCount属于ECS服务指标，覆盖ACTIVATING、RUNNING和DEACTIVATING生命周期状态，无需选择启用Container Insights。
- RunningTaskCount要求任务当前状态和期望状态都为RUNNING；Container Insights内这项指标从2026年10月1日起自动免收费。
- LiveTaskCount使用AWS/ECS命名空间，按ClusterName与ServiceName定位，单位Count，可看Average、Minimum和Maximum。
- 计入任务不等于任务已准备好接收新请求；没有RUNNING任务时可能没有数据点，缺值也不能直接当成零。
- 免费的是指定任务数指标，不是整个Container Insights、容器日志或全部监控配置。
公告是10月13日，RunningTaskCount免收费从10月1日算起
AWS在2026年10月13日公布两项变化：新增不额外收费的LiveTaskCount，以及取消CloudWatch Container Insights中RunningTaskCount的指标费用。公告说明，变化适用于提供Amazon ECS的全部AWS区域；RunningTaskCount价格调整自10月1日起自动适用，无需申请。
LiveTaskCount已经包含在ECS服务利用率指标中，不要求启用Container Insights。若只是需要服务任务数，先查看这项现成指标；不要因为看到“免费”就顺手开启一整套容器观测功能。
已在使用Container Insights的团队可以继续用RunningTaskCount。它仍是服务健康与稳定性的一个信号，免收费并没有把它的计数范围改成LiveTaskCount。
启动中和连接排空中的任务，为什么也会被计入？
LiveTaskCount计入服务中处于ACTIVATING、RUNNING和DEACTIVATING生命周期状态的任务。ACTIVATING是准备接收流量，例如向负载均衡目标组或服务发现注册；DEACTIVATING则包括排空连接、从接收流量的资源注销，之后才停止。
RunningTaskCount更窄：任务当前状态和期望状态都必须为RUNNING。任务仍在处理旧连接、但正向停止状态过渡时，LiveTaskCount可以继续计入它，RunningTaskCount则不计入。
假设一个服务有8个任务正常运行，另有2个任务正在缩容排空连接，并且其余条件相同。这个示意场景下，LiveTaskCount可以是10，RunningTaskCount是8。这不是我们运行的测试，也不能由10推断有10个任务都能接收新请求。
需要完整观察仍在运行、产生指标的任务时，LiveTaskCount更适合容量监控和扩缩容判断；需要当前与期望都在RUNNING的数量时，继续看RunningTaskCount。两者都不能单独代替应用响应或负载均衡健康检查。
先在CloudWatch核对服务和维度，再比较曲线
在对应AWS账户和ECS服务所在区域打开CloudWatch指标，查看AWS/ECS命名空间中的LiveTaskCount。用ClusterName和ServiceName两项维度定位同一个服务，避免把不同集群的同名服务混到一起。
这项指标单位为Count，官方列出的统计值是Average、Minimum和Maximum。比较两张图前，先统一时间窗口、周期和统计值；例如，聚合时段的Average不一定是整数，不能直接当成某一瞬间任务清单的行数。
ECS指标参考说明默认按一分钟间隔发送指标。先读现有数据并对照该时段的任务状态；若要修改扩缩容告警或容量计算，另外复核原公式是否需要把排空中的任务保留在计数中，再决定如何调整。
服务缩到零后，空白曲线不等于已报告零
ECS指标参考明确：如果服务或其他资源没有RUNNING状态的任务，该时段可能不会向CloudWatch发送指标。Container Insights文档也说明，只有存在运行任务的资源才会在相应时间范围产生这类指标。
因此，空白曲线既不能直接读成“报告了0”，也不能仅凭缺值判断遥测故障。先核对账户、区域、ClusterName、ServiceName、时间窗口，以及服务是否确实有RUNNING任务。
告警对缺失数据的处理会影响触发结果。需要监测缩到零的服务时，应把没有数据点的情况纳入自己的告警设计，不能因为任务数指标免费，就假设任何停机或缩容情况都会持续返回零值。
RunningTaskCount不收费，为什么账单仍有Container Insights？
AWS明确取消的是RunningTaskCount这一项指标费用，不受账户内ECS服务或集群数量影响。Container Insights采集的其他指标仍按相应CloudWatch规则计费，容器日志的摄取与存储费用也没有随之取消。
CloudWatch定价页示例19以Fargate增强可观测性场景说明区别：每个服务列出31项指标，其中RunningTaskCount免费，所以按每个服务30项付费指标计算；示例中的5个服务各有一项免费RunningTaskCount，其余指标仍进入月费计算。
这是官方假设示例，不是我们的账单测量。示例价格基于美国东部（弗吉尼亚北部），且假定整月上报；不同区域、运行时长、集群结构、观测模式和日志用量都可能改变金额，不能拿示例总价当成所有账户的固定月费。
已有监控先保留，新增监控只选需要的信号
若已有RunningTaskCount告警，先保留其健康与稳定性用途，在相同服务、时间窗口和统计值下观察LiveTaskCount，重点看发布或缩容时的差异。价格自动调整不代表现有仪表盘、告警公式或扩缩容策略会自动改用新指标。
若尚未启用Container Insights，只需要完整任务数，可以先查看现成的LiveTaskCount。只有确实需要更细的任务、容器、资源利用率或日志信息时，再按所需观测能力评估Container Insights及其费用。
最后分别确认两件事：曲线计数是否符合你要观察的任务状态，实际费用是否符合账户所在区域的计费记录。官方上线和价格公告说明产品规则，不能替代你自己服务的健康与账单结果。
资料来源
常见问题
LiveTaskCount能直接显示集群里所有独立任务吗？
本次公告和指标表描述的是服务级LiveTaskCount，使用ClusterName与ServiceName维度。不能据此把它当成整个集群所有任务、所有独立任务或所有容器的通用总数；应按你查询的资源与维度另行核对。
为什么LiveTaskCount变高，应用吞吐却没增加？
它可能包含尚在准备接收流量的ACTIVATING任务，以及正在排空连接的DEACTIVATING任务。计数增加只说明覆盖到的生命周期状态数量变化，不能单独证明可用容量或吞吐增加；应结合应用响应与流量健康信号判断。
这次免费是否包含20秒高分辨率CPU与内存指标？
本次公告明确的免费范围是LiveTaskCount和Container Insights的RunningTaskCount，没有把全部高分辨率指标纳入。ECS文档另列CPUUtilization和MemoryUtilization默认60秒、可配置20秒的监控方式；不要把任务数指标的价格承诺套到这类独立配置上。