AWS 中国区有哪些服务？这个问题我在 Chinaready 的对等性清单 文章中早就回答过了：120 个服务，北京和宁夏两区怎么区分使用，Bedrock、Q、Connect 等服务的缺席。真正在中国区踩过坑的团队都知道，AWS 的服务目录只是第一道门。即便目标服务在中国区的清单上打了勾，打开控制台那一刻，与国际区的真实差距才开始。
这篇文章不做服务目录的对比。我用一组账号在北京区和宁夏区跑了几天只读 API，把打勾背后五个维度的问题一个一个测出来：版本、功能、配额、体验、成本。在你做中国区架构评审和 PoC 排期之前，这几个数字是你需要的底牌。文章会随实测持续更新（数据实测于 2026-10-07/09）。
五个维度看 AWS 中国区服务：从「打没打勾」到「能不能用」
服务目录回答的问题很简单：有，或没有。但一个服务在中国区能不能用，至少要看五层。
| 层 | 问题 | 差一个身位意味着什么 |
|---|---|---|
| 版本 | 同名服务的引擎/运行时/API 版本是否同步？ | 新特性用不了，迁移脚本跑不通，文档对不上 |
| 功能 | 关键子功能（第三方集成、区域联动、托管选项）是否在？ | 架构方案走到一半发现要自建，或者要集成第三方方案 |
| 配额 | 默认配额与扩容路径与国际区一致吗？ | 压测当天发现开不了实例 |
| 体验 | 文档、示例代码、工具链是否可用？ | 跟着官方教程一步步走到报错 |
| 成本 | 定价结构、免费额度、汇率结算一致吗？ | PoC 预算直接翻倍 |
先举一个直观的例子：你在国际区用 CloudFront 部署静态网站，可以顺便用 AWS 托管的免费 SSL 证书。到了中国区你会发现这条路走不通：免费托管证书用不了，要上 HTTPS 只能自己上传和维护证书。这个差距在服务目录里看不到，只有实际操作时才会撞上。
下面每一节先给实测数据，再说结论。
版本：核心服务基本同步，别被刻板印象骗了
把 18 个常用引擎和组件在三区逐一过了一遍，结论和大多数人的预期相反：版本不是中国区的主要问题。
开源数据库引擎
| 引擎 | us-east-1 | 北京 | 宁夏 | 判定 |
|---|---|---|---|---|
| RDS MySQL | 8.4.9 | 8.4.9 | 8.4.9 | 完全同步 |
| RDS PostgreSQL | 18.6（56 版） | 18.6（45 版） | 同北京 | 最新同步，历史版本少 11 个 |
| RDS MariaDB | 12.3.3 | 12.3.3 | 12.3.3 | 完全同步 |
| Aurora MySQL 8.x | 3.13.0 | 3.13.0 | 3.13.0 | 最新同步 |
| Aurora PostgreSQL | 18.6 | 18.4 | 18.4 | 落后 2 个小版本 |
| DocumentDB | 8.0.2 | 8.0.2 | 8.0.2 | 完全同步 |
| Neptune | 1.4.8.0 | 1.4.8.0 | 1.4.8.1 | 宁夏反而最新 |
缓存、搜索与消息
| 引擎 | us-east-1 | 北京 | 宁夏 | 判定 |
|---|---|---|---|---|
| ElastiCache Redis / Valkey / Memcached | 7.1 / 9.1 / 1.6.6 | 同左 | 同左 | 完全同步 |
| MemoryDB Redis / Valkey | 7.1 / 7.3 | 同左 | 同左 | 完全同步 |
| OpenSearch | 3.7（36 版） | 3.7（36 版） | 3.7（36 版） | 完全同步 |
| Amazon MQ RabbitMQ | 4.3 | 4.2 | 4.2 | 落后 1 个主版本 |
| Amazon MQ ActiveMQ | 5.19 | 5.18 | 5.18 | 落后 1 个主版本 |
容器
| 组件 | us-east-1 | 宁夏 | 判定 |
|---|---|---|---|
| EKS 集群版本 | 1.32–1.37 | 1.32–1.37（完全一致） | 同步 |
| EKS vpc-cni addon | 117 版 | 117 版 | 同步 |
| EKS aws-ebs-csi-driver | 100 版 | 100 版 | 同步 |
| EKS pod-identity-agent | 17 版 | 17 版 | 同步 |
| EKS Auto Mode | 可用 | 可用（实测） | 同步 |
以上 18 项服务里 14 项完全同步。开源数据库这条线跟得最紧，MySQL、MariaDB、DocumentDB 都是最新版齐平，连 Valkey 这种 2024 年才出的新引擎也没落下。「中国区数据库版本落后」这个流传很广的说法，实测假消息。
真正要记进选型清单的缺口有三个。Aurora PostgreSQL 落后两个小版本，追新特性的团队要看清版本号再迁移。Amazon MQ 是全部 18 项里唯一存在主版本代差的服务，RabbitMQ 和 ActiveMQ 各落后一个主版本，重度使用消息队列的架构要把它算进成本。还有个反常细节：Neptune 最新版 1.4.8.1 只在宁夏有，北京还是 1.4.8.0，选区的时候这种小落差也真实存在。
EKS Auto Mode 值得单独说。这个 2024 年底才发布的新托管形态，中国区也能用。API 列表里查不到它的开关，我是用 create-cluster 带 computeConfig 参数探测出来的：服务端报错直接引用了 Auto Mode 的配置完整性规则，说明校验逻辑已经就位。对迁移团队这是个明确的利好：EKS 的最新托管形态不构成额外差距。
再看一眼全局就清楚了。中国区只有国际区约三分之一的服务数，但这些服务里几乎所有核心层（EKS、RDS、Aurora、ElastiCache、OpenSearch）版本都在线。真正掉队的是两类：政策敏感型（SES、SMS 等涉及个人信息的服务）和新兴 AI 型（Bedrock、Q、CodeWhisperer）。你的架构如果压在前者上，版本维度可以直接放心；压在后者上，缺的是整个服务，不是版本。
对于那些由于政策敏感而缺失的 AWS 服务 在中国有很多更经济的替代选项。在 AI 方面 如果只是 AI 推理的应用场景，中国大陆将有更多的大模型服务提供商可供选择 例如 DeepSeek MiniMax 等等；他们都是与 Open API 和 Claude Code 兼容的大模型服务，很可能将你的 AI 应用迁移到中国并不是一个特别有挑战的工作
功能：打勾之后灰掉的开关
功能这一节覆盖两类问题：整条产品线的缺席（Bedrock、GPU 训练卡），和服务在但关键子功能被灰掉（CloudFront 的证书、Route 53 的流量策略）。
表一：AI、边缘与计算类服务的功能差异
| 服务 | 在国际区的状态 | 在中国区的实测结果 |
|---|---|---|
| CloudFront | 可用（全球 CDN） | 将停止服务：AWS 官方通知 2027 年 5 月 31 日停止中国（宁夏）区域支持。官网公告 |
| EC2 实例类型 | 1,375 种 | 北京 432 种 / 宁夏 461 种，约为国际区三分之一 |
| EC2 GPU 芯片 | 9 种：T4/A10G/L4/L40S/A100/H100/H200/Trainium 等 | 仅 NVIDIA T4（2018）、NVIDIA A10G（2021）、AWS Inferentia（2020）三种。没有 A100/H100 级别的训练卡 |
| EC2 GPU 实例族内规格 | g4dn 7 种 / g5 8 种 / inf1 4 种 | g4dn 7 种 / g5 8 种 / inf1 4 种，族内规格不缩水。缺的是整条产品线：g6、inf2、p4d、p5、trn1 等 11 个族整体缺席 |
| Bedrock | 可用（122 个模型） | 服务未部署，不是「暂未开通」 |
| Rekognition / Textract / Translate / Polly / Q / CodeWhisperer / OpenSearch Serverless | 多数可用 | 北京区全部不可用 |
| Route 53 | 可用（完整功能） | 仅宁夏区提供。Hosted Zones 和健康检查可用；流量策略不可用；不支持域名注册 |
这张表里最重要的一个信号是 CloudFront 的去留：AWS 官方已经公告 2027 年 5 月 31 日停止宁夏区域支持。如果你的中国区架构里有 CloudFront，现在就要开始规划替代方案，这不是「功能差异」而是「服务退出」。中国大陆有非常丰富的 CDN 厂商供选择，CloudFront 退出后可以直接迁移到国内 CDN。
AI 这条线，两个判断。第一，中国区能开到的最强单机是 g5.48xlarge，8 张 A10G，每张 24GB 显存。推理 24GB 以内装得下的模型可以跑，训练或微调 70B 以上的模型，目前无解。第二，托管 AI API 整体缺席：Bedrock 之外，Rekognition、Textract、Translate、Polly、Q、CodeWhisperer 在北京区全部不可用，SageMaker 是唯一完整可用的 AI 服务。想在中国区跑 AI，SageMaker 自建几乎是唯一的官方路径，而它又撞上第一道墙：没有大显存训练卡。两道墙一起立在那里。
除了 API 探测，我也登录 Console 逐个点了 CloudFront、S3、Route 53 的控制台。人工比对的结论和 API 一致：这些服务在中国区的功能面明显更少，Console 里能看到的选项就少一截。
功能差异里还有一类容易被忽略：数据与治理这些「水电煤」服务。它们不像 AI 那样整条缺席，坑藏得更深。这七个服务我也逐一测了。
表二：数据与治理类服务的对等度
| 服务 | 对等度 | 差异点 |
|---|---|---|
| DynamoDB | 完全对等 | API 全通；账号/表容量上限完全一致（80,000/40,000 CU）。唯一注意：全球表不能跨分区同步 |
| ElastiCache | 引擎同步，广度七成 | 引擎版本三区一致；可购节点 SKU 167 种 vs 国际区 236 种 |
| DocumentDB | 版本同步，实例类打折 | 引擎最新版一致；实例类北京 33/39、宁夏 27/39，缺的主要是老代次，核心 r5 系完整 |
| ECS | API 对等 | 差异在配额管理面：service-quotas 中国区返回空列表 |
| CloudWatch 指标/拨测/SLO | 对等 | 指标、Synthetics 拨测、Application Signals 三区全通 |
| CloudWatch RUM | 不可用 | 服务未开放 |
| Organizations | 中国区内可用 | SCP、多账号全通，但与国际区 org 完全独立，两套体系互不相通 |
| IAM Identity Center | 中国区内可用 | Permission Sets、应用注册（OIDC/SAML）、可信令牌签发者、本地身份源全部可用，含新特性 |
这批结果给出了功能维度最重要的结论：数据层几乎可以无脑搬。DynamoDB 完全对等，ElastiCache 连 Valkey 新引擎都同步，DocumentDB 缺的只是老代次实例。海外团队把数据层搬进中国区，技术阻力很小。
坑有两个。一是可观测性缺口：指标、拨测、SLO 都在，但 RUM（真实用户监控）明确不可用，做前端体验监控的团队要提前找替代方案。二是账号治理的误判风险：国际区的 Organizations 和 Identity Center 不能延伸到中国区，但中国区可以自己搭一套完整的，而且不是缩水版，新特性 API 都实测可用。你的多账号策略、SCP 权限体系、SSO 体系都得在中国区重新建一遍。一句话：架构可以复制，治理不能继承。
配额：压测日才发现的地雷
结论表（default 与 applied 两层 API）
| 配额项 | us-east-1 | 北京 | 宁夏 | 性质 |
|---|---|---|---|---|
| EC2 On-Demand Standard vCPU（default） | 5 | 5 | 5 | 分区一致 |
| EC2 On-Demand Standard vCPU（applied） | 32 | 8 | 8 | 账号差异，非分区差异 |
| Lambda 并发（default） | 1,000 | 1,000，可调 | 同北京 | 分区一致 |
| Lambda 并发（applied） | 10 | 未初始化 | 未初始化 | 账号冷启动状态 |
| ECS 配额（default 层） | 62 项 | 62 项（完全一致） | 同北京 | 分区一致 |
| ECS 配额（applied 层） | 28 项（全部可调项） | 空列表 | 空列表 | 账号未初始化可调配额 |
| EKS 配额（default + applied 两层） | 13/12 项 | 两层都报「服务不可用」 | 同北京 | 分区差异（唯一） |
读这张表要知道一个背景：service-quotas 的数据分两层，default 层是 AWS 文档默认值，applied 层是账号自己的应用值。EC2 的应用值会随账号使用量自动增长，和分区无关。ECS 的 applied 层为空也是账号状态：它的配额几乎全是「不可调」项，只有可调项才进 applied 层，新账号没有可调项记录，列表自然为空，Console 面板照样能看到完整清单。
把账号噪音滤掉之后，配额维度真正的分区差异只有一个：EKS 在中国区连 service-quotas 都没接入，两层 API 都直接报「服务不可用」，Console 服务列表里也找不到 EKS。想查 EKS 的节点数、集群数上限，没有任何自助渠道，只能提工单。IaC 里引用 EKS 配额值做守卫的，这里会直接失败。
这个结论本身就是个提醒：跨区对比配额时，applied 值会被账号历史污染，只有 default 值反映分区策略。用错层，就会把账号差异误读成分区差异。
从 Console 面板里再摘几条容易踩的默认值。这些数字不大，但撞上的时候没有商量余地：
| 场景 | 配额 | 默认值 | 谁会先撞 |
|---|---|---|---|
| BI 并发查询 | Athena Active DML queries | 20 | 报表一多就排队 |
| 高频部署 | Lambda 控制面 API 速率 | 15 次/秒，不可调 | CI/CD 流水线 |
| 弹性伸缩 | ECS 任务启动速率 | 500，不可调 | 伸缩风暴时 |
| 备份窗口 | EBS 每卷并发快照 | 5，不可调 | 批量备份脚本 |
| 刷缓存 | CloudFront 活动通配符失效 | 15，不可调 | 发布系统频繁失效缓存 |
| 多证书站点 | CloudFront 每分发 SSL 证书数 | 1，不可调 | 多域名架构 |
注意「不可调」这三个字。资源类配额不够可以提工单，这一批撞了只能改架构。Console 里过半的配额都是这个标记，设计阶段就要绕着走。控制台配额查询入口：https://console.amazonaws.cn/servicequotas/home/dashboard 。
开发者体验：文档、镜像与工具链
这一节写给每天写代码的人。架构师看目录，开发者看的是三件事：文档查得着、镜像拉得动、CI 跑得通。
中国区有专属文档站：https://docs.amazonaws.cn 。同一个服务的文档在这里和全球站并不完全同步，遇到行为对不上文档的时候，先确认你看的是不是中国区版本。
镜像这一关最磨人。EC2 和 EKS 的节点跑在中国境内的网络里，Docker Hub、GitHub、Kubernetes 官方镜像源基本拉不下来。可行的替代是从境外自建的镜像仓库或镜像代理拉取。好在 GitHub 本身基本可用，克隆中小规模的仓库在时间上可以接受，你也可以把自己的代码库拉到中国区环境里自行构建镜像。
AWS CLI 没有任何问题。一台机器配两个 profile，一个指向中国区，一个指向国际区，同时用。中国区的 endpoint 是独立域名，但这个差异对 CLI 完全透明，从中国大陆直连中国区的各种服务，网络畅通。
域名和 DNS 是另一套规则。中国区不支持域名注册，你需要先在国内可用的注册商那里买域名，然后完成 ICP 备案，之后才能在中国区使用这个域名。没备案的域名，DNS 解析能成功，但是网页打不开。
还有一个容易忽略的：中国区没有 CloudShell，国际区正常。习惯在浏览器里开终端的工程师，到中国区要自己准备本地工具链。
成本：北京和宁夏区的定价差异
Linux/Shared/按需小时价（pricing API 实测）
| 实例 | us-east-1 | 北京 | 宁夏（折 USD） |
|---|---|---|---|
| m5.xlarge | $0.192 | ¥2.026（$0.285，+48%） | ¥1.356（$0.191，-1%） |
| c6i.2xlarge | $0.340 | ¥2.958（$0.417，+23%） | ¥1.972（$0.278，-18%） |
| g4dn.xlarge | $0.526 | ¥5.223（$0.736，+40%） | ¥3.711（$0.523，-1%） |
| g5.12xlarge | $5.672 | ¥53.641（$7.556，+33%） | ¥37.781（$5.321，-6%） |
这组数字藏着一个反直觉结论：京宁定价是倒挂的。北京比国际区贵 23 到 48 个百分点，宁夏反过来，通用和 GPU 实例的价格普遍等于甚至低于国际区。g5.12xlarge 在宁夏折合 $5.32 一小时，比美东还便宜 6%。同一个国家两个 Region 价差 30%，这种事在国际区找不到可比的现象。
宁夏在用定价引导算力往宁夏走，AI 推理负载尤其明显。如果你的负载对延迟不敏感，把 GPU 推理放在宁夏，比北京省三分之一成本，比美东还便宜。选区的决策权重，成本这一项在中国区内部就值得单独算一遍。
上线前一小时的核对法
上面所有实测浓缩成一张清单。架构评审前花一小时照着核对，大部分中国区的意外都能提前拦下。命令都在本实验里验证过。
- 查版本：运行
aws eks describe-cluster-versions和aws rds describe-db-engine-versions，对比目标区与你现有区的版本列表。 - 查机型：运行
aws ec2 describe-instance-type-offerings，确认你的架构选定的每一种实例类型在中国区存在。GPU 负载要额外确认芯片型号。 - 查服务可用性：在 docs.amazonaws.cn 上逐个确认你的架构依赖的每个服务在中国区的支持状态。
- 查配额：先运行
aws service-quotas get-service-quota，返回为空时再运行get-aws-default-service-quota。EKS 在中国区会直接报「服务不可用」，这个报错就是结论。 - 查定价：用 pricing API 对比三个区的价格，北京和宁夏的差价可能改变你的部署决策。
从差距到决策
五个维度摆在一起，结论很冷静。AWS 中国区不是缩水版的国际区，它是一个需要独立评估的目标平台。
版本同步了，18 项里 14 项完全对齐，连 EKS Auto Mode 这样的新形态都没缺席。默认配额一致，配额维度的分区差异只剩 EKS 一处管理面缺口。宁夏定价甚至比美东还低，成本策略清晰可算。数据层几乎可以无脑迁移，治理体系可以完整重建。
但 AI 算力停在 2021，托管 AI API 整体缺席，CloudFront 已经公告退出时间表。这些都不会出现在目录清单里。
所以迁移决策的真正分水岭不在「AWS 中国区行不行」，而在你的架构压在哪条线上：核心计算、数据库、容器、可观测性这些线上，中国区是一个体面且定价友好的目标平台；AI 这条线上，目前只有 SageMaker 自建一条路，而且天花板由芯片决定。
这篇文章会随实测持续更新。如果你的团队正在做中国区架构评审，Chinaready 的评估服务可以帮你把这套五维核对跑成正式流程；想要目录级的对等性清单，见《进中国市场技术就绪清单》；如果你的问题其实是「海外站在中国访问慢」，先读这篇排查指南。