In this guide 6 sections
Spot suits interruptible batch work, burstable instances suit small services that idle most of the day, and serverless suits spiky, event-driven code that can tolerate a cold start. Steady, heavy load usually runs better on ordinary instances, ideally with a commitment attached.
Spot instances trade stability for a lower rate
A spot instance is spare capacity that the provider can take back, usually with a short warning. Your job must survive that. If it cannot, spot is the wrong tool.
Good fits save progress often and can restart from a checkpoint, which is why video transcoding, nightly report builds, CI runners and data pipeline stages all qualify. A stateful database primary does not.
Spread requests across several instance types and availability zones, because a fleet that asks for one type in one zone gets interrupted together, which defeats the point.
- Checkpoint to object storage every few minutes
- Handle the interruption notice and drain gracefully
- Mix instance families in the same pool
- Keep a small on-demand base for the control plane
Burstable instances run on credits
A burstable instance earns CPU credits while idle and spends them when busy. A back-office app with a sleepy afternoon and a Monday spike fits well, while a service pinned near its limit all day will throttle and frustrate its users.
Watch the credit balance metric. When it reaches zero, the instance is throttled to its baseline, and users see slow pages with no error to explain it. Some settings let you pay for extra burst, which can cost more than a larger size.
Treat burstable as the default for small internal tools, staging servers and low-traffic sites. Move up a size when the balance never recovers.
Serverless charges for invocations, with cold starts
Functions run only when called, so idle time costs nothing. A bursty API, a webhook receiver or a file upload handler can sit unused for hours, then handle a thousand requests in a minute.
The price is the cold start. A function that has not run lately needs a moment to load its runtime and your dependencies. Heavy packages and VPC attachment make it worse. For a checkout call that a customer waits on, that delay matters more than any saving on the monthly bill.
Long jobs fit poorly. Execution time limits cut them off, and per-millisecond billing grows against a busy, steady workload that never sleeps.
- Keep the deployment package small
- Set provisioned concurrency only for user-facing paths
- Reuse database connections through a proxy
- Add timeouts and a dead-letter queue for failed events
Match the option to the workload shape
Draw the load for a typical week. Is it flat, spiky, or a few large jobs? The shape picks the tool far more reliably than a price list.
Flat and heavy load belongs on regular instances with reserved capacity or a savings plan. Nightly batch jobs belong on spot. Quiet internal apps belong on burstable. Short event handlers and low-volume APIs belong on serverless.
Mixing is normal. One company might run its web tier on ordinary instances under a savings plan, its image processing on spot, and its webhook handlers as functions behind an API gateway.
Test before you move anything
Pick one workload and run it for two weeks beside its old setup, recording the p95 response time, the interruption count, the credit balance and the monthly bill line.
Set a rollback rule in advance. For example, resize if the credit balance hits zero twice, and add warm capacity or move back if cold starts break an agreed response time.
Start with the batch job that nobody waits on. It is the safest first trial and shows how your team handles interruptions.
Compute option comparison sheet
Each row of this single sheet is a workload (batch job, back office app, bursty API, steady web tier), and the columns are spot, burstable and serverless. Each cell holds a fit score from one to three, the main risk, the metric to watch and the rollback rule. A final row records the chosen option and the trial end date.
Open a blank worksheet to printQuestions owners ask
Can I run a production web tier on spot?
Only part of it. Keep a base of ordinary instances and let spot absorb extra load behind the same balancer. A tier made wholly of spot can vanish together.
How do I know a burstable instance is too small?
The credit balance stays near zero and CPU is throttled in the monitoring graphs, while users report afternoon slowness with no errors in the logs.
Do cold starts matter for background jobs?
Rarely. A queue consumer can take a moment longer without anyone noticing. They matter for calls that a person waits on, such as login or payment.
Is serverless always cheaper for small apps?
Not always. Low and uneven traffic favours it. Once calls arrive steadily all day, a small instance often costs less, so compare using your actual invocation counts.