目录

据 2026 年 10 月 20 日的报道，AWS Transform 现已支持将 .NET 应用中的 Azure SDK 代码转换为使用 AWS SDK 的代码。该功能支持从 Azure Functions 转换到 AWS Lambda 等场景，但团队仍需验证运行情况，并处理工具无法转换的代码。

要点#

  • AWS Transform 新增了针对使用 Azure 服务的 .NET 应用的代码转换功能。
  • 支持函数、对象存储、队列和 NoSQL 数据库的转换。
  • 没有对应转换目标的代码，可能会被替换为 TODO 注释、桩代码，或单独 Markdown 文件中的指导说明。
  • 请将转换后的应用视为迁移候选版本，在部署前进行审查和测试。

AWS Transform 转换哪些内容#

本次更新针对特定的迁移问题。使用 Azure SDK 构建的 .NET 应用依赖 Azure 服务。将这些应用迁移到 AWS 时，除了移动应用文件，还需要修改服务调用。

AWS Transform 支持以下 4 组服务之间的转换。

| Azure 服务 | AWS 迁移目标 | |---|---| | Azure Functions | AWS Lambda | | Azure Blob Storage | Amazon S3 | | Azure Queue Storage | Amazon SQS | | Azure Cosmos DB | Amazon DynamoDB |

这些对应关系可作为替换 Azure 依赖的起点，但并不保证所有功能、配置和使用模式都有直接对应的实现。所提供的报道未说明各项服务的详细支持范围。

此次更新适用的场景#

实际好处在于减少开发者需要手动重写的服务集成代码。例如，对于将文件保存到 Azure Blob Storage 的应用，可以将相关调用转换为面向 Amazon S3 的调用。同样的方法也适用于受支持的计算、队列和数据库集成。

因此，如果现有 .NET 应用使用了列表中的 Azure 服务，并且正在考虑迁移到 AWS，这项功能就能派上用场。在项目中采用之前，请先梳理应用的实际依赖。服务名称出现在支持列表中是有用的判断依据，但仍需确认应用使用的操作和功能是否受支持。

这里描述的范围是代码转换。根据所提供的报道，无法确认 AWS Transform 是否还会为这些应用迁移数据、构建全部所需基础设施，以及完成生产环境切换。请在迁移计划中将这些工作作为独立任务管理。

审查未完成的转换#

AWS Transform 会通过 TODO 注释、称为桩代码的临时实现，或标为“Next Step”的单独 Markdown 文件，指出尚未处理的工作。开发者需要逐一检查这些输出。

桩代码尤其需要注意，因为必要的行为可能仍未实现。仅凭构建成功，无法判断迁移后的应用能否正常运行。请对照原应用的行为审查转换后的代码，包括故障处理。

请使用以下 4 项审查清单。

  • TODO 注释： 确认缺失的行为，并指定负责人。
  • 桩代码： 在发布前，将临时实现替换为可正常工作的实现。
  • Next Step 指导说明： 将每条相关指示转化为可跟踪的任务。
  • 转换后的调用： 确认输入、输出和错误处理是否保留了所需行为。

测试服务行为#

源服务和目标服务的用途相似，但 API 和运行规则可能有所不同。验证时，不应只检查新的 SDK 调用能否编译，还应根据应用需求进行检查。

对于从 Azure Functions 转换而来的代码，请测试 Lambda 函数接收事件、返回结果和处理故障的方式。对于存储代码，请验证文件内容、应用依赖的元数据和访问权限。队列测试应检查重试和重复处理。数据库测试则应针对所采用的 DynamoDB 设计，检查应用的查询和更新行为。

这些是迁移时的检查事项，并非 AWS Transform 已确认的限制。所提供的报道没有给出转换成功率的测量值，也没有证据表明生成的代码能完整保留应用行为。请在执行转换前制定验收标准，以便按明确的标准评估结果。

后续步骤#

选择一个使用受支持 Azure 服务的非生产环境 .NET 组件，通过 AWS Transform 进行试验性转换。记录所有 TODO、桩代码和 Next Step 项目，测试该组件的主要操作和一个故障场景，然后再决定是否扩大迁移范围。

来源: https://www.publickey1.jp/blog/26/aws_transformazure_functionsaws_lambdamicrosoft_azureaws.html

目录