Rackspace IT Hosting AS IT Hosting Provider Hong Kong sells hosted capacity that still depends on racks, transit and repair windows

Summary

• Rackspace IT Hosting AS IT Hosting Provider Hong Kong maps to AS45187 in APNIC and RIPEstat public records. APNIC's RDAP record names Rackspace.com Hong Kong Limited as the registrant organization, and RIPEstat labels the holder "RACKSPACE-AP - Rackspace IT Hosting AS IT Hosting Provider Hong Kong."
• The route surface is materially visible. RIPEstat's routing-status snapshot for AS45187 showed 13 IPv4 prefixes, 2 IPv6 prefixes, 66,816 IPv4 addresses, full observed RIS visibility for both address families, and 23 observed neighbours. The announced-prefixes view listed active prefixes including 119.9.64.0/19, 119.9.96.0/19, 120.136.32.0/20, 180.150.128.0/19, 202.168.208.0/21, 203.60.0.0/17, 2401:1800::/32 and 2407:fa00::/32.
• PeeringDB adds facility and interconnection context rather than a capacity guarantee. It lists "Rackspace Hong Kong" for AS45187, an open policy, 100 IPv4 and 10 IPv6 informational prefix counts, two 10G exchange entries at Equinix Hong Kong and HKIX, and one facility entry at MEGA-i in Hong Kong.
• Rackspace's own HKG1 and HKG5 pages make the physical dependency visible. HKG1 is described in Tsuen Wan with UPS modules, dual 11kV feeds and redundant network components; HKG5 is described in Tseung Kwan O with 917 sq m of dedicated data-center space, 13.5 MW utility power, 7.2 MW UPS capacity, seven fibre carriers, 10G per carrier, BGP multipath route optimization and a stated split where customers retain admin control of leased servers while Rackspace controls networking hardware.
• The evidence grade is Strong for public network identity and Hong Kong operating evidence, but not a blank cheque for every hosted workload. Customers still need service-specific proof of placement, redundancy, restore times, ticket escalation, maintenance exclusions, spare-parts access, RPKI status, contract boundaries and exit paths.

The useful question is no longer whether Rackspace exists in Hong Kong

Some infrastructure profiles begin with a thin name and a faint ASN. This one does not. The public record around Rackspace IT Hosting AS IT Hosting Provider Hong Kong is thick enough to move the investigation past existence and into dependency. APNIC's RDAP autonomous-system record identifies AS45187 as RACKSPACE-AP, with country HK and Rackspace.com Hong Kong Limited as the registrant organization. RIPEstat's AS overview uses the holder label "Rackspace IT Hosting AS IT Hosting Provider Hong Kong" and marks the ASN as announced. That pairing is stronger than a scraped hosting directory entry or a stale company page.

The route evidence is also current enough to matter. RIPEstat's routing status for AS45187 showed IPv4 and IPv6 visibility across all observed RIS peers at the snapshot time, 13 IPv4 prefixes, 2 IPv6 prefixes and 23 observed neighbours. The announced-prefixes dataset listed 15 current prefix rows. Those include two large IPv6 aggregates, 2401:1800::/32 and 2407:fa00::/32, and IPv4 routes such as 119.9.64.0/19, 119.9.96.0/19, 120.136.32.0/20, 122.200.132.0/22, 180.150.128.0/19, 202.168.208.0/21 and 203.60.0.0/17. This is not a one-prefix vanity network.

Rackspace's public facilities material makes the subject even less abstract. Rackspace's HKG1 data-center page places one Hong Kong facility in Tsuen Wan and describes power, cooling, security, connectivity and guarantees. Its HKG5 page places another in Tseung Kwan O and goes further, listing 917 sq m of dedicated data-center space, 13.5 MW total utility power, 7.2 MW UPS power capacity, seven fibre carriers to the site and BGP multipath route optimization. The existence question is therefore settled enough for procurement work. The open question is whether a particular customer's hosted service has the same resilience as the published footprint suggests.

That distinction matters because "Rackspace" is a large brand, "Hong Kong" is a market label, AS45187 is a network boundary, and a customer workload is a contract-specific deployment. A buyer can see public number resources and Rackspace's facility claims, but the buyer cannot infer which hall, rack, carrier, VLAN, backup system, support team or maintenance calendar applies to its own environment. A well-supported facility page should make the review stricter, not lazier.

AS45187 is a real operating edge, but the registry does not show every service

The APNIC and RIPEstat records show a coherent identity. The RDAP record gives a registration date in December 2014 and a last-changed date in July 2020. RIPEstat's whois-derived view records the aut-num as 45187, the as-name as RACKSPACE-AP, the description as Rackspace IT Hosting AS IT Hosting Provider Hong Kong, and the country as HK. It also shows older import and export policy lines naming AS3491, AS1239 and AS2914, plus Rackspace route-maintenance contacts. Those details are useful because they tie the number resource to Rackspace's Hong Kong entity and to a long-running routing administration record.

They are not enough to define the product. AS45187 may carry public cloud, managed hosting, dedicated server, colocation, storage, monitoring, control-plane, support or backbone functions in different ways. Some customer systems may be directly addressed from AS45187. Others may use provider-assigned addresses, private interconnects, cloud-provider addresses, or hybrid routes that do not appear as customer-visible origins. The registry can tell a buyer where to look. It cannot tell the buyer which exact product uses the route edge, which legal entity signs the contract, or which supplier is responsible for an incident.

The APNIC holder evidence is therefore best read as a responsibility map starter. If a customer is told that a Hong Kong workload is delivered from Rackspace infrastructure, AS45187 gives the customer a concrete network boundary to ask about. Which prefixes are in scope? Which are customer-facing, management-only, backup-only or legacy? Which route policies are live, and which are historical? Which prefixes have route-origin authorization, and which remain unknown to RPKI validators? Those are not academic questions. They decide whether a route leak, filter change, DDoS mitigation event or upstream outage can affect service.

The first caution is RPKI. The validation check used for this article on 119.9.64.0/19 through RIPEstat's RPKI validation endpoint returned unknown status rather than valid. The same status appeared for the prefix set checked from the announced-prefixes list. Unknown is not the same as invalid, and it does not mean the network is failing. It does mean route-origin authorization should be a live procurement question, because networks that enforce Route Origin Validation treat valid, invalid and unknown routes differently. For a customer that depends on a stable Hong Kong edge, "unknown" should lead to a discussion of ROAs, route filters, contact procedures and change-control ownership.

Rackspace publishes two different kinds of Hong Kong facility evidence

Rackspace's Hong Kong facility pages are unusually concrete compared with many regional hosting profiles. HKG1, described at Rackspace Technology Data Centers: Hong Kong (HKG1), is placed in Tsuen Wan. The page states that the Hong Kong facilities are staffed by system-engineering professionals who manage and maintain systems 24x7x365. HKG1's listed physical claims include 400 KVA UPS modules in N+1 configuration, 30 minutes of battery backup time, dual 11kV power supply from separate HKE zone substations, dual power supply risers, multiple generator sets and a carrier-neutral facility fed by dual telecom connections.

HKG5, described at Rackspace Technology Data Centers: Hong Kong (HKG5), is placed in Tseung Kwan O and exposes a different set of specifics. It lists 917 sq m of dedicated data-center space, 13.5 MW total utility power, 7.2 MW UPS power capacity, diesel generators with 2.25 MW capacity each, 12,000 litre fuel tanks, more than 1 MW of cooling capacity, seven carriers providing fibre connectivity to the site, 10-Gigabit Ethernet per carrier, redundant Cisco and Arista routers, and BGP multipath route optimization. It also states that customers retain administrative control of leased servers while Rackspace retains control of networking hardware.

Those claims have operational meaning. They say Rackspace is not merely reselling an anonymous cloud region under a Hong Kong label. They point to physical plant, network design, support staffing and control boundaries. But they should still be converted into service-specific evidence. "HKG5 has seven carriers" does not by itself prove that every customer service has seven active, default-capable, paid and provisioned paths. "BGP multipath route optimization" does not prove route diversity all the way to a customer's application, storage tier or management console.

"Customers retain admin control" does not prove a customer can recover the service if the network hardware, portal, support queue or billing state blocks access.

The facility pages are strongest where they name physical inputs. Power feeds, UPS capacity, generator fuel, carrier count and router families are all real things a buyer can ask to see in a service design. The pages are weakest where they are necessarily general. They do not publish cabinet assignments, customer placement, patch panels, private VLAN maps, storage topology, backup geography, spare-parts bins or the queue depth of the technicians who would be called during an incident. The procurement task is to bridge that gap without pretending the public facility page already did it.

PeeringDB confirms interconnection signals, not customer placement

PeeringDB's network API for ASN 45187 lists one network object named Rackspace Hong Kong. The fields show an open general policy, an IRR AS set of AS-RACKSPACE, informational prefix counts of 100 IPv4 and 10 IPv6, IPv6 support, an IX count of 2 and a facility count of 1. PeeringDB is a voluntary directory, so none of those fields is a certification. Even so, the entry is valuable because it ties AS45187 to an interconnection posture that can be compared against route collectors and Rackspace's facility statements.

The PeeringDB netixlan records list two operational exchange-facing entries: Equinix Hong Kong and HKIX: HKIX Peering LAN. Both show 10,000 Mbps speed. The Equinix Hong Kong row lists IPv4 address 36.255.56.87 and IPv6 address 2001:de8:7::4:5187:2. The HKIX row lists IPv4 address 123.255.90.101 and IPv6 address 2001:7fa:0:1::ca28:a065. The PeeringDB netfac record lists MEGA-i (iAdvantage Hong Kong) in Hong Kong as the facility entry for the network object.

Those rows create a useful tension with Rackspace's own HKG1 and HKG5 pages. Rackspace publishes facility pages for Tsuen Wan and Tseung Kwan O, while PeeringDB exposes one network-facility entry at MEGA-i and exchange attachments at Equinix Hong Kong and HKIX. There is no contradiction unless someone tries to make one record do more than it can. PeeringDB may describe interconnection presence rather than customer compute placement. Rackspace's data-center pages may describe hosting facilities rather than every exchange or cross-connect location.

A customer needs the map that links these layers: where the server sits, where the edge router sits, where exchange peering happens, where transit enters, and where the customer has contractual rights.

The immediate operational lesson is that facility count is not the same as redundancy. One PeeringDB facility row can coexist with multiple Rackspace-operated or Rackspace-marketed sites. Two exchange-facing ports can improve reachability to selected networks without proving full transit diversity. A 10G exchange port can be useful for peering, but the surviving customer path during an outage may depend on paid transit, private interconnect, DNS, security filtering, load balancers, storage replication and support access. The public interconnection record gives the buyer names and addresses to test, not an end-to-end failover result.

The route surface is broad, but diversity still has to be proven twice

AS45187 has a visible neighbour set. RIPEstat's ASN-neighbours endpoint returned 23 observed neighbours. The list included large global networks such as AS174, AS3257, AS3300, AS3491, AS4637, AS6453, AS6939 and AS7473 on the left side, one right-side row for AS58982, and several uncertain rows. Public BGP cannot tell whether each adjacency is a paid upstream, a peer, a customer, an exchange route-server relationship, a temporary route leak artefact or a collector-side classification artefact. It can only tell us that the route edge is not invisible.

The older APNIC whois policy lines add another layer. They list imports from AS3491, AS1239 and AS2914 and exports to those ASNs. That is useful historical routing-administration evidence, but it does not automatically describe current traffic engineering. RIPEstat's current neighbour list includes some of those names indirectly and also shows others. A buyer should ask Rackspace for the current transit and peering design rather than relying on static whois policy text.

Diversity must be proven twice: once in routing, and once in physical operations. A network may have multiple BGP neighbours in public data while several paths share the same building, meet-me room, power domain, fibre duct, router pair or support queue. Conversely, a service may have strong private or supplier-side resilience that is barely visible in public BGP. The goal is not to punish Rackspace for hiding operational details; it is to avoid mistaking a public AS graph for a tested customer recovery design.

The better questions are layer-specific. Which AS45187 prefixes are originated from which Hong Kong edge routers? Which upstreams carry default routes for the service in normal operation? Which exchange sessions are settlement-free peering versus critical reachability? Which paths are diverse at the fibre entrance and building level? How much traffic can the remaining path carry at peak after one provider, one exchange, one router or one facility domain is removed? Public BGP can suggest where to ask. It cannot answer all of that by itself.

Rackspace sells abstraction, but the Hong Kong economics are still physical

Rackspace's managed hosting page frames the product in familiar enterprise language: managed dedicated hosting, single-tenant dedicated infrastructure, bare metal, databases, networking, storage, managed backup, disaster recovery, RackConnect and private cloud. The commercial promise is that Rackspace will convert physical complexity into a service. Customers buy performance, support and control without owning every router, power feed, storage array, cross-connect and maintenance process.

That bargain has real value, but it does not erase the underlying economics. Rackspace's colocation customer guide describes allocated billing by kilowatt for reserved redundant critical power, with separate monthly recurring fees for cross-connects and blended bandwidth where purchased. It also references one-time installation fees, power circuits, private cages, in-rack PDUs and cross-connects. This is the vocabulary of physical capacity. The cloud invoice still rests on power allocation, cabinet space, optics, remote hands, bandwidth commits and labour.

The Hong Kong pages make that visible. HKG5's 13.5 MW utility-power claim, 7.2 MW UPS capacity and seven fibre carriers are not marketing decoration. They are capacity inputs that can constrain or protect a customer. If rack density rises, if a customer needs more cross-connects, if a spare router is unavailable, if a carrier path congests, or if a maintenance window requires serial work, the customer experiences the physical estate through latency, ticket delay, migration limits or credits after downtime. Hosted capacity is bought as a service, but it fails as a chain of physical and administrative steps.

This is why "installed" and "usable" capacity must be separated. Installed capacity is what the published footprint appears to include: facilities, generators, UPS systems, carrier connections, routers, prefixes and support staff. Usable capacity is what remains for a customer after normal reservations, oversubscription, maintenance, customer-specific routing and protection domains are taken into account. Recoverable capacity is narrower still: the part that can be restored within the customer's required time after a component has failed. Public pages are good at installed capacity.

Customer assurance has to prove usable and recoverable capacity.

Control is split by design

HKG5's most important line may not be about megawatts or carrier count. The page says customers retain administrative control of leased servers while Rackspace retains control of networking hardware. That split is exactly what a managed hosting customer wants in normal operation: the customer can manage its workload, while the provider protects the shared network layer. During a failure, the same split becomes a boundary that has to be rehearsed.

If a leased server is healthy but unreachable, the customer's admin rights may not be enough. If a customer can log into a server over a VPN but not reach the public service, the network boundary matters. If a customer needs a route change, firewall rule, cross-connect ticket or hardware replacement, Rackspace's authority and queue become the pacing item. If the customer has a backup but cannot move enough data through the available path, the server-level control is insufficient. Shared responsibility is not a slogan here; it is the operational architecture.

The Rackspace colocation guide reinforces the same boundary. It describes implementation leaders, customer portal training, smart-hands requests, automatic ticket creation, alert monitors and a runbook. It says customers can interact by creating tickets through the Rackspace Customer Portal and can call the 24x7x365 support team. It also lists smart-hands tasks such as power-cycling devices, visual verification, cable testing, customer-provided hardware replacement, racking and un-racking, in-cabinet network cabling and hard-drive destruction. Those are the concrete actions that convert outage detection into repair.

For a buyer, the control question is simple: what can we do without Rackspace, what can Rackspace do without us, and what requires both parties to act in the right order? That question should be answered before production. It should be written in operational steps, not only in contract language. Which portal users have authority? Which phone number works if the portal is unavailable? Which route changes require a ticket? Which hardware actions are included? Which tasks are charged in 15-minute increments? Which tasks depend on parts supplied by the customer rather than Rackspace?

Repair windows are a product feature, not a footnote

Rackspace's data-center pages publish strong guarantees, but the details are important. HKG1 and HKG5 both include network, infrastructure and hardware replacement guarantee language. The network and infrastructure sections speak in terms of availability and credits, while the hardware replacement guarantee says replacement or repair of Rackspace-provided hardware or components will begin within one hour of problem identification, with credits if it does not. The wording "begin" matters. It is not the same as "complete," and it does not describe every customer-provided component.

The colocation guide's smart-hands table is more operationally granular. It shows HKG1 as having both a 1 hour response SLA and a 24 hour execution SLA for smart hands. The same guide gives estimated times for common tasks, such as 30 minutes for power cycling a router, server or switch, 60 minutes per three cables for testing cabling media, and 60 minutes for replacement of a customer-provided device that is not a hot-swap. It lists a smart-hands rate of US $46.25 per 15 minutes plus bill of materials. These are not trivial details. They show where the repair clock can move from abstract uptime to paid human work.

A customer should therefore separate three clocks. Detection time is how long it takes for monitoring to notice and classify a fault. Response time is how long it takes for Rackspace or the customer to accept ownership and begin action. Execution time is how long the repair actually takes, including parts, access, cabling, reboot, route change, storage rebuild and verification. Credits after downtime are commercially important, but they do not restore the workload. The resilience review should focus on measured restoration, not only on service credits.

The same logic applies to maintenance. Rackspace's guarantee language excludes scheduled or emergency maintenance. That exclusion is normal, but it matters in a hosted-capacity review. If one path or site is out for maintenance, the customer's real resilience is the capacity left in the non-maintenance path. If a customer needs a change during a provider maintenance freeze, escalation rules matter. If an emergency maintenance event touches a shared network component, the customer's admin rights may not help. Repair windows and maintenance windows are part of the product, not ancillary paperwork.

Route-origin security is the weak spot in an otherwise strong public footprint

The most obvious downgrade in the network evidence is RPKI status. RIPEstat reported the route surface clearly, and PeeringDB gave interconnection details, but the RPKI validation checks against the current prefix list returned unknown rather than valid in the sampling used here. Unknown status can exist for many reasons, including absent ROAs, validator coverage, timing or resource-management choices. It does not mean AS45187 is hijacking routes. It does mean the origin authorization layer is not as publicly strong as the BGP visibility layer.

For a hosted customer, that matters because origin validation is no longer exotic. RFC 6811 describes route-origin validation as a way to use the Resource Public Key Infrastructure to determine whether an AS is authorized to originate a prefix. APNIC's own RPKI material explains the resource-certification control in operational terms. A customer that depends on public reachability should care whether its provider's production prefixes are valid, unknown or invalid, and whether any customer-routed prefixes have correct ROAs before migration.

The practical question is not "does Rackspace know BGP?" The public neighbour set and facility claims suggest mature routing operations. The question is narrower: for the exact prefixes that carry the customer's service, are route-origin authorizations published and tested with major validators? If the customer brings its own address space, who creates and maintains the ROAs? If Rackspace assigns the address space, can Rackspace show the status and change-control process? If a prefix must be moved during an incident, what happens to the ROA and filter state?

This is one of the few public checks where the answer can be improved without revealing private facility detail. A valid ROA does not prove customer resilience, but it removes one avoidable failure mode. An unknown route can still work across most networks; it simply gives the buyer less assurance at the origin-validation layer. In an otherwise strong Rackspace Hong Kong record, that is exactly the kind of specific, fixable question that should not be lost under the weight of a large brand.

Data locality is not solved by the letters HK

The assignment's region is HK, APNIC lists AS45187 with country HK, Rackspace publishes Hong Kong facilities, and the PeeringDB record describes Hong Kong interconnection. Those are good locality signals. They still do not prove where a customer's data, backups, logs, support records, identity system, snapshots or recovery copies sit. In cloud and managed-hosting contracts, locality is a placement matrix, not a country code.

Hong Kong's privacy regulator makes that point in public guidance. The PCPD's January 2025 Guidance on Cloud Computing tells data users to consider where data is stored, the security measures in equipment, integrity and competence of people with access, secure transmission, processor contracts, retention controls and cross-border transfer implications. A PCPD case note on cloud systems outside Hong Kong states that the ordinance does not prohibit storing personal data in a cloud system outside Hong Kong, but data users must still comply with the PDPO and the Data Protection Principles. The PCPD's recommended model contractual clauses provide a contract framework for cross-border transfers.

For Rackspace Hong Kong customers, the consequence is practical. The customer should ask where primary data is stored, where snapshots are stored, where backups are stored, where management logs are stored, which support teams can access the environment, which subcontractors or partner clouds participate, and whether any normal support action transfers personal data outside Hong Kong. A Hong Kong route edge can coexist with non-Hong Kong support tooling, global identity systems, offshore backup copies or multi-cloud interconnects. None of that is necessarily improper.

It simply needs to be disclosed and tested against the customer's own regulatory duties.

Locality also interacts with recovery. A backup outside Hong Kong may improve resilience but change transfer analysis. A local-only backup may satisfy a residency preference but fail if the local facility suffers a regional event. A multi-site Hong Kong design may be better for latency and jurisdiction but more expensive and still dependent on common suppliers. The buyer needs the design, not the slogan.

Exit evidence is part of resilience

A hosted service is not fully resilient until the customer can leave it under pressure. Rackspace's documentation contains useful signs that some services expose export and migration paths. The Rackspace Cloud on OpenStack Flex handbook links to functions for creating virtual machines, block storage, object storage, image export, image import and migration planning. The exporting images guide describes exporting instance snapshots from an OpenStack Flex project. The Object Storage API guide explains that access requires Rackspace Cloud credentials, project details and API calls.

Those documents are not proof that every Hong Kong managed-hosting customer can perform a complete emergency exit. They are proof that exit should be discussed at the level of artifacts. Can the customer export VM images? Can it export block volumes? Are backups portable? Are network configurations, firewall rules, load-balancer settings, DNS zones, certificates, logs and monitoring history exportable? Does export work if the customer portal is degraded? Does it require a paid support engagement? Can it be tested without triggering a production change?

The physical layer reappears during exit. Large exports consume bandwidth and time. Cross-connect billing, transit caps, storage read rates, object-store credentials and support tickets all become part of the migration path. A customer that has never measured a full export may discover during an incident that "we can move" really means "we can start a long transfer after the provider approves the request." Exit planning is not hostility toward Rackspace. It is the honest end of a dependency review.

Rackspace's published infrastructure is strong enough that many customers will rationally choose not to run equivalent infrastructure themselves. That is the economic point of managed hosting. The danger is not using a provider; it is using one without preserving the evidence needed to move, restore or independently verify service when something goes wrong.

The corporate wrapper is useful, but local proof still wins

Rackspace Technology's broader corporate record helps explain why this Hong Kong profile should not be treated like a tiny regional host. Rackspace Technology, Inc. appears in SEC submissions as a Nasdaq-listed company under ticker RXT, and its 2025 Form 10-K gives investors the broader business and risk context around its cloud, hosting and services operations. Rackspace's own global data-center page presents a multi-market data-center footprint and says its facilities use redundancy across security, power, cooling and networks. Those facts reduce identity uncertainty and make the Hong Kong facility pages more credible than a standalone landing page would be.

They do not remove the need for local proof. A global company can still have a local facility constraint, a regional supplier dependency, a product-specific deprecation path, a customer-specific support tier or a private-cloud design that differs from the public facility page. The 10-K is also written for investors, not for a Hong Kong customer trying to know which cabinet, route, backup system and engineer will decide a Saturday outage. Public-company disclosure can describe business risks, revenue segments, debt, competition and operating assumptions. It cannot certify the recovery path of a particular AS45187 workload.

That corporate wrapper changes the assurance method. With a small unknown provider, the first task might be proving that the company and network exist. With Rackspace Hong Kong, the first task is aligning several public layers that are each real: APNIC's AS45187 identity, RIPEstat's current route evidence, PeeringDB's interconnection rows, Rackspace's HKG1 and HKG5 facility pages, Rackspace's managed-hosting and colocation documentation, and the customer's own contract. The risk is not that every layer is fake. The risk is that a customer assumes all layers apply to its service in the same way.

The buyer should therefore ask Rackspace to produce a local service annex. It should name the facility or facilities, the relevant ASNs and prefixes, the recovery site, the backup location, the support model, the maintenance exclusions, the RPKI plan, the data-location controls and the exit process. A global brand can make that annex easier to obtain. It cannot replace the annex.

What customers should test before trusting the Hong Kong edge

The first test is mapping. Ask Rackspace to map the service to AS45187, the facility or facilities, the production prefixes, the management paths, the backup paths and the support systems. Compare the ASN answer with APNIC RDAP, RIPEstat announced prefixes, PeeringDB's Rackspace Hong Kong record and Rackspace's HKG1/HKG5 pages. If the customer service does not use AS45187, that may be fine, but it should be stated plainly.

The second test is failure. Remove one upstream, one exchange path, one router, one storage component, one support portal, one customer credential and one maintenance domain in a tabletop or live exercise. Record what happens to reachability, console access, DNS, monitoring, backup, billing, ticketing and data export. The result should identify which part of the service is active-active, active-standby, backup-only or manual.

The third test is route security. Ask for RPKI status on the exact production prefixes, including any customer-owned prefixes. Ask how ROAs are changed during migration and who approves the change. Ask whether route filters are maintained for AS45187 and customer announcements. Public RPKI unknown status should not be treated as a scandal; it should be treated as an open control item.

The fourth test is support and repair. Use the colocation guide's smart-hands vocabulary to make the exercise concrete. Who opens the ticket? Who can call if the portal fails? Which tasks are included, charged or excluded? Which spare parts are Rackspace-provided, customer-provided or vendor-provided? Which HKG1 smart-hands SLA applies, and what is the equivalent for the exact HKG5 service? If a hardware replacement guarantee begins within one hour of problem identification, who identifies the problem and what marks the start?

The fifth test is locality and exit. Ask for the data-location matrix, including primary, replica, backup, logs, support records and identity. Ask for export evidence and a timed restore test. The PCPD material makes clear why those questions belong in a Hong Kong cloud discussion: the customer remains accountable for personal-data handling even when using a cloud provider or processor.

The evidence grade

Rackspace IT Hosting AS IT Hosting Provider Hong Kong earns a Strong public network evidence grade. That grade reflects identity and operating visibility, not an unlimited statement about every Rackspace service. APNIC ties AS45187 to Rackspace.com Hong Kong Limited. RIPEstat shows AS45187 as announced, with 13 IPv4 prefixes, 2 IPv6 prefixes, full observed RIS visibility at the checked snapshot and 23 observed neighbours. PeeringDB lists Rackspace Hong Kong with two exchange-facing 10G entries and a Hong Kong facility row. Rackspace publishes HKG1 and HKG5 pages with concrete facility, power, carrier, network and support claims.

The grade is not stronger than that because the public evidence still stops at the customer boundary. It does not disclose a customer's rack assignment, server count, reserved power, storage topology, backup geography, spare-parts inventory, support queue, contract exclusions, maintenance calendar, or tested exit time. It also leaves route-origin authorization as an open question because sampled current prefixes returned RPKI unknown status rather than valid.

The practical conclusion is narrow and useful: this is not a thin Hong Kong hosting footprint. It is a real, well-documented Rackspace network and facility presence that still requires service-specific assurance. Customers should not dismiss it as unverifiable. They should also not let the Rackspace name, two Hong Kong data-center pages, or visible AS45187 route surface substitute for the failure evidence that actually protects a workload.

Who feels the failure

The people who feel an AS45187 or Hong Kong facility failure first may be application owners, reseller operators, financial-technology teams, SaaS administrators, online retailers, database owners, compliance officers or network engineers trying to keep customer services reachable. The downstream effect can move quickly from packet loss to revenue loss, from a storage alert to a missed regulatory duty, from a portal outage to a delayed migration, or from a billing dispute to an administrative lock.

Rackspace's scale may reduce some risks. It has global data-center operations, published SLAs, named Hong Kong facilities, mature support language and visible interconnection. Scale can also hide customer-specific dependency. A large provider may have many routes, but the customer still depends on its own service design. A large provider may publish hardware-replacement guarantees, but the customer still needs to know whether the failed part is Rackspace-provided, customer-provided or controlled by another supplier. A large provider may have global engineers, but the customer still needs a local and contractual escalation path.

That is why this article treats Rackspace Hong Kong as a dependency to be understood rather than a mystery to be solved. The public evidence is good. The physical infrastructure is named. The network is visible. The interconnection record has useful detail. The remaining work is to test how those facts behave when a real workload loses a rack, an upstream, a hardware component, a support path, a billing permission, a maintenance window or a migration route. Hosted capacity is only as resilient as the proof behind those answers.