China Unicom Zhongwei Cloud Is Live. Its Usable Capacity Still Has to Be Proven.

Summary

• AS10206 is a registered, visibly active network identity, while dated public records show a China Unicom campus in Zhongwei moving from trial racks to multiple operating buildings. Neither evidence set publicly maps a prefix, router or customer port to a particular hall and contract.
• Rack totals, mechanical delivery, substation ratings and low-PUE claims describe real infrastructure milestones, not a dated inventory of commissioned, compatible and uncommitted capacity that remains usable during a major failure.
• A serious buyer should contract against named assets and duties: the legal seller, assigned hall and rack, power train, physically traced fibre paths, compatible spares, repair windows, alternate recovery site, tested restore objective and workable data exit.

The name identifies a network surface, not the whole service

“China Unicom Zhongwei Cloud” sounds like a complete commercial entity. In the public record, it is more useful to begin with a narrower statement. The APNIC record for AS10206 describes CUZW-CN as China Unicom Zhongwei Cloud, assigns it to China and records routing policies involving AS4837 and AS9929. That is strong evidence that the name belongs to a maintained autonomous-system entity inside China Unicom structures. It is not a certificate of incorporation, a customer agreement, a property title or a list of the equipment carrying any one workload.

Physical records point to related but differently named parties. A 2025 land-use permit for a second data-centre park names the Ningxia branch of China United Network Communications Limited as the land user for 150 mu and a plan involving three data-centre buildings and supporting works. Other power documents use the Ningxia branch or the Zhongwei city branch as project owner. Those names establish responsibility for land or physical works at the level described by each document. They do not establish that every service advertised under the AS10206 label is sold by that same branch, or that no affiliate, platform operator, equipment lessor or maintenance contractor sits between the customer and the asset.

This distinction matters because a hosted service is assembled from rights and obligations, not from a brand name. A buyer may receive floor space from one legal party, servers from another, bandwidth through a third arrangement and remote maintenance from a fourth team. The IP addresses may be originated by AS10206 while the traffic reaches a national backbone, and the application may sit on hardware owned by either side. A common name can describe the experience without defining who owes the remedy when one layer fails.

The safe identity model therefore keeps several layers separate. AS10206 is not automatically the China Unicom parent. It is not AS4837, AS9929, the Ningxia provincial network, the China Unicom Cloud brand or China Unicom’s international operations. It is also not Ningxia West Cloud Data Technology or the AWS Ningxia network. Association among these entities can be operationally important, but association is not a licence to combine their routes, buildings, staff or spare capacity into one pool.

Before considering scale, a customer needs a legal and technical schedule that says who sells the service, who owns or controls the assigned hardware, who operates the hall, who controls the relevant network ports and who can authorise repair. The contract should identify material subcontractors and should state which entity receives incident notices, holds customer data, approves remote access and returns or deletes data at exit. Without that schedule, the buyer may know that the wider environment is real while still not knowing which party is accountable for the particular service it bought.

AS10206 proves reachability, not physical route diversity

The routing evidence is meaningful. The Hurricane Electric view of AS10206 displays originated IPv4 and IPv6 prefixes, RPKI status for the routes shown and an observed adjacency to AS4837. The IPinfo AS10206 overview also shows active address and relationship observations. At the prefix level, IPinfo’s view of 103.251.240.0/24 places the allocation in a Ningxia context and shows a measured path involving AS4837. A separate BigDataCloud observation of the same /24 identifies AS10206 as the origin and AS4837 as the receiving network. Taken together, these records justify a straightforward conclusion: AS10206 is not a dormant label. It is visible in live internet routing.

That conclusion has a strict limit. Border Gateway Protocol describes logical reachability. A collector can see an origin and an adjacent network without seeing the router chassis, the line card, the optical transport system, the building entrance or the conduit under the road. A sampled path to one address does not locate all addresses in one hall. Nor does a geolocation label prove where a server, customer port or network edge is installed. Routing observations change over time and vary by collector; even a stable relationship says little about the physical failure domain underneath it.

The APNIC policy records AS4837 and AS9929, but current displayed observations in the fact set consistently show AS4837 and do not establish a simultaneously active AS9929 path. It would be wrong to turn a registered policy into a statement that two upstreams are live. It would still be wrong to call two live sessions physically diverse without route drawings. Two BGP sessions can terminate on one router, use the same optical shelf, leave through the same entrance, share one conduit or converge on the same regional site. Logical multiplicity becomes resilience only after the physical dependencies are traced.

There is also evidence of participation in a broader cloud-connectivity environment. The bgp.tools view of AS135629 lists AS10206 as one upstream for the network associated with Ningxia West Cloud Data Technology and AWS Ningxia. This is useful corroboration of a regional role. It does not prove that AS10206 owns AS135629, that the two networks share a building, that a China Unicom Zhongwei Cloud customer occupies AWS equipment or that either side provides recovery capacity to the other.

Geographic service claims require the same restraint. A 2025 report on the wider Zhongwei cluster names direct links to Beijing, Shanghai, Guangzhou and Chengdu and says the cluster reached 26 important cities. Those claims indicate substantial intercity connectivity in Zhongwei’s data-centre economy. They do not assign every city link to AS10206, reveal the path of a contracted circuit or establish that the path avoids a common backbone failure.

For a buyer, the route question is concrete. Which customer-facing prefixes will be used? On which edge routers and ports? Which upstream sessions are active for those prefixes? Where are the handoffs? Do the circuits enter through separate building sides and travel in separate conduits? Do they use separate optical systems and aggregation rooms? Where do they first converge? A credible answer includes circuit identifiers, as-built route drawings, carrier letters and a witnessed isolation test.

Public BGP evidence earns AS10206 a medium network-evidence grade: clearly live, but not publicly mapped to the rack or demonstrated as physically diverse.

The Zhongwei campus has crossed from concept into operation

The physical story is stronger than a single announcement because it unfolds across dated records. A 2020 municipal account of the western data hub described a 200-mu concept with six data-centre buildings while the first phase was still under construction. At that point, the large numbers belonged to a plan. The document is evidence of intent, site development and an early design frame, not evidence that all proposed racks had been built or powered.

By April 2021, the status had changed. A municipal report on the Zhongwei internet exchange and campus said one IDC building and an operations building had been completed, with 760 racks in trial operation. It also described government and medical cloud workloads as in use. Trial operation is not the same as full commercial acceptance, but named workloads and working racks are credible operating evidence. They move the campus beyond rendering, permit or shell construction.

Expansion reporting then introduced both commercial traction and ambiguity. A September 2021 project update said 1,500 first-phase racks had been sold and described a second phase designed around 4,000 racks at 8 kW. The claim that racks were sold indicates demand or reservation, not necessarily installation and energisation. More importantly, the number did not remain stable. An April 2022 major-project report put first-phase installation above 90 per cent and described a 2,000-rack second phase, reportedly pre-sold. The public record does not supply a bridge explaining whether the earlier 4,000 represented a larger concept, a different phase boundary or a plan later reduced.

The November 2022 Fujian–Ningxia Cloud launch again referred to 2,000 racks in the second phase and another 2,000-rack third phase. It reported more than ten Fujian enterprise users for the initial service. That is evidence of an interprovincial workload relationship and commercial use. It does not reveal those users’ rack assignments, contracted power, network paths or restoration arrangements.

Construction milestones continued. A May 2023 report on the third building recorded structural topping-out for a design of 2,000 racks at 8 kW and more than 30,000 servers. Topping out proves the structure reached an important stage. It says nothing by itself about switchgear, UPS systems, cooling loops, network acceptance, fire systems, customer installation or live load.

By December 2024, a government-hosted account of the Zhongwei AIDC site described two operating buildings, 1,500 racks at 4 kW and 2,000 racks at 8 kW, more than 14,000 GPU chips and installation above 85 per cent. It also named government, medical, Kingsoft Cloud and Lenovo workloads. Several figures originated with the operator and lack a public building-level audit, but the combined details make continued operation difficult to doubt.

The later record shows a campus still moving. A December 2025 operating update reported five operating buildings, two more under construction and more than 8,000 delivered racks. It also described a future concept of 120,000 standard racks and 300 MW of IT load. The first set is a dated operating milestone; the second is a projection. A January 2026 report on DC6 said that building had been mechanically delivered with 1,992 racks and about 29 MW of IT capacity, while DC7 was in testing and DC8 remained at an earlier construction status.

This chronology supports a medium-high grade for campus operating evidence. It also makes status language decisive. A campus can be operating while one building is mechanically delivered, another is being tested and a third is still progressing through civil works. The existence of live buildings cannot accelerate the status of later ones. The evidence should be read building by building and date by date, not compressed into a single campus capacity number.

Rack arithmetic conceals the inventory a customer actually needs

Rack counts are attractive because they appear comparable. In practice, each count answers a different question. A designed rack is a spatial and engineering intention. An installed rack may lack commissioned power or network access. A powered rack may be reserved, incompatible with a customer’s density or unavailable under maintenance conditions. A sold rack may not yet be accepted. A mechanically delivered building may still be awaiting integrated tests. None of these states is the same as an uncommitted rack that can carry a new workload and remain serviceable through a defined failure.

The second-phase conflict illustrates the problem. Public accounts moved from a 4,000-rack plan in 2021 to 2,000 racks in 2022 without a published as-built reconciliation. Adding both numbers would double count. Choosing one as the current total would pretend the scope change had been explained. The only defensible treatment is to preserve both dated statements, identify the conflict and refuse to convert either one into current free capacity.

The fourth-phase record offers another warning. A 2024 EPC procurement notice described a building and support-centre scope with about 1,625 racks at 20 kW and a design PUE of 1.197. A later natural-resources notice cancelled the earlier planning permit at the applicant’s request for scheme optimisation. Subsequent reporting says building 4 entered operation, but the public material does not connect the tender design, the cancelled permit, the revised scheme and the final operating configuration in one stable table.

Other documents are precise about authorisation but not availability. The DC7 post-permit notice establishes project identity and permission to construct. It does not state commissioned rack or IT-load capacity. The DC8 planning notice describes a four-storey data-centre building with module, battery, electrical and auxiliary rooms and a diesel platform. That is useful physical scope. Planning-stage plant is not operating plant, and civil completion is not electrical acceptance.

Even the strongest current milestone, more than 8,000 delivered racks across a campus with five reported operating buildings, stops short of the buyer’s denominator. “Delivered” does not disclose how many racks are physically installed, energised, networked, commissioned and technically compatible. It does not disclose the number already loaded or reserved. It does not show how much space must remain unused because of electrical, cooling or structural limits. Above all, it does not show capacity after the largest credible failure.

A usable capacity statement needs a dated bridge for every relevant building. It should begin with design racks, then show installed, energised, commissioned and loaded racks. It should identify sold or reserved inventory, uncommitted inventory and the conversion method behind any “standard rack” figure. It should state actual IT MW, utility draw, supported density bands, cooling limits and hardware compatibility. The final column should show what remains usable when a transformer, bus, UPS block, cooling loop, aggregation switch or building is removed from service.

DC6 demonstrates why units cannot be mixed casually. The public milestone combines 1,992 racks with about 29 MW of IT capacity. Dividing one by the other might produce an average, but it would not reveal the intended density of each hall, distribution losses, cooling constraints, redundancy allocation or actual load. Nor would it show whether capacity is sold, reserved or ready for a recovery event. Rack arithmetic is not worthless; it is simply not inventory accounting.

For procurement, the proper question is not “How many racks does the campus have?” It is “Which dated, accepted and uncommitted assets are assigned to this service, at what power and cooling envelope, and what remains available during maintenance and failure?” Until the answer is supported by a building-level bridge, customer-usable capacity merits a low evidence grade even though the campus itself clearly operates.

Power documents show planned infrastructure, not a customer power train

The public power record is unusually useful because it names equipment ratings and source stations. It is also easy to overread. The environmental assessment for the first new 110 kV substation specifies three 63 MVA transformers, two intended 110 kV feeds from Fengyun No. 1 and No. 2 switch stations and 36 outgoing 10 kV circuits. The assessment expressly excludes the export-line works, which were handled separately. A later planning notice for that substation confirms authorisation and physical scope. Neither document is an energisation certificate, a load record or an integrated-systems test.

The upstream context is equally important. The Fengyun switch-station approval says the regional project was intended to support seven cloud enterprises. Two named feeds into a campus can therefore retain a shared dependency higher in the grid. “Dual feed” is not a complete resilience claim unless the customer can see where the sources originate, where they converge and what happens when the shared element is unavailable.

The assessment for a second 110 kV substation describes another three 63 MVA transformers, 36 outgoing circuits and two underground cable routes of roughly 1.5 km and 1.7 km. The routes use partially different corridors inside the campus, which is relevant physical-route evidence. Both originate at Datang switch station, and the document describes a proposed project. Partial corridor separation can reduce some local risks while leaving the source station as a common failure domain.

Energy-review documents add governance milestones without resolving load. A 2022 review for the second building’s mechanical and electrical works records passage through an energy review, but the public version omits consumption figures and does not prove commissioning. An amended energy review for the third building records changed review conditions and the need to address material changes, while actual energy figures remain unavailable. Review, permission, construction, energisation and stable operation are distinct states.

Three times 63 MVA also cannot be converted directly into 189 MW of sellable IT capacity. MVA is an apparent-power rating. The usable IT figure depends on power factor, transformer operating policy, losses, cooling and auxiliary loads, downstream distribution, maintenance reserve and the intended contingency model. In an N+1 arrangement, one unit may be held as reserve. In a different topology, the same nameplate can be allocated in another way. Without the one-line diagram, protection settings, live load and operating rule, the arithmetic does not disclose what a customer can consume.

The buyer needs the complete assigned power train, not the campus headline. That means the utility sources, switch stations, incoming circuits, transformers, medium-voltage paths, room switchgear, UPS blocks, batteries, generators, PDUs and rack feeds serving the contracted equipment. For each step, the buyer should know normal load, rated load, redundancy mode, maintenance state and the largest element that can fail without interrupting service. Generator count, runtime, fuel replenishment, battery autonomy and black-start or transfer test results matter because a grid design alone does not describe extended operation.

Power evidence is strongest when tied to an acceptance date and a specific customer hall. A nameplate in an assessment describes what is intended. An energisation record describes what became live. An integrated test describes how the elements behaved together. A customer schedule then identifies which of those elements support the purchased service. Public records here support a serious expansion story, but they do not publicly complete that chain.

Efficient cooling is plausible, while failure headroom remains unknown

Zhongwei’s climate and the published engineering choices make low-energy cooling plausible. The 2024 operating account cites outside-air cooling, indirect evaporative cooling, fluorine-pump systems and cold-plate liquid cooling, along with PUE below 1.2. The fourth-phase tender used a design PUE of 1.197. These are coherent technologies and targets for a dry, cool region serving a mixture of conventional and higher-density equipment.

They are not equivalent forms of proof. A design PUE is an engineering target for a stated design. An operator-reported PUE is meaningful only when its period, load, meter boundary and calculation method are understood. A campus number can conceal variation among buildings, halls and seasons. A low annual average does not show peak-day thermal performance. It does not reveal how the cooling system behaves during maintenance, a pump failure, a loss of water, a controls fault or a partial power interruption.

The national green and low-carbon data-centre action plan provides a wider policy direction around efficiency, utilisation and energy sourcing. It does not verify a particular Zhongwei building’s PUE or renewable-energy share. National ambition and site measurement belong at different evidence levels.

Cooling capacity also has a compatibility dimension. A hall designed around 4 kW racks differs from one designed for 8 kW or 20 kW racks. A cold-plate liquid-cooled accelerator installation requires a chain that may include coolant distribution, manifolds, compatible servers, leak detection, water treatment and trained maintenance. Empty floor space in one hall cannot necessarily receive equipment intended for another. A spare rack position does not become recovery capacity if its power density, cooling interface or network attachment is unsuitable.

Water evidence is another gap. Indirect evaporative approaches can reduce compressor use, but a buyer still needs the site’s water source, consumption envelope, storage, treatment and drought or interruption response. For liquid-cooled systems, the relevant questions include loop separation, component stocks, isolation procedures and the effect of a leak or pump outage. None of those questions is answered by a campus PUE headline.

The practical cooling schedule should identify the assigned hall’s normal and maximum density, cooling technology, current load, design outdoor conditions and maintenance reserve. It should show which cooling components are common to multiple rooms, how many can be unavailable, how long thermal ride-through lasts and whether a failed loop can be isolated without shutting down the customer equipment. Annual and peak-period readings should use a disclosed boundary. Failure tests should include the controls and electrical dependencies that actually start pumps and fans.

Efficiency deserves commercial attention because it affects cost, expansion and policy exposure. Resilience deserves separate attention because an efficient facility can still have little spare thermal capacity during a component failure. The public evidence supports credible engineering intent and reported performance. It does not quantify cooling failover headroom for the exact service a buyer would receive.

Hosted capacity is a chain of duties beyond the building

A data-centre campus can remain available while a hosted service fails. The official telecommunications service classification helps explain why: IDC services can combine space, maintenance, rented servers or storage, lines, bandwidth and supporting or security facilities. A customer buying “cloud” or “hosting” may therefore be buying several dependent services under one commercial description.

The MIIT guidance on customer data in IDC services distinguishes hosting, storage and compute scenarios and highlights boundaries among operator, customer and third-party responsibilities. It is general guidance, not an audit of China Unicom Zhongwei Cloud. Its value here is conceptual: responsibility changes with the service form. A customer-owned server in a rented rack raises different maintenance and data-access questions from rented compute managed by the operator.

At rack level, failure can begin with a PDU, power supply, disk, accelerator, memory module, firmware issue or liquid-cooling component. Facility redundancy does not repair a failed accelerator. The critical measure is the path from detection to restored service: monitoring ownership, remote-hands access, diagnostic authority, compatible stock, vendor escalation and the promised repair window. A rack may have two power feeds and still wait for a part that is not held on site.

At room or building level, the dependency widens to switchgear, busways, UPS and battery blocks, generators, cooling loops, aggregation switches and fire controls. Redundancy claims should name the component and operating state. N+1 cooling under normal load may become N during maintenance. Dual rack feeds may converge on one upstream switchboard. A generator system may carry essential loads but not the full commissioned IT load. The buyer needs a component map, not a general adjective.

At campus and regional level, substations, shared switch stations, common cable corridors, fuel resupply, site access and staffing can affect multiple buildings. The existence of five operating buildings improves the number of local placement options, but the buildings may still share grid, network and operational dependencies. A severe regional event can also delay staff and parts even when equipment remains powered.

The network path adds edge routers, optics, cross-connects, conduits, upstream backbone paths and route control. An error in route policy or DDoS controls can make a healthy server unreachable. A commercial issue can have the same user-visible effect: an expired cross-connect, billing dispute, service suspension or failed contract between operating parties can remove access without any physical damage.

Migration is a final dependency, often discovered late. Proprietary images, unexported encryption keys, slow data transfer, incompatible targets, missing logs or unaffordable egress can trap a workload. A service can meet its normal availability target and still expose the customer to a long outage when the relationship ends or a major failure requires relocation.

The contract should assign every duty. It should distinguish customer equipment from rented equipment, preventive maintenance from break-fix service, facility work from hardware work, and network restoration from application restoration. It should list response and repair clocks separately. It should name the stock held locally, the stock held elsewhere and the party that pays for urgent transport. Service credits are not a substitute for access to the people, parts and capacity that restore operation.

This is why the central procurement entity is not a rack count. It is an end-to-end service path with owners, dependencies and time limits. The building is indispensable, but only one link in that path.

Failure travels along shared components and repair queues

The public record names users and operating contexts without disclosing enough topology to calculate their exposure. Government and medical workloads in Ningxia, Fujian-linked enterprise services, named platform and technology customers, downstream networks and remote end users could all depend on some part of the Zhongwei environment. Their impact profiles differ. A government system, an accelerator workload, a storage service and an upstream customer network do not fail in the same way.

A useful failure analysis starts with the smallest component and expands outward. One server fault affects one workload unless clustering or storage design spreads the effect. One rack PDU can affect many servers. One room switchboard or cooling loop can affect many racks. One building aggregation point can affect an entire hall. One switch station, conduit corridor or route-control error can reach across buildings. At each level, the customer should identify the number of workloads that share the component and the available alternative.

The phrase “largest credible failure” should be made specific. For power, it may be a transformer, bus section, UPS block, generator group, substation or common source station. For cooling, it may be a coolant loop, controls domain, water source or electrical supply. For networking, it may be an edge chassis, meet-me room, conduit, optical system or upstream site. For operations, it may be loss of site access, a remote-hands backlog or a vendor unable to deliver compatible parts.

Repair windows deserve as much scrutiny as redundancy. A redundant component buys time or preserves service; it does not eliminate the need to repair the failed element before another failure occurs. The safe operating period may be hours or days depending on load and maintenance state. A buyer should ask how quickly the team detects the fault, dispatches authorised staff, isolates the component, obtains a replacement and returns the system to its intended resilience mode.

Stock claims should be expressed as a compatibility matrix. “Spares available” is weak when generations of server, accelerator, optic, power supply and cooling component are not interchangeable. The schedule should list quantities, locations, ownership, replenishment lead times and reserved versus shared status. It should state whether a part can be installed by on-site staff or requires an external vendor. For remote buyers, access permissions and change approval can be as important as physical stock.

Network repair has its own chain. A second route on a diagram does little if both routes share the damaged conduit or if only one is active for the customer prefix. A carrier’s restoration target may differ from the hosting operator’s service clock. The customer needs a joined escalation path that prevents each party from waiting for another. Isolation testing should demonstrate that traffic continues when one named path is deliberately withdrawn.

Commercial control should be tested in the same exercise. Who can approve emergency bandwidth, replacement hardware or movement into recovery capacity outside business hours? Can the customer retrieve keys and configuration when the primary management system is unavailable? Are incident communications independent of the affected service? A technically redundant design can be immobilised by an approval bottleneck.

Public information cannot answer these customer-specific questions. It can identify credible dependencies and show why a numerical availability estimate would be false precision. The absence of a public repair matrix is not evidence that repair arrangements are poor. It means the buyer must obtain them directly, place them in the contract and test them before treating resilience as proven.

Multiple buildings do not prove an independent recovery domain

The campus’s expansion creates options. Workloads may be distributed among rooms or buildings; equipment may be moved locally; maintenance can sometimes be absorbed elsewhere. Those are useful operational possibilities. They do not establish disaster recovery unless the alternative capacity is identified, reserved, compatible and sufficiently independent of the primary service.

No public evidence in the fact set identifies a second site for this exact service. There is no disclosed replication mode, reserved recovery inventory, achieved recovery point objective, achieved recovery time objective, witnessed restore exercise or network path shown to be independent of Zhongwei. The record also does not establish that spare capacity in another campus building remains available when the primary building fails.

Local separation and regional separation address different events. Another room can protect against a rack fault. Another building can protect against some room or building failures. It may not protect against a shared substation, switch station, fibre corridor, network edge, management domain, staffing constraint or regional access problem. An alternate site outside the campus may still share a backbone, operations team, commercial system or data-control dependency. Recovery design must follow the failure being mitigated.

Capacity is central. The recovery site needs enough compatible compute, storage, network and cooling resource at the moment of failure. Capacity sold to ordinary customers cannot simultaneously be guaranteed for recovery unless the allocation rule is explicit. A large campus total provides no assurance that the right hardware and power density are reserved. During a widespread event, multiple customers may invoke recovery at once, so shared reservation ratios should be disclosed and tested.

Replication alone is not restoration. A replica can be stale, corrupted, inaccessible or dependent on keys held in the failed environment. The buyer needs measured data lag, backup isolation, key custody and a documented sequence for bringing services up. The test should restore a representative workload and data set, validate network and identity dependencies, and measure the result from incident declaration to user access.

Independence should be demonstrated across utility supply, fibre, carriers, route control, management access, staffing and vendors. The alternate site should have a full legal operator name and address. Its customer-facing capacity should be scheduled in the agreement. The network path between sites and onward to users should be traced, including common points. A map with two dots is not enough.

Exercises should include uncomfortable conditions: a whole building unavailable, normal administrators unable to reach the primary management system, an off-hours start, one carrier path isolated and a need for compatible replacement hardware. The result should record what failed, what required manual intervention and whether the target times were achieved. A test that validates only backup creation does not prove restoration.

The correct public conclusion is narrow but consequential. Zhongwei has more than one operating building, and that physical scale can support resilient designs. Yet no public document closes the chain from those buildings to a service-specific, independent and tested recovery arrangement. Recovery evidence for the exact service remains low until the buyer sees a named site, reserved capacity, an architecture and recent witnessed results.

Data in Zhongwei can still cross operational and legal boundaries

Locating systems in Zhongwei can support a domestic-placement strategy. It gives the customer a real Chinese location around which to specify storage and processing. It does not, by itself, answer where every copy, log, support session or administrative action occurs. Data locality is a flow map and a set of duties, not a pin placed on the primary server hall.

China’s Data Security Law provides a framework involving data classification, protection, monitoring and the handling of important data. The Personal Information Protection Law sets duties for personal-information processing and addresses cross-border activity. The 2024 rules on cross-border data flows define current mechanisms and exemptions for covered transfers. Their application depends on the customer’s data, role, sector and actual processing. None of these sources decides a particular deployment’s compliance merely because the primary equipment sits in Ningxia.

A locality schedule should account for primary storage, replicas, backups, logs, monitoring data, support records and security telemetry. It should identify remote administration locations and every party that can access the systems. It should distinguish routine access from emergency support. Subcontractors, equipment vendors and managed-security teams may create operational flows that are invisible in a simple hosting diagram.

The customer also needs role clarity. Who determines the purposes and means of processing? Who acts on instructions? Who is responsible for responding to requests, classifying data, reporting incidents and deleting copies? The commercial label “cloud” does not settle those duties. They must be assigned for the actual service components and legal entities.

Recovery can change the data map. A backup or alternate site may be physically sound but legally unsuitable for a particular data set. Conversely, a domestic alternate may meet location requirements while sharing too many technical dependencies with the primary site. Legal and technical recovery destinations must be evaluated together. Replication should not be activated until the destination, access model, retention and onward flows are approved.

Logs and keys are especially important during failure and exit. A customer may be able to export application data but not the audit trail needed to prove completeness. Encryption can protect data while creating a dependence on key custody. The agreement should say who controls keys, how they are recovered if the management environment fails and how their destruction is evidenced.

Exit rights complete the locality story. The customer needs export formats, available bandwidth, fees, time limits, assistance, verification of completeness and deletion evidence. A large data set may be technically portable in theory but take too long to move through the contracted connection. A partial migration exercise can expose incompatible formats, missing metadata and unrealistic timing before an emergency.

Zhongwei therefore supplies meaningful location evidence but not a complete sovereignty answer. The buyer must map every data state and administrative path, then test both recovery and exit under the relevant legal conditions. Physical domestic placement is the starting point, not the conclusion.

Policy ambition supports the region, not an individual service guarantee

Zhongwei sits within a national effort to coordinate computing resources and place suitable workloads in western hubs. The East Data, West Computing implementation guidance addresses utilisation, east-west coordination and workload placement. That direction helps explain sustained construction, interprovincial customer links and attention to energy efficiency. It is evidence of strategic relevance, not a service-level warranty.

Policy can improve the operating environment by attracting grid investment, network links, skilled labour and related enterprises. A larger ecosystem may offer more carriers, equipment support and customer demand. It can also create shared dependencies. Several cloud enterprises may rely on the same regional switch station, transport corridors or labour market. Cluster growth can increase both the number of alternatives and the consequence of a common regional event.

National or regional targets should remain separate from assigned assets. A projected campus or cluster end state does not tell a buyer what is accepted today. A direct-link claim for the cluster does not define the path of one service. A low-carbon objective does not supply a building meter. The practical value of policy is realised only through completed, commissioned and contractually assigned infrastructure.

The buyer should nonetheless use the policy context in long-term diligence. Expansion plans can alter construction risk, utility topology, network congestion, access routes and maintenance activity around live buildings. New power and cooling systems may eventually increase resilience, but integration work can introduce temporary states. The agreement should require notice of material changes to assigned infrastructure and preserve the customer’s right to assess changed dependencies.

The economic question is also more specific than whether Zhongwei is growing. Hosting cost depends on usable power, compatible density, bandwidth, support labour, repair stock, reservation policy and exit terms. Cheap planned capacity is not cheap if the service cannot be restored promptly or moved. A buyer comparing regions should price the evidence required to turn physical scale into dependable service.

The strongest interpretation of the policy and campus record is neither scepticism nor promotion. Zhongwei is an established and expanding computing location with visible operating activity. China Unicom’s projects form a material part of that environment. But public ambition cannot fill the missing rows in a customer asset schedule. The service guarantee must still be built from accepted equipment, traced routes, assigned people and tested recovery.

Buyers should ask for a service map that survives one removal at a time

The evidence gaps can be converted into a practical verification programme. First, settle identity. The order form should state the full legal seller, invoicing party, data-handling roles and every material subcontractor. It should link the commercial service name to a precise asset schedule. If different China Unicom branches control land, power, network or support, the agreement should explain their duties and the customer’s remedy across those boundaries.

Second, settle placement. The schedule should name the campus, building, hall, cage or room, rack positions and equipment ownership. It should state whether assignments can change and what notice and approval a move requires. A facility letter should confirm the operator’s right to provide the space and services. Router and cross-connect records should tie the customer ports and prefixes to the named location.

Third, settle capacity. For the assigned building, obtain a dated bridge from design to installed, energised, commissioned, loaded, sold or reserved and uncommitted inventory. Record IT MW, utility MW, rack density and cooling compatibility. Identify capacity held for maintenance and the capacity that remains after the largest specified failure. Do not accept a campus total as a substitute.

Fourth, trace power from the rack outward. Name both rack feeds, PDUs, UPS blocks, switchgear paths, generators, transformers, incoming circuits and source stations. Mark every convergence point. Record normal load, contingency load and maintenance state. Review energisation and acceptance evidence and witness a test that removes one named path while the contracted load continues.

Fifth, trace the network in the same fashion. List customer prefixes, edge routers, ports, optics, meet-me rooms, entrances, conduits, upstream circuits and first convergence sites. Distinguish AS4837 and AS9929 policy from current sessions. Ask for physical route drawings and current telemetry. Test path withdrawal and confirm that monitoring, escalation and traffic restoration work as designed.

Sixth, contract for repair. Define detection, response, workaround and repair clocks separately. List compatible spare parts and their locations. Name remote-hands coverage, authorisation rules and vendor escalation. Review recent ticket performance for comparable equipment. Test an off-hours replacement and record the time needed to restore the intended redundancy level, not merely basic service.

Seventh, prove recovery. Name an alternate site outside the relevant primary failure domain, its legal operator and its reserved compatible capacity. Document replication, backup isolation, key custody, network independence and shared reservation assumptions. Run a whole-building restoration exercise with representative data and measure achieved recovery point and recovery time. Record unresolved manual steps.

Eighth, test exit. Export a representative workload, including data, metadata, logs, keys where appropriate and configuration needed to run elsewhere. Measure bandwidth, duration, cost and operational effort. Verify deletion and retention handling after the test. Ensure that a billing or contract dispute cannot block access to the material required for orderly migration.

The method across all eight steps is the same: remove one named component and observe what remains. Remove a power feed, a network path, a cooling component, a key administrator, a building or the primary site. The result should identify the real alternative, the time to use it and the person authorised to act. This turns resilience from a collection of nouns into demonstrated behaviour.

Verification should be repeated after material changes. Campus expansion, revised permits, new substations, building acceptance, equipment refreshes and changes in upstream routing can all alter the dependency map. A service that passed a test last year may no longer have the same components or reserve. The contract should require updated drawings and a fresh exercise when assigned infrastructure changes.

The evidence supports operation, but not capacity equivalence

China Unicom Zhongwei Cloud presents an unusual combination of strong existence evidence and weak customer-level mapping. AS10206 is registered and visible in routing. The Zhongwei campus has a multi-year record of trial service, named workloads, operating buildings and continuing construction. Land, planning, power and energy documents add physical depth. This is not a paper network attached to an imaginary campus.

The gaps begin where a buyer’s service begins. No public cross-reference binds every AS10206 prefix, router or customer port to one building. No public table converts the campus’s rack milestones into a current inventory of commissioned, compatible and uncommitted capacity. Power assessments disclose substantial planned equipment but not the assigned, energised and tested customer power train. Cooling claims do not reveal failure headroom. Multiple buildings do not identify a recovery site independent of common Zhongwei dependencies.

The resulting evidence grades should remain asymmetric. Network evidence is medium: a live ASN and observed AS4837 relationship are clear, while physical diversity and building mapping are unresolved. Campus operating evidence is medium-high: multiple dated records support actual operation and expansion. Customer-usable capacity evidence is low because the public numbers do not reconcile design, delivery, power, commissioning, reservation and failure-condition availability.

Those grades are not a verdict on undisclosed operations. Operators often hold detailed diagrams, acceptance records and contracts outside public view. The point is that a customer cannot infer their contents from the public headlines. The diligence burden is to obtain service-specific proof and turn it into enforceable schedules.

The most dangerous shortcuts are simple equations: an ASN policy equals two physical routes; two feeds equal independent utility supply; a transformer rating equals IT capacity; a delivered rack equals a free rack; five buildings equal disaster recovery; a Zhongwei address equals complete data locality. Each equation drops the intervening dependencies that determine whether a workload stays available.

China Unicom Zhongwei Cloud can credibly be described as a live network identity associated with a real and expanding operating context in Zhongwei. What it cannot be described as, on public evidence alone, is a fully mapped pool in which every route, rack, megawatt and building is interchangeable. A buyer should purchase named capacity with named dependencies, insist on repair and recovery proof, and treat every campus total as context until it is reconciled to the exact service.