Managed Cloud Providers: Four Facts That Should Drive Your Selection

"Managed cloud provider" is a category that has gotten fuzzy in the last five years. It used to mean "someone who runs your VMs and applications on infrastructure they own." Now it covers everything from hyperscaler resellers to boutique Kubernetes shops to MSPs that rebranded the day AWS came out. The label does not tell you much.

After 20-plus years of delivering managed cloud services ourselves — and occasionally helping customers untangle relationships with providers who let them down — here are the four facts that should actually drive your selection. None of these show up on a typical RFP checklist, which is most of what is wrong with typical RFP checklists.

Fact One: Most Managed Cloud Providers Are Resellers Plus a Ticket Queue

A huge fraction of the companies that call themselves managed cloud providers are, structurally, resellers of hyperscaler capacity with a layer of tickets on top. They buy AWS or Azure at a discount, resell it to you at list or near-list, and handle support through their own helpdesk.

This is not inherently bad. A good reseller with a competent helpdesk can be a better experience than going directly to AWS or Azure, especially for mid-market customers who are too small for enterprise support. But it is important to know what you are buying.

Questions that reveal the model

• "Do you own any data center infrastructure, or is everything on hyperscaler accounts?" Not a gotcha — just tells you what the stack is.
• "If AWS has a regional outage, what happens to my workload?" A real managed provider has a plan. A reseller will point you at the AWS status page.
• "Who is on call at 3 AM for a performance issue, and what can they actually do?" The answer is usually one tier of junior engineers with limited access unless you pay for premium support.
• "What is your staff retention rate? How long has my account team been at the company?" Fast turnover in managed services is a red flag.

Nothing wrong with being a reseller. Wrong to pretend you are more than that when the contract is up for renewal.

When a reseller is the right answer

• You are small enough that direct hyperscaler enterprise support is out of reach economically
• Your workloads are standard enough that the reseller's playbooks cover them
• You want a single invoice, a named account manager, and a helpdesk you can call
• You do not need anything unusual — custom networking, bare metal, specialized hardware, on-prem integration

When a reseller is not enough

• You need real hybrid infrastructure with on-prem components
• Your workloads include specialty compute (high-density GPU, large-memory, HPC) that the reseller does not have deep experience in
• You need engineering that goes beyond ticket response — actual architecture work, performance tuning, migration planning
• You operate in a regulated industry where "we'll open a ticket with AWS" is not an acceptable response to a compliance question

Fact Two: The Billing Model Tells You the Incentives

A managed cloud provider's pricing model is the single best predictor of whether their incentives are aligned with yours. Read the contract before you read the marketing.

Providers that mark up consumption

A lot of managed providers bill you the underlying hyperscaler cost plus a percentage. This sounds reasonable and is often the wrong model. Why? Because the provider's revenue scales with your spend. The provider has an active financial incentive to not help you optimize cost. When you ask about right-sizing, they nod and file a ticket, but the nod is thinner than the ticket they would file if right-sizing cost them money.

We have seen this pattern play out. Customers with consumption-markup providers routinely pay 30 to 50 percent more than they should because no one on the provider side is motivated to find the savings.

Providers that charge fixed fees

A provider that charges a fixed monthly management fee independent of consumption has the opposite incentive. Optimizing your cost costs them nothing. If they are any good, they will find savings aggressively, because it is the easiest way to demonstrate value at the next renewal.

The disadvantage: fixed-fee models can feel expensive up front for small workloads. The advantage: the incentives are correct, and over three years the arithmetic is usually better for you.

Hybrid models

Some providers charge a fixed management fee plus a small passthrough on consumption. This can work if the passthrough is small enough that their profit is not dominated by your cost. Read the contract, do the math, and make sure the numbers actually align.

The honest test

Ask a prospective provider this: "If I found a way to cut my AWS bill by 40 percent next month, what happens to your revenue?" A provider whose honest answer is "nothing" has aligned incentives. A provider who hesitates or walks back the question has misaligned ones.

Fact Three: Response Time Means Nothing Without Authority

SLAs on a managed cloud provider's marketing page typically advertise aggressive response times. "15-minute response for P1 incidents." "1-hour response for P2."

That number is close to meaningless in isolation. What actually matters is what the responder can do within that window. A 15-minute response from a tier-1 engineer who can only file a ticket with the hyperscaler is not a 15-minute response to your problem — it is a 15-minute acknowledgment. The actual resolution might be hours later after the ticket escalates.

What to ask for instead

• Mean time to resolution for P1 incidents over the last 12 months. Raw data, not marketing copy. If the provider will not share it, that is a data point in itself.
• The skill level of the first-line responder. If the first person who picks up the phone can only read a runbook, you are paying for something different from "hands-on engineering."
• Whether the responder has write access to your environment. Some providers require a second layer of approval before any engineer can make changes, which is good for audit and slow for incidents.
• Examples of recent incidents and what was done. A good provider will have anonymized post-mortems they can walk you through. A weak one will not.

The 2 AM test

The test we use when evaluating a managed cloud provider is what we call the 2 AM test. It is this: "At 2 AM on a Saturday, my application stops responding. Who picks up the phone, what are they allowed to do, and how long before it is fixed?"

The answers tell you whether you are buying engineering or theater. Good answers sound like "our on-call engineer for your account has admin access to your environment, runbooks for common failures, authority to make changes, and a direct escalation path to senior engineers who know your stack." Weak answers sound like "we'll open a ticket and get back to you."

Fact Four: The Providers Who Survive Have Engineering Depth

The managed cloud provider industry has consolidated hard over the past five years. A lot of shops that looked viable in 2020 are gone — absorbed, bankrupt, or quietly pivoted to something else. The ones that survived share a property: they have real engineering depth, not just ticket-handling depth.

What engineering depth looks like

• Published, maintained internal tooling. Runbooks, automation, monitoring, infrastructure-as-code templates that are not just copy-pasted from the hyperscaler documentation.
• Engineers who can answer technical questions in a sales conversation. If you ask about how they would handle a specific architectural problem and the answer is "we'll get back to you," you are talking to sales, not engineering.
• A track record of handling unusual situations. Ask for three examples of complex migrations or troubleshooting. Vague answers are a warning.
• Tenure. How long have the senior engineers been there? A provider whose senior engineering team has been stable for years has the institutional knowledge to solve hard problems. A provider that lost its founding engineers two years ago is a different company than the one whose reputation you heard about.
• Opinions. A provider with engineering depth has opinions about tradeoffs. "It depends" is a reasonable answer to a lot of questions, but if every answer is "it depends" with no framework for deciding, they do not actually know.

Why it matters

The value of engineering depth is not about normal operations. Normal operations are automated and boring at any decent provider. The value shows up during migrations, during performance crises, during compliance audits, and during the annual "we need to cut cloud spend by 30 percent" conversation with leadership. Engineering depth is what lets a provider solve problems that do not have a runbook.

The Synthesis

When we help customers select a managed cloud provider, we do not send them to the analyst magic quadrants. We send them to these four questions:

• What are you actually buying — reselling, ticket handling, engineering, or some combination — and does the label match the reality?
• What are the billing incentives and do they align with your goal of controlled, optimized spend?
• What happens on a bad day, and does the person who responds have the skill and authority to fix things?
• Does the provider have the engineering depth to help you with hard problems, or only easy ones?

Get honest answers to those four, and the provider decision mostly makes itself. The providers who are good at the easy questions are plentiful. The providers who are good at the hard ones are rare and worth finding.