AWS China vs Global: Partition Differences Measured Across 66 Services

Most writing on AWS China region differences is a catalog check: a service is listed or it is not. That method misses where migrations actually fail — on load-test day when nothing launches, or in month three when the event bus throttles at 4% of the traffic it was sized for. Catalog presence says nothing about versions, sub-features, rate limits, or price.

This article reports a different measurement. Two brand-new AWS accounts — one in the China partition (Beijing cn-north-1, Ningxia cn-northwest-1), one in the global partition (us-east-1) — were measured against each other across 66 services and four dimensions. Because both accounts were empty on day one, every number here is a cold-start baseline: the defaults a new product team inherits at AWS China, with no account history and no negotiated limits.

The four dimensions, per service, always the same:

Two scope notes. First, this is not a catalog comparison; accounts, operators, and catalog gaps are covered in our AWS China orientation guide. Second, AI services are out of scope for the per-service matrix: in a separate measurement campaign, AWS China Bedrock availability resolved to a simple fact — no endpoint for Bedrock or any managed AI API in either China region, leaving SageMaker self-build, with a 2021-generation A10G accelerator ceiling, as the only path.

Official AWS sources, for cross-checking anything below:

• AWS China product catalog and features — www.amazonaws.cn/en/products/
• AWS China official price list — www.amazonaws.cn/en/pricing/
• AWS China documentation — docs.amazonaws.cn

These are the authoritative references; this article’s numbers are independent measurements taken at a point in time.

How we tested

The method — we call it a four-dimension partition benchmark — is symmetric measurement: every number below was produced by calling the same read-only AWS API, with the same commands, against both partitions on the same days, so any difference in these tables can only come from the platform, never from the measurement. The principle is falsifiability: each table names the API behind it and every open question we could not resolve is published rather than smoothed over, so your team can re-run the commands against your own accounts and check us.

• When: October 11–12, 2026, in six batches, all commands re-runnable.
• Accounts: One fresh China-partition account, one fresh global account. Account identifiers are excluded from this article. “Fresh” matters: applied quotas carry account history, so every quota number below is the default layer — the factory setting a new team inherits.
• Method: Read-only API calls only — describe / list / get. Zero resources created, zero spend. Service-quotas values read from both API layers (see field note below). Engine versions from describe-*-engine-versions. Endpoint existence verified per service by calling a minimal read API and classifying the response; “not deployed” below always means the endpoint does not exist in public DNS or rejects the call as unsupported — never a guess.
• Pricing: Read from the Price List API (EC2 per instance type; managed services pulled as full regional catalogs and matched client-side). One structural finding: RDS and Aurora compute SKUs are absent from the Pricing API for the China partition — for those, and only those, you must price from the official AWS China price list; the blind-spot table in the Cost insight is the complete list of verified gaps. Everything else in this article is API-sourced.
• All prices are shown in USD; China list prices were billed in CNY and converted at ≈7.1 CNY/USD.

Field note: read quotas in two layers, or you will misread them

Our first pass concluded that the Lambda concurrency quota “does not exist” in China: GetServiceQuota returned NoSuchResource while the console showed 1,000. The resolution: applied-value and default-value are two different APIs, and a quota that was never initialized is invisible to the applied layer — GetAWSDefaultServiceQuota returned 1,000 cleanly. This is not China-specific; any fresh account behaves this way. Every quota claim in this article survived the two-layer read.

Key numbers at a glance

For readers with thirty seconds — and for anyone quoting this benchmark — five numbers carry most of the weight. Each links to the section that measures it.

The matrix: 66 services, four dimensions, three regions

Each service gets the same four-row table. The Gap column is the verdict; the three region columns are the evidence. “Parity” means all three regions returned the same answer. Ten further service surfaces have no endpoint in either China region; they are consolidated in the closing table of this section, so the ledger closes at 66 measured plus 10 absent. One convention on Cost rows: a number is API-measured on both sides, three dashes mean the unit was simply not captured by this benchmark, and the only verified API absence — RDS and Aurora compute — points to the blind-spot table in the Cost insight.

Compute and runtime

EC2 — one-third the catalog, no 7th generation, three GPU chips

EKS — service healthy; quota self-service not integrated

ECS / Fargate — API parity; the difference is quota management

Lambda — durable-execution rates halved

Auto Scaling — full parity

Batch — full parity

Elastic Beanstalk — works everywhere; quota plane absent in China

Messaging and streaming

SQS — parity

SNS — transaction rates at one twenty-fifth of global

EventBridge — invocation and PutEvents rates at one twenty-fifth

Step Functions — parity

MSK (Kafka) — 36 versions, fully in sync

Amazon MQ — the dataset’s only major-version gap

Kinesis (Streams + Firehose) — parity

Application platform

AppSync — API parity; quota plane absent

API Gateway — REST works; HTTP API does not exist

AppConfig — parity

Cloud Map — parity

Systems Manager (incl. Parameter Store) — parity

Data layer

RDS MySQL — versions in sync; Beijing and Ningxia quotas diverge

RDS PostgreSQL — latest in sync; 11 fewer historical versions

RDS MariaDB — fully in sync

Aurora MySQL — latest in sync

Aurora PostgreSQL — two minor versions behind

DynamoDB — full parity, measured twice

DocumentDB — engines in sync; instance classes trimmed

ElastiCache — engines in sync (including Valkey); Ningxia trims history

MemoryDB — fully in sync

Neptune — the only engine ahead of global

OpenSearch — engines in sync; the serverless variant is absent

Redshift — works; version API too coarse to compare fairly

DAX — works; a quota-catalog oddity worth recording

Storage and backup

S3 (incl. S3 Tables) — parity, except Beijing’s object-size ceiling

EBS — parity, and gp3 is cheaper in Ningxia

EFS — works; quota plane absent in China

FSx — works; OpenZFS capacity quota quartered

AWS Backup — parity

Network and edge

VPC / ELB — Beijing LCU premium on the ingress line

Transit Gateway — works; attachment premium 41%

PrivateLink — catalog breadth, not price, is the gap

CloudFront — distributions work; no edge compute; Ningxia end of support 2027-05-31

Route 53 — zones and health checks in; traffic policy and registration out

Direct Connect — parity

Identity and security

IAM — parity

Organizations — fully usable inside China; no bridge to your global org

IAM Identity Center — parity within the partition

KMS — request rates at one tenth

Secrets Manager — parity

ACM — parity

WAF (v2) — service parity; quota plane absent

GuardDuty — parity

CloudTrail — parity

AWS Config — parity

DevOps toolchain

CloudFormation — parity

ECR — parity

CodePipeline — parity (and its quota plane IS integrated — an earlier draft of our notes said otherwise; corrected against measured data)

CodeBuild — works; quota plane absent, which makes CI concurrency opaque

CodeDeploy — works; fleet sizes halved

Observability

CloudWatch — core parity; RUM out, query throttles lower

X-Ray — parity

Analytics

Athena — concurrent queries one tenth of global

Glue — parity

EMR — works; release-catalog comparison deferred

QuickSight — API reachable; fresh account not subscribed

SaaS-critical services

SES — deployed in Ningxia only; a region-selection factor

DMS — works; narrower engine menu

Not deployed in either China region

These endpoints do not exist in Beijing or Ningxia. The replacement path is the actionable content:

Dimension insights

Versions: sync is the norm, and the exceptions fit on one line

Of the 17 engine lines with a comparable version axis, 12 match the latest version in both China regions — including EKS (1.37, with Auto Mode), MSK (36 Kafka versions), and the entire open-source database line, down to Valkey 9.1, an engine that first shipped in 2024. The “China database versions lag” folklore is not supported by measurement.

The exceptions, in full: Aurora PostgreSQL is two minors behind (18.4 vs 18.6); Amazon MQ is the only major-version gap — both RabbitMQ (4.2 vs 4.3) and ActiveMQ (5.18 vs 5.19); Neptune is ahead in both China regions (1.4.8.1 vs 1.4.8.0), the dataset’s only inversion; ElastiCache memcached drops four historical versions in Ningxia. If your workload is version-sensitive, your entire pre-migration version audit is these four lines.

Features: whole families are missing, not thinned

Feature gaps in the China partition are structural absences, not degradation. EC2 has 432–461 instance types against 1,375 — but within any family that exists, every size matches global exactly (g4dn 7/7, g5 8/8). The same pattern repeats at every layer: OpenSearch exists, OpenSearch Serverless does not; API Gateway REST exists, HTTP API does not; CloudFront distributions exist, the entire edge-compute plane (Functions, KV stores, realtime logs, and Lambda@Edge by dependency) does not.

AWS China GPU instances warrant specific attention in architecture reviews: three accelerator chips (T4, A10G, Inferentia) against thirteen in us-east-1, including the 2026-generation B200/B300, and the 7th-generation CPU families (m7i/c7i/r7i) have not landed. Performance-generation-sensitive workloads face a hard ceiling. On the AI stack, the scope note from the introduction applies: no Bedrock, no managed AI APIs, SageMaker self-build with an A10G ceiling.

Quotas: rate limits, not resource limits

This dimension produced the numbers most likely to change a migration plan. Resource-class quotas (vCPUs, DB instances, tables) are mostly partition-consistent at the default layer — but the rate-class quotas run 10–25× below global: EventBridge invocations at 750 vs 18,750 TPS, SNS topic operations at 120 vs 3,000 TPS, KMS symmetric crypto at 10k vs 100k TPS, Athena concurrent queries at 20 vs 200. These limits bind CI/CD pipelines, event backbones, and BI dashboards on launch day, not at scale.

Three structural findings around them:

1. The quota management plane is itself gapped. Global exposes 320 services through self-service quotas; China exposes 119/111 — and the missing set includes EKS, API Gateway, CodeBuild, WAF, and EFS. For those, the ceiling is real but unreadable from the API.
2. “Not adjustable” is the default posture. 94% of Beijing’s EC2 quota items carry no increase path. You design around them; you don’t file tickets.
3. Intra-China asymmetry is real and material. RDS instances default to 20 in Beijing vs 40 in Ningxia; the S3 object-size quota is reported under two conventions (5 TB vs 48.83 TB — pending verification); SES exists only in Ningxia. “Which China region” is a first-order architecture decision, not a footnote.

Cost: Beijing premium, Ningxia discount

AWS China pricing divides cleanly by region (CNY list prices converted at ≈7.1). Beijing runs +23–49% over us-east-1 on compute (m6i.xlarge +49%, c6i +23%), adds a 153% premium on ALB LCU-hours, and charges +41% for Transit Gateway attachments. Ningxia, meanwhile, prices at or below us-east-1 almost across the board: m5.xlarge −1%, GPU g5.12xlarge −6%, EBS gp3 −6%, ALB −37%, Lambda at exact parity, ElastiCache at parity. Public IPv4 addresses are cheaper in both (−7%).

For budget modeling: EC2, EBS, S3, ALB, ElastiCache, Lambda, EKS, TGW, and PrivateLink are all API-priced for China and captured throughout this article. The Cost rows elsewhere in the matrix that carry dashes were simply not captured by this benchmark — not claimed absent. What the China Pricing API genuinely lacks is a short list:

The Pricing API blind-spot list

Two practical notes for FinOps automation. The catalog pull must be location-based — server-side usagetype filters silently return nothing for China regions — and EBS hides under the AmazonEC2 service code with CNN1-/CNW1-prefixed usagetypes. Once those two conventions are handled, everything in the bottom row scripts cleanly; the database lines do not, as of data version v2026-10.

The compute bill: EC2 and EKS

Every line measured at Linux / shared tenancy / on-demand, shown in USD (China CNY list prices converted at ≈7.1).

Note the inversion: standard families carry a Beijing premium of +23–49%, but burstable t3/t4g run 11–38% below us-east-1 in both China regions, making small dev/test workloads among the few things genuinely cheaper in China. The 7th-generation rows express the generation gap from the features section as money.

The database bill: managed vs self-hosted

Managed database pricing splits into what the API exposes and what it doesn’t. RDS and Aurora compute SKUs are the one blind spot — us-east-1 baselines below are API-measured; China prices for those four rows must come from the official China price pages or the Amazon Pricing Calculator (China region) for interactive estimates. Everything else is measured.

The self-hosted rows quantify the fallback where a managed price is not API-readable: the floor is an EC2 node that prices exactly. In Ningxia that floor sits at −1% vs us-east-1.

The storage bill: S3 classes and EBS volume types

S3 storage classes (GB-month; the 2026 price catalog renames Standard to “General Purpose” and Glacier tiers to “Archive” — old names shown for readability):

EBS volume types (GB-month, full ladder):

The storage pattern is consistent: Beijing carries roughly +5% on block storage and +8–51% on object storage by class, while Ningxia lands at or below us-east-1 on every row; provisioned-IOPS SSD is 14% cheaper there. Archive classes carry a +6–18% premium over us-east-1 — modest, but log-retention and backup-heavy SaaS should still re-run the math before porting a retention policy.

One claim withdrawn during review: an earlier draft flagged the Beijing g5 ladder as inverted because g5.12xlarge (4× A10G, $7.55) lists above g5.16xlarge (1× A10G, $5.46). Sorting by GPU count shows this mirrors the global structure exactly — us-east-1 prices the same pair at $5.67 vs $4.10. The ladder is GPU-count-driven; there is no anomaly.

Four conclusions from 66 services

Read across the four dimensions and four structural conclusions emerge:

1. The catalog was never the problem. Of the 76 service surfaces a complex SaaS would touch, 66 are deployed, healthy, and measured below, and 10 have no endpoint in either region; on the version axis, 12 of 17 engine lines match global’s latest in both regions. A team that stops at “is it listed?” predicts failure where measurement shows parity, and misses it where it actually occurs.

2. The gaps are in rate and management planes. The gaps that bite are EventBridge at 4% of global TPS, KMS at 10%, Athena at 10%, quota APIs that cannot answer for EKS and CodeBuild, and an edge-compute plane that doesn’t exist. None of these appear in a catalog; they appear in production.

3. Beijing and Ningxia are different products. The intra-China asymmetries (RDS 20 vs 40, SES Ningxia-only, S3 replication destinations 2 vs 28, ALB LCU +153% vs −0%, EBS +5% vs −6%) mean region selection is an architecture decision with quota, cost, and feature consequences — made once, at the start. For cost-sensitive, latency-tolerant workloads the data says Ningxia; for anything needing SES or lower latency to North China, Beijing — with its premium — is the only option.

4. A fresh account is a known quantity. Because this baseline was measured on day-zero accounts, a new product team can read every default above as their own starting position — and the two-layer quota method in our field note tells them how to keep reading it correctly as they grow.

Decision rules, condensed:

What we could not pin down

Published, not hidden. Status vocabulary: verified (double-checked), needs-console-review (API evidence is strong but the console must confirm), inconclusive (this method cannot resolve it).

Appendix: reproduce every table

The claim “all commands re-runnable” should be checkable, not trusted. Every command below is read-only (describe / list / get), costs nothing, and produces rows in this article. China-region calls need a China-partition profile; us-east-1 calls need a global one.

# Quota catalog coverage — the 320 vs 119/111 table
aws service-quotas list-services --region cn-north-1

# Default-layer quotas per service — the layer every quota number here uses
aws service-quotas list-aws-default-service-quotas --service-code ec2 --region cn-north-1

# Two-layer quota read — the field-note method (applied vs default)
aws service-quotas get-service-quota --service-code lambda --quota-code L-B99A9384 --region cn-north-1
aws service-quotas get-aws-default-service-quota --service-code lambda --quota-code L-B99A9384 --region cn-north-1

# Engine versions — the version tables
aws eks describe-cluster-versions --region cn-north-1
aws rds describe-db-engine-versions --engine aurora-postgresql --region cn-north-1
aws elasticache describe-cache-engine-versions --region cn-northwest-1
aws kafka list-kafka-versions --region cn-north-1
aws mq describe-broker-engine-types --region cn-north-1
aws opensearch list-versions --region cn-north-1

# Compute breadth and GPU inventory
aws ec2 describe-instance-type-offerings --region cn-north-1
aws ec2 describe-instance-types --instance-types g5.12xlarge --region cn-north-1   # GpuInfo

# Feature presence — one minimal read probe per service
aws sqs list-queues --region cn-north-1
aws apigatewayv2 get-apis --region cn-north-1          # HTTP API: fails in China regions, by design of the probe
aws sesv2 get-account --region cn-northwest-1          # SES: Ningxia responds, Beijing has no endpoint

# Prices — Price List API, always queried via the us-east-1 pricing endpoint
aws pricing get-products --service-code AmazonEC2 \
  --filters 'Type=TERM_MATCH,Field=regionCode,Value=cn-north-1' 'Type=TERM_MATCH,Field=instanceType,Value=m5.xlarge'
aws pricing get-products --service-code awselb \
  --filters 'Type=TERM_MATCH,Field=location,Value=China (Beijing)'   # full catalog pull; match SKUs client-side

Data version, citation, and requesting a test

Data version: v2026-10 (measured 2026-10-11/12). No fixed re-test cadence is promised — most of these measurements are one-shot by design. Re-measurements and extensions increment the version and land in the changelog.

Download the dataset. Every quantitative row in this article — quota values, engine versions, probe statuses, and unit prices, 224 rows with the source API named on each — is exportable as machine-readable data:

• JSON (aws-china-partition-benchmark-v2026-10.json, ~60 KB)
• CSV (long format: service, dimension, metric, region columns, source API)

Both carry the same metadata block as this article (method, dates, conventions, withdrawn claims) and are served under CC BY 4.0 with attribution to Chinaready.

Changelog

• v2026-10 — 2026-10-12 — Initial release: 66 services × 4 dimensions × 3 regions; quota catalog diff (320/119/111); per-service default-layer quota alignment; unit prices for 10+ cost lines; RDS/Aurora identified as the Pricing API blind spot for China.

Cite this dataset

Chinaready. "AWS China vs Global: Partition Differences Measured Across 66 Services."
Chinaready Insights, four-dimension partition benchmark, data version v2026-10, 2026-10-12.
https://chinaready.co/insights/aws-china-partition-benchmark/

<cite>Chinaready. <a href="https://chinaready.co/insights/aws-china-partition-benchmark/">AWS China vs Global: Partition Differences Measured Across 66 Services</a>. Chinaready Insights, four-dimension partition benchmark, data version v2026-10, 2026-10-12.</cite>

Attribution, trademarks, and disclaimer

Disclaimer. The measurements and conclusions in this article are an independent, user-side evaluation conducted by Chinaready. They do not represent the official position of Amazon Web Services, Inc. or the operators of the AWS China regions — this is a customer’s benchmark, not an AWS test. All AWS product names and trademarks are the property of AWS. For authoritative answers on AWS products, pricing, or quotas, use the official sources listed at the top of this article or contact AWS China through its official channels.

Attribution and copyright. The dataset downloads (JSON and CSV) are licensed under CC BY 4.0 with attribution to Chinaready. The article text is © 2026 Chinaready; quote or excerpt it with a link to this page.

Request a test

This dataset covers what a migration review needs, not everything. If a service, region pair, or dimension you care about is missing or stale, request a test. Two ways in:

1. Use the contact form — tell us what you need measured and why it matters to your architecture.
2. Email [email protected] with your test request.

Selected requests get measured and folded into the next data version with a changelog entry. Requests that map to a real architecture question tend to get picked first.

Where to go next

• AWS China partition — what works vs global accounts — the orientation Guide behind this dataset: accounts, operators, catalog gaps, ICP adjacency.
• ICP and PSB filing explained — the compliance step that gates every public endpoint in this article.
• China Readiness Assessment — if these tables describe your next quarter.