This is a mixed issue (Azure Key Vault and .NET).

.NET has a service called SignedXml that can be used to create xml signatures. The problem is that you need the X509Certificate (with private key) to create the signature using its ComputeSignature method (the digest is calculated, internally, only when you compute the signature).

It would be very nice if SignedXml could be more Azure-aware.
We would like to calculate the digest from SignedXml (without using the priv.cert), sign the digest via Azure Key Vault's SignAsync method, and feed the signature back into the service so that it can create the correct xml signature.

It would also be nice if SignAsync could support SHA-1 (even if it is considered unsafe, it's still in use in many enterprise systems).
At the moment it seems that RSNULL and wrapping the SHA-1 digest in the correct ASN1 structure is a valid workaround.

I would like to see some functionality that mitigates the risk of Rouge Administrator accounts. If an employee who is an Azure administrator goes crazy or their Azure account gets hacked then they could deliberately delete the whole Azure tenancy in a very short amount of time. This includes Azure backups.

I would like to see some functionality that could resurrect the Azure environment if that occurred.

You can take many precautions to protect Azure admin accounts but system administrators can become disgruntled employees just like any other employee. At the moment I don't believe Azure offers any protection from this type of threat.

I similar risk does exist with on-prem environments but at least there would be onsite backups if an Administrator went 'Rouge'

Even after performing a transfer for a subscription, though it is visible at https://account.windowsazure.com/Subscriptions, the included Resource Group, Database Server, and SQL Database that belong to it are not seen at https://portal.azure.com/#blade/HubsExtension/Resources/resourceType/Microsoft.Resources%2Fresources until you go and access the “Access control (IAM)” screen and individually add the new transfer user as both an Owner and as a Co-administrator for the Database Server (under All Resources). I suggest all this be automated! I thought these settings would have been taken care of (or inherited) automatically when we initially transferred the subscription, but I was wrong. We were down unnecessarily for a little while until we figured this out (unnecessarily because had the documentation been more clear or adamant that these steps take place we would have caught the issue earlier, and unnecessarily again because in fact I am beginning to think all this was only administrative virtual paperwork that really didn't impact the operational status of the database while we got it all sorted out--so we probably could have continued using it anyway). Immediately after making those changes, the missing resource group, database server and the database showed up in the transfer user's Azure Portal! Additionally, I had to manually change the SERVICE ADMINISTRATOR e-mail separately on the Subscriptions page. This was also not set automatically by the subscription transfer routine. These are important additional steps that are easy to miss on Microsoft’s write-up at https://docs.microsoft.com/en-us/azure/billing/billing-subscription-transfer because that page only hints at it. I don't see why these steps couldn't all be lumped into the subscription transfer process either as a wizard UI or in an automated batch process. FYI - I’ve documented my exploits at https://dba.stackexchange.com/questions/216708/azure-sql-server-database-error-18456-severity-14-state-1/216711#216711.

In AWS, when I want to create a VM that is encrypted, I create a key store and then when I create the AMI I can create a copy of it and tick the encrypted option. It is very easy indeed and I can go from nothing to an encrypted machine in about 20 minutes.

In Azure, I have to create a vault, create a key encryption key, create an application, allow the application access to the key vault, make a note in excel of about 28736 parameters, try to create the VM, work out why it failed, try to create the VM, work out why it failed,
try to create the VM, work out why it failed. Eventually, I might, after 6 hours of hair pulling, get an encrypted VM.

Perhaps you could get someone who is NOT on acid to devise a simpler encrypted VM deployment method? (And templates do not make it easier as they also require all the pre-reqs.)

20 minutes from scratch should be your target.

Some newer Azure servicesSDKs started to (only) support .net standard 2.0 in latest releases, and for projects currently using .net framework, it requires using Visual Studio 2017 to be compatible with.
It has been a whole year since VS 2017 came out, and we really like to get on it to use its latest and coolest features, and most importantly being able to use some newer Azure Service SDKs, but with our dependency on Ibiza framework which currently only support VS 2015,
none of the above could be achieved.
It would be really great if Ibiza team would like to prioritize this task.

Reference: https://docs.microsoft.com/en-us/dotnet/standard/net-standard