AWS Console-to-Code 新增 26 项服务：跨区域录制怎么验收

很多团队在AWS控制台做完跨区域配置之后，最头疼的不是操作完没留下代码，而是录制出来的结果把不同区域、不同浏览器标签页的动作拆得七零八落，事后根本没法确认哪些步骤属于同一套基础设施。AWS 推出的Console-to-Code功能这次新增26项服务支持，总数从原先的6项扩展到32项，同时上线了跨区域和跨浏览器标签页录制的能力。

这项更新刚好可以用来整理控制台的探索流程：先录下整个可复现的操作过程，再查看自动生成的基础设施即代码，最后切回目标区域做一轮最小验证就好。要注意生成的结果还是得人工过一遍，不能觉得“能自动生成代码”就直接不评审往线上发。

AWS Console-to-Code 这次更新解决了什么

以前的控制台录制基本只适合单区域、单页面的短流程。一旦操作中途要切换区域，或者开不同浏览器标签页查依赖资源，动作列表很容易就断了连续性。AWS 这次把跨区域和跨标签页录制作为配套能力一起放出来，核心变化不是多了一个导出按钮，而是整个录制的上下文可以连贯保留。

先把跨区域操作录成一条可解释的链路

开始录制之前先理清楚本次操作的边界：起始区域、目标区域、资源名称和想要的输出格式。比如先在 us-east-1 创建网络资源，再到 eu-west-1 检查配套资源，最后回到原区域确认标签。名称和区域如果完全依赖浏览器当前状态，生成代码的时候很容易出现“资源定义是对的、部署位置错了”的问题。

1. 打开 Console-to-Code 入口，确认当前 AWS Region 和目标服务匹配。
2. 开始录制后完成第一组资源操作，每次跨区域切换的时候顺手记下区域变化。
3. 需要查依赖资源的时候开新的浏览器标签页操作，避免覆盖原有的操作上下文。
4. 结束录制之前先过一遍动作列表，删掉误点、重复刷新和跟目标资源无关的动作。

这里删掉无关动作的步骤很重要。控制台里的筛选、展开面板和查看详情都只是辅助操作，不一定需要进到最终的IaC代码里；而创建、修改、绑定和权限配置这类操作就得全部保留，还要核对顺序对不对。

生成代码后，按三层检查再交给部署流程

Console-to-Code 的价值就是把控制台里试出来的操作快速转成基础设施代码，省去从零开始写的工作量，但输出的内容本质上还是需要人工审核的草稿。建议把验收分成三层走，不要只看代码能不能过语法检查就完事。

• 资源层：资源类型、名称、区域、依赖关系是不是和录制过程完全对应，尤其要检查跨区域资源有没有被误放到默认区域。
• 参数层：账号 ID、子网、镜像、标签、变量和密钥引用是不是已经替换成环境参数，不能把临时测试值直接带到生产环境。
• 权限层：生成的角色、策略和服务关联权限有没有超出最小权限的范围，先在隔离账号或者测试工作区验证一遍再往下走。

不管输出的是 Terraform 还是 CloudFormation 格式，先做代码差异审查，再到最小测试环境里创建一套完整资源。测试通过之后，把录制动作、生成代码和人工修改的差异记录都留存好，后续复盘的时候才能分清哪些内容来自控制台自动生成，哪些是团队后续补充的工程约束。

常见问题

Console-to-Code 现在支持多少项 AWS 服务？

AWS 公告称，此次新增 26 项服务后，支持范围从 6 项扩展到 32 项。具体动作是否可录制，还要以当前控制台入口和官方文档中的服务列表为准。

跨区域录制会自动部署到多个区域吗？

不会。跨区域录制解决的是动作记录和上下文汇总问题，生成的 IaC 仍需人工检查区域、依赖和权限，再由团队自己的部署流程执行。

跨浏览器标签页录制有什么用？

它适合在一个标签页执行资源操作、另一个标签页查看依赖或权限时保持同一份动作记录，减少切换页面导致的录制中断。

生成的代码可以直接用于生产吗？

不建议直接使用。先检查资源区域、临时参数、敏感信息、权限范围和删除策略，再在隔离环境做最小部署验证。

把 Console-to-Code 当成可审查的起点

这次更新让跨区域、跨标签页的控制台探索更容易沉淀为代码，但最终可靠性还是取决于提前定好的录制边界和后续的人工审查。实际用的时候，把区域与资源名称提前写进操作记录，删掉无关动作，核对生成代码的资源和权限，再把通过测试的结果对接现有IaC流程，才能把临时的控制台尝试变成可重复使用的工程资产。