Transfer Family允许工作流自选日志组：执行记录可独立归集，旧查询入口需要同步检查
2026年10月1日，AWS为Transfer Family托管工作流开放自定义CloudWatch日志组。创建工作流时，可以通过控制台或API选择工作流级目的地，让执行日志离开所属服务器的统一日志组。该功能覆盖提供Transfer Family托管工作流的AWS区域。
日志归属可以跟着工作流走
此前，挂接到同一Transfer Family服务器的工作流会把执行记录发到该服务器的CloudWatch日志组，无法为每个工作流分别指定目的地。新设置允许把不同业务的执行日志分开，也允许把多个相关工作流汇入同一个组，以便做统一指标和看板。
日志继续采用既有结构化JSON格式，仍能用CloudWatch Logs Insights查询。改变的是投递位置，不是把日志变成另一套格式。已有解析逻辑可能继续适用，但查询覆盖哪些日志组、指标从哪里取数，需要随着目的地变化重新核对。
AI模型生成的概念插图：不同工作流的执行记录流向各自的归集位置；不是实际CloudWatch界面，也不表示真实日志内容。
只投递到选定组，别等待旧位置再出现一份
公告明确：配置工作流级日志组后，Transfer Family只向选定的组投递工作流日志，不需要服务器日志角色。如果没有选择结构化日志目的地，则在已配置的情况下继续使用服务器原有的基于角色的日志方式；已有工作流也继续沿用当前配置。
这几种路径不能混用成“新功能会自动搬走所有旧日志”。公告确认的是新建时选择目的地及现有配置保持原状，没有宣称历史记录自动迁移，也没有给出对所有已有工作流一键替换的承诺。准备调整既有流程时，应先核实可用操作和实际依赖。
对排障人员，最容易遇到的问题是旧查询突然没有新执行记录。本文建议先查工作流的实际目的地，再看日志是否送达，而不是马上判定工作流没有运行。反过来，日志组里看到启动记录也不足以证明整个文件处理链成功，仍要检查执行状态和最终产物。
选择分开或合并，要对应维护方式
如果两个工作流由不同团队负责，独立日志组可以让查询和保留配置更贴近责任范围；如果它们共同完成一条文件处理链，集中归集可能更便于联合调查。这是部署设计上的取舍，不能仅根据“现在能拆”就把每条流程都拆成一个新组。
合并后还应保留能识别具体工作流和执行的字段，避免把一次失败的多个步骤算成多次独立故障。拆分后则要检查现有看板是否仍然覆盖全部必要来源。格式保持JSON，并不会自动保证旧指标对新目的地的选择仍然正确。
本文建议用一条无敏感内容的测试文件做验收：记录它触发的工作流与执行状态，核对选定日志组中的步骤记录，再确认原服务器日志查询的预期变化。安排一个可控失败案例，检查异常步骤是否进入对应查询和告警，并验证处理产物确实符合预期。
最后检查日志组的保留期限、访问范围与使用成本。公告没有声明CloudWatch日志存储和查询免费，也不能因为不再需要服务器日志角色，就推导出任何调用者都可读取目标组。对日志有保存要求的团队，应将新的归集位置写进值班说明和审计材料。
这次更新让日志组织方式更贴近工作流本身。要让它产生维护收益，需要把目的地、查询、指标和负责人员一起更新，而不只是确认创建页面多了一个选择项。
来源与核对时间
资料核对：2026年10月3日（北京时间）。本文未修改云端日志配置，验收流程为原创建议。
