Load shape and egress decide it
For a hosting company this is not a philosophical argument. You already know how to run hardware. The question is whether your load shape and your egress bill make owning the metal cheaper than renting it, and at what size that flips.
We run both. Serverside.com and Host Havoc have racks in production and cloud in the mix, and the split moved over time rather than being decided once.
When owning the metal wins
- Steady-state load. If your utilisation curve stays within twenty percent of itself across a week, you are paying a cloud premium for elasticity you never use.
- High egress. This is the big one. Egress is priced per gigabyte in the cloud and per committed gigabit in colocation, and the two diverge hard past a few dozen terabytes a month.
- Predictable growth. If you can see eighteen months of capacity coming, you can buy hardware against it and amortise properly.
- Storage-heavy workloads. Disk is the cheapest thing you can own and one of the more expensive things you can rent.
- You already have ops. If someone on your team already replaces a disk at two in the morning, the marginal cost of a rack is far lower than the spreadsheet suggests.
When it doesn’t
We will say so when the answer is cloud, or when it is one or two units rather than a rack. We do dedicated racks, cages and suites; below that we point you somewhere better.
- Spiky load. Real ten-to-one peaks, seasonal or event-driven, are exactly what the cloud is good at.
- Small footprint. Below roughly one full rack the fixed costs (remote hands, spares, the minimum cross-connects, your own time) do not amortise.
- No ops team. Colocation is not managed. If nobody owns the hardware lifecycle the saving evaporates into incidents.
- Uncertain roadmap. If you cannot commit to eighteen months of capacity, do not sign thirty-six months of contract.
- Managed services you would have to rebuild. A managed database you would replace with two people and a runbook is not a saving.
A worked example
Take a mid-size hosting workload: 80 dual-socket servers, four racks, 5 kW committed a rack, a 36-month term, roughly 200 TB of egress a month and 400 TB of usable storage. Every share below is indicative and rounded. We show the shape rather than amounts, because the shape is what matters; amounts for your own workload are on request.
- Colocation, per month
- Hardware amortised over 48 months (longer than the 36-month term, because the servers outlive the contract) a little over half, colocation itself about a quarter, hands, spares and ops time about a seventh, transit and IX the remaining 5 percent
- Cloud equivalent, per month
- 80 instances on a three-year commit, each smaller than the dual-socket server it stands in for, just over half; egress about a quarter, object storage about a fifth. The total comes to roughly 1.8 times the colocation column
- Gap
- About 44 percent of the cloud bill, of which egress and storage are more than half
- Break-even
- Around one to two racks and 20–30 TB of monthly egress, depending on how much of your own time you count
Change two inputs and it flips
Drop egress to 20 TB a month and the gap narrows to something a finance team can argue about in either direction. Make the load spiky and the colocation column has to be sized for peak while the cloud column does not, which eats most of what is left.
That is the whole method. Model the two or three inputs that dominate your bill, and stop modelling the rest. The rack build-up itself is in the note on negotiating a rack price.
Egress is where it flips
If you only model one line, model this one. In colocation you buy a committed gigabit and pay a flat monthly; the marginal terabyte is close to free until you hit the commit. In the cloud you pay per gigabyte, forever, with discounts that soften the curve without changing its shape.
For a hosting company egress usually grows with revenue. So the cloud bill grows with revenue at roughly the same slope, while the colocation bill grows in steps when you add a rack or raise a commit. Over three years those are two different businesses.
Amsterdam helps here specifically. Sitting one cross-connect from the exchanges means a meaningful share of your traffic can be peered rather than transited, which pushes the cheapest line lower again. That is the point of an AMS-IX colocation footprint.
The hybrid answer, which is usually the right one
Almost nobody we work with is entirely one or the other. The pattern that keeps working: steady-state and egress-heavy on your own metal, spiky and experimental in the cloud, disaster recovery in whichever one you are not using for production.
- Baseline capacity in colocation, sized to the flat part of your curve.
- Burst and seasonal peaks in the cloud, with the images already built and tested.
- Object storage wherever it is cheapest for your access pattern, which is not always where the compute is.
- Control plane and CI in the cloud, because that load is small and spiky.
- A written exit on both sides. A colocation contract you cannot leave and a cloud footprint you cannot move are the same problem.
How to decide in a week
Pull twelve months of egress in gigabytes, your p50 and p95 utilisation, and your current cloud invoice split by line. Price a four-rack footprint against it. If the gap is under twenty percent, stay where you are; the move is not worth the risk. If it is over forty, start.
Send us the numbers and we will do the colocation side properly, with quotes from two or three operators. You contract directly with the datacenter; there is no markup either way.
