Welcome to the AWS series that will discuss AWS tools for Windows PowerShell. The first article of the series will discuss the following:
- Introductory notions about PowerShell
- Installation of AWS tools
- Configuration of AWS tools
The second part of the series will provide a few examples on how AWS tools for Windows PowerShell can be used in conjunction with AWS services.
VMware Training – Resources (Intense)
First, what is Windows PowerShell? It’s very likely that although you have used Windows for many years, you never saw this mentioned. PowerShell is an automation and configuration management framework from Microsoft. It allows administrators to perform tasks to local or remote Windows machines.
PowerShell uses cmdlets which are actually operations. The cmdlets can be combined in scripts.
So what are AWS tools for PowerShell then? They are very simple. They are a set of PowerShell cmdlets that allows you to manipulate the AWS services from the PowerShell command line. The AWS tools come together with the AWS SDK for .NET. Whatever you can do with the SDK, you can do it using PowerShell.
So let’s go ahead with the installation. To be able to install AWS tools, you need to run Windows XP or later and PowerShell 2.0 or later. Right now, the latest PowerShell release is 5.0. Windows 7 and Windows Server 2008 R2 comes with PowerShell 2.0. Newer Windows releases have newer PowerShell versions. For older releases (for instance Windows XP), you would have to manually install PowerShell.
If you plan to use AWS tools for PowerShell from a Windows AMI, then you don’t need to do anything. They come preinstalled.
Let’s check what release of PowerShell we have installed and what modules we have (this is for later comparison after AWS tools will be installed). Use these commands from PowerShell: “$psversiontable” and “Get-Module –ListAvailable”:
As you can see, I have version 2.0 (the default one) and there is no reference about AWS tools module being installed.
You can go ahead and download the AWS tools from AWS website from here.
After you installed it, you need to load the AWS module. To do this, you need to enable PowerShell script execution. You need to run this command at the PowerShell prompt with Administrator rights: “Set-ExecutionPolicy RemoteSigned”. Once you do it, you will notice that PowerShell is aware of the AWS module:
But this is still not enough. Because we are running PowerShell 2.0, we need to load the AWS module manually. To confirm if the module was successfully loaded, we need to run the command “Get-Module”. Check the output of this command before and after the module was loaded:
Of course, you would have to do this every time you start a new PowerShell 2.0 session. You can configure it to be added automatically every time you start a PowerShell 2.0 session. How can you do that? PowerShell has its own profile. You need to edit the file that contains the profile and add the AWS module. There are variables that contain the profile:
PS C:\Windows\system32> echo $profile
Just edit this file by adding the AWS module. It’s very likely (as in my case as well), that the folder and the actual file didn’t exist. You would need to create them.
Basically you would need to add this line to the profile file:
import-module “C:\Program Files (x86)\AWS Tools\PowerShell\AWSPowerShell\AWSPowerShell.psd1”
You don’t need to use the above procedure (adding the AWS module either each time you start a PowerShell session or load the module in the profile) if you are using PowerShell 3.0.
Once we did all this, we can check what AWS tools version we are using and what services can be accessed by this version. We can use this command “Get-AWSPowerShellVersion –ListServices”. If “-ListServices” would have been omitted, then only the AWS tools version would be shown:
Now that we are done with installation and initial configuration of AWS tools for PowerShell, it’s time to go ahead and use them.
One thing you should always be aware of is that each PowerShell Tools command must contain AWS credentials. You can specify the credentials each time when you issue a command or only one time for each new session or only one time for all future PowerShell sessions. As you might already have figured out, it’s not too safe to use the credentials (literal the credentials) in every command. The alternative is to configure the credentials within a profile and then reference the profile for each PowerShell command.
There are two different credentials stores:
- * SDK store – this encrypts the credentials and stores them in the home folder
- * Credentials store – stores the credentials as plain text in the home folder
Let’s see how you can create a new profile and use SDK store. This is how you create the profile:
“Set-AWSCredentials -AccessKey AKIAJO2QSLZUZZC3SFBQ -SecretKey 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 -StoreAs profile-1”
And this is how you list the profiles:
To remove the profile, use “Clear-AWSCredentials -StoredCredentials profile-1″.
When you issue a command, as I mentioned, you need to specify the credentials. There is a preferred order of choosing the credentials. This is the preference:
- * Use the credentials provided in the command
- * Use the credentials from the profile name specified
- * Use the credentials from the –Credentials parameter
- * Use the credentials from the session profile
- * Use the credentials from the default profile
- * Use the credentials from the EC2 instance credentials in case the command is run from an Amazon EC2 instance
There are multiple ways to specify the credentials and a few of them are widely used.
One of them is to use the default profile that will be used for every PowerShell session. Use this command to do this: “Initialize-AWSDefaults -ProfileName profile-1”. Byusing this command, you will be asked to set the default region as well:
Another method is to specify the credentials only for the current PowerShell session. You can do it using this command: “Set-AWSCredentials -ProfileName -profile-1”:
The last common method is to use the credentials in the command profile like this: “Get-EC2Region -ProfileName profile-1”. Bear in mind that “Get-EC2Region” is a specific command related to EC2. You might as well use something else.
Below you have an output on how to set the credentials for the last two methods:
You noticed that when we used the first method to set the credentials, we were asked for a default region. This is because most of the cmdlets requires a region to be specified. If you don’t specify a region in the command, then PowerShell assumes you are talking about the default region.
You can set the default region like we did above or by using “Set-DefaultAWSRegion” command. Let’s check the current default region and then change it and check the default region again:
You can override the default region by using “-Region” within the command.
There are hundreds of cmdlets that you can use with AWS tools. To find all the commands, you need to run this command: “Get-Command -Module AWSPowerShell”. This might be too much and you can restrict the search by using “Select-String” like below. In this command, we narrowed the search only to the commands that work with volume:
One other useful feature of AWS tools is that you can use aliases. You can configure a name that is more descriptive to you for a PowerShell cmdlet. Then you can use the alias to perform the same function as you would run the PowerShell cmdlet.
Another feature that you can use is pipelining. Pipelining allows you to use objects returned from a command to be used as parameter for another one. For instance, this command will stop all the EC2 instances from EU-WEST-1 region: “Get-EC2Instance -Region eu-west-1 | Stop-EC2Instance”.
And we reached the end of the first part of the series.
By reaching this point, you should know how to install AWS tools for Windows PowerShell and how to load the AWS module in PowerShell. Also you should know how to set up the credentials and how to do the initial configuration of AWS tools. You should be also aware of some features (which are not specific to AWS tools, but to PowerShell) like aliases and pipelining.
The second part of the series will discuss some advanced topics like how to use the AWS tools to work with AWS services.