top of page
Search

PowerShell's Custom Runtime for AWS Lambda's - Installation

Introduction

PowerShell custom runtime for AWS Lambda is an addition to the AWS Lambda services, offering developers and Microsoft engineers the ability to leverage PowerShell within the serverless environment. Unlike the standard runtimes supported by AWS Lambda, which include languages like Python, Node.js, and Java, the PowerShell custom runtime, developers can now build and deploy Lambda functions using their existing PowerShell skills.

It allows for the integration of PowerShell's vast library of cmdlets and modules, enabling developers to leverage a wide range of pre-built functions and automation tasks. PowerShell's object-oriented scripting approach also provides a means for manipulating and managing AWS resources, making interacting with other AWS services like Amazon S3, Amazon DynamoDB, and AWS CloudFormation easier.


Additionally, it's now possible to edit the PowerShell script directly within the published Lambda, which was not previously possible.


The Truth of the Matter

The issue, it's PowerShell, any real DevOps will be using anything but PowerShell as it's a scripting language, so there's limited support for PowerShell on AWS. However, if you're a Microsoft engineer who needs to manage the Windows Infrastructure on AWS then PowerShell will be your go to scripting language for Lambda functions.


The PowerShell custom runtime setup provides 3 options for deployment, Linux or WSL, native PowerShell and Docker. The native PowerShell deployment doesn't work, at least I couldn't get it working and others have faced similar issues, with no resolution provided.


The good news is that Windows Subsystem for Linux (WSL) deployment does successfully deploy and execute and this is what I'll be using.


Requirements

WSL 2 requires the Hyper-V Hypervisor, this rules out any AWS EC2 instance, Hyper-V isn't supported.


A Windows 2022 or Windows 11 with the latest patches installed is required. I've Windows 11 installed on a Zenbook Space Edition laptop with the Hyper-V feature installed and virtualization enabled in the system's BIOS or UEFI.


WSL 2 isn't directly installed on the laptop, it can be, I prefer keeping my clients free of clutter and instead opted for a Windows Server 2022 Hyper-V vm. Any issues the vm will be rolled back or redeployed.


Now deploy a Gen2 Windows Server 2022 Hyper-V image named, ensure the latest Windows updates are applied.


AWS Configuration

An account named 'svc_lambda' has been created with Administrative access in IAM. The excessive rights are for ease of deployment, the permissions will be adjusted to those needed later.

The account's Access and Secret have been exported for use during the creation of the PowerShell Runtime Lambda.


Installation of Windows Subsystem for Linux version 2

WSL version 2 was not supported by Server 2022 or Windows 11 at release. Install the latest Windows patches to enable WSL2 support. I may have mentioned this a few times now.


Power off the VM and from the host open an elevated Powershell session. Then type the following command to enable nested hypervisor. AWS-Mgmt01 is vm's name in the Hyper-V console and not its hostname.

Set-VMProcessor -VMName AWS-Mgmt01 -ExposeVirtualizationExtensions $true


Power on, AWS-Mgmt01, login and elevate a PowerShell session and execute the following command. This will install all components and features required. If the command fails to be recognised, then Windows updates aren't applied or the experience I had, they failed to install correctly.

wsl --install

Restart AWS-Mgmt01, log in and WSL should auto launch, if not run wsl --install from PowerShell.

Type in a username and password at the prompt.

Installation confirmation will show that the latest version of Ubuntu and WSL 2 are configured.

In the Linux shell execute the following commands to update and install all required dependencies.

sudo apt update -y && sudo apt upgrade -y

sudo apt install glibc-source groff less unzip make -y


AWS Serverless Application Model Installation

AWS SAM (Serverless Application Model) is a framework provided by AWS that simplifies the development, deployment, and management of serverless applications. It extends the capabilities of AWS CloudFormation, allowing developers to define serverless application resources using a simplified YAML syntax and is next to install.


Type pwd and it will return '/home/user'.


Type: mkdir Downloads to create a working directory and cd into the directory.


Download the SAM client for Linux, unzip and Install.


unzip aws-sam-cli-linux-x86_64.zip -d sam-installation


sudo ./sam-installation/install


Confirm version and successful installation.

/usr/local/bin/sam --version

Download the AWS Client for Linux, unzip and Install


unzip awscli-exe-linux-x86_64.zip


sudo ./aws/install


Confirm version and successful installation.

/usr/local/bin/aws --version

Download the AWS Lambda PowerShell Runtime.


mv aws-lambda-powershell-runtime/ aws-sam


cd aws-sam/examples/demo-runtime-layer-function

Export the access and secret keys for the Lambda service account via AIM.


Configure access for the Lambda-Svc user.

aws configure

AWS Access Key ID [None]: AKIA5IZEOZXQ4XXXXX

AWS Secret Access Key [None]: 2O8hYlEtAzyw/KFLc4fGRXXXXXXXXXX

Default region name [None]: us-east-2

Default output format [None]:

Build the custom runtime .

sam build --parallel

Deploy Custom Runtime to AWS.

sam deploy -g

Stack Name [sam-app]: PowerShellLambdaRuntime

AWS Region [us-east-2]: us-east-2

Confirm changes before deploy [y/N]: n

Allow SAM CLI IAM role creation [Y/n]: y

Disable rollback [y/N]: n

Save arguments to configuration file [Y/n]: n

The deployment will take a few minutes as it creates CloudFormation, an S3 bucket and finally the Lambda.

Testing the Runtime Lambda Function

From the AWS console, open Lambda and browse to Functions to confirm the successful deployment of the PowerShell Runtime Demo.

It's at this point when native PowerShell is used, the whole runtime falls apart and fails to execute.


Click on Test after reviewing the PowerShell code. This is a first not only can it be viewed, it's editable.

Add an Event Name and Save.

Click on Test and review the details.

The Runtime is installed, but not much else.....

This is just the beginning and a bit of a problem if you thought that it was a simple matter of creating new Lambda's and applying PwsRuntimeLayer. I'm the bearer of bad news, let me explain.


Two layers were created for the demo, the DemoAWSToolsLayer and PwshRuntimeLayer.

For PowerShell, the correct modules need importing and these are supplied in the Lambda layers. In this case, it's the DemoAWSToolsLayer that loads the required module for the Lambda demo. And in the Demo's case, it's only the AWS.Tools.Common module needed by the function to the Get-AWSRegion.


Consequently, additional layers containing the necessary modules for the function are required. For instance, to create a Lambda function to stop an EC2 instance, both the AWS.Tools.Common and AWS.Tools.EC2 modules are needed. We will delve into this in the next blog (here).


Links





31 views1 comment
bottom of page