https://aws.amazon.com/blogs/aws/new-accelerate-your-lambda-functions-with-lambda-snapstart/
✻ Lambda SnapStart can improve startup performance for latency-sensitive applications by up to 10x at no extra cost, typically with no changes to your function code. The largest contributor to startup latency (often referred to as cold start time) is the time that Lambda spends initializing the function, which includes loading the function's code, starting the runtime, and initializing the function code.
✻ With SnapStart, Lambda initializes your function when you publish a function version. Lambda takes a Firecracker microVM snapshot of the memory and disk state of the initialized execution environment, encrypts the snapshot, and caches it for low-latency access. When you invoke the function version for the first time, and as the invocations scale up, Lambda resumes new execution environments from the cached snapshot instead of initializing them from scratch, improving startup latency.
⚠️ Important
➣ If your applications depend on uniqueness of state, you must evaluate your function code and verify that it is resilient to snapshot operations. For more information, see Handling uniqueness with Lambda SnapStart.
SnapStart supports:
✅ Java 11 runtime
SnapStart does not support:
❌ provisioned concurrency
❌ arm64
❌ Lambda Extensions
❌ EFS
❌
> 512 MB ephemeral storageℹ️ You can't use SnapStart on a function's unpublished version (
$LATEST).SnapStart vs Provisioned Concurrency
👉 Use Provisioned Concurrency if your application has strict cold start latency requirements.
👉 SnapStart helps you improve startup performance by up to 10x at no extra cost.
❗ You can't use both SnapStart and Provisioned Concurrency on the same function version.
#Lambda
