AS63199 makes Global Cloud Co., Ltd visible; the enterprise path

Summary

ARIN and RIPEstat give AS63199 a clear public identity and show it as an announced network with broad collector visibility. That is stronger evidence for a routed operating surface than company marketing alone.
PeeringDB records 26 operational exchange attachments and 26 facility attachments for the network profile associated with AS63199. These records support geographic interconnection presence, but not traffic volume, owned infrastructure, route policy or customer-specific performance.
CDS Global Cloud markets GPN, PIR, Global DIA, CloudConnect and BGP services around China and global connectivity. Its capacity, carrier, service-level and licence statements remain company-authored claims in the public sources reviewed here.
An enterprise buyer therefore has to test the exact service path: which autonomous system originates or carries the route, where the handoff occurs, how failover is controlled, what the service-level remedy measures, which legal entity supplies each segment, and who performs operational escalation.

The useful starting point is a network identity

Cloud-service descriptions can make unlike products sound interchangeable. A direct cloud connection, an internet route optimized for China, a private Layer 2 circuit and a blended BGP service may all be sold as ways to reach the same application. Their control points are different. The first task is therefore to identify what network is actually visible and which company record is tied to it.

For Global Cloud Co., Ltd, the cleanest anchor is AS63199. ARIN RDAP identifies the autonomous system as CDSC-AS1 and associates it with CDS Global Cloud Co., Ltd. The registration date shown for the AS is 8 September 2014, and the record's last-changed date is 9 January 2026. A separate ARIN organization record resolves handle CDSC-1 to the same company name, with a registration date of 2 June 2014 and the same 2026 last-changed date. These records establish a registry relationship. They do not certify the present commercial scope of the business or the quality of a service.

ARIN also records a direct IPv4 allocation named CDSC-1, covering 148.153.0.0 through 148.153.255.255, registered on 12 January 2016. That is evidence of an address resource assigned to the organization. It is not evidence that every address is active, announced by AS63199, assigned to a customer or reachable through the same product.

This distinction matters because the company's public pages name both AS63199 and AS38353. The ARIN and RIPEstat records reviewed here independently close the registry and routing identity of AS63199. They do not provide the equivalent external registry and routing pass for AS38353. AS38353 can therefore be described here only as a companion autonomous system claimed by the company, not as an independently verified second operating surface.

The result is a narrower but more useful proposition than a general cloud label. A buyer can begin with a named autonomous system, an organization record and an address allocation, then ask the provider to map the offered service onto those identifiers. If the sales design cannot make that mapping, the public network evidence and the commercial offer are not yet connected.

AS63199 is observable, but observability is not path control

RIPEstat reports AS63199 as announced and lists the holder as CDSC-AS1 - CDS Global Cloud Co., Ltd, with ARIN as the assigning registry. Its announced-prefixes response returned 547 prefixes for the observation window from 6 July to 20 July 2026. The set included IPv4 examples such as 38.123.107.0/24, 148.153.219.0/24 and 118.193.20.0/24, as well as the IPv6 example 2400:5280:804::/48.

The routing-status response adds longitudinal and visibility signals. It reports AS63199 first seen with 139.159.48.0/24 on 2 April 2015. At the 20 July 2026 query time, its last-seen example was 154.223.132.0/24. The response showed the AS visible to 325 of 325 RIS IPv4 peers and 320 of 320 RIS IPv6 peers. These are strong indications that AS63199 was not an obscure or locally invisible registration at the time of observation.

They still answer only part of an enterprise question. Route collectors can show that prefixes and paths are visible from their observation points. They do not show that a particular customer circuit will use a particular ingress, remain on a preferred route during congestion, or fail over within a contractual interval. Nor does the count of 547 observed prefixes establish how many belong to Global Cloud Co., Ltd, its customers or another origin arrangement in a commercial sense. Prefix counts are also time-sensitive and can change after the observed window ends.

RIPEstat returned 211 observed neighbours for AS63199. High-power samples in the response included AS174, AS1299, AS12956 and AS17408. The word "observed" does important work here. A neighbour seen in routing data is not automatically a confirmed supplier, customer, paid-transit contract or currently preferred path. Without contract evidence or a direct session statement, the neighbour set is a view of routing adjacency, not a commercial ledger.

That makes the public routing record valuable in two ways. First, it gives a buyer independent points to test before signing: advertised prefixes, path changes, origin consistency and visibility from relevant markets. Second, it sets a limit on what can be concluded. AS63199 is visibly participating in global routing; the public record does not disclose the policy logic that will select an enterprise's path on an ordinary day or during a fault.

The 547-prefix snapshot is a test set, not an estate count

The RIPEstat prefix response is tempting to use as a scale indicator because 547 is a precise number. Precision does not remove the need to understand the measure. The response is a time-bounded observation of prefixes announced by AS63199. It is not an inventory of servers, customers, sites, contracts or address resources owned by Global Cloud Co., Ltd. The public sources reviewed here do not classify each prefix by registrant, service or customer use.

The direct ARIN allocation helps illustrate the boundary. 148.153.219.0/24, one of the announced-prefix samples, sits inside the recorded 148.153.0.0 to 148.153.255.255 allocation. That creates a clean connection between one observed route sample and an address range registered to CDSC-1. It does not extend automatically to all 547 prefixes. Each additional range would require its own registry and route-origin check before it could be described as directly allocated company space.

The snapshot can instead become a diligence test set. A customer whose service will use provider-assigned addresses can ask which prefixes apply to the service, whether AS63199 will originate them, and whether the same origin is expected during failover. A customer bringing its own addresses can ask what authorization and routing arrangement will be used. In both cases, the offered prefix list can be compared with current observations rather than with the headline total.

Timing should be recorded as carefully as the count. The RIPEstat announced-prefix observation ends on 20 July 2026, and routing data can change. A pre-contract route capture should therefore state when it was made, from which relevant markets it was observed, and which prefixes and paths were expected. A later difference is not automatically a fault; it is a prompt to determine whether the commercial design changed, normal routing changed, or the original description was incomplete.

The all-peer visibility figures require the same discipline. Visibility to 325 of 325 RIS IPv4 peers and 320 of 320 RIS IPv6 peers is broad collector coverage for the AS at query time. It does not mean every enterprise endpoint can reach every announced prefix with the same quality. It also does not reveal whether the customer will receive a route through a nearby exchange or a longer path through another market. Collector visibility should be used to verify existence and propagation, while endpoint measurements verify the service the buyer actually experiences.

The neighbour count is most useful as a question generator. If the provider proposes a particular carrier path, an observed adjacency may support the plausibility of that design. Its absence from a snapshot does not necessarily disprove a private or newly established arrangement, and its presence does not prove a contract. The provider still needs to identify the operational relationship relevant to the service, and the buyer still needs to observe the delivered route.

PeeringDB shows distribution, not the service an enterprise receives

The PeeringDB profile for ASN 63199 is another strong industry signal. It lists network id 8581 under the exact name CDS Global Cloud Co., LTD, classifies it as an NSP, marks its general peering policy as Open, gives AS-CAPITALONLINEDATA as the IRR AS-set, and reports 200 IPv4 prefixes and 10 IPv6 prefixes. The profile was updated on 12 June 2026.

PeeringDB is self-maintained, so these fields are not an independent audit. The difference between the profile's prefix figures and the 547 prefixes returned by RIPEstat is not necessarily a contradiction: the sources have different definitions, observation methods and update times. It is, however, a reason not to turn either number into a simple measure of scale. A buyer should ask which prefixes are relevant to the proposed service and then observe those prefixes directly.

The network's exchange distribution is substantial on paper. The PeeringDB API returned 26 operational exchange attachments, including IX.br Sao Paulo, DE-CIX Frankfurt, Equinix exchanges in Singapore, Hong Kong, Dallas and Miami, HKIX, SGIX, BBIX in Singapore and Tokyo, JPNAP Tokyo, FL-IX and IIX-Jakarta. This list supports a geographically distributed interconnection presence across the Americas, Europe and Asia.

The facility API also returned 26 attachments across the United States, Germany, Korea, Brazil, Singapore, Hong Kong, Japan, mainland China and Taiwan. Named examples include Equinix DA1, Equinix SG3, Equinix TY4, Equinix HK2, Digital Realty LAX, DataBank sites in Dallas and Miami, Chief Taipei, KINX Seoul and Capital Online sites in Beijing.

Neither list proves how a customer service is built. An exchange attachment does not disclose which peers exchange traffic there, how much capacity is provisioned, whether a session is currently active, or which route is preferred. A facility attachment does not prove that Global Cloud Co., Ltd owns the facility, controls a particular room, maintains a specific amount of equipment, or can restore a service within a stated time. "Operational" is the state of the PeeringDB attachment, not a warranty for every circuit sold from that location.

For procurement, the useful move is to convert the broad footprint into a proposed path. Which listed exchange or facility is the actual handoff? Is the customer buying internet transit, private transport, a virtual connection or a combination? Where does the service cross from the customer's access circuit into AS63199? Which segment can reroute, and which segment is fixed? Public attachment records help test the answer, but they do not supply it.

Geography has to become a route sequence

The company location list and the PeeringDB attachment lists overlap, but they are not the same kind of record. Company pages describe markets where CDS Global Cloud says it operates or offers services. PeeringDB describes where the AS63199 network profile reports exchange or facility presence. Overlap in the United States, Germany, Singapore, Hong Kong, Japan, mainland China, Taiwan and Korea strengthens the case that the marketed geography has an interconnection counterpart. It does not establish that every product is available at every listed point.

The differences are equally informative without being contradictions. The company location page names Indonesia, Vietnam and the Netherlands, while the selected PeeringDB facility examples and attachment-country summary in the sources reviewed here do not prove an AS63199 facility presence in every one of those markets. PeeringDB, meanwhile, reports Brazilian attachments, including IX.br Sao Paulo, within the network footprint. One source may describe a serviceable location, another an exchange port or facility, and neither is a complete product matrix.

A customer route should therefore be written as an ordered sequence rather than drawn as a cloud over a world map. A notional sequence might name the customer access location, the provider handoff, the autonomous system carrying the internet segment, the exchange or private-network transition, the cloud on-ramp and the destination region. The point is not to assume that this is how CDS Global Cloud builds every service. It is to require the commercial design to disclose its own sequence.

That sequence makes geographic claims falsifiable. If the route is sold through Singapore, the design can identify whether the relevant presence is at an exchange such as SGIX or at a facility such as Equinix SG3, and whether either is merely near the path rather than on it. If the route is sold through Hong Kong, HKIX, an Equinix exchange attachment and Equinix HK2 are distinct records; they should not be merged into one vague Hong Kong node. The same applies to Tokyo, where JPNAP Tokyo, BBIX Tokyo and Equinix TY4 represent different interconnection or facility references.

The Americas and Europe need the same specificity. DE-CIX Frankfurt, FL-IX, Equinix Dallas, Equinix Miami and the DataBank or Digital Realty facility examples demonstrate reported points of presence, not an end-to-end path. A proposal that names Frankfurt and Dallas should say whether traffic exchanges there, is merely handed through a facility there, or reaches those markets over a private GPN segment. Otherwise, a footprint list can appear to answer a route question while leaving every routing decision unstated.

This route-sequence approach also disciplines redundancy claims. Two city names are not necessarily two independent paths; two exchange names are not necessarily two independent access circuits; and two AS numbers named by the company are not independently verified equivalents in the external records reviewed here. Diversity can be assessed only after the shared segments, providers, handoffs and control systems are shown. The GPN page's carrier, line and route diversity claims identify the intended property. A customer-specific topology and failover result are needed to demonstrate it.

China optimization is a route design, not a universal property

The company's own product pages make China access central to the offer. The Global Private Network, or GPN, page describes a fully meshed Layer 2 network linking China, Asia Pacific, North America and Europe. It claims carrier, line and route diversity and presents the service as a base for WAN backbones, point-to-point Ethernet, IEPL, SD-WAN, EVPL/VPL and enterprise VPNs. This is an architecture description from the provider, not a customer topology or a failover test.

The Premium Internet Routing, or PIR, page describes optimized IP transit through AS63199. It says the network peers with more than 200 global carriers, including China carriers, and advertises a 99.9 percent service level for users in China accessing servers outside the country. It also offers Mbps or usage-based pricing and says customers can burst up to 10 Gbps. No independent source listed below measures the carrier count, capacity or service-level performance, and the public record contains no contract text showing the measurement point, exclusions, credits or remedy.

The BGP service page separates an AS38353 China Blended IP Transit proposition from a Global BGP proposition. It names China Telecom, China Unicom, China Netcom and CERNET for the blended service, and names PCCW, NTT, TATA, Zayo, Level 3 and HE for international connectivity. These are provider statements. No independent source listed below confirms current sessions or commercial contracts with those named networks.

This analysis makes no separate claim about ChinaConnect. The public sources below do not provide a specific ChinaConnect product fact to evaluate, so the name cannot be used here as evidence for another route, licence, capacity pool or operating model.

Global DIA is positioned differently again: as a dynamic-routing underlay for enterprise cloud applications involving mainland China. The page presents a Shanghai SmokePing comparison in which regular DIA averaged 20.97 percent packet loss over ten days, and it says Global DIA is restricted to enterprise use. A provider-selected example can illustrate the problem the product is intended to address. It cannot be generalized to all ordinary DIA services, all locations, all dates or the path a new customer will buy.

The practical lesson is that "China optimized" is not a property that can be established by a brand name. It has to be resolved into route and service decisions. A credible design should identify the origin and transit AS for each direction, the ingress and egress locations, the traffic-engineering controls available to the customer, the failover route, and the metrics observed at the customer's endpoints. It should also say whether AS63199, the company-claimed AS38353, or another carrier is responsible at each segment.

Only then can the buyer test the claim against the public record. If a proposed path is said to use an exchange where AS63199 has no documented attachment, that does not automatically make the design false, but it creates a clear request for additional evidence. If an exchange is listed, that does not automatically make the customer path true. Presence and path are separate proofs.

CloudConnect moves the handoff; it does not remove the chain

CloudConnect extends the same question into cloud on-ramps. CDS Global Cloud says it uses Equinix Cloud Exchange for direct access to multiple clouds across multiple networks and resources, with GPN providing on-demand global connectivity. The description suggests a route that can avoid some ordinary public-internet segments. It does not identify which customer site can reach which cloud region over which physical and logical chain.

For an enterprise, the service boundary could include a local access circuit, a GPN segment, an exchange virtual circuit, a cloud-provider port and routing on either side of the handoff. Each boundary can have a different owner, capacity commitment, monitoring system and support queue. Calling the combined product a direct cloud connection does not consolidate those responsibilities unless the contract does so explicitly.

This is where cloud-service dependency becomes measurable. The buyer should request the service identifiers and demarcation points for every segment, the committed and burst rates, the routing mode, the cloud-side account and port dependencies, and the failover design if the Equinix Cloud Exchange path is unavailable. It should also establish whether the provider monitors the end-to-end service or only the portion under its direct control.

The question is not whether CloudConnect or GPN can be useful. The public pages describe plausible interconnection components, and the PeeringDB record gives AS63199 presence in several of the markets named by the company. The question is whether the offered combination has been reduced to a testable path for the customer's actual sites and cloud regions.

Three service shapes require three different proofs

The product pages suggest several ways an enterprise might reach an application. They should not be evaluated with one generic connectivity checklist because the relevant control points differ. Three service shapes are enough to show why.

The first is an internet-routed service built around PIR or Global BGP. Here AS63199's public visibility is directly relevant. The buyer can observe the origin and AS path for agreed prefixes, compare forward and return observations, and test what happens when the preferred route changes. The remaining proof is commercial and operational: which advertised service objective applies, where it is measured, whether burst capacity is included during a fault, and which routing changes the customer may request.

The second is a private GPN segment connected to a cloud on-ramp through CloudConnect and Equinix Cloud Exchange. Public BGP observations may show only the internet-facing portions, if any, and may say little about the private Layer 2 segment. The proof has to move to circuit identifiers, virtual connection state, port capacity, demarcation points and a test of the alternate design. A broad AS footprint is supporting context, not a measurement of the private service.

The third is a China-facing blended or optimized route involving a company-claimed AS38353 segment and a global AS63199 segment. The company's BGP page provides the product distinction, but the external records reviewed here independently verify only AS63199. The buyer would need a design that identifies where the autonomous-system boundary occurs, which named carrier relationships are relevant, and how routing, support and legal responsibility pass between the segments. Without that map, the two-AS description can create the appearance of a joined service without showing how it is joined.

These models may be combined in an actual proposal, which increases rather than reduces the need for clarity. A customer could have private transport to a hub, internet routing for a backup path and a cloud-exchange virtual circuit at the destination. Each segment may be technically sound while the end-to-end recovery plan remains incomplete. The acceptance record should therefore test both segment health and the transitions between segments.

Service shape to test	Public evidence that helps	Customer-specific proof still needed
PIR or Global BGP over AS63199	ARIN identity, RIPEstat routes and neighbours, PeeringDB exchange distribution	Offered prefixes, expected paths, policy controls, measurement point, capacity and remedy
GPN plus CloudConnect	Company GPN and CloudConnect architecture claims, relevant PeeringDB presence	Circuit and virtual-connection identifiers, demarcations, committed capacity and failover test
China Blended IP Transit linked to global routing	Company distinction between AS38353 and Global BGP; independently visible AS63199 surface	External closure for the AS38353 segment, carrier/session evidence, inter-segment responsibility and legal mapping

The evidence request should match the service shape rather than ask the provider to prove everything with a single network diagram. A current BGP capture is useful for the routed model. It cannot prove private-circuit capacity. A virtual-connection screenshot may help establish a cloud on-ramp. It cannot prove the China access path. A licence document may support a legal position. It cannot prove route performance. Keeping the proofs separate makes the final dependency chain easier to audit.

The company's scale claims describe products, not a reconciled inventory

CDS Global Cloud presents several overlapping measures of reach. Its home page says it has more than 10 full-service data centers globally and more than 50 satellite locations in mainland China. The locations page lists China, the United States, Singapore, Indonesia, Vietnam, Japan, Germany, Hong Kong, Taiwan, the Netherlands and South Korea. It describes 10 key data centers in Beijing, additional locations in Guangzhou, Shanghai, Wuxi and Wuhan, and more than 50 mainland satellite centers.

The Enhanced Internet page uses a much larger product-coverage vocabulary: more than 50 countries, 89 cities, more than 400 carriers, nearly 100 dedicated submarine cables and 94 data centers. It describes GPN and cloud-exchange connectivity as components of the service. The About page adds claims that AS63199 and AS38353 carry petabytes of data over 10G and 100Gb private backbone links across data centers worldwide.

All of those figures come from the company. They may refer to different things: owned or operated sites, partner availability, carrier reach, serviceable markets, network links or product endpoints. The public evidence does not reconcile the categories, audit the counts or show how they map onto the 26 PeeringDB facility attachments. It would therefore be unsafe to combine them into a single estate number or to assume that every named site offers the same products and capacity.

This ambiguity also affects economics. A PIR offer priced by committed Mbps is not economically equivalent to usage pricing with burst, and neither is automatically comparable with a private GPN circuit or a CloudConnect virtual connection. A meaningful quote should identify the route class, handoff, committed rate, burst rule, metering interval, overage treatment, installation charges and failover capacity. The public pages establish that several pricing and product forms are marketed. They do not provide enough detail to compare a customer's total cost or the cost of a degraded backup path.

Rather than asking for a bigger global number, a buyer should ask for a smaller, service-specific schedule. Which locations participate in this design? Which are direct Global Cloud Co., Ltd service points and which involve partners? What capacity is committed at each handoff? Which alternative path is reserved, and is it priced and tested at the same level? That schedule would connect the product vocabulary to an operational and economic boundary.

Compliance positioning must be mapped to the actual circuit

The company's legal-compliance page says CDS Global Cloud is licensed in mainland China for domestic landline data transmission, IDC service, CDN, domestic VPN and ISP service. It frames cross-border services around MIIT No.32 and No.2496 and CDTIA convention requirements. In the sources reviewed here, those are company-authored legal and regulatory statements. There is no regulator source independently confirming the scope, holder, validity or applicability of the stated permissions.

That does not make the page irrelevant. It identifies the compliance framework the provider says it uses and gives a buyer concrete items to verify. The contracting entity, licensed entity, access carrier, domestic service, cross-border segment and cloud endpoint should be named for the proposed design. The buyer can then ask for the licence identifiers and counsel's explanation of how each service segment fits the stated framework.

The public routing footprint cannot answer those questions. An ARIN registration for AS63199 proves neither a mainland China licence nor the legal treatment of a cross-border circuit. A PeeringDB attachment in Hong Kong, Singapore or mainland China does not determine the regulatory status of traffic that traverses it. Likewise, a provider's compliance positioning does not guarantee a compliance outcome for a customer's application, data, users or chosen route.

The safe conclusion is procedural: the service design and the compliance analysis should describe the same path. If the route diagram, bill of materials, legal entities and licence explanation use different boundaries, the claim has not been closed. Global Cloud Co., Ltd may be able to supply the required evidence, but the public sources listed below do not contain it.

Local support labour is an unexposed part of the service

The network records are unusually visible; the operating labour is not. The public sources reviewed here do not establish the size or location of the network operations team, its languages, shift coverage, escalation authority, on-site response arrangements or customer-specific restoration process. PeeringDB facility attachments and company location claims cannot fill that gap.

This matters most when the design crosses organizations and time zones. An alarm may be visible to one operator while the affected access circuit belongs to another. A cloud virtual connection may be healthy while the route feeding it is impaired. A customer can receive a ticket response without the responder having authority to change routing or dispatch work at a handoff site. None of those outcomes can be predicted from a list of exchange attachments.

The procurement test should name people and powers, not merely channels. Which team owns the end-to-end incident? Which team can alter BGP policy? Who contacts an access carrier or exchange partner? Which support hours apply in mainland China and at the remote cloud region? What evidence will be shared during an incident, and when does escalation move from monitoring to a path change? If a service-level commitment is missed, what clock and measurement source govern the remedy?

These questions are not evidence that Global Cloud Co., Ltd lacks support capacity. They identify a material unknown in the public record. A buyer can close it with a support schedule, escalation matrix, sample incident report and a witnessed failover exercise tied to the proposed service. Without those artefacts, a globally visible AS and a wide facility list still leave the human control surface undefined.

Evidence should survive the sales process

An enterprise route is likely to change over the life of a contract, while a sales diagram can remain frozen. The acceptance process should preserve enough evidence to tell the difference between an expected change and a material departure from the offered design. That does not require every routing update to become a contract amendment. It requires a baseline that names what matters.

For the AS63199 service surface, the baseline can include the agreed prefixes, representative route observations from customer-relevant locations, the primary and alternate ingress or egress, and the date of capture. For a PeeringDB-supported handoff, it can include the exact exchange or facility named in the design and clarify whether the record is evidence of presence, the actual handoff, or simply a nearby interconnection option. For GPN or CloudConnect, it can include circuit and virtual-connection identifiers without pretending those private components are visible in public BGP.

Service review should then focus on changes with customer impact. A new observed neighbour is not automatically a problem, and a disappeared neighbour is not automatically a breach. A different path that still meets the documented service objective may be ordinary engineering. But a move that changes the legal entity, removes the promised diversity, reduces committed capacity or shifts the handoff outside the agreed support model deserves explicit review. The contract should identify who has enough evidence to make that determination.

Incident evidence should use the same baseline. Route captures, alarm times, provider actions, partner escalations and customer-visible effects can be assembled against the named service segments. This avoids a common evidentiary gap in which the provider reports that its core network was healthy while the customer reports an unreachable application, with neither statement identifying the failed boundary. Segment-level proof makes both claims testable.

The public sources already provide a durable starting record. ARIN identifies the network and organization, RIPEstat captures a dated routing view, PeeringDB records a dated industry footprint, and company pages define the marketed service concepts. Preserving the customer-specific additions would turn that public record into an operating dossier rather than a one-time procurement presentation.

A customer-specific proof should connect six layers

The available sources support a disciplined pre-contract test. Each layer has public evidence, but each also has a boundary the public evidence cannot cross.

Layer	What the public record supports	What remains to be proved for the service
Identity	ARIN binds AS63199 and `CDSC-AS1` to CDS Global Cloud Co., Ltd; ARIN also records the `CDSC-1` organization and IPv4 allocation.	The exact contracting and operating entities for every service segment.
Routing	RIPEstat shows AS63199 announced, broadly visible and associated with hundreds of observed prefixes and neighbours.	The customer's forward and return paths, route policy, traffic-engineering controls and failover behaviour.
Interconnection	PeeringDB lists an open-policy network profile plus 26 exchange and 26 facility attachments.	Active sessions, usable capacity, actual handoff sites and the role of each partner in the sold path.
Product	Company pages describe GPN, PIR, Global DIA, Enhanced Internet, CloudConnect and BGP propositions.	A route-level design, measurable service objectives, exclusions, remedies and capacity for the customer's endpoints.
Compliance	The company states a mainland China licence position and cites MIIT and CDTIA requirements.	Independent licence evidence and a legal mapping from the customer's application and circuit to the relevant permissions.
Operations	Company geography implies a multi-region service surface.	Named support ownership, escalation authority, local coverage, incident evidence and a tested recovery procedure.

A useful acceptance test would start before production traffic moves. The provider and customer could agree a list of prefixes and endpoints, capture baseline forward and reverse paths, test the primary and alternate route, record loss and latency at the application-relevant hours, and identify who acted at each transition. Commercial terms could then refer to those same measurements and demarcation points. This would not eliminate dependency, but it would make the dependency legible.

The test should also distinguish evidence types. ARIN and RIPEstat can independently corroborate identity and routing visibility. PeeringDB can corroborate industry presence while remaining self-maintained. Company pages can describe intended products and legal positioning. A contract, current route observation, capacity record or failover test is still needed for the customer-specific claims that none of those public sources can establish.

A visible network is the beginning of diligence, not its conclusion

Global Cloud Co., Ltd has a stronger public network case than a provider represented only by promotional cloud language. AS63199 has a registry-bound identity, a direct IPv4 allocation, current routing visibility and a geographically broad set of PeeringDB exchange and facility records. Those facts make the network observable enough for an enterprise to ask precise questions and compare answers with external data.

The same evidence also prevents an easy overclaim. It does not prove a customer's path, the commercial meaning of observed neighbours, current carrier contracts, available capacity, service-level performance, site ownership, support staffing, restoration authority or a compliance outcome. The company's GPN, PIR, Global DIA, Enhanced Internet and CloudConnect pages describe how it wants buyers to understand the offer; they are not substitutes for a customer-specific route and responsibility map.

The decisive procurement artefact is therefore not another global footprint figure. It is a joined-up schedule that names the AS and prefixes, primary and alternate paths, exchange or facility handoffs, cloud on-ramp, capacity and metering rules, support owners, service-level measurements, contracting entities and licence basis. That schedule can be tested against the public evidence before launch and again when routing changes.

AS63199 makes Global Cloud Co., Ltd visible. Whether that visibility becomes dependable China-to-cloud access depends on details that remain outside the public record. The provider should be asked to prove those details for the exact service sold, and the buyer should preserve the proof as part of the operating contract.

AS63199 makes Global Cloud Co., Ltd visible; the enterprise path still needs proof