Day 29: An Introduction to Amazon Web Services and PowerShell

Welcome to Day 29 of the “100 Days of DevOps with PowerShell” ! For background on our goals in these articles, see Announcing the “100 Days of Devops with PowerShell” Series here at SCC.

In this post I  am going to take you through getting started with the PowerShell cmdlets that provide support for Amazon Web Services (AWS).

DISCLAIMER: Before we begin, I’m not going to go into detail on how to create an AWS account, there are plenty of resources available to walk you through this process.  Nor am I going to explain in detail the various features of AWS and how they may or may not differ from Azure.  Again there’s been plenty written already on this topic.

Getting Started with PowerShell and AWS.

The PowerShell cmdlets for AWS are always at the same URL, so you can always grab the latest version.  Picking up on what we’ve learnt in the past we  know we can install the AWS PowerShell cmdlets as a package a number of different ways, either via Chocolatey (Day 4) or with OneGet (Day 11).  For now, lets use the PowerShell code below and also take the extra step of including the tools into our PowerShell profile:

Once the PowerShell AWS tools are installed, a quick count of the cmdlets shows us that in version 2.2.4 (use Get-AWSPowerShellVersion to verify the version) there are a whopping 925 cmdlets and there is pretty much complete coverage of the AWS services via the PowerShell tools.

GetCommands

The reason for the extensive coverage is that the PowerShell AWS tools are on the same release cycle as the AWS .Net Framework SDK, in fact many of the cmdlets are code generated from the SDK.  That being said we’re going to concentrate on using same of the core cmdlets to deploy and manage some EC2 instances.  Before we start deploying some instances (in AWS parlance an instance is a virtual machine) via PowerShell  there are a few steps you need to take:

  • We need to have an access key and secret key – please follow the steps in Getting Your Access Key ID and Secret Access Key
  • We need to generate a key pair  – a key pair is used to encrypt the Windows administrative password when you deploy a new instance.  Creating a new key pair generates a public key  which AWS keeps and will use to encrypt the random Windows administrative password. The key pair that you download contains the private key that will be used to decrypt the password.

To create a key pair either follow the steps in the web console: Creating your own key pair using Amazon EC2 or you can use PowerShell:

CAUTION: Ensure this file is backed up in a secure location.  If you deploy instances using the specified key pair and you no longer have access to the pem file, you will not be able to decrypt the Windows password and logon to the server.

AWS Regions

AWS has multiple independent regions across the globe to provide high availability and low-latency response times for users.  The cmdlet Get-EC2Region will show the available regions:

Regions

Each cmdlet has support for specifying a region, so if you wished deploy instances in the Europe data center as opposed to one of the US data centers (us-east-1, us-west-1, us-west-2), you would specify eu-west-1.  This is particularly important if the data and the applications you are dealing with have specific sovereignty rules.

AWS Images

With our access and secret keys in hand, as well as our key pair, lets see if we can retrieve a list of AWS provided Windows images or as they known in AWS, Amazon Machine Image (AMI) and we can then use that image to deploy a fresh instance.

GetImagesError

The error “No credentials specified or obtained from persisted/shell defaults” means we have not specified the the access key and secret key when running the Get-EC2Image cmdlet.  This cmdlet has both –AccessKey and –SecretKey parameters, in fact all the AWS cmdlets have these parameters.  Rather than specifying them each time we call a cmdlet, we can set them as defaults, along the region that we want to work with.  Specifying the region for retrieving AMIs is particularly important, because although each region will have the same AWS provided images they will have different image ids and it’s the image id you specify when deploying your instances.  To set default access key, secret key and region we can use the following:

Using Initialize-AWSDefaults allows these settings to be persisted across PowerShell sessions and reboots.  If you wish to remove them, you can use the Clear-AWSCredentials cmdlet.

AWS provides hundreds of AMIs (actually 801 at last count!), so it makes sense to be able to filter out the ones we’re going to be using for our deployments.  Rather than retrieving all 801 AMIs and then using the Where-Object on the results, we can use the filter parameter and pass the names and values as a hash table and allow the filtering to be done on the server side.  To see what we can filter on we can bring up properties of the base Windows Server 2012 base image:

BaseImage

Note the date at the end of Name is 2014.08.13 which means that the August Microsoft updates have been included in this image.  The command above actually returns the image details for July’s updates as well, so there are two versions of this image you can deploy.

Using AWS Filters

To demonstrate how we can use filters is key to using the AWS cmdlets because they can save you a lot of time.  In the example below we’re retrieving all AWS provided images (-Owner amazon) and in the filter we’re specifying Windows operating systems and also for the 64-bit platform.

CAUTION: When specifying the names and values it is case-sensitive.  So although the above example showed “Platform : windows”, you must use the lower case “platform”.

ImageResults

Conclusion

This has been a gentle introduction to AWS PowerShell Tools and how to get started.  In the next post we’ll use the Image ID we retrieved above to deploy a new instance and then use the key pair we created to retrieve the Windows password allowing us to connect.  Please let me know if you have any questions in the comments below!

3 thoughts on “Day 29: An Introduction to Amazon Web Services and PowerShell

  1. Wilson W.

    There are a number of Powershell scripts that Amazon makes available that allow you to collect and upload performance metrics into CloudWatch.  Those powershell scripts run locally within the instance and require a set of IAM credentials in order to upload the data into CloudWatch.  What do you recommend to be the best way to securely store those credentials?

  2. Luke Swords Post author

    Hi Wilson,

    I think this issue is not unique to CloudWatch but part of a bigger picture of how you secure credentials with PowerShell.  A good starting point is to have a read of Dave Wyatt’s post on this:http://powershell.org/wp/2013/11/24/saving-passwords-and-preventing-other-processes-from-decrypting-them.

    Specifically with AWS I use least privilege wherever possible, so the CloudWatch credentials only has access to CloudWatch and does not have a password set for console access.  You could also explore creating a role where instances have permissons to call AWS services on your behalf, although I haven’t tested to see how feasible this is: http://aws.amazon.com/blogs/aws/iam-roles-for-ec2-instances-simplified-secure-access-to-aws-service-apis-from-ec2/

    Thanks,

    Luke

  3. Wilson W.

    Ah yes, thanks for pointing me in the right direction. Apparently assigning an AWS role with the right permissions to upload data to CloudWatch is the way to go. That completely eliminates the need to have your Powershell scripts reference any kind of IAM credentials.

    One gotcha to keep in mind: AWS roles need to be defined when the instance is first created. They cannot be assigned retroactively. So if your instance doesn’t have a role assigned to it when it was first created you won’t be able to go back and assign a role to it afterwards.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.