Please add the following to virtual networks and related services:

1. Purchase or have added as many static or at the very least reserved IP addresses that I need to use.
2. I want to be able to specify rules as to which IP(s) should map to which service of mine (firewall translation rule) and which ports can be allowed. (all mapped to my VNet addresses)
3. I need to be able to assign static addresses from my VNet to my VMs.
This would resolve a lot of issues for a lot of people.
1. SSL would be fixed and multiple sites could be supported correctly.
2. DNS addressing that requires static addresses would work.
3. Security that is IPsec driven would work.
4. Traffic would be able to be load balanced without using the cloud services. (this should be build into the service)

In an ideal world the traffic manager would have handled this, but, the TM only updates DNS info which is pointless for a company such as mine. Without these controls it would be foolish to move our services to the azure cloud. With them I could justify the move.

I'm currently working on a solution which will be using multiple storage accounts which will continue to grow indefinitely.
The 100TB limit means that I have to continuously list the blobs in my container to workout what the total size used is and then determine if I need to create a new storage account on the fly. This is cumbersome and time consuming for the type of performance the business requires.

It would be better to remove the account size limitation which would simplify the solution considerably and remove all the blob listing look-ups which seem counter intuitive. The only other alternative would be to provide an API call to show the current size of an account.

I'm well aware of the 5k transactions per second and 3 gigabits per second limitations per storage account, and fall well within them... even using a 10 year projection.

Azure storage is protected using a connection string which contains credentials. Usually this connection string is placed in a configuration file. Reality tells us that information placed in configuration string leaks. It is likely that the storage configuration string will leak to non-authorized people. If someone has the connection string he owns your Azure storage!
It is not possible to compare Azure Storage connection string to SQL connection strings because SQL is not exposed to the web. Even if a bad guy has the connection string he cannot use it unless he get network access to the SQL server or he installs some piece of software near the SQL DB.
In Azure storage anyone with the connection string can access the storage and get full control.
It just does not make sense that the data is protected only with the connection string!
It is required to add another security dimension to azure storage and allow the owner of the storage account to mark that only roles running from the same subscription ID can access this account. This way he can place sensitive data in a storage account that cannot be accessed from outside of windows azure or outside of his subscription.
Non sensitive data will be placed in normal storage accounts running exactly like they do today.

Was wondering what others thought about "tiering" this more than a simple fixed storage transaction rate ? i.e. something more like

$0.01 - 10K up to 10 million
$0.008 - 10 million 15 million
$0.005 - 15 million+

Something like this ?

It just seems that transactions can be eaten up really quickly and there is no pricing mechanism to facilitate heavy users ?

Generally, the sessionState based problem - http://social.msdn.microsoft.com/Forums/en-US/windowsazure/thread/1436b9fe-c899-46c8-813a-82b919273dda - is the worst and it just destroy transaction volumes. MSFT have acknowledged the problem - so this is the primarily reason.

I am sure there are many other people having issues with this and heavy users should really be discounted otherwise we could simply change CDN to Amazon based CDN and storage and reduce requests to table storage on Azure ?

But why do this when MSFT could simply make it more attractive?