Preview Release of the new AWS Tools for PowerShell

#Amazon #AWS

In 2012 we announced the first version of the AWS Tools for PowerShell module for Windows PowerShell, containing around 550 cmdlets supporting 20 or so services. In the years since, the growth of AWS has expanded the module to almost 6000 cmdlets spanning 160+ services, plus an additional (but identical) module for users of PowerShell 6 or higher that is capable of being run cross-platform.

There are downsides to putting all those cmdlets into a single module (AWSPowerShell for PowerShell v2 through v5.1 on Windows, AWSPowerShell.NetCore for PowerShell v6 or higher on Windows, macOS, and Linux). First, the import time of the modules has grown significantly. On my 8th Gen Core i7 laptop the time to import either module has grown beyond 25 seconds. Second, the team discovered an issue with listing all of the cmdlets in the module manifests and subsequently had to revert to specifying ‘*’ for the CmdletsToExport manifest property. This prevents PowerShell from determining the cmdlets in the modules until they are explicitly imported, impacting tab completion of cmdlet names.

In my shell profile I use the Set-AWSCredential and Set-DefaultAWSRegion cmdlets to set an initial scope for my shells. Thus I have to first explicitly import the module and then wait for the shell to become usable. This slow load time is obviously unsustainable, even more so when writing AWS Lambda functions in PowerShell when we particularly want a fast startup time.

Announcing the Refactored AWS Tools for PowerShell Modules (Preview)
Today the team released a new set of modules to the PowerShell Gallery to address this issue. These modules are in preview so that the team can gather your feedback (good or bad) which we hope you’ll give!

In the preview release each AWS service now has its own PowerShell module, all depending on a common shared module named AWS.Tools.Common (this is the same modular approach that we take with the AWS SDK for .NET on NuGet). This has a number of implications:

Instead of downloading and installing a single large module for all services, you can now install only the modules for services you actually need. The common module will be installed automatically when you install a service-specific module.
You no longer need to explicitly import any of the preview modules before use, as the CmdletsToExport manifest property for each module is now properly specified.
The versioning strategy for the new modules currently follows the AWSPowerShell and AWSPowerShell.NetCore modules. The strategy is detailed on the team’s GitHub repository notice for the preview and we welcome your feedback on it.
Shell startup time is fast! On the same system I noted earlier the load time for my command shells is now between 1 and 2 seconds on average. The only change to my shell profile was to remove the explicit module import.

The new modules follow the name pattern AWS.Tools.ServiceName. In some cases the more common contraction is used for the name. For example:

AWS.Tools.EC2
AWS.Tools.S3
AWS.Tools.DirectoryService
AWS.Tools.ElasticLoadBalancingV2
AWS.Tools.Polly
AWS.Tools.Rekognition
etc

If you are writing PowerShell functions for AWS Lambda, be sure to update your script dependencies (using the #Requires statement) to use the new modules. You also need to add a #Requires statement for the common module. For example if I am writing a Lambda function in PowerShell that uses Amazon Simple Storage Service (S3) then I need to add the following two statements to my function’s script file:

#Requires -Modules @{ModuleName='AWS.Tools.Common';ModuleVersion='3.3.563.0'}
#Requires -Modules @{ModuleName='AWS.Tools.S3';ModuleVersion='3.3.563.0'}

Mandatory Parameters
The team has also addressed another long-standing and popular request from users – that of marking parameters as mandatory. Mandatory parameters are a great feature of PowerShell, helping guide users who are unfamiliar with APIs, and we’re very pleased to now be in a position to support them. The marking of mandatory parameters is dependent on data in the service models so if you discover any issues please let the team know in the link at the end of this post so that they can investigate and have the service models corrected if need be.

Other Preview Changes
The development team has also taken the opportunity to remove some old and obsolete cmdlets. If you need to use any of these removed cmdlets you will need to continue using the existing modules for the time being, but be sure to raise an issue on GitHub so that the team can consider supporting them in the new version:

CloudHSM (HSM) is removed in favor of CloudHSMV2 (HSM2)
ElasticLoadBalancing (ELB) is removed in favor of ElasticLoadBalancingV2 (ELB2)
CloudWatchEvents (CWE) is removed in favor of EventBridge (EVB)
KinesisAnalytics (KINA) is removed in favor of KinesisAnalyticsV2 (KINA2)

What happens to the AWSPowerShell and AWSPowerShell.NetCore modules?

Nothing! These modules will remain and will be updated in sync with the preview for the foreseeable future. Backwards compatibility is taken very seriously at AWS and we don’t want to deter use of these modules until we know the community is happy with the replacements.

Note that you cannot mix the two different sets of modules. For example if you have the AWSPowerShell (or AWSPowerShell.NetCore) module loaded then an attempt to load modules from the preview will fail with an error.

Get involved!

The new preview modules are now available in the PowerShell Gallery and more details about the release can be found in Matteo’s notice on GitHub. The development team is eager to hear your feedback on the preview – do you like (or not like) the new modular format? Have you encountered any issues with the new support for marking mandatory parameters? Any other backwards compatibility issues you’ve found? Thoughts on the versioning strategy that should be adopted? Be sure to let them know on their GitHub issues repository!

— Steve