Strategies to minimize cold start impact

• Provisioned Concurrency — Pre-warm N instances of your function. Eliminates cold starts entirely. Cost: you pay for the reserved capacity even when idle. Use for latency-sensitive user-facing functions.
• Keep init code minimal — Move heavy imports and SDK client initialization outside the handler (module-level) so they only run on cold start, not on every invocation.
• Ping/warmup schedulers — A CloudWatch Events rule that invokes the function every 5 minutes keeps at least one instance warm. Simple, cheap. Does not help with concurrent burst spikes.
• Choose a fast runtime — Node.js and Python have sub-400ms cold starts. Java and .NET are slower. If you have cold start budget constraints, language choice matters.
• Use SnapStart (Lambda for Java) — AWS Lambda SnapStart takes a snapshot of the initialized execution environment and restores it on invocation. Reduces Java cold starts to <1s.

State storage patterns for serverless

• Short-lived ephemeral state — /tmp storage: 512MB–10GB (configurable) persists within a warm execution environment but is not shared across instances and is lost on cold start.
• Session state — JWT tokens (stateless) or Redis (ElastiCache). JWT is preferred — no server lookup needed, state encoded in the token itself.
• Workflow state across multiple functions — AWS Step Functions: visual workflow orchestrator that tracks state across multiple Lambda invocations, handles retries, and provides audit trails.
• Streaming/event state — Use event sourcing — each Lambda publishes events to EventBridge or SNS. State is reconstructed from the event log, not stored locally.