AI DeploySelf-hosted LLMGet it deployed

Check GPU Host SLAs for an LLM Deployment

Compare service credits, support, and claim steps; AWS's SLA sets 99.99% monthly uptime for qualifying multi-AZ EC2 and 99.5% for one instance.

An LLM deployment should be accepted only after the exact GPU service, SKU, Region, purchase model, and failure architecture are matched to the host’s written SLA. For llm hosting, verify the uptime promise and the conditions for a credit, then rehearse monitoring, incident-record collection, and the support claim path before production.

What should you verify in llm hosting SLAs?

An SLA percentage applies only after you match its covered unit, topology, storage, and exclusions to the deployed service. Treat it as an infrastructure commitment, not proof that your inference endpoint will answer. The provider-published terms below were checked on 2026-10-01 and may change, so verify the current page before signing.

Amazon EC2

AWS makes two separate commitments under its Amazon Compute Service Level Agreement: at least 99.99% monthly Region-Level uptime when all running instances are deployed concurrently across at least two Availability Zones in the same Region, and at least 99.5% Instance-Level monthly uptime for one instance.

For the Instance-Level SLA, “unavailable” means that the instance has no external connectivity. AWS says it will not charge for a single instance that is unavailable for more than six minutes of a clock hour, without requiring a claim.

Service credits are calculated as a percentage of the monthly bill, excluding one-time upfront payments such as Reserved Instance upfront fees. They apply against future EC2 payments rather than refunds, and a credit is issued only if it exceeds one US dollar ($1 USD). You must open a case in the AWS Support Center by the end of the second billing cycle after the incident. Region-Level and Instance-Level claims cannot be combined for the same instance, and service credits are the sole and exclusive remedy.

Google Cloud

The Google Cloud Compute Engine Service Level Agreement defines VM downtime as a loss of external connectivity or persistent disk access. Partial or intermittent downtime lasting less than one minute does not count. Read the current Google SLO table for its applicable percentage rather than inferring one from the definition of downtime.

You must notify Google technical support within 60 days of becoming eligible for a financial credit and provide logs showing each downtime period and its date and time. Total financial credits for a billing month cannot exceed the amount due for the affected covered services in Regions that did not meet the SLO. The financial credit is the sole and exclusive remedy.

The SLA excludes pre-general-availability features unless the associated documentation says otherwise, features explicitly excluded in that documentation, and errors caused by factors outside Google’s reasonable control.

Azure China

Under the Azure China virtual machine SLA, the connectivity commitment is at least 99.99% when two or more instances are deployed across at least two Availability Zones in the same Azure Region. For a single VM, the connectivity commitment is at least 99.9% when all operating-system and data disks use Premium SSD or Ultra Disk.

Submit a claim to customer support within two months after the end of the billing month in which the incident occurred. A service-fee credit is the sole and exclusive remedy and cannot exceed that month’s service fee. The SLA excludes problems caused by operations beyond the applicable service quota or by preview features.

Alibaba Cloud ECS

The Alibaba Cloud ECS SLA uses the calendar month as its service cycle. It commits to service availability of at least 99.975% for a single instance and at least 99.995% for the single-Region, multi-AZ dimension.

Compensation is limited to ECS vouchers and cannot exceed the single-instance monthly service fee paid for the month in which the target was missed. That monthly fee excludes amounts offset by vouchers, coupons, Savings Plans, and resource packages.

You may apply after the fifth working day for the previous month, but the application must arrive within two months after the relevant month ends. Later applications are not accepted. Exclusions include unavailability caused by your own stop, restart, or cloud-disk detachment through the console, API, or CLI; dependence on local-disk data; and suspension or release after non-payment. Some instance families have no SLA commitment, in which case charges generated during the fault are returned only as vouchers.

Map the host SLA to the LLM deployment

Create a record that maps the infrastructure SLA to the actual serving path. Include every serving instance, its Region and Availability Zone, persistent storage, network endpoint, and the traffic-routing arrangement. If the quote names a managed GPU service or bare-metal rental that is not named in the SLA, obtain the exact service terms before comparing them with an instance SLA.

For an AWS quote, read the Amazon EC2 billing and purchasing options before adding the lines. AWS documents On-Demand billing by the second; Savings Plans as a one- or three-year commitment to consistent usage measured in USD per hour; Reserved Instances as a one- or three-year commitment to a specific instance type and Region; and Capacity Blocks as an option for reserving a cluster of GPU instances.

Use a plain-text worksheet rather than relying on memory:

Provider legal entity | YOUR_VALUE
Service and GPU instance family | YOUR_VALUE
Region and Availability Zones | YOUR_VALUE
Purchase option | YOUR_VALUE
Running instance scope | YOUR_VALUE
Storage and network conditions | YOUR_VALUE
Monthly quote lines | YOUR_VALUE
SLA exclusions | YOUR_VALUE
Claim deadline and support destination | YOUR_VALUE

Fill each field from the current contract, quote, inventory, and provider documentation. Keep the purchase commitment and the SLA in separate columns: one describes how capacity is obtained, while the other defines coverage and remedies.

Calculate the claim outcome

Open the current bill or quote and list every line assigned to the affected service. Mark whether each line is recurring, one-time, discounted, or offset. Add only the lines that the applicable agreement identifies as eligible, then subtract its stated exclusions.

Use this worksheet formula:

ELIGIBLE_MONTHLY_BASE = SUM(ELIGIBLE_LINE_ITEMS) - YOUR_VALUE
CREDIT_OUTCOME = YOUR_VALUE

Fill YOUR_VALUE only from the current agreement. If it specifies a percentage, apply that rate to the eligible base. If it specifies a cap, fixed schedule, service-fee credit, or voucher, do not replace it with a percentage calculation.

For every provider, record:

  • The exact covered service and deployment topology.
  • The definition of unavailability used for a claim.
  • Whether the remedy is a bill credit, service-fee credit, financial credit, or voucher.
  • The eligible monthly base, exclusions, cap, and minimum issuance condition.
  • Whether the remedy can be applied only to future payments.
  • The claim deadline, support destination, and required logs or incident records.
  • Whether the agreement makes that remedy the sole and exclusive remedy.

If the current provider document does not state a rate, cap, submission channel, or exclusion, leave the field unresolved and request the missing term in writing before accepting the contract.

Verify monitoring and claim readiness

Translate the selected SLA into an observable signal rather than monitoring only model-process health. A process can still be running when the contractual connectivity or storage condition has failed.

The Prometheus alerting rules documentation distinguishes a pending alert from a firing alert: when a condition is active but its for duration has not elapsed, the alert is pending. The optional keep_firing_for setting keeps an alert firing for a specified period after its condition clears. Prometheus exposes active alerts through a synthetic ALERTS time series with an alertstate label.

ALERTS{alertname="YOUR_VALUE", alertstate="YOUR_VALUE"}

Replace both placeholders with values from your alert configuration, then use this sequence:

  1. Configure monitoring for the exact failure signal named in the selected SLA.
  2. During a controlled observation, confirm that the signal changes and that the alert moves through the expected states.
  3. Record the start and end time, affected instance, Region or zone, monitoring result, and relevant provider message.
  4. Confirm that logs, invoice lines, and deployment records can be retrieved together for a support request.
  5. Rehearse the documented submission path internally; do not file a claim unless the incident meets the agreement’s conditions.

Where SLA checks usually fail

  • Copying only the percentage: The covered unit, Region, number of instances, zone placement, and storage configuration may be part of the condition.
  • Confusing application health with infrastructure availability: Model errors or routing failures do not automatically establish that the contracted VM or network service was unavailable.
  • Treating every remedy as cash: A future-payment credit, service-fee credit, financial credit, and voucher have different contractual uses.
  • Waiting until an incident to find the deadline: Add the claim date, support destination, and responsible owner to the deployment record before production.
  • Relying on a live dashboard alone: Retain the underlying logs and instance records needed to reconstruct the incident later.

A deployment is ready for sign-off only when every worksheet row has an identified covered service, exact commitment, eligibility condition, remedy calculation, claim route, monitoring signal, and record owner. This is general information about the cited contract terms, not legal advice. These steps are compiled from the official documentation linked in the text and should be checked against the current version before use.

Sources