Investigate effectiveness of keep_warm vs standard AWS Lambda cold start solutions

[monkut]

Summary

Zappa's keep_warm feature uses a CloudWatch Events rule (default: rate(4 minutes)) to periodically invoke the Lambda function via handler.keep_warm_callback, keeping one execution environment warm. While this has been a core feature since early versions, AWS has since introduced native cold start mitigation options that may be more effective, cost-efficient, or complementary.

This issue proposes investigating the real-world effectiveness of keep_warm and comparing it against current AWS-native solutions.

Current Implementation

• keep_warm (default: true): Schedules a CloudWatch event to invoke the Lambda on a timer
• keep_warm_expression (default: rate(4 minutes)): Controls invocation frequency
• keep_warm_callback: Calls lambda_handler with an empty event to trigger web app initialization
• Only keeps one execution environment warm — concurrent requests still hit cold starts

AWS-Native Cold Start Solutions to Compare

1. Provisioned Concurrency (GA since Dec 2019)

• Pre-initializes a specified number of execution environments
• Eliminates cold starts for up to N concurrent requests
• Costs: ~$0.015/GB-hour (provisioned) + reduced per-request cost
• Can be combined with Application Auto Scaling

2. SnapStart (GA for Java since Nov 2022, Python since Nov 2024)

• Takes a snapshot of the initialized execution environment
• Restores from snapshot instead of full cold boot
• Reduces cold start from seconds to ~200-400ms for Python
• No additional cost beyond standard Lambda pricing

3. Lambda Function URLs / Response Streaming

• Not directly a cold start solution, but architectural alternatives that may affect warm behavior

4. ARM64 / Graviton2

• Faster init time and lower cost — can indirectly reduce cold start impact

Investigation Areas

• Measure actual cold start times with and without keep_warm for typical Zappa apps (Flask, Django, FastAPI)
• Quantify the gap keep_warm leaves: concurrent cold starts, environment recycling despite warm pings
• Cost comparison: CloudWatch event invocations vs Provisioned Concurrency vs SnapStart
• SnapStart compatibility: Can Zappa leverage Python SnapStart? What changes would be needed?
• Provisioned Concurrency integration: Should Zappa offer a provisioned_concurrency setting as an alternative or complement to keep_warm?
• Hybrid approach: Would keep_warm + SnapStart or keep_warm + Provisioned Concurrency yield better results than any single approach?
• Documentation: Update guidance on when to use which approach based on traffic patterns

Expected Outcome

A clear recommendation (with data) on whether:

1. keep_warm remains the best default for Zappa users
2. Zappa should add first-class support for Provisioned Concurrency and/or SnapStart
3. keep_warm should be deprecated in favor of native AWS solutions
4. A combination approach provides the best experience

Related

• keep_warm setting in zappa_settings.json
• handler.keep_warm_callback in zappa/handler.py
• CloudWatch Events scheduling in zappa/cli.py