Deprecate keep_warm in favor of AWS-native cold start solutions

[monkut]

Summary

The keep_warm feature should be deprecated in favor of AWS-native cold start solutions (SnapStart, Provisioned Concurrency).

Rationale

Investigation in #1445 confirmed that keep_warm:

• Does not improve cold start duration — init times are identical (~1,020-1,080ms) with or without keep_warm
• Only reduces cold start frequency by keeping one execution environment alive via CloudWatch pings
• Only keeps 1 environment warm — concurrent requests still hit full cold starts
• Costs ~$0.05/month for marginal benefit

AWS-native solutions are superior:

Solution	Cold Start Reduction	Cost
keep_warm	0% (same duration)	~$0.05/mo
SnapStart	45-72% faster	~$1.95/mo
Provisioned Concurrency	100% eliminated	~$5.40/mo

Proposed Changes

1. Add deprecation warning when keep_warm is enabled — log a warning during deploy and update recommending SnapStart or Provisioned Concurrency
2. Change default from keep_warm: true to keep_warm: false
3. Update documentation to recommend SnapStart and Provisioned Concurrency as primary cold start solutions
4. Keep the feature functional for users who explicitly opt in — full removal in a future major version

Related

• Investigate effectiveness of keep_warm vs standard AWS Lambda cold start solutions #1445 — Investigation results confirming keep_warm ineffectiveness
• snap_start setting not passed to create_lambda_function on initial deploy #1447 — SnapStart not passed on initial deploy (fixed)
• SnapStart requires version publish after config update, but zappa update publishes before enabling #1448 — SnapStart version ordering bug (fixed)

[mihow]

Great contribution! SnapStart reduces the cold start time, but keep_warm still prevents cold starts from happening at all (for an app that only needs one execution environment), for near zero costs. So perhaps the two features serve different purposes and work better in tandem? This change as-is will make existing small apps load slower and cost more since they will always cold start and always use SnapStart, right?

[mihow]

Thanks for the thorough investigation in #1445, it looks like it draws the same conclusion:

SnapStart without keep_warm is the worst option at all traffic levels — more frequent cold starts mean more restore charges, and the cache charge is still $1.95/month regardless.

[monkut]

@mihow I don't mind keeping it in, but from my investigation, if you want to reduce cold starts 'provisioned' seem like the way to go.

The keep_warm feature only appears to affect 1 instance, and if your request happens to hit that warm instance you'll get some savings, but other than that there appears to be no effect.

My concern is that having a keep_warm option that is minimally effective may be presenting more capability than we actually have. In other words, the expectation is larger than actual reality.

Baseline (keep_warm=true) and nowarm show identical cold start init times (~1,020-1,080ms across all frameworks). The keep_warm feature doesn't reduce cold start duration — it reduces cold start frequency by keeping one execution environment alive.