Last week I wrote about The Maximum (EBS) Drives/Volumes for an EC2 Windows Instance. In that I discussed the max I had discovered was 12. While that is accurate, it is important to understand that was based on “instance-store” (or S3-backed) instances. Since I’ve been working recently with EBS-backed Windows (2003 and 2008) instances I wanted to see what they could handle.
I started by creating about a dozen EBS volumes, then using ElasticFox I attached them to my Windows instance. ElasticFox will auto-assign the device name – xvdh, xvdi, xvdj, and so on up to xvdp. After that it will begin using xvdg, xvdf, xvde, etc. After I had 14 total drives (Amazon calls them volumes, Windows calls them drives – therefore I am using the terms interchangeably) attached I received the message, “The request must contain the parameter device” and couldn’t attach any more.
Next I turned to Amazon’s AWS Management Console which displays a list of available devices. However, it only displays xvdf – xvdp.
Since xvdd – xvdp were already in use, and I reasoned that the root volume was using xvda, I tried to manually use xvdc, and it worked. I was also able to manually assign device xvdb.
At this point I had 16 EBS volumes (drives 0-15) attached to my Windows instance.
I was able to successfully reboot the instance and everything worked fine, unlike when I lost connectivity to the instance-store instance as described in my previous post.
Just for fun I tried to device names outside the specified range. For example when I tried to use xvdq I received the message, “Value (xvdq) for parameter device is invalid. xvdq is not a valid EBS device name.”
This all makes sense as “p” is the 16th letter in the alphabet. Therefore, devices xvda – xvdp are available and usable on Windows 2003 and Windows 2008 Amazon EBS-backed instances.