Refactor AWS Lambda Functions to Use Arm/Graviton2 Architecture in CDK
We are repeating the same pattern across all of our lambda functions. We can extract the common parts into their own constant to save ourselves some time.
By generalizing the repeated code we have now made our app easier to refactor. Let's take advantage of that by refactoring our Lambda functions to use the Arm/Graviton2 architecture which enhances cost performance by 20%.
All you have to do is add an architecture prop to your lambda config with a value of lambda.Architecture.ARM_64
Tomasz Łakomy: [0:00] If we take a look at the definitions of our Lambda functions in CDK stack, you may notice that those props are quite similar. For instance, the environment variables are basically the same, as well as the runtime. In order to avoid repeating ourselves, let us extract all those props to a common object.
[0:17] In order to do that, above all of our Lambda functions, I'm going to create a commonLambdaProps. That is an object of type lambda.FunctionProps. The only thing that is truly unique about all of those functions is the handler. I'm going to copy everything else. I'm going to get all of that, paste that here, and remove the handler.
[0:37] TypeScript is complaining because handler is not defined in this object, but would like only the common parts to be in this object, and the handler is not exactly one of them. I'm going to change the type of this object to Omit<lambda.FunctionProps>, and I'm going to omit the "handler".
[0:52] Omit is a type that is provided by TypeScript, and it allows you to take a type -- in that example, the FunctionProps -- and omit one of its fields. In this case, this is the handler.
[1:03] With that prepared, I can go ahead and use these common Lambda props in all of those other Lambda functions. I can just spread all the common Lambda props. Let me repeat that for other Lambda functions, over here and also over here.
[1:21] Now, all of our Lambda functions are sharing those common Lambda props. For instance, if I wanted to bump the memory size of our Lambda functions, I can do that in a single place. In fact, let us try something.
[1:33] AWS has recently announced that AWS Lambda functions can be powered by AWS Graviton2 processor, which allows us to achieve up to 34 percent better price performance. This is good news because with Lambda, you are charged based on the number of requests for your functions and the duration. That is, the time it takes for your code to execute.
[1:53] If I switch to this brand-new architecture, the duration changes are 20 percent lower. This is a cost reduction with a single line of code. Let's give it a shot. I was not kidding with "a single line of code." The only thing that we need to change is the architecture prop to our common Lambda props. That is going to be equal to lambda.Architecture.ARM_64. That's it.
[2:15] Let us verify our changes. To do that, open up the terminal and run cdk diff. We can see that all of our handlers are going to be using the brand-new architecture for AWS Lambda functions.
[2:27] Changes like those are a huge benefit of CDK because it is very often the case that AWS releases something new and the only thing that you need to do in order to reap benefits from it is to add a single line of code in your CDK stack.
[2:41] Let's double check our stack by deploying it and calling our API. Everything works just fine. After we navigate to our Lambda function in AWS Console, if we scroll down in this createBookHandler page, we're going to see that the architecture was changed to arm64.