Ask a prospective managed cloud provider one question before you ask about price: what happens to your fee if our cloud bill drops 30% next quarter?
The answer tells you the pricing model, the incentive structure, and how the provider thinks about your interests, in a single sentence. It’s also a question most buyers never ask, because the invoice arrives looking like one number when it’s really two. One part is the compute, storage and egress you would have paid Amazon or Microsoft regardless. The other is the management fee for running it, and that fee is the actual subject of this page.
If you’ve arrived here from a per-user managed IT quote, you want a different comparison. Managed IT is priced per seat and covers laptops, accounts and helpdesk; we covered how those contracts get priced separately. Cloud managed services price the infrastructure layer, and the metrics have almost nothing in common.
The six shapes a management fee takes
Providers rarely name their pricing model in a proposal. They quote a number. Working out which of these produced it is most of the job.
| Model | How it is quoted | What it rewards | What it punishes |
|---|---|---|---|
| Percentage of spend | A share of your monthly cloud bill | Simple auditing, scales with you | Optimization, which shrinks the fee |
| Flat retainer | Fixed monthly or annual fee, add-ons priced separately | Budget predictability | Growth, until renegotiation catches up |
| Tiered packages | Three tiers with defined scope and resource caps | Clear scope boundaries | Anyone who grows past a cap mid-term |
| Pay-as-you-go | Consumption units: compute hours, storage, transfer, vCPU | Variable and seasonal workloads | Annual budgeting |
| Performance-based | Base fee against an SLA, credits on misses | Reliability you can point at | Nothing, if the credit is too small to matter |
| Gain-sharing | A cut of measurable savings realised | Actual cost reduction work | Buyers who could have found the savings themselves |
Four of those deserve detail.
Pay-as-you-go is where a CloudBolt breakdown works its 5% example: a management fee of 5% on a $10,000 monthly serverless bill, so $500, covering provisioning, monitoring, incident management and capacity planning. The same guide illustrates a standalone percentage model at 10%, which is $2,000 on $20,000 of monthly spend. A separate pricing guide puts the typical percentage-of-spend band at 15 to 25%, which is a fivefold gap against CloudBolt’s 5% floor and the clearest evidence available that no market rate exists.
Tiered packages in the structure CloudBolt describes run Basic as ticket-only support with caps on VMs, storage and transfer; Professional adding a shared customer success manager, capacity planning, and FinOps reports that identify savings without helping you capture them; Enterprise adding a dedicated account manager, custom integrations and a shared FinOps team on monthly or quarterly reviews. Read the middle tier slowly. “Identifies savings, doesn’t capture them” is a real and commonly missed distinction, and it’s the difference between a report and an outcome.
Gain-sharing varies its cut by how hard the work was. CloudBolt describes keeping 80% of the gains from re-architecting a client-server application onto Kubernetes or serverless, but only 20 to 30% from buying savings plans, because one is engineering and the other is a purchase order. Milestone variants apply a 10 to 15% credit from an early phase toward implementation.
Performance-based deals set a base fee against an SLA. CloudBolt’s example is $5,000 a month against 99.9% uptime with a 10% discount when the provider misses. Check that the credit is meaningful against what an outage actually costs you, because 10% of $5,000 is $500 and that doesn’t cover much.
None of these are exclusive. A single contract might carry all of the above in different sections.
The incentive problem, and what the source says on both sides
Percentage-of-spend deserves its own section because the arithmetic runs against you in a way the others don’t. We’ll state this as an opinion rather than a fact, because reasonable people in this industry disagree: we think unbounded percentage-of-spend is the wrong default for anyone whose main reason for hiring an MSP is cost control. Not dishonest. Just badly aimed.
At a 10% fee, a client spending $20,000 a month pays $2,000. Optimization that cuts spend to $18,000 cuts the fee to $1,800. CloudBolt’s own summary table puts it flatly: the model “won’t incentivize the MSP to optimize cloud spending.”
The management fee, in numbers
In fairness, the same guide argues the opposite elsewhere on the page, on the grounds that goodwill generated by prioritising client savings pays off over a long relationship. That’s a real argument and plenty of providers behave exactly that way. The point isn’t that percentage-of-spend providers are untrustworthy. It’s that you’re relying on a provider’s character to override its compensation, and if cost reduction is specifically what you’re buying, that’s a weak place to stand.
Three responses work better than hoping. The first is to bound the percentage with a floor and a ceiling, which keeps a shrinking bill from cratering the provider’s economics and removes the honest reason they resist optimization in the first place. The second is to fix the fee against an agreed baseline spend and reset it annually, so savings inside the year accrue entirely to you and the provider knows the reset is coming.
The third is to split the contract: percentage-of-spend for operations, gain-sharing for optimization work. That one carries a caveat we’ve made in the context of FinOps engagements, where savings-share sounds fair and often isn’t, because it pays a vendor a percentage of waste you would have found yourself with a fixed-fee audit. The distinction that rescues it is exactly the one CloudBolt’s own tiering makes. Gain-sharing on genuine re-architecture is buying engineering nobody on your team was going to do. Gain-sharing on reserved-instance purchases is paying a percentage for a decision that takes an afternoon. Scope any savings-share to the first kind and pay a fixed fee for the second.
A provider who insists on unbounded percentage-of-spend while marketing itself on cost optimization is selling two things that don’t fit together, and is worth asking about it directly.
What actually sits inside the fee
Scope is where quotes diverge much further than rate does, and it’s where a cheap-looking contract turns into a monthly argument. Ask about each of these by name.
On-call and incident response is the largest cost driver and the most commonly qualified, so establish whether 24/7 is included or an add-on, what the response-time commitment is, and what happens when it’s missed. Related but separate is the gap between monitoring and remediation: some contracts deliver alerts, some deliver someone fixing it at three in the morning, and the price difference between those is enormous while the proposal language often isn’t.
Then there’s who executes changes. If your engineers still write the Terraform and the provider reviews it, you’re buying oversight rather than capacity, which is a legitimate purchase at a different price. Capacity planning splits the same way, between real forecasting against your roadmap and a monthly utilisation PDF. FinOps splits as described above, between identifying savings and capturing them. Security patching and posture is frequently carved into its own line and occasionally not covered at all. And tiered packages cap VMs, storage and transfer, so model your growth against the caps before signing rather than after.
Normalise before you compare
Convert everything to an annual figure at your projected spend twelve months forward, not today’s. A 10% fee on today’s $15,000 a month is $18,000 a year; if you’re growing 60%, that same quote is $28,800 by month twelve while the flat retainer sitting next to it hasn’t moved. Providers quote against today’s bill and you’re signing for next year’s.
Then subtract the scope differences. If quote A includes 24/7 on-call and quote B bills incidents hourly, estimate B’s volume from your last six months of pages and add it in. If A’s FinOps tier only reports, price the engineer-hours you’ll spend capturing the savings yourself.
When managed services is the wrong purchase
Sometimes the fee buys you very little. If two or three engineers already run your infrastructure competently and the environment is stable, a management layer mostly adds a handoff. If your problem is one large architectural mistake, the wrong database or the wrong instance family or egress patterns nobody designed, that’s a fixed-scope engineering project rather than a recurring fee. Paying 10% of spend forever to manage a badly shaped environment costs more than reshaping it once, and reshaping it is what our cloud consulting practice does when the diagnosis comes back that way.
Managed services earns its cost when you need coverage you can’t staff across nights, weekends and holidays, when compliance demands documented operational process, or when your team’s time is genuinely worth more on product than on infrastructure. Those are good reasons. “Our cloud bill feels high” usually isn’t, and that one is a cost-optimization engagement with a defined end date and a lower price tag.
So ask the fee question first. A provider who has thought about it has an answer ready and will tell you which of the three fixes above it prefers. A provider who improvises is telling you something too.