AWS 中国区实战：与国际区服务目录之外的真实差距

Wed, 07 Oct 2026 15:00:00 +0800

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 的评估服务可以帮你把这套五维核对跑成正式流程；想要目录级的对等性清单，见《进中国市场技术就绪清单》；如果你的问题其实是「海外站在中国访问慢」，先读这篇排查指南。

中国区 on Martin Liu's Blog