For occasional burst jobs on a small VM, resize up beats spot/ACI
Speeding up an occasional heavy compute job (transcription, large build, one-time data import) on an existing always-on small cloud VM
Instinct is to reach for spot VMs, Azure Container Instances, or job-queue infrastructure to handle 'spike compute.' For one-off serial jobs where you already have a tiny always-on VM holding the data, temporarily resizing the existing VM beats all the fancier patterns. az vm resize -g rg -n vm --size Standard_B8pls_v2 takes ~5 seconds, restarts the VM in-place, gives you 4x the compute. Run the job. Resize back to small. Total extra cost = (bigger_hourly - smaller_hourly) × job_hours, usually under $1/job. Zero state migration (data stays on the same VM). Zero eviction handling. Zero cold-start. Zero new infrastructure. Spot or serverless saves more $$ in absolute terms but only matters above ~5-10 jobs/month, because the one-time engineering cost (cloud-init scripts, eviction retry loops, shared storage, job orchestration) is 4-6 hours of work vs literally two CLI commands for resize. For under-10-jobs/month use cases, resize-around-job is dominant on both effort and reliability axes.
For a heavy job that runs occasionally on existing infra, default to az vm resize (or gcloud compute instances set-machine-type, or equivalent) rather than spinning up new VMs/spot instances/serverless workers. The engineering savings almost always exceed the per-job dollar savings unless you're running many jobs per month.