AWS AppSync 无服务器 GraphQL API 实战：从 0 搭建带实时订阅的全托管 API（2026 深度教程）

📅 2026-10-06 · ChengziCloud - 一站式云端服务

Meta Description: AWS AppSync 无服务器 GraphQL API 实战教程：从 0 搭建全托管 API 与实时订阅，含 CLI 全流程、DynamoDB 直连、定价对比表与免费套餐避坑指南。

> 关键词：AWS AppSync、无服务器 GraphQL、AppSync 教程、AppSync 定价、AWS 免费套餐、实时订阅、Serverless API、AWS 国际版

一句话结论： 如果你要的是一个"不用自己养服务器、天生支持实时推送、还能直接连 DynamoDB"的 API，AppSync 是 AWS 上最省事的托管 GraphQL 服务——没有实例、没有最小费用、按操作数计费，一个中小型应用每月的 API 层账单往往只有几美元。但它有两个反直觉的计费点：实时消息按"每 5KB 一个操作"计量，以及客户端保持连接要按"连接分钟"单独收费。搞不懂这两条，账单会比预期高出好几倍。

一、先划边界：AppSync 在整个无服务器体系里的位置

站内已经写过不少无服务器相关的实战文，读者最容易问的一句话是"这跟我上次看的那篇有什么不同"。所以先把边界画清楚，本文只讲 AppSync 这一层，被划出去的层只引用、不重复展开。

| 既有主题 | 它解决的问题 | 与本文的关系 | |---|---|---| | AWS Lambda 无服务器 API | 用函数承载业务逻辑、事件驱动 | AppSync 的计算后端之一，本文只讲怎么把它挂成数据源 | | API Gateway 深度实战 | REST/HTTP/WebSocket API 的网关层 | 同类但不同范式：API Gateway 是"请求-响应"，AppSync 是"声明式 Schema + 解析器" | | DynamoDB 无服务器数据库 | 表设计、容量模式、索引 | 本文的默认数据源，不重复表设计细节 | | SAM 无服务器应用部署 | 用 IaC 描述 Lambda/API | AppSync 也可写进 SAM/CloudFormation，本文讲控制台与 CLI 手动路径 | | Amplify 前端全栈托管 | 前端托管 + 自动生成后端调用代码 | AppSync 的前端搭档，Amplify 只负责把 AppSync 串起来 | | Well-Architected 架构评审 | 六大支柱的评审框架 | 本文只在"成本优化支柱"上提供一份具体的计费拆解 |

一句话分工：Lambda 管逻辑，DynamoDB 管数据，AppSync 管"API 契约 + 实时通道"。 三者拼起来才是一个完整的无服务器应用。

1.1 AppSync 到底是什么

AWS 官方对它的定义很简短：AppSync 提供用于从应用中以 GraphQL 方式创建和交互数据源的 API 操作（"AppSync provides API actions for creating and interacting with data sources using GraphQL from your application"）。落到实操上，它替你做了四件事：

1. 托管 GraphQL 端点——你写好 Schema，它给你一个 HTTPS 端点，不用管任何服务器； 2. 解析器运行时——把 GraphQL 请求翻译成对 DynamoDB / Lambda / OpenSearch / 任意 HTTP API 的调用，逻辑用 JavaScript 写，跑在 AWS 自研的 APPSYNC_JS 运行时上； 3. 实时通道——基于 WebSocket 的订阅（Subscription），数据一变就推给客户端； 4. 五种授权模式——API Key、IAM、Cognito 用户池、OIDC、Lambda 授权，可按字段做细粒度控制。

1.2 一个常被忽略的冷知识

很多人以为"写 GraphQL 一定要先懂 GraphQL"。官方 FAQ 的第一条就回答了这个顾虑：不需要。AppSync 控制台有一个可视化 builder，你输入数据模型，它能自动生成整套 API、Schema 和数据源连接；控制台还内置了大量可直接运行的示例 Schema。更实用的是——它能从一张已存在的 DynamoDB 表自动反推 GraphQL Schema（包括主键与前缀索引的推断），完成后查询、变更、订阅"零代码"可用，非主键属性也会自动映射。

这意味着：你手上已经有一张 DynamoDB 表，可以在几分钟内给它套一个带实时能力的 GraphQL API，一行后端代码都不写。 这是 AppSync 相比自建 Apollo Server 最大的效率差。

二、AppSync GraphQL 与 AppSync Events：两套 API 怎么选

AppSync 现在其实已经分成两条产品线，定价页把它们分开列，选错了计价逻辑完全不同。

| 维度 | AppSync GraphQL | AppSync Events | |---|---|---| | 定位 | 声明式 Schema 的数据查询/变更 API | 纯粹的发布-订阅事件通道 | | 核心概念 | Type / Query / Mutation / Subscription / Resolver | Channel（频道）/ Namespace（命名空间）/ Event Handler | | 客户端协议 | GraphQL over HTTP + WebSocket（订阅） | HTTP 发布 + WebSocket 订阅 | | 数据源 | DynamoDB / Lambda / OpenSearch / HTTP 等 | 无数据源，只做事件路由 | | 逻辑入口 | Resolver（JS） | Event Handler 的 onPublish / onSubscribe（可选） | | 典型场景 | 博客、电商、社交 App 的读写 API | 实时比分、Live 弹幕、设备状态推送 |

选择口诀：要"存数据、查数据"用 GraphQL；只做"广播事件"用 Events。

但两者并不互斥。Events 的最大价值是它比 GraphQL 订阅更便宜、更专注：GraphQL 的实时更新是每百万次 $2.00，而 Events 的所有操作（入站发布、出站广播、事件处理器调用、连接、订阅）统一按每百万次 $1.00 计费。如果你的场景是"一发布、多订阅"的纯广播（比如一场比赛的比分推送给十万观众），Events 的单位成本只有 GraphQL 订阅的一半。

> 小提示：Events 的 onPublish 事件处理器可以在转发前改写事件，甚至直接 return null 丢弃消息——这等于给了你一个"免费的轻量过滤层"，不需要再挂 Lambda。

三、计费模型：三个计费项，外加一个"按 5KB 计量"的玄机

AppSync GraphQL 的计费非常干净，官方原话是"只为使用的部分付费，没有最小费用，没有强制用量"。一共三个计费项（以下单价锚点为美东 us-east-1，2026 年官方定价页）：

| 计费项 | 单价 | 说明 | |---|---|---| | Query 与数据修改操作 | $4.00 / 百万次 | 每一次 Query/Mutation 算一次操作 | | Real-time Updates（实时更新） | $2.00 / 百万次 | 所有广播出去的出站消息 + WebSocket 操作（如客户端连接） | | 连接 | $0.08 / 百万连接分钟 | 客户端保持 WebSocket 连接的时间 | | 数据传输 | 按 EC2 数据传出费率 | 跨区/出网另计，详见下文口径说明 |

AppSync Events 的计费则更简单——所有操作一律 $1.00 / 百万次，外加 $0.08 / 百万连接分钟。所谓"操作"是泛指的：入站发布的每条消息、广播出去的每条消息、每次事件处理器调用、每次客户端连接、每次订阅请求、每次 ping，全部算一次操作。

3.1 最容易被忽略的一条：实时消息按"每 5KB 一个操作"计量

这是全篇最值钱的一句话，也是官方定价页在页脚用小字标注的规则：

> 对 GraphQL 和 Events 两条产品线，进出站的实时消息都按"每 5KB 负载"计量。例如一个 8KB 的负载会被计为两次操作。

翻译成人话：你以为 1 条消息 = 1 次操作，其实 1 条 8KB 的消息 = 2 次操作，1 条 15KB 的消息 = 3 次操作。 一条平均 3KB 的聊天消息算 1 次，但一条带缩略图 Base64 的 20KB 消息会算 4 次。所以推送大对象是 AppSync 实时费用飙升的头号原因——正确做法是消息里只放 ID 或 URL，让客户端拿到后自己回源拉取。

同理，配额页里也明确写着"一条出站消息 = 5KB 负载数据"（One outbound message is equal to 5 KB of payload data delivered）。

3.2 第二个玄机：连接本身要单独付费

即使你一条消息都不推，客户端只要挂在 WebSocket 上就产生连接分钟费。$0.08/百万分钟听起来微不足道——换算下来 100 万连接分钟约等于"1 万个客户端各挂 100 分钟"，成本 $0.08。但如果你的 App 有个"永远在线"的长连接、且客户端几十万，这一项就会从零头变成主项。优化办法很简单：让客户端在后台/无焦点时断开订阅，别让它在用户根本没看屏幕时保持连接。

3.3 可选缓存：唯一"按小时"计费的部分

如果你觉得解析器每次查 DynamoDB 太慢，可以给 API 挂一个专用缓存实例。这是 AppSync 里唯一按小时（无长期承诺）计费的部分：

| 实例类型 | vCPU | 内存 (GB) | 网络性能 | 单价（/小时） | |---|---|---|---|---| | cache.small | 1 | 1.55 | 低到中 | $0.044 | | cache.medium | 2 | 3.22 | 低到中 | $0.089 | | cache.large | 2 | 12.3 | 最高 10 Gbps | $0.298 | | cache.xlarge | 4 | 25.05 | 最高 10 Gbps | $0.595 | | cache.2xlarge | 8 | 50.47 | 最高 10 Gbps | $1.189 | | cache.4xlarge | 16 | 101.38 | 最高 10 Gbps | $2.379 | | cache.8xlarge | 32 | 203.26 | 10 Gbps | $4.758 | | cache.12xlarge | 48 | 317.77 | 10 Gbps | $6.775 |

注意：缓存没有免费额度，且是按小时全天计费。 cache.small 一个月跑满约 $32（$0.044 × 730），比很多中小应用整个 API 层的操作费还贵。所以缓存是"性能选项"不是"省钱选项"——只有在你能明确量化"省下的 DynamoDB 读写请求费 > 缓存费"时才值得开。

3.4 Merged API（API 联邦）不额外收费

AppSync 支持把多个独立的 GraphQL API 合并成一个 Merged API（API 联邦），对外给消费者一个统一 Schema，内部各团队独立演进子 Schema。关键点：为源 API 创建 Merged API 不产生额外费用，你只为合并后的查询/变更操作和实时更新付费，源 API 本身不再单独计费。对多团队协作来说这是一项"零成本治理能力"。

四、免费套餐与 2026 账号额度（最容易被误读的一块）

AppSync 的免费额度分两块，很多人把它们搞混。

4.1 AppSync 自带免费额度（按月，前 12 个月）

| 产品线 | 每月免费额度 | 有效期 | |---|---|---| | AppSync GraphQL | 250,000 次 Query/数据修改操作 + 250,000 次实时更新 + 600,000 连接分钟 | 注册后 12 个月内 | | AppSync Events | 250,000 次实时更新 + 600,000 连接分钟 | 注册后 12 个月内 |

超出部分按上面第 3 节的单价计费。注意这是"按月"的额度（官方写 "The AppSync GraphQL Free Tier offers…"，且明确 "Use beyond these levels is billed at the published rates"），而不是把 12 个月打包成一个总量——每个月都重置一次。

4.2 2026 AWS 免费计划额度（账号级，别和上面搞混）

2025-07-15 起，AWS 的新客免费套餐口径已经改版，官方定价页也同步更新：

- 新账号注册时可选择免费计划或付费计划； - 最高 $200 赠金（注册即得 $100 + 完成入门探索操作最多再得 $100），可用于抵扣 AppSync 等符合条件的服务； - 免费计划有效期 6 个月（从账号创建起算），$200 赠金必须在账号创建后 12 个月内用完； - 升级为付费计划后，剩余赠金会自动抵扣账单； - 加入 AWS Organizations 或创建 Control Tower landing zone 会让赠金立即失效——如果你打算多账号，先把赠金用掉。

对 AppSync 而言，$200 赠金 ≈ 5,000 万次 Query 操作（按 $4/百万算）。换句话说，一个个人项目几乎可以"前 12 个月白嫖"：自带的每月 25 万次操作额度大概率就够用，$200 赠金还能兜底突发流量。

> ⚠️ 一个易错点：这两块额度是"叠加"而不是"二选一"。先用完每月免费的 250,000 次操作，超出部分才从 $200 赠金里扣，赠金用完才开始计入正常账单。

五、从 0 搭建第一个 GraphQL API（控制台 6 步）

我们以一个"待办事项（Todo）"应用为例，后端用 DynamoDB 存数据。整个流程在控制台里 6 步走完：

1. 打开 AppSync 控制台（console.aws.amazon.com/appsync/home/），点 Create API，选择 GraphQL API，再选 Design from scratch。 2. 填写 API 名称（如 todo-api），下一步选授权模式。练习建议先选 API key（最简单，适合开发和 demo）。 3. 定义 Schema。控制台提供一个可编辑的 Schema 编辑器，把下面这份 Schema 粘进去：

`graphql type Todo { id: ID! title: String! done: Boolean! } type Query { listTodos: [Todo] } type Mutation { addTodo(id: ID!, title: String!): Todo } type Subscription { onAddTodo: Todo @aws_subscribe(mutations: ["addTodo"]) } `

4. 一键创建资源。控制台会问你要不要自动生成 DynamoDB 表和解析器，选"是"即可——它会建好表、生成属性映射、并把 Query/Mutation 的 Resolver 自动挂上。 5. 发一条数据试跑。切到 Queries 面板，输入： `graphql mutation { addTodo(id: "1", title: "学习 AppSync") { id title done } } ` 点运行，应返回 { "id": "1", "title": "学习 AppSync", "done": false }。 6. 在浏览器里直接测订阅。AppSync 控制台的 Queries 面板支持实时订阅预览：开一个标签页订阅 onAddTodo，再开另一个标签页执行一次 addTodo，第一个标签页会立即收到推送消息——这就是 AppSync 的实时能力，全程没写一行前端代码。

> 关键体验点：第 4 步"自动生成 DynamoDB 表 + 解析器 + 属性映射"是 AppSync 独特的省力设计。换成自建 Apollo Server，这三件事要分别写表结构、写 resolver、写 ORM 映射，至少要小半天。

六、CLI 全流程：用命令行把 API 建起来

控制台适合入门，生产环境更推荐 CLI 或 IaC。以下是已逐条核对过 Synopsis 的命令，可直接复制执行。

第 1 步，创建 GraphQL API（授权模式先用最简单的 API Key）：

`bash aws appsync create-graphql-api \ --name todo-api \ --authentication-type API_KEY `

第 2 步，创建一把 API Key（可选 --expires 指定 Unix 时间戳过期时间；第 1 步返回值中的 graphqlApi.apiId 就是后续命令要用的 --api-id）：

`bash aws appsync create-api-key \ --api-id <API_ID> \ --description "dev key" `

第 3 步，上传 Schema（新版用 start-schema-creation）：

`bash aws appsync start-schema-creation \ --api-id <API_ID> \ --definition file://schema.graphql `

第 4 步，创建一个 DynamoDB 数据源：

`bash aws appsync create-data-source \ --api-id <API_ID> \ --name todoTable \ --type AMAZON_DYNAMODB \ --service-role-arn arn:aws:iam::<账号ID>:role/AppSyncDynamoDBRole \ --dynamodb-config '{"tableName":"Todo","awsRegion":"ap-northeast-1"}' `

第 5 步，为 addTodo 字段挂一个 UNIT 解析器（用 JS 运行时）：

`bash aws appsync create-resolver \ --api-id <API_ID> \ --type-name Mutation \ --field-name addTodo \ --data-source-name todoTable \ --kind UNIT \ --runtime 'name=APPSYNC_JS,runtimeVersion=1.0.0' \ --code file://resolver.js `

参数说明（均已核对官方 CLI 参考）：

- create-graphql-api 的必填项只有 --name 和 --authentication-type，后者取值只能是 API_KEY / AWS_IAM / AMAZON_COGNITO_USER_POOLS / OPENID_CONNECT / AWS_LAMBDA 之一； - create-data-source 必填 --api-id / --name / --type，DynamoDB 场景再带 --service-role-arn 和 --dynamodb-config； - create-resolver 必填 --api-id / --type-name / --field-name；--kind 取 UNIT（单数据源，默认）或 PIPELINE（串联多个 Function）；用 JS 代码时 --runtime 与 --code 必须成对出现，runtime.name 目前只允许 APPSYNC_JS、runtimeVersion 目前只允许 1.0.0； - 如果你更想用旧式映射模板，create-resolver 还支持 --request-mapping-template / --response-mapping-template（每份模板上限 64KB）。

几个高频管理命令（都在 aws appsync 命名空间下，已核实命令名存在）：

| 命令 | 用途 | |---|---| | list-graphql-apis / get-graphql-api | 列出/查看 API | | create-data-source / update-data-source / list-data-sources | 数据源管理 | | create-resolver / update-resolver / list-resolvers | 解析器管理 | | create-api-key / update-api-key / list-api-keys | API Key 生命周期 | | create-domain-name / associate-api | 自定义域名与绑定 | | evaluate-code / evaluate-mapping-template | 用 mock 数据本地验证 JS 逻辑 | | flush-api-cache | 清空 API 缓存 | | create-api | 创建 Event API（Events 产品线，必填 --name 与 --event-config） | | create-channel-namespace / list-channel-namespaces | Event API 的命名空间管理 |

CLI 能"离线测逻辑"是一个被低估的能力：evaluate-code 让你用 mock 数据远程评估 JS 解析器，不必真的连数据源——这意味着你可以把解析器逻辑写进单元测试框架里，在 CI 阶段就验证，而不是等上线后靠线上日志排错。官方 FAQ 也确认了这一点："AppSync 提供 remote API，可用 mock 数据评估你的 JavaScript 代码，并可接入你熟悉的测试框架做单元测试。"

七、数据源与解析器：JS resolver 直连 vs Lambda 代理

这是 AppSync 最需要做决策的一层，官方 FAQ 有一个专门的问答回答了它。

| 方案 | 何时用 | 代价 | |---|---|---| | JS Resolver 直连数据源 | 绝大多数场景——直接读写 DynamoDB / OpenSearch / Aurora Serverless / HTTP API | 无需额外算力，零额外成本（只算 AppSync 操作费） | | Lambda 数据源（代理） | 需要复杂业务逻辑、跨多个数据源编排、或调用 JS 运行时无法直接访问的服务 | 多一层 Lambda 调用与冷启动，额外付 Lambda 费用 |

官方给的选择建议很明确："在大多数情况下，直接连接目标数据源的 AppSync 函数就能提供你所需的全部功能。只有当你需要实现 JS 解析器不支持的复杂业务逻辑时，才用 Lambda 数据源作为代理。"

换成钱来说：JS resolver 直连 = 只花 AppSync 的 $4/百万次；走 Lambda 代理 = AppSync 的 $4/百万次 + Lambda 的请求费 + 时长费。一个每天 100 万次调用的 API，直连和代理的年成本可能差出一台服务器的钱。能用 JS resolver 解决的，就绝不上 Lambda。

PIPELINE 解析器是介于两者之间的第三种形态：它把多个 Function 串联执行，让一次 GraphQL 请求命中多个数据源（比如先写 DynamoDB、再发一条 SNS、再写审计日志），全程仍是 JS 运行时、不经过 Lambda。配额上，一个 pipeline resolver 或 handler 最多挂 10 个 Function。

八、实时订阅：把数据"推"给客户端

订阅（Subscription）是 AppSync 区别于 API Gateway REST 的核心卖点。机制很简单：任意数据源发生 Mutation 时，结果可以立刻通过 WebSocket 推送给订阅了该事件的客户端。官方 FAQ 原话是"Subscriptions are supported with AWS AppSync against any of the data sources"——任何数据源都支持，不限 DynamoDB。

Schema 里的写法就是给 Subscription 字段挂一个 @aws_subscribe 指令，声明它监听哪些 Mutation：

`graphql type Subscription { onAddTodo: Todo @aws_subscribe(mutations: ["addTodo"]) } `

客户端订阅后用 WebSocket 长连接接收，适合聊天、协同编辑、实时看板、IoT 状态等场景。三条实操纪律：

1. 订阅不等于轮询——不要用轮询去模拟实时，那是连接分钟费的主要来源； 2. 单条订阅负载上限 240KB（订阅通道收到的消息大小），但记住 5KB 才计一次操作，大消息会被放大计费； 3. 单个 WebSocket 连接默认最多 200 条订阅语句（该配额可申请提高），每条语句可让客户端收到多个相关消息。

如果你的场景根本不需要 Schema 和数据源，只是"发布-订阅事件"，那就用 Events 产品线——HTTP 发布、WebSocket 订阅，onPublish / onSubscribe 事件处理器可选，单位成本只有 GraphQL 订阅的一半。

九、认证与安全：五种授权模式 + 私有 API + 自定义域名

9.1 五种授权模式

创建 API 时必须选授权类型（--authentication-type），可选：API Key、AWS IAM、Cognito 用户池、OpenID Connect（OIDC）、Lambda 授权。实践中的常见组合是"默认 API Key（开发）+ 追加 Cognito 或 IAM（生产）"——AppSync 允许一个 API 配多种授权提供者，并按字段/操作做细粒度控制。每个 API 最多配 50 个认证提供者。

9.2 一个重要的安全事实

官方 FAQ 里有一句话必须划重点："应用数据存储在你自己的 AWS 账号中，不在 AppSync 服务里"（"Application data is stored at rest in your AWS account and not in the AWS AppSync service"）。也就是说 AppSync 只是"API 层"，数据主权始终在你手上。再配合用户上下文透传，你可以在解析器里对资源做精细的行级访问控制。

9.3 私有 API 与自定义域名

- 私有 API：AppSync 支持创建只能从你的 VPC 内访问的 GraphQL API。适合内部微服务之间调用，彻底不暴露在公网。 - 自定义域名：把你自己的域名绑到 AppSync 的 GraphQL 端点与实时端点上。做法是提供一个域名 + 一份覆盖该域的 ACM 证书，创建自定义域名后 associate-api 绑定 API，再把 DNS 指向 AppSync 提供的域名即可。好处是可以随时切换关联的 API 而不必改客户端配置。默认每个区域最多 50 个自定义域名（可申请提高）。

十、性能与成本优化：三个能省钱的开关

1. 缓存要"算得过来账"再开（见第 3.3 节）。缓存能省 DynamoDB 读请求费，但自己按小时收费、且无免费额度。判据：省下的 DynamoDB 读写费 > 缓存小时费。 2. 用 Merged API 做治理，而不是堆 API。多个 GraphQL API 合成一个 Merged API，不额外收费，还能给消费者一个统一入口，避免"一个业务一个 API"的碎片化。 3. 控制实时消息的体积。这是收益最直接的一招——消息只放 ID/URL，不放 Base64 大对象。一条 20KB 的消息按 4 次操作计，把它压到 5KB 以内就降到 1 次，实时费用直接砍到 1/4。

十一、区域可用性与配额（香港可用）

11.1 区域（对香港/华南读者是关键信息）

根据 AWS 官方"AppSync endpoints and quotas"页，AppSync GraphQL 在 31 个商业区域提供端点，包含 ap-east-1（中国香港）。亚太可选区域：

| 区域代码 | 区域 | 端点 | |---|---|---| | ap-east-1 | 亚太（香港） | appsync.ap-east-1.amazonaws.com | | ap-northeast-1 | 东京 | appsync.ap-northeast-1.amazonaws.com | | ap-northeast-2 | 首尔 | appsync.ap-northeast-2.amazonaws.com | | ap-northeast-3 | 大阪 | appsync.ap-northeast-3.amazonaws.com | | ap-southeast-1 | 新加坡 | appsync.ap-southeast-1.amazonaws.com | | ap-southeast-2 | 悉尼 | appsync.ap-southeast-2.amazonaws.com | | ap-southeast-5 | 马来西亚 | appsync.ap-southeast-5.amazonaws.com | | ap-southeast-7 | 泰国 | appsync.ap-southeast-7.amazonaws.com |

另外 AppSync Event API 与实时端点在中国大陆（cn-north-1 北京 / cn-northwest-1 宁夏）也有独立端点（appsync-api.cn-north-1.amazonaws.com.cn）——注意中国区账号体系与计费独立，本文所有价格均为国际版口径。

11.2 关键配额（部分，均来自官方配额页）

| 配额项 | 默认值 | 可否提高 | |---|---|---| | 每区域 GraphQL API 数 | 50 | ✅ | | 每个 API 的 API Key 数 | 50 | ❌ | | 每个 API 的认证提供者数 | 50 | ❌ | | Schema 文档大小 | 1 MB | ❌ | | 单次请求执行时间 | 30 秒 | ❌ | | 解析器/函数/处理器响应大小 | 5 MB | ❌ | | 单个请求可执行的解析器数 | 10,000 | ❌ | | 请求/响应映射模板大小 | 64 KB | ❌ | | 每个客户端连接的订阅数 | 200 | ✅ | | 每区域自定义域名数 | 50 | ✅ | | 每个 Merged API 的源 API 数 | 10 | ✅ | | 请求令牌速率（美东/东京等主力区） | 10,000/秒 | ✅ | | 请求令牌速率（其他区域） | 5,000/秒 | ✅ | | 每 API 连接速率 | 2,000/秒 | ✅ | | 每 API 入站消息速率 | 10,000/秒 | ✅ | | 每 API 出站消息速率 | 1,000,000/秒 | ✅ |

值得注意的两点： ① 大多数硬上限（API Key 50、认证提供者 50、Schema 1MB、模板 64KB）都不可提高，设计时就要按这个天花板规划；② 请求令牌（request tokens）不是"请求次数"——AWS 按每次请求消耗的处理时间与内存来分配令牌，一个"重"查询可能消耗多个令牌。这意味着限流保护的是资源消耗，不是请求个数，优化解析器的计算量本身就能提高吞吐。

十二、三个真实成本算例（改写自官方定价页）

官方定价页给了三个算例，这里直接改写成可对照的表格。单价锚点为美东 us-east-1。

算例一 · 博客 App（纯查询）

场景：5 万月活，每人每月 100 次搜索 → 每月 500 万次查询操作，平均响应 3KB。

| 计费项 | 计算 | 金额 | |---|---|---| | Query 操作费 | 5 百万 × $4.00/百万 | $20.00 | | 数据传输费 | 3KB × 500 万 = 14.3 GB × $0.09 | $1.29 | | 合计 | | $21.29 |

算例二 · 聊天 App（写入 + 实时 + 长连接）

场景：2,500 月活，每人每月在线 1,500 分钟、发 1,000 条、收 1,000 条 → 每月 250 万次数据修改 + 250 万次实时更新。

| 计费项 | 计算 | 金额 | |---|---|---| | 数据修改操作费 | 250 万 × $4.00/百万 | $10.00 | | 实时更新费 | 250 万 × $2.00/百万 | $5.00 | | 连接费 | 2,500 × 1,500 分钟 = 375 万连接分钟 × $0.08/百万 | $0.30 | | 数据传输费 | 2.4 GB × $0.09 | $0.21 | | 合计 | | $15.51 |

算例三 · 体育比分 App（Events 产品线）

场景：向两个频道发布 10,000 + 100,000 条消息，100 万客户端连接（平均 10 分钟），共广播 1,000 万条出站消息（平均 1KB）。

| 计费项 | 计算 | 金额 | |---|---|---| | 入站发布 | 110,000 × $1.00/百万 | $0.11 | | 事件处理器请求 | 100,000 × $1.00/百万 | $0.10 | | 出站广播 | 1,000 万 × $1.00/百万 | $10.00 | | 连接请求 | 100 万 × $1.00/百万 | $1.00 | | 订阅请求 | 100 万 × $1.00/百万 | $1.00 | | 连接分钟 | 100 万 × 10 分钟 × $0.08/百万 | $0.80 | | 数据传输 | 10GB（官方按免费额度计 $0） | $0.00 | | 合计 | | $13.01 |

12.1 一个必须交叉核对的口径问题

细心的读者会发现：GraphQL 算例一把 14.3GB 全部按 $0.09/GB 计了费（$1.29），而 Events 算例却注明"前 10TB/月免费"（数据传输记 $0）。 这两处官方口径并不一致——如果真按"前 10TB 免费"，算例一的数据传输应为 $0。

怎么办？ 上表如上保留了官方原值以便对照，但做预算时建议按"数据传输可能产生少量费用"来估，别把它当成必然为零。这也再次印证一条通用纪律：官方算例可以引用，但同一页的两个算例之间的口径差异必须自己发现并标注出来，否则读者拿它做预算会踩空。

12.2 选型对比：AppSync vs API Gateway vs Lambda Function URL

| 维度 | AppSync（本文） | API Gateway | Lambda Function URL | |---|---|---|---| | API 范式 | GraphQL（声明式 Schema） | REST / HTTP / WebSocket | 直连函数 | | 实时订阅 | ✅ 内置 WebSocket 订阅 | 需自建 WebSocket API | ❌ | | 直连数据源 | ✅ 无需 Lambda | ❌ 需 Lambda 承接 | ❌ 需自己写 | | 起步计费 | $4.00/百万次操作 | HTTP API $1.00/百万次；REST $3.50/百万次 | 仅算 Lambda 费用 | | 最适合 | 数据读写型 App、需实时 | 通用 REST/HTTP 网关 | 极简单函数 |

一句话：要"省手的 GraphQL + 实时"选 AppSync；要"极致便宜的标准 REST"选 API Gateway HTTP API；只是想把一个函数暴露出去选 Function URL。 AppSync 贵在"操作单价"，但省下了"自己写 resolver、自己搭 WebSocket 服务"的工程成本。

十三、省钱 5 招 + 7 大坑

13.1 省钱 5 招

1. 小消息优先：实时消息只放 ID/URL，把单条压进 5KB（1 次操作），大对象会被按 5KB 放大计费。 2. 断连省钱：客户端无焦点/后台时主动断开订阅，直接砍掉连接分钟费。 3. JS resolver 直连替代 Lambda 代理：能直连 DynamoDB 就别再挂 Lambda，省一层计费与冷启动。 4. 纯广播用 Events 而非 GraphQL 订阅：Events 操作单价 $1.00/百万，是 GraphQL 实时更新（$2.00/百万）的一半。 5. 缓存只在划算时开：cache 按小时全天计费、且无免费额度，先用"DynamoDB 省下的读写费 > 缓存费"验证再开。

13.2 7 大坑

1. 把"消息条数"当计费单位 —— 实际按"每 5KB 一个操作"，大消息会成倍放大费用。 2. 忽略连接分钟费 —— 长连接即使不推消息也在计费，几十万客户端时它可能是主项。 3. 给每个 GraphQL API 都独立建、不做 Merged API —— Merged API 不额外收费，却能让治理收敛。 4. 以为"写 GraphQL 必须先精通 GraphQL" —— 控制台可自动生成 Schema/数据源，还能从现有 DynamoDB 表反推。 5. 把缓存当省钱手段 —— 它是性能选项，cache.small 一个月约 $32，常常比整个 API 层的操作费还贵。 6. 用 API Key 上生产 —— API Key 适合开发/demo，生产应换 Cognito/IAM/OIDC，并利用字段级授权。 7. 把 $200 赠金当成永久 —— 免费计划 6 个月、赠金 12 个月内用完，加入 Organizations 或建 Control Tower 会让赠金立即失效。

常见问题 FAQ

Q: AppSync 会替换掉 Lambda 吗？ A: 不会，两者是配合关系。AppSync 负责 API 契约、认证、实时通道与数据源编排，Lambda 负责"JS 运行时搞不定的复杂业务逻辑"。大多数 Query/Mutation 用 JS resolver 直连数据源即可，只有复杂逻辑才挂 Lambda 数据源。

Q: 我不懂 GraphQL 能用吗？ A: 能。控制台提供可视化 builder，输入数据模型即可自动生成整套 API、Schema 与数据源；还能从现有 DynamoDB 表自动反推 Schema，完成后零代码可用。

Q: AppSync 有免费额度吗？ A: 有，且是按月的：GraphQL 每月 25 万次操作 + 25 万次实时更新 + 60 万连接分钟，前 12 个月有效；Events 每月 25 万次实时更新 + 60 万连接分钟。另有 2026 账号级免费计划最高 $200 赠金（免费计划 6 个月、赠金 12 个月内用完）。

Q: 数据存在 AppSync 里吗？ A: 不存。官方明确"应用数据存储在你自己的 AWS 账号中，不在 AppSync 服务里"。AppSync 只是 API 层，配合用户上下文透传可做行级访问控制。

Q: AppSync 支持私有网络内访问吗？ A: 支持。可以创建"只能从 VPC 内访问"的私有 GraphQL API，不暴露到公网。

Q: 能用自己的域名访问吗？ A: 能。提供域名 + 覆盖该域的 ACM 证书，创建自定义域名后关联 API，再改 DNS 即可；切换关联 API 时不必改客户端。默认每区域上限 50 个（可提额）。

Q: 香港节点可用吗？对中国用户延迟如何？ A: 可用，ap-east-1（香港）在 AppSync 的 31 个商业区域列表内；亚太还有东京、首尔、大阪、新加坡、悉尼、马来西亚、泰国等可选。就近选区域能显著降低 API 延迟。

Q: 中国区账号能写这篇文章里的价格吗？ A: 不能直接套用。中国区（北京 cn-north-1 / 宁夏 cn-northwest-1）有独立的端点与计费体系，本文所有价格均为国际版口径。

> ⚠️ 文中价格为 2026 年参考价，实际费用随区域和官方调价变动，请以 AWS 官网为准。

> 🚀 需要 AWS 国际版账号？通过 3.chengzicloud.cloud 获取最新注册教程与专属优惠，助你轻松上云。

> 本文由 3.chengzicloud.cloud 提供，点击访问首页了解更多