Colocation and public cloud get framed as a binary choice, but they solve different problems, and the right answer depends more on the workload than on which model is trendier this year. Both have a real, durable place in most mid-market infrastructure strategies.
What Each Model Actually Offers
Colocation means owning the hardware and renting the facility, space, power, cooling, and connectivity, from a provider. It offers control over the hardware and predictable, flat costs once capital expenditure is made, but no elasticity: capacity is fixed until new hardware is purchased and installed. Public cloud means renting both the hardware and the facility as a service, with elastic, usage-based pricing and no capital expenditure, but less control over the underlying infrastructure and cost that scales directly with usage, for better or worse.
| Factor | Colocation | Public Cloud |
|---|---|---|
| Cost structure | Capital expense plus flat facility fees | Operating expense, scales with usage |
| Scalability | Fixed until new hardware is purchased | Elastic, near-immediate |
| Control | Full control over hardware and configuration | Limited to what the provider exposes |
| Best fit | Steady, predictable, compliance-sensitive workloads | Variable-demand, customer-facing, rapidly scaling workloads |
How to Actually Decide
Workload predictability is the clearest signal. A steady-state workload with little demand variation often costs less on owned hardware in colocation over a multi-year horizon, once the cloud's usage-based pricing is modeled honestly against it. A workload with real demand variation, seasonal spikes, rapid growth, unpredictable traffic, tends to favor cloud's elasticity, since over-provisioning colocation hardware for a peak that happens a few weeks a year wastes capital the rest of the time.
Why Many Companies End Up With Both
The honest answer for a lot of mid-market environments isn't choosing one, it's running colocation for the steady, predictable core and cloud for the variable, customer-facing layer. That's effectively a hybrid cloud strategy, and it tends to outperform a forced all-or-nothing choice in either direction. See Hybrid Cloud Infrastructure for how that split typically gets structured.
Total Cost Comparison, Done Honestly
A fair comparison prices colocation at its full real cost, hardware purchase and depreciation, facility fees, power, and the internal staff time to manage physical infrastructure, not just the monthly colocation invoice. It prices cloud at realistic future usage, not today's usage, since growth is exactly where cloud's usage-based pricing can outpace a static colocation cost. Done honestly, over a three-to-five-year horizon, the answer is genuinely workload-dependent, not a foregone conclusion in either direction, which is exactly why this decision deserves real modeling rather than a default.
A Simple Decision Framework
Three questions narrow the decision quickly. How predictable is the demand; steady and known favors colocation, variable and uncertain favors cloud. How much control does the workload genuinely require over the underlying hardware and configuration; regulatory or performance requirements that need deep control favor colocation. And how much capital is available for an upfront hardware investment versus an ongoing operating expense; this is often the deciding factor when the first two questions point in different directions.
Exit Flexibility Matters as Much as Entry Cost
Colocation contracts and cloud commitments both carry exit considerations worth pricing in before signing, not after. A colocation contract with a long minimum term limits flexibility if the workload's needs change; a cloud commitment with aggressive reserved-capacity terms carries a similar risk if usage comes in below projection. Neither model is inherently more flexible than the other once contract terms are accounted for, which is one more reason the decision should be made on the actual terms on the table, not on generic assumptions about which model is "more flexible" in the abstract.
Negotiating a Colocation Agreement Well
Colocation contracts carry their own negotiation levers that are easy to leave on the table. Power density pricing, how much is charged per kilowatt versus per rack, varies meaningfully between providers and should be compared on actual anticipated usage, not the facility's advertised capacity. Term length trades directly against rate: a longer commitment typically secures a better rate but reduces flexibility if the company's infrastructure needs change. And renewal terms deserve the same scrutiny as the initial agreement, since colocation renewals without a competitive benchmark tend to drift toward above-market pricing in exactly the way telecom and cloud contracts do.
Frequently Asked Questions
Is colocation becoming obsolete as cloud adoption grows? No. It remains the better fit for specific workload profiles, and plenty of companies run both colocation and cloud deliberately rather than migrating everything to one model.
What's the biggest mistake in this decision? Choosing based on industry trend rather than the specific workload's demand pattern. A predictable, steady workload doesn't automatically benefit from cloud's elasticity, since that elasticity isn't free.
Can a company move from cloud back to colocation if the economics change? Yes, though it's a real migration project, not a quick switch. Companies do reverse-migrate specific workloads when usage patterns stabilize and cloud's elasticity premium no longer pays for itself.
Does colocation make sense for a company planning to grow rapidly? It depends on whether growth is predictable or volatile. Rapid, predictable growth can still be planned for with colocation capacity; rapid, uncertain growth generally favors cloud's elasticity.
How does disaster recovery factor into this decision? Both models support strong DR strategies, but the approach differs. See Disaster Recovery & DRaaS Sourcing for how resilience planning changes between the two.
Where to Go Next
For the cost modeling behind this decision, see TCO in Cloud Computing. For the sbroader architecture question, see Hybrid Cloud Infrastructure..
