Day 54: Managing volumes in AWS with PowerShell

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

When you provision a new instance with using the New-EC2Instance in PowerShell, a single 30 GB volume is allocated to your instance be default.  On Windows Server 2012 R2, once you start patching the server regularly, along with general usage, you will find that 30GB is a challenging size for the operating system.  Therefore when deploying AWS instances you may want consider creating a slightly larger system partition.

Deploying a larger system partition

In the example below an AWS Windows Server 2012 R2 instance is deployed with a 60GB system partition.  To do this we must create two objects in the process: Amazon.EC2.Model.EbsBlockDevice and Amazon.EC2.Model.BlockDeviceMapping.  The Amazon.EC2.Model.EbsBlockDevice really defines the properties of the volume i.e. its size, its type (what type of storage) and if the volume should be deleted when the instance is deleted.  This is defined by the DeleteTermination property and you must be careful with your choices here.  If you leave it as false, every time you delete the instance, the volume will be kept, so be cautious.  If you retain a lot of volumes the cost of the storage can easily mount up.

Once we have defined the properties of the EbsBlockDevice and assigned it to the $volume variable, we then create the BlockDeviceMapping.  With the DeviceName property we’re stating how the volume is going to be attached to the instance and root volumes are always ‘/dev/sda1’.  Finally we assign the $volume we created before and assign it to the Ebs property.  Finally the $DeviceMapping object is passed to the –BlockDeviceMapping parameter.

Deploying multiple volumes

Assigning multiple volumes at deployment time is more or less the same process as deploying just one volume, except for one or two key differences.  For each volume you need separate Amazon.EC2.Model.EbsBlockDevice and Amazon.EC2.Model.BlockDeviceMapping  objects.  For the system volume we again use ‘/dev/sda1’ for the DeviceName property.  For any other volumes you specify the DeviceName property in the format of xvd[f-z], so the next volume would be xvdf and the one after that xvdg etc.  Finally the two device mapping objects are separate by commas and passed to the –BlockDeviceMapping parameter.

Attaching snapshots as volumes

AWS provide a number of public snapshots that you can attach to an instance as a volume.  For example all the Windows Server installation media can be attached.  The full list of media available for the us-east region can be found here.  Not the snapshot ids are unique for each region, so i you are deploying an instance in a region, you must also use the available snapshots for that region.  As well snapshots of installation media, AWS also provides snapshots of public data.  So if you would like the Marvel Universe Social Graph or 200TB of data from the 1000 Genomes Project, you can add that data as a volume to your instance.  For more public datasets, please look here.

In the example below we are going to assign the Windows Server 2012 R2 installation media as volume to a running instance.  The first step is to create the volume, specifying the size, the availability zone and the snapshotId that the volume will be based off.  The volume isn’t immediately available, so we have a While statement to check every 15 seconds when it’s available.  Once it’s available we use the Add-EC2Volume cmdlet to add the volume to the instanceId we created in a our second example.


Adding volumes to an instance either at deployment or while the instance is running is fairly straight forward.  In addition if you require a lot of test data, this can be easily attached to the instance using public AWS snapshots.

In the next article we’ll dig deeper into instances and how you can backup / restore a volume and resize a volume using snapshots.


Previous Installments

To see the previous installments in this series, visit “100 Days of DevOps with PowerShell”.

Leave a Reply