Lambda Snap Start Restore Duration

Question

Hello Everyone,

I have enabled snap start for one of my lambda function in published version for Spring Boot Application.
In the restore phase of snap start I am have observed some inconsistent restore duration as follows:

**Case 1: **
2023-08-30 05:28:49.829,"**RESTORE_START **Runtime Version: java:11.v21	Runtime Version ARN:

2023-08-30 05:28:50.911,"{""level"":""INFO"",""loggerName"":""CRAC_Hook"",""message"":""afterRestore"",""contextMap"":{}}

**Case 2: **
2023-08-29 10:40:19.208,
"**RESTORE_START **Runtime Version: java:11.v21	Runtime Version ARN:

2023-08-29 10:40:21.833,"{""level"":""INFO"",""loggerName"":""CRAC_Hook"",""message"":""afterRestore"",""contextMap"":{}}

**Observation:**
The time taken after restore function to reach my java function 
**Case 1: ** 1.082000s
**Case 2: **2.625000s

There is roughly 1s of difference in both the cases.
Could you please help in finding what would be the possible reasons for such scenarios.

Answer

I would love to have a complete log. Here's what I can see from the **Restore Log** shared:

`2023-08-30 05:28:49.829,"RESTORE_START Runtime Version: java:11.v21 Runtime Version ARN: `

However, I couldn't locate:

`2023-08-30 05:28:??.??? RESTORE_REPORT Restore Duration: ??`

Based on this information, the following appears to be the invocation phase:

`2023-08-30 05:28:50.911,"{""level"":""INFO"",""loggerName"":""CRAC_Hook"",""message"":""afterRestore"",""contextMap"":{}}`

There is a noticeable inconsistency between case one and two. To resolve this issue, I recommend referring to the CloudWatch for SnapStart section in the documentation [[1]](https://docs.aws.amazon.com/lambda/latest/dg/snapstart-monitoring.html). This documentation includes a CloudWatch insight query sample that can help you troubleshoot.

Additionally, consider utilizing X-Ray for a deeper analysis of your Lambda's performance, as also explained in the documentation.

I hope this information proves helpful.

**Lambda SnapStart Monitoring**

[1] https://docs.aws.amazon.com/lambda/latest/dg/snapstart-monitoring.html

Answer

Lambda SnapStart uses a single snapshot as the initial state for multiple execution environments, unique content if included in the snapshot during initialization is reused across execution environments. In order to handle such scenario and maintain the required uniqueness, you must verify before using SnapStart that any unique content previously generated during the initialization now gets generated after the initialization. This includes  unique IDs, unique secrets, and entropy used to generate pseudo-randomness.

To maintain the uniqueness, you can use SnapStart scanning tool that checks for certain categories of code that assume uniqueness. With those results in hand, you make changes as required. The SnapStart scanning tool [[1]](https://github.com/aws/aws-lambda-snapstart-java-rules) is an open-source SpotBugs plugin that runs static analysis against a set of rules against which the scanning tool checks the code. AWS Lambda SnapStart Bug Scanner helps AWS Lambda customers inspect their functions against potential bugs unique to AWS Lambda SnapStart environment.

**AWS Lambda SnapStart Bug Scanner**

[1] https://github.com/aws/aws-lambda-snapstart-java-rules

Lambda Snap Start Restore Duration

Relevant content