Bigger companies have a DR strategy with given Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) for defined workloads. RTO and RPO are very important as they can decide if a company will survive a disaster or not. That is why a “kind of guarantee" is needed that RTO and RPO can be achieved during a real disaster and not only during tests.
All Azure provided DR services like Azure Site Recovery (ASR) and Azure Backup have one very big weakness: There is no capacity guarantee!
Let's assume that one Azure region or also one Azure Availability Zone (AZ) goes down and is expected to stay down. What will happen is that hundreds of Azure customers will trigger their DR plans and either try to bring up their workload in the associated region or one of the remaining AZs (dependent on the scenario).
It can be assumed that there is not enough capacity available for everyone. This potentially means that the defined RTO for a workload cannot be achieved what might mean out of business for a company!
We thirst thought that Azure Reserved Instances will solve this issue until we found that this a financial reservation only. Then we thought about to host our prod systems (VMs) in different regions or AZs than our non-prod systems. But this does also not help as we need to shutdown non-prod to bring up prod and someone could “steal” capacity in the meantime. Then we thought about Azure Dedicated Host what was not recommended by MS.
Microsoft could not really propose a viable option how to handle the capacity issue for ASR and Azure Backup.
The only feasible way looks to be to maintain prod standby/DR systems (VMs) but this is a lot of effort.

What I would really appreciate is a possibility to reserve capacity or even better to ensure that non-prod capacity can be used for DR (what is again a capacity reservation).
Bigger companies might not move their production workload to Azure if they have to fear that RTOs cannot be guaranteed.

Azure needs to stick to flaws, one on the windows system and one on the portal - both serious.

1: The modification of azure spot shares, even if made, is not recognized when the VM Spot changes its size or even when it is created. For some reason, even though the regional Spot limit has been increased to, for example, 72, it is stuck in the standard limit of 10 in the standard. The message is "10 left out of 72 cpu".

2) This is a serious and costly mistake. Most Nvidia cards are not fully recognized by Windows. Only Tesla M60, Tesla T4 and AMD Radeon are fully recognized (or at least 90%). Video cards (including the most expensive ones on the portal!) Such as P40, P100, V100 have very limited implementation. They do appear in the device manager, but are not recognized in all programs, the graphics configuration of windows itself does not recognize (takes into account only the basic windows driver - microsoft render basic driver, something like that), programs like Topaz cannot even be opened. The only way these cards really work on Azure is if the image you acquire is the NVIDIA WORKSTATION GRID + WINserver combo. In this case, the system recognizes, windows etc. But then in addition to paying Azure, you must pay Nvidia by the hour.

VMSS should allow us to configure a custom script that can be run before performing an upgrade to ensure that all connections are drained before upgrading the image.

Currently, the only way to do this is to use manual upgrades and RDP/remote powershell to each VM and take down the health probe, drain all the connections and then trigger the manual upgrade.

This is not scalable with a large number of VMs and seems like a feature that could very easily be implemented on the VMSS.

It would simply require custom script extensions that can be triggered manually by a user and at time of rolling upgrades. Currently custom script extensions only run at time of creation of a new VM.

The functionality to run custom scripts is already there, why not just allow it to improve the upgrade process.

Currently rolling upgrades lead to dropped connections and connections being sent to a shutdown VM (for the few seconds between the shutdown and the health probe marking the instance down)

The term "hybrid benefit" for Red Hat Enterprise Linux is misleading.

This is not really a hybrid benefit like you get with Windows where you can run a datacenter license both on-premises and not pay the licensing costs to run a cloud virtual machine with the same license.

The Red Hat Enterprise Linux "hybrid benefit" doesn't allow you to do that, it is merely a method to convert a pay as you go VM in to using a paid red hat subscription without needing to use the Red Hat Gold Images from the marketplace.

The term of this should be changed as it is confusing to customers that currently use the hybrid benefit for Windows virtual machines.