Warm Instances

Cold starts are acceptable for background jobs. Nobody notices if a queue processor takes an extra 2 seconds to start. But for user-facing APIs? A 2-second delay on login is unacceptable. A 3-second delay on checkout loses revenue.

Warm instances solve this by keeping execution environments pre-initialized and ready. When a request arrives, it hits an already-running environment, no initialization delay. The response is fast, consistent, and predictable.

The concept is not unique to serverless. Traditional auto-scaling groups can maintain minimum instance counts. Kubernetes can keep minimum replica counts. The principle is identical: trade idle compute cost for guaranteed readiness.

AWS published a case study showing that a fintech company reduced their P99 Lambda latency from 4,200ms to 85ms by enabling Provisioned Concurrency on their payment processing functions. That is a 98% reduction. The idle cost was $180/month. The lost revenue from 4-second checkout delays was several thousand per month.

The economics:

Suppose your Lambda function serves 1,000 requests during business hours and 5 requests overnight. Without warm instances, you pay nothing overnight but cold start those 5 late-night requests. With 1 provisioned concurrent instance, you pay ~$15/month to keep it warm 24/7, but those 5 requests respond instantly.

When warm instances make sense:

• User-facing APIs where latency matters
• Functions with heavy initialization (Java, .NET)
• Payment processing (delays feel like errors to users)
• Health check endpoints that monitoring systems hit regularly
• Real-time data APIs feeding dashboards

When they do not make sense:

• Background processing (queues, batch jobs)
• Infrequent cron tasks
• Internal tools with tolerant users
• Development/staging environments
• Functions with < 100ms cold start (Go, Rust)