Summary
- The APNIC registration for AS151217 identifies
SIHE-SHCTas Sihe Cloud Shanghai Technology Co., Ltd., at 1508 Kunyang Road in Shanghai. The company also holds the portable IPv4 range160.19.76.0/23and the portable IPv6 range2401:9e20::/32, all registered in May 2024 with matchingsihe.aicontacts. - AS151217 itself is not publicly active. RIPE's routing status reports no announced IPv4 or IPv6 space, no observed neighbour and zero visibility among its full-table peers. The Shanghai company's IPv6 allocation is also unrouted.
- The IPv4 block is different: RIPE sees
160.19.76.0/23at every reporting IPv4 peer, originated by AS9808, China Mobile. The route has been visible since June 2024. This proves public reachability of the address resource, not independent network operation by AS151217 or a particular rack location. - A live Sihe Cloud storefront sells virtual machines, containers, managed databases, object storage and file storage, supported by a reachable console and documentation centre. Yet those public pages and the standard service agreement identify Haining Sihe Cloud Computing Technology Co., Ltd. as the supplier. They do not explain the Shanghai company's role in retail service delivery.
- The prudent conclusion is therefore narrow. Sihe Cloud Shanghai Technology Co., Ltd. demonstrably controls internet-number resources and has an IPv4 block routed through a major carrier. Public evidence does not establish that it owns a data centre, operates the customer-facing cloud, controls a multi-carrier edge, keeps migration reserve or bears the support and data-return obligations sold under the Sihe name.
The live route is the strongest fact, and it creates the hardest question
Small cloud companies are often easiest to find through the public internet resources attached to their legal names. That is true here, but the records do not form the simple picture suggested by a company name. The AS151217 record names Sihe Cloud Shanghai Technology Co., Ltd., gives the network name SIHE-SHCT, and locates the administrative contact at the second floor of Building 2, 1508 Kunyang Road, Minhang District, Shanghai. Registration occurred on 11 May 2024. The administrative, technical and abuse contacts all use the sihe.ai domain.
On the same date, the company received two portable address resources. The first, 160.19.76.0/23, spans 512 IPv4 addresses. The second, 2401:9e20::/32, is an IPv6 allocation large enough to support an enormous number of customer subnets. These are not casual directory mentions. They are authoritative resource registrations maintained through APNIC and CNNIC. They establish that the Shanghai company is the named holder of the resources and has a recognised operational contact surface for abuse and network administration.
What they do not establish is equally important. An office address in an internet registry is not a data-centre address. A portable block does not disclose whether the holder owns the routers, leases a rack, uses a carrier's managed announcement service, assigns addresses to customers, reserves the space for later deployment or has delegated daily operation to another company. APNIC's resource registration guidance says an organisation qualifies for an ASN when it is multihomed with a distinct routing policy, or can demonstrate that it will meet those criteria shortly after receiving the number. Possessing the identifier is therefore an option and intention to operate a distinct routing policy, not proof that the option is being exercised now.
The Shanghai company's IPv4 block is nevertheless live. RIPE's network information maps the entire /23 to AS9808. The routing-status view records AS9808 as the origin, reports visibility at all 325 available IPv4 peers at the observation point, and dates the first seen route to 7 June 2024. Routing history shows repeated visible intervals under the same origin from June 2024 onward. The route is not a forgotten registry allocation. It reaches the global table.
That makes the central question sharper, not easier. If a customer receives an address from this block, the public route says that China Mobile's network is the origin visible to the rest of the internet. The route does not pass through AS151217. The Shanghai company may have a commercial arrangement that gives it legitimate and useful control over addressing, filtering and customer assignments, but the public path does not reveal the terms. When an incident requires an urgent route change, mitigation action or prefix withdrawal, customers need to know which party can make that change and which party merely opens a ticket.
AS151217 is assigned but silent
There is no ambiguity in the current collector view of the Shanghai company's own ASN. RIPE's AS overview marks AS151217 as unannounced. Its routing-status response reports zero IPv4 prefixes, zero IPv6 prefixes, no first-seen route, no last-seen route and no observed neighbour. Visibility is zero among 325 IPv4 and 322 IPv6 full-table peers. The announced-prefixes response is empty, and the neighbour view reports no left, right, unique or uncertain neighbour.
Independent topology evidence points in the same direction. CAIDA's AS Rank record identifies SIHE-SHCT in China but marks it unseen, with no provider, peer or customer degree and no address or prefix cone. CIDR Report says the ASN is not used to announce a prefix in the global table or as a visible transit AS. A query to PeeringDB returns no network entity. PeeringDB participation is voluntary, so absence there is not proof of no interconnection. Taken together with the collector data, however, it offers no support for a public peering or facility footprint under AS151217.
Silence does not mean the company is inactive in every sense. It can use provider-assigned addresses, place equipment behind a carrier, operate private networks, or ask another ASN to announce its portable space. The routed /23 shows that the last of those possibilities is not theoretical. The distinction matters because a carrier-originated prefix can support a perfectly functional hosting service. It simply gives the customer a different control model from one in which the hosting company visibly runs its own edge and has independently observable upstream relationships.
The portable IPv6 allocation is also silent. RIPE's status for 2401:9e20::/32 finds no origin, no more-specific route, no less-specific route and zero visibility among the available IPv6 peers. The allocation is administratively substantial but operationally absent from the public table. That gap matters for customers who expect dual-stack service, because an IPv6 resource on paper is not equivalent to a routed IPv6 service with tested customer assignments, filtering, monitoring and incident response.
The route-security picture is thin as well. RIPE's RPKI validator returns unknown for the AS9808 and 160.19.76.0/23 pair because it finds no validating route-origin authorisation. Unknown does not mean invalid and is not evidence of a hijack. It means the public cryptographic system does not provide a positive authorisation that AS9808 may originate this prefix. For a portable block routed through a third party, a valid authorisation would make the intended origin more explicit and reduce one category of routing ambiguity.
The origin belongs to China Mobile, not to the resource holder's ASN
The APNIC record for AS9808 identifies CHINAMOBILE-CN as China Mobile Communications Group Co., Ltd. That is a major carrier network with a scale and route footprint far beyond the Shanghai company's /23. Its presence as origin gives the block global reachability and a carrier-grade path into the wider internet. It does not tell a customer whether the Shanghai company buys transit, buys an access circuit, leases hosting capacity, uses an address-announcement product or has some other arrangement.
This difference between allocation and origin is not merely a routing technicality. The resource holder can be responsible for address assignment and abuse contacts while the origin network controls the border policy visible to the world. A denial-of-service attack may need action from both parties: the service provider identifies the target and desired response, while the carrier applies filtering or scrubbing at a point where the traffic can still be absorbed. A route leak may require the origin to change policy. A planned maintenance window on the carrier handoff can disconnect servers that remain powered and healthy.
A commercial dispute over the circuit can make a valid address allocation unreachable.
The public route also reveals only one origin, not diversity. A multi-carrier service can still originate a prefix through one ASN while using other carriers in ways that collectors do not expose, but there is no public basis for assuming that here. AS151217 has no visible neighbours. The /23 has one visible origin. The absence of a PeeringDB network entry leaves no voluntary listing of exchange points, facilities or interconnection policy. A buyer should therefore treat carrier diversity as an unanswered engineering question rather than infer it from the existence of an ASN or from broad claims on a related commercial site.
The physical handoff is just as important as the logical route. Two contracts with different carrier names can still share one building entry, one fibre tray, one aggregation router or one metropolitan duct. Conversely, one carrier can sometimes deliver genuinely diverse paths. Proving resilience requires route diagrams, circuit identifiers, entrance paths, demarcation points, maintenance responsibility and failure-test results. A logo list cannot do that work.
The public data for the Shanghai company does not disclose even the facility in which the routed block terminates, so the first task is to establish the site before assessing diversity inside it.
The orderable Sihe service points to a different contracting company
There is a functioning commercial service under the Sihe name. The Sihe Cloud homepage advertises elastic virtual machines, container compute, managed relational databases, load balancing, object storage, file storage and distributed denial-of-service protection. It links to a reachable management console where a user can register, and to a documentation centre with product instructions, pricing pages and service terms. These are stronger operating signals than a dormant company website or a bare registry record. They show a maintained customer surface with products described in enough detail to support actual use.
But the legal name on that service is not Sihe Cloud Shanghai Technology Co., Ltd. The homepage metadata, company description and footer identify Haining Sihe Cloud Computing Technology Co., Ltd. The about page says that Haining company was established in 2018 and describes cloud computing, equipment design and manufacturing, and IDC construction and operation. It gives a customer-service number and an address at 180 Canghai Road in Haining, Zhejiang. The documentation footer also names Haining Sihe and displays a Zhejiang ICP filing and a value-added telecommunications business licence number.
The standard service framework and SLA is more explicit. It states that Haining Sihe Cloud Computing Technology Co., Ltd. contracts with the user to provide the Sihe cloud-computing platform. It names 180 Canghai Road, Haining, as the place of performance. It promises round-the-clock operational service, monthly availability of at least 99.9 per cent and the start of a response within 30 minutes after a technical problem. It also defines exclusions, payment duties, suspension rights, termination conditions and resource reclamation.
None of those pages assigns a role to the Shanghai company. Shared sihe.ai contacts, the same Sihe name and the obvious commercial proximity may indicate common organisation or cooperation. They cannot by themselves establish ownership, parentage, agency, subcontracting or joint responsibility. The public contract does allow the service provider to transfer rights or obligations in specified circumstances, but it does not identify the Shanghai entity as the party operating the routed block, the racks or the support desk.
That boundary should remain intact. The Shanghai company can be described as the holder of AS151217 and the two portable allocations because the registry says so. The Haining company can be described as the public supplier because the storefront and terms say so. The IPv4 block can be described as originated by China Mobile because the route says so. Joining those three facts into a single corporate and operational chain requires an agreement, ownership filing or first-party technical disclosure that is not public.
The storefront is reachable through a fourth network surface
The visible web service does not currently use the Shanghai company's portable IPv4 block. Public DNS for the homepage, the console and the documentation site leads through Sihe-named Deyang hosts to 222.213.119.154. RIPE's network information places that address in 222.208.0.0/13, originated by AS4134. APNIC's address record identifies the covering network as CHINANET-SC, China Telecom's Sichuan network.
This is a point-in-time view of the service edge, not a map of the application or storage estate. A DNS label containing Deyang can reflect an operator's naming convention; it does not prove the building in which every server sits. An origin ASN identifies the network announcing the endpoint, not the owner of the server behind it. A web front end can also be separated from compute and storage regions. The observation is still useful because it shows that the most visible Sihe customer surfaces are not reached through AS151217 or through the Shanghai company's 160.19.76.0/23.
Customers should therefore avoid using the website route as evidence for workload placement. The public edge could be a load balancer, reverse proxy, entity-storage website endpoint or combined service host. The console could control machines elsewhere. Documentation can be served independently from production. To locate a workload, the relevant evidence is the assigned instance address, the storage endpoint, traceroutes from useful access networks, contract region, facility disclosure and the provider's data-location commitments.
The split also creates an outage pattern that is easy to overlook. The storefront and console can fail while customer machines remain reachable. Customer machines can fail while the console looks healthy. Documentation can remain online during a control-plane outage. The carrier-originated Shanghai /23 can stay visible while a rack behind it loses power, or be withdrawn while every server remains powered. A credible status model needs separate checks for account access, control operations, compute reachability, storage operations, DNS, each public prefix and each advertised zone.
A product catalogue describes obligations, not installed capacity
The ECS documentation describes virtual machines that can be configured by processor, memory and disk, exposed through several network protocols, monitored in the console and expanded or reduced as demand changes. It also says that if a physical host fails, the platform will automatically migrate virtual machines to a healthy machine, while advising customers to configure their services to start automatically. That is a concrete operational promise. It implies a scheduler, shared storage or a workable disk-migration method, spare host capacity, health detection and a destination host compatible with the failed workload.
The RDS documentation goes further into managed responsibility. It says the provider handles infrastructure, availability, backup and restore, upgrades and fault migration, and offers single-node and multi-node database patterns. A customer reading that description is not merely renting processor time. The customer is relying on an operating team to distinguish host failure from database failure, keep backups separate enough to survive the relevant fault, test restores and preserve consistency during failover.
The storage products multiply those dependencies. The entity-storage page claims distributed storage, automatic copies on different devices and data centres, high availability, automatic scaling and access through a widely used entity interface. The S3 command-line tutorial shows an export path using S3-compatible tools and access credentials. The NAS page describes redundant cloud disks, multiple-instance mounting and shared file access.
Those pages establish a saleable product surface. They do not count the physical hosts, drives, ports, racks, power draw or unused failover reserve behind it. They do not identify which products use the Shanghai company's portable block. They do not show whether entity copies occupy independent buildings, independent fire zones or merely different devices in one room. They do not provide customer-specific recovery-point or recovery-time commitments. The difference between a documented feature and installed capacity is where cloud risk usually hides.
The ECS pricing page prices processor, memory, disk and outbound traffic as separable consumption units and says the console price prevails. This is economically intelligible to a buyer, but each unit maps to finite infrastructure. A virtual processor is a share of a host processor. A gigabyte of memory must be installed in a server. A disk allocation consumes media, controllers, replication traffic and replacement stock. Outbound transfer consumes a carrier commitment and potentially a congested port. The retail meter does not reveal the provider's purchase commitment or the reserve available during a failure.
Installed, sellable and recoverable capacity are different quantities
A cloud operator can advertise a large catalogue while having little spare capacity in the exact fault domain that matters. Capacity passes through several stages. A site may be planned, built and supplied with power. Racks may be installed but empty. Servers may be installed but awaiting network or storage commissioning. Hosts may be commissioned but already allocated. Resources may be technically free but reserved for maintenance, replication or failure recovery. Only the remainder is safely sellable.
The Sihe homepage claims three machine rooms or availability zones with independent cooling and networking, dual utility feeds from two substations, multi-line network access, N+1 cooling, a self-built photovoltaic plant, 20Gb of public bandwidth and 50GbE or 400GbE internal networking. These are meaningful claims because they describe physical and logical design choices. They are not accompanied by facility names, site addresses, one-line electrical diagrams, carrier circuit details, commissioned load, utilisation, audit reports or failover tests.
The claims should therefore be read as supplier representations, not measurements of current customer-available capacity.
The word "three" is particularly easy to overread. Three rooms in one building do not provide the same protection as three sites on separate utility, flood, fire and carrier systems. Three logical zones can still share a control plane or storage fabric. Independent cooling within rooms can still depend on one building water or electrical system. Two utility feeds can converge at one substation, switchboard or transformer despite a design intention to separate them. A solar installation can reduce energy cost without sustaining the server load during a grid failure. Each claim needs a fault-domain map.
For the Shanghai entity, the location gap comes first. Its registry address on Kunyang Road is an administrative contact address and must not be promoted into a rack location. The Haining service agreement gives a place of contract performance, but not a list of data centres. The web edge uses Sichuan address space and Deyang labels, but that does not locate the whole cloud. The Shanghai /23 is originated by China Mobile, but a carrier origin does not disclose which city or building contains the terminating equipment. Public evidence therefore supports a service area in China, not a precise map of installed assets.
This uncertainty changes procurement. A buyer cannot calculate correlated risk across compute, database and object storage until it knows whether their primary and recovery copies share a site. It cannot assess power continuity until it knows the contracted rack and utility path. It cannot judge carrier diversity until it sees circuits and entrances. It cannot assess hardware replacement until it knows the fleet type and local spare stock. In a small cloud, a modest number of unused hosts or drives can be the difference between a quick migration and an extended queue.
The outage tree begins below the virtual machine
A customer sees an instance, an address and a console button. The service operator sees a chain of dependencies. At the bottom is the facility: utility intake, switchgear, uninterruptible power supplies, batteries, generators, cooling, fire systems, physical security and maintenance labour. Above it sit racks, power distribution units, top-of-rack switches, server power supplies, processors, memory, local media, storage networks and management controllers. Above those sit the hypervisor, scheduler, virtual network, image service, identity system, billing system and customer console.
Failure at any level can produce a similar customer symptom. A dead virtual machine can be a guest operating-system problem, an exhausted host, a failed drive, a switch outage, a storage pause, a rack power event or an account suspension. The route can remain visible during most of those faults. Conversely, a route failure can make a healthy machine look dead from outside. Diagnosis therefore depends on observability at each layer and a support team empowered to cross organisational boundaries.
The Shanghai route adds a carrier dependency to this tree. AS9808 is the public origin for 160.19.76.0/23. If a customer in that block loses connectivity, the hosting side must decide whether the fault is inside the virtual network, at the server-facing switch, at the carrier handoff, in the carrier backbone, in route propagation or on a remote access network. If the company does not directly control the origin routers, escalation quality becomes part of service quality. The practical questions are who holds the carrier account, what priority the circuit receives, whether engineers can call the network operations centre directly and whether emergency route changes require commercial approval.
Hardware stock creates another branch. The ECS promise of automatic migration assumes a healthy destination with sufficient processor, memory and storage capacity. If several hosts share a power or cooling fault, the platform must absorb more than one machine at once. If source storage is damaged or isolated, live migration may not be possible. If the destination has a different processor generation or device profile, some workloads may not start cleanly. A provider can meet ordinary sales demand yet lack the concentrated reserve needed during a site event.
Repair time is not only the time needed to replace a part. It includes detection, access approval, technician travel, fault isolation, spare identification, change approval, physical work, firmware or configuration, data rebuild, validation and return to service. A four-hour hardware swap can become a much longer customer incident if the correct power supply or drive is not local. The public material does not disclose Sihe Cloud Shanghai's fleet, on-site staffing, spare policy or access arrangement. Those omissions are not evidence of poor practice. They are limits on what a customer can confidently assume.
Redundancy claims must survive common-cause tests
The homepage's three-zone, dual-power, multi-line and N+1 claims describe the right categories of resilience. The test is whether they remove a shared cause. Two power feeds are useful only if a single breaker, automatic transfer switch, cable route or maintenance procedure cannot take down both. Two carriers are useful only if they do not converge on the same duct, entrance, optical distribution frame or upstream backbone. N+1 cooling is useful only within the design load and only if power, controls and heat rejection remain available.
Routing evidence does not currently demonstrate a multi-carrier edge for the Shanghai company. AS151217 is silent and has no observed neighbours. Its IPv4 block has one origin, AS9808. Its IPv6 block is not routed. This does not disprove a second access service, private interconnect or backup circuit. It means that the customer cannot validate diversity by inspecting the public route. The provider would need to disclose or demonstrate it at a different layer.
The most useful evidence would be a site-and-circuit matrix. For each advertised zone, it would name the facility operator, city, room, electrical feed, cooling boundary, carrier, circuit handoff, external origin, internal backbone path, storage replica and control-plane dependency. It would distinguish active-active capacity from a cold or capacity-constrained standby. It would show whether the Shanghai /23 is used for customer instances, infrastructure services, future capacity or another purpose. It would also show whether failover preserves the same customer address or requires DNS and address changes.
Tests matter more than diagrams. A controlled route withdrawal can show whether a backup path actually carries traffic. A host evacuation can show whether migration reserve exists. A restore exercise can show whether backups are readable and whether credentials survive a control-plane incident. A utility transfer test can show whether the rack remains powered. A support exercise can show whether the right people answer within the promised window. Without results, redundancy remains a design intention.
The BGP specification explains how networks exchange reachability and AS paths, while operational guidance in RFC 7454 covers filtering, session protection and controls such as maximum-prefix limits. Those practices reduce routing risk but cannot be inferred from a registered ASN. AS151217's silence means there is no visible public operation against which to assess them. For the live /23, the relevant policy is primarily the policy of the AS9808 origin and the commercial arrangement that authorises and governs it.
Recovery is a capacity problem before it is a software feature
The product pages make several recovery claims: ECS host migration, database backup and fault migration, entity copies across devices and data centres, redundant file storage, snapshots and images. Each can be valuable. None removes the need to ask how much capacity is reserved, where copies reside and how restoration behaves under stress.
For virtual machines, a migration feature should be separated into planned and unplanned cases. Planned evacuation can move workloads while the source host remains healthy. An abrupt host failure may require restarting a virtual machine elsewhere from shared storage or a replicated disk. That creates downtime even if the move is called automatic. The customer's recovery time then depends on failure detection, scheduler capacity, disk availability, boot behaviour and application recovery. The ECS instruction to configure automatic startup is a useful clue that customer configuration remains part of continuity.
For databases, the essential metrics are recovery point and recovery time. A multi-node configuration can reduce interruption if replicas are current and the failover mechanism can establish a safe primary. Backups protect against a different class of problem, including accidental deletion or corruption, but only if they are old enough to predate the damage and separate enough to survive the failure. The public RDS page describes high availability and backup in general terms. It does not publish a customer-specific topology, retention schedule, restore-test result or guarantee for either metric.
For object storage, S3-compatible access is a promising portability feature. The documented s3cmd method means customers can use familiar tooling rather than a purely proprietary interface. But an interface is not an exit plan. Large exports depend on listing behaviour, entity count, metadata compatibility, credentials, outbound bandwidth, throttling and fees. A customer that can theoretically copy hundreds of terabytes may still need weeks to do it through a constrained link.
For file storage, application consistency can be harder than block copying. An open database or active shared file system may need coordinated snapshots, quiescing or application-level backups. Redundant disks protect against some hardware failures but not necessarily operator error, malicious deletion, account compromise or a site-wide event. The correct recovery design often includes a copy controlled under separate credentials and, for critical workloads, outside the provider's fault domain.
A customer should test an external restore before it needs one. Export a representative virtual-machine image or rebuild from configuration. Restore a database into an independently controlled environment. Copy a meaningful entity set with metadata and verify checksums. Recreate access controls. Measure throughput at ordinary and peak times. Record which steps require the Sihe console or support desk. These tests turn portability from a contractual hope into an observed property.
Support, billing and contract state can stop healthy infrastructure
Cloud availability is partly administrative. The Sihe service agreement promises 365-by-24 operations support and says response will begin within 30 minutes after a technical problem. It does not promise resolution within 30 minutes. That difference is sensible, because repair depends on the fault, but buyers should make it explicit in their own expectations. They should know which channels are monitored, how severity is assigned, when an engineer rather than customer service joins, and how a carrier incident is escalated.
The agreement excludes several kinds of downtime from its availability calculation, including routine maintenance, user causes, third-party causes and force majeure. It also gives the service provider rights to stop service for unpaid obligations, specified harmful uses, regulatory demands and other breaches. On termination, it allows the provider to reclaim customer resources and dispose of or clean resources or equipment previously used by the customer. These terms make the account and payment state part of the infrastructure chain.
That chain can fail quietly. A payment notice sent to an unattended address can lead to suspension. A departed employee can retain the only administrator credential. Real-name verification or regulatory requests can block account changes. An abuse report can trigger urgent filtering. A contract disagreement can delay an export while machines remain technically healthy. Customers should separate billing, security and technical contacts; use shared organisational credentials; keep an external asset inventory; and define an emergency data-return path before a dispute occurs.
The entity boundary matters again here. The published standard agreement names Haining Sihe as the supplier. The portable IPv4 block names the Shanghai company as holder. China Mobile's AS9808 originates the route. If a customer address in that block is suspended or unreachable, it needs to know which contract governs the address, which company controls the account, which company speaks to the carrier and which party has possession of the data-bearing equipment. Shared branding is not a substitute for that allocation of responsibility.
The 99.9 per cent monthly availability figure also needs translation into operational consequences. In a 30-day month, 0.1 per cent is roughly 43 minutes. Excluded maintenance and third-party events can increase customer-experienced downtime without reducing the contractual calculation. A credit, if available, does not restore lost transactions or repair corrupted data. The useful procurement question is not whether the percentage looks familiar; it is whether the service architecture, exclusions, evidence and recovery plan match the customer's actual loss model.
Data locality is a chain of copies and controllers
All identified company and network records are in China, but "in China" is not a complete data-location answer. The Shanghai company's registration points to Minhang. The standard service agreement points to Haining. The storefront edge points toward a China Telecom Sichuan address and Deyang-named hosts. The IPv4 block is carried by China Mobile, without a public facility location. Product documentation claims storage copies across devices and data centres. These facts describe several places and roles without mapping a customer's primary and secondary data.
Locality should be documented by data type. A virtual machine has system and data disks, snapshots, images, logs, console metadata and credentials. A managed database has primary data, replicas, transaction logs, backups and monitoring records. Object storage has entities, metadata, indexes, access logs and possibly cached copies. Support interactions can contain customer names, addresses and system details. Billing and real-name verification add another set of personal and corporate records. Each may have a different controller, retention period and location.
China's Personal Information Protection Law sets a national framework for handling personal information, and its cross-border provisions impose conditions when personal information is provided outside China. The public evidence does not show that the Shanghai company or the Sihe service transfers customer personal information abroad. The law matters here because customers cannot assess their own obligations until they know which legal entity handles which data, where copies go and which subprocessors or carriers can access them.
The official Chinese telecommunications service classification describes IDC business in physical terms: facilities, placement and maintenance of customer equipment, leased servers and storage, communication lines and bandwidth. That definition is a useful corrective to the frictionless cloud metaphor. Even a virtual service rests on a licensed and contracted combination of rooms, hardware, lines and people. Public claims that the Haining company holds relevant licences do not establish which licence, facility or operating responsibility belongs to the Shanghai resource holder.
A customer locality schedule should therefore name the contracting entity, facility operator, city, primary region, backup region, support-access locations, network origins and export path. It should state whether customer data ever enters the Shanghai company's portable block and whether the block's traffic is processed or logged by another party. It should identify the legal basis and approval process for remote support. It should also define what happens to backups, snapshots and logs after termination.
Who is affected when the chain fails
The immediate victims are not limited to infrastructure teams. A small business may run its public website, inventory system and staff files on one account. A software company may place production containers, a managed database and object storage in the same service, creating a correlated dependency across application, state and backups. A video or industrial system may generate sustained storage and network load that is difficult to move quickly. An individual developer may rely on a low-cost instance without a second provider or local backup.
Each product fails differently. Loss of the carrier route disconnects every externally reached address in the affected block even if the hosts are healthy. Loss of a rack or storage fabric can damage a subset of instances while the route stays visible. Loss of the control plane blocks provisioning, restart and credential changes. Loss of the entity store can break applications that still have working compute. Loss of RDS can stop transactions while static pages remain online. Loss of billing access or an account suspension can cut across all of them.
The blast radius depends on whether the advertised zones are independent and whether customers deliberately spread workloads. Automatic migration can reduce a single-host failure but concentrate demand on remaining hosts. A multi-node database can survive one node but not a shared storage or control-plane failure. Entity replication can survive a drive but not an account-wide deletion if every copy follows the same authority. Carrier diversity can protect one circuit but not a shared route-policy error. The architecture must match the threat.
Downstream customers also inherit the operator boundary. If a software company sells service on top of a Sihe-hosted instance, its own users may never know that the public route is originated by China Mobile, that the standard contract names Haining Sihe or that the address is registered to the Shanghai company. During an outage, the downstream provider becomes the translator between an opaque infrastructure chain and users who need clear recovery estimates. That is why small-cloud procurement is not just a price comparison. It is continuity planning for everyone further down the stack.
The evidence that would make the Shanghai role clear
The first useful disclosure would be a short statement from Sihe Cloud Shanghai Technology Co., Ltd. explaining its present role. Does it operate network resources for the Haining service, hold addresses on behalf of a related company, provide Shanghai capacity, manage a carrier contract, or prepare future infrastructure? Which services use 160.19.76.0/23? Why is AS151217 not the origin? Is 2401:9e20::/32 scheduled for deployment? Clear answers would connect the registry facts to an operating purpose without requiring disclosure of sensitive customer details.
The second would be route authority and resilience evidence. A valid route-origin authorisation for the intended origin would improve the public security signal. A letter of authorisation or equivalent carrier record could confirm that AS9808's announcement is intentional. A network diagram could show the demarcation, backup path, filtering responsibilities and escalation chain. Route-monitoring history and a controlled failover result would show that the design works.
The third would be a bounded facility and capacity statement. It need not reveal exact rack coordinates. It should name the city and facility operator for each advertised zone, distinguish owned from leased space, state commissioned power and current usable reserve in broad bands, identify whether zones share a building, and disclose the number of independent carrier entrances. It should separate design capacity from installed equipment and installed equipment from customer-available failover capacity.
The fourth would be recovery evidence. Publish or provide under agreement the host-evacuation method, spare-capacity policy, snapshot and backup retention, database recovery targets, entity-replication fault domains and results of recent restore tests. Give customers a measured export rate and explain whether export remains available during suspension or termination. State which actions require the console and which can be completed through an emergency support path.
The fifth would be a responsibility matrix among the Shanghai company, Haining supplier, carrier and facility operator. For routing incidents, hardware replacement, security reports, billing suspension, regulatory requests, data return and contract termination, it should name the accountable party and escalation route. That single document would do more for customer confidence than a long feature list because it would expose the handoffs where time is usually lost.
Verdict: a routed resource with an unresolved service boundary
Sihe Cloud Shanghai Technology Co., Ltd. is more than a name in an old record. It holds AS151217, a portable IPv4 /23 and a portable IPv6 /32, all registered with consistent Shanghai and sihe.ai contacts. Its IPv4 block is publicly routed, globally visible and has been originated by China Mobile's AS9808 since June 2024. That is tangible network activity attached to a resource the company controls.
The same evidence stops short of showing an independently operated Shanghai network. AS151217 announces nothing, has no observed neighbour and has no visible prefix history. The IPv6 allocation is dormant. The IPv4 route uses another company's ASN and has no validating route-origin authorisation in the observed RPKI view. No public facility, rack inventory, carrier handoff, support team or customer workload is tied specifically to the Shanghai entity.
The live Sihe Cloud service adds commercial substance but not clean attribution. Its storefront, console, documentation and contract demonstrate that customers can buy and operate cloud products under the Sihe name. They also identify Haining Sihe Cloud Computing Technology Co., Ltd. as the public supplier and use a customer-facing web edge in China Telecom Sichuan space. The public materials do not explain how the Shanghai resource holder participates.
The resulting evidence grade is weak for the exact entity-to-infrastructure chain, despite the strong evidence for the individual registry and route facts. Customers should not infer that the Shanghai company owns a data centre, runs three independent sites, operates a multi-carrier edge or bears the retail SLA merely because its /23 is live and its name shares the Sihe brand. They should ask who controls the origin, where the addresses terminate, which company owns or leases the racks, how much migration reserve exists, who carries the support obligation and how data leaves under pressure.
That is the physical meaning of hosted capacity. A virtual machine can be provisioned in minutes, but its continuity still depends on a powered rack, an available host, a working storage path, a carrier willing and able to announce the route, a technician with the correct spare, and a contract that keeps account and export rights intact. For Sihe Cloud Shanghai Technology Co., Ltd., the public IPv4 route proves that one part of this chain is active. It also makes the undisclosed links impossible to ignore.