Why VolumeQueueLength goes high for SQL Server in AWS
A disk queue length of 32 for a period of time on modern storage systems is most likely insignificant. 

To correctly interpret disk queue length, you need to know how many physical disks are involved.  If the volume is spanned across 32 physical disks, for example, then you have an average disk queue across the disks of 1.  Since it's unlikely you can determine how many physical disks are really being used for the volume, it's difficult, if not impossible, to know what disk queue length number is going to be alarming until you can correlate it with SQL Server wait statistics showing that it is waiting on I/O.  Also, a high disk queue length can simply mean that there's a high load, and as long as performance is acceptable, then you've got nothing to fix, but just note what the disk queue length is as a benchmark.  

Generally you need to first look at SQL Server waits to determine if there is a bottleneck, and what the bottleneck is.  Check out articles such as Resolving SQL Server Disk IO bottlenecks to get started on this subject.  If you see I/O waits increasing, then you'll probably also see the disk queue length increasing.  

So that answers question number 2.  To answer question number 1, it's simply a matter of how many disk requests are waiting to be serviced.  If you have faster disks, or more disks, you'll be able to throw a higher load at it before it a the disk queue starts to increase.  There are so many factors--for example, if you have only one slow CPU, the application won't be able to process much data, and you'll have almost no disk queue, but performance will be horrible.