Spot Without Bidding: What Smooth Pricing Means for Real Workloads

On November 14, AWS retired the EC2 Spot auction. The announcement was understated, three paragraphs and a small diagram, and it was easy to scroll past. It shouldn't have been. For anyone who has spent the last few years writing bid-prediction code, tuning max-price ceilings, or apologizing to a product manager for a Spot price spike that ate a batch job, this is the largest behavioral change Spot has seen since it launched in 2009.

Three weeks in, the picture is clearer. The parts of the Spot runbook that were operationally noisy got quieter. The parts that were always the hard work, capacity engineering and interruption handling, didn't move. There's also a non-trivial amount of Xosphere code that used to earn its keep against the old model and now sits there mostly inert. We'll get to that.

What the auction actually was

It's worth being precise about what got removed, because the marketing language ("smooth pricing") doesn't quite capture it.

Before November 14, every Spot purchase went through an auction. You submitted a request with a maximum price. AWS published a current Spot price per instance type per Availability Zone. You always paid the current Spot price, not your bid: the bid was a ceiling, not what you were charged. If the current price rose past your ceiling, you got a two-minute warning and the instance went away.

That second mechanic mattered more than people remember. Capacity has always been the binding constraint on Spot. When AWS needs to reclaim capacity for an On-Demand or Reserved customer, somebody has to give up an instance. Under the auction, AWS picked the victims by bid: the lowest bidders got terminated first. The price-as-victim-selector was the entire point of the bidding mechanic. Capacity flowed to whoever was willing to set the highest ceiling on their bid.

That was the loophole. A large customer who really wanted to hold a pool could bid five or ten times the On-Demand rate and effectively guarantee they would never be the one terminated. They still paid the current Spot price, not their absurd bid, so the bid cost them nothing. Smaller customers running lean against an On-Demand-rate ceiling got displaced first. The market was technically open and practically gameable. AWS knew this; the bid prediction tooling published over the years was an attempt to make a fundamentally noisy mechanism feel manageable. It didn't really work.

So the operational problem with the old model wasn't that instances got reclaimed: capacity reclaims still happen and still need to. The problem was that the selection of who got reclaimed was a function of who had the deepest pockets. A c4.8xlarge in us-east-1c would disappear out from under your batch job because someone else's bid was higher than yours. There was no pattern you could plan around because the pattern was someone else's bidding strategy, not yours.

What replaced it

Two things changed at once, and they are easy to conflate.

The first is pricing. Spot prices now move gradually, in step changes that reflect longer-term supply and demand rather than minute-by-minute auction state. The cap is the On-Demand rate. The SpotPrice field in the API still exists and still defaults to On-Demand, but there is essentially no reason to tune it down.

The second is victim selection during capacity reclaim. AWS still reclaims Spot capacity when it needs it for On-Demand customers, Reserved customers, or maintenance. That part of the system is unchanged. What changed is how AWS picks which instances to terminate. The bid-as-proxy mechanism is gone. Selection is now random within the pool. The customer bidding On-Demand and the customer who hasn't touched their max-price field since 2015 have the same odds of being the one reclaimed. This democratizes the market in the most literal sense: the loophole that let bigger customers hold capacity at smaller customers' expense is closed.

The two-minute warning is unchanged.

Mechanically, here is what the same c4.4xlarge pool looks like before and after, sketched from the price histories we were looking at this week:

Spot price shape, c4.4xlarge us-east-1a (illustrative) 0102030405060 Day 1009080706050403020100 Price (% of On-Demand)

The shape change isn't the savings story. Savings is savings. A workload that ran for $0.30/hour on average before still runs for roughly $0.30/hour on average now. What the shape change buys you is forecastability.

What practitioners can actually do now that they couldn't

Two things become easier.

First, cost forecasting that holds up in a finance review. Under the auction, a Spot price forecast was a guess wrapped in a prayer. You could report a trailing 30-day average and watch finance refuse to plan against it because the variance was 4x the mean. Now the same series is flat for weeks. A unit-cost-per-job number for a batch pipeline is something you can stand behind. That doesn't change the average savings, but it changes the conversation. Teams that shelved Spot adoption because they couldn't underwrite the variance to their CFO have one fewer reason to wait.

Second, the bid knob disappears from your runbook. This sounds small. It isn't. We've audited customer Spot Fleet configurations where the bid strategy had three different rules, two of them written in 2015 and nobody on the current team remembers why. All of that is now dead code. Set the max to On-Demand (which is the default) and never think about it again.

What changes in your configuration

The IaC simplifications are real, and most of them are deletions.

• Max-price ceilings. Remove them, or leave them at On-Demand. If you have automation that adjusts them, retire it. The bid is no longer a lever.
• Bid strategy logic in Spot Fleet. Spot Fleet still supports two allocation strategies, lowestPrice and diversified. The difference between them used to compound with bid noise. Now the choice is simpler: diversified for production fleets that care about interruption tolerance, lowestPrice for very short-lived workloads where the difference doesn't matter. The reasoning that used to require a spreadsheet is now a one-line decision.
• Anti-spike replacement. Any tooling that watched Spot price history and pre-emptively moved workloads off a pool because the price was climbing can be retired. The price doesn't climb that way anymore. Capacity-driven reclaim doesn't telegraph itself in the price feed.
• Bid prediction. If you wrote a model that predicted next-hour Spot prices to inform placement, the model's inputs are now flat. The signal is gone because the noise is gone.

What you do not retire:

• Diversification. Each (instance type, AZ) is still a separate pool, and capacity reclaim still happens at the pool level. A fleet that accepts one type in one AZ is still one outage away from a bad afternoon.
• Interruption handling. Two-minute notice is unchanged. Drain logic, replacement-instance launch, load balancer deregistration, in-flight request completion: all of it still needs to work.
• Instance selection. Pool depth, generation tradeoffs, family fit to workload: none of that got easier. If anything, with the price signal gone, you have to lean harder on the capacity signal that's left.

Where the work moved to

This is the substantive change for anyone running Spot at scale: the operator's problem shifted from price engineering to capacity engineering.

In the old world, two variables had to be managed: price (volatile, controllable via bid) and capacity (volatile, partially controllable via diversification). Most teams put the majority of their attention on price because the spikes were dramatic and visible. Capacity work, the unglamorous business of accepting more instance types and spreading across more AZs, often got under-invested.

In the new world, price is no longer a variable you manage. Capacity is the only variable left. That sounds like a simplification. It is, but only in the sense that you no longer have an excuse to ignore the harder of the two.

The two boxes on the right of the new-operator side (interruption handling and capacity-aware selection) are where the real engineering effort lives now. The old box that used to consume operator attention (price tuning) is gone.

Honest read on what this means for Xosphere

A small slice of what Xosphere did under the old model is now redundant. The bid-related code paths in particular:

• Anti-spike replacement is inert. The feature watched Spot price history and preemptively moved a workload off a pool when the price was climbing toward our customer's max-price ceiling, before the termination signal fired. Under smooth pricing the price doesn't climb that way and the cap holds, so the watcher has nothing to react to. The code still runs; it just doesn't do much.
• Bid-prediction inputs are flat. We had a small model that predicted next-hour Spot prices in a pool to inform placement. Its inputs are now smooth lines. The signal is gone because the noise is gone.

That's it. The rest of the product is unchanged, because the rest of the product was never about price tuning. The value is and was capacity engineering and interruption handling. Smooth pricing changes the mechanics of one input we used to read. It does not change the orchestration work that sits on top of it.

What didn't move, and where Xosphere still earns its place:

• Diversification across pools. AWS doesn't help you here. Spot Fleet's allocation strategies are blunt. They don't continuously evaluate pool depth, they don't expand the accepted instance-type set when a pool thins out, and they don't fall back to On-Demand on a pool-by-pool basis. We do all of that.
• Two-minute notice handling across heterogeneous fleets. A drain that works for an EC2 instance behind an ELB looks nothing like a drain for an instance running inside an ECS task. Coordinating both, plus standalone instances and ASG members, plus whatever container scheduler is on top, is non-trivial. AWS gives you the notice. We turn the notice into a graceful handoff.
• Coordinated drain plus relaunch across ASGs and standalone instances. When an interruption fires on an instance that's part of an ASG, the ASG's own replacement loop will start a new instance, which may also be Spot, which may also be in a degrading pool. Orchestrating that flow so the replacement actually lands somewhere durable is work the ASG doesn't do for you.
• Instance-type selection that accounts for pool depth dynamics. Choosing c4.4xlarge over c5.4xlarge in a specific AZ on a Tuesday afternoon because the c4 pool has more headroom is the kind of decision that requires continuous data, not a launch-time config. Static Spot Fleet config can't do this.

The way we describe it internally now: smooth pricing makes Spot predictable. Orchestration is still what makes it production-ready.

Where the responsibility line sits now

A cleaner mental model than we had before the change:

AWS now owns the part of the system that used to surprise operators (the price). Operators still own the part that's specific to their workload (interruption tolerance, instance choice, replacement behavior). Orchestration sits between them, turning AWS signals into operator-grade behavior. The lines are easier to draw than they were a month ago.

What to do this quarter

If you operate Spot today, here's the short list we've been giving customers since November 14:

1. Delete the bid logic. Whatever you wrote, decide whether it's still needed (almost certainly not) and remove it. Smaller config is better config.
2. Re-evaluate workloads you previously ruled out for forecastability reasons. Anything you skipped because the price variance made the budget conversation impossible is worth a fresh look. The underlying savings math didn't change, but it is much easier to underwrite now.
3. Audit your diversification. A fleet that accepts three sizes from one family across one AZ was always a bad bet. Under the old model, the price spikes made it visibly bad. Under the new model, the badness is silent until a capacity event. Pull up your Spot Fleet or ASG configs and count the distinct (type, AZ) combinations they accept. If the number is below ten, you have work to do.
4. Test your drain. The change didn't make the two-minute notice friendlier. If your service drops requests on the floor when an instance is reclaimed, that's still a production problem; it's just now the only Spot-related production problem you have.

If you don't operate Spot today, one specific objection just lost its teeth. "The cost is too unpredictable to plan around" is no longer true. The remaining reasons not to run Spot are real, but they're engineering problems with known solutions: interruption handling, drain, replacement, diversification. Not market problems.

The change underneath the change

Stepping back: AWS has spent the last few years quietly reshaping Spot from a market into a discount. Spot Fleet's allocation strategies in 2015, the growing emphasis on diversified placement in their guidance, the gradual softening of "bidding" language in favor of "maximum price you're willing to pay." Smooth pricing is the largest single step in that direction, but it's not the first. The trajectory is clear. Spot is becoming a product that looks more like Reserved Instances with interruption risk than like a real-time market.

That's good for the audience that wants to run Spot at scale. It's not actually a threat to anyone whose product was built around making Spot work, including ours, because the value of orchestrating Spot was never the bid. The bid was a small input. The work was always capacity diversification, interruption handling, and instance selection. Smooth pricing changes one input and leaves the rest in place. The product we shipped a month ago and the product we ship next month do the same things; the noise floor on one of the inputs is just lower. Worth saying, because the temptation to misread "AWS simplified pricing" as "AWS solved Spot" is real, and it would lead a few teams to the wrong conclusion.