contract, agreement, signing a contract, document, signature, business deal, contract, contract, contract, contract, contract, agreement, signature, signature, signature, signature
Photo by Tumisu on Pixabay

Governance

Part of Cloud vendor due diligence

Reviewing cloud service commitments before procurement

Read a cloud SLA's coverage, conditions, exclusions, credits and claim process before signing a service agreement.

Desk Cloud Governance · · 5 min read

Before procuring a cloud service, map each commitment to the proposed service, region, tier and deployment pattern. Check its failure definition, target, conditions, exclusions, credit calculation and claim process against the governing terms. Treat anything unresolved as a procurement question, not assumed protection.

Find the applicable terms

List the services on the proposed application's critical path and locate each applicable SLA and purchase agreement. Record the region, tier, deployment pattern and any preview component. A reseller or negotiated order may change the applicable terms, so establish which document governs.

The Amazon Compute Service Level Agreement applies separately to each account using Amazon EC2. If it conflicts with the AWS Customer Agreement or another agreement governing the services, the SLA applies only to the extent of the conflict.

The Cloud Run Service Level Agreement applies during the agreement under which Google provides Google Cloud Platform. It defines a covered service as a Cloud Run service within a Project. If resale is authorised under a Google Cloud Partner or reseller program, the SLA treats the Partner or Reseller as the customer and applies credits only to impacted orders.

Do not rely on the headline percentage alone. Check the SLA's measurement, customer obligations and exclusions against the incident the business needs covered. A threshold by itself does not show whether a particular failure qualifies. Keep the workload's availability and recovery requirements separate from the provider's commitment.

Compare the covered failure with user impact

Amazon EC2 has Region-Level and Single EC2 Instance commitments. Region-Level coverage requires all running instances to be deployed concurrently across at least two Availability Zones in one region. If a region has only one Availability Zone, coverage requires deployment across at least two regions. Its target is 99.99% monthly uptime.

The Single EC2 Instance target is 99.5% per monthly billing cycle.

Cloud Run defines Downtime as an Error Rate above 1%. Error Rate counts valid requests to a Cloud Run service endpoint that return HTTP 5XX due to a failure of the Cloud Run infrastructure. A Downtime Period is one or more consecutive minutes; partial minutes or intermittent downtime lasting less than one minute do not count.

Cloud Run's monthly uptime target for non-GPU services and GPU services with zonal redundancy is 99.95% outside Mexico and Stockholm, and 99.9% in Mexico and Stockholm. For GPU services without zonal redundancy, the target is 99.5% in either region group.

Review item / Question

Covered unit
Which service, instance, project, region or operation is counted?
Failure definition
Would the incident the business fears qualify?
Preconditions
Which topology, request behaviour or quota conditions apply?
Exclusions
Which failures remain the customer's risk?
Measurement
Which period and records establish a missed target?
Remedy
What credit applies, and to which charges?
Claim
Who files it, with which evidence and by when?

The stated EC2 and Cloud Run thresholds do not identify a specific exclusion for a proposed incident. Check the applicable exclusions in the governing terms and ask the provider to clarify any that affect the proposed configuration.

Cloud Service SLA Coverage Comparison: AWS EC2 vs Google Cloud Run

  • ServiceAWS EC2 (Region-Level)
  • Target Uptime99.99% monthly
  • Failure DefinitionAll running instances unavailable across Availability Zones in a region
  • PreconditionsDeployment across at least two Availability Zones (or two regions if one AZ)
  • ExclusionsPlanned maintenance, customer-initiated actions, force majeure
  • Measurement PeriodCalendar month
  • Claim RouteAWS Support Center, by end of second billing cycle
  • ServiceGoogle Cloud Run (non-GPU, zonal redundancy)
  • Target Uptime99.95% monthly (outside Mexico and Stockholm)
  • Failure DefinitionError Rate >1% (HTTP 5XX from infrastructure failure) for ≥1 consecutive minute
  • PreconditionsProject-level service with zonal redundancy (for higher targets)
  • ExclusionsCustomer-side errors, quota limits, network issues, third-party dependencies
  • Measurement PeriodCalendar month, per Project and Region
  • Credit TiersFinancial Credits only, based on monthly uptime shortfall
  • Claim RouteVia governing agreement; submit within timeframe specified in SLA

Key SLA Metrics Summary

  • 99.99%AWS EC2 Region-Level Target
  • 99.5%AWS EC2 Single Instance Target
  • 99.95%Google Cloud Run (non-GPU, zonal)
  • 99.5%Google Cloud Run (GPU, no zonal redundancy)
  • 10%AWS Credit Threshold (%) — Uptime <99.99% but ≥99.0%
  • 100%AWS Credit Threshold (%) — Uptime <95.0%

Check the claim route

For the EC2 Region-Level SLA, credits are 10% when monthly uptime is below 99.99% but at least 99.0%, 30% below 99.0% but at least 95.0%, and 100% below 95.0%. The Single EC2 Instance SLA uses the same tiers, measured against its 99.5% target.

EC2 credits are calculated against the monthly bill for Amazon EC2 in the affected region, or for the affected Single EC2 Instance; one-time payments such as upfront Reserved Instance payments are excluded. AWS also does not charge for a Single EC2 Instance unavailable for more than six minutes of a clockhour, a rule applied automatically without a credit request for that hour.

An EC2 claim must be submitted through AWS Support Center by the end of the second billing cycle after the incident. Missing required information disqualifies the claim, so confirm the required information and assign an internal claims owner.

For Cloud Run, Financial Credits are the sole and exclusive remedy for failing to meet the SLO, provided the customer meets its SLA obligations. Uptime and credits are determined by calendar month, per Project and per Region. Confirm the applicable credit percentages, claim route, required information and submission deadline in the governing terms before signing.

Claim Submission Process for AWS EC2 and Google Cloud Run

  1. Monitor uptime and detect outageTrack monthly uptime via provider dashboards or monitoring tools
  2. Verify eligibility under SLA termsEnsure incident meets failure definition and is not excluded
  3. Gather required evidenceCollect logs, timestamps, error rates, and system metrics
  4. Submit claim within deadlineAWS: by end of second billing cycle after incident; GCP: per SLA terms
  5. Await credit processingCredits applied automatically or manually depending on provider

Decide before signing

Mark each critical dependency covered on the proposed configuration, covered if stated conditions are implemented, outside the commitment, or unverified. Give each conditional or unverified item an owner and a required answer. If the commitment is narrower than the workload requirement, decide whether to accept the gap or seek a different design or agreement.

The workload's availability target and the architecture to meet it remain separate decisions.

More from Governance