View a markdown version of this page

AWS-托管转型 - AWS 转换

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

AWS-托管转型

AWS-managed 转换是预先构建的、 AWS经过审查的转换,适用于常见用例,无需任何其他设置即可使用。

概述

AWS-管理的转换具有以下特征:

  • 验证者 AWS-这些转换经过审核 AWS ,质量很高

  • 随时可用-无需额外设置

  • 持续增长-不断添加其他转换

  • 可定@@ -可以通过使用additionalPlanContext配置参数提供针对组织需求的额外指导或要求来定制 Pre-built 转换

  • 抢先体验支持-某些变更可能会被标记为抢先体验,因为它们经过进一步的测试和完善

可用 AWS-托管转型

以下目录按用例分组列出了当前可用的 AWS托管转换。每个表都显示转换名称、其适用的语言或堆栈及其状态。要快速找到转换,请使用本页顶部的搜索框按名称、语言或用例进行搜索。

此目录是托管转换的 AWS规范列表。Kiro Power、代理插件、VS Code 插件和 CLI 都运行相同的转换。要列出注册表中可用的转换,请运行atx custom def list

注意

标有 “抢先体验” 的转换可以正常运行,但可能会根据客户反馈经常更新。

运行时升级

将语言或运行时升级到新版本,或者更改运行时分布。

转换 语言/堆栈 Status 说明
AWS/java-version-upgrade Java 正式发布 使用任何编译系统将 Java 应用程序从任何源 JDK 版本升级到任何目标 JDK 版本,依赖关系现代化包括 Jakarta EE 迁移、数据库驱动程序、ORM 框架和 Spring 生态系统更新。在聊天中或使用additionalPlanContext参数指定目标 JDK 版本。
AWS/python-version-upgrade Python 正式发布 将 Python 项目从 Python 3.8 或 3.9 迁移到 Python 3.11、3.12 或 3.13,同时保持功能和性能。在聊天中或使用additionalPlanContext参数指定目标 Python 版本。
AWS/nodejs-version-upgrade Node.js 正式发布 将 Node.js 应用程序从任何源 Node.js 版本升级到任何目标 Node.js 版本。在聊天中或使用additionalPlanContext参数指定目标版本。
AWS/lambda-nodejs-runtime-upgrade Node.js (Lambda) 抢先体验 将 AWS Lambda 函数从较旧的 Node.js 运行时(nodejs4.3 到 nodejs22.x)升级到 nodejs24.x,以解决 Lambda 运行时接口客户端 (RIC) 和 24 语言运行时中的重大变化。 Node.js
AWS/oracle-java-to-corretto Java(JDK 发行版) 抢先体验 将 Java 项目从 Oracle JDK 迁移到 Amazon Corretto。将 Oracle-specific 内部 API 替换为标准 Java 等效项,更新编译配置(Maven 和 Gradle)和容器基础镜像,移除商用 JVM 标志,并生成许可报告。
AWS/ruby-upgrade Ruby 抢先体验 将 Ruby 应用程序从 Ruby 2.x 升级到 Ruby 4.0,将其框架升级到 Rails 8.0 或 Sinatra 4.1。你可以将这种转换与 Rails 和 ActiveRecord 应用程序、Sinatra 应用程序和独立 gem 一起使用。该转换将每个 Ruby 版本与匹配的框架升级配对,然后运行测试套件。然后,它会在升级到下一个版本之前隔离故障。

软件开发工具包迁移

在 AWS SDK 的主要版本之间迁移。

转换 语言/堆栈 Status 说明
AWS/java-aws-sdk-v1-to-v2 Java 正式发布 使用 Maven 或 Gradle 将 Java 项目的 AWS SDK 从 v1 升级到 v2。
AWS/python-boto2-to-boto3 Python 正式发布 根据官方迁移文档,将 Python 应用程序从 boto2 迁移到 boto3。 AWS
AWS/nodejs-aws-sdk-v2-to-v3 Node.js 正式发布 无需更改版本,即可将 Node.js 应用程序从 JavaScript v2 Node.js 版 AWS SDK 升级到 v3,以获得模块化架构、一流 TypeScript 支持和更高的性能。

框架升级和迁移

将框架升级到新版本,或迁移到其他框架。

转换 语言/堆栈 Status 说明
AWS/spring-boot-version-upgrade Java /春靴 正式发布 将较旧的 Spring Boot 应用程序升级到目标 Spring Boot 版本,包括构建文件和启动程序、属性、Jackson 3 软件包、Spring Security 7 DSL、测试基础架构和可观察性依赖项。
AWS/JBoss-to-Spring-Boot Java(JBoss 或者 WildFly 到 Spring Boot) 抢先体验 将在 JBoss EAP 上运行的 Java EE 或 Jakarta EE 企业应用程序迁移 WildFly 到 Spring Boot,从而消除云原生容器化部署模型对应用程序服务器的依赖。
AWS/early-access-angular-to-react-migration 反应有角度 抢先体验 将 Angular 应用程序转换为 React。
AWS/angular-version-upgrade Angular 抢先体验 将较旧的 Angular 应用程序升级到目标 Angular 版本,包括组件、服务、模板和路由。
AWS/vue.js-version-upgrade Vue.js 抢先体验 执行从 Vue.js 2 到 Vue.js 3 的主要版本升级,对组件、状态管理、路由和全局 API 进行现代化改造。次要更新和补丁更新不在范围内。

GenAI 和模型迁移

将生成式 AI 工作负载迁移到.

转换 语言/堆栈 Status 说明
AWS/GenAI-to-Bedrock-Migration-Assessment 生成式 AI 工作负载 抢先体验 评估生成式人工智能工作负载,以便从第三方提供商(OpenAI、Google Gemini、Anthropic direct 和开源模型)迁移到。发现 SDK 的使用情况和模型,阐明需求,设计模型映射,估算成本和风险,并生成评估项目。 Assessment-only; 不修改源代码。还涵盖代理框架,例如 CrewaI LangGraph、和 Strands。

Language-to-language 迁移

将代码库从一种编程语言翻译成另一种编程语言。

转换 语言/堆栈 Status 说明
AWS/vba-to-python-migration VBA 到 Python 抢先体验 使用 openpyxl、pandas、tkinter 或 6 以及标准库将 Excel VBA 宏、模块和嵌入式逻辑迁移到等效的 Python 脚本和模块。 UserForms PyQt目标语言是 Python 3.8 或更高版本。在转换.bas、.cls、.frm 或嵌入.xlsm 的 VBA 代码时使用。

数据库迁移

目前没有特定于数据库的 AWS托管转换可用。要将微软 SQL Server 数据库及其关联的.NET 应用程序现代化为亚马逊 Aurora PostgreSQL,请参阅。SQL 服务器现代化

可观测性

将日志记录和监控现代化为 AWS原生服务。

转换 语言/堆栈 Status 说明
AWS/early-access-log4j-to-slf4j-migration Java(日志记录) 抢先体验 使用 Logback 后端将 Java 应用程序从 Log4j(1.x 或 2.x)迁移到带有 Logback 后端的 SLF4J。处理源代码、依赖关系管理(Maven 和 Gradle)和日志配置文件,并通过编译、测试和剩余导入扫描进行验证。
AWS/datadog-monitors-to-cloudwatch-alarms 基础设施即代码/监控 抢先体验 将跟踪 AWS 服务指标和自定义指标的指标监控器作为基础架构即代码迁移 DataDog 到原生 CloudWatch 警报。生成 CloudFormation YAML、CDK TypeScript 和 Terraform HCL。

架构

Re-architect、重新构建平台或优化应用程序。 AWS

转换 语言/堆栈 Status 说明
AWS/java-performance-optimization Java(性能) 正式发布 通过分析 JFR 分析数据来检测 CPU 和内存热点以及反模式,然后应用有针对性的代码修复,从而优化 Java 应用程序的性能。有关收集 JFR 数据的说明,请参阅 JFR 运行时指南。
AWS/early-access-java-x86-to-graviton Java(Arm64 /Graviton) 抢先体验 验证 Java 应用程序与 Grav AWS iton 处理器的 Arm64 架构的兼容性,并通过更新依赖关系、检测特定架构的代码模式以及在源代码可用时重新编译原生库来解决不兼容问题。许多现代 Java 应用程序已经存在 Arm64-compatible。
AWS/oracle-service-bus-to-aws Java/集成到无服务器 抢先体验 将 Oracle 服务总线 (OSB) 和 BPEL 流程配置迁移到 AWS原生无服务器架构, TypeScript 使用 Amazon API Gateway、Lambda AWS 和 Step Functions 生成可部署的 CDK 项目。 AWS
AWS/mulesoft-to-aws-native Java/ MuleSoft 到无服务器 抢先体验 将 MuleSoft Mule 3.x 和 4.x 应用程序转换为以 Lambda 上的 Java 17 为目标的 AWS 无服务器架构(亚马逊 API Gateway AWS 、Lambda 和 Step F AWS unctions) AWS SnapStart 转换将流触发器映射到 AWS 事件源,转换 DataWeave 和 MEL(MuleSoft 表达式语言)表达式为 AWS 等效表达式,并将连接器替换为 AWS SDK for Java v2 调用。它生成 SAM 模板、 AWS Lambda 处理程序和 JUnit 5 测试。
AWS/payshield-hsm-to-aws-payment-cryptography Java(从密码管理到 AWS 支付密码学) 正式发布 将 Java 应用程序从泰雷兹 PayShield 硬件安全模块 (HSM) 协议迁移到 AWS 支付密码学 SDK v2。迁移包括命令映射、密钥迁移、依赖关系设置和奇偶校验测试。

代码库分析

分析代码库和产品组合以规划现代化。这些转换会生成报告,并且不会修改您的代码。

转换 语言/堆栈 Status 说明
AWS/comprehensive-codebase-analysis 多种语言 正式发布 对代码库进行深度静态分析,生成分层、交叉引用的文档,该文档结合了行为分析、架构文档和商业智能,重点是技术债务见解。
AWS/agentic-readiness-analysis 多种语言 抢先体验 评估系统是否已准备好被 AI 代理安全调用,包括 API、身份、状态管理、人机在环和可观察性。
AWS/modernization-readiness-analysis 多种语言 抢先体验 扫描产品组合以了解云原生成熟度差距,并将发现结果与 AWS 现代化路径对应起来。
AWS/portfolio-agentic-readiness-analysis Portfolio 抢先体验 汇总应用程序组合中的各个代理就绪情况分析报告,以确定跨领域障碍、共同的补救模式和按优先顺序排列的建议。
AWS/portfolio-modernization-readiness-analysis Portfolio 抢先体验 将整个投资组合中的个人现代化分析报告汇总成一个合并的路线图,其中包含优先考虑的迁移浪潮和推荐的现代化路径。
AWS/business-rules-extraction 多种语言 抢先体验 此转换会静态分析整体代码库以生成可重写的文档,而无需构建、运行或修改源代码。它将系统分解为有界域,并提取每个域的业务规则、工作流程、跨领域问题和数据库结构。输出包括机器可读的清单、交互式仪表板以及每个域的语言中立实现规范,以指导现代化或完全重写。

自定义 AWS-托管转型

您可以通过additionalPlanContext配置 AWS参数提供其他上下文,自定义托管转换以满足组织的特定需求。

示例:自定义 Java 版本升级

codeRepositoryPath: ./my-project transformationName: AWS/java-version-upgrade buildCommand: mvn clean install additionalPlanContext: | The target Java version to upgrade to is Java 17. Update all internal library dependencies to versions compatible with Java 17. Ensure compatibility with our custom authentication framework.

示例:自定义 AWS SDK 迁移

codeRepositoryPath: ./my-project transformationName: AWS/java-aws-sdk-v1-to-v2 buildCommand: gradle build additionalPlanContext: | Maintain our existing error handling patterns. Use our organization's standard credential provider chain. Update logging to use our internal logging framework.