DevOps Service Providers: What Does the Fee Actually Buy?

Three quotes from three DevOps service providers for the same work land within a few percent of each other, and each one is priced on a different mechanism. One sells a block of hours. One sells a fraction of an engineer. One sells a percentage of your AWS bill.

Those are not variations on a theme. The mechanism decides who loses money in a quiet month and whether the people you pay have any reason to shrink your cloud bill. Our position: buy capacity you can name against a scope you can read, and refuse a fee that grows with your spend unless the contract pulls the other way.

Why do two DevOps service providers at the same fee sell different things?

Because the fee is a price for availability, not for work, and the mechanisms sell availability in different units. A day rate sells somebody's time, a retainer sells your option on it, a percentage of the cloud bill sells you a share of your own growth.

Which humans land on the account is the other half of this, and we wrote that up separately in who actually shows up on your account.

What are the four ways this work gets priced?

Four, plus a fixed price for anything with an end date.

• Time and materials. An hourly or day rate against what you consume. Honest, and awkward to budget, because your worst month is your biggest invoice.
• A retainer. A block of hours a month, discounted against the day rate, usually expiring on the last day of the month.
• Dedicated capacity. A named fraction of named engineers, billed whether you use it or not. Closest to a payroll line, and easiest to compare against hiring.
• A fee tied to the estate. Per account, per cluster, per node, or a percentage of what you spend with AWS.

A mix is sensible: dedicated capacity for the platform, time and materials above it. What goes wrong is a single number whose mechanism nobody wrote down, which both sides then read in their own favour for a year.

What happens to a retainer in a quiet month?

In most contracts, nothing. The hours lapse and you buy them again on the first. So the vendor's best month is the one where you ask for little, and the month you need everything is the month you go over the block and pay the premium rate on top.

None of that is a reason to refuse a retainer. Three things to settle first:

• Do unused hours roll forward, and for how long? A month of carry is worth more than a bigger block.
• What is the rate above the block, and is it the same rate at 3am as at 3pm?
• Are incident hours drawn from the block or billed separately? If an outage eats your planned work, the retainer bought you nothing.

Hours that never expire are no better. They become a bank you never draw down, because the engineer who would do the work is on three other accounts this quarter. Hours are an accounting unit; capacity is what you need.

Should anyone bill you a percentage of your AWS spend?

Not on its own, no. It points the wrong way at the job you most want done. A partner on four percent who halves your EC2 costs has just cut their own revenue, and nobody should be asked to do that out of principle.

AWS prices its own support this way and still tapers it. The published Support plans put Business Support+ at "whichever is greater: $29/month per account" or "9% of monthly AWS charges up to $10K", then 7% from $10K to $80K, 5% to $250K and 3% above that. Enterprise Support works the same way from a $5k floor. A floor, so small accounts are not free to support, and a taper, so the fee does not grow in a straight line. AWS is also not the party advising you to spend less with AWS.

Hold a provider to the same shape: a floor, a taper, a ceiling in absolute rupees or dollars, and a cost reduction target in the service levels. Then establish which number the percentage applies to, because unblended, net amortised and post-credit spend can differ by a fifth on the same account; that choice is in which cost number to report in a FinOps practice. A percentage of "your AWS bill" with no definition is a term nobody can audit, including you.

What does round-the-clock cover actually cost to staff?

More than most proposals price in, and the arithmetic is public. Google's SRE book, writing about its own rotations, says "the minimum number of engineers needed for on-call duty from a single-site team is eight", and for teams split across two sites that "a reasonable minimum size of each team is six". The same chapter caps load at "2 per 12-hour on-call shift" and keeps on-call under a quarter of an engineer's week.

Read that against a quote. A fee that buys one and a half engineers cannot also fund a rota covering nights, weekends and Indian public holidays on your account alone. A rota shared across several clients can, and that is a legitimate product. The question is whether you were told which one you bought.

So ask, without suspicion in the asking. How many engineers are on the rota, and how many accounts does it cover? What is the first response commitment, in minutes, by severity? What happens on the second simultaneous incident, when yours is not the payments outage? Hold the answers against carrying the rota yourself, which we costed in the hire or bring in a team comparison.

Which of these does the RBI expect to be written down?

More than teams expect. The Outsourcing of Information Technology Services Directions, 2023 ask the agreement to carry, at Para 16(vi), "the deliverables, including Service-Level Agreements (SLAs) formalising performance criteria to measure the quality and quantity of service levels". Quantity as well as quality, which a block of hours does not supply.

Para 19(1) wants a management structure to monitor and control outsourced IT activities, covering "performance, uptime of the systems and resources, service availability, adherence to SLA requirements". Para 22 asks for "a clear exit strategy" and obliges the provider to "cooperate fully with both the RE and new service provider(s)" on the way out.

That gives you a test for any pricing mechanism. Can it be stated as a service level, read monthly by your own people, and unwound on a date? A retainer of hours fails the first. A percentage of spend with no definition fails the second. The full clause set is in what the RBI expects in a DevOps outsourcing contract, and the numbers worth putting in an SLA are in how to measure a DevOps engagement.

What can you run on Monday?

Two jobs, about an hour, both producing something you can send.

First, price the proposal against your own account, not against the rival proposals. Pull six months of spend:

aws ce get-cost-and-usage \
  --time-period Start=2026-04-01,End=2026-10-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --query 'ResultsByTime[].{month: TimePeriod.Start, usd: Total.UnblendedCost.Amount}' \
  --output table

The end date is exclusive, so that window ends with September. The console is free but the API is not: AWS's Cost Explorer documentation notes that "each paginated API request incurs a charge of $0.01". Divide the monthly fee by each of those six numbers and you have the percentage of spend the quote really represents, to hold against the AWS tapers above. Ten percent for a part-time arrangement is not automatically wrong, but it is a number to say out loud.

Second, the scope table. Twelve rows, and every provider marks each one as included in the fee, billed hourly, or not covered:

1. First response to a production incident, by severity
2. Patching operating systems and rebuilding base images
3. Kubernetes or EKS version upgrades
4. Terraform provider and module upgrades
5. Fixing the CI pipeline when it breaks
6. Onboarding a new service onto the platform
7. Quarterly IAM review and access changes
8. Backup verification and restore drills
9. The half-yearly DR drill, if you are regulated
10. Monthly cost review, and acting on what it finds
11. Audit evidence packs and answering auditor questions
12. Writing the incident report your regulator wants inside six hours

Rows 9, 11 and 12 are where the replies diverge most, and they cost you a weekend when nobody owns them. Keep the marked-up tables; they are the only like-for-like comparison you will get.

When is the day rate the honest answer?

Often. A team that needs three days of help a month should buy three days, not a retainer it underuses. Work with an end date and a written scope is better bought at a fixed price, because the risk of the estimate then sits with the people who made it.

Even the percentage of spend has its case, where a provider runs the whole estate, holds the pager and can change the architecture. And sometimes the answer is nobody: steady platform work with no compliance deadline inside the year, that one good engineer can hold, belongs in-house.

We sell this work, so read that as interested advice. What we would hold any provider to, ourselves included, is a mechanism you can explain to your board in one sentence and a handover that is already paid for before anyone leaves.

The short version

• Ask which of the four mechanisms you are being quoted, in writing. Day rate, retainer, dedicated capacity and a fee tied to the estate are different products at the same number.
• On a retainer, settle rollover, the rate above the block, and whether incident hours come out of it.
• If a fee tracks your cloud spend, make it taper, cap it, define which spend number it applies to, and put a reduction target in the service levels.
• Send the twelve-row scope table to every provider. The rows about DR drills, audit evidence and the regulator's incident report separate the replies.

This is engineering guidance, not legal advice. Regulations and their annexures are amended over time; read the current text and take your compliance position from counsel.