我们如何将 AWS Amplify GraphQL 后端迁移到 CDK（无需重写）

AWS Amplify 对于启动 GraphQL 后端非常出色。它减少了摩擦，快速搭建基础设施，并让小团队能够快速行动。但随着系统的发展，许多团队会遇到这样的情况：Amplify 从加速器变成了限制因素。在这篇文章中，我将带您了解我们如何将一个现有的 AWS Amplify AppSync 后端迁移到 AWS CDK，而无需重写业务逻辑、为什么这样做，以及我们在此过程中学到的东西。这不是一篇反 Amplify 的文章，而是关于理解 Amplify 适合的领域——以及它在何处停止扩展。

Amplify 表现良好的时候

Amplify 是一个很好的选择，当你：

• 处于项目的早期阶段
• 希望进行快速的模式驱动开发
• 对 Amplify 托管的 CloudFormation 感到满意
• 不需要细粒度的 IAM 控制或自定义管道

我们在开始时正是这样使用 Amplify 的。使用 @model、@auth 和 connections 等指令，Amplify 生成了：

• 一个 AppSync GraphQL API
• DynamoDB 表
• VTL 解析器
• IAM 角色
• 需要时的 Lambda 数据源

在很长一段时间里，这运行得很好。

我们最终遇到的问题

随着后端的发展，一些问题变得越来越不容忽视。

1. 有限的控制和可见性

Amplify 抽象掉了大量的基础设施：

• IAM 权限是自动生成的
• CloudFormation 堆栈是隐藏的
• 资源命名是不透明的

这使得：

• 代码审查变得困难
• 安全审查变得痛苦
• 调试部署变得困难

2. 困难的多环境和平台集成

我们想要：

• 明确的开发/预发布/生产环境
• 与现有的基于 CDK 的平台集成
• 可预测的差异和回滚

Amplify 基于 CLI 的工作流程不太适合这一点。

3. 一个硬性的 CloudFormation 扩展限制

这是真正的推动因素。AWS CloudFormation 强制规定每个堆栈最多 500 个资源的硬性限制。 Amplify 将大多数 GraphQL 后端部署到一个或极少数 CloudFormation 堆栈中。随着模式增长，生成资源的数量快速增长：

• 解析器
• 函数
• IAM 角色和策略
• DynamoDB 表和 GSI

一旦每个堆栈接近 500 个资源的限制：

• 部署变得脆弱
• 添加新的模型或解析器可能会失败
• 在 Amplify 中没有受支持的方式来拆分或重构生成的堆栈

此时，后端的演化基本上停滞了。

为什么我们没有重写一切

当我们遇到这些限制时，我们已经拥有：

• 一个大型 GraphQL 模式
• 自定义 VTL 解析器
• 基于 Lambda 的业务逻辑
• DynamoDB 中的生产数据

完全重写将是：

• 有风险的
• 耗时的
• 不必要的

相反，我们提出了一个不同的问题：

• 如果 Amplify 只用于生成初始工件——而不永久拥有后端会怎样？

第 1 步：使用 Amplify 一次——作为脚手架工具

核心思想是，Amplify 可以保留为你的编译器，而 CDK 成为你的部署引擎。我们将 Amplify 视为生成器，而不是长期平台。 使用 Amplify，我们生成了：

• schema.graphql
• .vtl 解析器模板
• 构建工件：
  • build/cloudformation-template.json
  • build/stacks/*.json
  • build/resolvers/*.vtl
• 嵌入在解析器中的授权逻辑

在这个阶段，Amplify 很好地完成了它的工作。

第 2 步：提取持久资产

从 Amplify 后端输出中，我们只提取了持久且有价值的资产：

• GraphQL 模式
• 解析器模板
• 表定义
• 授权规则和逻辑

我们明确没有保留：

• Amplify CLI
• Amplify Console
• 自动生成的 CloudFormation 堆栈

这些是实现细节——不是架构。

第 3 步：在 AWS CDK 中显式地重建

每个由 Amplify 生成的资源都在 AWS CDK 中被显式地重新实现。CDK 接管了：

• AppSync API + 数据源
• FunctionConfigurations
• 管道解析器
• IAM 角色/策略
• DynamoDB 表（可选）
• Lambda 数据源（可选）

我们不是直接部署 Amplify 堆栈，而是将意图提取到 YAML 中，并从那里重新部署。这消除了 Amplify 的“魔法”并使行为可预测。

第 4 步：将后端拆分为多个 CDK 堆栈

与 Amplify 的单体堆栈不同，CDK 允许我们：

• 将 AppSync、DynamoDB、Lambda 和 IAM 拆分成独立的堆栈
• 控制资源边界
• 完全避免 CloudFormation 的 500 资源限制

这一单一的改变消除了一个主要的长期可扩展性风险。

第 5 步：配置驱动、环境感知设计

我们用以下方式取代了 CLI 驱动的配置：

• 基于 YAML 的配置文件
• 特定环境的定义（开发、预发布、生产）
• 确定性的命名
• 可通过 cdk diff 进行审查的差异

现在的部署看起来像：

1
2

cdk diff -c env=staging
cdk deploy -c env=staging

CDK 成为唯一的真理源。

第 6 步：完全移除 Amplify

一旦确认功能对等：

• Amplify 项目被移除
• Amplify Console 断开连接
• 不再有 amplify push

从那时起：

• 基础设施变更经过代码审查
• 部署是可预测的
• 扩展不再受堆栈限制的制约

我们学到了什么

• Amplify 非常适用于脚手架搭建
• 它不是为大型、长期存在的后端设计的
• CloudFormation 的 500 资源限制是一个真实的约束
• 迁移比重写更安全
• 明确的 CDK 所有权在扩展时能迅速带来回报

想要完整的设置？

我们将这种方法打包成了一个可复用的包，包括：

• 一个生产级的 CDK AppSync 后端
• 配置驱动的解析器和 Lambda 连接
• 迁移清单和来之不易的经验教训
• 真实世界的示例（不是玩具演示）

👉 Gumroad: https://stackopsai.gumroad.com/l/eizwk

最后感想

这次迁移不是关于拒绝 Amplify。而是关于在正确阶段使用正确的工具。 Amplify 帮助我们在早期快速行动。CDK 帮助我们在扩展时安全地行动。 如果你也接近同样的限制，这里有一个干净的出口——无需重写。