CyrusOne LLC and the operating boundary behind hyperscale data-center dependency

CyrusOne's hyperscale and colocation offer is not only power and floor space. Carrier-neutral interconnection, IP service, cloud on-ramps, and ASN 62 make network identity part of the facility dependency customers must map and test.

Summary

  • CyrusOne's colocation page explicitly joins carrier-neutral connectivity, Metro and National IX services, cloud on-ramps, IPv4 and IPv6 assignments, and multi-homed bandwidth via ASN 62.
  • PeeringDB corroborates CyrusOne's ASN and exchange/facility presence, but the record is a network ledger entry, not proof of route quality, customer control, or workload continuity.
  • The hyperscale operating boundary is shared: CyrusOne supplies facility and network infrastructure while the customer must preserve equipment, workload, identifier, monitoring, redundancy, and exit state.

A data center is also a network-identity control surface

CyrusOne should not be framed as a generic real-estate dependency. Its own colocation material places carrier-neutral connectivity, cloud on-ramps, Metro IX, National IX, optical transport, IP bandwidth, IPv4 and IPv6 addresses, and multi-homed service inside the product boundary. Those services determine how customer equipment becomes reachable and how traffic moves between facilities, carriers, clouds, and the public Internet.

PeeringDB independently records CyrusOne as ASN 62, with exchange and facility presence. That record corroborates a real network identity, but it does not prove what any customer route is doing now. It is a registry maintained from operator-contributed data, with fields updated at different times. The operational reality still requires current routing, cross-connect, carrier, address, DNS, and workload evidence.

Carrier-neutral does not mean dependency-free

Carrier-neutral facilities can give customers meaningful choice. CyrusOne says customers can select carriers, use cloud on-ramps, and connect through multiple interconnection services. That can reduce dependence on one access path and make hybrid designs practical.

Choice becomes resilience only after the customer builds separate failure domains. Two carrier names may still share conduit, equipment, power, or a common operational process. A cloud on-ramp may diversify public-Internet exposure while concentrating dependence on one port or facility. The buyer therefore needs evidence about physical diversity, logical routing, failover behavior, address policy, maintenance communication, and who owns each repair action.

The facility and customer retain different controls

CyrusOne says colocation customers retain control of their infrastructure while using provider facility expertise and operational support. That is the essential boundary. The provider can operate space, power, cooling, physical access, environmental monitoring, cross-connect processes, and network products. The customer still controls equipment configuration, workload architecture, identity, encryption, logging, software recovery, and the decision to use one or several paths.

A failure can cross the boundary in either direction. A functioning facility does not make a badly configured workload available. A resilient application can still be exposed to a facility, power, carrier, or cross-connect event. Shared responsibility is useful only when each dependency has a named owner, a monitored signal, an escalation path, and a tested alternative.

Hyperscale makes the dependency longer lived

CyrusOne presents hyperscale and build-to-suit infrastructure as a coordinated design across land, modular expansion, power, connectivity, cooling, and implementation. Those decisions can outlast several software generations. Moving a large deployment is not equivalent to changing an application subscription; it can require new space, circuits, cross-connects, addressing, hardware movement, data synchronization, contract overlap, and parallel testing.

The 2025 sustainability report supplies the physical reality beneath that dependency. Data centers run continuously, consume substantial electricity, produce heat that must be removed, and use backup generation and cooling strategies. Those facts do not prove the availability of a specific CyrusOne site. They establish why facility continuity and network continuity must be planned together rather than hidden beneath the word cloud.

ASN and address records are operational inputs

CyrusOne's published IP service includes unique IPv4 and IPv6 addresses for customers and multi-homed bandwidth via ASN 62. That statement makes address and routing metadata part of the customer dependency. It does not establish who owns an assigned address, whether it is portable, what route is visible, or what reverse-DNS and abuse-contact process applies to a particular service.

The Heng.lu doctrine test is to treat those records as a ledger of identity and handoff, not as a substitute for running proof. A buyer should record every assigned prefix or address, origin and upstream assumption, DNS and reverse-DNS dependency, cross-connect, cloud on-ramp, firewall boundary, monitoring source, responsible team, and migration condition. Current route and failover tests must then confirm that the recorded model matches operation.

Continuity requires one map across physical and logical layers

The practical output of a CyrusOne relationship should be a joined continuity map. It should connect facility, hall or cage, power path, cooling assumption, access procedure, carrier, cross-connect, ASN or upstream service, IP assignments, DNS, cloud connection, equipment, workload, data location, monitoring, escalation, and exit plan. Separate inventories are not enough if nobody can trace a public service through them during an incident.

The public sources do not prove CyrusOne's measured uptime, available power at a particular hall, security outcomes, incident history, route quality, customer list, or the resilience of a specific hyperscale build. The defensible conclusion is narrower. CyrusOne operates a facility and network-identity surface, and customers remain accountable for proving that its physical and logical dependencies form a recoverable service.

Claims To Exclude

  • CyrusOne operates more than 350 data centers; the current public page contains a likely overbroad figure that conflicts with other company materials
  • CyrusOne guarantees continuous availability, zero downtime, or route quality
  • every CyrusOne facility supplies every listed interconnection product
  • CyrusOne customers own ASN 62 or all assigned IPv4 and IPv6 resources
  • PeeringDB proves live BGP announcements or complete physical diversity
  • the sustainability report proves facility-specific power availability or workload reliability
  • carrier-neutral service automatically creates independent failure domains
  • Heng.lu doctrine is a factual source for CyrusOne's infrastructure

Source Register

  • Colocation: https://www.cyrusone.com/solutions/colocation (CyrusOne says colocation customers retain control of their infrastructure while using provider facility operations; facilities offer carrier-neutral options, cloud on-ramps, carrier-diverse connectivity, Metro IX, National IX, and IP bandwidth; the page says IP service includes unique global IPv4 and IPv6 addresses per customer and multi-homed bandwidth via ASN 62)
  • Hyperscale: https://www.cyrusone.com/solutions/hyperscale (CyrusOne presents hyperscale as modular, expandable infrastructure joining power, connectivity, cooling, and operational design; build-to-suit and hyperscale decisions can embed long-lived facility and network dependencies; the product surface supports cloud, enterprise, AI, and high-density workloads without proving any specific deployment)
  • About Us: https://www.cyrusone.com/company/about-us (CyrusOne identifies itself as an owner, developer, and operator of digital infrastructure; the company places build-to-suit, colocation, and interconnection in its core operating scope; power planning, floor layout, connectivity optimization, and implementation scheduling are presented as joined design activities)
  • 2025 Sustainability Report: https://www.cyrusone.com/hubfs/Website%20Documents%202025/2025%20Sustainability%20Report.pdf?hsLang=en (the report describes data centers as continuously operating infrastructure with substantial power and cooling requirements; electricity, backup generation, cooling, energy efficiency, and water trade-offs are material operating inputs; facility continuity is physically constrained and cannot be reduced to a software abstraction)
  • AS62 - CyrusOne: https://www.peeringdb.com/api/net?asn=62 (PeeringDB records CyrusOne as ASN 62 and network type NSP; the record reports exchange and facility presence and an open general peering policy; the registry entry corroborates that CyrusOne has a concrete network identity beyond a generic real-estate role)