| I built SpotVortex for a simple reason: most teams want more Spot savings, but they do not want to compromise service safety to get them. SpotVortex runs inside the cluster and controls Spot at the node-pool level. It watches market risk and pool health, then decides when a pool should grow, spot, hold, freeze, or move back toward On-Demand. A few concrete details about the shipped runtime: * The deterministic mode is the active path
* The control cadence is 10 minutes
* Decisions stay at the node-pool level, not the pod level
* Workload data stays in-cluster. The controller also looks at pool blast radius, not just price. It tracks things like: * PDB Slack under node loss
* How much critical workload is sitting on the Spot restart and recovery time
* Stateful workload mix
* zone spread
* evictability
* available On-Demand headroom
* Current AWS support is explicit. The shipped model scope covers 60 instance families across: compute: c5, c6, c7
general purpose: m5, m6, m7
memory optimized: r5, r6, r7
burstable: t2, t3, t4g Happy to answer hard questions. |
If you want to push on safety, failure modes, rollout, or supported AWS scope, those are the right questions.