DEV Community: Noah Grinstein

SaaS Uptime SLAs: What to Offer Enterprise Customers and How to Engineer 99.99% or Better

Noah Grinstein — Mon, 02 Nov 2026 23:40:39 +0000

Offer an SLA one step below what your architecture has proven it can deliver, commonly 99.9% for standard plans and 99.95% or 99.99% for enterprise plans, with clear measurement and service credits. 99.99% (about 52 minutes and 34 seconds of downtime per year) is hard to sustain end to end in a single region, because one region cannot survive a region-wide outage, and a single 15-hour regional outage uses about 17 years of four-nines error budget. The dependable path is active-active serving across at least two locations plus tested database failover. Control Plane runs a workload active-active across locations under a 99.999% availability SLA for workloads with at least two replicas in at least two locations, and those locations can be on different providers.

Disclosure: Control Plane publishes this guide.

TL;DR

Pick the SLA. Set your external SLA below your internal SLO. 99.9% is a common enterprise baseline; 99.95% and 99.99% belong on premium and mission-critical tiers. Only promise what your architecture has sustained over multiple months.
Know the downtime math. 99.99% allows 52 minutes and 34 seconds of downtime per year, or 4 minutes and 19 seconds per 30-day month. A single prolonged incident can exhaust your entire error budget.
Architect for the tier. Single-region multi-zone survives zone failures but not a region-wide outage. Active-passive multi-region adds recovery time. Active-active multi-region or multi-provider is the dependable path to 99.99% and beyond.
Test failover regularly. Run game days, drain one location at a time, and rehearse database promotion. Measure recovery time in every test.
How Control Plane fits. A workload deployed to Control Plane’s Global Virtual Cloud (GVC), a set of locations a workload runs across, runs active-active in every location of that GVC. A global endpoint routes each request to the nearest healthy location, delivering failover without paying for idle standby capacity, under a 99.999% availability SLA for workloads with at least two replicas in at least two locations.

What Uptime SLA Should a B2B SaaS Company Offer Enterprise Customers?

Offer 99.9% on standard enterprise plans and 99.95% or 99.99% on premium tiers, set one step below an internal SLO your architecture has already met.

SLA vs. SLO vs. SLI

These three terms are related but serve different purposes. A Service Level Indicator (SLI) is the metric you measure, such as the percentage of HTTP requests that return a successful response within 300 milliseconds. A Service Level Objective (SLO) is the internal target you set for that metric, for example 99.97% of requests succeed over a rolling 30-day window. A Service Level Agreement (SLA) is the contractual commitment you make to customers, backed by remedies like service credits if you miss it.

Set the external SLA below the internal SLO. If your SLO is 99.97%, offer a 99.9% SLA. The error budget is 100% minus the SLO, here 0.03%, or about 13 minutes per 30-day month. When it runs out, teams slow releases and fix reliability. The gap between the SLO and the SLA is a safety margin, so a missed SLO triggers internal action before it triggers credits.

What to Put in the Contract

A well-drafted uptime SLA needs several precise elements:

Measurement method and window. Define whether availability is calculated from synthetic health checks, production request success rates, or both. Specify the aggregation period, typically a calendar month or rolling 30-day window.
What counts as downtime. State whether downtime means the API returns errors, the login page is unreachable, or a health-check endpoint fails. Be specific about which components are covered.
Scheduled maintenance. Exclude pre-announced maintenance windows from the downtime calculation, and state the minimum notice period, the maximum maintenance time per month, and the allowed time windows.
Exclusions. Customer misconfigurations, force majeure events, beta features, and failures of services outside your control should be explicitly carved out.
Service credits. Credits usually increase as availability drops. For example, the AWS EC2 Region-Level SLA credits 10% of the monthly bill below 99.99%, 30% below 99.0%, and 100% below 95.0%. Many SaaS contracts cap total credits at a percentage of the monthly fee.
Claim process. Specify how customers submit credit requests, the evidence required, and the deadline for claims after an incident.
Regional scope. State whether availability is measured globally or per customer region. A global average can hide a full outage in the one region a customer uses.
Partial degradation. Define how elevated error rates, severe latency, or loss of a single feature count. A common approach counts a minute as down when the error rate exceeds a stated threshold.
Chronic failure. Enterprise buyers often ask for the right to terminate without penalty if the SLA is missed in several months within a set period.
Credits and liability. State whether credits are the sole and exclusive remedy and whether they count toward the contract’s liability cap. Buyers negotiate both.

Common Tiers

Plan	Typical SLA	Suited For
Self-serve / Starter	Best effort or 99.5%	Early adopters, non-critical workloads
Business	99.9%	Standard enterprise use
Enterprise	99.95% or 99.99%	Mission-critical applications, regulated industries

Higher-tier SLAs justify premium pricing because they demand more infrastructure redundancy, tighter operational processes, and faster incident response.

How Much Downtime Does Each SLA Allow?

The table below is computed from 525,600 minutes per year, 43,200 minutes per 30-day month, and 10,080 minutes per week.

SLA	Downtime per Year	Downtime per Month (30 days)	Downtime per Week
99%	5,256 min (3 days 15 hr 36 min)	432 min (7 hr 12 min)	100 min 48 sec
99.5%	2,628 min (1 day 19 hr 48 min)	216 min (3 hr 36 min)	50 min 24 sec
99.9%	525 min 36 sec (8 hr 45 min 36 sec)	43 min 12 sec	10 min 5 sec
99.95%	262 min 48 sec (4 hr 22 min 48 sec)	21 min 36 sec	5 min 2 sec
99.99%	52 min 34 sec	4 min 19 sec	1 min 0.5 sec
99.999%	5 min 15.4 sec	25.9 sec	6 sec

At 99.99%, a single five-minute outage wipes out more than a month’s error budget. At 99.999%, you have roughly 26 seconds per month. A human responder usually cannot be paged, diagnose the problem, and act within that budget, so detection and failover have to be automated.

How Do I Achieve 99.99% Uptime for a SaaS Application?

Run active-active across at least two regions with automated health-based routing, give the database a tested failover path, and roll out changes one location at a time.

Composite Availability: Why Dependencies Cap Your SLA

When components are in series, meaning a request must pass through each one, their availabilities multiply. The composite availability formula is:

A_composite = A_1 × A_2 × A_3 × … × A_n

For example, if your API server has 99.99% availability and your database has 99.95% availability, the composite availability is 0.9999 × 0.9995 = 0.9994, or 99.94%. Your database just pulled your system below four nines even though your application tier met it.

Adding redundancy helps. When two components operate in parallel so that the system fails only if both fail, the parallel availability formula is:

A_parallel = 1 − (1 − A_1) × (1 − A_2)

Two instances each at 99.9% yield 1 − (0.001 × 0.001) = 0.999999, or 99.9999%. That result assumes the two fail independently and that failover is instant. Real systems rarely meet either assumption. Replicas in the same region share power, network, and provider control-plane dependencies. Replicas running the same build share the same bugs. Replicas reading the same configuration fail together when that configuration is wrong. Treat the parallel result as an upper bound.

Changes to a live system, meaning code deploys and configuration pushes, are a leading cause of outages; the Control Plane Cloud Outage Tracker attributes 32% of major outages since 2020 to configuration or deployment changes. Redundancy does not protect against a bad change pushed to every location at once. Roll out changes one location at a time, gate each step on health metrics, and keep a fast rollback. Apply the same staged rollout to configuration, feature flags, and DNS changes.

Architecture by Tier

Single region, multi-zone. Deploy across two or more availability zones in one cloud region. This protects against single-zone failures such as power or network issues within one zone. Cloud providers back multi-zone compute with SLAs as high as 99.99% (for example, the AWS EC2 Region-Level SLA), but that covers only the compute layer. Once databases, load balancers, and DNS are multiplied in, end-to-end availability is lower, and the design cannot survive a region-wide outage. Every major provider has had region-level outages lasting hours.

Active-passive multi-region. A primary region handles all traffic while a standby region stays ready. On failure, traffic is redirected to the standby. Recovery time depends on how quickly you detect the failure, promote databases, and reroute DNS. The standby infrastructure sits idle during normal operation, which means you pay for capacity that serves no traffic most of the time. For a deeper comparison, see active-active vs. active-passive cost.

Active-active multi-region. Every region serves live traffic simultaneously. A global load-balancing layer routes requests to the nearest healthy region. When health checks mark a location unhealthy, the load balancer stops sending it traffic. Failover speed depends on health-check intervals, failure thresholds, and DNS TTLs when routing is DNS-based. Surviving locations need enough spare capacity to absorb the lost traffic, and the database still needs its own failover design. It survives a full region outage without a recovery step, which is why it can sustain 99.99% and above. Every location serves production traffic, so no standby region sits idle.

Multi-provider. Running across two or more cloud providers removes the single-provider risk. A region-wide outage on one provider does not affect locations on another. This adds complexity in identity, networking, and deployment but provides the strongest resilience posture. For a detailed breakdown of what each design can deliver, see five nines uptime architecture.

How Do I Fail Over a Database-Backed Application Between Cloud Regions?

Database failover is the hardest part of multi-region resilience. The application tier is often stateless and easy to replicate, but the database holds state that must survive a region failure without corruption or data loss.

Managed Cross-Region Replicas with Promotion

Major cloud databases offer cross-region replicas that can be promoted to primary on failure. Amazon Aurora Global Database replicates to secondary regions with typical lag under one second, and AWS says a secondary region can be promoted to read and write in under a minute. Cloud SQL supports cross-region read replicas that you promote manually, with replica failover and switchover on the Enterprise Plus edition. Azure SQL Database failover groups replicate databases asynchronously to another region and keep the same connection endpoint after a failover. Promotion takes from under a minute to several minutes, depending on the service, replication lag, and DNS caching, and writes are unavailable during that window.

Synchronous vs. Asynchronous Replication

Recovery Point Objective (RPO) is the most data, measured in time, you can afford to lose. Recovery Time Objective (RTO) is the longest the service can stay down before it is restored. Synchronous replication commits a write only after both the primary and secondary regions confirm it. This gives an RPO of zero, but every write waits for a round trip to the remote region, so latency grows with distance. It also ties write availability to the remote region: if the secondary is unreachable, the primary must either stop accepting writes or fall back to asynchronous mode and give up zero RPO. Asynchronous replication commits locally and ships changes to the secondary in the background. Writes are faster, but a failure can lose transactions that had not yet replicated, so RPO is above zero.

Distributed SQL Databases

Databases like CockroachDB and Google Cloud Spanner accept writes from clients in any region and use consensus replication (Raft in CockroachDB, Paxos in Spanner) to commit each write across regions. They provide strong consistency and automatic failover without manual promotion. The trade-off is write latency, because a write commits only after a majority of replicas acknowledge it, and some of those replicas may be in other regions. Surviving the loss of a full region requires replicas in at least three regions.

Fencing and Split-Brain Prevention

When a primary region becomes unreachable, you must ensure it cannot continue accepting writes while the new primary is active. Fencing prevents split-brain, where two nodes both act as primary. Common methods are revoking the old primary’s network access or credentials, powering it off (often called STONITH), leader leases that expire, and fencing tokens, increasing numbers that storage checks so it rejects writes from a stale primary. Leases depend on bounded clock drift, so set lease timeouts with margin.

Connection-String and DNS Changes

After promotion, your application needs to reach the new primary. Strategies include DNS-based failover with low TTLs, connection proxies that abstract the primary endpoint, or application-level configuration that reads the current primary from a coordination service.

How Do I Test Failover Without Taking Production Down?

Test failover in stages. Start in a non-production environment, then move to small, controlled slices of production traffic, with a rollback ready at every step. A failover path that has never been tested often fails when it is needed, and regular tests surface problems such as stale DNS records, expired credentials, and database promotion scripts that no longer work.

Game Days

Designate a scheduled window where your team deliberately triggers a failure scenario and practices the recovery process.

Canary Traffic Slicing

Fail over a small slice of traffic, such as internal users or a single tenant, to the secondary location. Observe behavior, latency, and error rates before committing to a full failover.

Draining One Location at a Time

Remove one location from your load balancer and verify that all traffic shifts cleanly to remaining locations. This tests both the routing layer and the capacity of surviving locations to absorb the additional load.

Synthetic Checks

Run synthetic transactions that exercise critical user flows, such as login, API calls, and data writes, from external vantage points. These catch failures that internal health checks miss, including DNS resolution problems, certificate expiration, and CDN misconfigurations.

Chaos Engineering Tools

Open-source projects like Chaos Mesh and LitmusChaos inject faults into Kubernetes workloads, including pod kills, network partitions, and CPU stress. The major cloud providers offer their own fault injection services: AWS Fault Injection Service, Azure Chaos Studio, and Google Cloud Fault Injection Testing (in Preview). Some of these tools can simulate the loss of a zone or region without an actual outage; for example, AWS FIS includes an AZ power interruption scenario and a cross-Region connectivity scenario that blocks traffic to another region and pauses cross-region replication.

Rollback Plan

Every failover test needs a documented rollback path. If the failover itself causes unexpected issues, you need a way to restore the previous state quickly. Test the rollback too.

How Do I Stop Paying for Idle Disaster Recovery Infrastructure?

Replace the standby region with active-active serving, where every location handles production traffic. Active-passive architectures require a standby region that consumes compute, storage, and database resources while serving no production traffic. You pay for capacity that exists solely to absorb a failover. In many organizations, this standby environment drifts out of sync with production because it receives less attention, fewer deployments, and less testing.

In an active-active design, every location serves live traffic, and when one fails, the others absorb its load. Each location still needs headroom to take that load, but the headroom runs production traffic every day, so it is exercised constantly. The application tier has no cold start and no standby fleet to promote, though the database still needs its own failover design.

On Control Plane, a workload deployed to a GVC runs active-active in every location of that GVC, and a global endpoint routes each request to the nearest healthy location. You get failover without paying for idle standby capacity. Customers typically cut compute costs 30 to 50 percent compared with running directly on AWS, GCP, or Azure.

How Do Financial Services Companies Stay Online During Cloud Outages?

Financial services firms stay online by running active-active across at least two regions, often on more than one provider, mapping every external dependency, and proving recovery with drills they can show regulators. The Control Plane Cloud Outage Tracker documents more than 60 major AWS, Azure, Google Cloud, and Cloudflare outages since 2020. No single region on any provider is immune.

Regulated organizations combine these practices with regulatory requirements:

Multi-region or multi-provider active-active. Running in at least two regions, ideally on different providers, ensures that a single-region failure does not take down the service.

Regulatory expectations. Regulators increasingly mandate operational resilience. The EU’s Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, which applies from 17 January 2025, requires financial entities to identify, protect against, detect, respond to, and recover from ICT-related disruptions. It also requires them to manage ICT third-party risk, including concentration risk from relying on a small number of ICT providers such as cloud providers. Firms must run a digital operational resilience testing program, so recovery capabilities have to be tested as well as documented.

Dependency mapping. Catalog every external service your application depends on, including DNS providers, identity services, payment processors, and CDNs. Understand the availability of each and plan for its failure.

Regular drills. Conduct failover exercises regularly; Google’s Well-Architected Framework suggests quarterly. Measure RTO and RPO in practice, not just on paper. Share results with leadership and regulators.

For a practical guide to surviving a specific provider outage, see how to keep your app online during an AWS region outage.

What Questions Should a CIO Ask Vendors About Cloud Resilience, SLAs, and Multi-Failure Tolerance?

Use this checklist when evaluating infrastructure vendors or SaaS providers for mission-critical workloads:

What does your SLA cover? Which services, endpoints, and features are included? Are there components excluded from the availability calculation?
How do you measure availability? Is it based on synthetic checks, real user traffic, health-check endpoints, or a combination? What is the measurement interval?
What are the credit terms? What percentage of the monthly fee is credited at each availability band? Is there a cap? Are credits the sole remedy, and can I terminate if you miss the SLA repeatedly? Is availability measured per region?
How many regions and providers do you operate in? Can my workload run in more than one region simultaneously? More than one cloud provider?
How does your failover work? Is it automatic or manual? What is the expected failover time? Is it active-active or active-passive?
How do you roll out changes? Do code and configuration changes deploy one location at a time with health gates and automatic rollback? Can a single bad change reach every region at once?
How often do you test failover? When was the last test? Can you share results or post-mortems?
What are your RTO and RPO? Are these tested values or theoretical targets?
Do you depend on a single region or provider? What happens to my workload if that region or provider has a multi-hour outage?
Do you publish incident history and post-mortems? Is there a public status page with historical data?
How do you handle data durability? Where are backups stored? Are they cross-region? How often are restores tested?
What are the exit terms? Can I export my data and migrate away without penalty? What formats are available?
Do you have adisaster recovery strategy that addresses multi-failure scenarios? How do you handle simultaneous failures across zones or regions?

How Control Plane Approaches Uptime

Control Plane is the platform for running unbreakable apps and agents. It combines locations on any cloud, neocloud, and bare metal into a single GVC.

A workload deployed to a GVC runs active-active in every location of that GVC. A global endpoint routes each request to the nearest healthy location. Readiness probes, which can be HTTP, gRPC, TCP, or a command, decide when each replica can take traffic. When a location has no ready replicas, the global endpoint routes requests to another healthy location. The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. Those locations can be two regions of one cloud or locations on different providers, for example one AWS region and one neocloud location joined through Control Plane Managed Kubernetes (MK8s). Disabling a location in a GVC removes its replicas and routes traffic to the locations that remain, which turns a location drain into a one-step game-day test.

Control Plane’s location routing options tune this per GVC. A routing tier sets priority: locations with the lowest tier number serve traffic, the lowest-latency location within that tier wins, and the next tier receives traffic only when every location in the higher-priority tier is unavailable. A latency offset makes a location appear closer or farther in milliseconds, which shifts more or less traffic to it.

During the October 20, 2025 AWS us-east-1 outage, which lasted about 15 hours and affected 100+ AWS services in that region, 20 percent of Control Plane customers had us-east-1 in their GVC. Their workloads were “active and running in healthy locations within 10 seconds,” with no customer downtime, according to Control Plane internal incident telemetry.

Control Plane handles Day 2 operations for you, including autoscaling, Capacity AI right-sizing (Control Plane’s right-sizing of CPU and memory based on historical usage), built-in observability, and security, with no Kubernetes cluster you have to operate. A tamper-proof audit trail records changes made through the Control Plane API, and built-in metrics, logs, and traces cover every location in one place.

Control Plane runs serverless, standard, stateful, and cron workloads on AWS, GCP, and Azure and on Kubernetes clusters you already run, and runs VM workloads alongside them on your own servers, including on premises, turned into managed locations with MK8s. Many teams run Control Plane in a single region of one cloud for its Day 2 operations, and adding another region or provider later means adding a location to the GVC. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant.

Control Plane’s Universal Cloud Identity gives workloads short-lived, least-privilege access to 600+ AWS, GCP, and Azure services, with no long-lived cloud keys in your code.

Databases still need a replication and failover design, and Control Plane helps there too. Stateful workloads give each replica its own persistent volume, and the Control Plane template catalog deploys databases built to span locations, including pgEdge active-active PostgreSQL with multi-master replication, a PostgreSQL cluster stretched across locations with automatic promotion in a surviving location, and CockroachDB. Pair one with the active-active application tier, in enough locations for the database’s quorum (three for CockroachDB), and both layers survive the loss of a location. Active-active serving with health-based routing removes any single replica, zone, or region as a point of failure for the application tier, and any single provider when the GVC spans providers. See also: how to prevent website downtime.

FAQ

What uptime SLA should a B2B SaaS company offer enterprise customers?

Offer 99.9% for standard enterprise plans and 99.95% or 99.99% for premium and mission-critical tiers. Set the external SLA one step below your proven internal SLO so you maintain error budget headroom. Only commit to an SLA your architecture has sustained over multiple months of production operation.

How much downtime does 99.99% uptime allow per year?

99.99% uptime allows 52 minutes and 34 seconds of downtime per year, computed from 525,600 total minutes in a year. Per 30-day month, that is 4 minutes and 19 seconds. A single extended incident can exhaust the entire annual budget.

How do I achieve 99.99% uptime for a SaaS application?

Deploy active-active across at least two regions with automated health-based failover, redundant databases with tested promotion, zero-downtime deployments rolled out one location at a time, and external synthetic monitoring. Single-region multi-zone architectures struggle to sustain 99.99% end to end because they cannot survive a region-wide outage.

What is the difference between an SLA, SLO, and SLI?

An SLI is the metric you measure, such as request success rate. An SLO is your internal target for that metric. An SLA is the contractual commitment to customers, backed by remedies like service credits. The SLA should always be set below the SLO.

How do I fail over a database between cloud regions?

Options include managed cross-region replicas with promotion, synchronous replication for zero RPO, asynchronous replication for lower latency with non-zero RPO, and distributed SQL databases that accept writes in every region. Fencing mechanisms prevent split-brain, and you must rehearse promotion regularly.

How do I test failover without causing an outage?

Run game days with deliberate failure injection, drain one location at a time to verify traffic shifts cleanly, use chaos engineering tools like Chaos Mesh or LitmusChaos, and test with a canary slice of traffic before full failover. Always have a documented rollback plan.

How does Control Plane deliver 99.999% availability?

Control Plane’s 99.999% availability SLA applies to workloads running at least two replicas in at least two locations, and those locations can be on different providers. Each workload runs active-active in every location of its Global Virtual Cloud (GVC), readiness probes decide which replicas take traffic, and a global endpoint routes each request to the nearest healthy location. During the October 2025 AWS us-east-1 outage, affected customers’ workloads were active in healthy locations within 10 seconds, according to Control Plane internal incident telemetry.

How do I stop paying for idle disaster recovery infrastructure?

Use an active-active architecture where every location serves live traffic instead of active-passive where standby capacity sits idle. On Control Plane, workloads run active-active in every location of the GVC, so you get automatic failover without paying for idle standby capacity.

What questions should I ask vendors about cloud resilience?

Ask about SLA scope and measurement method, credit terms and caps, number of regions and providers, failover design and test frequency, how changes roll out across locations, tested RTO and RPO, dependency on a single region or provider, incident history and post-mortems, status page availability, data durability, and exit terms.

How can my company avoid being taken down by the next major cloud outage?

Run active-active across at least two regions, ideally on more than one provider. Map all dependencies, test failover quarterly, and monitor from external vantage points. Every major provider has had multi-hour regional outages.

Talk to the Control Plane team or sign up free to try it.

Originally published on the Control Plane blog.

Build vs Rent GPUs: A Break-Even Model for AI Compute in 2026

Noah Grinstein — Mon, 02 Nov 2026 23:39:40 +0000

Owning GPUs is cheaper than renting only when you keep them busy enough over their useful life to clear a break-even utilization, so the decision turns on sustained utilization, the all-in cost of owning (hardware, power, cooling, networking, space, staff, and depreciation), and how fast your needs change. Most teams end up hybrid, owning a steady base and renting for peaks and new hardware generations. On Control Plane, one Global Virtual Cloud (GVC), Control Plane’s named set of locations that a workload runs across, can include GPU servers you own and rented cloud GPUs, so the build-versus-rent split changes by adding or removing locations instead of re-platforming.

Disclosure: Control Plane publishes this guide.

TL;DR

Ownership wins on cost when sustained GPU utilization stays high over the hardware’s useful life. Renting wins when demand is variable, scale is small, or you need access to the latest generation quickly.

The break-even rule. Owned cost per useful GPU-hour must fall below the rented price per GPU-hour. That crossover depends mainly on utilization, useful life, hardware cost, operating cost, and the rental rate you can get.
What TCO must include. Hardware, high-speed networking, storage, power, cooling, rack space or colocation, spares, maintenance, staff, software, and financing cost on the own side, with hardware amortized over its useful life. Per-GPU-hour or reserved pricing, storage, egress, networking, support tier, and idle reserved capacity on the rent side.
Neocloud vs hyperscaler. GPU-focused neoclouds often list lower per-GPU-hour prices because they run leaner service stacks, but hyperscalers bundle ecosystem services, broader compliance attestations, and availability guarantees that can offset the sticker difference.
Procurement and compliance factors. GPU and server lead times, data center power and cooling capacity, network gear availability, data residency requirements, and attestation coverage all constrain the decision beyond pure cost.
How Control Plane fits. On Control Plane, one GVC can include rented GPU capacity and GPU servers you own, which join as locations through Managed Kubernetes (MK8s), Control Plane’s way of turning your own servers into managed locations. A new location that offers the same GPU model runs every workload in the GVC, so the owned-versus-rented mix changes without editing workloads. GPU Ocean, Control Plane’s approach to pulling GPU capacity from any provider, works today through MK8s.

How do I estimate total cost of ownership for AI infrastructure with GPU clusters and networking?

A rigorous TCO comparison requires enumerating every cost line, not just GPU purchase price or hourly rental rate. The table below lists every category you should account for, separated by ownership model and cost frequency.

Category	Owning	Renting	One-Time or Recurring
GPU servers (GPUs, CPUs, memory, chassis)	Yes	No	One-time (amortized)
High-speed networking (InfiniBand or RoCE switches, optics, cables)	Yes	No	One-time (amortized)
Storage (NVMe, networked file systems)	Yes	Included or add-on	One-time (amortized) + recurring maintenance
Power (electricity for compute)	Yes	Included in hourly price	Recurring
Cooling (CRAC units, liquid cooling loops, chilled water)	Yes	Included	Recurring
Rack space or colocation fees	Yes	No	Recurring
Spares and warranty replacements	Yes	No	Recurring
Maintenance contracts (vendor support)	Yes	No	Recurring
Staff (infrastructure engineers, on-call)	Yes	Reduced	Recurring
Software (orchestration, monitoring, security)	Yes	Partial overlap	Recurring
Financing cost (interest or opportunity cost of capital)	Yes	No	Recurring
Depreciation (the amortized hardware rows above, not an extra cost)	Yes	No	Accounting (already counted in (H − S) / L)
GPU failures and RMA turnaround (capacity lost while parts are out)	Yes	No (provider replaces)	Recurring
Cluster software licenses (for example NVIDIA AI Enterprise, a per-GPU subscription)	Yes, if used	Yes, if used	Recurring
Insurance for owned equipment	Yes	No	Recurring
Decommissioning, data destruction, and resale value at end of life	Yes (resale offsets cost)	No	One-time
Time to deploy (procurement, power, and install lead time before the cluster earns value)	Yes	Short	One-time (opportunity cost)
Per-GPU-hour or reserved pricing	No	Yes	Recurring
Data egress and transit	Yes (IP transit and cross-connects, often billed on committed bandwidth)	Yes (usually per GB)	Recurring
Cloud networking (VPC, load balancers)	No	Yes	Recurring
Support tier (premium support plans)	No	Yes	Recurring
Idle reserved capacity (committed instances not fully used)	No	Yes	Recurring

When building your own TCO model, assign each line a dollar value per year (or amortize one-time costs over the useful life you assume for the hardware). The sum of all owned lines divided by the number of productive GPU-hours gives you the true cost of ownership per GPU-hour, which is the number you compare against a rental quote.

For a broader comparison of cloud, on-premises, and hybrid cost structures, see Control Plane’s cloud vs on-premises vs hybrid cost guide.

How do I evaluate ROI for building a GPU data center versus renting AI infrastructure capacity?

Owning returns more than renting once your sustained utilization exceeds the break-even level defined below.

The break-even model

Variables:

H = total hardware cost (GPU servers, networking, storage, all one-time capex)
S = expected resale value at end of life, minus decommissioning cost (use 0 if unsure)
L = useful life in years (the period over which you amortize hardware)
O = yearly operating cost (power, cooling, rack space or colocation, IP transit, spares, maintenance, insurance, staff, software and licenses, financing cost)
N = number of GPUs in the cluster
U = average utilization (fraction of time GPUs are doing productive work, 0 to 1)
R = rented cost per productive GPU-hour. For on-demand capacity you release when idle, use the hourly price. For reserved or committed capacity you pay for whether or not it is busy, use the committed hourly price divided by that capacity’s own utilization.

Owned cost per useful GPU-hour:

Owned cost per hour = ((H − S) / L + O) / (N × 8,760 × U)

The numerator is total yearly cost (amortized hardware plus operating expenses). The denominator is the number of useful GPU-hours produced per year.

Break-even condition:

Ownership is cheaper when Owned cost per hour < R.

Break-even utilization:

Rearranging for the utilization at which owned cost equals rented cost:

U_breakeven = ((H − S) / L + O) / (N × 8,760 × R)

If your expected utilization exceeds U_breakeven, owning is cheaper. If it falls below, renting is cheaper. If U_breakeven comes out above 1, ownership cannot beat that rental rate at any utilization.

How to read the model. Plug in your own numbers for hardware quotes, local power rates, colocation fees, staffing costs, and the best rental rate you can negotiate. Run the model at multiple useful-life assumptions (two years, three years, four years) because GPU generations can shift the resale and relevance window.

Sensitivity: what moves the answer

Variable	Change	Effect on Break-Even Utilization
Actual utilization (`U`)	Higher	No effect on break-even utilization; moves you further above it, so ownership wins by more
Resale value (`S`)	Higher	Lowers net hardware cost, lowers break-even utilization
Useful life (`L`)	Longer	Lowers amortized hardware cost per year, lowers break-even utilization
Power price	Higher	Raises yearly operating cost, raises break-even utilization
Rented price discount (commitments)	Deeper discount	Lowers `R`, raises break-even utilization (harder to beat renting)
Staff cost	Higher	Raises yearly operating cost, raises break-even utilization
Hardware purchase price (`H`)	Higher	Raises amortized cost, raises break-even utilization
Cluster size (`N`)	Larger	Lowers break-even utilization only if per-GPU cost falls with scale (shared staff, volume pricing); larger fabrics can add networking cost per GPU

How do I budget GPU hosting versus building my own?

Structure the budget as a three-year plan with a review point when the next GPU generation ships. In year one, allocate capex (if building) or committed reservations (if renting), plus all operating lines. In years two and three, project operating costs with an escalation factor for power and staffing, and write down the hardware on your depreciation schedule for accounting. At the review point, run the model again for new purchases with updated rental rates and next-generation hardware prices. For hardware you already own, the purchase price is sunk: keep it while its operating cost plus the resale value you give up is below the cost of renting the same work. If the new generation delivers meaningfully more performance per watt or per dollar, that test can favor a shift toward renting the new generation while continuing to run owned hardware for workloads that do not need the upgrade.

Is it cheaper to run GPU workloads on a neocloud than on AWS?

GPU-focused neoclouds often list lower per-GPU-hour prices than the major hyperscalers. Neoclouds build fleets optimized for GPU density, carry fewer bundled services, and compete primarily on price and availability for AI workloads. Hyperscalers bundle extensive ecosystem services (managed databases, identity, networking, ML tooling), broader compliance attestation coverage, and multi-region availability guarantees that can offset the sticker-price gap.

Factors that can narrow or reverse the neocloud price advantage:

Egress fees. Moving large datasets or model artifacts off a provider adds cost that is easy to overlook.
Storage. High-performance storage for training data and checkpoints varies widely in pricing.
Support and SLAs. Enterprise support tiers and uptime guarantees differ.
Contract terms. Commitment length, cancellation penalties, and price-lock provisions matter over a multi-year horizon.
Compliance scope. Not every provider holds the same attestations in every region.
Ecosystem services. If your pipeline depends on managed services (vector databases, model registries, logging), switching providers may require replacing those services.

Prices change often. Always compare current pricing pages before making a commitment. What each major provider offers, from its own official pages:

AWS EC2 offers GPU instances across families such as P5, P6, and G6 with on-demand, reserved, and spot pricing, plus deep integration with SageMaker and other ML services.
Google Cloud GPUs provides A2, A3, A4, and A4X accelerator-optimized and G2 and G4 graphics-optimized machine series alongside TPU access, integrated with Gemini Enterprise Agent Platform (formerly Vertex AI).
Microsoft Azure GPU VMs includes ND and NC series instances with Azure Machine Learning integration.
CoreWeave is a GPU-specialized cloud built on Kubernetes (CoreWeave Kubernetes Service), offering NVIDIA GPUs from A100 and H100 through B200, B300, and GB300 NVL72.
Lambda offers on-demand GPU instances, 1-Click Clusters of interconnected NVIDIA HGX B200 and H100 GPUs, and larger Superclusters for ML training and inference.
Nebius offers GPU clusters with InfiniBand networking for large-scale AI training.

For a more detailed comparison of these and other providers, see the best GPU cloud providers for 2026 roundup.

How do I evaluate capacity constraints and lead times when procuring GPUs for AI infrastructure expansion?

Cost modeling assumes you can actually get the hardware or capacity when you need it. In practice, procurement constraints shape the decision as much as price.

GPU and server lead times. Demand for current-generation GPUs has often outpaced supply, which can stretch lead times. Lead times for servers vary by OEM, configuration, and order volume. Check with your vendor for current estimates rather than relying on published figures that may be outdated.
Data center power and cooling capacity. Dense GPU racks draw significantly more power than standard compute. Rack-scale systems such as NVIDIA GB200 NVL72 use a liquid-cooled design, and not all colocation facilities support liquid cooling. Securing power capacity in a desired market can take months or longer.
Network gear lead times. InfiniBand switches, high-speed optics, and cabling have their own supply chains. A server cannot join a training cluster until its fabric is installed, so order both together.
Reserved capacity commitments in the cloud. Hyperscalers and neoclouds offer reserved instances or committed-use contracts, but availability of specific GPU models in specific regions is not guaranteed. Quota limits may restrict how many GPUs you can provision without a quota increase request.
Generational timing risk. Buying a large fleet of current-generation GPUs shortly before the next generation ships accelerates depreciation and may leave you with less competitive hardware. Stagger purchases or use shorter commitment windows to manage this risk.

What factors determine GPU hosting versus private cloud for compliant AI infrastructure workloads?

Data residency, attestation coverage, GPU tenant isolation, where prompts and model weights are stored, audit logging, and exit terms decide between hosted GPUs and a private cloud. If a provider cannot meet one of these in the region you need, private or self-hosted capacity wins regardless of price.

Which GPU hosting providers are best for developers and AI users who need compliance and privacy?

The best providers for compliance-sensitive AI work hold your required attestations in your target region, offer dedicated GPU hosts, and state in writing that they do not retain prompts or outputs. Use this checklist to test any provider or self-hosted environment:

Data residency. Confirm that the provider offers GPU capacity in the specific countries or regions your data must remain in. Not all GPU instance types are available in all regions.
Attestations. Verify that the provider holds the attestations your workload requires (for example SOC 2 Type II, PCI DSS, ISO 27001) and, for HIPAA data, whether it will sign a business associate agreement (BAA), in the specific region you plan to use. Attestation scope can vary by region and service.
Tenant isolation for GPUs. Understand whether GPU memory is isolated between tenants, whether you get dedicated or shared GPU hosts, and how the provider handles GPU memory clearing between workloads.
Model weight and prompt storage. Know where model weights, input prompts, and inference outputs are stored, cached, and logged. Confirm whether the provider retains any of this data.
Audit logs. Ensure the provider supplies audit logs for access, configuration changes, and data movement that meet your compliance framework’s requirements.
Exit terms. Review data deletion guarantees, data export mechanisms, and contract termination provisions before signing.

Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant. When you join your own GPU servers as locations with Control Plane Managed Kubernetes (MK8s), your workloads and the data they process run on your hardware, while Control Plane manages Kubernetes, orchestration, and routing and collects the logs and metrics behind its built-in observability.

How do I compare GPUs versus ASIC accelerators for AI compute cost, performance, and availability?

Cloud ASICs can cost less per hour for models they support, while GPUs run on any provider and on hardware you own. GPUs, particularly NVIDIA’s lineup, offer broad framework support (PyTorch, JAX, TensorFlow) and portability across providers. A model trained on NVIDIA GPUs in one environment generally runs on NVIDIA GPUs in another with little or no code change, provided CUDA, driver, and framework versions are compatible.

Cloud-specific ASICs take a different approach:

Google Cloud TPUs are custom-designed accelerators optimized for large-scale training and inference. They can deliver strong price-performance for supported model architectures, work with JAX, PyTorch, and TensorFlow, usually with TPU-specific tuning, and are available only on Google Cloud.
AWS Trainium and Inferentia are purpose-built chips for training (Trainium) and inference (Inferentia). They offer competitive pricing for supported models but require the AWS Neuron SDK and run only on AWS.

ASICs can lower per-hour cost for workloads that fit their supported frameworks and model architectures, but they tie you to a single cloud provider and toolchain. If your strategy depends on portability between owned and rented infrastructure, or between multiple providers, GPUs remain the safer choice. If you are committed to a single cloud and your models are well-supported by that cloud’s ASIC toolchain, the cost savings may justify the lock-in.

How can I invest in AI infrastructure that will withstand rising hardware costs?

To limit exposure to rising hardware costs, keep workloads portable, spread purchases across GPU generations and providers, and cut the GPU-hours each request needs.

Keep workloads portable in containers. Containerized workloads can move between owned GPU servers and rented cloud GPUs without rewriting application code.
Avoid over-buying a single generation. Stagger hardware purchases across GPU release cycles.
Mix providers. Spreading GPU capacity across multiple providers or between owned and rented infrastructure reduces dependency on any single vendor’s pricing, availability, or roadmap.
Measure utilization before buying. Run workloads on rented GPUs first to establish real utilization patterns, then apply the break-even model above to decide whether ownership is justified.
Keep model serving efficient. Quantization (running models at lower precision), dynamic batching, and efficient model architectures reduce the number of GPU-hours each request consumes, lowering cost regardless of whether you own or rent. For a deeper look at running inference across multiple GPU sources, see AI inference on multiple GPU clouds.
Use shorter commitments. One-year reserved instances or month-to-month colocation contracts preserve the ability to shift strategy when the next GPU generation arrives or rental prices drop.

How Control Plane approaches build-versus-rent

Control Plane is the platform for running unbreakable apps and agents. It combines any cloud, neocloud, and bare metal into a Global Virtual Cloud (GVC). A workload deployed to a GVC runs active-active in every location of that GVC, and a global endpoint routes each request to the nearest healthy location.

On Control Plane, GPU servers you own or colocate join the GVC as managed locations through MK8s. Rented GPU servers or Kubernetes clusters from a cloud or neocloud join the same GVC as additional locations through MK8s or BYOK (Bring Your Own Kubernetes, Control Plane’s option for connecting an existing cluster). GPU Ocean lets you pull GPU capacity from any provider, which you can do today with MK8s by joining GPU servers as locations.

A workload’s GPU request applies in every location of its GVC, so group locations that offer the same GPU model. Put owned GPU locations in a higher-priority routing tier and rented locations in a lower one. Control Plane sends traffic to the lower tier only when every location in the higher tier is unavailable, and within a tier a latency offset makes a location more or less likely to receive traffic. Your owned GPU servers serve normal traffic, and rented GPUs take over if owned locations become unavailable, with no change to the workload. Rented locations still run the workload’s minimum replicas while on standby, so count those GPU-hours at the committed rate when you calculate R.

On Control Plane-managed GPUs, drivers are installed automatically and Control Plane keeps driver versions current. Control Plane-managed regions offer NVIDIA T4 and A10G. For other GPU models, MK8s joins GPU servers you own or rent from neoclouds as additional locations. GPU workloads get the same Day 2 operations as any other workload on Control Plane, including built-in logs, metrics, and traces, mTLS with a deny-by-default internal firewall, and a tamper-proof audit trail, and MK8s locations expose full Kubernetes for teams that want operators or Helm charts.

As you acquire more owned capacity, add those servers as locations, and as you scale down, remove rented locations. Changing the owned-versus-rented mix only changes the GVC’s location list, not the workload. Adopting a new GPU generation can mean updating that request or deploying to a GVC built around the new model. Control Plane’s Universal Cloud Identity gives workloads short-lived, least-privilege access to 600+ AWS, GCP, and Azure services, with no long-lived cloud keys in your code, so a GPU job on your own servers can read training data from Amazon S3 or Google Cloud Storage without stored keys.

Control Plane’s 99.999% availability SLA applies to workloads running at least two replicas in at least two locations, and those locations can be on different providers, such as an owned MK8s location and a cloud region. Customers typically cut compute costs 30 to 50 percent compared with running directly on AWS, GCP, or Azure. That figure covers general compute; GPU rates are listed per GPU-hour on the pricing page.

For practical guidance on combining GPU capacity from multiple sources, see how to combine GPU capacity across providers. For the infrastructure requirements behind an inference layer, see what infrastructure do you need to run an inference layer.

FAQ

Is it cheaper to buy or rent GPUs for AI workloads in 2026?

Buying is cheaper only when sustained utilization exceeds the break-even level from this formula: U_breakeven = ((H − S) / L + O) / (N × 8,760 × R), where S is resale value. If your actual utilization exceeds that threshold, owning is cheaper. If it falls below, renting is cheaper.

How do I estimate total cost of ownership for AI infrastructure with GPU clusters and networking?

List every cost line for both options. For owning: hardware (GPUs, servers, InfiniBand or RoCE networking, storage), power, cooling, rack space, spares, maintenance, staff, software, and financing cost, with hardware amortized over its useful life. For renting: per-GPU-hour or reserved pricing, storage, egress, networking, support tier, and idle reserved capacity. Sum each side on an annual basis and divide by productive GPU-hours to get a comparable per-hour cost.

How do I evaluate ROI for building a GPU data center versus renting AI infrastructure capacity?

Calculate the owned cost per useful GPU-hour using ((H − S) / L + O) / (N × 8,760 × U) and compare it to the rented price per GPU-hour R. Run the model at multiple utilization and useful-life assumptions. Structure the analysis as a three-year budget with a review point when the next GPU generation ships.

Is it cheaper to run GPU workloads on a neocloud than on AWS?

Neocloud list prices are often lower per GPU-hour because they run GPU-focused fleets with fewer bundled services. However, egress fees, storage costs, support tiers, availability guarantees, compliance scope, and ecosystem services can offset the difference. Compare current pricing pages from each provider before committing, and see the best GPU cloud providers for 2026 for a fuller comparison.

What factors determine GPU hosting versus private cloud for compliant AI infrastructure workloads?

Data residency, attestation coverage (SOC 2 Type II, PCI DSS, ISO 27001), a signed HIPAA BAA where needed, tenant isolation for GPUs, storage of model weights and prompts, audit log availability, and exit terms. Verify each factor per provider and per region, not just at the company level.

How do I compare GPUs versus ASIC accelerators for AI compute?

Choose GPUs for portability and ASICs for lower cost inside a single cloud. GPUs (NVIDIA) offer broad framework support and portability across providers. Cloud ASICs like Google TPUs and AWS Trainium can lower cost for supported models but tie you to one cloud and toolchain. If your strategy requires moving workloads between owned and rented infrastructure, GPUs are the portable choice.

How can I future-proof my AI infrastructure investment?

Containerize workloads for portability, avoid over-buying a single GPU generation, use shorter commitment windows, mix providers, measure utilization before purchasing, and keep model serving efficient through quantization and batching. See AI inference on multiple GPU clouds for practical patterns.

How does Control Plane help with the build-versus-rent decision?

Control Plane lets you run the same workload on GPU servers you own (joined via MK8s) and on rented cloud GPUs in a single GVC. Priority routing tiers and latency offsets let you prefer owned GPUs and use rented capacity as fallback. The build-versus-rent split changes by adding or removing GVC locations, without editing workload definitions.

What GPU models does Control Plane support?

Workloads can attach NVIDIA GPUs, and Control Plane’s pricing page lists models from T4 to B200, with per-second billing on NVIDIA accelerators, subject to availability. Control Plane-managed regions offer NVIDIA T4 and A10G. For other models, MK8s joins GPU servers you own or rent from neoclouds as additional locations.

Should I use a hybrid approach for GPU infrastructure?

Most teams benefit from a hybrid strategy: own or reserve GPUs for steady baseline demand where utilization will be high, and rent on-demand or reserved cloud GPUs for peaks, experiments, and access to new hardware generations. On Control Plane, owned and rented GPU capacity are locations in the same GVC, so one workload definition covers both, and routing tiers keep rented capacity as failover for owned GPUs.

Talk to the Control Plane team or sign up free to try it.

Originally published on the Control Plane blog.

Day 2 Operations for AI Infrastructure: How to Keep Model Serving Running 24/7

Noah Grinstein — Mon, 02 Nov 2026 23:38:36 +0000

Keeping AI infrastructure running 24/7 takes automated patching and upgrades, autoscaling, three layers of observability (infrastructure, serving, and model and data), tested incident response, and policy-controlled automation. You can staff all of it yourself, buy managed services piece by piece, or use a platform that handles the infrastructure layer for you. Control Plane handles Day 2 operations for the workloads it runs, including autoscaling, Capacity AI (Control Plane’s right-sizing of CPU and memory reservations from historical usage), built-in observability, and security, so teams focus on models and data instead of clusters.

Disclosure: Control Plane publishes this guide.

See Control Plane’s guides on what is AI-ready infrastructure and what infrastructure you need to run an inference layer.

TL;DR

Day 2 for AI is everything after the first successful deployment: the ongoing work of patching, upgrading, scaling, monitoring, responding to incidents, controlling costs, and enforcing policy across inference infrastructure.
The operations that matter most are OS and node patching, GPU driver and CUDA upgrades, model server upgrades, autoscaling, capacity planning, certificate rotation, backups, observability, incident response, and cost control.
Three observability layers are required: infrastructure metrics (CPU, memory, GPU utilization), serving metrics (latency percentiles, error rates, tokens per second), and model and data metrics (prediction quality, input drift, cost per request).
Build vs. managed vs. platform : you can run raw Kubernetes yourself, use hyperscaler managed services, or adopt a platform that operates the infrastructure layer for you. Each trades off control, staffing, and portability differently.
Control Plane is the platform option built for Day 2. It runs workloads active-active across locations with no Kubernetes cluster you have to operate.

What are Day 2 operations for AI infrastructure?

Day 1 is getting a model into production: provisioning compute, deploying a model server, and routing the first request. Day 2 is everything after. It covers patching, upgrades, scaling, monitoring, and incident response. A typical Day 2 failure is a GPU driver update that breaks CUDA compatibility and takes down a model server.

AI infrastructure amplifies Day 2 complexity compared to traditional software. GPU resource constraints, model versioning, drift detection, and bursty workloads create failure modes that standard web services rarely encounter. Skipped Day 2 tasks rarely cause an outage right away. The risk builds until it shows up as a production incident, often during a traffic spike or an unrelated change.

Day 2 Task	What Goes Wrong If Skipped	Typical Recurrence
OS and node patching	Known CVEs remain exploitable; compliance audits fail	Weekly to monthly
Kubernetes upgrades	Version goes out of support; API deprecations break workloads	About every 4 months upstream; at least once a year to stay in standard support on EKS, GKE, or AKS
GPU driver and CUDA upgrades	New model frameworks require newer drivers; performance regressions go unfixed	Quarterly to biannually
Model server upgrades	Missing bug fixes, security patches, and performance improvements	Monthly to quarterly
Autoscaling configuration	Cold starts violate latency SLOs; idle GPUs waste budget	Continuous tuning
GPU capacity planning	Spike in traffic exhausts GPU quota; requests queue or drop	Monthly review
Certificate and secret rotation	Expired certs cause hard outages; leaked secrets enable breaches	Automated, before expiry (Let’s Encrypt certificates last 90 days, and public TLS certificate lifetimes drop to 47 days by 2029); secrets per your rotation policy
Backups	Data loss after storage failure; no rollback path for model artifacts	Daily to weekly
Observability	Silent failures go undetected; debugging takes hours instead of minutes	Continuous
Incident response	Mean time to recovery stretches from minutes to hours	Every incident
Cost control	GPU spend grows unchecked; finance loses trust in engineering forecasts	Weekly review
Policy enforcement	Misconfigured workloads reach production; compliance drift	Every deployment

How can AI operable infrastructure automate patching, upgrades, and policy enforcement for clusters?

Automate them with managed node auto-upgrades, pinned and tested GPU driver images, rolling and canary rollouts, and admission-control policies that also run in CI.

Automated node image updates. All three major managed Kubernetes services can roll out new node images for you. Amazon EKS managed node groups update to the latest EKS optimized AMI in one operation that you start, and EKS Auto Mode replaces nodes automatically at least every 21 days. Google Kubernetes Engine enables node auto-upgrade by default. Azure Kubernetes Service offers node OS auto-upgrade channels and defaults new clusters to the weekly NodeImage channel. When a node must be replaced, it is drained and replaced in a rolling fashion.

GPU driver and CUDA version management. GPU driver upgrades are higher risk than standard node patches because a mismatch between the driver version, CUDA toolkit, and the model framework (PyTorch, TensorFlow, vLLM) can stop the model server from starting, crash inference, or quietly cost performance. The safe pattern is to pin a tested driver and CUDA version in your node image, validate it against your model server in a staging environment, and only then roll it out to production nodes. Avoid letting auto-upgrade channels change GPU drivers without testing.

Rolling upgrades with surge capacity. Rolling upgrades replace pods or nodes one at a time (or in small batches) while maintaining enough healthy replicas to serve traffic. For CPU nodes, a surge of one or two extra nodes prevents capacity dips. GPU surge capacity may be unavailable or costly, so many teams set surge to zero, keep enough spare replicas to lose one node, and upgrade off-peak. Set a PodDisruptionBudget, and gate traffic on a readiness probe that passes only after the model is loaded, so a replica is not drained before its replacement can serve.

Canary upgrades for model servers. Before promoting a new model server version to all replicas, deploy it to a single replica and compare its latency, error rate, and output quality against the existing version under real traffic. If metrics degrade beyond a threshold, roll back automatically.

Policy as code. Admission controllers such as Open Policy Agent Gatekeeper and Kyverno enforce rules at deploy time: requiring resource limits on GPU workloads, blocking images from untrusted registries, mandating labels for cost allocation, and preventing privileged containers. Running the same policies in CI catches violations before they reach the cluster.

How do I design observability and operations for AI-ready infrastructure supporting 24/7 model serving?

Design it around three observability layers, SLOs with error budget burn-rate alerts, and a tested incident runbook, so every alert maps to a layer and a response.

How can I add observability for AI infrastructure including model metrics, data drift, and system logs?

Add observability in three layers: infrastructure, serving, and model and data.

Layer 1: Infrastructure metrics. This layer covers the compute substrate. Key signals include CPU and memory utilization, GPU utilization and GPU memory headroom via NVIDIA DCGM, node health, disk I/O, network throughput, SM activity (a truer load signal than GPU utilization), power and thermal throttling, and GPUs that sit allocated but idle. System logs from the OS, kubelet, and container runtime surface hardware errors, OOM kills, and GPU Xid errors. Some Xid codes point to failing hardware (Xid 79 means the GPU has fallen off the bus), and others point to application or driver faults.

Layer 2: Serving metrics. This layer covers the model server and its request handling. Key signals include request rate, server error rate (5xx) tracked apart from 429 rate-limit responses, latency percentiles (p50, p95, p99), time to first token and inter-token latency for streaming LLM endpoints, tokens per second, queue depth, batch size, KV cache usage and request preemptions (vLLM exports both as Prometheus metrics), model load time, and cold start frequency.

Layer 3: Model and data metrics. This layer covers the correctness of what the model produces. Key signals include prediction quality (accuracy, F1, or domain-specific metrics when labels are available), drift in input feature distributions compared to training data, feedback signals from users or downstream systems, and cost per request broken down by model and team. Silent failures, where the endpoint returns 200 OK but the output is wrong, are only caught at this layer.

Tooling recommendations. OpenTelemetry provides a vendor-neutral standard for collecting traces, metrics, and logs. Prometheus scrapes and stores time-series metrics. Grafana builds dashboards and supports alerting. Define SLOs for latency, availability, and error rate, then set alerts on error budget burn rate rather than raw thresholds. Use multiwindow, multi-burn-rate alerts as described in the Google SRE Workbook. A fast window catches sharp spikes and pages. A slow window catches gradual burn and opens a ticket.

What managed operations services help run AI infrastructure 24/7 with reliability and incident response?

Managed options include hyperscaler Kubernetes services (Amazon EKS, Google Kubernetes Engine, Azure Kubernetes Service), hyperscaler ML platforms, and platforms such as Control Plane that handle Day 2 operations for the workloads they run.

Which providers offer managed AI operations and maintenance for AI infrastructure?

The three approaches differ in what you still operate, how many platform engineers you need, and how portable your workloads are.

Dimension	Platform (Control Plane)	Self-Managed Kubernetes	Hyperscaler Managed Services
What you still operate	Models, data, and application logic. On Control Plane-provided compute, the platform handles compute, GPU drivers, scaling, infrastructure and serving observability, networking, and security	Everything: OS, Kubernetes, GPU drivers, networking, observability, scaling, security	Kubernetes control plane is managed; you operate node pools, GPU driver version testing, model servers, observability, scaling policies
Staffing needed	No dedicated platform team required	Dedicated platform engineering team	Smaller platform team, but still needed for GPU ops and observability
Portability	Workloads run on AWS, GCP, Azure, neocloud GPU servers, and on premises, in any mix and active-active, through one API; full Kubernetes stays available on your own clusters and servers	High (standard Kubernetes)	Workloads are portable, but node pools, IAM, networking, and GPU setup are per cloud
Best for	Teams that want production-grade infrastructure without a platform team	Teams with deep Kubernetes expertise that want to own and staff every layer	Teams committed to one cloud with moderate operational capacity

Hyperscaler managed Kubernetes services (Amazon EKS, Google Kubernetes Engine, Azure Kubernetes Service) reduce the burden of managing the Kubernetes control plane but still leave GPU driver version testing, node pool configuration, autoscaling policies, observability setup, and security hardening to you. Each cloud also offers managed ML platforms (Amazon SageMaker AI, Google Gemini Enterprise Agent Platform (formerly Vertex AI), Azure Machine Learning), which further abstract infrastructure but tie your training and serving pipelines to that cloud’s APIs, identity, and storage, making a move to another cloud harder.

How should I handle incident response for AI model serving?

Handle incidents with SLO-based detection, triage by observability layer, rollback before root-cause analysis, failover to healthy locations, early stakeholder updates, and a written post-incident review.

Detect with SLO-based alerts. An error budget burn rate alert fires when errors are using up the budget fast enough to matter, well before it runs out.
Triage by layer. Is the problem infrastructure (node down, GPU error), serving (model server crash, queue backup), or model/data (drift, bad predictions)? Check each observability layer in order.
Roll back the model or the deployment. If a recent model update or infrastructure change correlates with the alert, roll back first and investigate second.
Fail over to another location. If the problem is localized to a region or availability zone, shift traffic to healthy locations. Multi-location serving makes this possible without manual intervention.
Communicate. Notify stakeholders with what is known, what is being done, and when the next update will come.
Write a post-incident review. Document the timeline, root cause, contributing factors, and action items. Share it broadly.

Multi-location serving shortens incidents because traffic shifts to replicas already running in other locations. Size each location with enough headroom, or enough autoscaling room, to absorb a failed location’s traffic. This matters because major cloud regions experience multi-hour outages regularly. Control Plane’s cloud outage tracker documents these events across AWS, GCP, and Azure, showing that relying on a single region creates a predictable availability ceiling.

How do I implement CI/CD for AI infrastructure and machine learning pipelines on Kubernetes?

Version code, data, and models together, gate every model on evaluation results, and deploy through GitOps with canary rollouts and automatic rollback.

Version everything. Store application code in Git. Track data versions with DVC or a similar tool. Store model artifacts in a model registry with metadata about training data, hyperparameters, and evaluation results.

Build model-server containers. Use reproducible container builds that pin the base image by digest, the CUDA runtime version (which the host GPU driver must support), and the model framework version. Tag images with the model version and the commit hash.

Run evaluation gates before promotion. Automated tests compare the candidate model’s accuracy, latency, and resource consumption against the current production model. If the candidate fails any gate, the pipeline stops.

Deploy with GitOps or a CI tool. Argo CD and Flux watch a Git repository for changes and reconcile the cluster state to match. Alternatively, a CI tool can apply Kubernetes manifests or Helm charts directly.

Canary and roll back. Route a small fraction of traffic to the new deployment. Monitor serving metrics and model quality. If metrics degrade, roll back automatically.

Keep infrastructure as code. Define all infrastructure, including clusters, node pools, networking, and policies, in version-controlled templates.

Which tools automate AI infrastructure provisioning and policy enforcement for multi-cloud environments?

Infrastructure as code tools, policy engines, GitOps controllers, and multi-cloud platforms handle provisioning and policy enforcement across clouds.

Infrastructure as code. Terraform and OpenTofu use declarative HCL to provision resources across AWS, GCP, and Azure. Pulumi offers the same capability using general-purpose programming languages. All three support state management and plan previews, and can detect drift by comparing live resources with recorded state; scheduled drift detection is a feature of HCP Terraform and Pulumi Cloud paid tiers.

Policy engines. Open Policy Agent evaluates policies written in Rego against Kubernetes admission requests, Terraform plan output, and API calls. Gatekeeper runs OPA policies as a Kubernetes admission controller, and Kyverno is an alternative that uses YAML and CEL policies instead of Rego.

GitOps controllers. Argo CD and Flux reconcile cluster state against a Git repository, providing an audit trail of every change and enabling rollback by reverting a commit.

Platforms that expose one API across clouds. Rather than maintaining separate Terraform modules, CI pipelines, and observability stacks for each cloud, a platform approach provides a single API for deploying and operating workloads everywhere. Control Plane takes this approach, with one API across AWS, GCP, Azure, neoclouds, and your own servers. Control Plane ships its own Terraform and Pulumi providers, so it complements the infrastructure as code you already run.

What are the best AI controlled infrastructure platforms for managing spot instances?

Spot and preemptible instances offer deep discounts (AWS advertises up to 90% off On-Demand prices, Google Cloud up to 91%, and Azure up to 90% off pay-as-you-go prices) but can be reclaimed at short notice. AWS gives a two-minute interruption notice, and Google Cloud and Azure give about 30 seconds. Model load time often exceeds that window, so a replica on spot capacity must stop taking traffic and drain as soon as the notice arrives. Tools that manage this include Karpenter on AWS, which watches for interruption notices and replaces nodes, and GKE Spot node pools with the cluster autoscaler. Spot GPUs are also scarcer than spot CPUs, so expect reclaims and stockouts.

Good candidates for spot capacity:

Batch inference jobs that can be restarted
Training runs with periodic checkpointing, so progress is not lost on interruption
Stateless inference replicas with sufficient headroom, where losing one replica does not drop all traffic

Poor candidates for spot capacity:

Single-replica serving endpoints, where an interruption means a full outage
Latency-sensitive endpoints without fallback replicas on on-demand capacity

The recommended approach is to mix on-demand and spot capacity. Run a baseline of on-demand replicas to guarantee minimum availability, and add spot replicas for burst capacity. Checkpoint training jobs frequently. Use multi-location fallback so that if spot capacity is reclaimed in one location, traffic shifts to replicas in another.

Is it safe to let AI agents help operate AI infrastructure?

Yes, if agents start with read-only access and every change goes through scoped permissions, approval gates, and an audit trail.

Low risk with read-only access:

Read-only diagnosis: querying logs, metrics, and deployment status (treat log content as untrusted input, and redact secrets)
Summarizing error patterns across time windows
Proposing configuration changes for human review
Generating runbook steps from incident context

Requires guardrails:

Restarting or scaling workloads (scoped permissions, approval gates)
Modifying network policies or secrets (approval for destructive actions)
Deploying new versions (CI/CD pipeline integration, not direct API calls)

Give agents least-privilege permissions and record every action they take. On Control Plane, the MCP server connects AI assistants such as Claude to the Control Plane API over the Model Context Protocol, so they can query logs and metrics, diagnose a failing workload, and restart or roll it back, within the orgs you authorize and the toolset profile you choose, including a read-only profile. Every action is recorded in Control Plane’s tamper-proof audit trail. The CLI, console, Terraform and Pulumi providers, and the MCP server all work through the same Control Plane API.

How Control Plane approaches Day 2 operations for AI workloads

Control Plane is the platform for running unbreakable apps and agents. It combines AWS, GCP, Azure, neocloud and bare-metal servers, and on-premises machines into Control Plane’s Global Virtual Cloud (GVC), a set of locations a workload runs across. On Control Plane-provided compute, there is no Kubernetes cluster you have to operate. Control Plane handles Day 2 operations for you, including autoscaling, Capacity AI right-sizing of CPU and memory, built-in observability, and security.

For teams that need to use their own servers, including GPU servers, Control Plane’s Managed Kubernetes (MK8s) turns those machines into managed locations. Control Plane operates the Kubernetes layer on servers you join, and the hardware stays yours.

Built-in observability collects metrics and logs for every workload in every location, plus traces once tracing is turned on for the org or GVC, with no third-party agent to install. Each org gets Grafana with built-in alert rules, and a workload can expose its own metrics, such as a model server’s tokens per second or queue depth, for Control Plane to scrape and autoscale on. Logs can be forwarded to Datadog, Coralogix, Syslog, Fluentd, or any OpenTelemetry target, and metrics can be federated into your own Prometheus. Model quality and drift monitoring stay in your ML tooling.

Multi-location availability is a core architectural feature. A workload deployed to a GVC runs active-active in every location of that GVC, and a global endpoint routes each request to the nearest healthy location. Readiness probes (HTTP, gRPC, TCP, or a command) decide when each replica can take traffic, and when a location has no ready replicas the global endpoint routes requests to another healthy location. The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. Those locations can be two regions of one cloud or locations on different providers.

This architecture proved its value during the October 20, 2025 AWS us-east-1 outage, which lasted about 15 hours and affected more than 100 AWS services. Control Plane customers with us-east-1 in their GVC had no downtime, and their workloads were “active and running in healthy locations within 10 seconds,” according to Control Plane internal incident telemetry.

GPU workloads. Workloads can attach NVIDIA GPUs, and the pricing page lists models from T4 to B200. On Control Plane-managed GPUs, drivers are installed automatically and Control Plane keeps driver versions current. Teams serving AI inference across several GPU providers group those GPU locations into one GVC. Control Plane-managed regions offer NVIDIA T4 and A10G, and for other models MK8s joins GPU servers from neoclouds or your own data center as additional locations. The workload’s GPU request applies in every location of the GVC.

Security defaults. Workloads are closed by default behind a deny-by-default internal firewall. Traffic between workloads uses mTLS. Each workload is isolated with cgroups, namespaces, and restricted syscalls and capabilities. Control Plane’s built-in secrets management keeps secret values out of code and images. Universal Cloud Identity, Control Plane’s credential-free cloud access, gives workloads short-lived, least-privilege access to 600+ services across AWS, GCP, and Azure, such as pulling model weights from Amazon S3 or Google Cloud Storage, with no long-lived cloud keys in your code.

Cost efficiency. Customers typically cut compute costs 30 to 50 percent compared with running directly on AWS, GCP, or Azure. On Control Plane-provided compute, you pay for the CPU and memory you reserve, by the millicore and the megabyte, with no contracts or minimums. Egress, storage, observability, dedicated load balancers, and GPUs are billed separately.

Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant.

FAQ

What are Day 2 operations for AI infrastructure?

Day 2 operations are the ongoing tasks required after initial deployment to keep AI inference services running reliably. They include patching, upgrading, autoscaling, observability, incident response, cost control, and policy enforcement.

How do Day 2 operations differ from Day 1 for AI systems?

Day 1 is provisioning compute and deploying a model for the first time. Day 2 is maintaining that deployment over weeks, months, and years, handling upgrades, scaling, monitoring, and incidents as they arise.

What observability do I need for AI infrastructure including model metrics, data drift, and system logs?

Three layers: infrastructure metrics (CPU, memory, GPU utilization, node health), serving metrics (latency, error rate, tokens per second, queue depth), and model and data metrics (prediction quality, input drift, cost per request). OpenTelemetry, Prometheus, and Grafana are widely used open-source tools for collecting and visualizing these signals.

Which providers offer managed AI operations for scalable and reliable deployment?

Hyperscaler managed Kubernetes services (Amazon EKS, Google Kubernetes Engine, Azure Kubernetes Service) manage the Kubernetes control plane but leave GPU operations, observability, and scaling to you. On Control Plane-provided compute, Control Plane operates the infrastructure layer, including GPU drivers, autoscaling, observability, networking, and security, so teams focus on their models and application logic. On your own servers, Control Plane’s Managed Kubernetes (MK8s) operates the Kubernetes layer while the hardware stays yours.

How do I implement CI/CD for AI infrastructure and machine learning pipelines on Kubernetes?

Version code, data, and models. Build reproducible model-server containers. Run evaluation gates before promotion. Deploy with GitOps tools like Argo CD or Flux. Use canary deployments with automatic rollback based on serving and model quality metrics.

What tools automate AI infrastructure provisioning and policy enforcement for multi-cloud environments?

Infrastructure as code tools (Terraform, OpenTofu, Pulumi), policy engines (Open Policy Agent with Gatekeeper, or Kyverno), and GitOps controllers (Argo CD, Flux) form the foundation. Control Plane adds a single API across clouds with its own Terraform and Pulumi providers.

How should I handle incident response for AI model serving?

Detect with SLO-based alerts, triage by observability layer (infrastructure, serving, model), roll back recent changes, fail over to healthy locations, communicate with stakeholders, and write a post-incident review. Multi-location serving shortens incidents because traffic shifts to replicas already running elsewhere, as long as those locations have headroom.

Is it safe to let AI agents help operate AI infrastructure?

Yes, if agents start read-only. Querying logs and metrics is low risk, though log content should be treated as untrusted input. Actions that modify state, such as restarting workloads or deploying new versions, need scoped permissions, approval gates, and a tamper-proof audit trail. On Control Plane, the MCP server can connect with a read-only toolset profile for safe diagnosis, reaches only the orgs you authorize, instructs the assistant to explain the impact and get your approval before it deletes or overwrites resources, and records every action in Control Plane’s tamper-proof audit trail.

What are the best approaches for managing spot instances for AI workloads?

Spot capacity works well for batch inference, training with checkpoints, and stateless inference with headroom. It is risky for single-replica serving. Mix on-demand and spot capacity, checkpoint frequently, and use multi-location fallback to handle interruptions.

How does Control Plane handle Day 2 operations for AI workloads?

Control Plane handles autoscaling, Capacity AI right-sizing, built-in observability, security, and multi-location failover with no Kubernetes cluster to operate. Workloads run active-active across locations with a global endpoint that routes to the nearest healthy replica. The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations.

Talk to the Control Plane team or sign up free to try it.

Originally published on the Control Plane blog.

How to Run Regulated Apps in the Cloud: SOC 2, HIPAA, and PCI DSS Platforms, Data Residency With Failover, and a Compliance Checklist

Noah Grinstein — Mon, 02 Nov 2026 23:37:24 +0000

A compliant application platform gives you audited infrastructure controls, but compliance is shared: you still need your own controls for data classification, identity, secrets management, and logging. To keep data in one country with failover, run in at least two locations inside that country and ensure every replica, backup, and log stays there. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant, and it runs a workload only in the locations you choose across AWS, GCP, Azure, and your own servers.

Disclosure: Control Plane publishes this guide.

This is general guidance, not legal or audit advice.

TL;DR

What platform compliance covers. SOC 2 Type II, HIPAA eligibility, and PCI DSS attestations apply to the platform’s services, not your application logic or data handling.
How to verify a platform ’s claims. Request the SOC 2 Type II report under NDA, the PCI DSS Attestation of Compliance, and a signed BAA. Check which services and regions are in scope.
Data residency with failover. Choose two or more locations inside the same country, run active-active or active-passive between them, and pin replicas, backups, logs, and keys to those locations.
The compliance checklist. Classify data, enforce region allow-lists with policy as code, manage secrets outside your codebase, isolate tenants, log everything immutably, and document AI data flows.
How Control Plane fits. On Control Plane, a workload runs only in the locations of Control Plane’s Global Virtual Cloud (GVC), a set of locations a workload runs across, so you control data residency by choosing locations. Workloads deploy active-active across every location in a GVC, and a global endpoint routes each request to the nearest healthy location.

Which application platforms are SOC 2 Type II, HIPAA, and PCI DSS compliant?

AWS, Google Cloud, and Azure each hold SOC 2 Type II reports and PCI DSS Level 1 service provider attestations, and each signs a BAA covering a published list of HIPAA-eligible services. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant. Its SOC 2 Type II audit was completed by Prescient Assurance, and its SOC 2 Type II report and PCI DSS Attestation of Compliance are available from support@controlplane.com, and its docs publish a PCI Responsibility Matrix.

What each framework means for a platform buyer

SOC 2 Type II is an attestation report from an independent CPA firm. The auditor tests whether a platform’s controls operated effectively over a review period, commonly three to twelve months. A Type I report covers only control design at a single point in time. Platforms renew the report each year, so check the period end date and ask for a bridge letter if it ended months ago. A badge on a marketing page shows none of the scope or exceptions, so ask for the report itself.

HIPAA has no official certification program. The U.S. Department of Health and Human Services does not certify software or cloud platforms as “HIPAA compliant.” Instead, look for two things: a signed Business Associate Agreement (BAA), which sets out how the platform must protect electronic protected health information (ePHI), and a clear list of HIPAA-eligible services. Under the HITECH Act, a platform that handles ePHI as a business associate is also directly liable for complying with the HIPAA Security Rule. Any service not on that list should not touch ePHI.

PCI DSS compliance is documented in an Attestation of Compliance (AoC), the official PCI Security Standards Council form summarizing the results of an assessment. Platforms that process, store, or transmit cardholder data are assessed as service providers. Card brands such as Visa and Mastercard classify a service provider as Level 1 when it handles more than 300,000 card transactions a year, and Level 1 requires an annual assessment by a Qualified Security Assessor (QSA) and a Report on Compliance. The AoC states which services and environments are in scope.

How to verify a platform’s compliance

Request the SOC 2 Type II report under NDA. Read the auditor’s opinion, the description of the system boundary, and any exceptions noted.
Request the PCI DSS Attestation of Compliance. Confirm the service provider level and check which services and data center regions are covered.
Request a signed BAA before any ePHI touches the platform. Confirm the list of HIPAA-eligible services.
Check scope : which regions, which services, and which deployment models are included. A platform may be compliant in some regions but not others.

AWS, Google Cloud, and Azure each publish compliance programs with lists of in-scope services. AWS maintains its compliance programs page, Google Cloud publishes its compliance offerings, and Azure documents its compliance offerings.

Who owns which compliance controls, the platform or the customer?

The table below maps common control areas to who typically owns them.

Control Area	Typically Responsible	Evidence to Collect
Infrastructure security (host OS, hypervisor, physical)	Platform	SOC 2 Type II report, penetration test summaries
Network segmentation and firewalls	Shared	Network architecture diagrams, firewall rule exports
Identity and access management	Customer	SSO configuration, MFA enforcement logs, RBAC policies, access reviews
Secrets management	Customer	Secrets manager configuration, rotation logs, proof secrets are not in code
Data encryption (at rest and in transit)	Shared	Encryption configuration, key custody documentation, TLS certificates
Logging and audit trails	Shared	Log retention policies, tamper-resistance proof, SIEM integration
Application code security	Customer	SAST/DAST scan results, dependency vulnerability reports, change approvals
Data classification	Customer	Data inventory, classification tags, handling procedures
Backups and disaster recovery	Shared	Backup location confirmation, restoration test results, RTO/RPO evidence
Incident response	Shared	Incident response plan, tabletop exercise records, notification procedures

A platform’s audit reports cover the rows marked Platform and the platform’s part of the Shared rows. Rows marked Customer or Shared need your own controls and evidence.

How do I keep customer data in a specific country while still having multi-region failover?

Run the application in two or more locations inside the country, replicate data only between those locations, and keep every replica, backup, log, and key in-country. Traffic fails over between the in-country locations, never to a region abroad.

Architecture options:

Active-active between two in-country locations removes failover delay, because each location already serves traffic, and a global load balancer routes requests to the nearest healthy one.
Active-passive keeps a standby location in-country that takes over during an outage. It costs less but introduces failover time.

Databases in active-active. The application tier can run active-active, but most relational databases accept writes on one primary. Put the primary in one in-country location and a replica in the other, and send writes from both locations to the primary. Synchronous replication gives a recovery point objective (RPO) of zero, meaning no committed write is lost, at the cost of added write latency. In-country locations are usually close enough to keep that cost low. Asynchronous replication adds no write latency but can lose writes not yet copied when the primary fails. On failure, promote the replica and repoint the application. Use a quorum or fencing so two primaries never accept writes at once. To accept writes in every location, use a distributed SQL database such as CockroachDB, YugabyteDB, or Google Cloud Spanner, and keep all of its nodes in-country.

For a deeper comparison of these patterns, see active-active vs. active-passive cost and architecture trade-offs.

What to pin in-country:

Primary database and all replicas
Backups and snapshots
Object storage buckets
Application logs and audit logs
Encryption keys
Cache layers

What to check:

Where does the platform’s support staff access data from?
Where do telemetry and monitoring data flow?
Where does TLS terminate? Global load balancers and CDNs can decrypt requests at edge sites outside the country.
Where do managed AI APIs send prompts and responses for processing?
Does the platform offer contractual commitments on data location?

Where can I find a cloud provider that keeps my data in one country to reduce risk?

AWS, Google Cloud, and Azure each run two or more regions in the United States, Canada, Australia, Japan, and India, so one provider can cover in-country failover in those countries. Not every country has two cloud regions from a single provider. In those cases, combining regions from multiple providers, or adding your own data center, may be the only viable in-country option. A detailed breakdown of provider coverage by country is available in best cloud providers for data sovereignty in 2026. For architectural patterns, see sovereign cloud architecture for data residency compliance.

What practical controls ensure data residency and sovereignty in a multi-cloud infrastructure?

Region allow-lists enforced by policy. Each major cloud has a native mechanism: AWS Service Control Policies with aws:RequestedRegion conditions (with exemptions for global services such as IAM), Azure Policy’s built-in Allowed locations policy, and the Google Cloud resource locations organization policy constraint.
Data classification and tagging. Tag every resource with its data classification (e.g., data-class: phi, data-class: pci). Use tags to trigger policy enforcement and to generate audit reports.
Encryption with keys held in-region. Store encryption keys in the same jurisdiction as the data they protect. Cross-border key storage can undermine sovereignty even if the ciphertext stays in-country.
Egress controls. Block or alert on data transfers to regions outside the approved list. Use VPC flow logs, firewall rules, and DLP inspection at egress points.
Residency-aware backups. Explicitly configure backup destinations. Some services copy backups or geo-redundant replicas to a second region by default or with a single setting, and that region is not always in the same country. For example, Azure geo-redundant storage replicates to the paired region, and Brazil South is paired with South Central US. Multi-region storage locations such as Google Cloud’s EU or US buckets span several countries.
Logging location. Route logs to a logging service or bucket pinned to an approved region. If you use a third-party logging provider, confirm where they store and process your data.
Regular audits. Periodically scan for resources created outside approved regions. Automated compliance scanners can flag drift before it becomes an audit finding.

What cloud compliance checklist should I follow when migrating a regulated application to AI infrastructure?

AI workloads introduce new compliance surfaces. Prompts, model outputs, training data, and vector store contents can all contain regulated data. Follow this checklist:

Classify data before it reaches a model. Determine whether inputs contain ePHI, cardholder data, PII, or other regulated categories. Apply classification before inference, not after.
Decide what can go to third-party model APIs. If you use external APIs for inference, confirm the provider’s compliance posture, sign the appropriate agreements (BAA, DPA), and understand where prompts and responses are processed and stored. Confirm in writing that prompts are not used for training and how long the provider keeps them.
Prefer self-hosted or in-region inference for regulated data. Running models on infrastructure you control, within approved regions, keeps regulated data off third-party networks.
Log prompts and outputs with redaction. Maintain audit logs of what was sent to a model and what it returned. Redact or tokenize regulated fields before logging.
Apply access control to models and vector stores. Treat model endpoints and vector databases as regulated data stores. Enforce RBAC, authentication, and network segmentation.
Keep training and fine-tuning data in-region. If you fine-tune models on regulated data, the training data, checkpoints, and resulting model weights must stay within approved jurisdictions.
Document data flows for auditors. Create a data flow diagram that shows how regulated data moves through your AI pipeline: ingestion, preprocessing, inference, post-processing, storage, and deletion. Auditors will ask for this.
Plan for deletion. Embeddings and fine-tuned weights derived from personal data must be deletable when a data subject asks for erasure, so record which data each one came from.

What are the best practices for secrets management in IaC pipelines to meet cloud compliance requirements?

Secrets in infrastructure-as-code pipelines are a frequent audit finding and a common attack vector.

No secrets in code, state files, or CI logs. Credentials leaked in repositories are a common way attackers get cloud access. Terraform writes values read through data sources into state; Terraform 1.10 added ephemeral resources and 1.11 added write-only arguments to keep secrets out of state and plan files.
Use a secrets manager, referenced by name. Store secrets in a dedicated service such as AWS Secrets Manager, Google Cloud Secret Manager, or Azure Key Vault, or in HashiCorp Vault. IaC templates should reference secret names, never values.
Short-lived credentials through workload identity federation. Replace static API keys with short-lived federated tokens that expire automatically, typically within an hour. AWS, GCP, and Azure all support workload identity federation natively.
Least-privilege pipeline roles. The CI/CD service account should have only the permissions needed for the current deployment. Separate roles for plan and apply stages.
Rotation. Automate rotation on a defined schedule, and rotate immediately after a suspected exposure or when someone with access leaves. Log every rotation.
Secret scanning in CI. Run tools like Gitleaks or TruffleHog in your CI pipeline to catch secrets before they merge.
Encrypted and access-controlled IaC state. Terraform and Pulumi state files can contain sensitive values. Encrypt state at rest, restrict access to the state backend, and audit who reads it.

How should I structure governance and policy as code for compliant multi cloud infrastructure using IaC?

Policy as code turns compliance rules into enforceable, version-controlled, auditable artifacts. Structure it in layers:

Preventive guardrails at the account or organization level. These are the broadest controls. Service Control Policies in AWS, Organization Policies in Google Cloud, and Azure Policy assignments at the management group level prevent non-compliant resources from being created in the first place.

Policy checks in CI before apply. Before any IaC change reaches production, validate it against your compliance rules. Open Policy Agent (OPA) is a widely adopted open-source engine for this purpose. Evaluate the JSON output of terraform plan with OPA through a tool such as Conftest, or use Pulumi CrossGuard policy packs with pulumi preview, and fail the pipeline on violations. In Kubernetes, OPA Gatekeeper or Kyverno applies the same rules at admission time.

Runtime detection. Even with preventive controls, configuration drift happens. Use runtime scanners to detect resources that have drifted from their compliant state and alert or auto-remediate.

Evidence collection for audits. Every policy evaluation, pass or fail, should produce a log entry. These logs become audit evidence showing that controls were in place and operating continuously.

Examples of rules to codify:

Allowed deployment regions (for example, only the regions inside the country your data must stay in)
Required encryption on all storage resources
Required classification tags on every resource
No public access on storage buckets or object stores
MFA required for privileged roles

What cloud solutions offer multi tenant protection against cross tenant data breaches?

Cloud platforms separate tenants at three layers: separate accounts or projects (AWS accounts, Google Cloud projects, Azure subscriptions), compute isolation (separate clusters or microVM sandboxes such as Kata Containers), and data isolation (separate databases and per-tenant encryption keys).

Tenant isolation models

Model	Layer	Isolation	What tenants still share
Separate accounts or projects	All layers	Highest	Only organization-level billing and policy
Separate clusters in one account	Compute	High	Cloud IAM, network, and account quotas
Separate namespaces in one cluster	Compute	Low to moderate	Kernel, nodes, and cluster control plane; relies on network policies, RBAC, quotas, and pod security
Separate database instances	Data	High	Network and admin credentials
Separate databases or schemas on one instance	Data	Moderate	Database engine, memory, and admin accounts
Row-level security on shared tables	Data	Lowest	Everything; one missing tenant context or a role that bypasses RLS exposes other tenants

Choose a compute model and a data model separately. A common pattern is separate accounts for the most sensitive tenants and shared clusters with separate databases for the rest.

How do I design AI infrastructure for cloud compliance using BYOK and tenant data segregation?

In this context, BYOK (bring your own key) means encrypting data with keys you control, generated or imported into a cloud key management service, instead of provider-managed keys. Tenant isolation and per-tenant encryption are the two pillars of preventing cross-tenant data exposure.

Per-tenant encryption keys

Store each tenant’s encryption key in a cloud KMS (such as AWS KMS, Google Cloud KMS, or Azure Key Vault). The application references the tenant’s key ID when encrypting or decrypting that tenant’s data. If one tenant’s key is compromised, only that tenant’s data is exposed. Disabling or deleting a tenant’s key makes their data unreadable, which supports offboarding and deletion requests, and KMS logs show every use of each tenant’s key. Scope the application’s decrypt permission per tenant, or one compromised service can still use every key.

Tenant separation in AI workloads

Vector stores and model caches introduce new cross-tenant risks. If multiple tenants share a vector database, queries from one tenant could surface embeddings from another. Mitigations include:

Namespace or collection-level separation within the vector store
Tenant-scoped query filters enforced at the application layer
Separate model inference endpoints per tenant for the most sensitive workloads
Scoping prompt caches and response caches to one tenant. Inference servers that reuse the KV cache for shared prompt prefixes, and semantic caches that return a stored answer for a similar prompt, can leak data or timing signals across tenants. Add the tenant ID to the cache key or disable cross-tenant cache sharing.

How Control Plane approaches regulated workloads

Control Plane is the unbreakable platform for production workloads. It combines any cloud, neocloud, bare metal, and your own servers into what Control Plane calls a Global Virtual Cloud (GVC), and teams run it in a single region, a single cloud, or across clouds. Control Plane handles Day 2 operations for you, including autoscaling, right-sizing, built-in observability, and security, with no Kubernetes cluster you have to operate.

Compliance posture. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant. These controls and the evidence they produce support your compliance, though they do not make you compliant on their own.

Data residency through location selection. A workload runs only in the locations of its GVC, which can include AWS, GCP, and Azure regions, Kubernetes clusters you already run, and servers in your own data center or from bare-metal and GPU providers. Control Plane Managed Kubernetes (MK8s) joins those servers into a cluster that Control Plane runs for you as a location. You can keep two or more locations inside one country, including combinations of providers, so the GVC’s location list acts as the region allow-list for that workload. Two in-country locations can also meet the 99.999% SLA condition below. Platform data is handled separately: org secrets are encrypted with envelope encryption and held in cloud HSMs across multiple providers, and logs are aggregated by Control Plane (30-day default retention) and can also be shipped to destinations you control, such as an Amazon S3 bucket or CloudWatch in your chosen region.

Active-active failover. A workload deployed to a GVC runs active-active in every location of that GVC, and a global endpoint routes each request to the nearest healthy location. The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. Those locations can be two regions of one cloud or locations on different providers. For strategies on surviving a single-region outage, see how to keep your app online during an AWS region outage.

Security defaults. Workloads are closed by default behind a deny-by-default internal firewall, and traffic between them uses mTLS, with each workload’s client certificate rotated every hour. All data is encrypted at rest and in transit. Each workload is isolated with cgroups, namespaces, and restricted syscalls and capabilities, and Control Plane Sandboxes, isolated environments for AI coding agents and untrusted code, run in dedicated Kata Containers microVMs.

Secrets and identity. Control Plane’s built-in secrets management lets workloads reference a secret as cpln://secret/NAME once their identity is granted the reveal permission, so secret values stay out of code and images. Control Plane’s Universal Cloud Identity gives workloads short-lived, least-privilege access to 600+ AWS, GCP, and Azure services, with no long-lived cloud keys in your code.

Audit trail. Every action, whether made through the console, CLI, Terraform, Pulumi, or AI agents using the Control Plane MCP server, is recorded in a tamper-proof audit trail. Your own workloads can write application events to the same audit trail through a custom audit context.

Policy and IaC. Control Plane policies are org-scoped and grant fine-grained permissions on every resource type to users, groups, service accounts, and workload identities. Control Plane ships its own Terraform and Pulumi providers, so it complements the infrastructure as code you already run.

Cost. Customers typically cut compute costs 30 to 50 percent compared with running directly on AWS, GCP, or Azure. SAFE Health, a connected-diagnostics platform working with Mayo Clinic, migrated 8 environments from AWS to Control Plane and cut its AWS spend 75 percent.

For teams looking to simplify multi-cloud operations or consolidate existing infrastructure, see how to consolidate multiple clouds into one platform. For a comparison of managed platform services versus building your own portability layer, see managed services vs. portability and cloud lock-in.

FAQ

Does a SOC 2 Type II report mean a platform is secure?

No. A SOC 2 Type II report shows that an independent auditor tested specific controls and found they operated effectively over a defined period. Read the report’s scope, exceptions, and complementary user entity controls to understand what the platform covers and what you must handle.

Is there an official HIPAA certification for cloud platforms?

No. The U.S. Department of Health and Human Services does not certify cloud platforms as HIPAA compliant. Look for a signed Business Associate Agreement and a published list of HIPAA-eligible services. The BAA sets the platform’s contractual obligations for safeguarding ePHI, and under HIPAA a business associate is also directly liable for certain requirements, including the Security Rule.

What is the difference between PCI DSS Level 1 and other levels?

Level 1 is the top tier for service providers. Visa and Mastercard assign it to service providers that handle more than 300,000 card transactions a year, and it requires an annual assessment by a Qualified Security Assessor, who issues a Report on Compliance (ROC) and an Attestation of Compliance (AoC). Level 2 service providers can self-assess with Self-Assessment Questionnaire D. Ask any provider for its responsibility matrix, which PCI DSS v4.0 requirement 12.9.2 obliges it to provide on request.

Can I achieve multi-region failover while keeping all data in one country?

Yes, if the country has two or more available cloud regions or data center locations. Run active-active or active-passive between them and pin all replicas, backups, logs, and encryption keys to those locations. If a single provider lacks two in-country regions, combine providers or add your own data center.

How do I prevent secrets from leaking in IaC pipelines?

Store secrets in a dedicated secrets manager and reference them by name in your IaC templates. Use short-lived credentials through workload identity federation, run secret-scanning tools in CI, encrypt your IaC state files, and restrict access to the state backend.

What is the shared responsibility model in cloud compliance?

The platform is responsible for infrastructure-level controls such as physical security, hypervisor patching, and network fabric. You are responsible for identity and access management, secrets, application code security, and data classification. Network segmentation, encryption, logging, backups, and incident response are shared.

How should I handle regulated data in AI inference pipelines?

Classify data before it reaches a model. Use self-hosted or in-region inference for regulated data. Log prompts and outputs with redaction of sensitive fields. Apply access control to model endpoints and vector stores. Document the full data flow for auditors.

Does Control Plane make my application compliant?

No. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant and provides audited controls and evidence that support your compliance, but your application still needs its own controls for data classification, identity, secrets, application security, and logging.

Can Control Plane keep my workload in a single cloud?

Yes. Many teams run Control Plane in a single cloud for its Day 2 operations and security defaults. A GVC can contain locations from a single provider, and two regions of one cloud qualify for the 99.999% SLA when a workload runs at least two replicas in those two locations.

How does Control Plane handle workload isolation?

Each workload is isolated with cgroups, namespaces, and restricted syscalls and capabilities, and Control Plane Sandboxes run in dedicated Kata Containers microVMs. Workloads are closed by default behind a deny-by-default internal firewall, and traffic between them uses mTLS.

See how Control Plane runs regulated workloads.

Talk to the Control Plane team or sign up free

Originally published on the Control Plane blog.

Managed Services vs Portability: When Cloud Lock-In Is Worth It and How to Stay Cloud-Agnostic

Noah Grinstein — Sat, 31 Oct 2026 04:36:00 +0000

Lock-in is worth accepting when a managed service saves more engineering time than it will cost to leave, and it is not worth it for the core compute runtime that every workload depends on. The runtime is the layer you should keep portable. Control Plane keeps the runtime portable across AWS, GCP, Azure, and your own servers, including on premises, while still letting workloads use each cloud’s managed services through Universal Cloud Identity, Control Plane’s credential-free access to AWS, GCP, and Azure services. This guide offers an honest framework for deciding when lock-in is a fair price, a service-by-service map of proprietary services to portable alternatives, and a practical exit plan you can act on today.

Disclosure: Control Plane publishes this guide.

TL;DR

Lock-in becomes a problem when it is accidental, unmeasured, or applied to the wrong layer.

When lock-in is worth it: A managed service materially reduces staffing, improves reliability, or accelerates delivery, and you have documented the exit cost.
When it is not: The service is your core compute runtime or your identity plane, where switching costs compound across every workload. Managed Kubernetes is fine when workload definitions stay in standard manifests.
The portable layer to protect: Application code, container images, deployment pipelines, data formats, and the runtime itself.
The exit plan: Maintain a service-dependency register, test data exports quarterly, keep infrastructure as code, and budget for egress.
How Control Plane fits: Control Plane runs workloads on AWS, GCP, Azure, your own Kubernetes clusters through Control Plane’s Bring Your Own Kubernetes (BYOK), and your own machines, from bare metal to on-premises servers, joined as locations with Control Plane Managed Kubernetes (MK8s), all mixed in one environment. Universal Cloud Identity lets those workloads call AWS, GCP, and Azure managed services without long-lived cloud keys in your code. You get managed-service benefits without surrendering runtime portability.

For a deeper look at the full lock-in landscape, see our companion piece on how to avoid cloud vendor lock-in.

When Do Managed Platform Services Increase Vendor Lock-In?

Managed services create lock-in in five ways, and they differ in how hard they are to undo.

Proprietary APIs

When your application code calls a vendor-specific API, every call is a line of migration debt. The more deeply integrated the API, the more refactoring a move requires. This is the most visible form of lock-in and the one engineers think of first.

Data Gravity and Egress Costs

Large datasets are expensive to move. Cloud providers charge for data leaving their network, and the sheer time to transfer terabytes or petabytes creates inertia. Transfer time and egress fees grow with data volume, so the cost of leaving rises the longer you stay.

Proprietary Identity and Permissions

IAM systems differ significantly between AWS, GCP, and Azure. Policies, roles, and service accounts written for one cloud do not translate to another. Migrating identity is tedious, error-prone, and security-sensitive.

Proprietary Serverless Runtimes

Functions tied to a specific serverless platform carry implicit dependencies on the platform’s event model, scaling behavior, timeout limits, and deployment tooling. These are difficult to replicate elsewhere.

Contract Terms

Committed-use discounts, enterprise agreements, and reserved capacity create financial lock-in. Breaking a contract early can mean forfeiting discounts or paying penalties.

Data gravity and proprietary identity are the hardest to undo. Moving data is a large but bounded transfer project, while identity must be redesigned and re-audited for every workload. Proprietary APIs come next, then serverless runtimes, then contract terms, which have a defined end date.

Decision Framework: When Is the Managed Option Worth It?

Use this table to evaluate each service category.

Service Category	Lock-In Level	Switching Cost Drivers	When the Managed Option Is Worth It
Compute runtime	High	Every workload depends on it; migration touches everything	Rarely worth locking in. Keep this portable.
Kubernetes	Medium	Storage classes, load balancer and ingress annotations, CNI plugins, and the link between pods and cloud IAM (EKS Pod Identity, Workload Identity Federation for GKE, Microsoft Entra Workload ID) are cloud-specific	Use managed Kubernetes for convenience, but keep workload definitions portable via standard manifests.
Relational databases	Medium	Schema compatibility is high (PostgreSQL, MySQL), but managed features (replication, backups) differ	Worth it when the managed service handles HA, patching, and backups you would otherwise staff for.
NoSQL databases	High	Proprietary query languages, data models, and SDKs (DynamoDB, Cosmos DB)	Worth it for rapid prototyping or when throughput requirements match the service exactly. Document the exit path.
Object storage	Low (API), Medium (large datasets)	S3-compatible APIs are a de facto standard, though Azure Blob Storage uses its own API. Egress fees and transfer time scale with data volume. Lifecycle rules, storage classes, and event notifications differ by provider.	Almost always worth it. For large buckets, budget for egress and keep an export or replication path.
Queues and streaming	Medium	Client SDKs, delivery semantics, ordering, and retention differ across SQS, Pub/Sub, Event Hubs, and Kinesis	Worth it for most workloads. Wrap producers and consumers behind an interface, or use a Kafka- or AMQP-compatible managed service so client code stays portable.
Serverless functions	High	Event sources, cold-start behavior, and runtime constraints are proprietary	Worth it for event-driven glue code, spiky traffic, and low-traffic endpoints. For core business logic, keep handlers thin and put the logic in plain libraries that can also run in a container.
Identity	High	Policies, roles, and trust relationships are cloud-specific	Abstract identity where possible. Use workload identity federation over long-lived keys.
Observability	Medium	Proprietary query languages and dashboards; data export is usually feasible	Worth it when the team is small. Adopt OpenTelemetry for instrumentation to keep the data portable.
Managed AI / model APIs	Medium-High	Model-specific prompt tuning, fine-tuning artifacts, and pricing models	Worth it for speed to market. Use an abstraction layer for model calls.

Which Open-Source Alternatives to Managed Databases Best Support Portability?

When a managed service’s lock-in level is too high for your risk tolerance, open-source alternatives can restore portability. The table below maps common managed services to their portable counterparts.

Managed Service	Portable Alternative	Notes
Amazon RDS for PostgreSQL, Cloud SQL for PostgreSQL, Azure Database for PostgreSQL	PostgreSQL	Schema-level compatibility is strong. Run it on any cloud or on premises.
Amazon RDS for MySQL, Cloud SQL for MySQL	MySQL or MariaDB	Widely supported. MariaDB began as a MySQL fork and is compatible with many MySQL workloads, though the two have diverged in newer versions.
DynamoDB, Cosmos DB	ScyllaDB or Apache Cassandra	Both are wide-column databases. Apache Cassandra is open source. ScyllaDB is source-available since 2025 and offers Alternator, a DynamoDB-compatible API. Cosmos DB also offers a Cassandra-compatible API, which eases moves in either direction.
Amazon SQS, Google Pub/Sub	Apache Kafka, NATS, or RabbitMQ	Kafka excels at high-throughput streaming and is the closer match for Pub/Sub. RabbitMQ is mature for task queues and is the closer match for SQS. NATS is lightweight and supports both patterns.
AWS Lambda, Cloud Functions, Azure Functions	Standard containers	Package functions as containers to decouple from the serverless runtime. Any container platform can run them.
Amazon ElastiCache	Redis or Valkey	Redis is widely deployed and, from Redis 8, is available under AGPLv3 as well as source-available licenses. Valkey is a BSD-licensed Linux Foundation fork of Redis 7.2.4. ElastiCache supports both engines, so the move is usually low-friction.

The right choice depends on your team’s operational capacity and workload requirements, not on a blanket recommendation.

When Is It Worth Accepting Platform Lock-In for Managed AI Services?

AI services are the newest and fastest-moving category of managed cloud offerings. The lock-in calculus here is different because the field changes so quickly that today’s best model may not be tomorrow’s.

Evaluate Five Factors

Speed to market. Managed AI APIs remove the work of hosting, scaling, and updating models, so you can ship a first version without building GPU infrastructure. If time-to-market is critical, the lock-in trade-off is often favorable.
Model quality. Some proprietary models outperform open alternatives on specific tasks. Benchmark on your data before committing.
Data sensitivity. Sending data to a third-party model API may conflict with compliance requirements. On-premises or private inference may be necessary.
Cost at scale. API pricing that looks cheap at prototype volume can become prohibitive at production scale. Model the cost curve before you commit.
Ability to swap models behind an abstraction. If your application calls models through a thin abstraction layer, switching providers is mostly a configuration change. You still need to re-test prompts and tool calls, re-run evaluations, and re-embed stored vectors if the embedding model changes.

Use managed AI APIs for experimentation and initial deployment, and build an abstraction layer for model calls from day one. For production inference at scale, portable containers running on GPU infrastructure give you the flexibility to move between clouds or neoclouds as pricing and performance shift. On Control Plane, workloads can attach NVIDIA GPUs, and MK8s lets you join GPU servers from other providers as locations. See our guide on running AI inference across multiple GPU clouds.

What Multi-Cloud Infrastructure Patterns Reduce Dependence on Proprietary Managed Services?

Six engineering patterns reduce dependence on proprietary managed services when applied across the stack.

Containerize the Runtime

Package every workload as a standard container image that follows the OCI image spec. An image packages application code and dependencies so any runtime that supports the OCI image spec can run it. Portability still has limits. Build multi-architecture images if you may run on both x86 and Arm nodes, keep configuration in environment variables or secrets rather than the image, and treat kernel features and GPU drivers as host dependencies.

Infrastructure as Code

Define all infrastructure in code with tools such as Terraform, OpenTofu, or Pulumi. Infrastructure as code makes environments reproducible and auditable. On Control Plane, the CLI, console, and Control Plane’s own Terraform and Pulumi providers all work through the same Control Plane API, so your definitions stay consistent.

Open Protocols and Formats

Prefer open standards: OpenTelemetry for observability, S3-compatible APIs for object storage, SQL for relational data, AMQP or NATS for messaging. Open protocols reduce the surface area of proprietary dependency.

Isolate Provider-Specific Code Behind Interfaces

When you do use a managed service, wrap it behind a well-defined interface in your application code. A storage interface, a queue interface, or a model-call interface means you can swap implementations without touching business logic.

Scheduled Data Replication

For critical datasets, replicate data to a second cloud or to your own infrastructure on a schedule. This keeps a current copy outside the primary provider for migration or disaster recovery. Replication adds ongoing egress and storage costs, so limit it to data you cannot rebuild.

Workload Identity Instead of Long-Lived Keys

Long-lived API keys and service account credentials are both a security risk and a portability obstacle. Use workload identity federation to grant short-lived credentials scoped to the current task. On Control Plane, Universal Cloud Identity does this for AWS, GCP, and Azure services.

For a broader look at cloud-native design principles that support portability, see our guide on cloud-native architecture principles, patterns, and building portable systems.

Should I Choose PaaS or SaaS for Vendor Lock-In and Portability?

Choose a PaaS when portability matters. A PaaS runs your application, so you keep the code, images, and data. A SaaS product replaces the application, so only your data can move.

The platform provides the runtime, networking, and operational tooling. If the PaaS uses standard container images and open APIs, your application is portable even if the platform itself is not.

With SaaS, the contract usually says you own your data, but the export format and completeness depend on the vendor. You do not control the application logic, the runtime, or the operational model. Portability depends entirely on the vendor’s data export capabilities and API compatibility. Switching SaaS providers often means rebuilding workflows from scratch.

A PaaS keeps these advantages only if it runs standard containers and does not impose a proprietary build or deployment format. For a detailed comparison of PaaS options, see our guide to the best PaaS providers in 2026.

What Contract Clauses Should I Require for Data Portability and Service Exit?

Before signing a cloud or managed-service agreement, negotiate terms that protect your ability to leave. The following checklist covers the essentials.

This is general guidance, not legal advice. Consult qualified counsel for your specific situation.

Data export format and timeline. The provider must export your data in a standard, documented format within a defined number of days after termination.
Exit assistance. The contract should include a transition period during which the provider supports migration activities.
Egress fee terms. Cap or waive egress fees during the transition period. At minimum, get clarity on per-GB costs.
Notice periods. Ensure notice periods for termination are reasonable and symmetric. You should not need 12 months’ notice to leave.
Termination for convenience. You should be able to terminate without cause, subject to reasonable notice and payment for services consumed.
Price change caps. Limit annual price increases to a defined percentage, or require advance notice that gives you time to evaluate alternatives.
Data deletion certification. After migration, the provider must certify in writing that your data has been deleted from their systems, including backups, within a specified timeframe.

Maintain a service-dependency register that tracks each provider-specific component, its owner, data location, export procedure, portable alternative, and estimated exit cost. Review it quarterly.

How Control Plane Approaches Portability

Control Plane is the platform for running unbreakable apps and agents. It combines any cloud, neocloud, and bare metal into what Control Plane calls a Global Virtual Cloud (GVC), a set of locations a workload runs across.

On Control Plane, a workload deployed to a GVC runs active-active in every location of that GVC, and a global endpoint routes each request to the nearest healthy location, so you get failover without paying for idle standby capacity. The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations, and those locations can be on different providers.

During the October 2025 AWS us-east-1 outage, which lasted about 15 hours, Control Plane customers with us-east-1 in their GVC had no downtime, and their workloads were “active and running in healthy locations within 10 seconds,” according to Control Plane internal incident telemetry. See designing systems that survive the inevitable.

Control Plane runs serverless, standard, stateful, cron, and VM workloads on AWS, GCP, and Azure, on clusters you already run through Control Plane’s Bring Your Own Kubernetes (BYOK), on your own machines (bare metal or VMs) turned into managed locations with Control Plane Managed Kubernetes (MK8s), and on premises. On Control Plane-provided compute, there is no Kubernetes cluster you have to operate, and Control Plane handles Day 2 operations for you, including autoscaling, Capacity AI (Control Plane’s right-sizing of CPU and memory based on historical usage), built-in observability, and security. You pay for the CPU and memory you reserve, by the millicore and the megabyte, with no contracts or minimums. Egress, storage, observability, dedicated load balancers, and GPUs are billed separately.

On Control Plane, the template catalog deploys open-source data services such as PostgreSQL, MySQL, MariaDB, Cassandra, Kafka, NATS, RabbitMQ, and Redis or Valkey into a GVC, so the portable alternatives above run on the same platform as your workloads.

Control Plane’s Universal Cloud Identity gives workloads short-lived, least-privilege access to 600+ AWS, GCP, and Azure services, with no long-lived cloud keys in your code. The Control Plane MCP server uses the same API as the CLI, console, and Terraform and Pulumi providers, so Control Plane complements the infrastructure as code you already run.

Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant.

Customers typically cut compute costs 30 to 50 percent compared with running directly on AWS, GCP, or Azure.

You use each cloud’s managed services where they earn their place, and your runtime stays free to move. For a walkthrough of deploying the same application across AWS, GCP, and Azure, see how to run the same app on AWS, GCP, and Azure.

FAQ

When do managed platform services increase vendor lock-in?

Managed services increase lock-in when they expose proprietary APIs, store large volumes of data subject to egress fees, impose proprietary identity models, or use non-standard event systems. The more deeply your application integrates with these surfaces, the higher the switching cost.

Which open-source alternatives to managed databases best support portability?

PostgreSQL, MySQL, MariaDB, Apache Cassandra, Redis, and Valkey are widely adopted portable alternatives. ScyllaDB is a source-available option with a DynamoDB-compatible API. For queues and streaming, Apache Kafka, NATS, and RabbitMQ replace proprietary offerings.

When is it worth accepting platform lock-in for managed AI services?

It is worth it when speed to market is critical and you build an abstraction layer over model calls from day one. Avoid deep lock-in for production inference at scale; portable containers on GPU infrastructure give you pricing and performance flexibility.

What multi-cloud infrastructure patterns reduce dependence on proprietary managed services?

Containerize workloads, define infrastructure as code, use open protocols (OpenTelemetry, S3-compatible APIs, SQL), isolate provider-specific code behind interfaces, replicate critical data on a schedule, and use workload identity instead of long-lived keys.

Should I choose PaaS or SaaS for vendor lock-in and portability?

Choose PaaS when portability is a priority, because you keep control of your application code, container images, and data. SaaS portability depends almost entirely on the vendor’s data export capabilities.

What contract clauses should I require for data portability and service exit?

Require data export in standard formats within a defined timeline, exit assistance during a transition period, capped or waived egress fees, reasonable notice periods, termination for convenience, price change caps, and written data deletion certification.

How does Control Plane keep the runtime portable while using managed services?

On Control Plane, workloads (containers or VMs) run on a Global Virtual Cloud (GVC), Control Plane’s set of locations that can span AWS, GCP, Azure, Kubernetes clusters you bring through Control Plane’s Bring Your Own Kubernetes (BYOK), and your own servers on premises. Control Plane’s Universal Cloud Identity lets those workloads use AWS, GCP, and Azure managed services without long-lived cloud keys in your code.

Is multi-cloud the same as cloud-agnostic?

No. Multi-cloud means using more than one cloud provider. Cloud-agnostic means your workloads can move between providers with minimal effort. You can be multi-cloud and still deeply locked in to each provider’s proprietary services. True cloud-agnostic architecture requires portable runtimes, open standards, and abstraction layers.

Does containerization solve cloud portability?

Only partly. Containers make application code and dependencies portable, as long as images are built for the CPU architectures you target. They do not solve portability for databases, storage, identity, networking, or observability, which often remain cloud-specific. You need additional patterns, such as open protocols and interface abstraction, to address those layers.

How often should I test my cloud exit plan?

Test your cloud exit plan on a fixed schedule set by how critical the system is, such as quarterly for revenue-critical workloads, and after any major architecture change. Each test should export real data and deploy a representative workload on an alternative cloud.

Talk to the Control Plane team or sign up free to try it.

Originally published on the Control Plane blog.

How to Consolidate Multiple Clouds and Accounts Into One Platform: An Enterprise Guide for 2026

Noah Grinstein — Sat, 31 Oct 2026 02:09:38 +0000

Consolidating clouds means putting every account and provider under one deployment model, one identity and policy layer, and one view of cost and health, while workloads can keep running where they are. The fastest route is a platform layer over the existing clouds rather than a mass migration to one provider. Control Plane puts AWS, GCP, Azure, and your own servers under one API, one policy model, and one billing account whose Cost & Usage view covers every org.

Disclosure: Control Plane publishes this guide.

TL;DR

Cloud consolidation means bringing every cloud account, provider, and workload under a single operational model for identity, policy, deployment, and cost visibility. It does not require moving every workload to one provider.

The program: Inventory everything, classify workloads, set a policy baseline, deploy in waves starting with stateless services, retire duplicates, measure.
How to measure ROI: Sum the savings from retired tools, reduced idle capacity, fewer undifferentiated engineering hours, and lower incident cost. Subtract one-time costs (migration, training, parallel running) and recurring platform fees over a fixed horizon, and report the payback period.
The merger case: Inventory and federate identity in the first 30 days, apply shared policies and observability and move the first stateless workloads by Day 90, then migrate stateful services and fold in contracts as they renew.
How Control Plane fits: A Control Plane org holds workloads, policies, secrets, and identities across AWS, GCP, Azure, your own clusters, and your own servers. Control Plane’s Bring Your Own Kubernetes (BYOK) adds clusters you already run, and Control Plane’s Managed Kubernetes (MK8s) turns bare metal or VMs into managed locations. Control Plane’s Global Virtual Cloud (GVC) is the set of locations a workload runs across. Enterprises can run several orgs, for example one per environment or business unit, under one billing account. Customers typically cut compute costs 30 to 50 percent compared with running directly on AWS, GCP, or Azure.

Why do enterprises end up with cloud sprawl?

Cloud sprawl builds up through acquisitions, team autonomy, and regional expansion. Acquisitions bring new AWS accounts and Azure subscriptions overnight. Business units spin up their own projects in GCP because the central team’s ticket queue is too slow. Shadow IT flourishes when developers need a sandbox faster than procurement can provide one. Region-by-region expansion adds accounts in new geographies to meet data residency rules. Different teams also pick different tools: one group standardizes on one provider’s managed database, another on a competing provider’s ML platform.

Sprawl creates five recurring costs.

Duplicated tooling and contracts. Multiple monitoring agents, multiple secret managers, multiple container registries, each with its own license and support agreement.
Inconsistent security policy. What counts as “least privilege” in one account may not exist in another. Firewall rules drift.
Fragmented identity. Engineers juggle separate credentials for each cloud. Service accounts accumulate long-lived keys that nobody rotates.
Idle and overlapping capacity. Dev environments left running, reserved instances bought by one team that another team duplicates in a different provider.
No single view of spend or health. Finance cannot answer “how much do we spend on compute?” without pulling reports from three consoles and a spreadsheet.

Each of these problems is manageable in isolation. Together, they create an environment where security incidents take longer to investigate, cost overruns go undetected for months, and platform teams spend their time on undifferentiated operations instead of building product.

What does consolidating clouds actually mean?

There are three common models.

Model A: Migrate to one cloud	Model B: Govern each cloud separately	Model C: Platform layer across clouds
What changes	All workloads move to a single provider	Each cloud is managed with its own native tools
Migration effort	High	Low (no workload moves; per-cloud tooling setup remains)
Lock-in	High (single provider)	Moderate per provider (each workload still uses native tools; operational complexity stays)
Governance consistency	High within one provider	Low across providers
Best for	Small estates with few provider-specific dependencies	Organizations with strong per-cloud teams and low cross-cloud interaction

Model A can be the right call for a small estate with workloads that have no deep provider-specific dependencies. Model B is the status quo for many large enterprises, and it works until the sprawl costs exceed the governance budget. Model C fits organizations that need consistent identity, policy, and cost control without a mass migration. On Control Plane, clusters you already run and your own servers join the same environment as cloud regions, so consolidation does not start with a mass migration. Workloads on Control Plane are standard containers and VM images, and Control Plane ships its own Terraform and Pulumi providers, so your definitions stay portable.

How can large enterprises consolidate multiple cloud accounts and providers into a single unified platform?

This seven-step program works with an in-house platform or a commercial one.

Inventory accounts, workloads, owners, and spend. List every cloud account and subscription. Map each workload to an owner, a cost center, and a classification (production, staging, dev, sandbox). Record monthly spend per account.
Classify workloads: keep, move, retire. Some workloads belong where they are (tightly coupled to a provider service, subject to data residency rules). Some should move (running in an expensive region for no reason, duplicated across providers). Some should be retired (orphaned environments, abandoned projects).
Define one identity and policy baseline. Decide on a single identity provider for human access (federated through your existing directory). Define a minimum policy set: tagging requirements, network segmentation rules, encryption standards, and least-privilege access patterns. Write these as code.
Pick the deployment model. Choose from the three models above. For most large enterprises, this means selecting a platform layer and integrating it with existing infrastructure-as-code pipelines.
Move workloads in waves, starting with stateless services. Stateless web services and APIs are the lowest-risk workloads to consolidate first. They can run active-active in old and new locations during the transition. Stateful services (databases, queues, caches) come later, with careful data migration planning.
Retire duplicate tools and contracts. As workloads consolidate, decommission redundant monitoring agents, secret managers, container registries, and CI/CD systems. Renegotiate or cancel contracts as they come up for renewal.
Measure. Record a baseline during step 1, then track accounts retired, policy compliance rate, spend reduction, deployment frequency, lead time for changes, and mean time to recovery. Report monthly to the executive sponsor.

What is the best way to standardize deployment and governance across dozens of cloud accounts?

Standardize on eight controls that apply to every account.

Account structure. Organize accounts using each provider’s native hierarchy: AWS Organizations for grouping AWS accounts under organizational units, Azure management groups for nesting subscriptions under a management hierarchy, and Google Cloud resource hierarchy for organizing projects under folders and an organization node. These structures let you apply policies at the right scope.
Policy as code. Express security and compliance rules as code using engines like Open Policy Agent. Evaluate policies in CI before deployment, and enforce them again at the provider level (AWS service control policies, Azure Policy, Google Cloud organization policies) to catch changes made outside the pipeline.
Infrastructure as code. Use Terraform, OpenTofu, or Pulumi to define all infrastructure. No manual changes in consoles.
One CI/CD path. Every workload deploys through the same pipeline, regardless of target cloud. This reduces “works on my cloud” problems and makes every deployment auditable.
Workload identity instead of long-lived keys. Replace static API keys and service account JSON files with short-lived, scoped credentials issued at runtime. Each major cloud supports this natively, for example IAM roles for EC2 and EKS Pod Identity on AWS, managed identities and Microsoft Entra Workload ID on Azure, and service account attachment and Workload Identity Federation on Google Cloud.
Tagging and cost allocation. Enforce a mandatory tag set (owner, cost center, environment, service) at deployment time. Reject resources that lack required tags.
Central audit log. Aggregate AWS CloudTrail, Azure Activity Log, and Google Cloud Audit Logs into a single, immutable store. Set retention policies that meet your regulatory requirements.
Golden paths and templates. Publish a standard set of approved architectures (a web service, a background worker, a scheduled job, a database) as reusable modules. Teams pick from the catalog instead of building from scratch.

What is the ROI of consolidating disparate cloud environments into one virtual cloud platform?

ROI varies by estate. The model below gives you a framework to estimate it from your own inventory. Do not plug in industry averages; use your actual numbers.

Formula:

Pick a fixed horizon, such as three years, so one-time costs are spread over the period that benefits from them.

ROI over the horizon (%) = (total savings – one-time costs – recurring costs) / (one-time costs + recurring costs) × 100. Report it together with the payback period.

Payback period = the first month in which cumulative savings minus cumulative recurring costs exceed one-time costs. At steady state this is one-time costs / (monthly savings – monthly recurring costs).

Savings lines:

Line item	How to estimate from your inventory
Retired tools and licenses	Sum annual cost of monitoring, security, CI/CD, and secret management tools that will be replaced or consolidated
Reduced idle and overlapping capacity	Identify dev/staging environments running 24/7, duplicate reserved instances across providers, and unused accounts. Sum their monthly cost and multiply by 12.
Rightsized compute	Compare current resource reservations to actual utilization (pull from provider cost explorers). The gap is the savings opportunity.
Fewer engineer hours on undifferentiated operations	Estimate hours per month spent on account provisioning, credential rotation, patching, and incident triage across clouds. Multiply the hours you expect to remove by fully loaded hourly cost, then by 12.
Lower incident cost	Estimate average cost per incident (engineer hours, customer impact, SLA credits). Multiply by the number of incidents per year you expect to avoid through consistent policy and faster detection.

Cost lines:

Line item	Type	How to estimate
Migration effort	One-time	Engineer hours to onboard workloads, rewrite provider-specific integrations, and validate in the new model
Platform fees	Recurring	Annual cost of the platform layer or tooling you adopt
Training	One-time, plus a smaller recurring amount for new hires	Cost of upskilling teams on the new model and tools
Parallel running during transition	One-time	Cost of running workloads in both old and new locations until cutover is complete
Contract exit and data transfer	One-time	Early-termination fees on contracts you exit before renewal, and egress charges for moving data between providers

Savings ramp up as waves complete, so model them by quarter rather than assuming the full figure from month one. Count each dollar once: capacity you shut down as idle cannot also count as rightsizing.

How do large organizations reduce redundant cloud spend from overlapping AWS and Azure subscriptions?

Redundant spend usually sits in five places.

Find duplicate services across clouds. Two monitoring platforms, two container registries, two managed Kubernetes clusters doing the same job in different providers. Pick one or consolidate to a platform that covers both.
Rationalize commitments and reservations before they renew. Review AWS Savings Plans and Reserved Instances, Azure reservations and savings plans, and Google Cloud committed use discounts. Most cannot be cancelled mid-term, so decide before each purchase or renewal whether to renew, resize, or let the commitment lapse. Coordinate across business units so one team’s commitment does not duplicate another’s.
Retire idle accounts. Sandbox accounts, former employee projects, and abandoned proof-of-concept environments accumulate cost. Inventory them, archive what is needed, and shut down the rest.
Rightsize. Use each provider’s cost tools (AWS Cost Explorer, Microsoft Cost Management, Google Cloud Billing Reports) to find over-provisioned instances. Downsize or switch to burstable types.
Consolidate observability and security tools. Running three APM agents, three log shippers, and three vulnerability scanners for the same workloads adds cost without adding coverage.

For a deeper walkthrough, see the cloud cost optimization guide.

How do I consolidate cloud infrastructure after a merger or acquisition with minimal downtime?

Integrate the acquired estate, with its own accounts, identity providers, tools, and contracts, in three phases, moving stateless workloads active-active so traffic shifts gradually.

Day 0 to 30: Discover and stabilize

Inventory the acquired company’s cloud accounts, workloads, identity providers, and spend. Use the same inventory template as your existing estate.
Connect identity. Day 0 is legal close, so prepare federation before close and switch it on after a security review of the acquired identity provider (MFA, conditional access, admin accounts). Federate the acquired directory into your identity provider for single sign-on, then map each user’s cloud roles so you can see who has access to what. Merge directories later.
Freeze new sprawl. Require all new workloads in the acquired estate to go through your provisioning process. No new shadow accounts.

Day 30 to 90: Align policy and observability

Apply your minimum policy baseline (tagging, encryption, network segmentation) to the acquired accounts. Use policy-as-code tools to enforce, not just audit.
Ship the acquired company’s logs and metrics to your central observability stack. This gives you one place to detect incidents across both estates.
Move the first stateless workloads. Pick low-risk APIs or web services. Run them active-active in both the old and new locations during the transition. This works only if the data each service reads is reachable from both locations. Traffic then shifts gradually and can shift back if something breaks.

Day 90 and beyond: Consolidate data and contracts

Migrate stateful services (databases, queues, object stores) with careful data validation. Use replication tools such as AWS Database Migration Service, Azure Database Migration Service, or Google Cloud Database Migration Service to keep source and target in sync until a short final cutover.
Consolidate contracts. As the acquired company’s reserved instances and enterprise agreements come up for renewal, fold them into your master agreements or let them expire.
Decommission the acquired company’s redundant tooling: CI/CD, monitoring, secret management, container registries.

Stateful services still need a planned cutover or replication window, and DNS-based shifts are limited by record TTLs and client caching.

On Control Plane, you can add the acquired company’s existing Kubernetes clusters as locations through BYOK. Once a workload is deployed through Control Plane to a GVC that includes those clusters and your cloud regions, it runs active-active across all of them, and the global endpoint sends each request to the nearest healthy location. Workloads still running outside Control Plane do not gain active-active until they are deployed this way.

Which tools support consolidating shadow IT cloud accounts?

What tools help reduce cloud vendor sprawl across business units?

Tools for cloud consolidation fall into six categories. Each solves a different piece of the problem.

Category	What it solves	Examples
Discovery	Finding shadow accounts and unsanctioned cloud services	Billing and payment-card records, SSO sign-in logs, Microsoft Defender for Cloud Apps cloud discovery
Cloud-native governance services	Account structure, policy guardrails, and compliance within a single provider	AWS Organizations, Azure Policy, Google Cloud Organization Policy
Infrastructure as code	Reproducible, auditable provisioning across providers	Terraform, OpenTofu, Pulumi
Policy engines	Cross-cloud policy evaluation and enforcement	Open Policy Agent
FinOps and cost tools	Cost visibility, allocation, and optimization. Native tools cover one provider each; a cross-cloud view needs a common billing export such as the FinOps Foundation’s FOCUS specification, which AWS, Azure, and Google Cloud support	AWS Cost Explorer, Microsoft Cost Management, Google Cloud Billing Reports
Platform layers	Unified deployment, identity, policy, and observability across all clouds	Control Plane; see the multi-cloud management platforms roundup for a vendor comparison

Infrastructure as code and policy engines work across providers but require a team to build and maintain the glue. FinOps tools give you visibility but do not deploy or govern workloads. Platform layers cover deployment, identity, policy, observability, and cost for the workloads that run on them.

Which vendors specialize in enterprise cloud consolidation for regulated industries like finance and healthcare?

Shortlist vendors that can show current compliance evidence scoped to where your workloads run, then test them against the five criteria below.

Evaluation criteria for regulated buyers:

Compliance attestations. Request current SOC 2 Type II reports, PCI DSS attestations of compliance, and HIPAA business associate agreements. Ask for the scope of each attestation: does it cover the vendor’s management layer, the infrastructure where your workloads run, or both?
Data residency controls. Can you restrict workloads and data to specific regions or jurisdictions? Is this enforced by policy, or just documented?
Audit trails. Does the platform produce a tamper-evident log of every change to configuration, policy, and access? Can you export it to your own SIEM?
Identity and least privilege. Does the platform support workload identity with short-lived credentials? Can you enforce least-privilege access to cloud provider services without embedding long-lived keys?
Exit terms. What happens if you leave the platform? Can you export your workload definitions, policies, and configuration? Are there data portability guarantees in the contract?

Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant. On Control Plane, every action, whether made through the console, CLI, Terraform, Pulumi, or AI agents using the Control Plane MCP server, is recorded in a tamper-proof audit trail. A workload runs only in the locations of its GVC, so you control residency by choosing locations. Workloads are closed by default behind a deny-by-default internal firewall, and traffic between them uses mTLS.

Which enterprise platforms unify identity, billing, and deployment across multiple clouds?

How can I get a single pane of glass view across all our cloud providers and regions?

On Control Plane, an org is an isolated boundary that holds workloads, secrets, policies, and identities. Enterprises can run several orgs, for example to separate environments or business units, and pay for all of them from one billing account. The CLI, console, Terraform and Pulumi providers, and the Control Plane MCP server all work through the same Control Plane API.

Day 2 operations. Control Plane handles Day 2 operations for you, including autoscaling, Capacity AI right-sizing (Control Plane’s automatic right-sizing of CPU and memory reservations between a minimum and maximum you set, based on historical usage), built-in observability, and security, with no Kubernetes cluster you have to operate.

Deployment. A GVC can mix AWS, GCP, and Azure regions, clusters you already run (added through BYOK), and your own servers (added through MK8s). A workload deployed to a GVC runs active-active in every location of that GVC, and a global endpoint routes each request to the nearest healthy location. You get failover without paying for idle standby capacity. The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. For more detail, see how to run the same app on AWS, GCP, and Azure.

Identity. Control Plane’s Universal Cloud Identity gives workloads short-lived, least-privilege access to 600+ AWS, GCP, and Azure services, with no long-lived cloud keys in your code. Access policies are defined once per org and govern every resource in it, in every location.

Observability. Built-in metrics, logs, and traces cover every location in one place, with no third-party agent to install. Logs can also be forwarded to the logging stack you already run.

Cost visibility. A Cost & Usage view adds together every org on the billing account and breaks spend down per org and per resource, with a projected total. A billing_viewer role lets finance teams see costs without accessing workload configuration. A monthly spend alert, once you set an amount, emails every billing admin.

SAFE Health, a connected-diagnostics platform working with Mayo Clinic, migrated 8 environments from AWS to Control Plane and cut its AWS spend 75 percent. In their words: “We migrated 8 environments from AWS to Control Plane and no one noticed! Everything just worked.”

During the October 20, 2025 AWS us-east-1 outage, which lasted about 15 hours and affected 100+ AWS services, the 20 percent of Control Plane customers with us-east-1 in their GVC had no downtime, and their workloads were “active and running in healthy locations within 10 seconds,” according to Control Plane internal incident telemetry. A detailed write-up is available in the post on designing systems that survive the inevitable.

On Control Plane-provided compute, you pay for the CPU and memory you reserve, by the millicore and the megabyte, with no contracts or minimums. Egress, storage, observability, dedicated load balancers, and GPUs are billed separately. Control Plane is just as useful on a single region or a single cloud, where teams adopt it for the Day 2 operations alone.

For a broader look at hybrid and multi-cloud management approaches, see the hybrid cloud management guide.

FAQ

What does cloud consolidation mean?

Cloud consolidation means bringing every cloud account, provider, and workload under one identity layer, one policy framework, one deployment model, and one view of cost and health. It does not require migrating everything to a single cloud provider.

How do I consolidate multiple cloud providers without migrating everything?

Use a platform layer that sits above your existing clouds. Onboard accounts and workloads incrementally. Start with governance and visibility, then move workloads in waves if needed. On Control Plane, you add existing clusters through BYOK and your own servers through MK8s as locations, then deploy your containerized applications to them without re-architecting. See the guide on moving off a single cloud provider without re-architecting your apps.

How long does cloud consolidation take for a large enterprise?

For a large enterprise it is a multi-quarter program, paced mostly by data migrations and contract renewal dates. Governance and cost visibility come first and can land within the first 90 days. Stateless workloads follow in waves. Stateful services and contracts take longest, because data needs validation and contracts end on their own renewal dates.

What is the biggest risk of cloud consolidation?

Two risks dominate: downtime during a hard cutover, and concentrating every workload on one region or provider. Avoid both by running workloads active-active across multiple locations and providers, so traffic moves gradually during the transition and an outage in one location does not take down your services. Also confirm the platform’s exit terms, so you can export workload definitions and configuration.

How do I handle cloud consolidation after an acquisition?

Inventory the acquired estate and federate identity in the first 30 days, apply shared policies and observability and move the first stateless workloads by Day 90, then migrate stateful services and fold in contracts as they renew. Run stateless workloads active-active in old and new locations so traffic shifts gradually instead of in one cutover.

Can I consolidate clouds without a dedicated platform team?

Yes. A platform layer that handles Day 2 operations (autoscaling, right-sizing, observability, security) reduces the need for a large platform team. See the guide on production-grade infrastructure without a platform team.

How do I measure the ROI of cloud consolidation?

Sum savings from retired tools, reduced idle capacity, rightsized compute, fewer engineering hours on operations, and lower incident cost. Subtract one-time costs (migration, training, parallel running, contract exit) and recurring platform fees over a fixed horizon such as three years, and report the payback period. Use your own numbers from the inventory, not industry averages.

What compliance certifications should I require from a cloud consolidation platform?

At minimum, request current SOC 2 Type II reports, PCI DSS attestations of compliance, and HIPAA business associate agreements if you handle protected health information. Verify the scope covers both the vendor’s management layer and the infrastructure where your workloads run.

How does Control Plane handle billing across multiple clouds?

Control Plane puts every org on one billing account, and its Cost & Usage view shows spend per org and per resource with a projected total. A billing_viewer role gives finance teams read-only access to cost data. On Control Plane-provided compute, you pay for the CPU and memory you reserve, by the millicore and the megabyte, with no contracts or minimums. In locations you add through BYOK or MK8s, workloads run on nodes you supply, so your provider bills you for those nodes.

Does consolidating clouds mean I am locked into a new vendor?

Not necessarily. Evaluate exit terms before adopting any platform. Look for the ability to export workload definitions, policies, and configuration. Use infrastructure as code to keep your deployments portable.

Talk to the Control Plane team or sign up free to try it.

Originally published on the Control Plane blog.

How to Let Claude or ChatGPT Deploy Your App (Safely)

Noah Grinstein — Fri, 30 Oct 2026 20:53:11 +0000

You let Claude or ChatGPT deploy your app by connecting the assistant to a deployment platform through the Model Context Protocol (MCP), with sign-in and per-org permissions, so it can build, deploy, and check your app with tools instead of pasted commands. Control Plane is a listed connector in Claude and a listed plugin in ChatGPT, so connecting takes a few clicks.

TL;DR

An AI assistant on its own writes code and suggests commands. An assistant connected to a platform over MCP can also build an image, deploy it, read the logs, and roll back a bad release. The connection is what turns “here is a Dockerfile” into “your app is live at this URL.”

The 4-step version:

Connect. Add Control Plane from Claude’s connector directory or install it from the ChatGPT Plugin directory.
Authorize. Sign in to Control Plane and pick the orgs the assistant may access.
Describe the app. Tell the assistant what to build or deploy, and where.
Review the result. Check the URL, the workload status, and the audit trail. Approve anything destructive yourself.

How do AI assistants deploy apps?

MCP is an open-source standard for connecting AI applications such as Claude and ChatGPT to external tools and data. A platform publishes an MCP server, the assistant connects to it, and the assistant can then run the actions the server exposes, such as creating a workload or reading logs. The specification is public at modelcontextprotocol.io.

Assistant that only writes code	Assistant connected to a platform
Output	Source files and commands
Who runs the commands	You, by pasting them
Build	You run the build
Verification	You check the result
Failure handling	You read logs and report back
Access control	Your terminal session

Pasted commands also run with whatever credentials your shell holds. A connected assistant uses the access you granted on the platform, and nothing more.

How do I let Claude or ChatGPT deploy my application?

Connect the assistant to a platform that exposes deployment tools over MCP, then ask it to deploy. With Control Plane, the Claude and ChatGPT paths are directory listings, so there is no JSON to edit and no API key to paste. Coding agents and other MCP clients connect with a plugin or a URL. Each path is below.

How do I let Claude deploy my application?

Control Plane is a listed connector in Claude’s directory. These steps work in claude.ai and in the Claude desktop app. Connectors sync across both.

Open Claude’s connector directory.
Find Control Plane.
Click Connect to Claude.
Sign in to Control Plane with Google, GitHub, Microsoft, or SAML.
Pick the orgs Claude may access.

Directory listings connect on the core toolset profile. Full setup details are in the Claude setup guide.

Can Claude deploy my app to production?

Yes, once it is connected to a platform that deploys to production. Claude itself writes the code and calls tools. The platform does the build and the deploy, inside the orgs you selected during sign-in.

Three practices keep that safe:

Grant only the orgs Claude needs. An org you did not select is out of reach.
Start on the readonly toolset profile, added as a custom connector at https://mcp.cpln.io/mcp?toolsets=readonly, if you want Claude to inspect before it changes anything.
Review the result and the audit trail after every change.

Can ChatGPT deploy my app?

Yes. Control Plane is a listed plugin in the ChatGPT Plugin directory.

Open the Control Plane listing in the ChatGPT Plugin directory.
Click Install plugin.
Authorize the orgs ChatGPT may access.

The same listing reaches ChatGPT on the web, desktop, and mobile, and Codex. As with Claude, directory listings connect on the core toolset profile. See the ChatGPT setup guide.

How do coding agents and other MCP clients connect?

Claude Code, Codex, and Antigravity CLI can use the Control Plane AI plugin. It bundles:

The MCP server.
Control Plane domain skills.
Two guided agents: workload troubleshooting, and migration from Kubernetes, Docker Compose, or Helm.
Slash commands.
Guardrails.

The plugin is also listed in Anthropic’s community plugin marketplace, where every listing has passed Anthropic’s review. See the AI plugin guide.

Other MCP clients, including Cursor, VS Code, Amp, and OpenCode, connect to https://mcp.cpln.io/mcp. The AI overview lists every supported client.

The MCP server has over 100 tools in four toolset profiles: readonly, core, mk8s, and full. Directory listings use core. To use readonly, mk8s, or full, add the MCP URL by hand.

The MCP server cannot read your local filesystem. A folder on your machine builds with the CLI (cpln image build --remote) from an agent that has a terminal. A repository, an existing image, or code the assistant writes in the chat does not need the CLI.

The CLI, console, Terraform and Pulumi providers, and the MCP server all work through the same Control Plane API.

What should I ask the assistant to do?

Job tools do a whole task in one call. Examples are deploying an app, adding a database, creating or rotating a secret, and diagnosing a workload. The prompts below are quoted from Control Plane’s examples page.

Create an app from scratch

Create me a small Flask app that shows a random quote on each refresh and deploy it to org “my-org”. Give me the URL and the source code when it is up.

The assistant writes the code, builds it into an image in your org’s private registry, and deploys it as a public workload. It reports the URL and a link to download the source.

Deploy an existing image

Deploy nginx:latest as a public app called “web” on port 80 in GVC “production” and give me its URL.

A GVC is Control Plane’s Global Virtual Cloud, the set of locations a workload runs in. One call deploys the image with production defaults: health checks and two replicas, so a deploy does not take it offline.

Build from a repository

Build https://github.com/my-org/my-app on the main branch and deploy it as a public app called “my-app” in GVC “production”.

The repository is built on Control Plane. No Docker daemon or CLI is involved.

Recover from a bad deploy

Workload “api-server” in GVC “production” started failing after the last deploy. Diagnose it, and if the new image is the cause, roll it back and confirm it is healthy again.

Databases, caches, and secrets

Databases and caches come from the Template Catalog. Secrets can be created or rotated without the value passing through the chat, so the credential never lands in the conversation history.

Check workload health (illustration)

This prompt is an illustration, not quoted from Control Plane’s documentation.

Show me the status of every workload in GVC “production” and list any that are unhealthy.

Pair a prompt like this with the readonly profile when you want the assistant to look and not touch.

How do I give an AI agent safe access to my cloud infrastructure?

Start with principles that apply on any platform, then check how your platform implements them.

Vendor-neutral principles

Least privilege. Give the agent only the permissions the task needs.
Scoped tokens. Limit credentials by account, project, or org, and prefer short-lived ones.
Read-only first. Let the agent observe before it can change anything.
Audit trail. Record every change the agent makes, with the identity that made it.
Human review for destructive actions. Deletes, scale-downs, and secret changes need a person to approve.
Keep secrets out of the chat. A value pasted into a conversation can be stored, logged, or repeated.

How Control Plane applies them

Principle	Control Plane behavior
Scoped access	OAuth sign-in with per-org consent on every path. You scope each AI tool to the orgs it needs.
Read-only first	The readonly toolset profile advertises no tool that creates, updates, deletes, or executes anything. An assistant on it cannot change a live resource.
No privilege creep	The profile is fixed for the life of a connection. An agent cannot expand it mid-session.
Human review	Before a deletion, the assistant states what it removes and what breaks, then waits for your explicit yes.
Audit trail	Every change is recorded in the audit trail.
Secrets	Job tools create or rotate secrets without the value passing through the chat.

A practical rollout:

Connect the assistant to a test org first.
Begin on the readonly profile and ask it to describe what is running.
Reconnect on core, the profile the directory listings use, when you want it to deploy.
Keep production in a separate org, and grant it only when needed.
Review the audit trail after the first few sessions.

For a deeper look at risk and controls, see how to run AI agents on production infrastructure safely.

Where can I find a cloud friendly deployment platform for AI models?

The flow in this guide also deploys inference services. A model server is a workload like any other. Workloads can attach NVIDIA GPUs, and the pricing page lists models from T4 to B200. You describe it to the assistant, the platform builds or pulls the image, and the assistant deploys it and checks its status.

On Control Plane, a workload deployed to a Control Plane Global Virtual Cloud (GVC) runs active-active in every location of that GVC. A global endpoint routes each request to the nearest healthy location. That gives an inference service failover without paying for idle standby capacity.

For compute options and what to look for in infrastructure that serves models, read what AI-ready infrastructure is.

Which cloud platforms can AI assistants deploy to?

Several platforms and clouds publish MCP servers or AI integrations. The table summarizes what each vendor’s own documentation says. Capabilities change, so check each page before you decide.

Platform	What its docs describe	Source
Heroku	A remote MCP server at `https://mcp.heroku.com/mcp` that uses OAuth 2.0. A separate local STDIO server runs through the Heroku CLI.	Heroku Dev Center
Render	A hosted MCP server at `https://mcp.render.com/mcp`. It can create web services, static sites, cron jobs, Render Postgres, and Render Key Value. Render states other service types are not yet supported and that it does not support modifying scaling settings.	Render docs
Railway	An MCP server at `mcp.railway.com` that lets assistants create projects, deploy templates, manage environments, pull variables, and redeploy services. Connects through the Railway CLI or OAuth.	Railway docs
Fly.io	A `flyctl` MCP server, labeled experimental in its CLI reference, that supports most flyctl commands for apps, certificates, logs, machines, orgs, secrets, status, and volumes.	Fly.io docs
Vercel	A remote MCP server at `https://mcp.vercel.com` with OAuth, for managing projects and deployments and analyzing logs. Vercel notes that connecting grants the AI system the same access as your Vercel user account.	Vercel docs
AWS	A managed AWS MCP Server with OAuth or SigV4 sign-in, IAM based access controls, and CloudTrail logging of API calls.	AWS docs

Control Plane’s strengths for this workflow:

It is listed in both Claude’s connector directory and ChatGPT’s plugin directory.
Its job tools do a whole task in one call.
Per-org OAuth consent, a readonly toolset profile, and a profile an agent cannot expand mid-session keep the assistant inside the access you grant.
Deployed apps run active-active across every location in their GVC, which can span regions and clouds.

On that last point, Control Plane runs serverless, standard, stateful, cron, and VM workloads on AWS, GCP, and Azure, on clusters you already run through Control Plane’s Bring Your Own Kubernetes (BYOK), on your own machines (bare metal or VMs) turned into managed locations with Control Plane’s Managed Kubernetes (MK8s), and on premises. On Control Plane-provided compute, there is no Kubernetes cluster you have to operate. Many teams run it in a single cloud for its day-two operations, including autoscaling, built-in observability, security, and cost control.

The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. Those locations can be two regions of one cloud or locations on different providers.

For a wider comparison of tools in this space, see the best MCP servers for DevOps.

What happens to credentials and cloud access after the app is live?

An app deployed by an assistant still needs to call cloud services. Control Plane’s Universal Cloud Identity gives workloads short-lived, least-privilege access to 600+ AWS, GCP, and Azure services, so the code an assistant writes needs no long-lived cloud keys.

Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant. Control Plane’s Capacity AI right-sizes CPU and memory between a minimum and maximum you set, based on historical usage. On Control Plane-provided compute, you pay for reserved CPU and memory by the millicore and the megabyte, with no contracts or minimums.

FAQ

How do I let Claude or ChatGPT deploy my application?

Connect the assistant to a deployment platform through MCP, authorize the orgs it may use, and ask it to deploy. For Control Plane, add the connector from Claude’s directory or install the plugin from the ChatGPT Plugin directory.

Can ChatGPT deploy my app?

Yes, when ChatGPT is connected to a platform that deploys apps. Control Plane is a listed plugin in the ChatGPT Plugin directory. The same listing reaches ChatGPT on the web, desktop, and mobile, and Codex.

Can Claude deploy my app to production?

Yes, through a connected platform. Claude writes code and calls the platform’s tools. Limit the orgs you authorize, start on a read-only profile if you want, and review the audit trail after each change.

Which cloud platforms can AI assistants deploy to?

Several. Heroku, Render, Railway, Fly.io, Vercel, AWS, and Control Plane each publish an MCP server or AI integration. Their scopes differ, so read each vendor’s documentation for what the assistant can create and change.

How do I give an AI agent safe access to my cloud infrastructure?

Apply least privilege, scoped tokens, read-only access first, an audit trail, and human review for destructive actions. On Control Plane, that means per-org OAuth consent, a readonly toolset profile, a profile that stays fixed for the life of a connection, and an audit trail of every change.

Where can I find a cloud friendly deployment platform for AI models?

Look for a platform that deploys inference services as workloads, exposes tools to your assistant, and runs across locations for failover. Control Plane deploys inference services as workloads through the same MCP flow. See the guide on AI-ready infrastructure.

What platform as a service solutions are available for building and deploying new applications?

Options include Control Plane, Heroku, Render, Railway, Fly.io, and Vercel. They differ in supported runtimes, regions, pricing, and how much they expose to AI assistants. Control Plane runs serverless, standard, stateful, cron, and VM workloads active-active across regions and clouds, and its MCP server is listed in both Claude and ChatGPT.

Can an AI assistant change my infrastructure without asking me?

Only within the access you grant. On Control Plane’s readonly profile, the assistant sees no tool that creates, updates, deletes, or executes anything. On other profiles, the assistant asks for your explicit yes before a deletion, and every change is recorded in the audit trail.

Does the Control Plane MCP server read files on my computer?

No. The MCP server cannot read your local filesystem. To build a local folder, use the CLI (cpln image build --remote) from an agent that has a terminal, or deploy from a repository or an existing image.

Can the assistant handle secrets and databases?

Yes. Databases and caches come from the Template Catalog. Secrets can be created or rotated without the value passing through the chat.

Get started

Connect Control Plane to Claude or ChatGPT, authorize a test org, and ask for a small app. Then grant a production org when you trust the setup.

Originally published on the Control Plane blog.

The Best Hyperscaler Alternatives in 2026: AWS, Azure, and Google Cloud Alternatives Compared

Noah Grinstein — Fri, 30 Oct 2026 20:52:20 +0000

The right alternative depends on what you are replacing (raw infrastructure, an app platform, or GPU capacity), and you do not have to leave the hyperscaler entirely. Control Plane runs the same workloads across hyperscalers and alternative providers from one platform.

Control Plane publishes this guide.

TL;DR: What are the best alternatives to AWS, Azure, and Google Cloud?

Start by naming what you want to replace. A hyperscaler bill usually mixes three different things: virtual machines and storage, an application platform for deploying code, and GPU capacity for AI. Each has a different kind of alternative.

Raw infrastructure. Developer clouds and VPS or bare-metal providers give you servers and a smaller catalog of services.
An app platform. PaaS products take your code or container and run it, so you manage less.
GPU capacity. GPU clouds and neoclouds focus on AI hardware.
More than one of these at once. A multi-environment platform runs workloads across hyperscalers, infrastructure providers, and GPU clouds from one definition.

Control Plane ranks first because it is the only entry that runs one workload across hyperscalers and the infrastructure and GPU providers listed here. Infrastructure providers follow, then app platforms. The order is editorial, not a benchmark, and each description comes from the vendor’s own page, linked below.

Control Plane: runs one workload across hyperscalers, infrastructure providers, neocloud GPU capacity, and your own servers.
DigitalOcean: a cloud with an AI focus, covering agents, inference, and general cloud services.
Hetzner: cloud servers in shared and dedicated resource plans for developers and teams.
Akamai Cloud (Linode): cloud for applications and AI inference on a globally distributed platform.
Vultr: cloud compute, cloud GPU, and bare-metal servers.
OVHcloud: public cloud with compute, storage, databases, and managed Kubernetes.
Render: an app platform for web services, databases, cron jobs, and workflows.
Fly.io: hardware-virtualized machines and sandboxes for apps and agents.
Heroku: a fully managed application platform built around dynos and add-ons.
Railway: a repo-connected deployment platform with a visual canvas.

What are the three kinds of hyperscaler alternatives?

Type	Examples	Typical fit	What you manage	Typical trade-offs
Developer clouds and VPS or bare-metal providers	DigitalOcean, Hetzner, Akamai Cloud, Vultr, OVHcloud	Replacing virtual machines, storage, and networking	Operating systems, deployment, scaling, and often databases and monitoring	A smaller service catalog than a hyperscaler, so you assemble more yourself
App platforms (PaaS)	Render, Fly.io, Heroku, Railway	Deploying code or containers without running servers	Application code and configuration	Less control over infrastructure, and platform-specific conventions
GPU clouds and neoclouds for AI	CoreWeave, Lambda, Nebius	Training and inference on GPU hardware	Models, data movement, and the surrounding application stack	GPU-focused catalogs, so general services and data may live elsewhere
Multi-environment platforms	Control Plane	Running one workload across hyperscalers, infrastructure providers, GPU clouds, and your own servers	The workload definition, with the platform handling placement and routing	One platform to adopt, replacing a separate toolchain for each provider

These are general patterns for each type. Check any provider’s specifics against its own documentation and SLA before you commit.

How do the options rank?

1. Control Plane

Control Plane is the platform for running unbreakable apps and agents. It combines any cloud, neocloud, and bare metal into what Control Plane calls a Global Virtual Cloud (GVC).

It runs on Control Plane-managed compute in AWS, GCP, and Azure regions, on neocloud GPU capacity, and on your own servers. It runs serverless, standard, stateful, cron, and VM workloads. You can bring clusters you already run through Control Plane’s Bring Your Own Kubernetes (BYOK), or turn your own machines (bare metal or VMs) into managed locations with Control Plane’s Managed Kubernetes (MK8s). On Control Plane-provided compute, there is no Kubernetes cluster you have to operate. Many teams run it in a single cloud, not only across clouds.

A workload deployed to a GVC runs active-active in every location of that GVC, and a global endpoint routes each request to the nearest healthy location. You get failover without paying for idle standby capacity.

On Control Plane-provided compute, you pay for the CPU and memory a workload reserves, by the millicore and the megabyte, with no contracts or minimums. Control Plane’s Capacity AI right-sizes CPU and memory based on historical usage, within a minimum and maximum you set. Customers typically cut compute costs 30 to 50 percent compared with running directly on AWS, GCP, or Azure.

Workloads can attach NVIDIA GPUs, and the pricing page lists models from T4 to B200. Control Plane’s Universal Cloud Identity gives workloads short-lived, least-privilege access to 600+ AWS, GCP, and Azure services, with no long-lived cloud keys in your code. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant. The CLI, console, Terraform and Pulumi providers, and the Control Plane MCP server all work through the same Control Plane API, and Control Plane ships its own Terraform and Pulumi providers, so it complements the infrastructure as code you already run.

For head-to-head comparisons, see Control Plane vs AWS, vs Render, vs Heroku, vs Fly.io, and vs DigitalOcean App Platform.

2. DigitalOcean

DigitalOcean’s homepage describes an “AI-Native Cloud” and “a unified stack for agents, inference, and cloud.” It lists serverless inference with intelligent routing and “80+ models,” a product called Agent Droplets, and DigitalOcean Managed Agents, which it says is in Public Preview. It also sells CPU and GPU Droplets, Managed Kubernetes, App Platform, managed databases, and storage and backups.

3. Hetzner

Hetzner describes its Cloud as a “cloud-hosting provider for developers & teams.” The page lists server plans with shared resources and with dedicated resources, a price calculator, networks, an API, and one-click apps. It states that the service is made in Germany and GDPR-compliant. Its cloud servers are available in Germany, Finland, Singapore, and the USA. Hetzner also sells S3-compatible Object Storage and Storage Box backup storage.

4. Akamai Cloud (Linode)

Akamai Cloud is presented as “Akamai Cloud for AI, Applications, and Agents.” Akamai says it lets you “run AI with rapid, GPU-powered inference and edge-native compute at global scale,” and that it “runs on one of the world’s most distributed platforms.” Access to NVIDIA GPUs is by request. The page also lists CPU compute, managed Kubernetes, managed MySQL and PostgreSQL databases, object and block storage, and backups.

5. Vultr

Vultr sells cloud compute, cloud GPU, and bare-metal servers. Its documentation also covers object and block storage, managed databases, Kubernetes, load balancers, and a container registry.

6. OVHcloud

OVHcloud’s Public Cloud page describes “over 50 OVHcloud infrastructure services and managed platforms.” It lists compute, storage, databases, and a secure network in 1-AZ or 3-AZ regions, with hourly, monthly, or long-term billing. It also offers managed Kubernetes and container management.

7. Render

Render calls itself “the cloud for builders.” Its page lists web services, Postgres databases, cron jobs, workflows, static sites, background jobs, key value stores, and private services. It describes load-based autoscaling, full-stack previews for each pull request, and managed Postgres with point-in-time recovery, read replicas, and high availability. For a direct comparison, see Control Plane vs Render.

8. Fly.io

Fly.io describes Fly Machines as “hardware-virtualized containers that launch instantly and run only when you need them.” It also offers hardware-isolated sandboxes for running untrusted or AI-generated code, storage options, and managed Postgres. The page says you can deploy from GitHub or its CLI. See Control Plane vs Fly.io for a comparison.

9. Heroku

Heroku describes a “fully managed application platform.” Apps run in dynos, which it calls “smart containers.” The page lists Heroku Postgres, a Key-Value Store, add-ons, buildpacks, team management, and fast rollback. See Control Plane vs Heroku for a comparison. In February 2026, Heroku moved to a sustaining engineering model focused on stability, security, reliability, and support rather than new features.

10. Railway

Railway calls itself “the all-in-one intelligent cloud provider.” You connect a repository, and the page says Railway handles configuration automatically. It offers a visual canvas, built-in networking, scaling, and logs, metrics, and traces. In October 2026, Railway disclosed a security incident, described in its preliminary report and in Control Plane’s guide to rotating keys or migrating.

Which cloud providers are best for full infrastructure control?

Control follows a spectrum, and each step toward more control adds operations work.

Level	Example type	Control	Operations work
Most control	Bare metal and VPS providers	You choose the operating system, networking, and software	Highest. You patch, scale, and recover.
Middle	Managed Kubernetes on a cloud	You control workloads and configuration	Moderate. You run the workloads, the provider runs the control plane.
Least control	PaaS	You control code and settings	Lowest. The platform runs the infrastructure.

Control Plane sits across this spectrum. Bring Your Own Kubernetes (BYOK) lets you keep clusters you already run and add them as locations. Managed Kubernetes (MK8s) turns your own machines (bare metal or VMs) into managed Control Plane locations. You keep your own clusters and servers and manage them under one platform, so you do not give up hardware ownership to get one way of deploying. On Control Plane-provided compute, you can skip operating a cluster.

How do managed hosting platforms compare to hyperscalers for reliability, incident response, and SLAs?

Compare the same four things for every provider, including the hyperscalers.

SLA scope and conditions. Read what the SLA covers. Many apply to specific services or configurations and require a minimum setup, such as more than one instance or location.
Credits versus actual uptime. An SLA usually remedies a miss with service credits. Credits do not replace the revenue lost during an outage, so design for availability yourself.
Multi-region options. Check whether you can run in more than one region or provider, and what that costs.
Status page and incident transparency. Look at how the provider reports incidents, how quickly, and how much detail it gives afterward.

Hyperscalers also have major outages. Control Plane keeps a public record in its cloud outage tracker. Do not assume that size guarantees availability.

Control Plane’s 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. Those locations can be two regions of one cloud or locations on different providers. Take other vendors’ SLA figures from their own SLA pages.

What are common compute, storage, and networking service equivalents when moving off a hyperscaler?

The equivalents below are generic service types, not specific vendors’ products. Confirm that a provider offers a service on its own product page before you plan around it.

Hyperscaler service	Generic equivalent elsewhere	Migration note
Virtual machines	VPS or bare-metal servers	Re-create images and configuration, and plan for patching.
Managed Kubernetes	Provider-managed or self-managed Kubernetes, or a platform that hides it	Check version support and add-ons.
Object storage	S3-compatible object storage	Check API compatibility for your tools and libraries.
Managed databases	Managed PostgreSQL or MySQL, or a self-run database	Plan data transfer, backups, and failover testing.
Load balancers	Provider load balancer or a reverse proxy	Confirm health checks and TLS handling.
DNS	Any DNS provider	Lower the record lifetime before you cut over.
Secrets	Secrets manager or an open-source secrets tool	Rotate secrets as part of the move.
Monitoring	Open-source monitoring and logging tools	Rebuild dashboards and alerts.

You do not have to move everything. With Universal Cloud Identity, workloads running on Control Plane can keep using the hyperscaler services you depend on, such as storage or a managed database, while the compute moves. That lets you separate the move of compute from the move of data. Read how to run the same app on AWS, GCP, and Azure for a walkthrough.

What are good hyperscaler alternatives for small business apps needing databases, backups, and monitoring?

Developer clouds and PaaS platforms are often the simplest fit for small apps. They ship with fewer choices, and several bundle managed databases, backups, and monitoring into one product. Render’s page lists managed Postgres with point-in-time recovery and integrated logs and monitoring. Heroku’s page lists Heroku Postgres and app metrics. Fly.io’s page lists managed Postgres and storage options. Developer clouds such as DigitalOcean, Vultr, and OVHcloud list managed database and storage products on their own pages, and Hetzner lists object storage and backup storage.

Use this checklist for a small app:

Does the platform offer a managed database for the engine you use?
Are backups included, and can you restore to a point in time?
Does it include logs and metrics, or must you add a monitoring tool?
What do you pay when the app is idle?
How do you move off it if you outgrow it?

What is the simplest cloud platform alternative for small business apps needing predictable monthly pricing?

For most small apps, a PaaS or a developer cloud with plan-based pricing is the simplest fit. Read each vendor’s pricing page for the plan structure.

Control Plane works differently. On Control Plane-provided compute, it bills per millicore and megabyte reserved, with no contracts or minimums. That suits teams that want to pay for what a workload reserves and that expect load to vary. It is not a fixed monthly plan.

How do performance and networking differ between hyperscalers and alternative AI infrastructure providers?

The differences fall into four areas. None of them can be settled with a headline number, so test your own workload.

GPU availability. Hyperscalers and GPU clouds both limit capacity at times. A provider that specializes in GPUs may have different hardware and lead times. Check what you can get, for how long, and under what terms.
Interconnect options. Training across many GPUs depends on how the GPUs are connected inside the provider. Ask which networking options exist for the cluster size you need.
Data transfer between providers. Moving data between a hyperscaler and a GPU provider can add cost and time. Keep data close to compute where you can.
Global network reach. Inference serving users in many regions depends on where the provider has locations and how requests are routed.

Control Plane workloads can attach NVIDIA GPUs, and the pricing page lists models from T4 to B200. A GVC can include neocloud GPU capacity next to a hyperscaler region. Control Plane’s GPU Ocean lets you pull GPU capacity from any provider. For a comparison of GPU providers, see best GPU cloud providers in 2026.

Do you have to choose only one provider?

No. Many teams keep a hyperscaler for the services they depend on and add an alternative for cost, control, or GPU capacity. The risk is running a second stack: separate deployment pipelines, separate access control, and separate monitoring for each provider.

Control Plane addresses that risk. You define a workload once, and it runs in every location of a GVC. The locations can be two regions of one cloud or locations on different providers. A global endpoint routes each request to the nearest healthy location. That lets you run a hyperscaler and an alternative together, with one workload definition across both. For the step-by-step version, read how to run the same app on AWS, GCP, and Azure.

FAQ

What are good non hyperscaler options for running containerized web apps as a platform service?

Control Plane runs containerized workloads as a platform service on Control Plane-managed compute, with no Kubernetes cluster for you to operate. App platforms such as Render, Fly.io, Heroku, and Railway also run apps for you.

Which cloud providers are best for full infrastructure control?

Bare metal and VPS providers give the most control and the most operations work. Control Plane lets you keep your own clusters and servers through BYOK and MK8s, under one platform.

How do managed hosting platforms compare to hyperscalers for reliability, incident response, and service level agreements?

Compare SLA scope and conditions, credits versus actual uptime, multi-region options, and status page transparency. Hyperscalers also have major outages, as the cloud outage tracker records. Control Plane’s 99.999% availability SLA applies to workloads running at least two replicas in at least two locations.

What are common compute, storage, and networking service equivalents when moving off a hyperscaler?

Virtual machines map to VPS or bare-metal servers. Object storage maps to S3-compatible storage. Managed databases map to managed PostgreSQL or similar. Load balancers, DNS, secrets, and monitoring each have generic equivalents, listed in the table above. Confirm a specific provider’s offering on its own page.

What are good hyperscaler alternatives for small business apps needing databases, backups, and monitoring?

Developer clouds and PaaS platforms are often the simplest fit. Check each for a managed database, backup and restore options, and built-in monitoring.

What is the simplest cloud platform alternative for small business apps needing predictable monthly pricing?

A PaaS or developer cloud with plan-based pricing is usually the simplest fit. Control Plane bills per millicore and megabyte reserved, with no contracts or minimums, which is a different model from a fixed plan.

How do performance and networking differ between hyperscalers and alternative AI infrastructure providers?

Compare GPU availability, interconnect options, data transfer between providers, and global network reach. Test your own workload rather than relying on a headline figure.

Do I have to leave AWS, Azure, or Google Cloud entirely?

No. You can keep a hyperscaler for the services you depend on and move compute elsewhere. Universal Cloud Identity lets workloads on Control Plane keep using hyperscaler services while compute moves.

Is Control Plane only for multi-cloud?

No. Many teams run it in one cloud. It also runs on your own servers and on premises.

Next steps

Name what you are replacing, shortlist one provider per job, and test one workload before you move more.

Originally published on the Control Plane blog.

How to Run AI Inference Across Multiple GPU Clouds: Failover, Burst, and Portability in 2026

Noah Grinstein — Fri, 30 Oct 2026 20:51:28 +0000

Disclosure: Control Plane publishes this guide.

TL;DR

To keep inference online and portable, package the model server as a container, run it in at least two GPU locations on different providers, and route requests to the nearest healthy one. Control Plane runs one inference workload across cloud regions and your own GPU servers, and routes each request to the nearest healthy location.

Why single-provider inference breaks: GPU capacity, quotas, regional outages, price changes, and model API outages all sit behind one vendor relationship.
The three patterns: active-active across GPU providers, a primary provider with a failover provider, and your own GPUs as the base with cloud burst.
How to choose providers: match each provider to your latency target, GPU memory needs, data residency rules, and exit cost. Pair a hyperscaler with a neocloud instead of ranking them.
How Control Plane fits: one workload deploys to Control Plane’s Global Virtual Cloud (GVC), a set of locations that can be cloud regions or GPU servers. A global endpoint routes each request to the nearest healthy location.
First steps: containerize the model server, pin versions, pre-stage weights in two locations, health check with a real inference request, and drill the failover.

Why does single-provider inference break?

Inference is a production service, but most teams run it behind one GPU cloud or one model API. Four things go wrong with that setup.

Capacity shortages and quota limits. Specific GPU models run short, and accounts carry quotas per GPU type and region. A launch or traffic spike can hit a quota while the model server is healthy.

Regional and provider outages. Major cloud providers have multi-hour outages. The Control Plane cloud outage tracker lists 62 major outages at AWS, Microsoft Azure, Google Cloud, and Cloudflare since 2020, with a median duration of 6h 08m. By provider, it shows AWS with 14 incidents (median 7h 34m), Azure with 20 (median 8h 17m), and Google Cloud with 12 (median 6h 08m). The tracker notes these counts reflect what each provider documents publicly and are not a reliability ranking. Its longest completed outage is Azure East US 2 in January 2025, at 50h 13m. As of its October 21, 2026 update, it also lists two AWS Middle East regions as disrupted since March 2026. The tracker covers cloud outages in general, not GPU services specifically. An inference service pinned to one region still inherits that region’s worst day.

Price changes. GPU prices and terms change. If your model server only runs on one provider’s services, you pay what that provider asks.

Model-provider API outages. If your product calls a hosted model API, its outage is your outage, whatever your own infrastructure looks like.

What are common challenges in AI model inference and how can I overcome them?

Challenge	Why it happens	Fix
GPU availability	Specific GPU models are scarce, and quotas cap what one account can use.	Qualify at least two providers for the same model server. Request quota in advance.
Cold starts and model load time	Weights are large and must be copied to a new node and loaded into GPU memory before the first request.	Pre-stage weights near every location. Keep a minimum number of warm replicas.
Latency for global users	Requests travel to one region, then back.	Run in several regions and route each request to the nearest healthy location.
Cost of idle GPUs	Standby capacity sits unused until a failure or spike.	Serve traffic from every location instead of holding idle standby. Own steady capacity and rent peaks.
Model and driver version drift	Locations are built at different times with different CUDA, driver, or server versions.	Pin versions in the container image. Deploy one image everywhere.
Observability	Each provider has its own metrics, logs, and dashboards.	Export metrics from the model server in one format. Track latency, queue depth, and error rate per location.
Data residency	Prompts and outputs may contain regulated data that must stay in a region.	Choose locations by jurisdiction. Route regulated traffic only to approved locations.

What are the three multi-provider patterns for AI inference?

All three patterns share one requirement: the same container image and the same model weights must be available in every location that might serve traffic.

Active-active across GPU providers

How it works. The model server runs in two or more locations on different providers. A global endpoint or load balancer sends each request to a healthy location, usually the nearest.

When to use it. Use it for user-facing inference where latency matters and an outage cannot wait for a manual switch.

Idle capacity cost. Low, because every location serves traffic. You still need enough total capacity that the remaining locations can absorb a lost location’s share. See the cost comparison in active-active vs active-passive.

What breaks during failover. Surviving locations take extra load and may queue requests or scale up. Scale-up needs warm-up time, so set a minimum replica count that covers a lost location. Version drift between locations can produce inconsistent answers.

Primary plus failover provider

How it works. One provider serves all traffic. A second provider holds the same image and weights and takes over when health checks fail.

When to use it. Use it for internal tools, batch inference, or products where a short brownout is acceptable and a second always-on fleet is hard to justify.

Idle capacity cost. Depends on how warm the failover is. A cold standby costs little and starts slowly. A warm standby starts fast and costs close to a second fleet.

What breaks during failover. Cold start is the main risk: weights must already be present and loaded. DNS-based switching adds propagation delay. Standby configurations also drift, because nobody tests them daily.

Own GPUs as the base with cloud burst

How it works. Steady traffic runs on GPU servers you own or reserve. Peaks go to cloud GPUs running the same image.

When to use it. Use it when baseline demand is predictable and high enough that owned hardware is cheaper than renting, and when peaks are brief.

Idle capacity cost. Owned servers carry fixed cost whether busy or not. Cloud burst capacity costs money only while it runs, but only if you can get the GPUs when the spike arrives.

What breaks during failover. Weights must be in the cloud location before the spike, not copied during it. The network path between your data center and the cloud adds latency and transfer cost. If the two environments run different driver or server versions, outputs can differ between them.

How do I fail over AI inference between GPU providers when one has an outage?

Follow these six steps.

Containerize the model server. Use a serving engine that ships as a container. vLLM describes itself as a fast and easy-to-use library for LLM inference and serving, and its docs cover deployment with Docker and Kubernetes. NVIDIA Dynamo-Triton, formerly Triton Inference Server, describes itself as open source inference serving software that supports models from multiple frameworks across cloud, data center, and edge. Hugging Face Text Generation Inference serves LLMs with Prometheus metrics and OpenTelemetry tracing, and its docs now state it is in maintenance mode and recommend vLLM, SGLang, llama.cpp, or MLX going forward.
Pin model and driver versions. Fix the model revision, serving engine version, CUDA version, and driver version in the image and in your infrastructure code. Upgrade all locations together.
Pre-stage weights in each location. Replicate weights to object storage or local disk near every GPU location. Verify checksums. A failover that has to download 100 GB of weights is a slow failover.
Use health checks that run a real inference request. A process that answers on a port can still fail to generate. Send a short prompt, check for a valid response within a time limit, and fail the location if it does not.
Route with a global endpoint or load balancer you control. The router must sit outside any one provider’s failure domain, and it must remove unhealthy locations automatically.
Drill the failover. Take a location out of rotation on a schedule. Measure how long recovery takes and how much traffic errors out. Fix what the drill finds.

How do I keep an AI product online when my model provider or GPU cloud has an outage?

For a GPU cloud outage, use the steps above. For a hosted model API outage, add a fallback chain:

Primary: the hosted model API you use today.
Second choice: a second API provider, with prompts tested against both.
Last resort: a self-hosted open-weight model running in two GPU locations.

Test prompts and output parsing against every model in the chain, because models differ in format and tone. Decide in advance whether a lower-quality answer is better than an error. Set timeouts short enough that the fallback triggers before users give up. Agent workloads need the same discipline. See where to run agents in production.

How do I run LLM inference on my own GPUs and burst to the cloud when demand spikes?

Keep steady traffic on owned or reserved GPU servers. Send peaks to cloud GPUs. Four points decide whether this works.

Size the base to the floor, not the peak. Owned GPUs earn their cost when they are busy. Set the base to the load you carry most hours, and let the cloud cover the rest.

Keep both environments identical. Use the same container image, the same pinned versions, and the same configuration from one infrastructure-as-code repository. Differences between the owned and cloud environments show up as inconsistent answers during a spike.

Pre-stage weights in the cloud. Copy weights to cloud storage near the burst location before you need it. Keep a small number of warm replicas so the first burst requests do not wait for model load.

Account for latency and data transfer. Requests that cross between your data center and a cloud region add round-trip time. Moving data or weights between them can add transfer charges. Place the burst location in a region close to your users and your data, and keep data that must stay on premises out of the burst path.

How do I move between GPU providers as prices and availability change?

Use this portability checklist:

Containers, not provider-specific services. Package the model server in a container image that any Kubernetes-compatible environment can run.
Infrastructure as code. Define locations, networking, and workloads in code, such as Terraform or Pulumi, so a new provider is a new target.
Open model formats where you can. Avoid formats that only one provider’s runtime can load. Keep a copy of the original weights.
Object storage replication for weights. Replicate weights across providers on a schedule, so any location can start serving without a long copy.
A routing layer you control. If your provider owns the router, your provider controls your exit. Run routing outside any one GPU cloud.
Identity without long-lived keys. Provider-specific keys embedded in code make moves harder. Use short-lived credentials instead.

Test the checklist by moving a small share of non-critical traffic to a second provider each quarter.

How do the main GPU clouds compare?

CoreWeave vs Lambda vs AWS for GPU workloads

All three offer NVIDIA GPUs, and they differ in type and positioning. AWS is a hyperscaler that sells GPU instances next to a broad set of other services. CoreWeave and Lambda are neoclouds that focus on AI workloads. The table below states only what each provider’s own pages say, as of October 30, 2026. Check each page for current prices, GPU availability, and regions, which change often.

Best GPU cloud providers for inference

The right provider depends on your workload, so this table does not rank them.

Provider	Type	Best for (per its own pages)	Notes
AWS	Hyperscaler	Deep learning and HPC applications	The EC2 P5 page describes instances powered by NVIDIA H100 GPUs, and P5e and P5en instances powered by NVIDIA H200 GPUs.
Google Cloud	Hyperscaler	Machine learning, data processing, and graphics-intensive workloads	The Compute Engine docs list NVIDIA GPU models and the accelerator-optimized machine series they attach to.
Microsoft Azure	Hyperscaler	Compute-intensive, graphics-intensive, and visualization workloads (GPU sizes)	The VM sizes overview groups sizes into families, including the GPU accelerated NC, ND, NG, and NV families.
CoreWeave	Neocloud	Complex AI workloads	Describes itself as the AI cloud purpose-built for training and serving models at scale.
Lambda	Neocloud	Training and inference at scale	Lists NVIDIA Vera Rubin NVL72, GB300 NVL72, HGX B300, HGX B200, H200, and H100 GPUs, offered as Instances, 1-Click Clusters, and Superclusters.
Runpod	Neocloud	Training, inference, and batch workloads	Offers on-demand GPUs and serverless compute, with Pods, Serverless, and Clusters.
Nebius	Neocloud	AI developers	Describes built-in MLOps tooling, serverless inference, and managed inference.

For a fuller roundup, see The Best GPU Cloud Providers for AI Inference and Training in 2026.

The strongest setup uses more than one of these. A hyperscaler gives you broad services and compliance coverage. A neocloud may give you GPU capacity or terms the hyperscaler cannot. Running the same container in both means an outage, a quota limit, or a price change at one provider moves traffic to the other.

How do I choose an AI model inference service for my application?

Work through this checklist in order:

Latency target. Set a time-to-first-token and total-response target for your users. Measure from where users sit, not from the provider’s region.
Throughput. Estimate peak requests per second and tokens per request. Plan capacity for the peak, then decide what runs on base capacity and what bursts.
Model size and GPU memory. The weights plus the KV cache, which grows with batch size and context length, must fit in the memory of one GPU or be split across several GPUs. This decides which GPUs qualify and how many you need.
Data residency and compliance. List the jurisdictions and certifications your data requires. Remove providers and regions that do not fit.
Managed API or self-hosted. A managed API is faster to start and ties you to that provider’s model and uptime. Self-hosting gives control over versions, cost, and location, and adds operational work.
Exit cost. Estimate what it takes to leave: egress charges, weight migration, retraining of prompts, and rework of provider-specific code.

How do I combine GPU capacity from multiple providers into one environment?

On Control Plane, you deploy one inference workload to a Global Virtual Cloud (GVC). A GVC combines any cloud, neocloud, and bare metal into one environment. Its locations can be AWS, GCP, or Azure regions, and GPU servers from other providers or your own data center. You join GPU servers as managed locations with Control Plane Managed Kubernetes (MK8s), or connect clusters you already run with Control Plane’s Bring Your Own Kubernetes (BYOK).

The workload runs in every location of the GVC. A global endpoint routes each request to the nearest healthy location, so you get failover without paying for idle standby capacity. A workload’s GPU request applies in every location of its GVC, so choose locations that offer the same GPU model.

On Control Plane, a readiness probe (HTTP, gRPC, TCP, or a command) decides when each replica can take traffic. A command probe, or an HTTP health endpoint that runs a short inference request, makes that check real. When a location has no ready replicas, the workload’s global endpoint routes requests to another healthy location. Metrics, logs, and traces for every location appear in one place, so you do not stitch together each provider’s dashboards.

The approach has held up in a real outage. During the October 2025 AWS us-east-1 outage, which lasted about 15 hours, Control Plane customers with us-east-1 in their GVC had no downtime, and their workloads were “active and running in healthy locations within 10 seconds,” according to the company’s internal incident telemetry. See designing systems that survive the inevitable.

Workloads can attach NVIDIA GPUs, and the pricing page lists models from T4 to B200. Control Plane’s GPU Ocean lets you pull GPU capacity from any provider by joining GPU servers as locations with MK8s.

Control Plane’s location routing options shift traffic between locations by setting priority tiers and latency offsets per location.

Control Plane backs this with a 99.999% availability SLA, which applies to workloads running at least two replicas in at least two locations. Those locations can be two regions of one cloud or locations on different providers.

A few more facts matter for inference teams:

Where it runs. Control Plane runs serverless, standard, stateful, cron, and VM workloads on AWS, GCP, and Azure, on clusters you already run through BYOK, on your own machines (bare metal or VMs) turned into managed locations with MK8s, and on premises. On Control Plane-provided compute, there is no Kubernetes cluster you have to operate. Many teams run it in one cloud, so you can adopt it before you add a second provider.
Cost. Customers typically cut compute costs 30 to 50 percent compared with running directly on AWS, GCP, or Azure.
Billing. On Control Plane-provided compute, you pay for the CPU and memory you reserve, by the millicore and the megabyte, with no contracts or minimums. Other resources such as egress, storage, load balancers, and GPUs are also billed.
Identity. Control Plane’s Universal Cloud Identity gives workloads short-lived, least-privilege access to 600+ AWS, GCP, and Azure services, with no long-lived cloud keys in your code.
Compliance. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant.
Tooling. The CLI, console, Terraform and Pulumi providers, and the Control Plane MCP server all work through the same Control Plane API. Because Control Plane ships its own providers, it complements the infrastructure as code you already run.

For the layers an inference stack needs, read what infrastructure you need to run an inference layer.

How do I run inference on my own GPUs alongside my cloud apps?

On Control Plane, join your GPU servers as a managed location with MK8s, or attach an existing cluster with BYOK, and add that location to the same GVC as your cloud locations. Your inference workload and your cloud apps then share one environment, one API, and one global endpoint. To prefer your own GPUs, set Control Plane’s location routing options. Put the owned location in a higher-priority routing tier than the cloud locations, and the cloud locations, which run the same workload, take traffic only when the owned location becomes unavailable. To lean traffic toward your own GPUs while cloud locations still serve users near them, give the cloud locations a positive latency offset instead. With MK8s, Control Plane operates the Kubernetes layer on the GPU servers you join, and the hardware stays yours.

FAQ

How do I fail over AI inference between GPU providers when one has an outage?

Run the same container image in at least two GPU locations on different providers, with weights pre-staged in each. Use health checks that run a real inference request, and route through a global endpoint outside any one provider. Drill the failover on a schedule.

How do I keep an AI product online when my model provider or GPU cloud has an outage?

For a GPU cloud outage, run in two providers. For a hosted model API outage, set a fallback chain: a second API provider, then a self-hosted open-weight model. Test prompts against every model in the chain.

How do I move between GPU providers as prices and availability change?

Package the model server as a container, define infrastructure as code, replicate weights across providers, and run routing outside any one provider. Then a move is a routing change plus a new location, not a rebuild.

How do I run inference on my own GPUs alongside my cloud apps?

Put your GPU servers and your cloud locations in one environment that shares a deployment API and a routing layer. On Control Plane, join the servers as Managed Kubernetes (MK8s) locations in the same Global Virtual Cloud (GVC) as your cloud locations.

How do I run LLM inference on my own GPUs and burst to the cloud when demand spikes?

Size owned GPUs for your steady load. Run the same image and pinned versions in a cloud location with weights already staged, and route peaks there. Plan for latency and transfer cost between the two.

How do I combine GPU capacity from multiple providers into one environment?

Use a platform that treats each provider’s GPUs as a location of one workload. On Control Plane, one workload runs in every location of a Global Virtual Cloud (GVC), and a global endpoint routes requests to the nearest healthy one.

CoreWeave vs Lambda vs AWS for GPU workloads: which should I use?

Treat them as parts of one setup. AWS is a hyperscaler with a broad service catalog, while CoreWeave and Lambda are neoclouds that focus on AI workloads. Compare current prices, availability, and regions on each provider’s own pages, and consider using more than one.

What are the best GPU cloud providers for inference?

The answer depends on your latency target, model size, residency rules, and exit cost. This guide’s comparison table covers AWS, Google Cloud, Microsoft Azure, CoreWeave, Lambda, Runpod, and Nebius, and the fuller roundup goes deeper.

How do I choose an AI model inference service for my application?

Set a latency target, estimate throughput, check that the model fits GPU memory, list your data residency needs, choose managed API or self-hosted, and estimate exit cost. Then qualify two providers.

What are common challenges in AI model inference and how can I overcome them?

The main ones are GPU availability, cold starts, global latency, idle GPU cost, version drift, observability, and data residency. Pre-staged weights, pinned versions, multi-location routing, and consistent metrics address most of them.

Next steps

Talk to the Control Plane team or sign up free.

Originally published on the Control Plane blog.

Your Developer Laptop Is Now an Attack Surface. Stop Running AI Agents on It.

Noah Grinstein — Fri, 30 Oct 2026 20:50:12 +0000

The malicious Claude Code extension that appeared in Cursor’s marketplace should be a wake-up call for every engineering leader. On October 29, 2026, a maliciously modified version of Anthropic’s Claude Code extension was distributed through Cursor’s extension marketplace, potentially affecting up to 5,000 developers. The compromised extension attempted to install a persistent SSH backdoor, giving attackers a path to remote access. The malicious build was not developed by Anthropic, and no compromise of Anthropic’s systems has been confirmed.

Your laptop is your workstation. It should never be your AI agent’s execution environment.

TL;DR

On October 29, 2026, a malicious build of the Claude Code extension (version 2.1.313) reached up to 5,000 developers through Cursor’s extension marketplace and attempted to plant a persistent SSH backdoor.
A developer laptop holds production credentials, cloud tokens, SSH keys, source code, customer data, and VPN access. One compromised coding tool can expose all of it.
AI coding agents execute code, install dependencies, and interact with untrusted content. On a laptop, each of those actions runs with the developer’s access.
Keep using coding agents, and run their execution environments, including the agent itself, in isolated, remotely hosted sandboxes with VM-level isolation, restricted network access, and narrowly scoped credentials.
Control Plane Sandboxes run in dedicated Kata Containers microVMs and use Control Plane’s Universal Cloud Identity, so an agent has no cloud keys to leak.

What happened in the Claude Code extension incident?

According to Cursor’s security notice, a maliciously modified version of Anthropic’s Claude Code extension was available in Cursor’s VS Code extension marketplace for about 11 hours on October 29, 2026, between roughly 2:27 a.m. and 1:35 p.m. Pacific time. The affected package is Anthropic.claude-code version 2.1.313. You are at risk only if you installed or updated to that version from Cursor’s marketplace during that window, which includes automatic updates. Cursor says at most 5,000 users were affected and that it will contact them directly.

The malicious build attempted to add an attacker-controlled SSH key to the developer’s authorized_keys file, enable the local SSH service, and open a reverse SSH tunnel. Cursor says the added key is labeled svc-telemetry. It made the tunnel persistent through a LaunchAgent on macOS and a scheduled task or Startup script on Windows, and StepSecurity and The Hacker News also report a cron entry on Linux.

Cursor says enabling SSH requires administrator rights the extension lacks on most macOS and Windows machines, so on those machines that step failed and the attacker could not log in through the tunnel. The extension still added the attacker’s key, installed persistence, and sent host details to the attacker, including the hostname, username, environment variable names, configured Git email, and public IP address.

Cursor states the malicious version was not developed by Anthropic and that it has no evidence other versions or the official distribution were affected. Cursor pulled the version, shut down its marketplace to audit it, and reports that no other extensions were tampered with. How the build was published under the extension’s name has not been publicly explained, as BleepingComputer notes, and no compromise of Anthropic’s systems has been confirmed. The Hacker News reports that Anthropic has published a clean version, 2.1.314.

The specific attack matters less than the pattern. A trusted developer tool, delivered through a normal marketplace, became a path into developer machines.

If you installed the extension, do this now

Follow the check in Cursor’s security notice to confirm whether you are affected.
If you are affected, disconnect the machine from the network before anything else.
Look for an entry labeled svc-telemetry in ~/.ssh/authorized_keys and, on Windows administrator accounts, in C:\ProgramData\ssh\administrators_authorized_keys. Remove any key you did not add.
Uninstalling the extension is not enough, because the payload leaves standalone persistence scripts. Use the remediation scripts Cursor publishes for macOS and Windows, or remove persistence by hand: ~/Library/LaunchAgents, /Library/LaunchAgents, and /Library/LaunchDaemons on macOS; Task Scheduler and Startup folders on Windows; crontab on Linux. Then stop any reverse SSH tunnel processes.
If you did not enable it yourself, turn off the SSH server: Remote Login on macOS, the sshd service on Windows or Linux.
From a clean device, rotate every secret the machine could reach: cloud credentials, SSH keys, API tokens, repository tokens, and package-registry publish tokens. Invalidate active sessions, and check your Git host for SSH or deploy keys you did not add.
Assess whether to rebuild the machine from a known-good state, then reinstall the extension at version 2.1.314 or later. Contact security@cursor.com with questions.

Why is a developer laptop such a big target?

Consider what sits on a typical developer’s laptop:

Production credentials and cloud access tokens.
SSH keys and access to private repositories.
Customer data, internal documents, and proprietary source code.
VPN connections into corporate infrastructure.

An attacker who gets code execution on that laptop inherits the developer’s access, and a persistent backdoor can keep that access after the malicious tool is removed.

Why do AI coding agents raise the stakes?

AI coding agents routinely execute code, install dependencies, and interact with untrusted content. Each of those is a path in:

Executing code. Agents run builds, tests, and scripts. Malicious code runs with the developer’s permissions.
Installing dependencies. Agents pull packages from public registries, where typosquatted and compromised packages appear regularly.
Reading untrusted content. Agents read issues, web pages, and documentation. Instructions hidden in that content can steer an agent into running commands or sending data it should not.
Running as an extension. The agent itself is software delivered through a marketplace. If that delivery channel is compromised, the agent is the attack, and it runs wherever the agent is installed.

Running all of that directly on a laptop gives every one of those paths the developer’s access. A remote sandbox helps only if the agent itself, not just its commands, runs there.

Laptop vs remote sandbox: what changes?

Agent runs on the laptop	Agent runs in an isolated remote sandbox (recommended setup)
What a compromised agent can reach	Everything the developer can reach: SSH keys, cloud tokens, repositories, VPN
Isolation boundary	None beyond the developer’s user account
Credentials	Often long-lived keys, tokens, and browser sessions
Persistence	A backdoor can survive removal of the tool
Network access	The laptop’s network, often including the corporate VPN
Cleanup after an incident	Investigate and rebuild a developer machine

How should you run AI coding agents safely?

Keep the developer’s workflow. Move the agent’s execution somewhere a compromise stays contained. A practical checklist:

Run agents in remote sandboxes. Install the agent CLI or extension inside the sandbox, not in the local editor, and keep its tools and dependencies off developer endpoints.
Use VM-level isolation. A shared kernel is a weaker boundary for code you do not trust.
Restrict network access. Give the sandbox only the network paths the task needs.
Scope credentials narrowly. Use short-lived, least-privilege credentials, never long-lived keys copied into the environment.
Bring no laptop secrets in. Do not mount the home directory, forward the SSH agent, or copy ~/.aws, ~/.ssh, or .env files. Give each sandbox its own repository-scoped token, read-only by default.
Make environments disposable. Start each task from a known template and throw the environment away afterward.
Keep production separate. Sandboxes are for building and running untrusted code, not for serving production traffic.
Review before merge. Agent output still goes through code review and CI, and agent tokens cannot push to protected branches or edit CI workflows.
Log and audit. Record agent commands, outbound connections, and credential use, and alert on anything unexpected.

For a broader comparison of options, see the best AI agent sandboxes in 2026, and for why sandbox design matters to coding agents, read dumb sandbox vs smart sandbox for coding agents.

What are Control Plane Sandboxes and how do they help?

Control Plane Sandboxes are isolated, remotely hosted environments where AI coding agents run code, install dependencies, and use tools inside dedicated Kata Containers microVMs, away from developer laptops. Control Plane is the platform for running unbreakable apps and agents, and its Sandboxes are designed for exactly this problem: developers keep their familiar workflows, agents get isolated execution environments, and a compromised agent does not automatically inherit access to everything on a developer’s machine.

VM-level isolation. Sandboxes run in dedicated Kata Containers microVMs.
No cloud keys to leak. Sandboxes use Universal Cloud Identity to call AWS, GCP, and Azure services without storing credentials in the sandbox.
Blueprint templates. Teams define templates with the tools an agent needs, such as cloud CLIs, Git CLIs, and coding agent CLIs, then start ephemeral sandboxes from them.
Sized for the work. Sandboxes range from 2 to 16 or more CPUs, and each has a dedicated TLS endpoint.
Idle behavior. Sandboxes auto-sleep when idle and spin back up in under one second.
Private access when needed. Control Plane’s Cloud Wormhole gives sandboxes access to services in VPCs and private on-premises networks behind firewalls, without VPN clients to install.
Familiar access. Developers connect with the Control Plane CLI command cpln sandbox connect from Cursor, over SSH, or in a browser IDE. See Getting Started with Sandbox.

Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant. When an agent graduates from experiment to production, it runs as a regular workload on the same platform. Read how to let AI agents work on production infrastructure safely.

See how Sandboxes fit your agents: talk to the Control Plane team.

How much does a sandbox reduce the blast radius?

No isolation layer stops every attack. What a sandbox changes is how far an attack can travel. A compromised agent inside an isolated environment with narrowly scoped access is a contained incident. The same agent on a developer laptop can become a breach of your engineering environment.

Your laptop is your workstation. It should never be your AI agent’s execution environment.

Doron Grinstein, CEO, Control Plane

FAQ

Should AI coding agents run on developer laptops?

Not for execution. Coding agents run code, install dependencies, and read untrusted content. On a laptop they inherit everything the developer can reach: SSH keys, cloud tokens, source code, and VPN access. Run the agent’s execution environment in an isolated remote sandbox, install the agent there rather than as a local editor extension, and keep the developer’s machine for editing and review.

What should I do if I installed the malicious Claude Code extension?

Follow the check in Cursor’s security notice. If you are affected, disconnect the machine, remove any authorized_keys entry labeled svc-telemetry, remove the persistence scripts (uninstalling the extension is not enough), and turn off the SSH server if you did not enable it. From a clean device, rotate the credentials the machine could reach and invalidate sessions. Then consider rebuilding the machine from a known-good state and reinstall version 2.1.314 or later.

What is a sandbox for AI coding agents?

An isolated, disposable environment where an agent can run code, install packages, and use tools without touching the developer’s machine or production systems. Good sandboxes add VM-level isolation, restricted network access, and short-lived, narrowly scoped credentials.

Does a sandbox stop every attack?

No. A sandbox limits the blast radius. A compromised agent inside a sandbox can reach only what that sandbox is granted, not everything on a developer’s laptop, unless it escapes the isolation boundary. You still need dependency hygiene, code review, and least-privilege access.

How do Control Plane Sandboxes isolate AI agents?

Sandboxes run in dedicated Kata Containers microVMs. They start from blueprint templates, auto-sleep when idle, and use Universal Cloud Identity to call AWS, GCP, and Azure services without storing cloud credentials, so an agent has no cloud keys to leak.

Can developers keep their normal workflow with remote sandboxes?

Yes. Developers keep their editor and review flow and connect to the sandbox when they need a shell, for example with cpln sandbox connect from Cursor, over SSH, or in a browser IDE. The agent’s tools and dependencies live in the sandbox, not on the laptop.

Get started

Talk to the Control Plane team | Sign up free

Originally published on the Control Plane blog.

Active-Active vs Active-Passive: The Real Cost of Multi-Region High Availability in 2026

Noah Grinstein — Fri, 30 Oct 2026 20:49:17 +0000

Traditional active-active usually costs roughly twice a single region because you run a full second stack, while active-passive costs less but recovers slower and sits idle most of the time. Control Plane is the platform that runs one workload active-active across locations without paying for idle standby capacity.

Disclosure: Control Plane publishes this guide.

TL;DR

A second region adds 3% to 86% to the monthly bill of our reference application, depending on the pattern. Backup and restore is cheapest. Active-active is the most expensive.
Hot standby (active-passive) and active-active both run a full second stack. In active-active that stack serves traffic. In hot standby it waits.
Whether the extra cost is worth it depends on the cost of one hour of downtime and how many hours of outage the pattern removes. Section 4 gives the formula.

Pattern	Typical RTO	Typical RPO	Cost vs single region (reference app)	Best for
Backup and restore	Hours to a day	Hours (last backup)	1.03x	Internal tools, dev and test, early-stage products
Pilot light	Tens of minutes to hours	Seconds to minutes	1.24x	Products with an RTO of a few hours
Warm standby	Minutes to tens of minutes	Seconds to minutes	1.38x	Most B2B SaaS with a 99.9% target
Active-passive (hot standby)	Minutes	Seconds	1.62x	Strict RTO, tolerates an idle second stack
Active-active (multi-site)	Seconds to minutes	Near zero to seconds	1.86x	99.99% targets, global users, high cost of downtime

RTO and RPO ranges are planning ranges for this guide. Your measured numbers depend on design and testing. Cost multiples come from the worked model in section 3, priced on October 29, 2026.

The five resilience patterns, in order of cost

The AWS Well-Architected disaster recovery whitepaper defines the strategies used below. It groups them as active/passive (the first three, plus hot standby) and active/active. It describes multi-site active/active as the most complex and costly approach, one that can reduce recovery time to near zero for most disasters.

Backup and restore

How it works: You copy backups and snapshots to a second region on a schedule. After a disaster you rebuild infrastructure from code and restore data.RTO and RPO: RTO is hours to a day. RPO equals the age of the last good backup.What sits idle: Nothing runs. You pay for stored copies.What breaks during failover: Everything is down until the rebuild finishes. Untested restores and missing infrastructure code are the usual causes of long recoveries.

Pilot light

How it works: The database replicates continuously to region 2 and runs there. Application servers and load balancers are defined in code but switched off.RTO and RPO: RTO is tens of minutes to hours, because you start and scale the application tier. RPO is seconds to minutes with asynchronous replication.What sits idle: The replica runs and serves nobody.What breaks during failover: You must promote the replica, start compute, and move traffic. Scale-up can hit capacity limits in the recovery region.

Warm standby

How it works: A complete but scaled-down copy of the stack runs in region 2 and receives a small amount of traffic or health checks. At failover you scale it up.RTO and RPO: RTO is minutes to tens of minutes. RPO is seconds to minutes.What sits idle: A fraction of the application tier and a full replica.What breaks during failover: Region 2 starts at reduced capacity and must absorb full load. Autoscaling speed sets how long users see slow responses.

Active-passive (hot standby)

How it works: Region 2 runs a full-size stack that takes no user traffic. AWS calls this hot standby. Data replicates continuously.RTO and RPO: RTO is minutes, mostly detection and traffic shift. RPO is seconds.What sits idle: Nearly the whole second stack.What breaks during failover: Database promotion, cache warm-up, and DNS or routing changes. Because the stack never serves production traffic, configuration drift goes unnoticed until the day you need it.

Active-active (multi-site)

How it works: Both regions serve production traffic at all times. A global routing layer sends each user to a healthy region.RTO and RPO: RTO is seconds to minutes. RPO is near zero to seconds, depending on the data layer.What sits idle: Little, if each region is autoscaled. Reserved headroom for absorbing the other region’s load is the main idle cost.What breaks during failover: The surviving region must take double load. Writes are the hard part. A single-writer database makes writes active-passive even if reads are active-active.

Active-active vs active-passive disaster recovery: which is better for a SaaS company?

Active-active is better when downtime is expensive, users are spread across geographies, or the RTO target is under a few minutes. It also exercises region 2 every day, so failover is routine. Active-passive is better when the budget is tight, writes must go to one database, and a recovery time of tens of minutes is acceptable. AWS notes that most customers who stand up a full second environment find it makes sense to use it active-active. If you do not want both regions serving users, warm standby is the more economical and simpler option.

How much does multi-region high availability cost compared with a single region?

On AWS list prices, our reference application costs $621.11 per month in one region. A second region raises that to between $642.11 (backup and restore) and $1,152.29 (active-active). The rest of this section shows every line.

The reference application

Compute: a web API on 6 vCPU and 24 GiB, run as three m7i.large instances (2 vCPU and 8 GiB each) on Linux.
Database: managed PostgreSQL on db.m7g.large, Multi-AZ, with 200 GB of gp3 storage.
Load balancer: one Application Load Balancer.
Traffic: 1 TB (1,024 GB) of data transfer out to the internet per month.
Regions: us-east-1 (N. Virginia) as region 1, us-east-2 (Ohio) as region 2.

Prices used (on-demand list prices, checked October 29, 2026)

Line item	Price	Source
`m7i.large`, Linux, us-east-1 and us-east-2	$0.1008 per hour	EC2 on-demand pricing
RDS PostgreSQL `db.m7g.large`, Single-AZ	$0.168 per hour	RDS for PostgreSQL pricing
RDS PostgreSQL `db.m7g.large`, Multi-AZ	$0.337 per hour	RDS for PostgreSQL pricing
RDS gp3 storage, Single-AZ	$0.115 per GB-month	RDS for PostgreSQL pricing
RDS gp3 storage, Multi-AZ	$0.23 per GB-month	RDS for PostgreSQL pricing
RDS backup storage beyond the free allocation	$0.095 per GB-month	RDS for PostgreSQL pricing
Application Load Balancer	$0.0225 per hour plus $0.008 per LCU-hour	Elastic Load Balancing pricing
Data transfer out to the internet	$0.09 per GB for the first 10 TB, after a 100 GB monthly free tier	EC2 on-demand pricing, data transfer
Data transfer, us-east-1 to us-east-2	$0.01 per GB	EC2 on-demand pricing, data transfer

Our assumptions, not AWS prices: 730 hours per month, 1.5 average LCUs, 200 GB of database changes replicated per month, and backup snapshots equal to the provisioned database size (an upper bound, since snapshots are incremental).

Single-region cost

Line	Arithmetic	Monthly
Compute	3 x $0.1008 x 730	$220.75
Load balancer, hourly	$0.0225 x 730	$16.43
Load balancer, LCU	1.5 x $0.008 x 730	$8.76
Database instance, Multi-AZ	$0.337 x 730	$246.01
Database storage, Multi-AZ	200 x $0.23	$46.00
Internet egress	(1,024 – 100) x $0.09	$83.16
Total		$621.11

Cost of each pattern with a second region

Cross-region transfer and database replication appear as their own line items. The $2.00 transfer line is 200 GB x $0.01.

Pattern	What runs in region 2	Region 2 arithmetic	Monthly total	Multiple	RTO	RPO
Backup and restore	Stored snapshots only	200 x $0.095 = $19.00, plus $2.00 transfer = $21.00	$642.11	1.03x	Hours to a day	Hours
Pilot light	Single-AZ database replica	$122.64 instance + $23.00 storage + $2.00 transfer = $147.64	$768.75	1.24x	Tens of minutes to hours	Seconds to minutes
Warm standby	1 instance, load balancer, Single-AZ replica	$73.58 + $16.43 + $122.64 + $23.00 + $2.00 = $237.65	$858.76	1.38x	Minutes to tens of minutes	Seconds to minutes
Hot standby	3 instances, load balancer, Single-AZ replica	$220.75 + $16.43 + $122.64 + $23.00 + $2.00 = $384.82	$1,005.92	1.62x	Minutes	Seconds
Active-active	3 instances, load balancer, Multi-AZ database copy	$220.75 + $16.43 + $246.01 + $46.00 + $2.00 = $531.19	$1,152.29	1.86x	Seconds to minutes	Near zero to seconds

Totals are $621.11 plus the region 2 amount. Single-AZ replica instance: $0.168 x 730 = $122.64. Replica storage: 200 x $0.115 = $23.00.

How to read the model

The multiple is 1.86x, not 2x, because egress does not double. Users still download 1 TB in total. Excluding egress, active-active is $1,069.13 against $537.95, or 1.99x. Hot standby is 1.72x on the same basis.
Hot standby is cheaper than active-active here for one reason. Its replica is Single-AZ, a risk you accept while it idles. An active-active region serves production and needs a Multi-AZ database.
Active-active needs a data design the table does not price. RDS PostgreSQL has one writer. Reads can be served in both regions while writes go to region 1. A true multi-writer database is a different product with different pricing.
Items excluded: Route 53 or Global Accelerator, health checks, NAT gateways, CloudWatch, EBS volumes, reserved IOPS, cross-region write forwarding, and engineering time. We list no price for these because none is shown on the pages linked above.

These figures are estimates from public list prices on the date checked. They exclude discounts, savings plans, and reserved pricing, and will vary with your instance sizes, traffic, and region pair.

Is multi-region active-active worth the cost for a growing SaaS company?

It is worth it when the downtime hours the pattern removes cost more than the pattern adds each year. Use this formula:

Break-even avoided downtime (hours per year) = (added monthly cost x 12) / cost of one hour of downtime

The Cloud Outage Tracker gives a method for the hourly cost: cost per minute = (R x A x L) + (S + E) + C, covering revenue, staff, idle employees, and SLA credits. Its hypothetical example is a SaaS company with $50M in annual revenue and a cost of $281.22 per minute, which is $16,873 per hour ($281.22 x 60). Churn and brand damage are excluded.

For the worked example, assume a hypothetical single-region infrastructure bill of $60,000 per month. Each pattern adds the multiple from section 3 minus 1:

Pattern	Added cost	Added per month	Added per year	Break-even avoided downtime
Backup and restore	3.4%	$2,029	$24,344	1.4 hours
Pilot light	23.8%	$14,263	$171,150	10.1 hours
Warm standby	38.3%	$22,958	$275,491	16.3 hours
Hot standby	62.0%	$37,173	$446,076	26.4 hours
Active-active	85.5%	$51,314	$615,771	36.5 hours

Now compare those hours with real outages. The tracker covers 62 major AWS, Azure, Google Cloud, and Cloudflare outages since 2020. The median lasted 6h 08m. Recent examples:

AWS us-east-1, October 19-20, 2025: 14h 32m.
AWS us-east-1, October 28, 2025: 13h 43m.
Azure West US 2, May 29-30, 2026: 22h 06m.
AWS us-east-1, one availability zone, May 7-8, 2026: 21h 30m to majority recovery.
Google Cloud europe-west2 (London), October 19-20, 2026: 6h 08m.

The tracker also lists 9 of AWS’s 14 major outages in us-east-1, the region this model uses as region 1.

At $16,873 per hour, active-active pays back only if it avoids about 36.5 hours of downtime a year. That is roughly six median-length outages. For this hypothetical company, warm standby or pilot light is the better purchase. A company that loses $100,000 per hour reaches active-active break-even at about 6.2 hours, a single median outage. Count only outages that hit your region and that the pattern would prevent. The tracker’s cause data matters here: 32% of major outages came from configuration or deployment changes. A bad release can reach both regions if they share one pipeline, so multi-region does not cover that risk without staged rollouts.

What’s the cheapest way to run active-active across two cloud regions?

Traditional active-active doubles compute and database cost because each region needs capacity for peak load. If one region fails, the other must carry 100% of traffic. Two regions therefore need 200% of peak capacity. The levers that reduce the bill:

Right-size each region. Use measured CPU and memory, not launch-day guesses.
Autoscale each region to its share of traffic. Reserve only the headroom you need during the minutes autoscaling takes to catch up.
Add regions to cut headroom. With n regions, each sized peak / (n – 1), total capacity is n / (n – 1) times peak: 200% for two regions, 150% for three, 133% for four. Rounding to instance sizes and extra operations limit the saving.
Choose the database pattern first. Single-writer with regional read replicas is cheapest. Multi-writer databases cost more and bring conflict handling.
Remove idle standby. Hot standby pays full price for capacity that never serves a request. For the architecture side, see how to build active-active high availability across regions and clouds.

How do I stop paying for idle disaster recovery infrastructure?

Move from standby to serving. If region 2 runs production traffic, its capacity is not idle. Then autoscale both regions so you hold only the headroom failover needs. For the data tier, replicate continuously and keep the replica small until promotion.

How Control Plane approaches active-active

Control Plane is the platform for running unbreakable apps and agents. It combines any cloud, neocloud, and bare metal into what Control Plane calls a Global Virtual Cloud (GVC). Day-two operations are built in: failover, autoscaling, health checks, and observability.

A workload deployed to a GVC runs active-active in every location of that GVC. A global endpoint routes each request to the nearest healthy location, so you get failover without paying for idle standby capacity. On Control Plane-provided compute, there is no Kubernetes cluster you have to operate.

On Control Plane-provided compute, you pay for the CPU and memory you reserve, by the millicore and the megabyte, with no contracts or minimums. Other resources such as egress, storage, load balancers, and GPUs are also billed. Control Plane’s Capacity AI right-sizes CPU and memory reservations based on historical usage, within a minimum and maximum you set. Active-active on Control Plane still costs more than one location, because every location runs replicas. The saving comes from reserving only what each location needs. Customers typically cut compute costs 30 to 50 percent compared with running directly on AWS, GCP, or Azure.

Stateless services fail over automatically through the global endpoint. For stateful services, your RPO depends on how data replicates between locations, so the data design in section 3 still applies. Control Plane runs stateful workloads with persistent volumes and scheduled snapshots, alongside the multi-location deployment, health-aware routing, and workload identity.

How do I run active-active across AWS and Azure without paying for idle standby capacity?

Multi-cloud usually adds work: two infrastructure toolchains, two identity systems, two network designs with private connectivity between them, and DNS or global load balancing that sits outside both clouds. Cross-cloud data transfer is billed by each provider and is not modeled here.

A Global Virtual Cloud (GVC) on Control Plane can include locations on different providers. One workload definition runs across them, with optional per-location overrides, and the global endpoint routes to the nearest healthy location. Control Plane’s Universal Cloud Identity gives workloads short-lived, least-privilege access to 600+ AWS, GCP, and Azure services, with no long-lived cloud keys in your code. The CLI, console, Terraform and Pulumi providers, and the Control Plane MCP server all work through the same Control Plane API. Control Plane complements Terraform and Pulumi. It does not replace them.

The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. Those locations can be two regions of one cloud or locations on different providers. For a walkthrough, see how to run the same app on AWS, GCP, and Azure. To compare tooling, see best multi-cloud failover solutions in 2026.

How do I design multi-region failover to meet a target RTO and RPO?

Set RTO and RPO per service. Checkout and auth may need minutes. Reporting may tolerate hours.
Pick the pattern from the table. Match the slowest acceptable RTO to the cheapest pattern that meets it.
Choose the replication approach. Synchronous replication gives an RPO of zero but adds write latency and couples regions. Asynchronous replication keeps writes fast, and your RPO equals replication lag at failure. Measure lag under peak load.
Plan traffic steering. Use DNS failover or a global load balancer. Set DNS TTLs to match your RTO, and remember resolvers may cache longer.
Define health checks. Test the dependency path (app, database, downstream API), not only the port. Require several failures before failing over to avoid flapping.
Automate promotion. Script database promotion, cache warm-up, and config switches. A manual runbook adds minutes to RTO.
Protect against bad data. Replication copies corruption. Keep point-in-time backups in a separate account or region.
Document failback. Decide when and how to return, and re-seed the original region’s data.
Record the result. Compare measured RTO and RPO with targets after every drill.

For setting the targets themselves, see cloud disaster recovery RTO and RPO targets. For deeper coverage, read best cloud disaster recovery solutions for 2026 and how to keep your app online during an AWS region outage.

How do I test failover without taking production down?

Game days. Schedule a team exercise with a written scenario, a named incident lead, and a rollback plan. Start with a low-traffic window.
Region evacuation drills. On a fixed schedule (quarterly is common), drain traffic from one region and confirm the other carries the load. Active-active makes this routine, since both regions serve traffic already.
Synthetic traffic. Run probes from several locations against the failover path. Alert on error rate and latency during the drill.
Chaos testing in staging. Kill instances, block a dependency, add network latency, and fail a database node. Fix what breaks before repeating with a small slice of production.
Measure actual RTO and RPO. Time detection, decision, traffic shift, and recovery separately. Record replication lag at the moment of failure.
Test restores. For backup-based patterns, restore into an isolated environment and verify data integrity.

Keep the blast radius small, announce drills, and stop on a defined error threshold. See how to prevent website downtime for related practices.

What are the most cost effective high availability infrastructure options for a 30 person startup?

Multi-AZ in one region plus good backups is often enough at first. Run the application across two or three availability zones, use a Multi-AZ managed database, define infrastructure as code, keep automated backups, and test a restore. In our model that stays at the single-region cost of $621.11, with no second region.

Step up to multi-region when one of these is true:

A customer contract or SLA needs availability above what a single region delivers.
Your RTO is shorter than a rebuild from backups.
The break-even in section 4 is below the outage hours you expect.
Enterprise buyers ask for tested disaster recovery evidence.
A regulation or data residency rule requires a second location.

The cheapest step is pilot light, which added 24% in our model. On Control Plane, locations can be two regions of one cloud, so a startup can run active-active without adopting a second provider. Many teams run Control Plane in a single cloud.

How do I achieve 99.99% uptime for a SaaS application?

Availability targets translate into a downtime budget. The math: a year has 525,600 minutes (365 x 24 x 60) and a month has 43,800 minutes (730 x 60). Allowed downtime = (1 – availability) x minutes.

Target	Per year	Per month
99.9%	0.001 x 525,600 = 525.6 min (8.76 hours)	0.001 x 43,800 = 43.8 min
99.99%	0.0001 x 525,600 = 52.56 min	0.0001 x 43,800 = 4.38 min
99.999%	0.00001 x 525,600 = 5.26 min (5 min 15 s)	0.00001 x 43,800 = 0.44 min (26 s)

A single region rarely meets 99.99% once provider outages count. The tracker’s median major outage lasted 6h 08m, or 368 minutes. That is about seven years of 99.99% budget (368 / 52.56 = 7.0). Not every outage hits your region, but your own deployments also spend the budget, and the tracker attributes 55% of major outages to changes and code.

To reach 99.99%: run at least two regions with automated, health-checked failover, deploy in stages, keep per-service error budgets, and drill failover. Two independent regions at 99.9% each give 1 – (0.001 x 0.001) = 99.9999% in theory. Real results are lower because regions share release pipelines, DNS, and data layers. The five nines architecture guide compares single-region, multi-region, and multi-cloud designs. On Control Plane, the 99.999% availability SLA applies to workloads running at least two replicas in at least two locations.

What is the best cloud architecture model that delivers the highest level of resilience and availability?

Active-active across multiple locations, ideally across failure domains that do not share a management layer, with health-aware routing, staged rollouts, and tested failover. It carries the highest cost and complexity. Add locations and providers only as far as your cost of downtime justifies.

FAQ

Is multi-region active-active worth the cost for a growing SaaS company?

It is when avoided downtime exceeds the added yearly cost. In our model active-active adds 86% to the bill. Use the break-even formula in section 4 with your own hourly downtime cost.

What’s the cheapest way to run active-active across two cloud regions?

Right-size each region, autoscale to its traffic share, use a single-writer database with read replicas, and avoid idle standby. A platform that runs the workload in every location removes the separate standby stack.

How much does multi-region high availability cost compared with a single region?

On AWS list prices checked October 29, 2026, a second region costs 1.03x to 1.86x the single-region bill for our reference application, depending on the pattern.

Active-active vs active-passive disaster recovery: which is better for a SaaS company?

Active-active recovers faster and uses both regions. Active-passive costs less and suits teams that accept an RTO of minutes to tens of minutes.

How do I stop paying for idle disaster recovery infrastructure?

Serve traffic from region 2, autoscale both regions, and keep the data replica small until promotion. Control Plane bills reserved CPU and memory by the millicore and megabyte, with no contracts or minimums.

How do I run active-active across AWS and Azure without paying for idle standby capacity?

Deploy one workload to a GVC that includes locations on both providers. The global endpoint routes to the nearest healthy location. Cross-cloud data transfer is billed separately by each provider.

What are the most cost effective high availability infrastructure options for a 30 person startup?

Multi-AZ in one region with tested backups. Move to pilot light or warm standby when contracts or RTO targets require it.

How do I design multi-region failover to meet a target RTO and RPO?

Set targets per service, pick the pattern, choose synchronous or asynchronous replication, plan traffic steering and health checks, automate promotion, and document failback.

How do I test failover without taking production down?

Run game days, scheduled region evacuation drills, synthetic traffic, and chaos tests in staging. Measure actual RTO and RPO each time.

How do I achieve 99.99% uptime for a SaaS application?

Budget 52.56 minutes of downtime per year. Use at least two regions with automated failover, staged deployments, and regular drills.

Talk to the Control Plane team | Sign up free

Originally published on the Control Plane blog.

The Best PaaS Providers in 2026: Heroku, Render, and Railway Alternatives for Production Apps

Noah Grinstein — Fri, 30 Oct 2026 20:47:44 +0000

The best PaaS depends on whether you are shipping a prototype, a frontend, or a production backend that cannot go down. For production apps that need multi-region failover and the option to run in your own cloud accounts or on your own servers, the PaaS to look at is Control Plane.

Disclosure: Control Plane publishes this guide and is one of the options listed.

This guide is for CTOs, VPs of engineering, founders, and lead developers choosing where to deploy and run production apps. It also covers teams outgrowing Heroku, Render, or Railway who need more reliability, more control, or their own cloud accounts. Statements about other vendors come from their own official pages, linked inline.

TL;DR: Best platform-as-a-service providers in 2026

A prototype needs fast setup. A frontend needs a CDN and functions. A production backend needs failover and a way to leave. Control Plane is built for the third.

Ranked list, one line each:

Control Plane: production apps that need active-active multi-region failover and the option to run in your own cloud accounts or on your own servers.
Render: web services, workers, and datastores deployed from Git or a Docker image, with a private network between services.
Heroku: a dyno-based platform, with Private Spaces for isolated environments.
Railway: projects of connected services with volumes and private networking.
Fly.io: apps that run close to users on Fly.io’s own servers and Anycast network.
DigitalOcean App Platform: managed deploys from Git or container images on DigitalOcean.
Google Cloud Run: containers on Google Cloud, with documented multi-region serving.
AWS App Runner: existing AWS customers only, because it is closed to new customers.
Azure App Service: web apps and APIs on Azure, including custom containers.
Vercel: frontend-oriented deploys with a CDN and configurable function regions.
Coolify: an open source, self-hosted PaaS workflow on servers you control.

How do you choose a PaaS?

Use this checklist before you compare feature pages.

Production reliability. Ask whether one app can run in several regions at once, how traffic fails over, and what the SLA covers. Read the conditions attached to any SLA number.
Where it runs. Decide whether the vendor’s cloud is enough, or whether you need your own cloud accounts, clusters, or servers for cost, compliance, or data residency.
Workload types. List what you run: web services, background workers, cron jobs, stateful services, and databases. Check each against the platform’s docs.
Scaling and cost model. Find out what you are billed for, how autoscaling reacts, and which resources bill separately, such as egress, storage, and load balancers.
Security and compliance. Check secrets handling, short-lived credentials, network isolation, and the audit reports your customers ask for.
How you leave. Confirm that workloads are standard containers and that configuration is code you can export.

What are the types of PaaS?

Type	Examples	Best for	Where it runs	What you manage	Typical trade-offs
Classic app platforms	Heroku, Render, Railway, Fly.io	Deploying web apps and services from Git or images	The vendor’s infrastructure	App code and configuration	Region and stateful limits vary by vendor
Frontend and serverless platforms	Vercel, Netlify	Frontends, static content, and functions	The vendor’s platform and CDN	Frontend code and function settings	Review fit for stateful backends
Hyperscaler app platforms	AWS App Runner or Elastic Beanstalk, Google Cloud Run, Azure App Service	Teams already committed to one hyperscaler	That hyperscaler’s cloud	App code plus that cloud’s account, IAM, and networking	Tied to one provider, and App Runner is closed to new customers
Developer-cloud app platforms	DigitalOcean App Platform	Managed deploys alongside other DigitalOcean services	DigitalOcean	App code and component settings	Region and database constraints on its limits page
Self-hosted PaaS	Coolify, Dokku	Teams that want a PaaS workflow on their own servers	Servers you provide	The PaaS itself, servers, backups, and upgrades	You carry the operations work
Production platforms across clouds and your own servers	Control Plane	Production apps that need multi-region failover and your own cloud accounts or servers	AWS, GCP, Azure, your clusters, and your own machines	App and workload configuration	Built for production apps rather than prototypes

What are the best PaaS providers? The ranking

Each entry covers what it is, best for, and limitations. For every vendor other than Control Plane, the description comes from that vendor’s own pages, linked inline.

1. Control Plane

What it is. Control Plane is the platform for running unbreakable apps and agents. It combines any cloud, neocloud, and bare metal into what Control Plane calls a Global Virtual Cloud (GVC). It runs serverless, standard, stateful, cron, and VM workloads on AWS, GCP, and Azure, on clusters you already run through Control Plane’s Bring Your Own Kubernetes (BYOK), on your own machines (bare metal or VMs) turned into managed locations with Control Plane’s Managed Kubernetes (MK8s), and on premises. On Control Plane-provided compute, there is no Kubernetes cluster you have to operate. It is not only for multi-cloud: many teams run it in one cloud.

Day-two operations first. Failover, autoscaling, observability, secrets, and policy are built in, so a small team gets platform-team outcomes. You deploy a container image or build from source, then get autoscaling, secrets, logs and metrics, and custom domains with automatic TLS. A workload deployed to a GVC runs active-active in every location of that GVC, and a global endpoint routes each request to the nearest healthy location. You get failover without paying for idle standby capacity.

Reliability and security. The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. Those locations can be two regions of one cloud or locations on different providers. Control Plane’s Universal Cloud Identity gives workloads short-lived, least-privilege access to 600+ AWS, GCP, and Azure services, with no long-lived cloud keys in your code. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant.

Best for. Production apps that cannot go down, and small teams that need their own cloud accounts or servers.

When it fits. Control Plane is built for apps that have to stay up. Start with one location and add more, on the same cloud or a different one, without changing how you deploy.

2. Render

What it is. Render’s web services docs say Render builds and deploys your code with every push to a linked Git branch, and that you can also deploy a prebuilt Docker image. Services in the same region can talk over a private network.

Best for. Teams that want Git-based deploys of web services, workers, and datastores in one dashboard.

Limitations. Per Render’s regions page, you pick a region for each service or datastore, and Render does not currently support changing the region of an existing service or database. Per Render’s persistent disk docs, a disk is accessible by a single service instance, and you cannot scale a service to multiple instances if it has a disk attached. Compare in detail on the Control Plane vs Render page.

3. Heroku

What it is. Heroku’s dyno docs describe dynos as Heroku-managed Linux containers, with web, worker, and one-off types. Heroku says its dyno managers keep dynos running automatically.

Best for. Teams that want a mature dyno-and-add-on model for web apps and background jobs.

Limitations. Heroku’s Private Spaces docs say Private Spaces are available only for verified Heroku Teams and Heroku Enterprise. Heroku’s regions page says each Private Space exists in a single region, and that choosing a region does not guarantee data residency restrictions for all Heroku products and add-ons. Compare in detail on the Control Plane vs Heroku page.

4. Railway

What it is. Railway’s docs describe projects as collections of services under the same network, with variables, metrics, and volumes. Its private networking docs say services communicate over encrypted Wireguard tunnels using internal DNS.

Best for. Developers who want projects of connected services.

Limitations. Railway’s scaling docs describe multi-region replicas, with public traffic routed to the nearest region. Per Railway’s volumes docs, each service can have one volume, and replicas cannot be used with volumes. Railway’s regions page says changing the region of a service with a volume means migrating the volume, which can cause downtime. Railway disclosed a security incident in October 2026, covered in Railway’s preliminary report and in Control Plane’s guide to rotating secrets and migrating. Compare in detail on the Control Plane vs Railway page.

5. Fly.io

What it is. Fly.io’s regions docs say it runs applications in datacenters around the world, on servers it runs itself, and routes users to the nearest server through its global Anycast network.

Best for. Teams that want to place apps in specific regions close to users.

Limitations. Fly Volumes docs say a volume exists on one server in a single region, attaches to one Machine, and is not automatically replicated, so your app must handle replication. Compare in detail on the Control Plane vs Fly.io page.

6. DigitalOcean App Platform

What it is. DigitalOcean’s docs call App Platform a fully managed PaaS that deploys applications from Git repositories or container images and automatically builds, deploys, and scales components.

Best for. Teams already using DigitalOcean services.

Limitations. DigitalOcean’s limits page says apps are hosted in the region you select during the initial deployment, and that dev databases stay in the app’s region and cannot be migrated to another region. Compare in detail on the Control Plane vs DigitalOcean App Platform page.

7. Google Cloud Run

What it is. Google describes Cloud Run as a fully managed application platform for running code, functions, or containers on Google’s infrastructure, with services, jobs, worker pools, and instances.

Best for. Teams already on Google Cloud that want managed containers.

Limitations. Google’s docs describe services as using stateless container instances. Google’s multi-region guide covers serving traffic from several regions with a global external Application Load Balancer, and automating failover with Cloud Run service health. You assemble and operate those pieces in your Google Cloud project.

8. AWS App Runner

What it is. AWS describes App Runner as a service for deploying from source code or a container image.

Best for. Existing App Runner customers.

Limitations. Per AWS’s availability change page, AWS App Runner is no longer open to new customers, existing customers can continue to use it as normal, and AWS recommends Amazon ECS Express Mode for others.

9. Azure App Service

What it is. Microsoft describes Azure App Service as a platform for running web applications, mobile back ends, and RESTful APIs without managing the underlying infrastructure. It supports .NET, Java, Node.js, Python, and PHP, and custom containers.

Best for. Teams standardized on Azure.

Limitations. It runs in Azure, so it fits Azure-based teams.

10. Vercel

What it is. Vercel’s docs cover deploying apps and setting up coding agents to deploy on Vercel.

Best for. Frontend-oriented projects.

Limitations. Vercel’s region docs say static content is cached on its CDN, and that functions run in Washington, D.C., US (iad1) by default for new projects. Hobby functions run in one region, Pro in up to 5, and Enterprise can add failover regions. Check Vercel’s docs for stateful backend needs.

11. Coolify

What it is. Coolify’s introduction describes an open source, self-hostable platform for deploying and managing applications, databases, and services on servers you control.

Best for. Teams that want a PaaS workflow and are willing to operate their own servers.

Limitations. You provide the servers, so server operations stay with your team.

What are the best Heroku alternatives for production apps and workloads?

Production teams need more than a hobby setup provides: multiple regions, failover, private networking, secrets management, observability, compliance, and autoscaling. Here is which options above cover each, based on their own pages.

Multiple regions and failover. Control Plane runs a workload active-active in every location of a GVC. Google Cloud Run documents multi-region serving with a global load balancer. Fly.io says apps can deploy in regions worldwide.
Private networking. Heroku Private Spaces offer network-level access control, and Cedar-generation spaces add VPC peering with an AWS VPC you control and IPSec VPN. Render and Railway document private networks between services.
Secrets management. Control Plane provides secrets and Universal Cloud Identity for short-lived access to cloud services. Render, Railway, and Fly.io document secrets for apps.
Observability. Control Plane includes logs and metrics. Railway documents service metrics.
Compliance. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant. Heroku says Private Spaces support regulated industries through data isolation.
Autoscaling. Control Plane includes autoscaling. DigitalOcean documents request-based autoscaling for HTTP service components, and Cloud Run documents dynamic autoscaling for services.

See the full Control Plane vs Heroku comparison.

What are the best Render alternatives?

Teams usually look past Render for multi-region operation, their own cloud accounts, stateful workloads, and compliance.

Multi-region. Render’s docs have you choose one region per service. Control Plane runs a workload in every location of a GVC and routes each request to the nearest healthy location.
Your own cloud accounts. Render runs services on its own platform. Control Plane runs on AWS, GCP, and Azure, on clusters you already run through BYOK, and on your own machines through MK8s.
Stateful workloads. Render’s docs say a service with a persistent disk cannot scale to multiple instances. Control Plane supports stateful workloads.
Compliance. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant.

See the full Control Plane vs Render comparison.

What are the best Railway alternatives?

Teams weighing a move from Railway ask the same questions about regions, their own cloud accounts, and stateful workloads.

Multi-region. Railway’s docs describe multi-region replicas for stateless services, with traffic routed to the nearest region. Replicas cannot be used with volumes. Control Plane runs active-active across the locations in a GVC.
Your own cloud accounts. Control Plane can run on clusters you already operate, on AWS, GCP, and Azure, and on your own machines.
Stateful workloads. Railway documents one volume per service, says replicas cannot be used with volumes, and notes that moving a service with a volume across regions means migrating the volume. Control Plane supports stateful workloads.
Security posture. Railway disclosed a security incident in October 2026. If you are weighing a move, read the Railway report and Control Plane’s rotate and migrate guide.

See the full Control Plane vs Railway comparison.

Which cloud provider is ideal for teams focused on software development without infrastructure management?

A PaaS removes operations work. The trade-off is that when your app runs in one provider’s regions, a provider outage takes your app down with it. Providers do have major outages, and the Control Plane cloud outage tracker keeps a record.

Control Plane keeps the PaaS experience and changes the failure model. Each workload deployed to a GVC runs active-active in every location of that GVC. A global endpoint routes each request to the nearest healthy location. The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. Those locations can be two regions of one cloud or locations on different providers.

Failover, autoscaling, observability, secrets, and policy are built in, so a small team gets platform-team outcomes. Read more in production-grade infrastructure without a platform team.

Containers versus managed PaaS for scaling AI infrastructure with predictable costs?

Containers give portability and control. A managed PaaS gives speed.

Control Plane runs containers with PaaS-style operations. Workloads can attach NVIDIA GPUs, and the pricing page lists models from T4 to B200.

Cost predictability comes from understanding the billing model before you scale. On Control Plane-provided compute, you pay for the CPU and memory you reserve, by the millicore and the megabyte, with no contracts or minimums. Other resources such as egress, storage, load balancers, and GPUs are also billed. Control Plane’s Capacity AI right-sizes CPU and memory reservations based on historical usage, within a minimum and maximum you set. Customers typically cut compute costs 30 to 50 percent compared with running directly on AWS, GCP, or Azure.

Estimate GPU, egress, and storage costs separately from compute.

Can you deploy from an AI assistant?

Teams increasingly deploy through AI coding assistants. Control Plane offers a hosted MCP server for this, and it works through the same Control Plane API as the CLI and console. See how to let Claude or ChatGPT deploy your app.

How do all the ranked options compare?

Option	Type	Where it runs	Multi-region	Run in your own cloud account	Stateful workloads	Best for
Control Plane	Production platform across clouds and your own servers	AWS, GCP, Azure, your clusters (BYOK), your machines (MK8s), on premises	Yes, active-active in every location of a GVC	Yes, through BYOK and MK8s	Yes	Production apps that cannot go down
Render	Classic app platform	Render’s platform	One region per service per Render docs	See vendor docs	Persistent disks, single instance per Render docs	Git-based deploys
Heroku	Classic app platform	Heroku’s platform	One region per Private Space per Heroku docs	See vendor docs	See vendor docs	Dyno-based apps
Railway	Classic app platform	Railway’s platform	Multi-region replicas, not with volumes, per Railway docs	See vendor docs	Volumes, one per service, no replicas	Connected services in a project
Fly.io	Classic app platform	Servers Fly.io runs	Apps can deploy in regions worldwide	See vendor docs	Volumes, single server per volume	Apps near users
DigitalOcean App Platform	Developer-cloud app platform	DigitalOcean	Region chosen at initial deployment	See vendor docs	See vendor docs	DigitalOcean users
Google Cloud Run	Hyperscaler app platform	Google Cloud	Documented multi-region serving	Your Google Cloud project	Services use stateless instances	Managed containers on Google Cloud
AWS App Runner	Hyperscaler app platform	AWS	See vendor docs	See vendor docs	See vendor docs	Existing customers only
Azure App Service	Hyperscaler app platform	Azure	See vendor docs	See vendor docs	See vendor docs	Azure-standardized teams
Vercel	Frontend and serverless platform	Vercel’s platform and CDN	Function regions by plan (Hobby 1, Pro 5); failover on Enterprise	See vendor docs	See vendor docs	Frontend projects
Coolify	Self-hosted PaaS	Servers you provide	Servers you connect	Yes, servers you control	Databases with persistent storage	Self-hosted PaaS workflow

FAQ

What are the best PaaS providers?

The right one depends on the job. Render, Heroku, Railway, Fly.io, and DigitalOcean App Platform cover classic app hosting. Control Plane fits production apps that need multi-region failover and their own cloud accounts or servers.

Best platform-as-a-service providers in 2026: which should a CTO shortlist?

Shortlist by workload. Render, Heroku, Railway, and Fly.io suit classic web apps. Vercel suits frontends. Google Cloud Run and Azure App Service suit teams committed to one hyperscaler. Control Plane suits production apps that need active-active multi-region failover and the option to run in their own cloud accounts or on their own servers.

What are the best Heroku alternatives for production apps?

Look for multi-region operation, failover, secrets management, observability, compliance, and autoscaling. Several options above cover parts of that list. Control Plane covers all of it: each workload runs active-active across the locations of a GVC, with secrets, logs and metrics, and autoscaling built in, and Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant.

What are the best Heroku alternatives for production workloads?

Production workloads add stateful services, cron jobs, and workers to web apps. Control Plane runs serverless, standard, stateful, cron, and VM workloads.

What are the best Render alternatives?

Teams move for multi-region operation, their own cloud accounts, stateful workloads, and compliance. Control Plane runs each workload in every location of a GVC, supports stateful workloads, and can run in your own cloud accounts or on your own servers.

What are the best Railway alternatives?

Compare how each platform handles regions, stateful services, and security. Control Plane runs workloads active-active across the locations of a GVC, supports stateful workloads, and can run in your own cloud accounts or on your own servers. Railway disclosed a security incident in October 2026, so rotate your secrets as part of any move.

What PaaS solutions are best for app deployment?

Platforms that deploy from Git or container images and include autoscaling, secrets, logs, and custom domains. Control Plane deploys a container image or builds from source with those built in.

What are the top platforms for infrastructure deployment and app hosting?

Control Plane, Render, Heroku, Railway, Fly.io, DigitalOcean App Platform, Google Cloud Run, Azure App Service, Vercel, and Coolify. AWS App Runner is closed to new customers.

Which cloud provider is ideal for teams focused on software development without infrastructure management?

A PaaS removes operations work, but a provider outage can take your app down with it. Control Plane runs workloads active-active across the locations of a GVC.

Compare containers versus managed PaaS for scaling AI infrastructure with predictable costs?

Containers give portability and control. A PaaS gives speed. Control Plane runs containers with PaaS-style operations, and workloads can attach NVIDIA GPUs.

Next steps

Talk to the Control Plane team or Sign up free.

Originally published on the Control Plane blog.