What Is Data Center Colocation: A Modern Infrastructure
What Is Data Center Colocation. Discover what data center colocation is, how service models work, and why power scarcity now defines the real procurement
15 min read
Data center colocation means renting third-party facility infrastructure while retaining control of an organization's own servers, storage, and network equipment. The decisive constraint is increasingly not physical rack space but access to power, grid capacity, and dense interconnection in markets where available capacity is scarce.
That challenges the most common advice. Colocation is often presented as a straightforward lease for space, electricity, cooling, and connectivity. Those services still define the model, but buyers in mature markets now face a harder procurement question: can the facility deliver the required power and network access when the workload needs it?
Table of Contents
- Why Colocation Is No Longer Just About Rack Space
- Colocation versus Building or Moving Fully Cloud
- How Colocation Service Models Scale from Racks to Halls
- What Colocation Pricing Actually Measures and Where Costs Vary
- When Colocation Becomes Harder to Procure than Self-Build
- How AI and Hybrid Cloud Are Reshaping Colocation Demand
- How to Choose a Colocation Provider and Market
- Frequently Asked Questions
Why Colocation Is No Longer Just About Rack Space
The modern colocation facility is a shared infrastructure platform. An enterprise supplies and controls its hardware, while the operator provides the building, electrical systems, cooling, physical security, and connectivity. That separation lets the customer avoid owning the facility layer, including shells, chillers, UPS systems, generators, and security operations, while preserving physical control over the computing stack. The colocation model describes this division between customer-owned equipment and provider-managed facility infrastructure.
The market's scale shows how far the model has moved beyond niche hosting. One estimate valued worldwide colocation revenue at USD 69.4 billion in 2024 and projected USD 165.5 billion by 2030, implying about 16% CAGR from 2025 to 2030. A separate estimate placed the market at USD 91.1 billion in 2025 and projected USD 184.4 billion by 2033, indicating that demand is expected to roughly double within the next decade. Grand View Research's colocation market analysis provides the first estimate and projection.
From hosting model to infrastructure layer
Colocation matured as internet and enterprise demand increased for carrier-neutral facilities. Hyperscale cloud growth and interconnection hubs then made shared sites more valuable because customers could place equipment close to carriers, cloud on-ramps, exchange points, and other tenants.
A separate forecast places the market at USD 74.1 billion in 2024 and USD 182.6 billion by 2031, with a projected 13.7% CAGR. Another estimate says Asia Pacific held over 41% of global share in 2025. These figures differ because market definitions and research methods vary, but they point in the same direction. Mordor Intelligence's colocation market report reflects that broader growth pattern.
The important shift is economic. Colocation now bundles power, cooling, security, connectivity, and sometimes managed services into a contracted operating platform. In leading markets, primary market vacancy fell to a record 1.6% in the first half of 2025, while the global weighted-average vacancy rate was 6.6% in the first quarter of 2025. CBRE's global data center trends report connects those vacancy conditions with capacity shortages.
Practical rule: A rack is only useful when the facility can reserve enough power, cooling, and network capacity for the workload's full operating life.
That makes colocation closer to a capacity-constrained utility than a simple real estate lease. The decision has shifted from “should the organization colocate?” to “which market can supply the required capacity, and under what contractual terms?”
Colocation versus Building or Moving Fully Cloud
Colocation is neither a partial self-build nor a cheaper form of public cloud. It is a distinct operating model: the customer owns and configures the equipment, while the operator supplies the facility, power systems, cooling, physical security, and interconnection environment. The customer still manages hardware lifecycle, software, architecture, and workload performance.
A self-built facility provides the widest control over site selection, electrical design, cooling architecture, security, and expansion timing. That control carries the full execution burden. The organization must secure land and grid access, construct and commission the facility, then operate and staff it over the long term. Self-build becomes more defensible when suitable land and power rights are already available, utilization is expected to remain high, and the organization can manage construction and facility operations directly.
Public cloud uses the opposite ownership model. The provider owns the physical infrastructure and presents virtualized or managed resources through a service interface. This can shorten provisioning time and support elastic consumption. In exchange, the customer accepts the provider's hardware abstraction, architecture, service boundaries, and pricing mechanics. Workloads that require specific hardware placement or direct physical control may fit poorly within those boundaries.
The strategic trade-off
| Deployment path | Customer controls | Provider or internal burden | Main strategic strength |
|---|---|---|---|
| Colocation | Servers, storage, network gear, and configuration | Facility, power, cooling, security, and connectivity supplied by the operator | Physical control without building a private facility |
| Self-build | Hardware and the entire facility environment | Organization carries construction and ongoing facility operations | Maximum control over design and site |
| Public cloud | Workload configuration within the service boundary | Provider owns hardware and facility infrastructure | Fast access to scalable infrastructure |
Colocation suits workloads that need dedicated hardware, predictable physical placement, or direct network relationships. It can support latency-sensitive or regulated operations without requiring the customer to finance and operate a complete facility. The procurement constraint is capacity, not just floor space. Expansion depends on the operator's available power, cooling, and interconnection capacity at the required density.
Hybrid deployment follows from that constraint. Stable or hardware-sensitive workloads can remain in colocation, while variable workloads use cloud capacity. This arrangement is not automatically cheaper or simpler. Its value depends on assigning each workload to the model that matches its control requirements, elasticity, latency, and operating responsibilities. That allocation, rather than the label attached to the architecture, determines whether the combined design is economically sound.
How Colocation Service Models Scale from Racks to Halls
Providers sell colocation in physical increments, and each increment changes the customer's privacy, expansion options, power commitment, and ability to customize the environment. The correct starting point isn't the number of servers. It's the workload's power density, enclosure requirement, connectivity pattern, and growth path.
Match the enclosure to the deployment
Partial rack space suits a small hardware footprint. The customer rents part of a cabinet and shares the surrounding enclosure with other tenants. This model limits physical separation and may constrain cable organization, equipment placement, and future density, but it provides an accessible entry point for a modest deployment.
A full rack or cabinet gives the customer dedicated vertical space and clearer control over equipment layout. The contract still needs to define the allocated power, cooling conditions, remote-hands support, access rules, and connectivity charges. A rack count without a power commitment can create a misleading view of usable capacity.
A private cage adds a secured enclosure within a shared data hall. It can improve access control and provide room for multiple cabinets, while the operator continues to manage the hall's common power and cooling systems. Cage design should account for cabinet arrangement, cable pathways, maintenance access, and future equipment additions.
A private suite provides a dedicated room that can support customized security, power distribution, and equipment organization. The customer gains greater separation from other tenants, but the agreement may involve larger commitments and less flexibility if demand changes.
Wholesale arrangements extend the same logic to large blocks of capacity, including dedicated halls or substantial portions of a facility. At that scale, the commercial discussion centers on delivered IT load, expansion phases, cooling architecture, interconnection routes, and construction or fit-out responsibilities.
Plan the thermal footprint first
The facility's available IT load and the tenant's thermal footprint determine whether a deployment can operate as planned. Dense computing can make an apparently spacious rack unusable if the cooling design, power distribution, or circuit allocation can't support the equipment.
A practical inventory should therefore record equipment power draw, expected peak demand, rack placement, network paths, and the physical maintenance process before the organization chooses a service tier. A structured directory of data center operators can support initial market research, but provider discussions still need facility-specific verification.
What Colocation Pricing Actually Measures and Where Costs Vary
Colocation pricing measures delivered capacity more than empty floor area. Providers may quote space, cabinets, cross-connects, power, remote-hands work, and other services separately, but the central economic variable is the committed IT load. Rack count matters only when it's connected to the power and cooling required by the equipment inside those racks.
That distinction becomes visible in regional pricing. Public North America wholesale averages are about USD 196 per kilowatt per month, Northern Virginia averages about USD 215 per kilowatt per month, and Singapore averages about USD 403 per kilowatt per month. WWT's colocation overview provides these benchmarks and illustrates how scarce power, land, and network access affect delivered capacity.
Colocation wholesale pricing benchmarks by region
| Region | Average price per kW per month |
|---|---|
| North America wholesale average | About USD 196 |
| Northern Virginia | About USD 215 |
| Singapore | About USD 403 |
The difference between these benchmarks isn't just a geographic surcharge. It reflects the interaction of available land, grid access, network density, construction conditions, and demand for a specific market. A lower headline rate can lose its advantage if the facility has limited expansion headroom or requires expensive network paths to reach users, partners, and cloud environments.
Read the quote as a capacity contract
A buyer should translate every proposal into a capacity model. The useful questions include:
- What is committed? Is the contract based on installed equipment, reserved capacity, measured consumption, or a combination?
- What can expand? Does the provider have adjacent space, additional power, and cooling capacity available under defined terms?
- What is connectivity priced separately? Cross-connects, carrier access, and cloud interconnection can materially affect the economics of a network-intensive deployment.
- What happens when demand changes? A rigid minimum commitment can create waste, while an undersized allocation can force a disruptive move.
A facility's price per kilowatt is therefore a benchmark, not a complete business case. The relevant comparison is the cost of usable, expandable capacity in a market that can meet the workload's latency and connectivity requirements. Buyers evaluating terminology and contract language can also use a data center terms reference before negotiating service definitions.
When Colocation Becomes Harder to Procure than Self-Build
Colocation removes construction risk, but physical scarcity remains. In a constrained market, a provider may have a suitable building and established operations yet lack power that can be delivered when the customer needs it. Procurement then depends on utility schedules, grid access, permitting, and capacity already reserved for other customers.
The central question is not whether a facility has space. It is whether the provider can deliver usable capacity at the required density and date. A cabinet that cannot receive the needed power, cooling, or network connections does not solve the deployment problem. Buyers should therefore treat time-to-capacity as a primary decision variable, alongside facility cost and service scope.
The procurement clock matters
A self-build can appear irrational when judged only by construction complexity. An organization that already controls land and power rights may, however, have more influence over its delivery schedule than a buyer waiting for a provider's next energization phase. Self-build is not automatically superior. The comparison is between facility cost, delivery certainty, and control over the constraint that could delay the workload.
Utility and energization dependencies deserve direct scrutiny. A provider should identify what power is available now, what remains subject to utility work or approvals, and which milestones trigger customer access. Contract language should also define the remedy if the delivery date slips. Without those details, a promised future capacity allocation may be less useful than a smaller deployment available immediately.
Precommitment changes negotiating power. Providers may reserve future capacity for customers that commit before construction or energization. Buyers that wait may face fewer locations, stricter minimums, or a mismatch between available power and the workload's density requirements.
The cheapest deployment path is irrelevant if it cannot deliver usable capacity within the workload's migration window.
A disciplined evaluation should test immediate availability, contracted future capacity, and a fallback market. For each scenario, identify who controls the grid dependency, what happens if delivery slips, and whether the workload can operate temporarily elsewhere. Colocation can bridge private infrastructure and cloud environments, but constrained capacity means it must be procured as infrastructure, not treated as ordinary leased space.
How AI and Hybrid Cloud Are Reshaping Colocation Demand
AI workloads have changed what available space means. A facility may offer cabinets and network access yet remain unsuitable when its electrical distribution or cooling systems cannot support high-density equipment. AI-ready colocation therefore depends on power delivery, heat removal, network placement, and the ability to increase density over time. Floor area is only one input.
Industry reporting indicates that nearly 70% of CIOs favor colocation and hybrid environments for AI and machine learning workloads. Provider cloud interconnection ranks as the top reason respondents choose colocation for generative AI, according to CoreSite's state of the data center report. These findings point to a procurement shift: connectivity is part of workload design, not a feature reviewed after the facility is selected.
Interconnection is part of the compute design
Colocation facilities can provide direct cross-connects to carriers, cloud on-ramps, and other tenants. These connections may shorten data center interconnect paths and place latency-sensitive systems closer to networks and exchange points than routes relying on less direct public access.
For hybrid AI architectures, the value is structural. Training, inference, storage, data preparation, and enterprise applications may run in separate environments, so the interconnection ecosystem determines how efficiently those components exchange data. A buyer that checks only cabinet availability may later find that the required network topology is costly, congested, or unavailable.
Supply growth does not resolve density constraints. Europe is expected to add 937 megawatts of new supply in 2025, while Latin America's colocation inventory grew 20% year over year, with 42% of pipeline capacity already precommitted, according to the report. Those figures describe expansion, not accessible capacity. Precommitment is the more consequential signal for late buyers because announced supply may already be allocated before construction is complete.
AI procurement should therefore test four conditions:
- Power: Can the facility support the required density now and through the next expansion phase?
- Cooling: Does the design match the equipment's thermal profile rather than a generic rack assumption?
- Interconnection: Can the deployment reach required cloud and network endpoints through direct paths?
- Operations: Can technicians install, replace, and troubleshoot dense equipment under the facility's access rules?
Colocation can host AI workloads, but only when the site is evaluated as an AI-capable interconnection environment. Spare cabinets alone do not establish usable capacity.
How to Choose a Colocation Provider and Market
Provider selection should begin with the constraint most likely to stop deployment. For a conventional workload, that may be power delivery or geographic latency. For a dense AI system, cooling and interconnection may become equally decisive. For a regulated application, physical access, jurisdiction, audit evidence, and contract language can determine suitability before pricing enters the discussion.
A useful sequence is:
- Define the workload envelope. Record current and expected power, density, cooling requirements, network paths, hardware ownership, and deployment timing.
- Screen the market. Remove locations that can't meet latency, jurisdiction, resilience, or delivery requirements.
- Verify capacity. Ask for available power, expansion phases, energization assumptions, and the portion already committed.
- Test connectivity. Map required carriers, cloud on-ramps, exchange points, cross-connect routes, and redundancy.
- Audit the agreement. Review power allocation, access rules, maintenance responsibilities, service levels, remedies, escalation, and termination terms.
Treat pipeline visibility as a procurement control
A market with many announced projects isn't necessarily a market with available capacity. Planned and under-construction facilities may already have commitments, unresolved grid dependencies, or delivery dates that don't match the migration plan. Market research should distinguish operating sites from future supply and disclosed capacity from estimates.
A searchable global data center directory can help teams compare facility locations, operators, operational status, and available capacity information during the initial screening stage. The final decision still requires direct provider diligence, site documentation, and contractual confirmation.
The strongest provider isn't just the one offering the lowest unit price. It's the one that can prove a workable path from today's deployment to the next required power block, cooling upgrade, and interconnection expansion.
Frequently Asked Questions
Does colocation include the servers?
Usually, no. In the standard model, the customer owns and controls the servers, storage, and network equipment, while the provider supplies the building, power, cooling, physical security, and connectivity. Managed services can add operational support, but the ownership boundary should be written clearly in the agreement.
Can a colocated deployment grow?
It can, provided the facility has uncommitted power, suitable cooling, available enclosure space, and an expansion process. A buyer should request those details before signing, because physical room without electrical or thermal headroom doesn't represent usable growth capacity.
Is a cage more secure than a rack?
A private cage creates a distinct physical access boundary within a shared hall. It can support tighter equipment separation, but security still depends on the facility's access controls, monitoring, visitor procedures, and the customer's own hardware and network practices.
What should an SLA clarify?
An SLA should define the service being measured, the provider's responsibility, response obligations, maintenance rules, exclusions, and remedies. Uptime language alone doesn't explain whether the commitment covers power, cooling, connectivity, access, or support response.
Should every AI workload use colocation?
No. AI workloads need a facility with appropriate density, cooling, power, and interconnection characteristics. A general-purpose colocation site may not support the required operating profile, so the workload should be tested against facility design rather than the label.
Data Centers List helps infrastructure teams research facilities, operators, locations, operational status, and disclosed or estimated IT power capacity across global markets. Visit Data Centers List to compare current and pipeline facilities before treating a colocation quote as available capacity.