AWS在2026年9月2日宣布，AWS Config一次新增60类可记录资源，覆盖Amazon EC2、Lightsail、Bedrock、SageMaker、AWS Organizations等多个服务。对需要集中盘点云资产和检查配置变更的团队来说，这次更新扩大了Config能够看见的资源边界。
新支持项既包括EC2 Route Server及其端点、对等连接，也包括Lightsail实例、数据库、负载均衡器和分配网络，还涉及RDS DB Proxy、EKS Pod Identity Association、S3 Vectors Index等较新的资源。它带来的实际价值不是多了一张列表，而是这些资源现在可以进入统一的记录、规则检查与跨账号汇总流程。
新增范围横跨计算、网络和AI服务
本轮60类资源中，传统基础设施与新服务都有明显扩展。EC2侧加入Route Server、Route Server Endpoint和Route Server Peer，Lightsail侧则覆盖实例、数据库、负载均衡、域名、容器与分配网络。
AI与数据服务同样占了较大比例，包括Bedrock Flow、Flow Version、Prompt Version、Enforced Guardrail Configuration，以及多种Bedrock AgentCore资源。SageMaker的App、Algorithm、Model Card、Model Package和MlflowApp等对象也被纳入。
Config能记录资源，不等于这些资源此前没有日志。变化在于配置状态和关系可以用统一方式留存，更适合做资产发现、变更追踪与合规判断。
全量记录账号会自动跟踪新资源
官方说明，已经把记录范围设置为所有受支持资源类型的账号，会自动开始记录这60类新增资源。团队无需逐项修改记录器，也不需要重新创建Config服务。
这项自动行为需要运维人员注意。以前不在记录范围内的资源开始产生配置项和变更记录后，数据量与调用费用可能变化，告警和自动修复流程也可能首次看到这些对象。
自动纳入最容易被忽略的是成本与规则影响。多账号、多区域环境应在更新后观察Config记录数量、交付通道和月度费用，确认新增覆盖没有超出原本预算。
选择性记录需要手动更新清单
没有启用全量记录，而是明确选择资源类型的环境，不会因为AWS增加支持就自动扩大范围。管理员需要根据实际治理目标，把需要的新资源加入记录策略。
例如团队在Lightsail运行小型网站，却只记录EC2和RDS资源，新增支持并不会自动补上Lightsail实例与数据库。类似情况也会出现在Bedrock、EKS Pod Identity和S3 Vectors等较新服务中。
更新清单前可以先从资源发现结果中统计数量，再分批启用。生产账号最好先在一个区域或测试账号验证记录频率与配置关系，避免一次扩大范围后出现大量无效告警。
规则与聚合器可以直接使用新增类型
这些资源类型同时可以用于AWS Config规则和Config聚合器。规则负责检查配置是否符合要求，聚合器则用于把多个账号与区域的配置和合规状态集中展示。
现有自定义规则如果按资源类型过滤，可以扩展到新对象。比如检查Lightsail负载均衡器、RDS DB Proxy或Organizations策略是否符合内部基线，再通过组织级聚合器查看整体结果。
但新增支持不会替团队自动生成合适的合规规则。记录解决的是看见资源，规则才决定哪些状态属于风险，两者需要分别配置。
上线后应先检查记录量和告警噪声
管理员可以先确认配置记录器采用全量还是选择性模式，再检查最近新增的配置项。多账号环境还应核对聚合器授权，避免部分成员账号已经记录但中央安全账号看不到。
第二步是查看现有规则、EventBridge事件和自动修复逻辑是否会匹配新资源。过于宽泛的条件可能突然触发大量告警，甚至对尚未验证的资源执行自动操作。
这次更新让AWS Config更接近完整云资产底账，但真正发挥作用仍依赖清晰的记录范围、合规基线和成本监控。先确认新增对象，再逐步补充规则，比一次性对60类资源全部套用相同策略更稳妥。
