Rackspace IT Hosting AS IT Hosting Provider Hong Kong Sells a Hosted Capacity That Still Depends on Racks, Transit, and Repair Windows

Summary

• Rackspace IT Hosting AS IT Hosting Provider Hong Kong corresponds to AS45187 in the public APNIC and RIPEstat registries. APNIC's RDAP record names Rackspace.com Hong Kong Limited as the holder organisation, and RIPEstat labels the holder "RACKSPACE-AP - Rackspace IT Hosting AS IT Hosting Provider Hong Kong".
• The routing surface is materially visible. RIPEstat's routing status snapshot for AS45187 showed 13 IPv4 prefixes, 2 IPv6 prefixes, 66,816 IPv4 addresses, full RIS visibility observed 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 site and interconnection context rather than a capacity guarantee. It lists "Rackspace Hong Kong" for AS45187, an open policy, indicative prefix counts of 100 IPv4 and 10 IPv6, two 10G exchange entries at Equinix Hong Kong and HKIX, and a facility entry at MEGA-i in Hong Kong.
• Rackspace's HKG1 and HKG5 pages make the physical dependency visible. HKG1 is described at Tsuen Wan with UPS modules, dual 11 kV feeds, and redundant network components; HKG5 is described at Tseung Kwan O with 917 m² of dedicated data centre space, a total electrical power of 13.5 MW, UPS capacity of 7.2 MW, seven fibre operators, 10 Gbit/s per operator, BGP multipath route optimisation, and a stated separation where customers retain administrative control of leased servers while Rackspace controls the network hardware.
• The evidence level is High for public network identity and operating evidence in Hong Kong, but it is not a blank cheque for all hosted workloads. Customers still need service-specific evidence regarding placement, redundancy, restoration times, ticket escalation, maintenance exclusions, spare parts access, RPKI status, contractual limits, 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 weak ASN. That is not the case here. The public record around Rackspace IT Hosting AS IT Hosting Provider Hong Kong is thick enough to shift the inquiry from existence to dependency. APNIC\'sautonomous system RDAP recordidentifies AS45187 as RACKSPACE-AP, with country HK and Rackspace.com Hong Kong Limited as the holder organisation. RIPEstat\'sAS overviewuses the holder label "Rackspace IT Hosting AS IT Hosting Provider Hong Kong" and marks the ASN as announced. This pairing is stronger than a scraped hosting directory entry or a stale corporate page.

The routing evidence is also current enough to matter. RIPEstat\'srouting statusfor AS45187 showed IPv4 and IPv6 visibility across all observed RIS peers at the time of the snapshot, 13 IPv4 prefixes, 2 IPv6 prefixes, and 23 observed neighbours. Theannounced prefixes data setlisted 15 current prefix lines. These 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 single-prefix vanity network.

Rackspace\'s public facility documents make the matter still less abstract. Rackspace\'sHKG1 data centre pageplaces a facility in Hong Kong at Tsuen Wan and describes power, cooling, security, connectivity, and guarantees. ItsHKG5 pageplaces another facility at Tseung Kwan O and goes further, listing 917 m² of dedicated data centre space, a total electrical power of 13.5 MW, UPS capacity of 7.2 MW, seven fibre operators to the site, and BGP multipath route optimisation. The existence question is therefore sufficiently settled for procurement work. The open question is whether a particular customer\'s hosted service has the same resilience as the published footprint suggests.

This distinction matters because "Rackspace" is a large brand, "Hong Kong" is a market label, AS45187 is a network border, and a customer workload is a contract-specific deployment. A buyer can see the public number resources and Rackspace\'s claims about its facilities, but cannot infer which room, which rack, which carrier, which VLAN, which backup system, which support team, or which maintenance schedule applies to his own environment. A well-evidenced facility page ought to make scrutiny stricter, not less rigorous.

AS45187 is a real operating edge, but the registry does not show all services

The APNIC and RIPEstat records show a consistent identity. The RDAP record gives a registration date of December 2014 and a last-changed date of July 2020. RIPEstat\'swhois-derived viewrecords 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 historical import and export policy lines naming AS3491, AS1239, and AS2914, as well as Rackspace routing maintainer contacts. These details are helpful because they tie the number resource to the Hong Kong Rackspace entity and to a long-standing routing administration record.

That does not suffice 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 interconnections, 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 him which exact product uses the routing edge, which legal entity signs the contract, or which provider is accountable for an incident.

The APNIC holder evidence must therefore be read as a starting point for the responsibility map. If a customer is told that a Hong Kong workload is delivered from Rackspace infrastructure, AS45187 gives the customer a concrete network border about which to ask questions. Which prefixes are involved? Which are customer-facing, management-only, backup-only, or legacy? Which routing policies are active, and which are historical? Which prefixes have a route origin authorisation, and which remain unknown to RPKI validators? These are not academic questions.

They determine whether a route leak, a filter change, a DDoS mitigation event, or an upstream outage can affect the service.

The first caveat concerns RPKI. The validation check used for this article on 119.9.64.0/19 via RIPEstat\'sRPKI validation endpointreturned an 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 that the network is failing. It means that route origin authorisation ought to be an active procurement question, because networks that enforce route origin validation treat valid, invalid, and unknown routes differently. For a customer who depends on a stable edge in Hong Kong, "unknown" should lead to a discussion about ROAs, route filters, contact procedures, and change-control ownership.

Rackspace publishes two different kinds of facility evidence in Hong Kong

Rackspace\'s Hong Kong facility pages are unusually concrete compared to many regional hosting profiles. HKG1, described onRackspace Technology Data Centers: Hong Kong (HKG1), is located in Tsuen Wan. The page states that the Hong Kong facilities are staffed with systems engineering professionals who manage and maintain the systems 24/7/365. The physical claims listed for HKG1 include 400 KVA UPS modules in N+1 configuration, 30 minutes of battery runtime, dual 11 kV power feeds from separate HKE substations, dual power risers, multiple generators, and a carrier-neutral facility fed by dual telecom connections.

HKG5, described onRackspace Technology Data Centers: Hong Kong (HKG5), is located in Tseung Kwan O and exposes a different set of specificities. It lists 917 m² of dedicated data centre space, a total electrical power of 13.5 MW, UPS capacity of 7.2 MW, diesel generators with a capacity of 2.25 MW 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 optimisation. It also states that customers retain administrative control of leased servers while Rackspace retains control of the network hardware.

These claims have operational meaning. They say that Rackspace is not merely reselling an anonymous cloud region under a Hong Kong label. They indicate a physical facility, a network design, support staff, and control boundaries. But they must 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 optimisation" does not prove route diversity all the way to the application, the storage tier, or the customer\'s management console.

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

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

PeeringDB confirms interconnection signals, not customer placement

ThePeeringDB network API for ASN 45187lists a network entity named Rackspace Hong Kong. The fields show a general open policy, an AS-IRR AS set of AS-RACKSPACE, indicative 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 these fields is a certification. Nevertheless, the entry is valuable because it ties AS45187 to an interconnection posture that can be compared with Rackspace\'s route collectors and facility statements.

ThePeeringDB netixlan recordslist two operational exchange-facing entries: Equinix Hong Kong and HKIX: HKIX Peering LAN. Both show a speed of 10,000 Mbit/s. The Equinix Hong Kong line lists IPv4 address 36.255.56.87 and IPv6 address 2001:de8:7::4:5187:2. The HKIX line lists IPv4 address 123.255.90.101 and IPv6 address 2001:7fa:0:1::ca28:a065. ThePeeringDB netfac recordlists MEGA-i (iAdvantage Hong Kong) in Hong Kong as a facility entry for the network entity.

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

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

The immediate operational lesson is that facility count is not the same thing as redundancy. A PeeringDB facility line can coexist with multiple sites operated or marketed by Rackspace. Two exchange-facing ports can improve reachability to selected networks without proving full transit diversity. A 10G exchange port may be useful for peering, but the surviving customer path during an outage may depend on paid transit, private interconnection, 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 outcome.

The routing surface is broad, but diversity must still be proved twice

AS45187 has a visible neighbour set. RIPEstat\'sASN-neighbours endpointreturned 23 observed neighbours. The list included large global networks such as AS174, AS3257, AS3300, AS3491, AS4637, AS6453, AS6939, and AS7473 on the left-hand side, a right-hand line for AS58982, and several uncertain lines. 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 routing edge is not invisible.

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

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

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

Rackspace sells abstraction, but the Hong Kong economy remains physical

Rackspace\'smanaged hosting pagepresents 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 bay, interconnection, and maintenance process.

This exchange has real value, but it does not erase the underlying economics. Rackspace\'scolocation customer guidedescribes kilowatt-allocated billing for reserved redundant critical power, with separate monthly recurring charges for interconnections and blended bandwidth when purchased. It also refers to one-time setup fees, power circuits, private cages, in-rack PDUs, and interconnections. This is the vocabulary of physical capacity. The cloud bill still rests on energy allocation, rack space, optics, remote hands, bandwidth commitments, and labour.

The Hong Kong pages make this visible. HKG5\'s claim of 13.5 MW of electrical power, its 7.2 MW of UPS capacity, and its 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 interconnections, if a spare router is unavailable, if a carrier path is congested, or if a maintenance window requires serialised work, the customer feels the physical state through latency, ticket delay, migration limits, or post-outage credits. Hosted capacity is bought as a service, but it fails as a chain of physical and administrative steps.

This is why one must separate "installed" capacity from "usable" capacity. 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 accounting for normal reservations, overbooking, maintenance, customer-specific routing, and protection domains. Recoverable capacity is narrower still: the portion that can be restored within the customer\'s required timeframe after a component failure. Public pages are good for installed capacity.

Customer assurance must prove usable and recoverable capacity.

Control is divided by design

The most important line on HKG5 may not be the one about megawatts or carrier counts. The page states that customers retain administrative control of leased servers while Rackspace retains control of the network hardware. This separation is exactly what a managed hosting customer wants during normal operation: the customer can manage his workload, while the provider protects the shared network layer. During a failure, the same separation becomes a border that must be rehearsed.

If a leased server is healthy but unreachable, the customer\'s administrative rights may not be enough. If a customer can reach a server via VPN but cannot reach the public service, the network boundary matters. If a customer needs a route change, a firewall rule, an interconnection ticket, or a hardware replacement, Rackspace\'s authority and queue become the limiting factor. If the customer has a backup but cannot move enough data over the available path, server-level control is limited public evidence. Shared responsibility is not a slogan here; it is the operational architecture.

The Rackspace colocation guide reinforces the same boundary. It describes implementation managers, customer portal training, remote-hand requests, automatic ticket creation, alert monitors, and a runbook. It states that customers can interact by creating tickets through the Rackspace customer portal and can call the 24/7/365 support team. It also lists remote-hand tasks such as device power cycling, visual verification, cable testing, customer-provided hardware replacement, rack mounting and de-racking, in-rack network cabling, and hard-drive destruction. These are the concrete actions that turn fault 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? This question should be answered before production. It should be written in operational steps, not just contractual 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 billed in 15‑minute increments? Which tasks depend on customer-supplied parts rather than Rackspace-supplied parts?

Repair windows are a product feature, not a footnote

Rackspace\'s data centre pages publish strong guarantees, but the details matter. Both HKG1 and HKG5 include guarantee language for network, infrastructure, and hardware replacement. The network and infrastructure sections speak in terms of availability and credits, while the hardware replacement guarantee states that replacement or repair of Rackspace-provided hardware or components will begin within one hour of problem identification, with credits if it does not. The word "begin" is important. It is not the same as "complete", and it does not describe all customer-provided components.

The remote-hands table in the colocation guide is more operationally granular. It shows that HKG1 has both a 1‑hour response SLA and a 24‑hour execution SLA for remote 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 wiring support testing, and 60 minutes for replacing a customer-provided device that is not hot-swappable. It lists a remote-hand rate of US$46.25 per 15‑minute increment plus bill of materials. These are not trivial details. They show where the repair clock can shift from an abstract uptime metric to paid human labour.

A customer should therefore separate three clocks. Detection time is the time it takes monitoring to notice and classify a fault. Response time is the time it takes Rackspace or the customer to accept ownership and begin action. Execution time is the time the repair actually takes, including parts, access, cabling, reboot, route change, storage rebuild, and verification. Post-outage credits are commercially important, but they do not restore the workload. Resilience scrutiny should focus on measured restoration, not just service credits.

The same logic applies to maintenance. Rackspace\'s guarantee language excludes planned or emergency maintenance. This exclusion is normal, but it matters in a hosted capacity review. If a path or site is unavailable for maintenance, the customer\'s true resilience is the remaining capacity 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 administrative rights may not help. Repair windows and maintenance windows are part of the product, not ancillary paperwork.

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

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

For a hosted customer, this 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 authorised to originate a prefix. APNIC\'s own RPKI material explains resource certification control in operational terms. A customer who depends on public reachability ought to care whether its provider\'s production prefixes are valid, unknown, or invalid, and whether the customer\'s own 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 narrower question is: for the exact prefixes that carry the customer\'s service, are route origin authorisations published and tested with main validators? If the customer brings his own address space, who creates and maintains the ROAs? If Rackspace assigns the address space, can Rackspace show the status and the change-control process? If a prefix must be moved during an incident, what happens to the ROA state and the filter?

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 may still work on most networks; it simply gives the buyer less assurance at the origin-validation level. In an otherwise strong Rackspace Hong Kong file, this is exactly the kind of specific, fixable question that should not be lost under the weight of a large brand.

Data locality is not settled by the letters HK

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

Hong Kong\'s privacy regulator underscores this point in its public guidance. The PCPD\'sGuidance on Cloud Computingfrom January 2025 tells data users to consider the location of data storage, security measures at the equipment, the integrity and competence of the persons who have access, secure transmission, contracts with subcontractors, retention controls, and the implications of cross-border transfers. APCPD case note on cloud systems outside Hong Kongstates that the Ordinance does not prohibit the storage of personal data in a cloud system outside Hong Kong, but that data users must still comply with the PDPO and the data protection principles. The PCPD\'srecommended model contractual clausesprovide a contractual 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 are involved, and whether a normal support action transfers personal data outside Hong Kong. A routing edge in Hong Kong can coexist with non-Hong Kong support tools, global identity systems, offshore backup copies, or multi-cloud interconnections. None of this is necessarily improper.

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

Locality also interacts with recovery. A backup outside Hong Kong may improve resilience but alter the transfer analysis. A local-only backup may satisfy a residency preference but fail if the local facility suffers a regional event. A multi-site design within Hong Kong may be better for latency and jurisdiction but more expensive and still dependent on common providers. 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 manual on OpenStack Flex points to functions for creating virtual machines, block storage, object storage, exporting images, importing images, and scheduling migration. Theexporting images guidedescribes exporting instance snapshots from an OpenStack Flex project. TheObject Storage API guideexplains that access requires Rackspace Cloud credentials, project details, and API calls.

These documents do not prove that every managed hosting customer in Hong Kong can perform a full emergency exit. They prove that exit should be discussed at the artefact level. Can the customer export VM images? Can he export block volumes? Are backups portable? Are network configurations, firewall rules, load-balancer settings, DNS zones, certificates, logs, and monitoring history exportable? Does the 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. Interconnection billing, transit caps, storage read rates, object storage credentials, and support tickets all form part of the migration path. A customer who has never measured a full export may discover during an incident that "we can move" actually means "we can begin a long transfer after the provider approves the request". Exit planning is not hostility towards Rackspace. It is the honest end of a dependency review.

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

Corporate packaging helps, but local evidence still wins

The broader Rackspace Technology corporate file helps explain why this Hong Kong profile should not be treated as a small regional hoster. Rackspace Technology, Inc. appears in SEC filings as a Nasdaq-listed company under the symbol RXT, and its2025 10-K filinggives investors the wider business and risk context around its cloud, hosting, and services operations. Rackspace\'sglobal data centres pagepresents a multi-market data centre footprint and states that its facilities use redundancy in security, power, cooling, and network domains. These 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 evidence. A global enterprise can still have a local facility constraint, a regional vendor dependency, a product-specific depreciation 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 learn which rack, which route, which backup system, and which 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 workload on AS45187.

This corporate packaging changes the assurance method. With a small, unknown provider, the first task might be to prove that the company and the network exist. With Rackspace Hong Kong, the first task is to align multiple public layers that are each real: the AS45187 identity from APNIC, the current routing evidence from RIPEstat, the interconnection lines from PeeringDB, the HKG1 and HKG5 facility pages from Rackspace, the managed hosting and colocation documentation from Rackspace, and the customer\'s own contract. The risk is not that each layer is false. The risk is that a customer assumes all layers apply to his service in the same way.

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

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. Cross-check the ASN answer with APNIC RDAP, RIPEstat announced prefixes, the PeeringDB Rackspace Hong Kong record, and the Rackspace HKG1/HKG5 pages. If the customer service does not use AS45187, that may be acceptable, but it should be clearly stated.

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

The third test is routing security. Ask for the 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. The public unknown RPKI 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 remote-hands vocabulary from the colocation guide to make the exercise concrete. Who opens the ticket? Who can call if the portal fails? Which tasks are included, billable, or excluded? Which spare parts are supplied by Rackspace, by the customer, or by the vendor? Which HKG1 remote-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-locality 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 these questions belong in a Hong Kong cloud discussion: the customer remains responsible for the processing of personal data even when using a cloud provider or subcontractor.

The evidence level

Rackspace IT Hosting AS IT Hosting Provider Hong Kong receives a High public network evidence level. This level reflects identity and operational visibility, not an unbounded statement about all Rackspace services. APNIC ties AS45187 to Rackspace.com Hong Kong Limited. RIPEstat shows AS45187 as announced, with 13 IPv4 prefixes, 2 IPv6 prefixes, full RIS visibility observed at the checked snapshot, and 23 observed neighbours. PeeringDB lists Rackspace Hong Kong with two 10G exchange-facing entries and a facility line in Hong Kong.

Rackspace publishes the HKG1 and HKG5 pages with concrete claims about facilities, power, carriers, network, and support.

The level is not higher than this because public evidence always 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, contractual exclusions, maintenance schedule, or tested exit time. It also leaves route origin authorisation as an open question because the sampled current prefixes returned an RPKI status of unknown rather than valid.

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

Who feels the failure

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

Rackspace\'s scale can reduce some risks. It has global data centre 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 his own service design. A large provider may publish hardware replacement guarantees, but the customer still needs to know whether the failing part is Rackspace-supplied, customer-supplied, or controlled by another vendor. 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 understand rather than a mystery to solve. 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 these facts behave when a real workload loses a rack, an upstream, a hardware component, a support path, a billing authorisation, a maintenance window, or a migration route. Hosted capacity is only as resilient as the evidence behind those answers.