Spot capacity can be up to 90% cheaper on AWS and up to 91% off on Google Cloud. Automate safe workload relocation with Kubernetes. Full breakdown.
What multi-cloud arbitrage actually means
Multi-cloud arbitrage is the practice of placing interruptible workloads where spare capacity is cheapest at the moment, then moving them when that advantage disappears. Spot capacity is the usual lever: the summary figures of up to 90% cheaper on AWS and up to 91% off on Google Cloud show how large the gap versus on-demand can be. Those discounts are not guaranteed forever, and they apply only to capacity that can be reclaimed with little notice. The 40% infrastructure savings target in the title is a portfolio outcome—what you keep after you account for interrupted jobs, data movement, and the control plane that decides where work runs—not a promise that every node will sit at the deepest discount all day.
Arbitrage only works when you treat price as a first-class input to scheduling. Fixed multi-year commitments, single-region lock-in, and stateful services that cannot leave a zone all shrink the set of jobs you can safely shop around. Start by classifying workloads: batch, CI, training, and other restartable pipelines are natural candidates; latency-sensitive frontends and tightly coupled databases usually are not until you redesign for mobility.
Spot economics without the spreadsheet fiction
Spot pricing reflects spare supply. When a region fills up, reclaim rates rise and effective cost climbs even if the listed discount still looks attractive. Compare providers on total cost of a completed job—not headline list discounts alone. Include cross-cloud egress, image pull time, cold start of caches, and human or automated time spent recovering from interruption. A job that is “cheaper per hour” but finishes late or restarts often can erase the savings you thought you bought.
Use the named discounts as ceilings, not baselines. Design budgets around a blended rate: some capacity on-demand or reserved for the control plane and sticky services, the rest on spot across two or more clouds when prices and reclaim risk look favorable. Revisit the blend when utilization patterns change; arbitrage is an ongoing process, not a one-time purchase.
Safe relocation with Kubernetes
Kubernetes is the practical control surface for this pattern because it already separates desired state from where pods land. To relocate safely, make workloads interruptible by design: checkpoint or checkpoint-friendly jobs, retries with backoff, and no single pod holding irreplaceable local state. Prefer multi-cluster or multi-cloud federation patterns so you can drain a cluster or node pool when prices spike or capacity vanishes, without rewriting application code for each cloud’s VM API.
- Label and taint node pools by provider, region, and capacity type so schedulers and operators know what is disposable.
- Use disruption budgets and graceful termination so reclaim events finish in-flight work or hand off cleanly.
- Keep container images, secrets, and config in a form that can start on either cloud without manual steps.
- Automate scale-up on the cheaper side and scale-down on the expensive side from the same policy engine, with hard floors for minimum healthy capacity.
Automation should fail closed: if pricing feeds drop, identity breaks, or network paths between clouds are unhealthy, keep running where you already are instead of thrashing. Log every move with cost and failure reason so you can prove the 40% path is real and tune which jobs stay eligible.
A practical rollout order
Begin with one non-critical, restartable workload and one secondary cloud or region. Instrument cost per successful run and interruption rate before expanding. Add a second candidate only when relocation is boring—predictable drain times, no secret or registry surprises, and operators who trust the automation. Expand the eligible set until the portfolio approaches the savings range the title implies, then stop pushing stateful or user-facing systems into spot just to chase the last percentage point.
Multi-cloud arbitrage is not about living entirely on the deepest spot discount. It is about systematically putting the right work on spare capacity, moving it with Kubernetes when that capacity is no longer the best deal, and measuring savings after interruptions and data movement—not before.