CPU as a Service contract

Create my notebook

CPU as a Service contract

A CPU-as-a-Service contract is not just a purchase document. It is the instrument that turns an abstract promise — “we provide compute” — into something a customer can measure, pay for, enforce, and exit. If the agreement is drafted well, it answers three practical questions from the start:

  • What exactly is being sold? Compute capacity, interfaces, support, and any included management features.

  • What controls the risk? Security, data protection, support duties, change management, liability, and termination rights.

  • What makes it enforceable? Clear metrics, pricing units, schedules, remedies, and named responsibilities.

The trap is to write this kind of agreement in marketing language. “High-performance compute,” “elastic capacity,” or “enterprise-grade availability” sound useful, but they do not tell either side what must actually be delivered. A working contract translates service into terms like vCPU hours, reserved capacity, uptime percentage, response time, invoice period, and defined remedies when service levels are missed. Cloud service agreements and SLA guidance consistently stress that service expectations, measurement methods, support obligations, security commitments, and remedies all need to be expressed in concrete terms, not slogans .

What the service actually is

A CPU-as-a-Service contract fails early if it never turns 'compute' into a measurable service definition.

Start with the simplest idea: the supplier is not selling “performance” in the abstract. The supplier is selling access to a defined compute resource under defined conditions. Usually that means some combination of:

  • Virtual CPU capacity made available on demand or as a reserved allocation

  • Burst capacity above a baseline allocation, often at a different price

  • Provisioning rights through an API, dashboard, orchestration tool, or ticketed request flow

  • Management interfaces for creating, resizing, monitoring, or terminating compute instances

  • Associated control-plane functions such as usage reporting, access management hooks, and event logs

This section matters because a compute service is easy to blur with neighboring services. Storage, networking, load balancing, backup, database hosting, and managed applications often sit next to CPU consumption, but they are not the same promise. If they are included, the contract should say so expressly. If they are not included, the contract should also say so expressly. Otherwise the customer assumes they bought an outcome when they only bought a resource layer.

The service description should answer five basic questions

  1. What is the unit?
    Is the unit a vCPU, a vCPU-hour, a reserved pool, a dedicated host slice, or some equivalent compute token?

  2. How is access delivered?
    Through self-service provisioning, provider-managed deployment, an API, a console, or all of them?

  3. What is included with the CPU service?
    Monitoring, autoscaling hooks, usage dashboards, support access, or nothing beyond raw compute?

  4. What is excluded?
    Storage persistence, network transit, software licensing, guest operating system management, application tuning, and managed security services should be called out if they are outside scope.

  5. Who can use it and for what?
    The agreement should define authorized users, workloads, region limits, and acceptable-use restrictions.

The contract needs units that billing and operations can both understand

A good unit does two jobs at once:

  • it tells the operations team what to provision

  • it tells the finance team what to invoice

That is why contracts for cloud-style services usually tie the service definition closely to the charging model and SLA language [2]).

For a CPU-focused service, useful units often include:

  • Allocated vCPU count

  • Consumed vCPU-hours

  • Reserved baseline capacity

  • Burst usage above baseline

  • Provisioning time

  • Availability of the control plane

  • Support response times

The trap here is to think “CPU” is self-explanatory. It is not. A vCPU in one environment may reflect a time-sliced share of a physical processor; in another, it may map to a dedicated thread or a pinned core allocation. The contract does not need to teach hardware architecture, but it does need to define what commercial and operational commitment the unit stands for.

A useful way to describe the service

Think of the service definition as a sentence with four parts:

  • Resource: what compute is made available

  • Access method: how the customer uses or requests it

  • Service boundaries: what is and is not included

  • Measurement unit: how usage, performance, and charges are counted

If any one of those is missing, the agreement becomes hard to operate. Sales may still sign it. Finance may still invoice it. But when there is a dispute, nobody can point to one clean sentence and say, “This is the service we actually bought.”

Capacity, performance, and availability metrics

Once the service is defined, the next layer is measurement. This is where many agreements sound precise but are still weak. They promise capacity, speed, and uptime, yet never say how those things are measured, over what period, from whose monitoring system, or what happens if the number is missed.

A helpful distinction is:

  • Capacity = how much compute is allocated or available

  • Performance = how that compute behaves under stated conditions

  • Availability = whether the customer can access and use the service at all

Those are related, but they are not interchangeable. A customer can receive the promised number of vCPUs and still suffer poor performance if the environment is oversubscribed. A service can remain “available” while provisioning requests take too long to be useful. This is why SLA drafting guidance stresses measurable criteria, responsibilities, and remedies rather than headline promises alone .

What the contract should measure

For CPU-as-a-Service, the important anchors usually include:

  • Allocated vCPU count or reserved capacity baseline

  • Provisioning latency for creating or scaling compute instances

  • Availability percentage over a stated measurement period

  • API or console responsiveness for core control-plane actions

  • Contention or oversubscription limits if relevant to the offering

  • Maintenance windows and whether they are excluded from uptime calculations

  • Incident response timing for severe outages

  • Measurement source and sampling method

If the supplier is making a stronger performance promise — for example, dedicated CPU classes, pinned cores, or specialized workloads — the contract may also need to specify the equivalent performance commitment, benchmark method, or workload assumptions. Otherwise “high performance” becomes a fight about expectations instead of a clause.

The hidden issue: measurement method

A metric without a measurement method is like a ruler with no markings.

The contract should say:

  • what tool or log is authoritative

  • how often measurements are sampled

  • whether scheduled maintenance is excluded

  • whether customer-caused failures are excluded

  • how quickly the customer must report an SLA claim

  • whether the remedy is automatic or only available on request

That last point matters. An uptime promise without a remedy is mostly reputation. An uptime promise with service credits, repeated-breach escalation, or termination rights becomes a commercial obligation .

Capacity promises are not the same as SLA promises

A common misunderstanding is to treat all technical commitments as one clause. They are usually better separated:

  • Service definition: what resource the customer receives

  • Capacity/performance commitments: how much and how well

  • SLA: what threshold counts as failure and what remedy follows

That separation keeps the agreement readable. It also helps when one promise fails but another does not.

Vague metrics create precise disputes.

Commercial structure: pricing, billing, and term

Once the technical unit is defined, the business deal has to mirror it. If the contract measures service in vCPU-hours but invoices by an undefined monthly “platform fee,” the commercial schedule and the service schedule are already drifting apart.

Most cloud-style contracts use one or more of these models:

  • Pay-per-vCPU-hour for pure usage pricing

  • Reserved capacity commitments for predictable baseline demand

  • Burst or overage pricing for consumption above a committed floor

  • Minimum monthly spend to guarantee provider economics

  • Prepaid credits that are drawn down as compute is consumed

The agreement should then say how charges are administered:

  • invoice frequency

  • payment due date

  • currency

  • taxes

  • disputed invoice process

  • consequences of late payment

  • whether unpaid amounts can trigger suspension

This is not just finance language. It determines how the customer experiences the service. For example, a one-year reserved-capacity deal with monthly true-up billing behaves very differently from a pure on-demand service, even if both technically deliver the same CPU resource.

Cloud contract guidance repeatedly points to the need to align service descriptions, uptime commitments, data handling, support, and pricing terms so that the customer knows what it is paying for and what rights attach to that spend .

Three pricing shapes that show up often

1. Usage-only

Best when demand is variable.

  • Customer pays only for measured consumption

  • Unit is usually vCPU-hour

  • Good for unpredictable workloads

  • Harder for the customer to forecast

2. Reserved baseline plus overage

Best when the customer has a stable floor and occasional spikes.

  • Customer commits to a baseline volume

  • Baseline gets a lower rate

  • Usage above baseline is billed at an overage rate

  • Often paired with term commitments

3. Minimum spend with service credits

Best when the provider offers a broader platform and wants revenue certainty.

  • Customer commits to a minimum monthly amount

  • Charges may be offset by service credits

  • Unused commitment may or may not roll forward

  • Contract must define how credits are applied

Term and renewal matter more than they look

A pricing model only makes sense in context of the term:

  • month-to-month

  • fixed annual term

  • multi-year committed capacity

  • auto-renewing unless notice is given

The trap here is to focus on the rate card and ignore renewal mechanics. A favorable rate can become expensive if the agreement auto-renews before the customer can reassess usage, or if committed capacity cannot be reduced during the renewal term. That is why notice windows, non-renewal rights, and ramp provisions deserve their own attention.

Writing a usable pricing schedule

A pricing schedule should read like a spreadsheet that survived contact with lawyers. It must be simple enough for a business team to review quickly, but precise enough that billing, audit, and dispute handling do not depend on memory.

At minimum, a pricing table for CPU-as-a-Service should include:

Why ambiguity survives longer than you think

Technical teams often assume that if the system can meter usage, the contract is fine. That is not enough. A billing engine can produce a number without telling you whether the number was the one the parties legally agreed to use.

For example, these phrases look harmless but create disputes:

  • “additional usage billed at standard rates”

  • “capacity priced according to provider schedule”

  • “credits applied where appropriate”

  • “usage determined by provider records”

Each one needs a definition. Which standard rates? Which schedule version? Applied automatically or on request? Are provider records conclusive, or can the customer challenge them?

A practical drafting shape

A usable pricing schedule usually works best if it separates the stable parts from the variable parts:

  • Stable terms

    • unit definitions

    • currency

    • invoice cycle

    • payment terms

    • taxes

    • credit rules

  • Variable terms

    • baseline volume

    • overage rate

    • promotional pricing

    • ramp periods

    • renewal pricing changes

That split keeps amendments cleaner. The legal framework stays put; the commercial numbers can be revised in order forms or renewal schedules.

The teaching point is simple: if the pricing language cannot be turned into one clean invoice formula, it is not ready.

Security, data protection, and compliance allocation

Even a CPU-focused service processes more data than people first assume. Management consoles, API calls, telemetry, logs, identity information, workload metadata, and support records can all contain customer data, personal data, or commercially sensitive information. So the contract cannot say, “This is only compute, therefore data protection is irrelevant.”

Security clauses in service contracts usually need to allocate at least six things:

  • Infrastructure security duties of the provider

  • Access control and authentication expectations

  • Incident notification timing and content

  • Logging and audit support

  • Use of subprocessors

  • Backup, retention, and deletion scope

Security and privacy guidance for cloud and service contracts consistently stresses getting these commitments into the contract itself, not leaving them at the level of marketing statements . Data-processing terms also matter because the processor’s obligations, assistance duties, and liability for security breaches should be express rather than implied .

What belongs on the provider side

The provider should usually commit to things such as:

  • securing physical and host infrastructure

  • controlling privileged administrative access

  • maintaining reasonable technical and organizational security measures

  • notifying the customer of security incidents within a stated period

  • identifying subprocessors or at least giving notice of material changes

  • stating where backups, logs, or telemetry are retained if relevant

What belongs on the customer side

The customer should usually own:

  • lawful use of the service

  • account and credential management

  • guest workload configuration

  • application-layer security

  • encryption choices inside the workload if not provider-managed

  • data classification and regulatory suitability of the workloads it places on the platform

The trap here is to think “security” is one promise. It is actually a stack of promises at different layers. The provider may fully secure the host platform while the customer still misconfigures an exposed workload. A good contract makes that boundary visible.

Compliance language should be proportional

Not every CPU service needs a giant regulatory schedule. But if the customer cares about data residency, sector-specific rules, audit rights, breach notice timing, or subcontracting controls, those items should not be left implied. The more regulated the workload, the less room there is for generic security language.

Who is responsible for what in the shared-responsibility model

Shared responsibility is easy to say and easy to misunderstand. The cleanest way to remember it is this:

  • the provider secures the platform it operates

  • the customer secures the workloads it deploys on that platform

That sentence is incomplete, but it gives the right starting picture.

Provider responsibilities

These usually include:

  • Physical infrastructure security

  • Host operating environment protection

  • Hypervisor patching and hardening

  • Control-plane monitoring

  • Platform logging relevant to SLA and incident handling

  • Availability reporting

  • Security of provider-managed administrative tools

Customer responsibilities

These usually include:

  • Guest operating system hardening

  • Workload and application patching

  • Secrets management

  • IAM role and permission configuration

  • Encryption choices within workloads, unless the provider manages them

  • Vulnerability management for software the customer installs

  • Lawful processing of data placed into the service

Where people get confused

The trap is to think the provider’s security promise follows the workload all the way up the stack. Usually it does not.

A child-friendly analogy works here: if the provider rents you a secure apartment building, the provider must maintain the doors, locks in common areas, electricity, and hallways. But if you leave your own apartment door open, that is your responsibility. In compute terms, the building is the host platform; the apartment is the guest workload.

Why this matters in the contract

If the agreement only says the provider will use “industry-standard security,” disputes become moral arguments. If it instead names the boundary — host layer, hypervisor, platform telemetry, customer IAM, customer guest patching — each side knows what it must actually do.

Support, change management, and outage handling

A compute service is judged most harshly on bad days. That is why support and operational governance clauses matter so much. They decide how quickly the provider reacts, how changes are announced, what counts as an emergency, and how customers are kept informed during an outage.

At minimum, the contract should define:

  • Support channels: portal, email, phone, API ticketing

  • Support hours: business hours or 24/7

  • Severity levels: for example, critical outage, major degradation, minor issue

  • Initial response targets

  • Resolution or workaround targets, if the provider is willing to commit to them

  • Maintenance notice windows

  • Emergency change rights

  • Incident communication cadence

SLA and HaaS-style service guidance both emphasize that measurable service standards should include not just uptime, but also operational responsibilities, customer dependencies, and issue handling expectations .

Support tiers should match business impact

A common mistake is to define severity only from the provider’s perspective. Better drafting defines severity by customer effect.

For example:

  • Severity 1: complete loss of service or inability to provision or access critical compute

  • Severity 2: major degradation with no reasonable workaround

  • Severity 3: partial impairment or non-critical feature failure

  • Severity 4: informational request or minor defect

That helps response obligations line up with actual urgency.

Change management is where reliability quietly lives

The service will change over time. APIs evolve. Dashboards are redesigned. Capacity classes are retired. Maintenance windows shift. If the contract says nothing about this, the provider keeps broad operational discretion and the customer absorbs the surprise.

Useful change-management clauses cover:

  • advance notice for material changes

  • emergency-change exceptions

  • backward compatibility expectations

  • deprecation windows for APIs or management tools

  • customer communication paths for planned maintenance

  • whether major changes trigger termination or migration rights

Outage handling should be procedural, not emotional

In a serious outage, people do not need beautiful language. They need a predictable process.

A workable outage clause often answers:

  1. How does the provider classify the incident?

  2. How quickly must it acknowledge the issue?

  3. How often will status updates be sent?

  4. When are service credits triggered?

  5. When does repeated failure become a termination event?

That last step is crucial. Service credits are useful for short incidents. They are often inadequate for chronic instability. Guidance on uptime commitments notes that repeated failure is often tied to escalation rights, including termination .

Liability, termination, and the schedules worth attaching

The main body of the agreement says who owes what; the schedules are where the service becomes concrete.

This final layer is the difference between a readable contract and an enforceable operating document. The main agreement can define the legal framework, but the attached schedules carry the specifics that people actually use: service levels, security controls, support process, and pricing mechanics.

Liability and risk allocation

The contract should address:

  • Limitation of liability

  • Excluded damages

  • Carve-outs for items the parties do not want capped in the usual way

  • Indemnity structure, if one is included

  • Responsibility for breach-related costs where security or processing obligations are violated

Data-processing language often makes clear that a processor remains liable for subprocessor acts and for failures tied to its own security obligations . That kind of allocation matters because not every failure should be folded into one generic liability cap.

Termination rights should match the service model

There is a big difference between:

  • termination for convenience

  • termination for cause

  • termination after repeated SLA failure

  • suspension for non-payment or misuse

A customer using compute for live production workloads needs to know not just how the agreement can end, but how much warning and transition support it gets. Contract guidance also highlights the importance of data portability and exit provisions rather than assuming customers can leave cleanly on their own .

Transition, return, and deletion

Even when the service is “just compute,” the exit process still matters because the platform may hold:

  • machine images

  • configuration data

  • access records

  • telemetry

  • logs

  • support history

  • backups or snapshots if included

The agreement should say:

  • what the customer can retrieve

  • in what format

  • during what post-termination period

  • what assistance, if any, the provider must give

  • when data is deleted

  • what copies may be retained for legal or security reasons

The schedules worth attaching

A CPU-as-a-Service agreement is usually stronger when it attaches at least these exhibits:

  • Service description / order form

    • units, regions, environments, included features

  • SLA schedule

    • uptime, measurement method, exclusions, credits, escalation rights

  • Pricing schedule

    • baseline, overage, invoice cycle, taxes, currency, credit treatment

  • Support schedule

    • severity levels, response times, support hours, communication path

  • Security schedule

    • controls, incident notice, subprocessors, logging, audit position

  • Data processing schedule

    • roles, instructions, subprocessors, breach support, deletion obligations

A practical enforceability checklist

Before signing, the reader should be able to answer yes to these questions:

  • Is the compute unit clearly defined?

  • Is billing tied to that exact unit?

  • Are uptime and performance measured in a stated way?

  • Are remedies attached to service failures?

  • Are provider and customer security duties separated?

  • Are support and outage procedures written down?

  • Are termination and exit mechanics usable in real life?

  • Are the key schedules attached and internally consistent?

If the answer is no to several of these, the agreement may still look polished. It is just not ready to carry a real service relationship.