The Province Is the Product: CTYun's State Cloud Operating Compact

Summary

• CTYun is operated via Tianyi Cloud Technology Co., Ltd., the 2021 successor to the cloud computing branch of China Telecom Corporation Limited; the directory labelCHINATELECOM-Ctcloudis an ASN-style network name, not the legal name of the company.
• Its defensible advantage is the coupling of cloud capacity with provincial installations and the China Telecom network, but a national footprint does not in itself prove availability zone independence, data location or the recovery path of a particular workload.
• CTYun's public cloud, private deployments, operator links, developer APIs and the Xirang AI marketplace create a broad operating surface whose economics go far beyond a virtual machine price.
• Buyers must include locality, failure domains, support responsibility, API portability, product retirement and verified export in the acceptance test; otherwise, the "state cloud" compact can turn continuity policy into concentrated single-vendor dependency.

The most revealing map is a calendar

The most revealing map of CTYun infrastructure is not a diagram. It is a calendar.

On 3 February 2026, CTYun informed its customers that its integrated heterogeneous compute product, Yunxiao Intelligent Computing, would stop accepting new purchases and renewals from 25 March. Existing customers could only continue until 25 August and were asked to back up their data in advance. Theretirement noticedid not signal a failure. It recorded something more ordinary and, for procurement, just as important: a cloud service can remain technically useful while its commercial clock runs out.

At the same time, CTYun's broader intelligent compute offering was expanding. ItsXirang product surfacepresents compute interconnection, training and inference, public capacity, model services and application hosting as a single system. An associatedXirang solution pageexplains that the previous Yunxiao, Huiju and Xirang components are integrated into a common public and private cloud architecture. The retirement is therefore proof of portfolio convergence, not proof that China Telecom is withdrawing from AI. Yet a customer running scripts, images, schedulers or operational procedures against the retired component still has a migration to perform.

This tension is the right entry point for CTYun. Its marketing scale is territorial: four major cloud bases, four major economic regions, pools spread across 31 province-level zones, hundreds of datacenters and a growing intelligent compute fabric. Its customer experience is specific: one account, one region, one availability zone, one quota, one image, one API version, one provincial service team, one invoice and finally one end date. "State cloud" is the strategic framework. A workload lives in the implementation.

The commissioning question is therefore not whether China Telecom has a large cloud. It clearly operates one. China Telecom Corporation Limited reportedRMB 120.7 billion in China Telecom cloud revenue in 2025, while attributing second place in China's public cloud infrastructure as a service and a top-three position in infrastructure and platform services according to IDC tracking at Q3 2025. These are group-reported figures and rankings, not a separate audited profit and loss account for Tianyi Cloud Technology Co., Ltd. They establish strategic weight, not unit economics.

The harder question is what kind of operating market this weight creates. CTYun bundles compute, storage, network reach, local facilities, security controls, support and public procurement under the China Telecom umbrella. This can reduce the number of organisational seams a customer must manage. It can also place more failure and exit paths behind the same business relationship. The thesis of this article is that CTYun should be bought as an operating compact, not as a list of cloud products. The compact is only valuable when its geography, responsibility and reversibility are made testable.

Prove the name first

The directory label must be handled carefully.CHINATELECOM-Ctcloudis not the name printed on CTYun's current customer contract, and it should not be promoted to a legal company through typography.

Public routing records identify the label with autonomous system 58519. TheAS58519 pageon Cloudflare Radar showsCHINATELECOM-Ctcloudand the alternative descriptionCHINATELECOM-CTCLOUD Cloud Computing Corporation. Thecurrent record on bgp.tools, which exposes the underlying APNIC-style WHOIS text, is more revealing. It lists the AS name asCHINATELECOM-Ctcloud, describes "Cloud Computing Corporation" and states that the network belongs to the cloud computing branch of China Telecom Corporation Limited. It also shows China Telecom Backbone, AS4134, as an upstream provider. These records prove a network and operator association. They do not prove that "CHINATELECOM-Ctcloud" is, or ever was, the registered full English name of a company.

The corporate bridge comes from China Telecom itself. A 2022 group report on reform states thatTianyi Cloud Technology Co., Ltd. was established on 1 July 2021with a registered capital of RMB 4 billion as a third-level company under China Telecommunications Corporation. It says the new company succeeded the cloud computing branch established in 2012, transforming the branch into a subsidiary. The article describes the company as the group's concentrated vehicle for public, private, dedicated, hybrid and edge cloud services.

Current contractual language completes the bridge. TheCTYun Usage Agreement, effective from 20 June 2025, states that the site ctyun.cn is created and operated by Tianyi Cloud Technology Co., Ltd. It also warns that some services may be provided by this company or its subsidiaries and that the actual service provider may sign the product contract and issue the invoice. CTYun's developer trail points to the same operator: the publicMaven artifact groupcn.ctyuncontains 2026 versions of the Java SDK whose copyright line uses the English rendering "China Telecom Cloud Technology Co., Ltd." and the Chinese legal name 天翼云科技有限公司.

The evidence supports a limited conclusion. AS58519 is an honest network/operator link for the directory line. The former subsidiary description in the routing record connects to the branch-to-subsidiary reform, and the current legal and developer surfaces connect CTYun to Tianyi Cloud Technology Co., Ltd. But the public sources reviewed do not show an APNIC transfer instrument, a current ASN resource-holding certificate or a specific customer purchase order tying each advertised service to that one legal entity. This article therefore concerns the CTYun/China Telecom Cloud Technology operating surface.

It does not rename the directory entity, substitute China Telecom Corporation Limited as the subject, or treat China Telecom Global as the same contracting party.

This distinction has commercial importance. "China Telecom" can refer to the state group, the listed operating company, a provincial subsidiary, a digital services subsidiary, Tianyi Cloud Technology Co., Ltd. or an overseas subsidiary. A logo does not identify the party that owes a service credit, holds customer data, operates a facility or must assist with exit. Any serious procurement should ask four identity questions before technical evaluation begins: who signs, who invoices, who operates the selected resource pool and who carries the transition obligation. The answer may legitimately involve multiple China Telecom entities.

It must not remain implicit.

The province is part of the product

CTYun's national geography is not a decorative coverage map. It is part of the product design.

The company'sinfrastructure pagedescribes a4+4+31+Xlayout. Four major bases are located in Inner Mongolia, Guizhou, Gansu and Ningxia. Four priority regions cover Beijing-Tianjin-Hebei, the Yangtze River Delta, the Guangdong-Hong Kong-Macao area and the Shaanxi-Sichuan-Chongqing area. Central pools extend into 31 province-level zones, while the "X" layer includes lower-level private cloud and content delivery deployments. The same page claims more than 700 datacenters and lists provincial counts. These are first-party fleet claims, not an independent inventory, and "datacenter" is not synonymous with a generally available CTYun region or multi-zone product location.

The map nonetheless explains the operational proposition. A national ministry, a provincial public service, a hospital network or a manufacturer with domestic facilities can value three things at once: compute near users, connectivity via an incumbent operator and a national administrative chain that can provide local implementation. A western resource base can provide land, power and bulk capacity. An eastern or provincial pool can place latency-sensitive services closer to demand. Private and edge deployments can bring selected functions further down the hierarchy.

The buyer must translate this hierarchy into a workload placement record. CTYun'savailability zone guidelinesdefine a zone as a geographically distinct area within a region with independent power and network, typically a separate computer room. They state that zones within a region communicate via an internal network, that a zone failure should not affect another, and that a virtual machine already purchased cannot be moved to another zone. They also note that some regions may expose only one zone.

These details avoid a common category error. Provincial presence is not the same as zone redundancy. A province may contain many facilities while a product is sold in a logical region or single availability zone. Two virtual machines are not resilient simply because their labels differ. Conversely, a multi-zone design can improve facility independence while retaining shared dependencies in identity, control plane, backbone, billing, DNS, support or a regional database service.

The procurement artefact should therefore name the selected region and zones, the physical and logical independence that CTYun guarantees, the services that are truly multi-zone, the control-plane dependencies that remain shared and the recovery region that receives copies. "Hosted in China" is too broad. "Hosted in province A" is still incomplete. The useful statement is a service-by-service placement and replication matrix that can be reconciled against the console, the invoice and the recovery test.

One cloud, multiple operational perimeters

CTYun's operating surface has at least four perimeters, and confusing them creates false assurance.

The first is the national public cloud site of Tianyi Cloud Technology Co., Ltd. and its provincial subsidiaries. The current usage agreement makes this perimeter visible through account creation, product orders and service delivery at the subsidiary level. The second is the private, dedicated and hybrid deployment domain described in China Telecom's group report. Here, equipment or software may reside in a customer or dedicated facility even when CTYun provides the stack and operations. The third is the Xirang AI compute federation, which can integrate owned and accessed capacity across providers, regions and accelerator architectures.

The fourth is China Telecom's international network and its overseas cloud envelope.

This last perimeter must not be merged into CTYun. China Telecom Asia-Pacific'scloud infrastructure pagepromotes compute, storage and networking inside and outside China, private connections to AWS, Azure, Google Cloud, Alibaba Cloud and Tencent Cloud, over 40 cloud or interconnection metro nodes and a multilingual operations centre. This is useful evidence of the broader group's cloud-network reach. Its footer and organisational context belong to an overseas China Telecom operation, not proof that Tianyi Cloud Technology Co., Ltd. contracts or operates every international node.

The limit becomes important when a multinational designs "one China Telecom cloud". Domestic data may reside in CTYun. A dedicated circuit may be sold by a provincial telecom subsidiary. International transit or cloud exchange may involve China Telecom Global or a regional subsidiary. A managed security appliance may have another provider. The customer sees one architectural drawing; the contracts may contain multiple service providers, legal regimes, support queues and incident clocks.

This does not make the integrated proposition illusory. It makes responsibility mapping essential. The value of an operator cloud is precisely that network and compute can be designed together. The required control in return is a responsibility matrix that names the operator for each layer, the escalation owner across layers and the party obliged to coordinate a cross-border incident. "Single contractual point of failure" is not a contract term. A signed cross-service operating model is.

A customer operates a chain

A CTYun customer does not simply rent a server. It operates a chain whose links differ by workload but typically include identity, placement, network, compute, storage, security, observability, support and finance.

The customer first creates and verifies an account, establishes organisational users and obtains credentials. It then selects a region and zone, creates a virtual private cloud and subnets, defines routes and security groups, chooses images and instance types, attaches disks or object storage, assigns public or private connectivity and configures monitoring. CTYun'sElastic Cloud Server pagepresents this as rapid provisioning: instances can be created in batches within minutes, resized, combined with load balancing and connected to multiple storage classes. It advertises general-purpose, local-disk, national-technology and GPU instances, as well as CTyunOS, KylinOS, openEuler and third-party images.

The product page is a commercial description, not an architecture guarantee. CTYun's more detailedECS product documentationshows the two main management paths: a web console and HTTPS APIs. A user integrating public cloud instances into another system is invited to use the API and, for some needs, to contact a customer manager. The separateOpenAPI portaloffers API documentation, debugging, SDKs, examples, call statistics and diagnostics. These developer surfaces are important because automation is where a cloud stops being interchangeable. Resource identifiers, error semantics, signing logic, quotas, eventual consistency behaviour and region endpoints become embedded in deployment pipelines.

The chain continues after provisioning. A production service requires approved images, patching, secret rotation, backups, log export, alert routing, capacity thresholds and restore drills. A public-sector system may also require classification, graduated cybersecurity controls, cryptographic assessments, national-technology compatibility and local support. An AI workload adds data staging, accelerator allocation, distributed training, checkpointing, model registry, inference endpoints and usage metering. A multi-cloud deployment adds private circuits and routing policy.

CTYun provides products for many of these links, but it does not assume the customer's application responsibility. Its publishedECS limitationsstate that physical host migration may restart or shut down a virtual machine and recommend application auto-start, cluster or active-passive deployment, backups and monitoring. Software licences tied to hardware may fail after migration changes machine information. These are unusually useful disclosures because they locate responsibility: infrastructure recovery may restart the instance, while service recovery still depends on the customer's application design.

The correct unit of analysis is therefore the service chain, not the instance. A low virtual machine price can coexist with expensive dedicated connectivity, support, commercial software, backup retention, security controls, data egress and scarce accelerator capacity. A strong SLA for one link can coexist with an untested recovery path for the entire application. Procurement must model and test the chain that produces a public outcome.

The control plane is the dependency

Infrastructure portability is often discussed at the Linux and container level. That is the easy layer. The harder dependency is the control plane.

A conventional application can run on a CTYun virtual machine with a familiar operating system. Entity data can use an S3-like interface. Kubernetes can package services. These choices reduce the amount of application code tied to a provider. They do not recreate the surrounding state: accounts, sub-accounts, access policies, keys, network entities, private endpoints, security groups, load balancers, images, snapshots, alarms, logging rules, quotas, billing tags and service-specific database parameters.

CTYun's public Java SDK trail illustrates the expansion. Thecn.ctyungroup includes separate artefacts for services such as virtual private cloud and elastic scaling. An application team that imports these clients gains typed access and faster delivery. It also accepts the SDK's release cadence, authentication method, endpoint taxonomy and error model. The right question is not whether using an SDK is lock-in. It is whether the customer has isolated the provider calls, pinned and tested versions, retained raw API documentation and built a second path for inventory and export.

Storage shows both portability and its limits. CTYun'sobject storage documentationstates that the service supports the S3 protocol, with some nodes also supporting file or HDFS semantics. Itscloud migration servicestates that it can move entities between AWS S3, Alibaba OSS, Huawei OBS, Tencent COS, CTYun ZOS and OOS, and other standard S3 services, then validate the migration. This is significant portability evidence.

The constraints matter more than the logo. CTYun'smigration limits pagestates that the default process only moves the latest version of a multi-version entity and does not migrate version history. One task manages one bucket; concurrency and daily task creation are capped per region; failure lists are limited; and the documented path rejects certain characters and metadata conditions. An export plan that tests only a thousand current entities may succeed while losing legal holds, historical versions, retention semantics, tags, entity ownership, checksums or an application's expected order.

Databases deepen the dependency. CTYun'sData Transmission Serviceadvertises full plus incremental replication, breakpoint continuation, row and field comparison, and encrypted public network transfer for supported database combinations. This is a practical entry and continuity tool. The public workflow examples are primarily migrations to CTYun, between CTYun databases or from self-managed databases hosted on CTYun. A buyer must not infer a symmetrical, zero-downtime export to any substitute. The exit proof must use the actual source engine, extensions, character sets, stored procedures, change volume and target.

The control plane is where locality also becomes operational. Region identifiers appear in scripts. Key services bind encryption and decryption to a provider context. Logs and monitors determine what operators can see. Private DNS and network policy determine what can communicate. To leave, the customer must reproduce not only the data and compute but also the rules that make them safe and observable.

AI transforms capacity into market

Xirang changes CTYun's economic unit. A traditional operator sells a circuit; a traditional cloud sells metered resources; an AI compute platform increasingly sells access to a planned heterogeneous production system.

China Telecom's 2025 annual results describe an intelligent cloud stack built around Xirang. The company stated 91 exaflops of owned and accessed intelligent compute capacity, a combination that must not be read as 91 exaflops of a single accelerator, single precision or single availability class. It stated RMB 12.3 billion in "intelligent revenue", defined as AI and smart computing services provided to customers. It also described general, intelligent, supercomputing and quantum capacity, a high-performance cloud network, unified AI storage and a "Triless" platform intended to decouple resources, frameworks and tools.

CTYun's currentXirang documentationturns the strategy into five public product families: public compute, training and inference, token services, application hosting and research assistance. The product page states that the platform can schedule across providers, regions and architectures, manage GPU and NPU servers as containerised capacity, provide dedicated clusters and combine public cloud rental with third-party capacity. Its strongest promise is abstraction: a customer requests a workload outcome while the platform matches resources underneath.

Abstraction is economically valuable when accelerator supply is fragmented. It can increase utilisation, reduce the need to build a cluster and allow a workload to reach different devices. It also moves the due diligence problem upward. A buyer needs to know what "capacity" means for the job: accelerator model, memory, interconnect, storage throughput, topology, framework image, precision, queue policy, preemption, tenancy, failure rate and checkpoint behaviour. An exaflop aggregate cannot answer these questions.

The platform's first-party reliability claims are specific enough to be tested. The Xirang page states that it supports Ascend and Nvidia routes, checkpoint continuation with a 15-minute recovery target, one-minute fault detection, five-minute localisation and ten-minute recovery in supported training scenarios. These are company claims, not a public benchmark or universal SLA. A procurement trial should inject a worker failure, storage slowdown, network partition and exhausted quota into the intended framework and model. Recovery must be measured in terms of useful training progress, not when a replacement node becomes visible.

The economic model also becomes multi-dimensional. Public compute can be rented on-demand. Dedicated clusters trade flexibility for isolation and capacity certainty. Training platforms add orchestration. Token services meter inference. Model adaptation and private appliances add services and hardware. Network and storage consumption continue while accelerators wait or checkpoints move. The economically relevant denominator is not the card's hourly price. For training, it is the cost per accepted run including failed and repeated work.

For inference, it is the cost per useful output at the required latency and quality, including reserved capacity, network, guardrails and idle headroom.

The Yunxiao retirement demonstrates another AI-specific risk. Rapid platform consolidation can improve the strategic stack while shortening a named product surface's life. Customers need contractual treatment of image formats, checkpoints, model artefacts, APIs and replacement capacity when a service is merged or retired. "Triless" is an architectural aspiration to make resources, frameworks and tools less relevant to users. It does not by itself make a customer's operational state portable.

Locality must be proven

CTYun's national footprint can help customers meet data localisation and sovereignty requirements. It cannot, by itself, decide what the law requires or prove where each copy travels.

China's Personal Information Protection Law is not a universal command that every byte stays in China. Article 40 of theofficial English text of the PIPLrequires critical information infrastructure operators and personal information processors that reach the prescribed threshold to store in China personal information collected and generated in China. When an overseas transfer is truly necessary, a security assessment may be required, subject to subsequent rules and exceptions. The law's scope, thresholds and transfer paths must be assessed for the customer and dataset; a cloud region selector is not legal advice.

Government data carries an additional operational duty. Article 40 of theChinese Data Security Lawprovides that a state organ that entrusts another party to construct or maintain an e-government system, or store or process government data, must use strict approval procedures and supervise the security obligations of the entrusted party. This turns "local cloud" from a static locality claim into an accountability process.

A useful locality record tracks the data lifecycle. It names the entry system, primary database, replicas, backups, snapshots, entity versions, logs, monitoring telemetry, support dumps, security scans, content delivery caches, disaster recovery copies and model training datasets. It states where each is stored, who can access it, whether support access crosses an organisational or territorial boundary, what keys protect it and what happens during repair. It also records deletion and retention.

CTYun's own privacy language shows why perimeters must be separated. Itsprivacy policycovers information that the platform collects for accounts and application functions and states that third-party marketplace services may have their own processing rules. It expressly distinguishes customer data uploaded or processed by the customer, for which the customer must establish a legal basis. This is normal cloud allocation, but it means that a privacy policy is not a data processing schedule for every workload.

Public cloud, private cloud and hybrid designs produce different locality evidence. A dedicated stack in a named government facility may offer strong physical placement but still call a central identity, update or support service. Public cloud data may remain in a selected national region while metadata is aggregated elsewhere. Xirang may schedule over heterogeneous accessed resources, so a customer with strict placement needs must constrain the eligible pool and verify resulting placement. "Resource-irrelevant" is useful for a flexible workload and unacceptable for a workload where resource and location are legally material.

The procurement control is positive proof. Demand a data flow diagram, a list of sub-processors and affiliates, a service-by-region inventory, backup destinations, support access process, encryption key location and a deletion certificate. Then reconcile these documents against logs and a recovery exercise. Sovereignty is not just the right to keep data somewhere. It is the ability to demonstrate where data, control and recovery authority actually reside.

Procurement writes the architecture

Public procurement records reveal CTYun more clearly than general market claims because they show what a customer makes the provider commit to.

In January 2024, Tianyi Cloud Technology Co., Ltd. won acloud service procurement for a central government information system. The award notice names the legal provider and its Beijing address, closing the identity loop independently of the brand site. More importantly, it lists the evaluation surface: availability zones, Internet protocols, platform openness, compliance, data security, price change constraints, latency, SLA breach compensation, data destruction, migration and confidentiality. The configuration included 70 virtual servers of various sizes, databases, Kubernetes, messaging and a set of cloud security policies intended to support graduated protection requirements.

This is not proof that every CTYun customer receives these terms or that every control worked effectively. It is proof that a sophisticated public buyer did not purchase "cloud" as a single line item. It decomposed the service into architecture, security, continuity, migration and price commitments. The notice also makes visible a feature of state-cloud economics: technical openness and exit can be procurement requirements even when national control and tight operator integration are priorities.

Other awards show that the competitive market is neither a simple brand ranking nor a guaranteed China Telecom franchise. Hunan provincial government cloud procurement for 2025-2027divided the work into four lotsand evaluated China Telecom's digital affiliate alongside China Mobile, China Unicom, Huawei Cloud, Inspur Cloud, Unis Cloud and China Electronics. Different providers won different lots. Scores and prices did not move in lockstep, and the rules prevented one bidder from taking all lots.

A Kunming government cloud awardshows the local operational layer. A consortium led by China Telecom's Yunnan branch won a cloud lot. The requirements called for facilities in Kunming, support for multiple CPU architectures, compliance with cloud security assessment, graduated protection and cryptographic requirements, monthly service reports, an emergency drill and on-site response within two hours. This is not necessarily a Tianyi Cloud Technology Co., Ltd. contract. It is evidence of China Telecom's broader delivery model and what public-sector continuity can demand.

The implication is twofold. First, procurement can turn a group advantage — network, local subsidiary, datacenter, integrator and cloud — into a single accountable service. Second, unless responsibilities are named, the same group structure can obscure who owns a failure. The tender should bind the consortium and affiliates into a single incident process, single evidence record and single exit plan while maintaining legal accountability per service.

Price follows the graph

CTYun publishes enough pricing structure to show why a displayed compute rate is a poor measure of total cost.

Thepricing centredistinguishes on-demand usage from annual or monthly commitments. On-demand capacity is positioned as flexible consumption without initial resource commitment; longer terms reserve capacity and offer discounts. The live ECS page shows monthly price examples per instance specification, but the displayed figure is not a universal quote. Region, CPU, operating system, disk, bandwidth, public address, duration, promotion, tax and negotiated public-sector conditions can change the outcome.

The bill expands as the service graph expands. Persistent disks continue after a compute instance stops. Snapshots and backups add stored capacity and requests. Object storage may charge for capacity, operations and transfer. Public bandwidth, dedicated lines, load balancers, NAT, security services, logging and support create separate meters. CTYun'sobject storage request fee documentationstates that console actions count as requests and that GET, PUT and DELETE classes may be billed. A migration may incur read requests and outgoing traffic at the source, write requests at the destination and a double storage period.

AI makes the graph more sensitive. A cheap accelerator that waits for data or repeatedly loses a training run can cost more per accepted checkpoint than a more expensive, better-connected cluster. A dedicated allocation may seem expensive by the hour and cheap when queue time threatens a public launch. Token pricing can shift spending from infrastructure teams to application teams while storage, retrieval, moderation and network costs remain elsewhere.

Operator integration can reduce some costs. A China Telecom customer may simplify procurement or get a better path between offices, datacenters and CTYun. Local support may reduce coordination time. But integrated pricing can also make unbundling difficult: the comparison is no longer a CTYun VM against another VM, but CTYun cloud plus circuit plus support plus compliance package against several replacement architectures.

The procurement model should therefore calculate three scenarios over the contract term: steady state, failure and exit. Steady state includes committed and variable consumption plus people. Failure includes idle capacity, replay, emergency support and service loss. Exit includes dual running, extraction, egress, conversion, validation and retained records. A discount is only valuable after pricing all three graphs.

Support changes the product

Support is not simply a phone number at CTYun. It changes the operating model.

The publicsupport plans pagedescribes light, enterprise and professional tiers with different technical staff, protected event services, account coverage and proactive reviews. Published plan details include 24/7 ticket management, a ten-minute response target for urgent tickets and thirty minutes for ordinary tickets, while human online chat hours are more restricted than the automated channel. Professional customers can get more tailored technical experts and operational routines. CTYun separately marketsexpert servicesfor planning, migration, implementation, operations and model adaptation.

These are offer descriptions, not proof of achieved resolution time. Response is also not restoration. A ten-minute acknowledgement can coexist with a long dependency diagnosis. The buyer should define severity from the public service perspective, not the provider's product component. It should distinguish response, qualified engineer engagement, workaround, restoration, root cause report and permanent fix.

Support identity matters in the operator cloud model. A circuit incident may start with a provincial telecom team; a virtual network incident with CTYun; a managed appliance with a partner; and an international path with another subsidiary. The contract should prevent each queue from closing its ticket because its own component looks healthy. For critical public services, a named incident commander and an escalation path between entities are more valuable than a collection of hotline entitlements.

Implementation support can also become a switching cost. Provider engineers accumulate knowledge about topology, exceptions and local approvals. This knowledge should be converted into customer-owned diagrams, infrastructure definitions, runbooks, contact maps and tested recovery procedures. Otherwise, premium support solves today's problem by increasing tomorrow's dependency.

Availability is assembled

CTYun advertises strong component availability. The application must still assemble it.

The ECS product page claims 99.975% availability for a single instance and 99.995% for multiple instances across availability zones. The page does not, by itself, define the metric, exclusions or credits. A separateelastic scaling SLAillustrates why legal text matters: it promises 99.95% for that service, measured on a monthly cycle, excludes interruptions below five continuous minutes and deducts from downtime notifiable maintenance, customer equipment, customer applications, credential failures, force majeure and other conditions. Other products have their own terms.

These figures cannot be added into an application SLA. A service may depend on identity, API, scaling, virtual network, load balancer, database, object storage, DNS and China Telecom access. Correlated failure matters more than the best individual percentage. So does the distinction between data plane and management plane. Existing workloads may continue while the console and API cannot create replacements; this may become a failure only when a worker fails or traffic grows.

CTYun's technical documentation provides concrete failure modes. A physical host failure may trigger cold migration and virtual machine restart. Theautomatic recovery guidestates that CPU and memory state may be lost when damaged equipment cannot support live migration. Its availability zone guidelines state that a purchased instance cannot simply be moved to another zone. Its current bulletin board publishes maintenance, endpoint changes, node lifecycle changes and product upgrades. This is evidence of an operational process, not a complete public incident history.

The public archives reviewed for this article did not provide a consolidated, machine-readable CTYun status history with incident start, affected services and regions, updates, restoration, root cause and corrective actions. This absence does not prove a poor incident record; it limits independent measurement. A customer should request incident and maintenance history for the exact regions and products purchased, including control-plane events and near-misses.

The test should then exercise failure. Shut down an instance without notice. Deprive a zone. Revoke a key. Fill a quota. Slow object storage. Break the private circuit. Fail the active database. Restore to the recovery region with people who did not build the system. Measure time to detect, decide, restore and reconcile. Compare the result against the public service recovery objective and the contract. Availability only exists at the point where architecture, operations and evidence meet.

Security claims have scope

CTYun's security surface is broad, but a certification label must be attached to the service and scope it actually covers.

The company'strust centreclaims more than 15 industry-specific trusted cloud certifications and more than 20 trusted cloud best-practice cases. Its about page more broadly references ISO, SOC, cybersecurity review, graduated protection and trusted cloud accreditations. These are company claims until a buyer sees the current certificate, issuer, entity name, covered locations, services, audit period, exceptions and transition letter.

There is a relevant external confirmation, but it is limited. In June 2025, China's Network Security and Market Regulation Certification Centre reported thatCTYun's multi-cloud management system passed a cloud service security assessment, using its dedicated government cloud and financial services cloud as validation platforms. This supports a particular assessed platform and validation scope. It does not automatically certify every CTYun region, Xirang capacity partner, marketplace application or customer configuration.

CTYun provides useful controls. ItsKey Management Servicedescribes hardware security module protection, lifecycle management, encryption and signing, national cryptographic certification and integrations with disks, object storage, file storage and databases. The entity service supports IAM, access keys, temporary credentials and pre-signed URLs. Yet the customer still decides key ownership, administrator separation, log retention, public exposure and recovery.

A June 2026object storage security noticeis instructive. CTYun began blocking new public-write policies in public pools, while leaving existing public-write configurations in place and urging customers to inspect and remove them. This is a sensible platform hardening measure. It also reveals shared responsibility: a safer default did not automatically fix every existing bucket, because that could break customer workloads.

Security procurement should therefore demand evidence by layers. Platform evidence covers facilities, hypervisor, control plane and operator processes. Service evidence covers the database, storage, AI or network product purchased. Configuration evidence covers the customer tenant. Supply chain evidence covers images, SDKs, hardware, models and marketplace components. Incident evidence covers detection, notification and remediation. One-layer badge cannot answer for the others.

Exit begins before entry

The best time to design a CTYun exit is before the first production order, when every dependency is still optional.

Minimal exit is not account cancellation. CTYun'saccount closure guidedescribes a 48-hour closure period followed by a 90-day retention period, after which the account is automatically cancelled; it also allows immediate cancellation during retention and warns that account data is then deleted. Resource, financial and order checks must succeed first. This process is an administrative endpoint, not a migration plan.

A production exit has six inventories. Data inventory covers databases, entities, file systems, disks, snapshots, backups, logs, queues, model artefacts and historical versions. Compute inventory covers images, instance assumptions, accelerators and hardware-bound licences. Control inventory covers identities, policies, keys, networks, load balancers, DNS, monitors and quotas. Software inventory covers CTYun SDKs, managed service APIs and proprietary database features. Evidence inventory covers audit logs, approvals, tickets and records that must survive the tenant.

Commercial inventory covers commitments, outstanding fees, circuit terms, support and deletion certificates.

Portability varies by layer. S3 compatibility is useful, but CTYun's own migration limitations show that version history and metadata require special handling. Virtual machine images can move in principle, but drivers, licences and boot configuration may fail. A managed database can export data while extensions, users, jobs, replication slots and performance behaviour remain provider-specific. KMS-protected data may be unreadable if keys or wrapping procedures are not exported or recreated. Xirang checkpoints may contain framework, accelerator and storage assumptions.

A private circuit and IP address cannot be carried to another cloud simply because the application moved.

Product retirement should be contracted as an exit trigger. The Yunxiao notice gave a defined runway and asked customers to back up; a separate2026 desktop cloud retirement noticestated that desktop data stored would be erased after shutdown and directed users to replacement products. These are not scandals. They are reminders that provider-led migration and customer-controlled exit are different things. A replacement in the same portfolio can preserve convenience while retaining the same concentration.

The acceptance test should export a representative production slice before going live. It should include the largest entity, an entity with versions and retention, a database under write load, a machine image, audit logs, access policies, a model checkpoint and a restore into a non-CTYun environment. Hashes, row counts and application-level results should be compared. The customer should record throughput and cost so that the full migration window can be estimated.

Finally, deletion should be staged. First, hand authority to the substitute. Then, freeze writes, reconcile data, retain required evidence, revoke external integrations, destroy credentials, close resources and demand deletion proof. Cancelling the account first may be irreversible. Exit is a controlled change of authority, not a billing administration act.

The competitive set is broader than clouds

CTYun competes with Alibaba Cloud, Huawei Cloud and Tencent Cloud, but these are not its only substitutes and they may not be the most relevant.

The Hunan government cloud award shows a national landscape that includes the three telecom operators, dedicated cloud companies, system integrators and hardware-linked platforms. A customer may split lots rather than choose a universal cloud. A regulated organisation may use a local government cloud, a private stack in a named facility, a national public cloud, an operator-hosted dedicated environment or a multi-cloud arrangement. For AI, it may rent public accelerators, buy a private appliance, build a cluster, use a model API or schedule through a capacity marketplace.

CTYun's differentiator is strongest when cloud and network must be bought together, local facilities and field support matter, national technology adaptation is mandatory, or a public buyer values a state operator's continuity role. Its provincial footprint may be more consequential than a global regions count. Xirang may broaden accelerator access beyond a single owned fleet.

The same features create the sharpest competitive questions. An operator-integrated cloud may have fewer independent network paths than a multi-operator design. A local subsidiary may accelerate support but complicate contractual identity. Full national integration may improve policy alignment while making international tools and staff skills less portable. A heterogeneous AI marketplace may broaden supply while making physical location and capacity performance class harder to generalise.

Substitution should therefore be tested by workload. A static public website may need commodity compute, object storage and a second DNS path. A provincial health system may prioritise named local facilities, on-site response and national database support. A cross-border manufacturer may need CTYun for mainland China workloads and a separately governed international cloud connected via private circuits. A long AI training job may prioritise topology, checkpoints and guaranteed accelerators over brand. No market share table chooses among these.

The strongest negotiating position is an architecture with credible alternatives at the boundary. Use portable data formats, customer-owned schemas, isolated provider adapters, independent log copies, tested image builds and a second connectivity route where service justifies it. Multi-cloud everywhere is expensive. Optionality at irreducible points is cheaper.

Twelve tests for the compact

A CTYun procurement can be made falsifiable. The following tests are deliberately specific to its combined cloud, operator, locality and AI surface.

1. 1. Prove the contractual chain.Obtain the legal name, registration details and role of the entity that signs, invoices, operates each selected pool, provides the circuit, provides support and holds each certification. If a provincial subsidiary, digital affiliate, international affiliate or partner participates, attach it to a responsibility and escalation matrix. Reject an answer that relies on "China Telecom" alone.
2. 2. Reconcile the map with the console.List each region and zone offered, then verify that the required compute, database, storage, KMS, logging, backup and AI products are actually orderable at the required scale. Record which locations have one zone, which have several, and which services share a regional control plane. Do not infer product availability from the datacenter count on the corporate map.
3. 3. Demonstrate failure domain independence.Ask CTYun to identify the shared power, network, identity, DNS, backbone, management and support dependencies across the proposed zones. Conduct a zone loss exercise. Confirm that the application, not merely the surviving instance, continues to meet its objective and that operators can create replacement resources while a control path is impaired.
4. 4. Trace every copy.Produce a data location matrix for primary data, replicas, backups, logs, telemetry, support bundles, caches, model datasets and disaster recovery copies. Constrain Xirang or any capacity marketplace to approved locations and providers. Verify placement from logs and billing records. Treat legal classification and transfer assessment as customer obligations requiring qualified advice.
5. 5. Test the network as a product.Measure latency, jitter, loss, route changes and recovery from user sites to CTYun via the proposed China Telecom access and via an independent path. Identify where AS58519, AS4134, provincial networks and private circuits appear. A cloud region SLA should not replace a circuit or end-to-end application objective.
6. 6. Exercise the APIs and SDK lifecycle.Provision and destroy a representative stack through automation. Pin SDK versions, capture error behaviour and test credential rotation, quota exhaustion and regional endpoint changes. Demand advance notice and a compatibility policy for API deprecation. Maintain an adapter boundary so thatcn.ctyunclients do not propagate into business logic.
7. 7. Assess useful AI work.For Xirang, name the accelerator, precision, topology, tenancy, framework image, storage path and queue policy. Measure accepted training progress per hour, checkpoint and restart time, failed task rate, inference latency at target concurrency and cost per accepted output. Test the advertised detection and recovery sequence rather than accept an aggregate exaflop number.
8. 8. Validate security scope.Collect current certificates and assessment reports with legal entity, service, region, date and exclusions. Map CTYun platform controls against customer configuration duties. Test public exposure, IAM separation, key rotation, log export and incident notification. Inspect existing entity buckets rather than assume the 2026 public-write restriction fixed them.
9. 9. Price three states.Build steady-state, failure and exit bills. Include compute, accelerator, storage, requests, snapshots, backup, logs, public and private traffic, security, support, licences, tax and people. Include idle resources and dual running. Demand notice and adjustment rules for price changes and product replacement.
10. 10. Make support restore, not just respond.Define severity by citizen or commercial impact. Set clocks for acknowledgement, qualified engagement, workaround, restoration, root cause report and permanent action. Name a commander for cloud-plus-network incidents. Conduct an out-of-hours call and cross-affiliate escalation before production.
11. 11. Export before acceptance.Move representative entities with versions and metadata, a live database, machine images, policies, logs and an AI checkpoint to a substitute. Compare hashes, row counts and application results. Measure throughput and cost. Record features that cannot be moved and the conversion required. An entry migration demonstration does not pass this test.
12. 12. Contract end of life.Demand minimum notice, replacement equivalence criteria, migration assistance, ongoing security patches, data export capability and deletion proof when a region, API or product is retired. Use the Yunxiao and desktop cloud notices as realistic scenarios. A successor product is an option, not portability proof.

What public records cannot prove

The evidence record is broad enough to analyse CTYun, but several consequential facts remain unavailable or unresolved in the public domain.

There is no public customer purchase order showing which entity signs each product in each province. The ASN record retains the predecessor branch language, and no resource transfer instrument examined here establishes the current legal holder of AS58519. CTYun's fleet totals do not provide a current service-by-service list of regions, zones, capacity, facility ownership and shared failure domains. Group reports aggregate China Telecom cloud and intelligent compute performance; they do not disclose Tianyi Cloud Technology Co., Ltd.'s revenue, margin, capital intensity or customer concentration.

Public product pages do not disclose realised availability by region, a consolidated incident history, capacity refusal frequency, oversubscription, recovery outcomes or support resolution percentiles. Certification claims are not accompanied on the public trust page by each current certificate and scope. Xirang's aggregate compute figure combines owned and accessed capacity without public breakdown by accelerator, precision, location, tenancy or guaranteed availability. Published pricing does not reveal negotiated discounts, public-sector cross-subsidies, support fees or the economics of dedicated AI capacity.

Documentation proves that S3-like storage, APIs, SDKs and migration tools exist. It does not prove semantic compatibility for every operation, symmetrical export, full metadata fidelity or a tested move to a named competitor. Public legal pages allocate responsibilities at a general level but do not replace a workload-specific data processing agreement, sub-processor list, service schedule or exit clause.

These are evidence limits, not adverse findings. They define the documents and tests a buyer must request. They also define the limit of this article: no customer incident, certification, market share, price, architecture or unrecorded conduct should be inferred from platform scale.

Monitor the compact, not the slogan

Five monitoring points will show whether CTYun's operating compact is strengthening or merely broadening.

1. First, regional rationalisation.CTYun's bulletin board already records maintenance, endpoint changes, stopped renewals and service retirements. Monitor whether smaller or older pools are consolidated, how much notice customers receive and whether replacements preserve locality, latency and commercial terms. A national map may grow in aggregate while a particular customer loses a useful node.
2. Second, Xirang capacity composition.China Telecom is moving from owned infrastructure to a mix of owned and accessed intelligent compute. Monitor what share is contractually guaranteed, the mix of accelerator and interconnect, the placement controls available to regulated users and the publication of workload-level reliability metrics. A marketplace becomes infrastructure when capacity quality and failure accountability are standardised.
3. Third, Triless in practice.Resource, framework and tool independence is an attractive direction. The test is whether customers can move a model, checkpoint and service workflow between accelerators and locations without custom rebuild, hidden performance loss or new proprietary dependency. Product retirements will provide real evidence.
4. Fourth, service-level security evidence.The 2025 multi-cloud security assessment and the 2026 object storage policy change are positive signals. Monitor current, downloadable scope documents, region-specific evidence, clearer incident reporting and safer default migration for existing tenants. Public-sector buyers need assurance that can be audited, not just a count on the trust centre.
5. Fifth, contractual separation in integration.China Telecom's combined network, cloud, local subsidiary and overseas reach can be a genuine advantage. Monitor whether contracts make responsibility between entities easier to understand, whether a single incident process covers the chain and whether customers can extract services without dismantling the entire arrangement. Integration should reduce operational seams without erasing legal accountability.

The compact must become a contract

CTYun is not simply a Chinese answer to a foreign hyperscaler. It is the cloud expression of a telecom operator whose network, provincial institutions, datacenters and public service role can be assembled around a workload. This makes the province part of the product and the operator relationship part of the architecture.

The compact can be powerful. A customer can place data domestically, connect offices and facilities through the same group, obtain local implementation, use public or dedicated cloud, and reach a growing pool of heterogeneous AI compute. Public procurement records show that buyers can demand openness, migration, destruction, security and continuity in this arrangement.

The compact can also concentrate risk. The same relationship may govern access, compute, support and recovery. A locality label may hide a single zone. An AI abstraction may hide materially different capacity. A familiar API may preserve syntax but not state. A replacement product may preserve the provider while changing the customer's operating surface.

The correct conclusion is neither that state ownership guarantees continuity nor that it prevents technical competition. CTYun should be judged on the ability of its promises to be translated into workload-specific evidence: the named legal party, the named facility and zone, the measured network path, the recoverable application, the scoped security assessment, the useful unit cost and the verified export.

The map is strategically impressive. The procurement win is to make every important line enforceable — and every necessary route out usable.