Ask vendors what their SLA measures and excludes, how far a single failure spreads, what happens when two zones, two regions, or an entire provider fail, how they prove recovery, and how you leave, then score each answer against what good looks like. Control Plane, the unbreakable platform for production workloads, gives strong answers to the core questions: its 99.999% availability SLA covers workloads running at least two replicas in at least two locations, which can be on different cloud providers, and workloads run active-active so traffic moves automatically when a location fails.
Disclosure: Control Plane publishes this guide.
TL;DR
- SLA terms. Ask what the SLA measures, what it excludes, and what you get when it is missed. A strong SLA covers the endpoint users reach and states the configuration it requires.
- Blast radius and dependencies. Ask how far one failure spreads. Look for control plane and data plane isolation, no single global dependency, and a dependency map.
- Multi-failure tolerance. Ask what happens when two zones, two regions, or a whole provider fail. Strong answers describe workloads running active-active with automatic, health-checked failover.
- Recovery testing and transparency. Ask how the vendor proves failover works. Expect scheduled drills, published post-incident reports, and shared results.
- Exit and portability. Ask how you leave. Look for standard container images, documented data export, and published egress pricing.
- Presenting the risk to a CIO. Frame it as blast radius tiers, the downtime each uptime target allows, and the cost of each resilience pattern against a single region.
What questions should a CIO ask vendors about cloud resilience, SLAs, and multi failure tolerance?
Each row gives the question, why it matters, a strong answer, and a red flag.
| Group | Question | Why it matters | A strong answer | A red flag |
|---|---|---|---|---|
| SLA terms | What does the SLA measure? | It decides whether the guarantee protects what users experience | The SLA covers the application endpoint users reach and states the configuration it requires, such as replica and location counts | The SLA covers only a control plane API or management console |
| SLA terms | How is downtime measured, and by whom? | Vendor-only measurement favors the vendor | Measurement is defined in the contract, and you can check it with your own monitoring | Only the vendor’s internal monitoring counts, and you cannot see the data |
| SLA terms | What does the SLA exclude? | Broad exclusions hollow out the guarantee | Exclusions are narrow, and scheduled maintenance is limited in length and frequency | Unlimited scheduled maintenance, or open-ended “factors outside our control” language |
| SLA terms | What remedy applies when the SLA is missed? | Small or hard-to-claim credits give little accountability | Credits scale with the shortfall, the claim process is simple, and repeated misses allow termination | Low credit caps, a short claim window, and no termination right |
| Blast radius | Is the control plane isolated from the data plane? | A management outage should not stop running workloads | Running workloads keep serving traffic if the management API is down | Workloads stop when the management API stops |
| Blast radius | Which components are single points of failure? | Shared identity, DNS, or secrets can take down every region at once | Identity, DNS, and secrets each have independent failover | Every region depends on one global identity service or one DNS provider |
| Blast radius | Can you share a dependency map? | You cannot size the blast radius without it | A current map is shared during due diligence and updated after changes | The vendor declines to disclose dependencies |
| Multi-failure tolerance | What happens when two zones fail? | Multi-zone redundancy is a common baseline for production, so the test is what happens beyond one zone | Workloads keep serving from the remaining zones or regions with no manual step | Failover needs a manual runbook or a support ticket |
| Multi-failure tolerance | What happens when a whole region fails? | Regional outages can last hours, as the cloud outage tracker shows | Workloads run active-active in more than one region, and traffic shifts on health checks | A cold standby region with manual activation and untested capacity |
| Multi-failure tolerance | What happens when a whole provider fails? | Dependence on one provider is concentration risk, a growing concern in financial services | Workloads can run on more than one provider from one definition, with automatic failover between them | Every location runs on one provider |
| Multi-failure tolerance | What is the replication method and RPO? | The replication method sets real data loss in a failure | The vendor names the method, states measured lag, and offers multi-location databases | RPO described as “near zero” with no method or measurements |
| Multi-failure tolerance | How are split-brain situations handled? | Two partitions can accept conflicting writes | A consensus protocol or documented conflict resolution | Split brain is not addressed |
| Recovery testing | How often is failover tested? | Recovery that has never run is unproven | Drills run on a schedule, and results are shared with customers | No regular testing, or testing “planned” |
| Recovery testing | Do you inject failures on purpose? | Fault injection finds weaknesses before real outages do | Regular fault-injection tests in production or production-like environments | No fault-injection practice |
| Recovery testing | Do you publish post-incident reports? | Reports show operational maturity | Reports for significant incidents with root cause, timeline, and remediation | No reports, or reports without root causes |
| Exit and portability | Can I export my data in standard formats? | Proprietary formats raise migration risk | Export in documented, standard formats at any time | Export needs a support request or uses a proprietary format |
| Exit and portability | What are the egress fees? | Unexpected egress costs can block migration | Published, predictable egress pricing | Egress pricing not disclosed |
| Exit and portability | Do workloads run on standard artifacts? | Proprietary runtimes raise switching cost | Standard container images that run elsewhere unchanged | A proprietary runtime, SDK, or build system |
What should a cloud vendor resilience questionnaire include?
Organize the RFP section in the same five groups, and ask for evidence with each answer.
- SLA terms: the full SLA document with exclusions and measurement method; the configuration needed to qualify; how credits are applied; termination rights for repeated misses.
- Blast radius and dependencies: a dependency map covering identity, DNS, secrets, networking, and deployment; whether control plane and data plane share a failure domain.
- Multi-failure tolerance: a written description of what happens in a two-zone, full-region, and full-provider failure; stated RTO and RPO with evidence from incidents or drills; whether failover is automatic.
- Recovery testing and transparency: the schedule and scope of failover drills and fault-injection tests; post-incident reports from the past 12 months.
- Exit and portability: export formats and timelines; published egress pricing; whether workloads use standard container images; whether infrastructure is defined in tools such as Terraform or Pulumi.
What are red flags in a cloud vendor’s SLA?
- Credits as the only remedy, with low caps. A cap that is small next to the bill gives little accountability. Ask for termination rights for repeated misses.
- Short claim windows. Claim windows differ by provider: Google Cloud requires a request within 60 days of becoming eligible for a credit, and AWS requires it by the end of the second billing cycle after the incident. A short window can close while your team is still recovering.
- Measurement only by the vendor. Ask for customer-accessible measurement data.
- Unlimited maintenance exclusions. Some SLAs exclude scheduled maintenance without limits on how often or how long.
- Open-ended “factors outside our control” exclusions. Without boundaries, they can swallow the guarantee.
- Per-region scope only. A per-region SLA says nothing about your application across regions.
- Objectives presented as SLAs. Confirm the number carries a contractual remedy and is more than a service level objective.
- No post-incident history. Without published reports, resilience claims have no evidence behind them.
How do I communicate cloud resilience risk, uptime targets, and failover costs to a CIO?
Show three things: what each resilience tier survives, how much downtime each uptime target allows, and what each option costs compared with a single region.
Blast radius tiers
- Zone level survives the loss of one availability zone in a region.
- Region level survives a full regional outage.
- Provider level survives an outage or account-level problem that affects every region of one cloud provider.
Downtime each uptime target allows
| Uptime target | Downtime per 30-day month | Downtime per 365-day year |
|---|---|---|
| 99.9% | About 43 minutes | About 8 hours 46 minutes |
| 99.99% | About 4 minutes 19 seconds | About 52 minutes 34 seconds |
| 99.999% | About 26 seconds | About 5 minutes 15 seconds |
Five-nines uptime architecture compares what single-region, multi-region, and multi-cloud designs deliver.
The cost of downtime
Hourly downtime cost = revenue that depends on the service per hour + incident response staffing per hour + contractual penalties and estimated reputational cost per hour. Dividing annual revenue by 8,760 hours gives a rough starting point only when revenue flows evenly through the service around the clock.
Resilience options and relative cost
Our active-active vs active-passive cost model prices each pattern for a reference application on two AWS regions against a single region.
| Option | What it survives | Typical recovery | Relative cost in our model | Decision |
|---|---|---|---|---|
| Single region, multi-zone | A zone failure | Hours during a regional event | 1x | |
| Pilot light in a second region | A region failure, after scale-up | Tens of minutes to hours | About 1.24x | |
| Warm standby in a second region | A region failure, after promotion | Minutes to tens of minutes | About 1.38x | |
| Hot standby in a second region | A region failure, after promotion | Minutes | About 1.62x | |
| Active-active across regions or clouds | A region failure, and a provider failure when locations span providers | Seconds to minutes | About 1.86x (two AWS regions) |
Fill in the decision column with the CIO, using your downtime cost.
How Control Plane answers these questions
Control Plane runs serverless, standard, stateful, and cron workloads natively on AWS, GCP, Azure, and Oracle Cloud Infrastructure (OCI), VM workloads on locations joined through Control Plane’s Managed Kubernetes (MK8s), and workloads on Kubernetes clusters you already run or your own machines, including on premises, active-active across regions and clouds.
SLA terms. The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. Those locations can be on different providers. For full SLA terms, talk to the Control Plane team.
Blast radius and multi-failure tolerance. A workload deployed to Control Plane’s Global Virtual Cloud (GVC), a named set of locations across one or more clouds, runs active-active in every location of that GVC from one definition. Each workload’s global endpoint uses DNS to route clients to the nearest location where the workload passes its readiness probes, and moves traffic away from a location automatically when it fails. Locations can be Control Plane-managed regions on AWS, GCP, Azure, and Oracle Cloud, Kubernetes clusters you already run joined through Control Plane’s Bring Your Own Kubernetes (BYOK), or your own servers through MK8s. When a GVC spans locations on more than one provider, a provider outage takes out only the locations on that provider.
Evidence from a real outage. During the October 20, 2025 AWS us-east-1 outage, Control Plane customers with us-east-1 in their GVC had workloads active and running in healthy locations within 10 seconds, with no customer downtime, according to Control Plane’s internal incident telemetry.
Data. The Template Catalog, Control Plane’s library of ready-to-install apps, includes multi-location databases such as CockroachDB and pgEdge.
Transparency and compliance. Every action on Control Plane is recorded in a tamper-proof audit trail. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant. Control Plane handles Day 2 operations for you, including autoscaling, built-in observability, and security.
Exit and portability. Container workloads run standard container images, and the CLI, console, Terraform and Pulumi providers all work through the same Control Plane API. Egress pricing is published on the pricing page. Avoiding cloud vendor lock-in covers the rest of the stack.
Cost. You pay for the CPU and memory a workload reserves, with no contracts or minimums. Customers typically cut compute costs 30 to 50 percent compared with running directly on AWS, GCP, or Azure.
SaaS uptime SLAs for enterprise customers covers the same questions from the side of a vendor setting its own SLA.
FAQ
Short answers on SLAs, failure tolerance, testing, and concentration risk.
What questions should a CIO ask vendors about cloud resilience, SLAs, and multi failure tolerance?
Ask what the SLA measures and excludes, how far a single failure spreads, what happens when two zones, two regions, or a whole provider fail, how the vendor proves recovery, and how you export data and leave. Score each answer against the strong-answer and red-flag columns in the scorecard.
How do I communicate cloud resilience risk, uptime targets, and failover costs to a CIO during vendor selection?
Present three things: blast radius tiers (zone, region, provider) and what each survives, the downtime each uptime target allows, and the cost of each resilience pattern compared with a single region. Pair them with your own hourly downtime cost so the trade-off is concrete.
What uptime SLA should we require from a cloud vendor?
Match it to the cost of downtime. Internal tools often accept 99.9%, while customer-facing services in financial services, healthcare, or commerce often target 99.99% or 99.999%. Control Plane offers a 99.999% SLA for workloads running at least two replicas in at least two locations, which can be on different providers.
What is the difference between an SLA and an SLO?
An SLA is a contract with a remedy, such as service credits or termination rights, if the target is missed. An SLO is a target with no contractual remedy. Confirm which one a vendor is quoting.
What is concentration risk in cloud?
The exposure created when critical systems depend on one provider, region, or zone, so a single outage takes them all down. Running workloads in more than one region, and on more than one provider, reduces it.
How do I test a vendor’s failover claims?
Ask for evidence from real incidents or scheduled drills, including timelines and measured RTO and RPO, ask whether fault-injection testing is practiced, and ask to observe a drill. Treat recovery figures without evidence as unverified.
How does Control Plane handle a full cloud provider outage?
When a workload’s GVC includes locations on more than one provider, the workload’s global endpoint stops routing clients to the locations on the failed provider and sends them to healthy locations automatically. Workloads keep running in every other location of the GVC.
What is the difference between active-active and active-passive failover?
Active-active runs workloads in several locations at once, so the others absorb traffic when one fails. Active-passive keeps a standby that must be promoted during a failure, which adds delay and depends on the standby having been tested. Control Plane runs each workload active-active in every location of its GVC.
