What a Colocation Contract Actually Commits You To

A colocation contract commits you to three things that most engineering teams don't fully price out before signing: a power draw ceiling that constrains your rack density, a cooling methodology that dictates your hardware roadmap, and a cross-connect fee schedule that compounds as your architecture grows more distributed. None of these show up clearly on the pricing page. They show up eighteen months in, when you're trying to add a GPU chassis and the facilities manager tells you the rack can't take another kilowatt. ## Power draw is the ceiling, not the floor Every colo contract quotes power in one of two ways: committed capacity or metered draw. Committed capacity means you're paying for, say, 8 kW per rack whether you use it or not. Metered draw means you pay for what you pull, but the rack still has a hard ceiling set by the circuit and the breaker upstream of it, usually 20A or 30A at 208V in a standard cabinet. Here's what catches people off guard: the number on your contract is rarely the number you can actually use. A 30A/208V circuit has a nameplate capacity of about 6.24 kW, but the National Electrical Code caps continuous load at 80% of breaker rating, which brings usable capacity down to roughly 5 kW. Providers know this. Most build the derate into their published density figures, but not all of them do, and the ones that don't will let you find out the hard way when your PDU trips at 5.8 kW because you assumed you had the full 6.24 to work with. Density has moved fast, and contracts haven't always kept pace with it. A single rack of modern GPU servers, the kind running dense NVIDIA H100 or H200 configurations, can pull 30 to 40 kW or more. That's not a standard cabinet anymore; that's a high-density suite with dedicated busway, in-row cooling, and a completely different pricing tier. If your growth plan involves any kind of AI training or inference workload, the power clause in your contract is the single most important paragraph in the document, because it determines whether you're renting a cabinet or renting a liability. ## Cooling envelopes decide what hardware you're allowed to run Colocation providers sell "cooling" as if it's one thing. It isn't. It's a design constraint that shows up in the contract as a maximum inlet temperature, a maximum kW per rack for that specific cooling zone, and sometimes a requirement about airflow direction and containment that your hardware has to match. Traditional colo space is built around raised-floor CRAC units pushing chilled air through perforated tiles, designed for loads in the 3 to 8 kW per rack range. That architecture runs out of headroom fast. Once you're north of 15 kW per rack, air cooling alone starts to struggle with hot spots, and providers either wall you off into a hot-aisle containment pod or push you toward liquid, whether that's rear-door heat exchangers or direct-to-chip cooling loops. The contract detail that matters here: does your provider's facility support the cooling method your hardware roadmap requires, and is that support written into the agreement or just promised verbally by a sales engineer? Liquid cooling retrofits are expensive and slow. A facility that's air-cooled today may take a year or more to add the plumbing, the coolant distribution units, and the leak detection infrastructure that direct-to-chip cooling demands. If you sign a three-year term assuming you'll upgrade to denser hardware in year two, and the facility can't cool it, you're either paying an early termination fee or running derated hardware for the rest of the contract. Some providers now quote cooling in terms of a "power usage effectiveness" target, a ratio of total facility power to IT equipment power. A PUE of 1.4 or lower is generally considered a strong result for air-cooled colo; the best liquid-cooled and hyperscale facilities push toward 1.1 or better. That number matters because it's baked into your total cost, even though it never appears as a line item; it shows up in the base rate you're quoted. ## Cross-connects: the fee that scales against you A cross-connect is a physical cable, fiber or copper, that connects your cabinet to another cabinet, a carrier's point of presence, or an exchange fabric like Equinix's ECX or a similar offering from Digital Realty. Providers typically charge a flat monthly fee per cross-connect, often somewhere in the range of $100 to $500 depending on the facility and the connection type. That fee looks trivial on a per-connection basis. It stops looking trivial once your architecture goes distributed. A company running a single database server needs maybe two or three cross-connects: one to a carrier, one to a backup provider. A company running a multi-region, multi-cloud setup with direct connections to AWS Direct Connect, Azure ExpressRoute, and a handful of network carriers for redundancy can end up with a dozen or more cross-connects per facility, and that number climbs further if you're peering directly with other tenants for latency reasons, which is common in financial trading colocation. The economics get worse when you consider that cross-connects are usually billed per-side. You pay your provider, and the party on the other end pays theirs. There's also often a one-time installation charge, and if you need to move cabinets within the same facility, plenty of providers charge you to re-terminate the connection, even though the fiber itself may already exist in the building's conduit. None of this is disclosed as clearly as the base rack rate, because the base rate is what gets compared across quotes. Cross-connect fees live in an addendum, and they're the reason a contract that looked cheaper at signing can end up costing more over a three-year term than the "premium" competitor. ## What this means for anyone signing None of this is a case against colocation. It remains the right choice for companies that need physical control over hardware without the capital burden of building a data center, and it beats cloud economics decisively for steady-state, predictable workloads. But a colo contract is an engineering document disguised as a real estate lease, and it should be read by someone who understands electrical load, thermal design, and network topology, not just procurement. Ask for the actual usable power per rack after derate, not the nameplate figure. Ask what cooling upgrade path exists if your density requirements double, and get the timeline in writing. And model out cross-connect costs against your actual network architecture, not the simplified version in the sales deck, because that's the line item that grows quietly while everyone's watching the power bill.