Understand invocation - Amazon Web Services (AWS) Tutorial

- In this lesson, we're going to create our final Lambda function, and that's a really simple one, a very easy Lambda function to create. But the goal here isn't for you to understand how to create a Lambda function. I think we've already accomplished that. What I want to do is demonstrate what happens when a Lambda function is invoked. So let's click Create function. I'm just going to call this Lambda function Invocation. And we are going to choose Python as usual. And actually, just to keep it really simple, let's use the blueprint for Hello World and Python 3.10. And again, I'll just name it Invocation. So it's a super simple Lambda function that's going to run some code that AWS has already written for us. And I'm going to create a new execution role with basic Lambda permissions. This Lambda function, we are going to invoke it multiple times. And then we're going to take a look at the CloudWatch logs, so it needs a role in order to be able to write to those CloudWatch logs. And then you can see the code that AWS has written for us with this Hello World function, a really simple function here. So I'm going to click Create function. And now what we're going to do is we are going to repeatedly test this Lambda function. And the idea here is I want to see what is the difference between the first time we invoke it, and the second, and the third time. What's happening as we invoke this Lambda function over and over and over again? And so let's scroll down here to test. We're going to create a new test event, which I'm going to call Invocation. And I'm just going to click on Test a whole bunch of times. All right, so now I've invoked this Lambda function many times. Let's go over to the Monitor tab, and let's click View CloudWatch logs. And let's dig a little bit deeper into what's happening as this Lambda function gets invoked. And so here's our log group. We've got a log group for each of our Lambda functions. So this is the log group for our invocation Lambda function. And then we can see the log streams down here. Let's click on our log stream, and we can see all of the events, starting with the oldest. And so let's start with the oldest event. And we've got this INIT_START event. This is the execution environment being created. So this is going to involve setting up the container, downloading the code, actually loading up the function. And you can see the function actually starts down here. So there's time that is elapsing for that execution environment to be prepared. This is the impact of a cold start. Then the Lambda function runs the code, executes, it ends, and then we have our little report, which is always the final step. Now notice here's the second time I clicked on the test button for our Lambda function. There is no INIT_START here. The execution environment was already ready to go, so we avoided a cold start. This is what we call a warm start. And so there's no delay between when we clicked that test button to when the code started executing. The execution environment was already there, already ready to go, and we can see that with each of these subsequent invocations. They're never initializing, they're just starting. So we avoid that cold start delay, because the execution environment is already ready. Now, what if I were to run 100 of these tests simultaneously? Well, then, for each of those invocations that are running at the exact same time, that execution environment would need to be created. So warm starts are going to occur the vast majority of the time. As your Lambda functions are invoked, if they've been invoked before, most of the time, will have a warm start. But these cold starts can be problematic. And so what are some of the ways that we can minimize the impact of a cold start? Well, we already learned about provisioned concurrency, and how that can be used to proactively create execution environments. But one of the other things that we can do, if we go back to Lambda, and we go to our Lambda function, is we could configure it with more memory. So if we go to our Invocation Lambda function, and we go to Configuration, this Lambda function is not using its maximum memory, and I'm giving it 128 megs of memory, I would guess it's probably using about 30 megs of that. So there's no way it's touching its maximum memory. But if I were to increase the amount of memory, I'm also increasing the amount of CPU and the amount of network bandwidth. And so when this Lambda function is launched for the first time and is executed, that may help the execution environment be prepared more quickly. Now, there's a pretty big downside to that, because now anytime this Lambda function is invoked, I'm paying a higher cost. With Lambda, you pay for the number of invocations. You pay for the number of milliseconds that the Lambda function runs, and the amount that you pay per millisecond depends on how much memory you've allocated. The more memory you allocate, the higher price you pay. So you don't want to just casually increase the amount of memory on a Lambda function to avoid those cold starts unless you absolutely must. And even if you do increase the memory, it doesn't truly avoid the cold start. It may just minimize the impacts of it.