Separate ecach sentence from the text: Welcome to the session. This is amazing to see too many people here. My name is <PRESIDIO_ANONYMIZED_PERSON>. I'm a senior SA engineer, and I build the PowerTools for AWS Lambda at AWS. PowerTools is a toolkit that helps customers to adopt the best practices. I'm here with my colleague, Sanrat, our principal PM for Lambda, and he'll be introducing himself later. So, today we'll talk about this great new launch that you did like a month ago, probably, that is an upstart for Python and .NET. Most of you probably know that it's already supported in Java, but now we added support in Python and .NET. Just a heads up before you move on with our presentation, please don't forget to fill out the survey when you finish the presentation. This is very, very important for us to improve and to make change and get better in the following years. So, let's talk about a common challenge that everyone has when building AWS Lambda functions, the initialization times. And it can vary depending on the language. Of course, Java is different from .NET, .NET is different from Python, from Node.js, from Go, and whatever. So, let me make some considerations when customers face challenges with initialization time when building Java. For example, Java needs to load the Java virtual machine. This is like a time-consuming operation. We know this is the nature of Java. Java works the same as Java exists. So, Java also needs to load the class. This also takes time, but not all that. Java needs to start up or initialize the static code. So, it can include your class, it can include whatever Java needs to do that. But customers can improve that. For example, customers are building AWS Lambda with Java and using just the required extensions, or the required libraries, sorry. They don't add things that doesn't need to be there, doesn't ship to the production libraries that it doesn't need. It helps to reduce the initialization time. Customers are already invoking Lambda sometimes, some period of time to keep it warm and go away from the code stack. In Java, as I mentioned before, customers can already use Snapstart. And you have some great history for customers that could improve the Java functions a lot using Snapstart. So, but customers is building .NET also. And .NET is quite similar to Java when it's coming to the way that they load things, and they build things. And customers basically have the same challenges when they have like in Java. .NET needs to bootstrap the CLR, the Common Language of Runtime. .NET also need to load the class, also need to load your code and whatever. And customers is already trying to improve this experience. Since the Lambda .NET, the .NET 8, the customer can take benefit of AOT, the Ahead of Time Compilation. That's not needed to use anymore just-in-time compilation that build things during the executed time. This improve the experience, improve the initialization time when you're building Lambda with .NET. But similar to Java, customer can, for example, doesn't import the unnecessary libraries or unnecessary namespacing in .NET. And now Python joined the room. We know that Python, we don't experience a lot of code starts with AWS Lambda because different from Java and .NET, Python is an interpreted language. So, it's behaving different when you're building AWS Lambda. But you know the stories from customers that still face some challenges and having code start. And similar to other languages, customer can reduce the imports that doesn't need to use it. Customer can opt for lightweight frameworks or SDKs or toolkit like PowerTools and not ship a lot of libraries into the Lambda code. Customers can, for example, use the approach of monolambda or fat lambda that you have like when building microservice, you have like one lambda that is responsive for all the endpoints or most of the endpoints that you have in your application. But all these improvements sometimes not enough to improve the initialization time. So that we've seen this presentation, some aspects in the new launch feature, Snapstart, to help you with that. We will cover some important aspects of AWS Lambda like on-demand invocation model, Lambda Snapstart, user cases, any other things. I hope you can leave this presentation with enough knowledge on how to improve your experience using Snapstart for Python and .NET. But before we proceed with the presentation, how many of you are building AWS Lambda with Python and .NET? Nice, nice, great to see. And how many of you have to deal with long code starts times? Yeah, yeah, I feel you, you are not alone. I've been in that position for so many times. Let's talk about the traditional mode of invoking a Lambda function, the on-demand invocation mode. So, your Lambda function receives an event, receives a request, and then Lambda needs to bootstrap, needs to create a new environment. We call that AWS Lambda execution environment. This involves, for example, bootstrapping or creating a micro-VM instance of Firecracker. For example, this includes offloading your code, this includes downloading your code and unpacking your code. We can translate that, that an execution environment is created, is reused, and it is destroyed all the time when using AWS Lambda. And of course, all the time that you need to create a new environment from scratch, and you need to bootstrap everything, and you need to load everything, you probably experience code start. Let's explore each step of the invocation model to make sure that we are on the same page when we experience code start. When the Lambda, when you invoke the Lambda the first time, the Lambda needs to download and unpack the file. It includes all your code and all the dependents. When you have a large package in AWS Lambda, you can experience more latency on the code start, because you need to download a large file. This is different when you download some kilobytes, you need to download megabytes file. After that, Lambda will start the execution environment. So, this is, again, this is creating the micro-VM with Firecracker, which provides you isolation and security when executing Lambda functions. And then after that, the manager on time will be bootstrapped, so will be created on top of the micro-VM. After that, the execution environment, first execution initialization code. This is basically everything that's outside of the Lambda handler. So it can be like a top-level import, it can be a top-level statement, it can be like a HTTP connection outside of the Lambda handler. This is executed during this phase. But you can ask me, hey, this is still missing to execute my Lambda handler, my business logic, my code itself. So, this is executed in the next step. Then Lambda completes all the steps that needs to create a new environment. And this is, we can call the code start. For the first time that you execute a Lambda function, you can experience a code start, because your Lambda needs to create everything from scratch. But after that, for the subsequent invocations, this is not code start anymore, because Lambda has an intelligence, it's smart enough to reuse the container that you created before. Remember that the Lambda is one invocation for one execution, one invocation for one execution. So, Lambda can reuse the container, but it's not guaranteed. We don't know if, for example, the EC2 fleet behind the Lambda will be refreshed, or if the Lambda do it some mechanisms, like load balancer that you have in front of, will balance you to a new container. So, this is not guaranteed that you will reuse the same containers and avoid the code start. But you can ask me, hey, okay, but how to solve that? That's why you'll be here. I will invite my colleague, Sam Ratty, to explain more details on that. Thanks, Leandro. So now that you understand how cold start impacts your application performance, especially around the latency introduced by loading up dependencies, let's talk about how do you reduce this initialization time and improve your application performance. So, I'm gonna talk about AWS Lambda Snapstart for Python and .NET, a feature that Lambda team announced last month. And so, for customers that are building scalable and responsive applications on Lambda who want to reduce the startup latency, both, so Java was already there. Now we have Python and .NET. How does Snapstart work? So, we'll look into that, and then we'll also go into the benefits of Snapstart. So, I think let's start with the benefits itself. In terms of where Snapstart is supported, Snapstart is available with Python 3.12, 3.13, .NET version eight, and Java 11, 17, 20, and later versions is gonna be available. Sorry, if I could go back. Something to keep in mind though is, you know, I talked about the benefits and the use cases. Where is Snapstart helpful? I think there are two main use cases. So, if you have latency sensitive web APIs, APIs, or web applications, where especially if it's user facing and latency is critical, that's somewhere that Snapstart is gonna be helpful. And even when there is batch data processing, and then you want to remove the outlier functions that may be taking longer to process, again, because of longer initialization times, those are use cases where Snapstart is very helpful. Now, unlike Java, and you know, Leandro sort of alluded to this, is with Python, typically the cold starts, you know, Java has a, you know, median cold start latency of let's say around four seconds, but typically Python functions, you know, run faster. But even within Python, like what we have observed is, you know, there are a couple of frameworks. So, if you're using, you know, or the apps are using frameworks like Flask, Django, Lang chain, that's where we see that cold starts can, you know, vary from two to five seconds. And with Snapstart, we see that latency go down to a sub second. Secondly, if you have processing workloads that are using libraries like DuckDB or NumPy, they, these also, you know, we have observed that typically these processing workflows will also run for like over five seconds. And with Snapstart, we have validated that, you know, overall latency goes sub second for these as well. And then Leandro mentioned about the ahead of time for .NET, but with .NET ahead of time compilation, there are certain challenges, even with the latest version of .NET, especially around the concept of trimming. So with the ahead of time compilation, if there is, you know, your application does some dynamic lookups and it's, you know, during that just-in-time compilation, if there are some parts of the application that are trimmed, then the behavior of the application will not be deterministic. And in such cases, you know, we recommend that, you know, .NET for Snapstart will help reduce that latency without code changes. Now, I think now let's look into how does Snapstart work in the workflow. In this case, you know, what you see here is for a function that has had the initialization. So, the status of pending is when you enable Snapstart on a function, you enable it and then you have to publish a function. And so, you get the function version. That's when the whole process kickstarts. And here, what you see is the process launching the entire initialization phase of the function. So, any, as soon as the initialization happens as part of Snapshot start, the Firecracker micro VM snapshot, it's a snapshot, encrypted snapshot of the memory and disk state. And that is captured and that is stored in a low latency cache in small chunks. And when there are subsequent invokes that happen for your Lambda function, this encrypted snapshot is loaded back up. I mentioned the tiered small chunks. And so, the most frequently accessed aspects of those chunks will be loaded, again, leading to improved latency. So, in this case, I talked about the function state itself going from pending as soon as you enabled and published a function with Snapstart. Once it is active, and so the state goes from pending to active, that's where all the corresponding invokes on Lambda will start loading the execution environment from the encrypted snapshot, and that reduces the cold start latency. So I think here, when you have, when there are multiple requests coming or multiple invokes happening on your Lambda function, Lambda will scale up for, you know, spin up multiple execution environment instances, and all of them will use the snapshots that were stored to resume and invoke the function and run the function handler that you have. We will dig into the details of what is happening as part of the initialization, and what are some best practices around the logic that you need to run, or at least think about before and after a snapshot is created. Let me talk about the invocation model with Firecracker. I talked about how, as part of Snapstart, we use the Firecracker micro-VM. It provides and offers both security as well as low latency for creating these snapshots and then loading them back up. And then at a later point in time, I'm going to cover the hooks, the pre and post hooks on how to think about what parts of initialization should you configure before a snapshot is created, and what are some ideal use cases for code that you want to run after a snapshot is created. And so, I talked about the init phase, and then every subsequent invocation that's happening after a snapshot is available and ready. That's being resumed with the with the Firecracker-based snapshot that is created for your application. So now, before going into the details of the pre and post snapshot hooks, let's look into the use cases, some specific use cases, and then we'll jump into the details of each of these hooks. Leandro? Thank you. You can see the difference between Vulkan Lambda and on-demand model, and then using Snapstart. You take a snapshot, and then you resume that snapshot. But let's talk about some use cases. For example, a hot topic today is building LLM application. Everyone wants to improve the GNI capabilities, want leverage and take advantage of that, and in building LLM application. A common use case is, sorry, I forgot to pass the slide, but a common use case is using language chain library. Language chain provides abstraction, like it works like a proxy for many, many, many models, and many downstream models or services that customers are building that using AWS Lambda. Let's see this example, for example. On top of this example, we are importing the language chain library, we are importing FastAPI, and we are importing Magnum that create like a wrapper on the top FastAPI. But in this example, the customer can create a GNI solution, for example, that will be work like an API. Someone asks a question, and this application can create like a shut and open API instance, and query this LLM, and it create an response. I mean, many use cases. Let's see, executing this coding with on-demand model, and then with Snapstart. You can see in the graphic, when you execute this function with one gigabyte of memory, it take around 3.5 seconds of code start, I mean, the first execution. But now, you can use Snapstart for that. When you use Snapstart, you can see that the result of the first invocation is around 500 milliseconds, because you don't need to create all the environment from scratch. You don't need to download the code, you don't need to unzip that and load everything. This is a snapshot now. This is a snapshot that can be resumed by AWS Lambda and improve the experience. But customer may not just build the GNI. Customer is also building some data analysis, that imagine that you have a large or medium data set that you want to query that, because you want to, I don't know, summarize the data, or you want to have fast response on large data set. I mean, many use cases. Imagine that in the same concept. You have an API that you query that, and you will check the large data set. In this code, you are importing DuckDB, the famous non-relational database. We are importing Pandas also, that you know who builds Python here and uses Pandas, know that Pandas is like a huge package, NumPy and all these things, and bring it by then, I think. I'm Python fan, so I know the pain. And then, the same with FastAPI, we create an API. Let's see this example, but here we have a consideration. We are connected to the database. We know that database is not like a normal situation, not take too much time, but you still connect to the database. This will help us to understand best practice in the final. So, running this function with the same one gigabits of memory, you can see in the code start, you experience eight seconds of code start. I mean, because it's loaded everything, it's loaded to some data set or model, I don't know, many use cases. But when using with Snapstart, we did like many, many tests. You see that you are invoking the Lambda, like for hours. We can experience just around one second of restore time. That is the code start for Snapstart. You see that you can use Snapstart and take benefit, even in a language like Python that's like interpreted. Any customer doesn't face too many code start timing, but you can use Snapstart for that. But, okay, now you understand the use case. It's a little bit more on Snapstart, but how can you enable that? How can you make your functions to use Snapstart? Sanat, please. Thank you, Leandro. Let's see how to configure Snapstart. You can enable Snapstart for new or existing functions. This point is very important, which is Snapstart only works with published versions or alias of your Lambda function. So, there are instances that, you know, you've seen customers sort of turn on Snapstart, but never either publish or refer to a version of the function that does not have Snapstart enabled. So, this one is important. And then, you know, we'll cover how do you monitor, how do you confirm that Snapstart is available, active, running, all of that will be available. And then, you know, you can enable Snapstart using console, SDK, CLI, SAM. And I'll cover some of this right now. The, so I did talk about, if you don't specify your function version or the alias, then Snapstart doesn't work. But let's see how in the console. So, after you've created a Lambda function, as part of the function configuration, that's where you have the option of turning on and enabling Snapstart, and then selecting published versions. And then, like I mentioned, that you have to publish the function. That's when that kickstarts the process of starting the snapshot process. And when it's available, the status is active. And all subsequent invokes from that point, you know, are loaded up using the snapshot, right? Here, the, so I'll also talk about quickly. So, this is an example of a CDK construct, where you have the on published versions for the Snapstart configuration. The, when you update, so there is the update function configuration. And if you check the get function config, that's where the optimization status lets you know, if the optimization status is on, that's when you know that Snapstart has been enabled for this function. And then the state is active. So, when the state is active, you know that Snapstart is activated, and the snapshot is available for invocation. So similarly, along with the CDK, there is the Snapstart entity in CloudFormation SAM that I'll cover. And this is the Snapstart property that you already see. The applied on published version, very similar to how the experience is with the other examples. And I think now I will go into the details of once you have enabled Snapstart, what are some other options? And I talked about the hooks for Python and .NET. So, let's talk about that. So when you want to implement code before or after snapshot creation, that's when, you know, such as before creating a snapshot, typically you, if you're downloading external files or there are some compute intensive tasks, those you cover as part of before creating a snapshot. Typically, what we see is, you know, these hooks are helpful for, you know, running such as cleanup and initialization, some setting, some dynamic configurations. If you have external integrations, you can decide, you know, what is ideal in terms of, in terms of running this code before or after a snapshot is created. And then finally, performance tuning. So, depending on, you know, what parts of logic are you adding to the snapshot creation before and after, that also impacts the performance. And I think one call out I'll say is when using the runtime hooks with Python, it's important to make sure that all the registered hooks are properly imported and included in your functions code. So, if you register a runtime hook in a separate file or a module, you must ensure that the module is present either directly as part of the larger package or in your functions handler file. And if the file or module is not imported into the function handler, then Lambda ignores the runtime hooks. All right, moving on, this is the, so going back into the, all the different steps of initialization, there is the, you know, creation of the execution environment, downloading code, starting runtime, and you see that when you have made a decision on what parts can you move into a pre-snapshot hook, that's where the logic goes and all of that is, you know, as part of that initialization. And then for subsequent, once the snapshot has been created for subsequent sort of invokes, the snapshot is being resumed as well as any logic that you have post-snapshot, that is, you know, usually like things like, you know, connections with database or you have some unique identifiers, like those are all, you know, retrieving secrets, like those are things you would do as part of the post-snapshot hook. And then, you know, Lambda will run the handler logic. I think continuing on, this links to the snapshot restore for Python projects, something that we launched for the runtime hooks. And so there are two, there's the register before snapshot and register after restore. So, this, you have these decorators and functions available to import and, you know, add logic on, again, code that you're running as part of before the snapshot creation or after, right? I will continue on an example of, so this is where you can see that you've imported the before snapshot and after restore as part of the code. And then there is the logic that goes before the Lambda checkpoint and after restore between the two. And again, I'll talk about some, two parts. One is I'll talk about the decorator. So, you have an option of using decorators or functions, and I'll show the code for both. And then some best practices in terms of, you know, while decorators can be convenient using function for hook registration can offer more explicit control, especially when you have multiple hooks and, you know, the way, the order in which these hooks will be run, you can control that better. And then the importing modules. So, something that I mentioned saying, if you are importing hooks within the Lambda handler, they won't be executed. So, you have to register a hook in a file that isn't imported in your main handler. And for your, so once you define and register your hooks, now it is, you know, it's available for, you know, function to run. I think continuing on to the runtime hooks for, so this is the example of using the, so I talked about decorators and functions. This one is the example of using the function method within Python, and then looking into runtime hook for .NET. So, this links to the amazon.lambda.core library to register code before and after a snapshot creation. So, these .NET runtime hooks are available as part of this package, the Lambda core package. And there are two methods that you can use. The register before snapshot and register after a snapshot to run code again before and after. Here is an example code of the two checkpoints. So before and after, register before snapshot, register after restore. A couple of call outs here is, register your hooks in your initialization code. So, some guidelines are the, for an executive assembly approach, register your hooks before you start the Lambda bootstrap with run async. For a class library approach, register your hooks in the handler class constructor. And then for the .NET core applications, register your hooks before calling the webapplications.run method. Then, you know this, so I have this example here and I think next, Leandro is going to take you through some considerations when using Snapstart. Leandro. Okay, thank you. So, let's move it to make some consideration. You saw that you can invoke the same code using on-demand model or using Snapstart model. In most of the case, you don't need to change your code. But sometimes it's, you need. Because it's a little bit more complicated because again, I mean, like all the technologies, you have some edge cases. You have some limitations. It's not different with Snapstart. Imagine the scenario when you need to deal with uniqueness. Imagine that you needed to create a unique seed salt, whatever, for cryptography reasons and you need to encrypt the request with that unique ID. This is supposed to be unique ID. But now imagine that you put the generation of the seed of the salt or your ID, whatever, outside of the Lambda handler. This will be executed once when you take the snapshot. And this will be one code. This will be like the unique value. This won't change in every vocation because Lambda is resuming from a frozen container. Lambda is resuming a snapshot. So, you have the same code. You need to take care about when dealing with uniqueness, when you need a content that should be unique across all the invocations. Because if you don't take care about that, you probably will end up with the same code, the same value, the same hash across all the millions, billions execution that using the same containers. Another thing that Sanrat already told about its version and alias. It doesn't work with the latest version. Imagine that you enable a snapshot, and you don't publish a version. This won't work. This will be executed as on-demand. And you can observe that if you go to the Lambda logs, you can see that the invocation model, or if you, for example, inspect the environment variables from the Lambda, you see that invocation model will be on-demand. So, make sure that you are creating a version and you're attaching these alias or not, but you need to invoke using version. Another thing that it was no problem in Java, but fortunately it's fixed now, it's the DNS cache. Because in Java, Java virtual machine caches the DNS. But fortunately, in Python and .NET, this is not a problem because the runtime in not either .NET nor Python caches the DNS. So, they all the time refresh the DNS, even if you have like, imagine that you are querying address during the snapshot phase. So, and then after that, inside your Lambda function, you want to make a call to this address, wherever this DNS. All the time in Lambda, in Python and .NET, we use the Lambda resolver with a fresh DNS, and it won't cache that. Another thing that I can say about this DNS is try to use that modern libraries, like in Python, that doesn't cache DNS. You know that the library doesn't intentionally cache DNS. Otherwise, even the runtime doesn't cache, you can have a problem with libraries. In .NET, it's tried to automatically establish the socket connection, but again, you need to check that, if you need to check if the library support that. This is what I want to say about DNS. Even the runtime, it doesn't have this problem. You need to take care about the libraries that you are using. Another important topic is, customers are already using provisional concurrence. Because the customers is, hey, I can use provisional concurrence for that. For those that doesn't are familiar with that, the provisional concurrency, it basically warms a number of Lambda functions, Lambda containers, you can configure it. So, you can say 100. So, you have 100 warm containers that will be responsiveness and whatever. Snapstart is also, there is a lot of value, for example, when using workloads that you have unpredictable spikes, for example. You have like a linear, you have linear invokes, but at the period of time of the day, you have like a thousand invocation, it's coming or whatever. You can use Snapstart to improve this code start time. While provisional concurrence, I can say that it's ideal for low latency workloads. Imagine that you have an API that you can't response over the, I don't know, 200 millisecond, 300 millisecond, just guessing a number here. So, this is, in my opinion, you can use Snapstart for that reducing the latency for 99% of requests, and when you have like unpredictable spikes of traffic. But while in contrast, sorry, the provisional concurrency, when you have like a linear responsiveness from the Lambda function. Another very important aspect of when using Snapstart, I mean, when using serverless in general, you need to observe, you just need to monitor. You need to observe your function. You need to observe the behaviors of your function. In Snapstart, you can use CloudWatch, for example, to monitor the need report. That's the time that it takes to make the snapshot, to create the snapshot. Another thing is you can monitor the invocation logs. You have a metric that's called restore report, restore time, that you can monitor how much time it takes to restore, to resume that Snapstart. Again, observe your function. Doesn't matter in on-demand model, in Snapstart model, observe your function because you can have great insights for that. Also, you can use AWS X-Ray to monitor the load runtime. For those that are already using X-Ray in the on-demand invocation model, you see they need time. When you use Snapstart, you can see the restore time. This is a different metric, but you can still observe that. You can also use the Lambda Telemetry API if you want to report in JSON or query that. Now, okay, we know that the consideration, but what's the best practice when working with the Snapstart? Let's take this one example. Imagine that you have like a Lambda function that you create some HTTP connection or some database connection outside of your Lambda handler. And then when the Snapstart takes the snapshot, it should execute that connection. You keep that in memory, appointed to the memory, whatever. But you invoke the Lambda like one hour after, two hours after, I don't know. The connection would not be available at that time because Lambda can restore your container in another server. Or Lambda or the downstream connection can be like, I don't know, many use cases. So, we'll see that in more detail, a real use case, but take care about the connection. You can use it, for example, the after restore, Snapstart look to check if the connection is still available or even inside your Lambda handler. Another use case is about ephemeral data. Imagine that you grab a secret or, I don't know, something that is supposed to be ephemeral and work like for a period of time when the Lambda is taking the snapshot. And then you don't check that after that. You consider that data, the ephemeral data is still valid. Can be a file, can be a secret, can be whatever that you consider ephemeral. You need to take care about that because the container, the snapshot, will be there for some days. So, imagine that you've taken a snapshot five days ago and now you're using the same secret that could be rotated. But let's see this in a real example. You have here a Lambda that is executing a connection to RDS during the init phase. I mean, when it takes a snapshot. And then when the Lambda resumes this container and you don't check the connection, you assume that the connection is still valid. What will happen when you invoke the Lambda? The connection will fail because the socket is no longer available, the address could be changed that you didn't know, or the secrets can be rotated for many use cases. Let's see the thing about ephemeral data. You have, again, a Lambda that grabs secrets from AWS secrets and then store that in the memory, in the snapshot. And then during the resume, you not check if the data is still valid, if the data was rotated, if the, I don't know, again, a lot of use cases. And then you try to connect to the same database. First, you have the problem, first you need to check the connection, but that connection is okay. I can ping, I can connect, I can, the socket is established. But now you try to connect itself. You try to go there and say, hey, this is my user and password. But it's failed because the credential was rotated. You have a policy in the company. I don't know, you have a policy in your account that Lambda is rotating AWS secrets for like two days. So that's, you need to take care about that. When you work with Snapstart, some user case like that, because you are using a container that was created, I don't know, some days ago, some hours ago, you need to take care about this use case. That's nice to know because I really love to advise customer that need to take care about that. But we are moving, we are heading towards to the final of the presentation. But it's still missing to cover an important price, one important topic, sorry, I did a spoiler. That is about pricing. So, Sarathi, please. Thanks. Okay, coming on to the, you know, talking about pricing. There are pricing for Snapstart is based on two dimensions. So, charges based on the amount of caching that Snapstart is performing, and then the number of restores. This example here, you know, I've taken a one GB function that is active for the entire month. So that's the GB second month, and then multiplying that with the rate that's available on the website. That is the charge for caching. And then in terms of restores, so typically as you can see that, you know, restores are a small percentage of the number of invokes that are happening. Typically, we see that, you know, less than, like around 1% of the total number of invokes are, or see the restores. So, in this case, there is a charge based on the number of restores and the memory that is being used. The, some things to keep in mind is for Python and .NET, the snapshots are not deleted for function versions that aren't invoked for 14 days. So, if you've used the Java Snapstart, you'll know that within, you know, after the 14-day period, if there are no invokes, the particular Snapstart goes inactive. And then if there is an invoke, you know, it goes back to an active state. Whereas with Python and .NET, the Snapstart functions, they're always active. So, the active state, once it has been initialized. And yeah, so for the caching, in terms of the time, like here for this example, I talked about the entire month, but the initial charge, like as soon as you start up, there is a minimum sort of for three hours, we compute the total duration. And after that it is per millisecond. So, if it's three hours and a few seconds, like that's the charge multiplied by the rate. And then I have an example here for, so the price is of course, depending on the amount of memory that you're allocating to your function. And then I have the, an example here where if there is a one GB function with 300 milliseconds of execution duration, and there are a hundred million invokes with about 250,000 restores, then the total charges, you know, with that rate is about $558. And then there's a breakdown, like the compute and request charges that is just the current pricing. But then there is the cache, you know, how the amount of snapshot that was cached by Lambda. And then the restores, number of restore charges, that is the pricing. I think the two parts to keep in mind here again is the caching charge is independent of the invoke volume, as you can see. And then the ratio of cold starts to invokes reduces as the traffic volume grows because, you know, like once the snapshot is available, the number of restores, especially for a warm execution environment is going to be lower, right? And then something to keep in mind would be the list version by functions API. Like that is an existing API, but at least that way using this API, you can tell what are the different function versions that have Snapstart enabled for purpose of tracking, as well as I think a best practice, especially since this pricing is per function version is to delete the functions, the older function versions that you're no longer using, because Lambda would continue to keep these snapshots available even for older versions. So, I think one best practice is, you know, just look for the function versions that you no longer care about. And if Snapstart is enabled, either disable it or just delete those versions. All right, with that quick takeaways, I know we covered a lot of ground today, but, you know, Snapstart is available for Python, .NET and previously as is the case with Java. The again, you know, call out on the part that Snapstart only works with the specific function version or the alias. If you're not specifying during an invoke the version, then, you know, even though Snapstart may be enabled for a function, you're not receiving the benefit of it. And then, you know, you can lower your costs by deleting unused versions. All right, I think that is what we have for today. Thank you so much for, you know, joining us today. And then, you know, please don't forget to fill out the session feedback to give us, you know, how we can sort of improve on this as well as any, we'll be around here. Like if you have questions and want to chat with us, we'll be available as well, right? Thanks a lot, Chukami. Thank you. Welcome.