Cross connects are among the least-discussed line items in a colocation contract and among the most consequential. They determine which carriers, clouds, and counterparties a deployment can reach, how quickly a network design can change, and how much of the monthly invoice is recurring interconnection cost rather than space and power. This article covers what a cross connect is physically, how it differs from the other connection types sold alongside it, what drives the fee, and what is worth establishing with a provider before the first order goes in.
What is a data center cross connect, physically?
A data center cross connect is a dedicated physical cable that runs between two parties inside the same facility — typically from your cage or rack to a carrier, a cloud on-ramp, an exchange platform, or another tenant. It is a layer 1 circuit. Nothing routes it, nothing shapes it, and no third-party network sits in the middle. That is the whole point of it.
In practice, the cable rarely runs directly between two cages. It runs from your patch panel, through structured cabling in the overhead tray or riser, into a meet-me room, where it is patched across to the counterparty’s panel. Media is usually single-mode fiber for anything carrier- or cloud-facing, multimode for shorter in-building runs, and copper for legacy or low-speed handoffs. The demarcation point is the panel, not the cable — which matters when something breaks and you need to establish whose side of the patch the fault sits on.
Because the path never leaves the building, a cross connect adds negligible propagation delay. What it removes is more interesting: transit hops, queuing on shared infrastructure, and the variability that comes from traffic traversing networks you do not control. For latency-sensitive workloads, that predictability tends to matter more than the raw microseconds, and it sits alongside the other factors covered in how latency accumulates across a real path.
Where does the meet-me room fit in?
The meet-me room is the neutral space where tenant and carrier cabling terminates and cross connects are physically patched. In a carrier-neutral facility it is operator-managed and open to any qualified provider, which is what makes competitive carrier choice possible in the first place. It is also the single place where a large share of a building’s interconnection risk concentrates.
That concentration is why some facilities operate two meet-me rooms — commonly described as MMR-A and MMR-B — on separate floors or in separate fire compartments, fed by separate pathways. Where dual meet-me rooms exist, a genuinely diverse pair of circuits can terminate in different rooms rather than in different panels of the same room. Where only one exists, diversity has to be achieved through pathway and carrier separation instead.
It is worth asking early which model a site uses, because the answer shapes what redundancy is achievable there at all. Facilities differ on this more than their marketing material suggests, and the distinction is easier to design around before a deployment than after.
Cross connect, metro link, or exchange port — which one are you actually buying?
These three are sold in the same conversation and solve different problems, so it helps to separate them before comparing prices.
A cross connect connects two parties in the same building. A metro link — offered under various product names across the industry — carries traffic between facilities in the same city over the operator’s own metro fiber, usually as a wavelength or Ethernet service. An exchange port connects you to a shared peering fabric where many networks exchange traffic through a single interface, rather than one cable per counterparty.
The economics diverge accordingly. Cross connects scale linearly: every new counterparty is another cable and another recurring charge. An exchange port scales better once the number of peers rises, which is the usual argument for peering as an ecosystem matures. Metro links solve reach rather than count, and are typically the mechanism for treating two buildings as one campus. Most enterprise deployments end up using all three, and the useful question is which traffic belongs on which. The distinctions are set out further in interconnection and peering.
What drives cross connect cost?
Cross connects are usually billed as a one-time installation charge plus a recurring monthly fee per circuit, and the recurring portion is where the long-term cost sits. Media type and speed influence the rate, and distance inside the building generally does not — a cross connect to a neighboring suite and one to the far side of the meet-me room tend to price the same.
The variable that surprises teams is not the unit price but the count. A single production environment with two carriers, two cloud on-ramps, an exchange port, and an out-of-band path is already eight to ten circuits once each is duplicated for redundancy. Add a second environment, a partner connection, or a migration running in parallel with the incumbent, and the number climbs before anyone revisits the budget. Interconnection can become a meaningful share of monthly spend in a network-heavy deployment.
None of that argues for fewer circuits. It argues for modeling the count at design time rather than discovering it at renewal, and for understanding how the provider treats changes: whether a re-patch is billed as a new install, whether circuits can be groomed onto higher-capacity handoffs later, and how the fee structure behaves as the deployment grows. Those questions belong in the evaluation stage described in choosing a colocation provider in Asia Pacific, not in the first invoice review.
Why are two cross connects not always two paths?
Ordering a second cross connect is easy. Establishing that it fails independently of the first takes more work, and this is where a lot of otherwise-sound designs turn out to be less resilient than intended.
Two circuits are genuinely diverse only if they are separated at every layer they share: different patch panels, different riser or tray pathways, different meet-me rooms where the facility offers them, different carrier equipment, and — for anything terminating outside the building — different entry points and different metro routes. A pair that leaves your cage through the same conduit is a single point of failure regardless of how the invoice describes it.
The practical approach is to ask for the physical path of each circuit and confirm the separation point by point. Providers with mature interconnection operations can usually produce this. When they cannot, that is useful information about how the site is run. Where a facility is genuinely carrier-neutral, you also have the option of splitting a redundant pair across two independent carriers rather than two circuits from the same one.
What is worth establishing before you order?
A few operational details determine how a cross connect program feels once it is running, and all of them are easier to settle before the first order.
Start with the paperwork path. Carrier and cloud connections generally require a Letter of Authorization and Connecting Facility Assignment, and the sequence differs by counterparty — AWS and Azure both publish their own requirements for the locations they serve. Then confirm delivery lead time for a standard order, what a change window looks like, and whether after-hours patching is available. Ask how circuits are labeled and documented, and whether you receive a record you can reconcile against your own inventory.
Finally, agree the escalation path before you need it. A cross connect fault at two in the morning is resolved by whoever can access the meet-me room and read the labeling, which makes documentation quality an operational property rather than an administrative one.
How does this vary across APAC markets?
Interconnection depth is uneven across the region, and cross connect strategy should follow the ecosystem rather than a template.
In Japan, Tokyo and Osaka both support dense carrier presence and multiple cloud on-ramp options, so a cross-connect-led design is usually workable within a single building, and Digital Edge facilities in Japan are positioned around that carrier density. Korea’s market is concentrated in and around Seoul, which makes metro links a more common component of a two-site design. In the Philippines, carrier choice has broadened considerably alongside new capacity, though the specific carriers present at a given site still warrant confirmation rather than assumption.
Indonesia is the clearest case for pairing cross connects with exchange access: Digital Edge in Indonesia offers ultra-low latency downtown facilities for financial and digital platforms, carrier-neutral, with future hyperscale-AI expansion, and local traffic exchange through a well-established internet exchange in Indonesia can materially improve routing efficiency for domestic users. The broader relationship between ecosystem depth and architectural flexibility is covered in what data center interconnection covers.
Conclusion
A cross connect is a simple object with disproportionate influence over a deployment. It sets which counterparties are reachable at short-hop distance, how much recurring interconnection cost the deployment carries, and whether the resilience described in a design document exists in the cable trays.
The teams that get the most out of it treat interconnection as a design input at site-selection stage — modeling the circuit count, confirming physical diversity, and understanding the ordering and change process — rather than as a procurement detail settled after the space is contracted. The building is chosen once; the interconnection decisions it enables continue for the life of the deployment.
Talk to Digital Edge
Digital Edge interconnection services cover cross connects, metro connectivity, and exchange access across APAC markets where carrier density and ordering speed both matter — reach out to our team to discuss how interconnection at your chosen site fits your network design.
