Write great AWS Lambda PowerShell functions

In this post, I share some tips I use when I write AWS Lambda PowerShell functions. You can find lots of help writing .Net end user functions for Lambda. By end user, I mean things that are part of an application system, like kicking off Glue jobs, working with Redshift and so on.

But what about admin tasks? PowerShell was originally conceived as an administrator’s language so it excels at common admin AWS tasks, especially those associated with IaaS applications like creating AMIs (though you might also consider DLM), updating security groups with newly propagated BGP routes and more.

What makes PowerShell so attractive for Lambda functions is that it has full logic capabilities plus all the .Net core classes. And AWS does a remarkable job of keeping the AWS PowerShell cmdlets up-to-date. So, a Lambda function in PowerShell has all the power of a scripting language, plus all of .Net and all the current AWS capabilities.

Tip #1

Use Publish-AWSPowerShellLambda just once. Use it just once to get the “bare bones” of the function set up in AWS. You can see an initial upload in the screenshot below.

After that, a much better workflow is to use New-AWSPowerShellLambdaPackage. As shown in the screenshot below, this will create a .zip of the function. Uploading the .zip will not change the function’s external settings in Lambda, which is a good thing if you want to take advantage of Tips 2 and 3.

Tip #2

Use separate SNS topics for end-user and diagnostic notifications. Admin scripts doing maintenance and making changes to the environment almost always need to notify users of what happened (“Your AMI is gone!) and also provide a log of what happened when the function ran in case of errors.

Here you see two separate SNS topics set up, with the one for end users (“output”) using the email style notification and the one for the admin (“execution”) using JSON style email. Tip 3 discusses how to use the execution SNS topic to good effect; I’ll discuss the end-user SNS topic in another blog post soon.

Tip #3

Use the “execution” function destination for success/failure logging. Sure, you can Write-Host during function execution to log anything you like to CloudWatch. Maybe it’s old-school, but I prefer being notified by email (where I spend a lot of time anyway) over having to seek the info from among many CloudWatch log groups.

It’s up to you to decide if you want both success and failure notifications (I always do both and filter them into folders in my messaging app). But you will come to rely on the SNS notifications as the first place to go to see “what happened.”

Once you set up the destination, here’s how you might use the messaging capability. I’m a fan of inspecting $AWSHistory, so this code shows a dirt-simple pwsh function that logs $AWSHistory.LastServiceResponse into an array and then at function termination, uses Publish-SnsMessage to send it to topic subscribers.

$responses = @() # Define array to hold $AWSHistory responses 
#region Function to create an array of output lines to be written to SNS
function snsWriteLine
{
    param (
        $l
    )
    $obj = New-Object -TypeName psobject 
    $obj = $l
    return $obj
}
#endregion
# Using the function after an AWS cmdlet call
$amis = Get-EC2Image -Owner self | Sort-Object -Property CreationDate # Get collection of AMIs created by this account
$responses += awsResponses $AWSHistory.LastCommand
.....
# At the function's end, put the array on the pipeline, which causes AWS to write it to the "destination"
(ConvertTo-Json -InputObject $responses -Compress -Depth 99) # Make SURE this is the last statement to put anything on the pipeline

This code adds the last response object to an array, then at function end converts that to JSON and pushes it to the pwsh pipeline. Lambda then sends that to the destination noted in Tip #2 and, voila!, automated notification of what happened in your function is in place for both failure and/or success.

One caution: these responses can add up, so use the destination logging judiciously. If you log more than 6MB of JSON objects, your Lambda function will terminate with an HTTP 413 error.

That’s it for this post…I have more that I’ll get to soon. Let me know in the comments what you think.