Summary

  • CloudRadium(HK) is best read as a network-operations company, not a generic cloud label: the accepted public record is AS17476, PeeringDB presence, APNIC registration, observed prefixes, Hong Kong exchange participation and named facility footprints.
  • The commercial case depends on whether CloudRadium can make Hong Kong transit, DDoS mitigation and DCI changes auditable enough to reduce route risk, false blocking, cross-connect delay and escalation burden compared with direct carrier buying or self-managed routing.
  • The strongest evidence is the mix of official service claims and external routing records; the weakest point is that several capacity, protection and response metrics remain company-asserted unless a buyer verifies them in a service order, live route test and incident drill.

The record that matters

CloudRadium(HK) has a name that can sound broader than the evidence allows. It is not, on the public record available today, a hyperscale cloud platform with published compute regions, object storage classes, serverless runtimes or a long list of enterprise reference customers. It is a Hong Kong network-infrastructure operator whose visible surface is IP transit, anti-DDoS service, data-centre interconnection, colocation and the operational records around AS17476. That distinction matters because the value of this company is not proved by phrases such as carrier-grade, low latency or global backbone.

It is proved by whether a buyer can see an accepted route, a credible mitigation path, a usable cross-connect, a reachable NOC and a clean abuse contact when something changes.

The company is therefore being tested by an operating record, not by a capacity slogan. Its own pages say AS17476 runs IP transit, Anycast DDoS mitigation, DCI and a Hong Kong data-centre service. Its client announcements add dated network-change claims, including Hong Kong POP upgrades, GTT route integration and Frankfurt POP additions. PeeringDB identifies CloudRadium(HK) as AS17476, lists an open peering policy, records a 300G port at Equinix Hong Kong, and shows facilities in Hong Kong, Tokyo, Frankfurt and Los Angeles. APNIC whois identifies the autonomous system as CloudRadium (HK) Limited and records the abuse and administrative roles.

RIPEstat and other public BGP observers show the system announced on current collector snapshots, with a small set of originated IPv4 prefixes and two IPv6 /40s visible in mid-July 2026.

That is enough to make CloudRadium a serious subject for network buyers, but it is not enough to let the reader assume invisible capability. The public record does not prove every private path, every customer handoff, every DDoS rule, every inter-facility fibre route or every commercial SLA. It gives a buyer a starting surface: which ASN to inspect, which facilities to ask about, which upstreams and peers appear in routing databases, which contact roles exist, and which official claims must be tied to a live contract before they can be treated as delivery facts.

CloudRadium's accepted Hong Kong test is therefore practical. Can the company move a transit, DDoS or interconnection change into an accepted network state with the route, mitigation, facility, customer and escalation evidence intact? If the answer is yes, the service can remove operational risk from buyers that do not want to operate BGP policy, cross-connect ordering, DDoS steering and multi-carrier escalation on their own. If the answer is no, the buyer may be paying for vocabulary that still leaves the hard work inside its own network team.

Identity and boundary

The entity boundary is CloudRadium(HK), also surfaced publicly through crtech.hk and the PeeringDB name CloudRadium(HK). The company should be kept separate from the carriers, exchanges, facilities, customers and route collectors that appear around its network. China Telecom, China Mobile, China Unicom, NTT, GTT, Arelion, Tata, Lumen, Hurricane Electric, Equinix, MEGA-i, Digital Realty, CoreSite, Telehouse and other names in the evidence are not CloudRadium. They are upstreams, peers, carrier hotels, data-centre locations, route-adjacent institutions or market context.

They should not be converted into CloudRadium customers, exclusive partners or proof of private topology unless the public record says so.

This boundary is especially important because network operators often publish facility names, carrier names and backbone claims in ways that can be easy to over-read. A PeeringDB facility entry says an ASN reports presence at a facility. It does not, by itself, prove every cross-connect inside that building, every protected path, every service order, every customer VLAN or the commercial terms attached to a route. An official product page can say that a service supports 400G ports or DCI in three business days. That is a useful sales and engineering claim, but it does not replace a buyer's acceptance test.

A public BGP collector can show a prefix originated by AS17476. It does not show all private traffic engineering decisions, all customer routes hidden behind aggregates, or the failure handling inside the NOC.

For CloudRadium, the evidence boundary is therefore the difference between a plausible network service and a proved customer outcome. The company has a public ASN. It has a public website. It has an APNIC record. It has PeeringDB data. It appears in BGP observers. It publishes product claims for IP transit, anti-DDoS, DCI and Hong Kong data-centre service. It posts announcements about network additions. Those facts are enough to judge the company as a Hong Kong connectivity operator. They are not enough to say that any unnamed enterprise, platform, content network or host has received a specific performance result.

The right question is not whether CloudRadium can describe a modern network. It clearly can. The right question is whether its public surface gives enough evidence for a buyer to run due diligence. On that question, the answer is mixed but useful. The ASN, PeeringDB and APNIC records are strong identity anchors. The facility and exchange data give a concrete interconnection map. The company claims provide a technical design to test. The missing pieces are independent customer outcomes, contract-level SLAs, measured incident histories, and third-party validation of the larger capacity and mitigation assertions.

What AS17476 shows

AS17476 is the centre of the CloudRadium record. APNIC whois lists AS17476 with the as-name CHL-AS-AP and describes it as CloudRadium (HK) Limited in Hong Kong. The APNIC record includes maintenance entities, route maintenance, an IRT entity and an abuse mailbox. That is not glamour, but it is the foundation of operational trust. A network buyer needs to know who holds the ASN, where abuse is reported, which maintainer is responsible for route objects and whether the company can be found in the regional registry.

PeeringDB adds the interconnection layer. The CloudRadium(HK) network entry identifies AS17476, links the company website, lists the IRR as-set as APNIC::AS17476:AS-CUSTOMERS, marks the network type as a network service provider, gives a traffic level of 5-10Tbps, and describes traffic as mostly outbound. It records an open peering policy, no ratio requirement and no contract requirement. It also records a 300G operational connection at Equinix Hong Kong with IPv4 and IPv6 addresses, route-server peering enabled, and a set of facilities that includes Hong Kong, Tokyo, Frankfurt and Los Angeles locations.

The BGP observer picture is more conservative than the sales picture, which is normal and useful. RIPEstat's routing-status data for AS17476 on July 12, 2026 showed visibility from all listed RIS peers in both IPv4 and IPv6, with seven IPv4 originated prefixes and two IPv6 prefixes in announced space. BGP.tools showed CloudRadium as active under APNIC and visible with peers, upstreams and downstreams, while listing originated IPv4 and IPv6 prefixes. IPinfo showed CloudRadium as the registered name for AS17476 and listed visible IP ranges with RPKI-valid status for several ranges.

These records do not validate every commercial claim, but they do show that AS17476 is not merely a website label.

There is also a useful tension in the data. PeeringDB's self-reported traffic and prefix scale fields are much larger than the originated prefix count visible in route collectors. That does not automatically mean a problem. Transit networks may carry downstream customer routes, use aggregates, or report traffic scale rather than originated-resource scale. But the gap is a reminder that buyers should not substitute one metric for another. Traffic level, originated prefixes, announced customer routes, IX port speed, facility presence and upstream diversity all describe different things.

CloudRadium's value depends on how those pieces combine in a specific service order.

For a transit buyer, the clean test is straightforward. Ask for the exact ASN relationship, prefix acceptance rules, IRR and RPKI expectations, route limits, BGP community catalogue, maximum prefix settings, failover design, contact escalation and route-change acceptance evidence. The public record suggests CloudRadium has the basic assets for that conversation. It does not prove that every proposed customer route will be accepted safely, nor that every route will perform better than direct carrier procurement.

That proof has to come from controlled turn-up, route collector visibility, traceroute checks, looking-glass output where available, and a written change record.

Transit as an operating discipline

CloudRadium's IP transit offer is the least abstract part of the company because transit has a public language. The buyer announces prefixes through BGP. The provider accepts, filters and propagates them according to policy. Upstreams and peers see the route. Traffic enters or exits through selected paths. The customer monitors latency, loss, reachability and path choice. If something goes wrong, the record can usually be inspected through route collectors, IRR objects, RPKI state, traceroutes, NOC tickets and peer feedback.

CloudRadium's official pages assert a 10Tbps-plus backbone, 400Gbps per port, direct BGP peering toward China premium networks, low monthly commits, burstable service, BGP turn-up within one business day and NOC response targets. Its PeeringDB record is consistent with an operator that wants peering relationships rather than only retail connectivity. The facility list and 300G Equinix Hong Kong exchange entry show a real public interconnection footprint. But the useful editorial judgment is not that the highest number wins. It is that the transit service is only as valuable as the control plane around it.

For a Hong Kong buyer, CloudRadium's pitch is most plausible where the buyer wants a bundled route-management surface. A host, regional cloud platform, content platform, game service, SaaS operator or infrastructure-heavy enterprise may need China-facing path options, Hong Kong carrier-hotel access, regional diversity and DDoS handling without running every carrier relationship itself. In that case, CloudRadium can be judged as an aggregator of network operations: it combines transit, peering, facility access, NOC response and filtering into a single service path.

The risks are equally practical. A route leak can move traffic into the wrong path and damage reachability. A bad BGP announcement can expose prefixes too broadly or suppress them from important peers. A stale IRR object can make a legitimate customer route fail filtering. A missing or wrong RPKI ROA can turn a change into a rejected route. Upstream congestion can make a seemingly diverse network behave like a single bottleneck. An unclear escalation path can turn a minutes-long route fix into an hours-long outage. CloudRadium's marketing language cannot remove those risks. Its operating value is the discipline with which it narrows them.

The repeated task is therefore not "sell bandwidth." It is: receive a customer change, verify prefix ownership and route authorization, model the export policy, configure BGP safely, observe propagation, check reachability, document the accepted state and keep a rollback path. Each step has a failure mode. Each step also has a piece of evidence. CloudRadium's public claim of BGP community control, open peering and route security language is meaningful only if those steps are explicit enough for a buyer to supervise.

DDoS mitigation as routing control

DDoS mitigation is where the gap between vocabulary and operating record becomes most important. CloudRadium describes Anycast DDoS mitigation, near-source scrubbing, 8Tbps-plus capacity, L3/L4 effectiveness claims, BGP community self-service, always-on and on-demand options, blackhole controls, stateful packet inspection, rate limiting, signature matching and behavioural analysis. That is a coherent mitigation vocabulary. It maps to how many network-layer services work: traffic is steered to scrubbing points, bad packets are filtered, legitimate packets are forwarded, and the buyer's origin is shielded from the worst volume.

But DDoS mitigation is not automatically good because it is Anycast, large or automated. It is good when the right traffic is diverted, the wrong traffic is not, legitimate sessions survive, the origin is not saturated, and the buyer can understand why a rule fired. The important questions are operational. Which prefixes can be protected? How is traffic diverted? Which communities trigger mitigation or blackholing? How are thresholds set? What packet classes are filtered by default? What happens to GRE, UDP-heavy applications, gaming traffic, DNS, voice, VPNs or custom protocols? What evidence does the buyer receive after an event?

How does the provider avoid false blocking during flash crowds?

CloudRadium's public material provides enough detail to ask those questions, but not enough to answer all of them without a service-specific test. The company says the service can steer customer prefixes through its Anycast scrubbing network and give BGP community control. That would be valuable for technical buyers because it reduces ticket dependency for repeated actions. A network team could trigger mitigation, change blackhole behaviour or keep always-on filtering without waiting for a manual support chain. In a real attack, that kind of control can reduce minutes of confusion.

The risk is that self-service controls can also make mistakes faster. A wrong community can blackhole a prefix. A too-aggressive threshold can block legitimate traffic. A missed threshold can let an attack reach the origin. A broad rule can damage multiple services when only one path was targeted. A protection provider can also hide the evidence if its portal shows only "mitigated" while the customer needs packet classes, time windows, route changes, dropped traffic and caveats. CloudRadium's service should therefore be judged less by the existence of a mitigation label than by how cleanly it records cause, action and outcome.

The commercial value is strongest where the buyer lacks in-house DDoS engineering. A smaller host, SaaS platform, content network or enterprise with a Hong Kong edge may not want to build scrubbing relationships, route steering, detection thresholds and 24-hour incident handling. If CloudRadium can make the protection predictable, it reduces labour cost and operational risk. If the buyer already has mature DDoS contracts, multiple carriers, traffic-engineering staff and incident runbooks, the value is lower. Then CloudRadium must win on path quality, Hong Kong facility adjacency, China-facing route options, economics or speed of change.

DCI and the physical state of the network

Data-centre interconnection is the part of CloudRadium's pitch that turns the network from a routing abstraction into a physical service. The company says its DCI offer includes Hong Kong, Tokyo and Frankfurt; protected path as standard; 40Tbps scalable capacity; three-business-day delivery; 100G and 400G options; and 50ms failover. Its data-centre material says its Hong Kong facility can connect through 100-400G dark-fibre cross-connects to MEGA-i, Equinix HK1/HK2/HK3, China Mobile GNC and NTT TKO, with HGC, HKT and HKBN on site.

Those claims speak directly to a common buyer problem. Hong Kong infrastructure buyers often need more than a port. They need a route from a rack to a carrier hotel, a path between facilities, a known handoff, a cross-connect record, a protection state and a clear escalation line when the light level drops or a circuit fails. DCI is attractive because it can reduce the number of separate vendors a buyer has to coordinate. It is also dangerous because hidden physical dependencies can turn "redundant" into "shared conduit" or "fast delivery" into a paper promise waiting on a landlord, carrier or field team.

CloudRadium's public facility footprint makes the DCI pitch plausible. PeeringDB records AS17476 at Equinix HK1, HK2 and HK3, MEGA-i, China Mobile International GNC Hong Kong, Telehouse Hong Kong CCC and NTT Com Asia Tai Po, as well as Tokyo, Frankfurt and Los Angeles facilities. The company's own pages name Hong Kong's own-property data centre and interconnect paths to major carrier hotels. The official announcements in 2025 and 2026 describe Frankfurt additions and Hong Kong POP upgrades. That is a visible interconnection surface.

The acceptance test is still physical and procedural. A buyer should ask which facilities are actually available for its service, which side orders the cross-connect, who owns the cable, which demarcation point applies, whether the circuit is protected by true path diversity, what the light-level and handoff evidence looks like, how delivery dates are measured, and what compensation or escalation applies if a carrier hotel, landlord or third-party provider delays the work. "Three business days" is meaningful only if the scope is defined.

A prebuilt cross-connect inside a controlled facility is not the same as a new metro fibre build through a congested building chain.

DCI also changes unit economics. If CloudRadium can use existing presence and prearranged facility relationships, it may reduce lead time and coordination cost for buyers that need Hong Kong-to-carrier-hotel access. If a buyer already has its own cages, carrier relationships and optical transport contracts, CloudRadium must show that its bundled service is cheaper, faster or safer than simply ordering direct cross-connects. The right comparison is not only monthly recurring cost. It is the full cost of project management, engineering review, remote hands, optics, router ports, outage handling, field escalation and future upgrades.

Reliability versus capability

Network buyers should separate capability from reliability. Capability is the list of things a provider says it can do: 400G ports, Anycast mitigation, China-facing paths, DCI, open peering, remote hands, NOC response, cross-connects. Reliability is what happens when those things are stressed by a routing error, attack, fibre cut, upstream congestion, expired contact, maintenance window or customer mistake. CloudRadium's public material is rich on capability. The reliability record is less visible because incident history, customer service evidence and contracted SLA performance are not public in detail.

That does not make the company weak. It means the buyer's due diligence has to be active. For transit, reliability should be tested through route propagation, failover, path diversity, RPKI and IRR acceptance, maximum-prefix handling and after-hours support. For DDoS, reliability should be tested through a controlled mitigation drill, false-positive review, route-steering evidence, alerting time and event report quality. For DCI, reliability should be tested through handoff documentation, protection switching, remote-hands response, optical readings and demarcation clarity.

For abuse handling, reliability should be tested through the public abuse mailbox, response process and escalation path.

CloudRadium's public NOC claims are useful but not decisive. The company publishes NOC and peering contact addresses, refers to 24/7 monitoring and describes response targets. APNIC also publishes an abuse mailbox. Those are necessary signals. They are not proof that the buyer's incident will be solved quickly. A strong operator turns those contacts into a tracked event: time opened, first response, diagnosis, route or physical change, impact window, rollback and post-incident note. A weaker operator treats the mailbox as a front door while resolution depends on informal relationships.

This is where the company can create value through repeatability. The same patterns recur in network operations: add a prefix, adjust a route map, turn up a port, filter an attack, check a cross-connect, inspect packet loss, escalate to upstream, answer abuse, close a ticket. A provider that performs these tasks cleanly can save customers labour even without owning every physical or upstream dependency. A provider that performs them inconsistently pushes labour back to the customer, because the buyer must monitor, chase and verify every step.

The public evidence suggests CloudRadium has built the vocabulary and surface area for repeatable operations. The question a buyer must settle is whether the actual service process is equally mature. That can be settled only through test orders, change drills, route observation and incident exercises. A network buyer should require those tests before treating large capacity numbers as operational assurance.

Commercial pressure in Hong Kong

CloudRadium operates in a market where substitutes are real. A buyer can purchase direct carrier service from global transit providers. It can buy from a larger regional network. It can use hyperscale cloud connectivity for workloads that already sit inside AWS, Google, Microsoft or other cloud ecosystems. It can place equipment in established carrier hotels and manage its own BGP. It can buy DDoS mitigation from specialist security networks. It can use an Internet exchange route server for settlement-free reach where appropriate. CloudRadium has to beat at least some of those alternatives.

Its likely advantage is bundling and Hong Kong adjacency. A buyer that needs IP transit, DDoS mitigation, Hong Kong facility reach and possible China-facing route options may prefer one operator that can coordinate the pieces. The PeeringDB record and official pages show enough facility diversity to support that argument. The company can position itself as a practical network operations layer for buyers that do not want to manage every carrier, cross-connect and attack response separately.

The counterargument is that bundling can hide dependency. Direct carrier buying gives the customer clearer commercial control over each upstream. Self-managed routing gives the customer direct policy control. Hyperscale cloud connectivity can simplify application-side operations if the application already lives in that cloud. Specialist DDoS networks may have more mature reporting, larger tested footprints or better-known protection records. A regional network with a longer incident history may be easier for risk teams to approve.

CloudRadium must therefore show not just that it can provide a service, but that the combined service reduces total operational risk.

Unit economics turn on utilisation and supervision. A 400G-capable port is valuable only if the buyer can use it or grow into it. DDoS capacity is valuable only if the protected applications need it and the false-positive cost is controlled. DCI is valuable only if the inter-facility path removes enough delay, complexity or router spend to justify the recurring cost. NOC support is valuable only if it reduces the buyer's staff burden. The buyer should include engineering hours in the comparison, because a cheaper direct carrier link can become expensive if every change requires senior routing staff to manage.

CloudRadium's commercial case is strongest for infrastructure buyers that are large enough to care about BGP and attack handling but not so large that they already run a mature multi-carrier network team in every region. It is weaker for buyers that only need commodity bandwidth, a single cloud on-ramp, a simple rack, or a globally standardised procurement relationship. The service appears most useful when Hong Kong route state, DDoS posture and interconnection state need to be managed together.

Automation and supervision cost

The assigned technical question is whether CloudRadium can keep routes, mitigation policy, customer handoff and interconnection state coherent when traffic shifts or attacks occur. That is not only an engineering question. It is a supervision-cost question. Every network buyer has to decide how much work remains on its own staff after the provider is hired. A good provider reduces the customer's need to watch every route, chase every field order, write every filter and interpret every packet event. A poor provider adds another coordination layer without removing the hard work.

CloudRadium's public claims around BGP communities, self-service DDoS controls, open peering, route-security checks, NOC response and DCI delivery suggest an attempt to automate repeated tasks. The useful form of automation here is not artificial intelligence or generic orchestration. It is controlled network change. A prefix should move from request to validation to policy to propagation with evidence. A DDoS event should move from detection to diversion to filtering to report with evidence. A cross-connect should move from order to demarcation to light test to acceptance with evidence.

An abuse report should move from intake to ownership to response with evidence.

The failure modes are familiar. A route leak can expose paths that should not be exported. A bad BGP announcement can cause reachability loss. A DDoS false block can damage legitimate users. A mitigation miss can leave the origin saturated. A cross-connect delay can hold up a launch. Upstream congestion can make a multi-carrier promise feel narrow. An abuse-contact gap can create reputation or compliance risk. A monitoring blind spot can let customers discover outages before the provider does. Escalation ambiguity can make a fix depend on personal contacts rather than process.

Automation reduces these risks only when it is bounded. A BGP community catalogue should have clear meanings, safety limits and audit trails. DDoS thresholds should have override rules and event reports. Route filters should use RPKI and IRR data without blindly trusting stale entities. DCI delivery should use known demarcation and acceptance tests. Monitoring should alert both the provider and customer when a route, packet profile or physical link changes. NOC escalation should show who owns each incident state.

This is where CloudRadium can differentiate itself if the private service matches the public design. Many small and mid-sized infrastructure buyers do not want to hire rare senior routing staff for every region. If CloudRadium can package network control with enough transparency, it reduces labour pressure. If it keeps the controls opaque, buyers will still need the same senior staff to verify every change, which weakens the commercial case.

Upstream and facility dependency

CloudRadium's dependencies are not a flaw; they are the nature of the business. IP transit depends on upstream contracts, peering relationships, route filters, router capacity, optical transport, data-centre access and human escalation. DDoS mitigation depends on scrubbing capacity, detection rules, packet-processing infrastructure, route steering, telemetry and upstream cooperation. DCI depends on facilities, fibres, cross-connects, optics, demarcation points and maintenance windows. Colocation depends on power, cooling, access control, remote hands and physical security.

The question is whether those dependencies are visible enough to manage. The PeeringDB facility list is helpful because it places AS17476 at specific public locations. Official pages and announcements are helpful because they identify service scope and recent additions. APNIC and routing databases are helpful because they anchor the network identity. But dependencies can still be hidden inside private contracts.

A buyer should ask which upstreams are used for its traffic, whether CloudRadium has direct or indirect relationships for claimed paths, where protected DCI paths run, which facility operators can delay delivery, and what happens if one upstream withdraws capacity during congestion or attack conditions.

The Hong Kong context raises the stakes. Hong Kong is dense, carrier-rich and strategically important for regional connectivity, but density can create correlated risk. Multiple providers may share buildings, meet-me rooms, ducts, power systems or field-service bottlenecks. A buyer that needs true resilience should not accept facility names alone. It should ask for diverse physical paths, maintenance coordination, handoff diagrams and documented failover. CloudRadium's claim of protected DCI is meaningful only if the paths, demarcation and failure tests are clear.

Upstream dependency also affects pricing. A provider with good carrier relationships and enough committed capacity can resell or aggregate service efficiently. A provider under upstream pressure may pass congestion, cost increases or route-policy surprises to customers. Public BGP data can show visible neighbours, but it cannot reveal contract terms, utilisation, reserved capacity or priority during an attack. That is why capacity claims should be treated as claims to verify, not as final evidence.

CloudRadium's best answer is to make dependencies part of the service record. If a buyer can see route authorisation, upstream path options, IX peering state, facility handoff, DCI protection design, NOC ownership and abuse handling, the dependency becomes manageable. If those pieces are hidden behind sales language, the buyer has to assume more residual risk.

What buyers should test

A serious CloudRadium evaluation should start with route evidence. The buyer should confirm that AS17476 is the serving ASN for the ordered service, that the correct customer prefixes are accepted, that IRR and RPKI status match policy, that the advertised path appears in public collectors, that the maximum-prefix limit is safe, and that withdrawal or rollback works. The buyer should also ask for the BGP community guide and test harmless communities before relying on them during a live incident.

For DDoS mitigation, the buyer should run a controlled drill. The goal is not to create a damaging event. It is to check detection, diversion, communication and reporting. Which prefix is protected? How is traffic moved? How quickly does the NOC respond? Can the buyer trigger or stop mitigation? What does the event report include? How are false positives handled? What packet classes are visible? What happens when the attack target is a latency-sensitive service rather than a web endpoint?

For DCI, the buyer should ask for a service-specific map and acceptance pack. Which facility, rack or meet-me point is the demarcation? Who orders and owns the cross-connect? What optical levels were recorded? What path is primary and what path is protected? Is failover automatic, and has it been tested? What maintenance windows apply? Does three-business-day delivery apply to an existing prebuilt path or to a new build? Who is called when the facility operator and network operator disagree?

For NOC and abuse handling, the buyer should test the contact chain before an emergency. APNIC lists an abuse mailbox, CloudRadium publishes NOC and peering contacts, and the company says it has around-the-clock coverage. The buyer should open a non-urgent test ticket, confirm response quality, understand escalation tiers and agree on event severity. In a network incident, the human path can be as important as the BGP path.

For economics, the buyer should compare CloudRadium against direct carrier buying, specialist DDoS services, cloud connectivity and self-managed routing. The comparison should include not only price per Mbps or port speed, but also engineering time, incident time, cross-connect costs, router ports, optics, project delay, route-risk exposure and the cost of a false block. CloudRadium's commercial advantage exists only if it reduces the full operating burden.

Final judgement

CloudRadium(HK) has enough public evidence to be treated as a real Hong Kong network operator, not merely a service brochure. The AS17476 record, APNIC registration, PeeringDB data, Hong Kong exchange entry, facility list, official product pages and dated announcements together create a credible operating surface. The company is specifically relevant to buyers that need Hong Kong transit, DDoS mitigation, data-centre interconnection and facility-adjacent network service in one place.

The public record also forces a disciplined reading. Many of the largest numbers and fastest delivery claims come from the company itself. Public route observers validate that AS17476 exists and is visible, but they do not validate every private route, every DCI path, every mitigation outcome or every response target. PeeringDB validates self-reported interconnection data and facility presence, but it is not a substitute for a contract, a light test, a route acceptance note or an incident report. The evidence is strong enough to start procurement due diligence, not strong enough to skip it.

The core technical question has a conditional answer. CloudRadium appears to have the ingredients to keep routes, mitigation policy, customer handoff and interconnection state coherent: ASN identity, registry records, peering data, facility presence, BGP community language, DDoS steering claims, DCI protection claims and NOC contacts. Whether it actually does so for a specific buyer depends on service-specific evidence. Buyers should require route snapshots, mitigation drill results, DCI acceptance records and escalation tests.

The core commercial question is similarly conditional. Hong Kong transit, DDoS and DCI services can reduce operational risk enough to beat direct carrier buying, hyperscale connectivity, self-managed routing and competing regional networks when the buyer values coordination, speed and reduced staff burden. They do not automatically win when the buyer only needs commodity capacity or already controls a mature multi-carrier network. CloudRadium's value is not "more cloud." It is the possibility of a cleaner operating record across BGP, filtering, cross-connect and NOC action.

That is the right way to judge the company. CloudRadium(HK) is tested by accepted interconnection and mitigation evidence. Route state, filtering decisions, cross-connect state and escalation history decide the value. The public evidence is concrete enough to make the test worthwhile, and limited enough that a serious buyer should still insist on proof before trusting the service under traffic shifts or attack pressure.