Spot instance CI cost in 2026: how to get 70% off self-hosted runners

Spot instances are cloud computing's overlooked cost lever. AWS, GCP, and Azure all sell unused capacity at 60-90% off on-demand prices, with the catch that they can reclaim the capacity with 1-2 minutes notice. CI workloads are uniquely well-suited to spot because they are interrupt-tolerant by design: the orchestration layer (GitHub Actions, GitLab) detects a dropped runner and retries the job. This page covers the per-cloud spot pricing, the integration patterns for CI runner pools, and the few job categories that should stay on on-demand.

AWS Spot pricing (2026 typical)

Spot prices are dynamic, regional, and AZ-specific. The numbers below are typical mid-2026 us-east-1 averages from the AWS Spot pricing page. Always check live pricing before committing to a particular instance family.

Interruption rates and instance selection

AWS publishes per-family interruption rates in the Spot Instance Advisor. Common families in 2026 typical us-east-1: c5/c6i 5-10% per month, m5/m6i 3-7%, c7g Graviton 2-5%, t3 family lower interruption due to lower demand for burstable compute. Larger instances within a family typically interrupt more often than smaller because the AWS reclaim algorithm prefers larger blocks of capacity.

For CI runner pools, the goal is to choose families with under 10% interruption rate. The cost of an interruption is the wasted partial compute plus the wait-time of the retry. At 5% interruption rate and 30-minute average build time, the average wasted compute is 5% x 15 minutes (assuming interruption mid-way) = 0.75 minutes per build, which is small. At 25% interruption rate the wasted compute exceeds the spot discount and on-demand becomes cheaper; this is rare for CI-suited families.

The retry-on-interrupt pattern

Ephemeral runner architectures (which we covered on the ephemeral runner cost page) handle spot interruption naturally. When a spot instance is reclaimed, the runner pod is killed. GitHub Actions or GitLab CI detects the runner disconnect, marks the job as failed with a retryable status, and queues a retry. The retry lands on a new pod on a new node, which may also be spot.

The integration glue: configure the workflow to retry on runner disconnect specifically (not on test failure). GitHub Actions: continue-on-error: false with retry annotations on the job, plus a workflow-level retry policy that distinguishes runner-loss from test-loss. GitLab CI: retry: { max: 2, when: runner_system_failure }. CircleCI: similar conditional retry semantics in the workflow definition.

Most teams set this up once on the runner controller and forget about it. The interruption rate is low enough that the retry cost is below 5% of total compute, well within the spot discount.

Karpenter spot-first node provisioning

The cleanest spot integration on Kubernetes is Karpenter with a node-pool configuration that prefers spot capacity and falls back to on-demand on spot exhaustion. Karpenter checks current spot pricing per AZ per family, picks the cheapest available combination, and provisions. When the spot capacity is reclaimed, Karpenter re-provisions on a different family or AZ.

Sample Karpenter NodePool configuration concept: capacity-type values [spot, on-demand], instance families restricted to low-interruption-rate sets, and a weight that prefers spot. Karpenter docs on node pools have current syntax.

Worked example: 50-dev team on spot

A 50-dev team running 50,000 build minutes/month (833 hours of compute) on m5.xlarge on-demand: 833 x $0.192 = $160/month. Same workload on spot at $0.058/hour: $48/month. Saving $112/month, or roughly $1,344/year on this single instance family.

Add a margin for retries: assume 5% interruption rate, 50% of interrupted jobs land on a worst-case 25% wasted compute. Effective overhead: 5% x 25% = 1.25%. Total spot cost: $48 x 1.0125 = $48.60. Saving still $111/month.

Scale this across a typical self-hosted CI runner pool with multiple instance families and the saving compounds. A team paying $800/month in self-hosted compute can typically reduce that to $250-300/month on a well-configured spot-first Karpenter setup, saving $500/month or $6,000/year. The setup cost is a few days of platform-engineering time. Payback measured in weeks.

When to keep workloads on on-demand

Three categories deserve on-demand. Release builds: a build that must complete before a release ceremony cannot tolerate retry latency. Pin these to on-demand or use a dedicated reserved-instance pool. Long-running integration tests (over 30 minutes): the probability of interruption rises with duration. A 60-minute test that interrupts at minute 50 wastes 50 minutes of compute, which often exceeds the spot saving. Jobs with non-idempotent side effects: deploy jobs that mutate production state, jobs that interact with paid third-party APIs, anything where re-running has cost beyond the compute. Run these on stable on-demand and accept the higher per-hour cost as insurance.

The hybrid pattern: a small on-demand pool for the high-stakes jobs, a larger spot pool for the bulk of PR-check workload. Most teams find 80-90% of CI minutes can safely live on spot, with the remaining 10-20% needing on-demand for reliability or speed reasons. The aggregate saving is still substantial.

Frequently Asked Questions