Writing PowerShell Core AWS Lambda Functions – Part II


In this second blog, we’ll be setting up our development environment to allow us to create and publish Lambda compatible PowerShell packages. This will involve installing the .NET Core SDK, PowerShell Core and two AWS specific PowerShell modules, namely AWSPowerShell.NetCore and AWSLambdaPSCore. We’ll also spend a bit of time looking at the cmdlets provided with the latter module.

The Story So Far

In the previous blog, we provided a brief overview on the use of PowerShell Lambda functions and how they process incoming and outgoing data. Then, we set about getting the Facebook app and page setup that is going to be used by our PowerShell driven ‘bot.

Now, let’s carry out the installation of the following

      • PowerShell Core 6.0
      • .Net Core 2.1 SDK
      • AWSPowerShell.NetCore Module
      • AWSLambdaPSCore Module

PowerShell Core 6.0

Various installations of PowerShell Core exist, dependent on your distribution platform. A link to installation instructions for each of these is listed below. Note that as part of the installation process, other prerequisites are installed, such as .Net Core.

Installing PowerShell Core on Windows
Installing PowerShell Core on Linux
Installing PowerShell Core on macOS
Installing PowerShell Core on ARM

.Net Core 2.1 SDK

PowerShell Core is built on top of .NET Core. As such, the Lambda support for PowerShell uses the same .NET Core 2.1 Lambda runtime for both .NET Core and PowerShell based Lambda functions. From a functionality point of view, the cmdlets in the AWSLambdaPSCore module ALSO need the .NET Core 2.1 SDK for packaging your functions for Lambda.

You can find the 2.1 SDK and installation instructions for your distribution here:

AWS Modules

We can now install our two AWS modules, AWSPowerShell.Netcore and AWSLambdaPSCore.

A couple of things worthwhile pointing out regards the installation of these modules:

  1. By default the PSGallery is not a trusted source for installing modules. If you have not configured this to be so, you will be prompted to confirm if you trust this source for the installation of a module.
  2. In the Scope parameter for the installation of the modules, I’ve set the value to CurrentUser. You can also set this to Global, but bear in mind if you choose this other option some platforms might require your PowerShell session to be running in an elevated context.

AWSPowerShell.Netcore Module

This module houses, as of version,  4488 cmdlets, split across 125 different AWS services. These are the cmdlets that our solution will offer interactive help on. Suffice to say, I’ll skip giving an overview on the main ones in these!

Launch PowerShell Core from a terminal session via:


Next, to install the module, we use the command below.

Install-Module -Name AWSPowerShell.NetCore -Scope CurrentUser

AWSLambdaPSCore Module

Lastly, we can install the AWS Lambda PowerShell Core module. These cmdlets in this module provide options for reporting available template information, creating your PowerShell script, creating an entire deployment package and the creation of the Lambda function itself.

Use the following command for installation:

Install-Module AWSLambdaPSCore -Scope CurrentUser

Once complete, we can see the current list of commands available in the module via Get-Command.

NB. If you wish to see more extensive information about the cmdlets in the module, such as Scriptblock and ParameterSets, you can use the following to return all properties:

Get-Command -Module AWSLambdaPSCore | Format-List -Property *


Let’s take a look at these commands in a bit more detail:


It’s important to be aware that the source of the input event data dictates its format and properties.

Whilst on a technical level PowerShell does not need to know the schema of JSON data being received before being able to cast it to a PSObject, it is still the case that in order to make effective use of the data therein, you will need to have an idea of how it is organized. Given the growing number of services whose events can be processed by Lambda, this can involve quite a bit of work.

Fortunately, AWS make things a bit simpler for starting out with a PowerShell Lambda function by providing a group of starter templates both offline (as part of the default install of the module) and online that cover some of the event sources/destinations formats that the Lambda function may need to use.

Should you so wish to, you can view them on your browser directly via either of the two URLs below:

As of the date of this blog, these comprise a set of blueprints for the CloudFormation, Code Commit, Amazon Rekognition, Kinesis, S3, SNS, and SQS services. There is additionally a generic template provided, Basic, which ultimately just contains details of the predefined variables for the Lambda context and event source data and details of logging to CloudWatch. You can see the Basic templates content in the HelloWorld example for one of the cmdlets below.

The list of blueprints is actively updated, which is where Get-AWSPowerShellLambdaTemplate assists. It provides a quick point of reference for the templates that are currently available for you to use when creating your solution.

When you execute this cmdlet without any parameters, it queries by default the URLs listed above and then casts the JSON data to a PSObject. If content is not available in either of these two locations, then the locally installed blueprints are returned.

There is also a parameter documented in the help for this cmdlet, InstalledOnly, which is intended to only parse locally installed templates and skip an online check. However, as far as I can see at the moment, this switch is not processed at all.


The New-AWSPowerShellLambda cmdlet is capable of either creating a basic, new Lambda function in a single PowerShell script file, or alternatively an entire project, consisting additionally of project, bootstrap, and parameter default files. The latter option is typically only used for advanced cases where additional manual intervention (e.g. adding additional files, or setting default values for parameters in your function) is required before creating the deployment package and needs to be invoked with the WithProject switch parameter. We’ll being doing all our work in a simple PowerShell script, so for the purposes of this blog will not explore this switch further.

An example of the use of the command and what it does is below:

Creating a ‘HelloWorld’ Lambda based on the Basic template

The ‘HelloWorld’ folder and file structure

‘HelloWorld.ps1’ contents

Subsequent to your work being complete, the script or project can be either directly turned into a Lambda function (using Publish-AWSPowerShellLambda), or put into a state which allows its later deployment via a deployment service, such as Cloudformation, using NewAWSPowerShellLambdaPackage. Details of both are below.


This penultimate cmdlet handles the heavy lifting of taking your script/project, putting it into a state suitable for deployment, and then creating the function itself with the appropriate parameters and with the package uploaded. This step extensively uses the .NET Core SDK, and behind the scenes installs the .NET Amazon.Lambda.Tools package. Once this step is complete, your Lambda function should be accessible to be used as an event handler for another service (Lex in our case).


This cmdlet is used to bundle up a script/project into a package and subsequent zip file that is available for use at a later date by another service or even in a separately defined Lambda project which you configure manually. We’ll not be using this cmdlet during this series of blogs.


At this point, we’ve put in place all the prerequisites for starting scripting of our Lambda function and learnt a bit about the cmdlets provided in the AWSLambdaPSCore module.

In the next blog, we’re going to start on the first stage of our Lex work. It’ll involve setting up a Slot, Intent, and a Channel which will link the ‘bot to the Facebook page created in the first blog. We’ll also cover the event data format, which will link us nicely into the third blog, which involves writing the Lambda function itself.

Thanks for reading! Feedback welcome!