AWS Transform 可转换 Azure .NET 代码，但迁移仍需架构审查

AWS 已为 AWS Transform 中的一项代码转换功能提供正式版本，可将现代 .NET 应用中部分 Azure SDK 调用改写为对应的 AWS 调用。该公告于 10 月 16 日发布，涵盖从 Azure Functions 到 AWS Lambda、从 Azure Blob Storage 到 Amazon S3，以及从 Azure Queue Storage 到 Amazon SQS 的转换。Azure Cosmos DB 到 Amazon DynamoDB 的转换目前作为预览功能提供。

它的直接吸引力很容易理解：团队可以提交一个已经在 Azure 上运行的应用，让代理识别受支持的云依赖，并获得转换后的代码库，而不必从头开始逐项重写服务。更重要的运维层面在于，这是一种源代码转换，并不是一次完整的云迁移。它不会重建 Azure 网络、迁移数据、复现身份策略，也不会证明转换后的应用仍具有相同的故障和一致性行为。

平台和工程团队评估这项功能时，应以这一差异为出发点。应把 AWS Transform 视为范围明确的现代化工作流加速器，而不是接受一份自动生成的拉取请求后就获准切换云服务商。

AWS 宣布了什么

AWS Transform 的 .NET 现代化代理可以检查提交的源代码、识别 Azure SDK 的使用情况，并在评估报告和现代化计划中列出转换选项。团队可以接受这些选项、修改它们，也可以在转换运行前选择退出。

正式发布的映射范围有意保持狭窄：

• Azure Functions 可以转换为 AWS Lambda 函数。
• Azure Blob Storage SDK 调用可以转换为 Amazon S3 SDK 调用。
• Azure Queue Storage 调用可以转换为 Amazon SQS 调用。
• Azure Cosmos DB 到 Amazon DynamoDB 的转换被列为预览功能。

AWS 表示，该功能在八个区域可用：美国东部（弗吉尼亚北部）、亚太地区（孟买、东京和首尔）、亚太地区（悉尼）、加拿大（中部），以及欧洲（法兰克福和伦敦）。文档还明确说明了一个重要限制：该功能转换应用代码，但不负责云基础设施迁移。

这项限制并不是脚注。在真实服务中，SDK 只是云服务商依赖的一层。Azure Function 可能依赖托管计划、托管标识、应用设置、私有终结点、部署槽位、事件绑定、存储账户、Key Vault 引用、监控规则和网络限制。替换命名空间和方法调用后，周边假设仍需要由人员发现并重建。

因此，AWS 的这项功能解决的是迁移成本中一个清晰可辨的部分：翻译特定于服务商的应用代码。它并没有消除定义目标架构的必要性。

为什么“等效服务”不等于等效行为

云服务名称容易制造出虚假的对称性。Blob Storage 和 S3 都是对象存储；Azure Queue Storage 和 SQS 都是队列服务；Azure Functions 和 Lambda 都是无服务器计算平台。在 API 层面，这些比较有参考价值；到了运行时，它们却并不完整。

迁移团队首先要问的，不是某个方法能否被转换，而是应用的契约能否在转换后继续成立。

对象存储是一个很好的例子。一段代码可能会上传对象、设置元数据、生成临时 URL，然后假设某种可见性延迟、覆盖行为、校验和约定或授权模型。目标服务可能支持类似操作，但默认值、请求头、错误类型、生命周期机制或策略术语不同。机械转换后的调用可以成功编译，却仍可能改变下游系统所观察到的行为。

队列也存在类似问题。生产者和消费者的耦合不只体现在发送方法上。它们还依赖投递语义、可见性超时、保留期限、最大消息大小、顺序预期、死信行为、重新投递策略、重复消息处理和重试时机。从 Azure Queue Storage 转换为 SQS，可能会生成有效的 AWS 调用，却无法证明消费者在消息重新投递时仍然安全，也无法证明现有的毒消息处理流程仍能正常运行。

函数又增加了一层复杂性。Azure Function 可能由 HTTP 请求、队列、定时器、事件流，或隐藏了特定云厂商底层连接逻辑的绑定触发。Lambda 也有自己的事件源、调用模式、并发控制、超时限制、部署打包方式、权限体系和可观测性模型。如果原应用依赖长时间运行的进程、本地文件系统持久化、特定的预热模式，或依赖绑定生成的请求形状，那么目标实现就需要开展超出 SDK 转换范围的设计工作。

实际结果很简单：编译成功只是早期信号，不能作为迁移验收标准。

正确解读评估报告

AWS Transform 的工作流很有用，因为它把转换决策放在转换执行之前。这样，团队就有机会审查拟议的目标方案，而不是等代码生成后才发现所有选择。

应将这份报告视为一份附带判断意见的依赖清单。

先将依赖分为三类：

1. 直接支持的调用。 这些是工具声明可以转换的 SDK 引用。它们适合进行自动化转换，但转换结果并不会因此自动正确。
2. 相邻的云厂商依赖。 其中包括身份、配置、网络、部署、日志、追踪、密钥、事件绑定和基础设施定义。这些内容可能出现在同一个代码仓库中，但不在列出的服务映射覆盖范围内。
3. 业务行为。 其中包括幂等性、顺序、保留策略、授权意图、数据验证、恢复流程，以及面向用户的错误处理。不能安全地从一对一的服务映射中推断出这些内容。

还应审查报告中的目标服务选择。AWS 的文档说明了默认目标，但允许团队自定义计划，包括选择退出部分或全部转换，以及改道某个默认映射。当目标架构并非字面意义上的服务替换时，这一点很重要。例如，团队可以选择在应用中保留面向对象的接口，同时引入存储适配器；也可以在衡量吞吐量和顺序要求后，决定将某项队列负载交给另一种集成服务。

一个有用的审查材料是为每项云厂商特定依赖建立一行的表格：

目的不是增加官僚流程，而是避免生成的差异成为事实上的架构文档。

该功能的优势

如果应用使用受支持的 Azure SDK，并且采用常规 .NET 代码，那么确实可以提高效率。该工具能够查找服务引用、提供现代化计划，并以原本需要大量开发时间的规模重写已知模式。根据 AWS 文档，在无法转换的地方，它还可以留下明确标记，包括 TODO 注释、存根或后续步骤文档。

这在三种情况下尤其有价值。

第一种是组合评估。拥有大量 .NET 服务的组织，可以利用分析结果了解每个应用与 Azure 的绑定程度。即使某项服务尚未准备好迁移，这一结果也能帮助改进迁移排序。

第二种是重复性转换阶段。一旦目标契约和基础设施模式确定，自动化编辑就能消除大量机械性工作。工程师可以把更多时间用于处理行为，把更少时间花在修改命名空间、客户端构造和常规请求形状上。

第三种是受控的现代化分支。团队可以针对应用副本运行转换，将输出与现有抽象边界进行比较，并利用生成的差异找出应在迁移开始前隔离的代码。

当代码库主要由基础设施即代码、文档不完善的绑定、自定义 Azure 集成、复杂的数据访问模式，或将供应商行为视为业务契约一部分的应用逻辑构成时，这项功能的作用会比较有限。这些场景仍可能受益于代码分析，但不应把转换误认为完整的迁移计划。

身份问题不只是更换客户端构造函数

供应商迁移经常在应用代码与授权的边界处失败。Azure 应用通常使用托管标识和角色分配。AWS 应用则使用 IAM 角色和策略，具体取决于运行时环境，权限可能附加到执行角色、任务角色、实例配置文件或其他身份上。

转换后的 SDK 调用本身并不具备任何权限。目标部署必须提供一个身份，能够对确切的资源执行确切的所需操作。这不仅意味着将“可以读取 Blob”映射为“可以读取对象”，还要映射访问范围、条件、资源名称、加密密钥、网络路径以及该访问权限的运维归属。

迁移审查应回答以下问题：

• 每个函数、工作进程和部署作业分别由哪个身份执行？
• 哪些资源策略和身份策略共同授权了这次调用？
• 目标环境是否使用客户托管的加密密钥？谁可以使用这些密钥？
• 工作负载能否通过预期的网络路径访问服务？
• 凭证是否为短期凭证，并且无需修改应用即可轮换？
• 授权检查失败时会记录什么？

这正是仅依赖代码转换可能造成完成假象的地方。应用可能成功编译，测试可能在宽泛权限下通过，但生产部署仍可能失败，因为真正的策略边界从未被设计过。反过来，授予一个范围过大的角色，可能让迁移“运行起来”，却扩大了故障影响范围。

因此，安全验收测试还应包括被拒绝的操作、跨资源访问尝试，以及从干净环境执行部署。迁移并不是在顺利路径上的请求成功时就完成了；只有当目标身份模型得到理解并受到约束时，迁移才算完成。

数据迁移和数据语义仍然需要人工处理

AWS Transform 不会迁移 Azure Blob Storage、Azure Queue Storage 或 Cosmos DB 背后的数据。这听起来显而易见，但它会改变项目进度安排。只有在团队明确两个版本将如何共存之后，代码转换和数据迁移才能并行推进。

对于对象数据，计划需要包括源数据清单、大小和对象数量估算、元数据与标签处理、加密要求、保留规则、访问日志以及切换策略。复制过程如果保留了字节却丢失了元数据，仍然可能导致消费者出错。即使每个对象都已成功到达，切换过程中改变 URL 生成方式或授权语义，也可能破坏客户端。

对于队列，复制消息很少是一项中性的操作。团队必须决定旧消息应当被排空、重放、丢弃，还是转换。重放可能触发两次副作用。排空可能延长迁移窗口。双写设计则可能造成数据分歧：一个供应商接受消息，而另一个供应商拒绝消息。更安全的选择取决于工作负载的幂等性及其业务后果。

对于数据库，Cosmos DB 到 DynamoDB 目前处于预览状态，这是需要格外谨慎的信号。NoSQL 系统在分区、索引、一致性、事务范围、查询语言、项目大小限制和变更馈送行为方面往往存在差异。转换后的数据访问层并不能证明目标数据模型能够扩展，也不能证明它会返回相同的结果。在承诺进行线上切换之前，团队应先对具有代表性的访问模式建模，并运行数据质量检查。

迁移计划应在每个阶段明确数据源的权威来源。“数据同时存在于两朵云中”并不是一致性策略。

测试应比较契约，而不只是比较输出

传统的单元测试套件可能会验证转换后的代码通过模拟客户端返回预期值。这是必要的，但还不够，因为模拟对象通常保留了原供应商设计的抽象。

更强的测试计划应包含多个层次。

契约测试验证应用自身的预期：消息架构、对象元数据、授权决策、重试处理和错误分类。凡是行为至关重要的部分，都应针对目标服务运行这些测试。

差异测试让等价工作负载分别运行于源实现和目标实现，并比较业务层面的结果。比较不应要求服务商返回完全相同的错误或请求 ID，而应检查用户、下游服务和运维人员所依赖的行为。

故障测试注入限流、超时、部分写入、重复投递、凭证过期、依赖项不可用以及格式错误的事件。目标是暴露源端与目标端故障模型之间的差异。

运维测试验证日志、指标、追踪、告警、仪表板和运行手册。一个迁移后的服务即使能够运行，却无法诊断问题，也还没有准备好投入生产。

安全测试确认策略遵循最小权限原则，并验证工作负载无法读取、写入或调用其预定边界之外的资源。

对于无服务器工作负载，应纳入并发和冷启动行为、超时余量、事件源重试以及部署回滚测试。对于队列，应根据实际处理分布测量可见性超时，而不是直接选用一个熟悉的数值。对于对象存储，应测试元数据、加密、条件写入和访问 URL。对于数据库转换，应重放真实的查询形态，并比较分页、一致性和故障处理。

更安全的迁移顺序

评估这项新能力的团队，可以通过缩小首个项目的范围来降低风险。

选择一个所有权明确、所依赖的受支持服务商依赖数量有限、并且具备可测试回滚方案的服务。不要从同时包含身份联合、事件扇出、受监管数据和未文档化运维流程的系统开始。

运行转换前，先建立源端依赖关系图。内容应包括 SDK 包、环境变量、绑定、部署清单、密钥、网络端点、数据存储、队列、定时触发器和监控集成。

随后定义目标端契约。确定应用将如何表示存储、消息传递、配置、身份和遥测。如果服务商特定调用散落在业务逻辑中，应在转换前引入或强化适配器。这样会增加准备工作，但能让最终差异更易于审查，也能降低未来变更的成本。

运行评估，并审查每一项拟议映射。记录有意跳过的内容。把不受支持的调用视为已规划的工作，而不是可以留到最后再处理的清理事项。

单独创建目标基础设施。使用范围严格限定的 IAM 角色、加密资源、必要时的私有连接、日志、告警、备份和部署控制。不要把生成的应用代码当作基础设施审查的替代品。

在分支中转换代码，编译代码并运行静态分析。然后使用具有代表性的数据，针对真实的目标服务进行测试，并注入故障。在迁移的业务契约和运维契约得到验证之前，应保留源实现可用。

切换时，优先采用可逆的顺序：先部署但不接收实际流量，验证读取操作，执行非破坏性写入，比较遥测数据，逐步转移少量流量或工作负载，并在提高占比前定义回滚触发条件。具体机制会因应用而异，但原则始终相同：转换应缩短机械执行阶段，却不应缩短证据收集阶段。

平台团队需要面对的治理问题

AWS Transform 改变了代码转换的经济性，这意味着更多组织可能只需较小的团队，就能尝试服务商迁移。这一点很有用，但也可能让风险更早进入流程。当代码转换变得廉价，架构决策和验证就会成为稀缺资源。

平台团队应为生成式迁移建立标准审查关卡。该关卡应要求：

• 完整盘点已转换和未转换的提供商依赖项；
• 获批准的目标架构和身份模型；
• 数据迁移与回滚计划；
• 针对提供商特定语义和故障行为的测试；
• 证明可观测性和事件响应能在目标环境中正常工作的证据；
• 为每个尚未解决的 TODO 或存根指定负责人；
• 对任何已更改的默认映射作出文档化决策。

审核门槛应与风险相称。一个用于存储非敏感对象的小型内部函数，不需要与受监管交易服务相同的流程。但两者都需要明确的负责人，以及能够证明转换后行为可接受的方式。

关键政策是让生成的代码保持可审查性。应将评估报告、现代化计划、转换差异、测试证据和例外情况，与服务的变更记录一并保存。如果之后重新运行转换，团队应能够解释发生了哪些变化，以及变化的原因。

接下来需要关注什么

当前公告涵盖一组范围明确的 Azure 到 AWS 映射，并且仍将 Cosmos DB 到 DynamoDB 的转换列为预览功能。这表明 AWS 目前从常见且容易识别的转换点入手，而不是宣称实现普遍的可移植性。

团队应关注受支持的 .NET 版本、更多 Azure 服务、基础设施处理能力，以及工具报告不确定转换的方式是否发生变化。同时也要关注自身的测试结果。某种模式在小型服务中看似等价，但在更高负载、重试场景或更严格的身份策略下，行为可能不同。

目前，实际可行的建议是：在 AWS Transform 最擅长的地方使用它，即盘点依赖项并加速重复性的代码修改。架构、数据、身份和生产环境验收则应继续接受明确的人工审查。该功能可以让迁移分支迅速成形，却无法让两朵云共享同一套契约。

这正是平台团队在批准第一个拉取请求之前需要作出的判断：问题不是“代理是否完成了代码转换？”，而是“有哪些证据表明，在提供商边界迁移之后，这项服务仍能正确、安全且可运维地运行？”