updated: May 10th 2015 - Added SAS workaround
I played quite a bit with Azure Premium storage accounts recently and I have to say that I welcome with arms wide open this new performance level. Especially for dev/test environments in Azure. Even if I deeply think that this is what we should have had in the first place or at least something in between the latency of XIO and a standard storage account.
It is good to know that
Premium Storage supports only Azure page blobs, which are used to hold persistent disks for Azure Virtual Machines (VMs)
To create a premium storage account, you declare as "Premium_LRS" or "Premium-LRS" depending if you are using PowerShell scripts or Azure Resource Manager templates.
During my tests and scripts migration to use the new storage account type faced an error message.
Given the following code:
New-AzureStorageAccount -StorageAccountName 'myaccount3456485' -Type Premium_LRS -Location 'East US 2'
New-AzureStorageContainer -Name 'myaccount3456485' -Permission Blob
this cause the following error:
New-AzureStorageContainer : The remote server returned an error: (400) Bad Request. HTTP Status Code: 400 - HTTP Error Message: One
of the headers specified in the request is not supported.
At C:\Temp\Demos\New-DevTestEnvironmentFromPowerShell.ps1:32 char:1
- New-AzureStorageContainer -Name 'myaccount3456485' -Permission Blob
If you either specify Container or Blob permission you will end up with this error message. You won't have this error if you specify Off or if you don't specify the -Permission parameter.
The only think I know is that it's not yet supported. No official word about when it will be, but I'm pretty sure it's only a matter of time before we see it working.
Workaround
You can use SAS (Shared Access Signature) to mimic the public permission on a container or blob. Be sure to remember that if you change the storage keys, this will invalidate the SAS you generated with them.
As a last resort, you could still use a standard storage account but you won't get the same performance.