CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch sells hosted capacity that still depends on racks, transit and repair windows

Summary

• APNIC identifies AS63659 as CU-CDC-SH and describes it as CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch in China. The same APNIC public data ties 103.68.128.0/22 to the CU-CDC-SH netname and a China Unicom building address at No. 1033 Changning Road, Changning District, Shanghai.
• The branch ASN is not a current public routing proof. RIPEstat's AS overview for AS63659 showed announced: false; the announced-prefixes view returned no current prefixes; routing-status showed 0 IPv4 prefixes, 0 IPv6 prefixes and 0 observed neighbours; routing history placed AS63659's visible 103.68.128.0/22 origin in 2017-2018, with the last seen AS63659 origin in November 2018.
• The address block still matters because RIPEstat's prefix view for 103.68.128.0/22 showed the prefix announced through AS138421, holder CU-CN-AS - China Unicom, with 325 of 325 RIS peers seeing it at the query time. That supports a current China Unicom routed path, not a branch-specific self-operated customer service claim.
• China Unicom's official reports show a large cloud and data-centre business: 2025 data-centre revenue of RMB28.1 billion, more than 1.10 million standard cabinets, seven 100 MW-grade AIDC campuses, Unicom Cloud revenue growth, and first-half 2025 Unicom Cloud revenue of RMB37.6 billion. Those figures establish parent-scale infrastructure context, not the exact customer placement, rack count or restore path for the Shanghai branch entity.
• The evidence grade is Weak. The public record supports a real branch-linked number-resource footprint and a currently routed China Unicom prefix, but it does not prove current AS63659 operation, branch-level customer capacity, transit diversity, data placement or recovery performance.

The useful evidence starts with a split

The main fact about CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch is a split between registration evidence and current routing evidence. In APNIC's RDAP record for AS63659, the handle is AS63659, the name is CU-CDC-SH, the country is CN and the status is active. RIPEstat's whois view for AS63659 gives the same operating label and describes the resource as CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch. That is a meaningful identity signal: it is not a generic reference to "cloud" pasted into a marketing page.

The routing evidence is narrower. RIPEstat's AS overview showed AS63659 as not announced at the 2026-07-11 16:00 UTC query time. RIPEstat's announced-prefixes view returned an empty current prefix list for the recent observation window, and the routing-status view showed zero announced IPv4 space, zero announced IPv6 space and zero observed neighbours. A customer cannot convert those fields into a promise that this branch ASN is carrying a live hosted service today.

That does not make the branch irrelevant. APNIC's RDAP record for 103.68.128.0/22 identifies the netname CU-CDC-SH and gives the range as 103.68.128.0 through 103.68.131.255, status active, country CN. RIPEstat's whois data for 103.68.128.0/22 repeats the branch description and the China Unicom building address. Those records tell a buyer where to begin, but they do not show a complete cloud service.

The important change is that the same address block is visible now through a different AS. RIPEstat's prefix overview showed 103.68.128.0/22 announced by AS138421, holder CU-CN-AS - China Unicom. The routing-status view for the prefix showed the route visible to all 325 RIS IPv4 peers at the query time, with origin AS138421. The evidence therefore supports a current China Unicom routed address block associated with the branch record. It does not support a simple sentence that AS63659 itself is currently the customer-facing edge.

A dormant branch AS changes the procurement test

A dormant AS is not automatically a failed service. Large carriers often consolidate customer routes into a broader backbone AS, retire small origin ASNs, change route policy, or keep number resources in a regional or product account while traffic moves through a national network. But a dormant branch AS does change the test. The question is no longer "does AS63659 announce customer prefixes?" The question becomes "which China Unicom network, facility and contract now carry the hosted capacity that the branch name appears to represent?"

RIPEstat's routing history for AS63659 showed historical visibility for 103.68.128.0/22 and related more-specifics under origin AS63659, with the visible AS63659 origin ending in late 2018 for the aggregate. The current prefix view, by contrast, places 103.68.128.0/22 under AS138421. That history is useful because it prevents two common mistakes. The first mistake is to call the branch a mere shell because its own AS is not current. The second is to treat an old AS origin as current operating proof.

The customer should force the distinction into the contract. If a sales or support document still mentions the branch, the customer should ask whether its workload will use 103.68.128.0/22, some other China Unicom Cloud address pool, a private interconnect, a public cloud exchange path, or a customer-assigned block. If the answer is "China Unicom backbone," the customer needs the AS138421 service edge, not AS63659, included in monitoring and incident evidence. If the answer is "Shanghai branch," the customer needs to know which facility and operations team make that true.

The lack of a PeeringDB profile for AS63659 in the public API check reinforces the same point. PeeringDB absence is not a negative judgement; many carrier internal or regional ASNs do not maintain public PeeringDB records. It simply means the public interconnection surface does not expose exchange attachments, facilities, peering policy or looking-glass data for this branch ASN. A buyer must get that information directly rather than inferring it from a name.

The live path appears to be China Unicom's broader backbone

The current path evidence sits with AS138421. RIPEstat's AS overview for AS138421 identified the holder as CU-CN-AS - China Unicom and showed the AS as announced. The AS138421 announced-prefixes view returned hundreds of current IPv4 prefixes in the recent window. For 103.68.128.0/22 specifically, RIPEstat's looking-glass data showed international collector paths ending in AS138421 through upstream paths that include AS4837 in many observations. That is consistent with the address block being reachable as part of a large China Unicom routing system.

The practical consequence is that the branch's customer-facing dependency may be a regional commercial and support relationship whose packets ride a national backbone. That can be a strength. A national carrier backbone can provide scale, repair leverage, optical transport, security operations and multiple regional options that a small independent hosting provider cannot match. It can also hide local details. A customer may know the carrier brand but not the data hall, rack, route origin, local cross-connect, metro power dependency or support queue that actually affects the workload.

Public routing cannot answer whether the active prefix is used for cloud servers, management services, customer access, internal systems or other China Unicom use. It cannot show how much of the /22 is free, assigned, filtered, firewalled or tied to a particular product. It cannot say whether the Shanghai branch controls the change calendar or whether a national network operations center controls route policy. The route is a current operating signal, not a capacity certificate.

That is why the customer's monitoring plan should include both identities. AS63659 is the branch-linked number-resource identity. AS138421 is the current public origin for the branch-linked prefix. A route monitor that watches only AS63659 will miss the live route if current service remains under AS138421. A procurement review that watches only AS138421 may miss the branch-specific uncertainty around address allocation, support escalation and customer placement.

China Unicom's scale is real, but scale is not placement

China Unicom's official reporting shows the scale behind the parent system. The 2025 annual report says data-centre revenue reached RMB28.1 billion, up 8.5% year-on-year; standard cabinets exceeded 1.10 million; seven 100 MW-grade AIDC campuses had been built; cabinet utilisation exceeded 72%; intelligent computing scale reached 45 EFLOPS; and more than 9,000 kilometres were added to the "Eight Vertical and Eight Horizontal" backbone optical fibre cable network for computing hub interconnection. The same report says Unicom Cloud evolved toward AI cloud and includes cloud IDC, cloud resources, cloud platform, cloud service, cloud integration, cloud interconnection and cloud security in the Unicom Cloud revenue definition.

The 2025 interim report adds a mid-year view: first-half Unicom Cloud revenue reached RMB37.6 billion; IDC revenue reached RMB14.4 billion; IDC resource utilisation exceeded 70%; China Unicom provided intelligent networking services to more than 280 cloud service providers and connected with more than 400 data centres; and the company described 10,000-chip intelligent computing centres in Shanghai Lingang, Hohhot, Zhongwei and Sanjiangyuan. The 2024 annual report similarly reported Unicom Cloud revenue of RMB68.6 billion, IDC revenue of RMB25.9 billion and large-scale intelligent computing centres in Shanghai and other regions.

Those are strong parent-level infrastructure facts. They matter because they show that "cloud" in this case is not only a reseller label attached to a small website. The parent group is spending and reporting at carrier scale. Yet parent scale does not decide branch placement. The reports do not say that CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch has a specific number of racks available to public customers. They do not state that 103.68.128.0/22 is a customer server pool.

They do not publish recovery times for this branch name, nor do they map the branch to a named site, carrier entrance, backup region or workload migration path.

The buyer should therefore treat parent-scale evidence as context rather than proof. A large carrier can still sell a local product whose repair depends on one building, one remote-hands queue, one service desk, one network change owner or one data-export procedure. Conversely, a branch with a dormant AS may still be backed by a robust national platform. Public research cannot choose between those outcomes. The contract, architecture evidence and test results must do that work.

The Shanghai address is a clue, not a data-hall map

The branch-linked public records point to Shanghai. APNIC RDAP and RIPEstat whois list the China Unicom building at No. 1033 Changning Road, Changning District, Shanghai in the administrative and technical contact address fields for the AS and the 103.68.128.0/22 allocation. That is a real location clue. It does not mean customer servers are located at that address, and it does not mean the address is a data centre. It may be an office, registration point, operations contact, network administration site or facility-adjacent business address.

Shanghai still matters. The official reports identify Shanghai among China Unicom's large-scale intelligent computing deployments, and the 2025 interim report specifically names Shanghai Lingang in a list of 10,000-chip intelligent computing centres. If a customer is buying China-based hosted capacity because Shanghai locality, network reach or regulatory context matters, it should ask whether the production workload is in Shanghai, in a national computing hub, in another province, or in a shared cloud pool whose control plane and backups span regions.

The question is not academic. A Shanghai-labelled service can have several physical layers: a local sales branch, a Shanghai customer support channel, an address allocation registered to a Shanghai contact, a national backbone route, a data centre in Lingang or another district, a backup in another province, and a management or logging platform elsewhere. Each layer changes latency, jurisdiction, operational responsibility and recovery.

The buyer should request a placement matrix. The matrix should list production compute, storage, backup, logs, identity, billing records, customer support system, monitoring, remote administration and export locations. It should also state which of those locations are guaranteed, which are normal operating practice, and which may change without customer approval. Without that matrix, the Shanghai branch label is useful for discovery but limited public evidence for sovereignty or continuity assurance.

Racks turn a cloud service into a repair problem

The phrase "hosted capacity" hides the physical queue behind the service. A virtual machine or managed platform needs cabinets, power, cooling, routers, switches, optics, cables, disks, firmware, spares and people with access rights. The China Unicom reports show an enormous cabinet base at the group level, but the customer risk is local: which racks hold this workload, which power domains feed those racks, and how quickly can a qualified person act when hardware fails?

Installed capacity is not the same as usable capacity. Installed capacity is what exists before failure: rack space, routeable addresses, optical transport, compute nodes and storage arrays. Usable capacity is what remains after a power event, router fault, upstream change, cooling restriction, failed disk pool, maintenance window or security isolation. Recoverable capacity is what the provider can restore before the customer's business deadline. Public BGP can show a prefix; it cannot show any of those three numbers.

For CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch, the public evidence points to a national carrier environment rather than an isolated boutique host. That helps with supplier depth. But it also makes the responsibility boundary more complicated. If a customer enters through a branch contract, uses a national Unicom Cloud platform, receives public addresses from one pool and relies on a regional data centre, the repair owner may change by layer. The branch may handle the account. A national operations center may handle the route. A facility team may handle power. A cloud platform team may handle storage.

A field team may handle hardware replacement.

That division is not a flaw if it is visible. It becomes a failure path when the customer has only a single help-desk contact and no evidence of how the escalation tree works. The useful question is not whether China Unicom owns many cabinets. It is whether this customer's service can survive the loss of the specific rack, route, storage pool or operations queue on which it depends.

Transit diversity has to be proven under the current origin

Transit diversity cannot be inferred from a dormant branch AS. RIPEstat showed no current AS63659 neighbours, which means AS63659 is not exposing a current public neighbour map in that data. The active prefix path points to AS138421, so transit and reachability testing should focus on the AS138421 edge that carries 103.68.128.0/22. The customer should ask for the current origin policy, the upstream and peer arrangement, the route-filtering controls, the route-origin authorisation state and the tested failover path.

The route-origin state is not ideal as a standalone assurance. RIPEstat's RPKI validation check returned status unknown for AS138421 and 103.68.128.0/22, with no validating ROAs in that query. Unknown is not invalid, and it does not mean the route is hijacked. It means the public RPKI signal did not provide a positive origin-authorisation proof for that origin and prefix at the time checked. For customers that depend on strict route filtering by upstreams or peers, unknown origin status is a real point to clarify.

Routing hygiene is only one part of resilience. RFC 6811 explains route-origin validation; RFC 7454 describes operational practices for BGP; MANRS frames routing-security expectations for network operators. These documents are useful because they define the questions, not because they certify any one operator. A provider can follow good route-filtering practice and still have a local fibre cut, a congested backup path or a slow support escalation.

The customer should ask for a path failure demonstration. If the primary carrier path is lost, which route remains? If a China Unicom backbone segment is congested, where does customer traffic shift? If RPKI filtering changes upstream, what evidence proves the prefix will still be accepted? If the customer uses private connectivity, does the private path share a facility, router or power domain with the public internet path? Diversity is a test result, not a topology diagram.

Support labour is part of the infrastructure

Support is not a soft service layered on top of the infrastructure. It is the mechanism by which the infrastructure becomes repairable. A hosted service can have a valid route and a strong parent brand, yet still fail operationally if the customer cannot reach the right team, if the support team cannot see the relevant layer, or if an escalation requires a separate account owner who is unavailable during the incident.

The branch structure makes this especially important. CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch may be the visible contract or account label, while technical restoration may sit with Unicom Cloud platform teams, China Unicom backbone teams, a data-centre operations group and a regional customer-service team. The customer needs to know which team owns each symptom. A public route withdrawal, packet loss, console failure, storage snapshot failure, identity lockout, billing suspension and export delay may all require different owners.

The strongest support evidence is not a generic SLA line. It is a sample incident path. Who receives the first ticket? What qualifies for telephone escalation? How does the provider identify whether the incident is branch-specific, AS138421 routing, a cloud control plane, storage, power, security filtering or customer configuration? Can the status page operate if the main management console is down? Is there a direct route to the team that can change routes or restore storage, or must every request pass through account support?

Customers should also test language and locality. A Shanghai branch contact may be valuable for Chinese-language support, local business hours and domestic compliance conversations. But if the emergency team works at national level, the customer should know how handoff occurs. The relevant support promise is not "we have support." It is "the support chain can reach the physical or control-plane owner fast enough to protect the workload."

Billing, suspension and account state are failure paths

Cloud failures are not always mechanical. Billing, identity and account state can stop hosted capacity as surely as a damaged fibre. A customer may lose access because an invoice is disputed, a payment route fails, an admin leaves, a domain expires, a security review locks the account, or a termination process removes resources before data export is complete. Those risks are easy to miss when the conversation is framed only around racks and routes.

The public evidence does not disclose the branch's billing system or account controls. That means the buyer should ask directly. Which legal entity invoices the service? Is the Shanghai branch the contracting contact, the support contact or both? What happens if there is a mismatch between the account name, ICP-related documentation, security review documentation and technical tenant? Can a non-payment suspension affect backups or data exports? How long does the customer have to restore account standing before resources are deleted?

These questions are not hostile. They make the service more usable. A hosted provider that can explain suspension rules, administrative recovery, account ownership transfer and emergency export is safer for customers than one that treats those controls as office paperwork. In infrastructure, administrative state is operational state. A locked console during a network or storage incident can turn a manageable failure into a migration crisis.

The customer should request two written paths: an emergency operations path and an emergency commercial path. The operations path says who can restore or move service. The commercial path says who can prevent a billing or account state from blocking that restoration. Both paths should be tested before production dependency grows around the service.

Data locality is not solved by a Chinese address

The branch's China and Shanghai signals are relevant to data locality, but they do not solve it. The APNIC address and the branch description show a China-linked number-resource record. China Unicom's reports show national cloud and data-centre scale. Chinese regulatory sources, including the 2024 CAC provisions on cross-border data flows, the CAC data export security assessment measures, and the official English publication of the Personal Information Protection Law, show why placement, access and export paths matter. But none of those sources tells a specific customer where its data, backups, logs or support records will sit.

For a China-hosted workload, the customer should separate data residency, operational access and network path. Data residency asks where the primary and backup copies are stored. Operational access asks which teams and suppliers can reach the system, from which jurisdictions and under which controls. Network path asks how traffic reaches the service and whether the public route, private line or cloud interconnect exposes the application to dependencies the customer did not intend to accept.

The branch-linked prefix 103.68.128.0/22 being currently originated by AS138421 does not answer those questions. A prefix can be registered to a Shanghai branch contact and still route through a national backbone. A control plane can be domestic while some operational systems are centralised. A backup may be in another province for resilience. A log platform may be separate from production. Locality is a design and contract statement, not a deduction from a country code.

The customer should require a locality schedule that covers production, backup, logs, telemetry, customer tickets, billing records, support access and data export. The schedule should state when data can move, whether customer consent is required, how cross-region replication works, and how a customer can prove deletion or export after termination. Without that evidence, the label "Shanghai Branch" remains useful but incomplete.

Migration is the last honest resilience test

The final test of hosted capacity is whether the customer can leave without losing the business. That is true for a small host and for a national carrier cloud. A service that performs well during normal operation can still be a poor dependency if the customer cannot export data, rebuild configuration, move DNS, reclaim addresses, retrieve logs, or transfer support evidence when the provider relationship changes.

For this branch, the public evidence raises a specific migration question: what happens to workloads tied to a branch-linked resource that is currently routed through a broader China Unicom AS? If the customer receives public IPs from 103.68.128.0/22, can those addresses move with the workload? Usually provider-assigned addresses do not move outside the provider, so the customer needs a plan for DNS, certificate, allow-list, partner API and security-policy changes. If the service uses private addresses or private links, the customer needs equivalent cutover evidence.

Data export needs the same precision. Can the customer export all data without professional services? Does the export include metadata, identity settings, security rules, logs, snapshots and entity versions? Can exports be run while the service is degraded? How long are exports retained after termination? Is the export bandwidth capped? Who approves an emergency export if the usual account administrator is unavailable?

The best migration test is small but complete. Move one representative workload out of the service, restore it elsewhere, validate data integrity, update access controls, preserve audit logs and measure the elapsed time. If the provider cannot support that exercise before a crisis, it is unlikely to be easier during a crisis. Portability is not a contract appendix. It is the customer's practical escape path.

Who feels the failure

The direct customer of CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch may be an enterprise tenant, public-sector workload, application operator, reseller, systems integrator, local business or another network team. The downstream user may never know the branch name. They may only notice that an application is slow, a console is unreachable, a database cannot be restored, a payment portal is unavailable, or a partner allow-list no longer matches the service address.

The failure can propagate through several layers. A route failure can remove public reachability. A storage fault can corrupt or delay data recovery. A cloud control-plane fault can prevent scaling, snapshotting or firewall changes. A support escalation fault can lengthen the incident even when the technical repair is known. A billing lock can block export. A locality mismatch can create legal or customer-communication problems after the technical service is restored.

The evidence here supports a careful operating posture. It does not support panic. China Unicom is a major carrier with a large cloud and data-centre estate. The prefix associated with the branch record is visible under a current China Unicom origin. Those are meaningful positives. The weakness is not the absence of a parent platform; it is the absence of branch-level public detail about current customer placement, multi-site failover, route authorisation, support authority and data portability.

Customers should therefore treat the branch as a dependency to document, not as a name to accept or reject in isolation. The right outcome is a sharper service map: legal counterparty, branch role, active AS, address pools, facility locations, backup locations, support owners, route controls, RPKI status, exit path and tested recovery results. Once those are visible, the customer can decide whether the hosted capacity is worth the dependency.

How to test the service before relying on it

The first test is identity and address mapping. Ask the provider to state whether AS63659 is used for any current customer-facing service. Ask whether 103.68.128.0/22 is assigned to the product, and if so whether it is originated by AS138421 in normal operation. Compare the answer with APNIC RDAP for AS63659, APNIC RDAP for 103.68.128.0/22, RIPEstat AS63659 routing status and RIPEstat 103.68.128.0/22 routing status. Any mismatch may be harmless, but it should be explained before production.

The second test is placement. Request the production site, recovery site, backup location, control-plane location and support location. If Shanghai locality is part of the purchase, ask which part of the service is actually in Shanghai and whether Shanghai Lingang or another site is involved. The provider does not need to disclose sensitive floor plans to answer the operational question. It can state region, facility type, redundancy design, power domain and customer-impacting change process at an appropriate level.

The third test is route and recovery. Monitor the prefix from multiple vantage points, watch the AS origin, check RPKI status, test private connectivity if used, and ask for a route-failover exercise. Then test workload recovery: restore from backup, move traffic, confirm logs, rebuild access controls and measure time. The exercise should include both a planned maintenance scenario and an unplanned failure scenario.

The fourth test is exit. Run a complete export, move a small workload elsewhere and confirm that the customer can operate without hidden provider assistance. Include DNS, IP address changes, certificates, partner allow-lists, compliance evidence and retained logs. A provider that can pass this test is not weakened by it. It demonstrates that the customer is buying service rather than captivity.

What would upgrade the evidence

The evidence would become materially stronger if the provider published or shared a current service map for the branch-linked resources. The most useful document would connect the branch name, the contracting entity, AS63659, 103.68.128.0/22, AS138421, the production region, the recovery region, the support owner and the customer product in one place. It would not need to expose sensitive rack coordinates or security controls. It would need to say which public facts are still operationally relevant and which are only historical.

A second upgrade would be live operational evidence. That could include recent route-monitoring samples for the customer address pool, a current RPKI plan or explanation for the unknown origin state, maintenance notices that name the affected layer, and a failover exercise showing what happens when the normal path, site or support channel is removed. A provider's internal confidence is useful, but a customer needs evidence it can keep and interpret during an incident.

A third upgrade would be portability evidence. The provider could show a complete export, a documented return-of-data process, account recovery contacts, suspension safeguards and deletion proof after termination. Those items would not make the public route table more impressive. They would make the hosted service less brittle. For this branch, that is the core issue: not whether China Unicom has infrastructure scale, but whether this customer-facing dependency is mapped, recoverable and movable enough to trust.

Evidence grade

The evidence grade is Weak. That grade is not a statement that the company is weak, and it is not a statement that China Unicom lacks cloud or data-centre scale. It is a statement about what public evidence can support for this exact branch-facing infrastructure dependency.

The positive evidence is concrete. APNIC and RIPEstat tie AS63659 and 103.68.128.0/22 to CU-CDC-SH and CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch. The branch-linked IPv4 block is active in registry data. RIPEstat shows 103.68.128.0/22 currently announced by AS138421, China Unicom, with full RIS visibility at the query time. China Unicom official reports establish a large national cloud, IDC and intelligent-computing estate, including reported data-centre revenue, cabinet scale, AIDC campuses, Shanghai intelligent-computing references and Unicom Cloud revenue.

The limiting evidence is just as important. AS63659 itself was not currently announced in RIPEstat, had no current prefixes in the announced-prefixes view and had no observed neighbours. The active route for the branch-linked /22 used AS138421, not AS63659. The RPKI check for 103.68.128.0/22 and AS138421 returned unknown. The public records reviewed here did not publish branch-level customer product pages, facility contracts, rack counts, power redundancy, support escalation, tested recovery objectives, customer data placement or export terms.

That weakness should shape the buyer's verification rather than end the assessment. The first boundary is legal: which China Unicom entity signs, invoices and can approve emergency action. The second is technical: which AS, prefix, cloud region, storage platform and control plane carry the workload today. The third is operational: which team can change routes, restore storage, enter a site, override a console lock or authorize export when the normal account path is unavailable.

The fourth is contractual: what happens to data, logs, addresses, certificates, support records and billing status when the customer leaves or when a service is suspended. A large national platform can answer those questions; the public record just does not answer them for this branch-level dependency.

The conclusion is narrow: CHINA UNICOM CLOUD DATA COMPANY LIMITED Shanghai Branch is a real branch-linked number-resource identity inside a very large China Unicom cloud and data-centre context, but public evidence does not prove the current branch-specific hosted-capacity surface. A customer should proceed by verifying the live AS, address pool, facility placement, route controls, support owner, recovery drill and exit path before treating the service as resilient.