Does Snowflake Work in China? Region Availability, Data Residency & Cross-Border Transfer
Snowflake is reachable from mainland China, and Snowflake even operates a separate China (Ningxia) region (cn-northwest-1 on AWS) — so reachability is not the real China question. The decision is data residency: the Snowflake account most teams run lives in an offshore region, and loading personal information or important data collected in mainland China into it is a cross-border transfer (数据出境) under PIPL — notice, a separate consent, and a transfer mechanism, possibly a data-export security assessment, and for a critical information infrastructure operator the Cybersecurity Law's in-country storage duty under Article 39 (formerly Article 37). A compliance-first look at Snowflake's region availability, the data-residency question, and the lawful path.
Does Snowflake work in China?
Yes — Snowflake is reachable from mainland China, and Snowflake even operates a separate China (Ningxia) region — so the honest answer is that reachability is not the problem. What actually decides the China question is data residency.
The Snowflake account most teams already run does not live in China; it lives in an offshore region on AWS, Azure, or Google Cloud. The moment personal information or important data collected in mainland China lands in that offshore account, it is a cross-border transfer (数据出境) under PIPL — requiring notice, a separate consent, and a transfer mechanism — and it may be subject to China's data-export security assessment. For a critical information infrastructure operator, the Cybersecurity Law's Article 39 (formerly Article 37) requires that such data be stored in China, which an offshore Snowflake region cannot satisfy.
21YunBox maps your cross-border and residency exposure, localizes the China-collected data onto a China-resident store (analyzing only what may lawfully leave in your global Snowflake), and delivers your China-facing app and dashboards in-country on ICP-filed infrastructure — with no rebuild, and never any form of circumvention. Treat the specifics as a risk to confirm with counsel.
What Snowflake's own documentation says about China
| Fact | Primary source |
|---|---|
| Snowflake lists exactly one China region, and it is a separate deployment. Under the heading “Asia Pacific and China,” Snowflake's Supported cloud regions documentation lists China (Ningxia), region ID cn-northwest-1 on AWS, and states: “The China region is separate from other Snowflake regions. It utilizes a separate domain name (snowflakecomputing.cn) and is wholly operated by Digital China Cloud Technology Limited (DCC), an authorized operating partner of Snowflake, Inc.” | Snowflake Documentation, “Supported cloud regions” (docs.snowflake.com), retrieved 2026-10-08 |
| The China (Ningxia) region reached general availability on September 1, 2024. Snowflake's release note, “China (Ningxia) region - General Availability,” announces “the general availability of the following region,” which it says “was previously introduced as a preview in June 2024,” listing cn-northwest-1 on AWS, operated by DCC. | Snowflake Documentation, release note “China (Ningxia) region - General Availability,” dated September 1, 2024 (docs.snowflake.com), retrieved 2026-10-08 |
| A China-region account is opened through the local operator, not by self-service. Snowflake's documentation states that customers “cannot use self-service to create their initial account in the China region” and “must request the account through DCC” under a separate agreement — so the China deployment is reached through its local operator, not switched on from a global Snowflake account. | Snowflake Documentation, “Supported cloud regions” (docs.snowflake.com), retrieved 2026-10-08 |
| China-collected data sent to an offshore account is a PIPL cross-border transfer. Moving personal information collected from users in mainland China to a Snowflake account hosted in an offshore region triggers PIPL Articles 38–40: notice, a separate consent, and one transfer mechanism — a CAC security assessment, the CAC standard contract, or certification. | Personal Information Protection Law of the PRC, Articles 38–40 (cac.gov.cn), retrieved 2026-10-08 |
Sources verified by the 21YunBox compliance team on 2026-10-08.
For a data team pointing at mainland China, the first question about Snowflake is usually “can we even reach it?” — and the answer is yes. Snowflake runs on AWS, Azure, and Google Cloud, it is reachable from the mainland, and Snowflake even operates a separate China (Ningxia) region. So reachability is not where the China decision is won or lost. The decision is about data residency: where the data your warehouse holds was collected, and whether it is allowed to be there.
That is because the Snowflake account most companies already run does not live in China. It lives in an offshore region — somewhere in the Americas, Europe, or the wider Asia-Pacific — and the China (Ningxia) region is a separate, walled-off deployment, not an extension of it. The moment personal information or important data collected in mainland China lands in an offshore Snowflake account, you have made a cross-border transfer (数据出境), and a different body of law decides whether that was lawful.
Snowflake in China at a glance
| What decides it | In Snowflake's own terms — and China's law |
|---|---|
| What it is | Snowflake is a cloud data platform — a data warehouse and analytics engine that runs on AWS, Azure, and Google Cloud. Your account lives in whichever region you chose when you set it up. |
| Is it reachable from the mainland? | Yes. Snowflake is reachable from China, and Snowflake also operates a separate China (Ningxia) region (cn-northwest-1 on AWS), generally available since September 1, 2024. Reachability is not the China question. |
| Where does your data actually sit? | Almost always an offshore region — somewhere in the Americas, EMEA, or the wider Asia-Pacific. The China (Ningxia) region is a separate deployment, on its own domain and wholly operated by a local partner (DCC); it is not an extension of your global account. |
| Putting China-collected data in an offshore account | A cross-border transfer (数据出境) of personal information under PIPL (Articles 38–40): notice, a separate consent, and one transfer mechanism. It may trigger China's data-export security assessment, and for a critical information infrastructure operator the Cybersecurity Law's Article 39 (formerly Article 37) sets an in-country storage duty an offshore region cannot meet. |
| The lawful path | Keep the China-collected data in-country — in a China-resident warehouse — analyze only what may lawfully leave in your global Snowflake, and deliver the China-facing app and dashboards in-country on ICP-filed infrastructure. 21YunBox maps, localizes, and delivers; it never uses or suggests circumvention. |
Availability: reachable — but which Snowflake?
Snowflake’s position is set in its own documentation, not by a load-time test. The global service spans AWS, Azure, and Google Cloud across the Americas, Europe, the Middle East and Africa, and the Asia-Pacific. Separately, under the heading “Asia Pacific and China,” Snowflake lists one China region: China (Ningxia), region ID cn-northwest-1 on AWS, generally available since September 1, 2024 after a preview in June 2024. Snowflake describes that region as separate from its other regions, on a separate domain, and wholly operated by Digital China Cloud Technology Limited (DCC) — and notes that customers “cannot use self-service to create their initial account in the China region” and “must request the account through DCC.”
So “does it load from Beijing?” is the wrong test. It loads. The real question is which Snowflake your China-collected data sits in, and whether that data was allowed to leave the country at all. For that reason this page publishes no first-party China latency figure for Snowflake: speed is not the axis for a decision that turns on data residency. And to be unambiguous — 21YunBox neither provides nor suggests any form of circumvention; the productive question is how to keep your China data on a lawful footing.
The data-residency question: an offshore account is a cross-border transfer
Here is the gate most teams miss. A Snowflake account in any offshore region is, by definition, outside the mainland. Loading into it the personal information or important data that your product collected from users in China is a cross-border transfer of personal information under China’s Personal Information Protection Law. PIPL puts the duty on the handler — you, not the platform vendor: Articles 38–40 require notice, a separate consent distinct from the user’s agreement to use the product, and one transfer mechanism — a CAC security assessment, the CAC standard contract, or certification.
Above certain thresholds, or where the data is “important data,” that transfer may also require China’s data-export security assessment (数据出境安全评估) before anything leaves. And if your organization is a critical information infrastructure operator, the Cybersecurity Law’s Article 39 (formerly Article 37) requires that personal information and important data collected and generated in China be stored in China — an in-country storage duty that a Snowflake account hosted in an offshore region simply cannot satisfy. None of this turns on how fast a query returns; it turns on whether the data had a lawful basis to be there. Whether, and which of these, apply to your specific data is a risk to confirm with counsel against what you actually collect and store.
Why you can’t just “switch on” the China region
The China (Ningxia) region looks like the obvious fix — keep the data in China, problem solved. It can be part of the answer, but it is not a toggle on your existing account. Snowflake’s own documentation describes the China region as separate from its other regions, on a separate domain, and wholly operated by DCC, with the initial account requested through DCC under a separate agreement. In practice that means a China-resident Snowflake is a distinct deployment you stand up with the local operator — not a region you flip on inside your global org, and not somewhere your global data can simply flow.
So the data-residency decision is sharper than “pick a region.” Keeping China-collected data in-country means deciding what must stay (and holding it in a China-resident store), and what may lawfully leave (and only then analyzing it in your global Snowflake). That split is the heart of the work.
The lawful path — map, localize, deliver
There is a lawful way to run analytics for a China-facing product, and it has a shape. First, map: our China team works through your PIPL cross-border exposure and your data-residency duties — classifying what China-collected data must stay in the country and what may lawfully be transferred, and where a data-export security assessment or an Article 39 storage duty bites. Settle the legal conclusions with counsel; we frame the technical picture that feeds them.
Then localize: keep the China-collected personal and important data in-country, in a China-resident data store or domestic warehouse, and move only what may lawfully leave to your global Snowflake for the analytics you already run — so the warehouse you depend on stays useful without becoming the thing that carries data out of China unlawfully.
Then deliver: the China-facing app, the dashboards, and the reporting that sit on top are themselves public services in the mainland, so they carry an ICP filing (备案) duty and need compliant, in-country delivery. 21YunBox delivers them in-country — the 21YunBox Optimizer — in front of what you already run, with no rebuild and no re-platform. The result is China-facing analytics that run on a lawful footing. What we do not do, and what no one lawfully can, is give you a way around China’s data-export rules: we localize what must stay and deliver in-country, we never route data out of the country by stealth.
Related reading:
- Cross-border data transfers under PIPL
- China’s data-export security assessment
- China’s Cybersecurity Law (data localization, Article 39)
- How to get an ICP filing for China
