top of page
Writer's pictureTenaka

PowerShell's Custom Runtime for AWS Lambda's - Importing Modules

Welcome to the second part of the installation and configuration process for the AWS Custom Runtime for PowerShell


Recap

In the first part, we covered the installation process of AWS's Custom Runtime for PowerShell, which involved deploying Windows Subsystem for Linux (WSL) and initializing the Runtime and deploying the Demo Lambda Function.


Here's the link. with instructions on how to instal WSL and deploy the Custom Runtime.


What's in Part 2

The first part left on a bit of a cliffhanger, functionally, the Custom Runtime for PowerShell worked, but without additional modules, there's very little that could be accomplished.


The subsequent steps entail the creation of Lambda layers that incorporate additional modules, which will be utilized in Lambda Functions to finalize the end-to-end deployment process.


Copy and Paste

Upon completing this process, the objective is to successfully deploy a Lambda Function equipped with a layer containing both the AWS.Tools.Common and AWS.Tools.EC2 PowerShell modules. This will enable the ability to start and stop an EC2 instance within the AWS environment.


Continuing where we previously left off, we are going to utilise the work that has already been completed by AWS, by amending an existing example.


Before we start, only 5 layers can be added to a Lambda Function, but a layer can contain multiple modules.


Change the directory into the AWSToolsforPowerShell directory.

cd /Downloads/aws-sam/powershell-modules/AWSToolsforPowerShell


Copy the existing S3EventBridge directory.

cp AWS.Tools.S3EventBridge AWS.Tools.EC2 -r

cd AWS.Tools.EC2


Amendments

The 3 files that will require amending to successfully publish additional modules as layers are:

  • build-AWSToolsLayer.ps1

  • template.yml

  • /buildlayer/make

The process is straightforward, find and replace all references to the current module functionality with the new module functionality.


Although updating build-AWSToolsLayer.ps1 is not strictly essential since we'll be relying on the Make command, taking a few seconds to do so ensures consistency among all the files involved.


nano build-AWSToolsLayer.ps1

Ctrl + o to save (output the file)

Ctrl _ x to exit nano


Add additional lines for modules that are to be extracted from aws.tools.zip.


Note: It is crucial to ensure the correct ordering of modules, with AWS.Tools.Common listed before the module for EC2. The EC2 module relies on the functionality provided by AWS.Tools.Common.

In the original S3EventBridge version of template.yml AWSTools.EC2 read S3EventBridge.


Ensure !Ref values are updated from AWSToolsS3EventBridgeLayer to AWSToolsEC2Layer, this value is passed between files and needs to be consistent.


Save and exit template.yml.

cd buildlayer


nano Make


The first line references !Ref and it must be consistent with the value set in template.yml.


Modify the unzip commands to accommodate any supplementary modules.


Save and exit Make.


Build and Deploy

After each amendment to the configuration files, the content must be redeployed in order to reflect the changes made:

sam build


To publish to AWS run the following:

sam deploy -g


Layers and a Lambda

Login to AWS Lambda and confirm the new layer has been created.

Let us bring the entire Custom Runtime endeavour to fruition, by creating a new Lambda Function designed to initiate the start of an EC2 Instance, by clicking Create Function.

Name the function and select the Amazon Linux 2 Runtime.


Ensure the Architecture is set to x86_64.


'Create a new role with basic Lambda permissions' is also selected.


Create Function

Within the Function Overview click on Layers, then Add Layers.


Select Custom Layers and then add in order:

PwshRuntimeLayer

AWSToolsEC2Layer

PwshRuntimeLayer is listed first, followed by any modules.

Click Configuration and Edit


Update memory to 512Mb and timeout to 1 minute.

Before saving the configuration updates, open the IAM link in another browser tab to grant the function the additional permissions required for execution.

Within IAM, add AmazonEC2FullAccess and AWSLambdaExecute to the Role.

Navigate back to Lambda and then select Code.


Update the Runtime Settings Handler information to reflect the name of the PowerShell script followed by "::handler". In this example, the handler will be "Start-Ec2.ps1::handler"

Navigate back to Code and delete all the default files.

Right-click on the folder and New File, rename to "Start-Ec2.ps1".


Copy and paste the provided script, and make sure to modify the Reservation ID with the ID of your own EC2 instance.

Start-EC2.ps1

#$VerbosePreference = "continue"

#$VerbosePreference = "SilentlyContinue"

Write-Verbose "Run script init tasks before handler"

Write-Verbose "Importing Modules"

Import-Module "AWS.Tools.Common"

Import-Module "AWS.Tools.EC2"

function handler

{

[CmdletBinding()]

param(

[parameter()]

$lambdaInput,


[parameter()]

$lambdaContext

)

Get-EC2Instance | where {$_.ReservationId -eq "r-06856f1f55c199e49"} | Start-EC2Instance

}

Deploy the changes.


Click Test

Complete the Configure Test Event by providing an Event Name.

Navigate to the Test tag and click Test to execute the Lambda Function.

I'm hoping this guide provides a starting point for further modules and functionality, especially those that come from a native Microsoft background. I wish to thank everyone for their time and any feedback would be gratefully received.




27 views0 comments

留言

評等為 0(最高為 5 顆星)。
暫無評等

新增評等
bottom of page