Azure Bastion: RDP and SSH to your VMs without a public IP or a jump box
You need to log into a VM to fix something. The lazy way is to give it a public IP and open port 3389 — and within minutes the internet's bots are trying every password they own against it. Azure Bastion is how you get in without ever opening that door.
Remote management is where a lot of cloud breaches quietly begin. The moment a VM has a public IP with RDP (3389) or SSH (22) exposed, it is being scanned and brute-forced around the clock — that is not paranoia, it is the ambient weather of the public internet. Azure Bastion removes the exposure entirely. Microsoft describes it as a fully managed PaaS service that provides secure RDP/SSH connectivity to your virtual machines directly over TLS from the Azure portal — and, the line that matters, when you connect through it, "your virtual machines don't need a public IP address, agent, or special client software."
How the connection actually flows
Bastion is deployed into your virtual network, in its own dedicated subnet, and it reaches your VMs over their private IP addresses. You open the VM in the Azure portal, click Connect, and an RDP or SSH session opens right in your browser over TLS on port 443. The path is: your browser → Bastion (over HTTPS) → the VM (over its private IP, inside the network). At no point does the VM need a public IP, and at no point is 3389 or 22 open to the internet. The management port lives entirely on the private side, where the scanners cannot reach it.
The VM keeps no public IP and opens no management port. You reach it over TLS in the browser — the door the attackers scan for is simply never there.
What you stop having to run
Before Bastion, the standard pattern for private VMs was a jump box (a bastion host): one hardened VM with a public IP that you SSH into first, then hop from it to everything else. It works, but it is a chore and a liability — that jump box is a VM you have to patch, monitor, harden, and keep alive, and it is itself an exposed, attacker-interesting target. Azure Bastion is that pattern delivered as a managed service. Microsoft runs it, scales it, and keeps it current; you deploy it once per virtual network and stop maintaining a jump box forever. Less to patch, less to break, and one fewer exposed IP in your estate.
Two properties do most of the work. First, your VMs are protected from port scanning — with no public IP and no open management port, there is nothing on the internet for a scanner to find. Second, connectivity is over TLS on 443, the same well-guarded, outbound-friendly port your browser already uses, so it slips through corporate firewalls without special holes. Standard and Premium tiers add native-client connections, custom ports, and file transfer; the Premium tier adds session recording for compliance, so you can prove who connected to what and when.
Where it fits with the rest of your network security
Bastion is not a replacement for your other controls — it is the piece that closes the human-access hole. You still use Network Security Groups to control traffic, and you still keep VMs on private subnets (often reached outbound through a NAT gateway). Bastion answers the specific question "how do I, a person, get a shell on a private VM without exposing it?" The honest trade is cost: Bastion bills hourly from the moment it is deployed, whether or not anyone connects, so it earns its keep in environments where you genuinely need interactive access to private VMs — not on a lone throwaway box you will delete tomorrow. For a real estate of private VMs, though, it is far cheaper than the incident an exposed 3389 eventually invites.
The takeaway
Azure Bastion gives you RDP and SSH to your VMs over TLS straight from the portal, with the VMs holding no public IP and no open management port, and with no jump box for you to run. It closes the single most-scanned door in cloud infrastructure — the exposed remote-access port — and hands the maintenance of that access layer to Microsoft. "Bastion for interactive access so the VMs stay private with no public IP, NSGs and private subnets around them, and no jump box to patch" is the answer of someone who knows exactly where cloud break-ins tend to start.