New – Accelerate Your Lambda Functions with Lambda SnapStart

{"value":"Our customers tell me that they love [Amazon Web Services Lambda](https://aws.amazon.com/lambda/) for many reasons. On the development side they appreciate the simple programming model and ease with which their functions can make use of other Amazon Web Services services. On the operations side they benefit from the ability to build powerful applications that can respond quickly to changing usage patterns.\n\nAs you might know if you are already using Lambda, your functions are run inside of a secure and isolated execution environment. The [lifecycle](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-environment.html#runtimes-lifecycle) of each environment consists of three main phases:```Init```, ```Invoke```, and```Shutdown```. Among other things, the ```Init``` phase bootstraps the [runtime](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html) for the function and runs the function’s static code. In many cases, these operations are completed within milliseconds and do not lengthen the phase in any appreciable way. In the remaining cases, they can take a considerable amount of time, for several reasons. First, initializing the runtime for some languages can be expensive. For example, the ```Init```\n phase for a Lambda function that uses one of the Java runtimes in conjunction with a framework such as [Spring Boot](https://spring.io/projects/spring-boot), [Quarkus](https://quarkus.io/), or [Micronaut](https://micronaut.io/) can sometimes take as long as ten seconds (this includes dependency injection, compilation of the code for the function, and classpath component scanning). Second, the static code might download some machine learning models, pre-compute some reference data, or establish network connections to other Amazon Web Services services.\n\n### **++Introducing Lambda SnapStart++**\nIn order to allow you to put Lambda to use in even more ways, we are introducing Lambda SnapStart today.\n\nAfter you enable Lambda SnapStart for a particular Lambda function, publishing a new version of the function will trigger an optimization process. The process launches your function and runs it through the entire ```Init``` phase. Then it takes an immutable, encrypted snapshot of the memory and disk state, and caches it for reuse. When the function is subsequently invoked, the state is retrieved from the cache in chunks on an as-needed basis and used to populate the execution environment. This optimization makes invocation time faster and more predictable, since creating a fresh execution environment no longer requires a dedicated ```Init``` phase.\n\nWe are launching with support for Java functions that make use of the Corretto (```java11```) runtime, and expect to see Lambda SnapStart put to use right away for applications that make use of Spring Boot, Quarkus, Micronaut, and other Java frameworks. Enabling Lambda SnapStart for Java functions can make them start up to 10x faster, at no extra cost.\n\n### ++Using Lambda SnapStart++\nBecause my last actual encounter with Java took place in the last century, I used the [Serverless Spring Boot 2 example](https://github.com/awslabs/aws-serverless-java-container/tree/main/samples/springboot2/pet-store) from the [Amazon Web Services Labs](https://github.com/awslabs) repo as a starting point. I installed the [Amazon Web Services SAM CLI](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-reference.html#serverless-sam-cli) and did a test build & deploy to establish a baseline. I invoked the function and saw that the **Init duration** was slightly more than 6 seconds:\n\n\n\nThen I added two lines to ```template.yml``` to configure the ```SnapStart``` property:\n\n\n\nI rebuilt and redeployed, published a fresh version of the function to set up SnapStart, and ran another test:\n\n\n\nWith 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**. SnapStart has reduced the cold start duration from over 6 seconds to less than 200 ms.\n\n### **++Becoming Snap-Resilient++**\nLambda SnapStart speeds up applications by reusing a single initialized snapshot to resume multiple execution environments. This has a few interesting implications for your code:\n\n**Uniqueness** – 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. If you (or a library that you reference) uses a pseudo-random number generator, it should not be based on a seed that is obtained during the Init phase. 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. Amazon Linux’s```/dev/random``` and ```/dev/urandom``` are also snap-resilient.\n\n**Network Connections** -If your code creates long-term connections to network services during the ```Init``` phase and uses them during the ```Invoke``` phase, make sure that it can re-establish the connection if necessary. The Amazon Web Services SDKs have already been updated to do this.\n\n**Ephemeral Data** – This is effectively a more general form of the above items. If your code downloads or computes reference information during the ```Init``` phase, consider doing a quick check to make sure that it has not gone stale during the caching period.\n\n\nLambda provides a pair of runtime hooks to help you to maintain uniqueness, as well as a scanning tool to help detect possible issues.\n\n### **++Things to Know++**\nHere are a couple of other things to know about Lambda SnapStart:\n\n**Caching** – Cached snapshots are removed after 14 days of inactivity. Lambda will automatically refresh the cache if a snapshot depends on a runtime that has been updated or patched.\n\n**Pricing** – There is no extra charge for the use of Lambda SnapStart.\n\n**Feature Compatibility** – You cannot use Lambda SnapStart with larger ephemeral storage, Elastic File Systems, Provisioned Concurrency, or Graviton2. In general, we recommend using SnapStart for your general-purpose Lambda functions and [Provisioned Concurrency](https://aws.amazon.com/blogs/aws/new-provisioned-concurrency-for-lambda-functions/) for the subset of those functions that are exceptionally sensitive to latency.\n\n**Firecracker** – This feature makes use of [Firecracker Snapshotting](https://github.com/firecracker-microvm/firecracker/blob/main/docs/snapshotting/snapshot-support.md).\n\n**Regions** – Lambda SnapStart is available in the US East (Ohio, N. Virginia), US West (Oregon), Asia Pacific (Singapore, Sydney, Tokyo), and Europe (Frankfurt, Ireland, Stockholm) Regions.\n\n— [Jeff](https://twitter.com/jeffbarr);\n\n\n\n### **[Jeff Barr](https://aws.amazon.com/blogs/aws/author/jbarr/)**\nJeff Barr is Chief Evangelist for Amazon Web Services. He started this blog in 2004 and has been writing posts just about non-stop ever since.\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n","render":"<p>Our customers tell me that they love <a href=\\"https://aws.amazon.com/lambda/\\" target=\\"_blank\\">Amazon Web Services Lambda</a> for many reasons. On the development side they appreciate the simple programming model and ease with which their functions can make use of other Amazon Web Services services. On the operations side they benefit from the ability to build powerful applications that can respond quickly to changing usage patterns.</p>\\n<p>As you might know if you are already using Lambda, your functions are run inside of a secure and isolated execution environment. The <a href=\\"https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-environment.html#runtimes-lifecycle\\" target=\\"_blank\\">lifecycle</a> of each environment consists of three main phases:<code>Init</code>, <code>Invoke</code>, and<code>Shutdown</code>. Among other things, the <code>Init</code> phase bootstraps the <a href=\\"https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html\\" target=\\"_blank\\">runtime</a> for the function and runs the function’s static code. In many cases, these operations are completed within milliseconds and do not lengthen the phase in any appreciable way. In the remaining cases, they can take a considerable amount of time, for several reasons. First, initializing the runtime for some languages can be expensive. For example, the <code>Init</code><br />\\nphase for a Lambda function that uses one of the Java runtimes in conjunction with a framework such as <a href=\\"https://spring.io/projects/spring-boot\\" target=\\"_blank\\">Spring Boot</a>, <a href=\\"https://quarkus.io/\\" target=\\"_blank\\">Quarkus</a>, or <a href=\\"https://micronaut.io/\\" target=\\"_blank\\">Micronaut</a> can sometimes take as long as ten seconds (this includes dependency injection, compilation of the code for the function, and classpath component scanning). Second, the static code might download some machine learning models, pre-compute some reference data, or establish network connections to other Amazon Web Services services.</p>\\n<h3><a id=\\"Introducing_Lambda_SnapStart_5\\"></a><strong><ins>Introducing Lambda SnapStart</ins></strong></h3>\n<p>In order to allow you to put Lambda to use in even more ways, we are introducing Lambda SnapStart today.</p>\n<p>After you enable Lambda SnapStart for a particular Lambda function, publishing a new version of the function will trigger an optimization process. The process launches your function and runs it through the entire <code>Init</code> phase. Then it takes an immutable, encrypted snapshot of the memory and disk state, and caches it for reuse. When the function is subsequently invoked, the state is retrieved from the cache in chunks on an as-needed basis and used to populate the execution environment. This optimization makes invocation time faster and more predictable, since creating a fresh execution environment no longer requires a dedicated <code>Init</code> phase.</p>\\n<p>We are launching with support for Java functions that make use of the Corretto (<code>java11</code>) runtime, and expect to see Lambda SnapStart put to use right away for applications that make use of Spring Boot, Quarkus, Micronaut, and other Java frameworks. Enabling Lambda SnapStart for Java functions can make them start up to 10x faster, at no extra cost.</p>\\n<h3><a id=\\"Using_Lambda_SnapStart_12\\"></a><ins>Using Lambda SnapStart</ins></h3>\\n<p>Because my last actual encounter with Java took place in the last century, I used the <a href=\\"https://github.com/awslabs/aws-serverless-java-container/tree/main/samples/springboot2/pet-store\\" target=\\"_blank\\">Serverless Spring Boot 2 example</a> from the <a href=\\"https://github.com/awslabs\\" target=\\"_blank\\">Amazon Web Services Labs</a> repo as a starting point. I installed the <a href=\\"https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-reference.html#serverless-sam-cli\\" target=\\"_blank\\">Amazon Web Services SAM CLI</a> and did a test build &amp; deploy to establish a baseline. I invoked the function and saw that the <strong>Init duration</strong> was slightly more than 6 seconds:</p>\\n<p><img src=\\"https://dev-media.amazoncloud.cn/70c89dbb7b934e218b4658aaf65db7f0_image.png\\" alt=\\"image.png\\" /></p>\n<p>Then I added two lines to <code>template.yml</code> to configure the <code>SnapStart</code> property:</p>\\n<p><img src=\\"https://dev-media.amazoncloud.cn/0bd15643b2f142cfb5d14a7d0bd095c8_image.png\\" alt=\\"image.png\\" /></p>\n<p>I rebuilt and redeployed, published a fresh version of the function to set up SnapStart, and ran another test:</p>\n<p><img src=\\"https://dev-media.amazoncloud.cn/a53d7da14fac4894b96641d20e03e7af_image.png\\" alt=\\"image.png\\" /></p>\n<p>With SnapStart, the initialization phase (represented by the <strong>Init duration</strong> 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 <strong>Restore duration</strong> + <strong>Duration</strong>. SnapStart has reduced the cold start duration from over 6 seconds to less than 200 ms.</p>\\n<h3><a id=\\"Becoming_SnapResilient_27\\"></a><strong><ins>Becoming Snap-Resilient</ins></strong></h3>\n<p>Lambda SnapStart speeds up applications by reusing a single initialized snapshot to resume multiple execution environments. This has a few interesting implications for your code:</p>\n<p><strong>Uniqueness</strong> – 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. If you (or a library that you reference) uses a pseudo-random number generator, it should not be based on a seed that is obtained during the Init phase. We have updated OpenSSL’s <code>RAND_Bytes</code> to ensure randomness when used in conjunction with SnapStart, and we have verified that <code>java.security.SecureRandom</code> is already snap-resilient. Amazon Linux’s<code>/dev/random</code> and <code>/dev/urandom</code> are also snap-resilient.</p>\\n<p><strong>Network Connections</strong> -If your code creates long-term connections to network services during the <code>Init</code> phase and uses them during the <code>Invoke</code> phase, make sure that it can re-establish the connection if necessary. The Amazon Web Services SDKs have already been updated to do this.</p>\\n<p><strong>Ephemeral Data</strong> – This is effectively a more general form of the above items. If your code downloads or computes reference information during the <code>Init</code> phase, consider doing a quick check to make sure that it has not gone stale during the caching period.</p>\\n<p>Lambda provides a pair of runtime hooks to help you to maintain uniqueness, as well as a scanning tool to help detect possible issues.</p>\n<h3><a id=\\"Things_to_Know_39\\"></a><strong><ins>Things to Know</ins></strong></h3>\n<p>Here are a couple of other things to know about Lambda SnapStart:</p>\n<p><strong>Caching</strong> – Cached snapshots are removed after 14 days of inactivity. Lambda will automatically refresh the cache if a snapshot depends on a runtime that has been updated or patched.</p>\\n<p><strong>Pricing</strong> – There is no extra charge for the use of Lambda SnapStart.</p>\\n<p><strong>Feature Compatibility</strong> – You cannot use Lambda SnapStart with larger ephemeral storage, Elastic File Systems, Provisioned Concurrency, or Graviton2. In general, we recommend using SnapStart for your general-purpose Lambda functions and <a href=\\"https://aws.amazon.com/blogs/aws/new-provisioned-concurrency-for-lambda-functions/\\" target=\\"_blank\\">Provisioned Concurrency</a> for the subset of those functions that are exceptionally sensitive to latency.</p>\\n<p><strong>Firecracker</strong> – This feature makes use of <a href=\\"https://github.com/firecracker-microvm/firecracker/blob/main/docs/snapshotting/snapshot-support.md\\" target=\\"_blank\\">Firecracker Snapshotting</a>.</p>\\n<p><strong>Regions</strong> – Lambda SnapStart is available in the US East (Ohio, N. Virginia), US West (Oregon), Asia Pacific (Singapore, Sydney, Tokyo), and Europe (Frankfurt, Ireland, Stockholm) Regions.</p>\\n<p>— <a href=\\"https://twitter.com/jeffbarr\\" target=\\"_blank\\">Jeff</a>;</p>\\n<p><img src=\\"https://dev-media.amazoncloud.cn/87e5becc2ea34ae78c4ac989555a1133_image.png\\" alt=\\"image.png\\" /></p>\n<h3><a id=\\"Jeff_Barrhttpsawsamazoncomblogsawsauthorjbarr_56\\"></a><strong><a href=\\"https://aws.amazon.com/blogs/aws/author/jbarr/\\" target=\\"_blank\\">Jeff Barr</a></strong></h3>\n<p>Jeff Barr is Chief Evangelist for Amazon Web Services. He started this blog in 2004 and has been writing posts just about non-stop ever since.</p>\n"}