The ports for RDP on Windows Servers and SSH for Linux are close to guaranteed to attempted to be hacked if you put a server with these protocols publicly exposed.
So all design recommendations have always been not to add these protocols on public IPs. However, regardless of how you plan and design sooner or later you get a solution that would require you to expose them. Until recently the only way to secure this on Azure was to limit the address ranges that were allowed to connect, which of course made the solutions less flexible.
Now Azure has introduced a solution called Bastion which may be the answer to how to secure this traffic. The solution has some limitations and may require some effort to add it to your network. One of them is that one Bastion can only be connected to one VNET. If your heavy on VNET separation you will have to have multiple instances of Bastion.
If you have the separation of systems based upon subnets you will find that you get more usage out of each of the Bastion instances.
The best use case I see for the Bastion solution is only for those solutions that are standalone, where the admins need to have an RDP or SSH connection to reach into the solution.
The user connects to the Azure portal when connecting to the Virtual Machine, the instance creates an SSL connection to the destination server and streams the view to the browser window utilizing HTML5. The connecting user needs Read rights to VM, the VMs NIC, and on the Bastion instance.
For the general cloud environment that is connected to your on-premises data center, I would recommend only allowing management RDP requests coming from hosts that are within management networks in the private data center and not expose this traffic to the internet at all.
