Howdy, gang! 
Introduction
I’ve just worked on an AWS Lambda ticket, and I want to share the experience with you.
It’s super easy to Deploy with Harness. But this customer needs to configure Provisioned Concurrency.
I’ve seen a lot of async architectures with SNS + SQS + Lambda, but this use case is different.
This guy is focusing on reducing the RTT/Latency of that request.
We already have a Feature Request (enhancement, tbh) to expose that natively, ok?
But let’s not wait:
Since our Delegate is capable to interact with AWS resources via CLI, by using the Instance Profile (Role) permissions, or even IRSA (EKS, for example), let’s take advantage of that!
Buckle up!
Tutorial
Requirement
Your Delegate must be capable of interacting with your AWS Lambda Service, ok?
First Step
Let’s deploy this dummy Lambda:
The first thing I do is to create a good Delegate Profile to install AWS CLI to my Delegate.
This is the shell script. I checked that this works with the K8s StatefulSet Delegate as well.
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
./aws/install
Go ahead and apply that one to your favorite AWS Delegate. In my case: EC2 as usual.
Second Step
Now we must ensure that my Delegate is capable of dealing with Lambda Services.
Just in case, right?
I have a Power User IAM Role in my Delegate, but we can test it with something like this:
Build Workflow → Shell Script:
#!/bin/bash
echo "This is just a test"
aws s3 ls
aws lambda list-functions
Third Step
Ok, so let’s create a Workflow.
The first step is to Deploy the Lambda;
the second is to configure that lambda via API.
I will start by creating a good Workflow variable to handle our Lambda Name:
Then I’ll use it on the Lambda Service, to override the name:
Fourth Step
The next step is to add a Shell Script that will call our config Function.
I’ll add a new Workflow Variable to handle the desired provisioned-concurrent-executions.
Also, I’m not a super Lambda Pro, and I’m not sure why we need that alias to use on the CLI command as a qualifier. Maybe there’s a latest or something, but we can take advantage of our Variables as well.
So this is my Shell Script:
#!/bin/bash
aws lambda get-function --function-name ${workflow.variables.LambdaName}
aws lambda put-provisioned-concurrency-config --function-name ${workflow.variables.LambdaName} --qualifier ${workflow.variables.LambdaAlias} --provisioned-concurrent-executions ${workflow.variables.provConcurrentExecs}
Fifth Step
Now, just remember to use that Workflow Variable at the Alias config in the Lambda step:
Sixth Step
Pretty easy, right? Let’s check that out!
This is my very small Workflow:
Let’s run it!
Nice!
Let’s check it at AWS Console:
And we’re done!
Outcome:
Now you are not afraid of AWS Lambdas and Harness, I hope.
Further reading:
Tags:
<cloud: aws, lambda>
<function: ci,cd>
<role: swdev,devops,secops,itexec>
<type: howto, experts>
<category: lambda, gitops, variables, aws, deployment>