This is one of a drawback my customer pointing out in Azure. Currently the billing continues when the VMs are stopped. The message shows "Stopped virtual machines continue to incur compute charges. If you do not wish to be charged, delete this virtual machine."

Issue is, once the VM created we are installing required softwares and does some work. When the users are not in office, they are ready to stop the system and free from the hardware resource used for that VM. But to avoid the billing for the unused VMs, we required to delete the VM instead of stopped. This creates issue for taking backup, re-create the VM etc.,

So, If would be nice if the billing is reduced for the stopped VMs and bill only for the storage cost (Disk, Image etc.,) instead of hardware usage.

Note: AWS does not charge for the stopped VMs, billing only the storage cost.

When you create a new VHD, you are able to give it a "friendly" name (e.g., "ExchangeStorage"). Unfortunately, this name is ONLY displayed in the Storage --> Containers --> VHDS area. A different name is displayed in Virtual Machines -> Images. It makes it a little difficult to correlate which storage VHD drive is associated with which VM drive. The only way to do it was to correlate based on the HTTP address.

I suggest that:
• In Virtual Machines -> Images, add a column with the VHD image name.
• In Storage --> Containers --> VHDS, include the drive size and which VM is is associated with (if any) and disk type AND the name as displayed in Virtual Machines -> Images (e.g., server-server-1-342309480239).

The second one is important as I almost deleted the wrong image because I wasn't sure if it was the desired one (i.e., Othrwise, how do I know that server-server-1-342309480239 is the same as "ExchangeStorage.vhd")?

We are adding endpoints for each virtual machine once created. Normally the RDP endpoint will be created by default, and can be added more if required by specifying the port #. I feel there are additional features needed to make this feature more flexible and to secure them in a centralized place. Some are -

1. The endpoints are configured by defining the ports, but it is not accepting whether the ports are inbound or outbound. So, there should be an option to include the port to open for inbound or outbound instead of configuring in the VM.

2. There should also be an option to choose the destination IP address on which the port needs to open. Because some enterprises are not willing to open ports to all destination (including 3389). So if there is an option to include the IP address of the machine on which the service can be consumable will reduce the un-authorized resource access. (For Ex: From which IP address, or range of address or subnet, the Azure VMs can able to access using RDP port).

3. It would be better if we have a concept called Endpoint Group (like Security Groups in AWS) which will allow us to group one or more endpoint configurations and name it as a single group. This allows us to define the endpoint group to any VM and can be controlled in a centralized place. This also allows auditing and restricting ports to VMs in a centralized place and making it as enterprise standard.

4. There should be a configuration setup which accepts a flag to make sure whether only endpoint group can be assigned to VMs or individual ports also. This will make sure opening individual ports to any VMs without the knowledge of Administrator.

4. There should be a dedicated user group for managing the securities on the Azure services such as firewall configuration on SQL Azure, endpoint configuration on VMs etc.,