Who this is for. MSP owners and finance-minded technical leads who want the hosting line of the business to make money on purpose rather than by accident. This article gives you the structure of the model. It deliberately contains no market prices, because they differ by supplier, region, contract and date, and any figure printed here would be out of date or wrong for you. Where the examples use numbers, they are arbitrary units chosen to make arithmetic visible.
What you must find out for yourself
A hosting cost model has inputs that only you and your suppliers can supply: what you pay for hosts or capacity, what licensing costs for the software you host, what network transit and storage cost, what your staff time costs. Collect them in writing. Where a supplier will not state a figure until a quote, record it as unknown and treat any model that guesses it as a draft. The structure below tells you which unknowns matter most.
Cost pools and how each behaves
The main mistake in hosting economics is treating every cost as if it were per tenant. Costs behave in three different ways, and a model has to respect that.
| Cost pool | Behaviour | Driver | Allocation approach |
|---|---|---|---|
| Hosts, storage arrays, switches | Stepped: bought in lumps | Peak demand plus failure headroom | Spread over tenants by reserved or peak resource share |
| Hosting software and licences | Mixed: often per core, per VM or per user | Defined by the licence terms | Direct to the tenant that uses it, where measurable |
| Backup storage | Variable, grows with retention | Data size x change rate x retention | Direct per tenant by stored volume |
| Network and transit | Fixed commitment plus variable | Uplink size and traffic | Mostly platform; direct for heavy users |
| Management plane and tooling | Fixed | Platform existence | Spread evenly or by tenant count |
| People: engineering, on-call, support | Semi-fixed, rises in steps | Tenant count and incident rate | By tenant count, weighted for complexity |
| Onboarding and offboarding effort | One-off per tenant | Complexity of the estate | Recover with a one-off fee or amortise explicitly |
Plenty of hosting lines look profitable on paper because the stepped and semi-fixed pools are quietly ignored: the cost of the next host is invisible until it is purchased, and the engineer’s on-call week is paid out of the general payroll.
Stepped capacity: why unit cost swings
Capacity arrives in lumps, so the cost per unit of sold capacity depends on how full the lump is. A worked example in arbitrary units:
- One host costs 100 units a month and provides 50 units of capacity.
- If you sell 30 units on it, each unit of sold capacity costs 100 / 30 = 3.33 units.
- If you sell 50, each costs 100 / 50 = 2.0.
- The moment you sell 51, you need a second host: 200 units for 51 units sold, or 3.92 each.
Margin per unit therefore changes sharply around a step, and the next tenant you win can be the one that forces a purchase. Two consequences follow. First, price new tenants against the marginal cost of the capacity they trigger, not only against the average cost. Second, a tenant who arrives just after a step is cheap to add, which is a useful fact in pricing conversations and a hazard if it becomes a habit of underpricing.
The cost of headroom
Failure tolerance is a cost you pay without selling it. If your design needs N-1 hosts to carry the load, as described in virtual servers and capacity planning, then one host’s worth of capacity is held in reserve. With five hosts, that reserve is a fifth of what you pay for. Add the ceiling you set for utilisation during a failure and the share of capacity you can actually sell is smaller still.
A simple expression for sellable capacity:
sellable = (N - 1) x C x u_design
cost per sold unit = (N x host_cost + other platform costs) / (sold units)where N is the number of hosts, C is the capacity of one host, and u_design is the utilisation you are willing to plan for. The numbers are yours; the point of writing them out is that the 20 percent you did not sell appears in the formula rather than in a surprise.
Allocation keys: how a shared bill reaches a tenant
You need an allocation rule to turn pooled costs into a per-tenant cost, and the rule shapes behaviour. Common keys, with their trade-offs:
- Per virtual machine. Easy to explain and to bill, but it rewards oversized VMs and ignores very different resource use between VMs.
- Per reserved resource (cores, memory, storage allocated). Aligns with what you must provision and with what the tenant controls, but tenants dislike paying for what they do not use.
- Per measured use (peak or 95th-percentile consumption). Fair when usage is steady, volatile when it is not, and needs reliable metering.
- Per tenant bundle with an agreed envelope and an overage rule. Simple to sell. It hides outliers unless you monitor each tenant against its envelope.
A practical hybrid is a base charge for the reserved envelope plus separately metered items that are expensive and variable: backup storage, network transfer and licences. Whatever you choose, make the key visible in your own model even if the client sees a simpler price.
A margin model you can fill in
Per tenant, per month:
margin(t) = revenue(t)
- allocated_platform(t) # share of hosts, storage, network, tooling
- licences(t) # direct, from the licence terms
- backup_storage(t) # data x change rate x retention
- support_cost(t) # tickets, on-call, account time
- amortised_onboarding(t)A worked example in arbitrary units for three tenants sharing a platform whose pooled cost is allocated by reserved resources:
| Tenant X | Tenant Y | Tenant Z | |
|---|---|---|---|
| Revenue | 100 | 100 | 100 |
| Allocated platform | 40 | 40 | 70 |
| Licences | 15 | 15 | 15 |
| Backup storage | 8 | 8 | 25 |
| Support cost | 10 | 10 | 30 |
| Margin (onboarding cost left out for simplicity) | 27 | 27 | -40 |
Tenant Z earns the same revenue as the others and loses money, because it reserves more, stores more and generates more support. The average margin of the three looks fine, which is how tenants like Z survive in a business. The model reveals them; the next question is whether to reprice, to cap, to move Z to dedicated capacity at a different price, or to accept the loss for strategic reasons.
Pricing structure without prices
This site does not suggest what to charge. It suggests what the structure should do.
- Cover the stepped costs. Tie price to the resources that trigger purchases, not to a flat per-user figure that ignores them.
- Separate the variable, expensive items so that growth in backup data or transfer is billed where it arises.
- Make the heavy tenant visible. A commitment plus overage, or tiered envelopes, shows outliers before they erode the line.
- Price isolation as a feature. Dedicated capacity, longer retention, tighter recovery objectives and special compliance handling have real costs; give them real line items.
- Charge for onboarding and offboarding or amortise them openly. Migrations are work, and see migration and tenant onboarding for how much.
Commercial terms that change your costs
Questions to put to a hosting supplier, because the answers are unknown until they say them:
- Are there minimum commitments or term lengths, and what happens if you shrink?
- How is capacity added: step sizes, lead time, and whether you pay from order or from delivery?
- Are there charges for data transfer in, out or between locations?
- How are software licences reported and billed, and what applies when a tenant leaves?
- What are the charges for support beyond the standard offering, and for out-of-hours work?
- What does exit cost: data export, transfer, assistance, and overlapping runtime while you migrate?
Evaluating a hosting provider expands these into a full evidence checklist.
Common mistakes
- Averaging across tenants and missing the ones that lose money.
- Pricing from current cost while ignoring that the next tenant triggers a purchase.
- Forgetting headroom, so the sellable capacity is overstated by the share you reserve for failure.
- Letting backup retention grow unpriced. Storage cost scales with data, change rate and retention, and clients rarely volunteer smaller numbers.
- Treating support as free. Time spent on one noisy or complex tenant is cost.
- Copying another business’s margin target without your own cost structure underneath it.
- Fixing the model once. Costs change; re-run it whenever a supplier price, licence term or tenant mix changes.
What to do next
Build the three-tenant version in a spreadsheet using your own unknowns, marking each unknown as unknown until a supplier confirms it. Then run the requirements planner to see which of your requirements (strong isolation, short recovery times, regulated tenants) carry extra cost, and read multi-tenant isolation for how to decide which tenants warrant them.