今年 AWS 的 re:Invent 又開始了，這一個禮拜會冒出蠻多新功能的，挑自己覺得比較有興趣得來寫。
AWS 針對 Lambda 推出 Lambda SnapStart，改善冷啟動的速度：「New – Accelerate Your Lambda Functions with Lambda SnapStart」。
他拿了一個比較明顯的例子，Java 的 Spring Boot，範例在「Serverless Spring Boot 2 example」這邊，冷啟動的速度可以從 6 秒降到 200ms：
SnapStart has reduced the cold start duration from over 6 seconds to less than 200 ms.
方法就是把 initialization 的程式完成後的記憶體打一份 snapshot 存起來，之後的冷啟動第一動變成是 restore 而非再 initialize：
With SnapStart, the initialization phase (represented by the Init duration that I showed you earlier) happens when I publish a new version of the function. When I invoke a function that has SnapStart enabled, Lambda restores the snapshot (represented by the Restore duration) before invoking the function handler. As a result, the total cold invoke with SnapStart is now Restore duration + Duration.
不過不是所有的應用程式都可以直接套用，有些要注意的地方，比較好理解的是連線 (像是對後端資料庫的預連線) 以及暫存檔的部份 (像是預先算好某些資料後寫到暫存檔) 都需要重新建立。
比較特別的是亂數產生器需要重新 initialize，不然會有機率產生出一樣的 random data，這個是一般開發者會忽略掉的：
When using SnapStart, any unique content that used to be generated during the initialization must now be generated after initialization in order to maintain uniqueness.
所以 AWS 有針對 SnapStart 下的 OpenSSL 修正，另外外他們也確認過 Java 的 java.security.SecureRandom 本身就沒問題：
We have updated OpenSSL’s RAND_Bytes to ensure randomness when used in conjunction with SnapStart, and we have verified that java.security.SecureRandom is already snap-resilient.
另外 AWS 也推薦可以直接讀系統的 /dev/random 或是 /dev/urandom，這樣就很自然的不會因為 snapshot 而固定，當然也就沒問題：
Amazon Linux’s /dev/random and /dev/urandom are also snap-resilient.
這個功能說不用另外收費，看起來對 Java 族群還不錯？