What Is Azure Bastion in Networking?

Imagine you are the manager of a very secure office building. The building has many sensitive rooms (your virtual machines, or VMs) where important work happens. Normally, to get into one of those rooms, you would need a key that is left outside the building for anyone to find.

That key is like a public IP address; it sits on the internet and anyone can try to use it to break in. Azure Bastion is like a secure, guarded reception desk at the front entrance. Instead of giving every room its own outside door with a key under the mat, you walk into the main lobby (the Azure portal), show your badge (your Azure login credentials, often with multi-factor authentication), and tell the receptionist which room you need to visit.

The receptionist then escorts you through a private, staff-only hallway that leads directly to that room. You never step outside the building, and no one on the street can see which room you entered. The hallway is built and maintained by Azure, so you do not need to rent extra space or build the hallway yourself.

The best part is that the rooms themselves still do not have any outside doors. They only have a private entrance that connects to this internal hallway. This means even if a hacker knows the building exists, they cannot directly knock on any specific room’s door because there is no door to knock on.

Azure Bastion works the same way: you connect to the Azure portal over a secure HTTPS connection, and from there, Bastion creates a secure tunnel inside Azure’s network to your VM. You never need to install a VPN client or configure complex network security rules. The traffic never goes over the public internet, and your VM never needs a public IP address that would make it a target for automated scanners and brute force attacks.

This is especially important for IT professionals who manage sensitive systems like databases or domain controllers, where any exposure to the internet is a high security risk. Azure Bastion also handles the hard work of authentication and session management, so you can focus on your work instead of worrying about network security. In short, it gives you a safe, easy, and browser-based way to manage your cloud servers without turning them into sitting ducks on the internet.

Azure Bastion is a platform as a service (PaaS) offering from Microsoft Azure that provides secure, seamless Remote Desktop Protocol (RDP) and Secure Shell (SSH) access to virtual machines (VMs) within an Azure virtual network (VNet) without requiring any public IP addresses to be assigned to the target VMs. The service is provisioned directly inside the VNet and uses a hardened, multi-layer architecture to broker connections. At its core, Azure Bastion acts as a reverse proxy, terminating all inbound RDP and SSH traffic at the Bastion host itself, then establishing a new, outbound-only connection to the target VM over the Azure backbone network.

This design ensures that malicious actors cannot target VMs directly from the internet because the VMs are never assigned a public IP. The Bastion service is deployed as a dedicated subnet named AzureBastionSubnet with a minimum size of /27 or larger. This subnet must be within the VNet where the target VMs reside.

The Bastion host is assigned a public IP address, but that public IP is attached only to the Bastion service, not to the VMs. All user traffic first reaches the Bastion host over HTTPS (port 443) through the Azure portal. The Bastion host validates the user's Azure Active Directory (Azure AD) credentials or, if configured, uses Azure AD authentication for the target VMs.

Once authenticated, the Bastion host opens a session and connects to the target VM over a private IP address within the VNet, using RDP (port 3389) or SSH (port 22) but only over the private network. The Bastion service supports both standard and premium tiers, with the premium tier offering additional features such as session recording, custom port forwarding, and scaling up to 50 concurrent RDP sessions or 500 concurrent SSH sessions per scaling unit. The service integrates with Azure Private Link, Azure Firewall, and network security groups (NSGs) for fine-grained access control.

The Bastion host itself is hardened against common attack vectors: it receives automatic security updates from Microsoft, it does not expose any management interfaces to the public internet beyond the necessary HTTPS endpoint, and it supports Just-In-Time (JIT) VM access for an additional layer of security. From a protocol perspective, Azure Bastion encapsulates RDP/SSH traffic within an HTTPS tunnel. The user’s browser renders the RDP or SSH session using HTML5, meaning no local client software is required beyond a modern web browser.

This is achieved through a web-based gateway that translates the remote desktop or terminal protocol into browser-compatible web sockets. The Bastion service also supports native client connections via the Azure CLI or the Bastion client for Windows, which uses a native RDP or SSH client while still using the Bastion tunnel. In terms of networking, Azure Bastion uses the Azure backbone for all traffic between the Bastion host and the target VMs.

This traffic never traverses the public internet, even if the VMs are in a different region. The VMs themselves must have the Bastion agent enabled (which is the default for most Azure marketplace images) or the Bastion must be able to communicate with the VM's guest OS via the private IP. For VMs not using the Bastion agent, the Bastion host injects the necessary credentials into the session using the VM's virtual network adapter.

Security considerations are paramount: the AzureBastionSubnet must not contain any other resources, and NSG rules can be applied to restrict inbound traffic to the Bastion subnet from only trusted IP ranges, although Microsoft recommends allowing all inbound traffic on port 443 from the internet because the Bastion host itself is the only point of entry. Azure Bastion supports Azure AD authentication for Windows VMs, enabling conditional access policies and multi-factor authentication (MFA) to be applied before the session even reaches the VM. The service is available in most Azure regions and supports VMs running Windows, Linux, and even some third-party operating systems.

Azure Bastion is not a VPN or a jump box in the traditional sense, because it does not provide general network-level access to the VNet. It only provides RDP/SSH access to specific VMs for which a user has explicit permissions. Azure Bastion is a full-featured, secure, and scalable solution for remote VM management that eliminates the operational overhead of maintaining a VPN gateway or a bastion host VM while providing enterprise-grade security controls.

Azure Bastion matters because it directly addresses one of the most common security vulnerabilities in cloud environments: exposing management ports (RDP and SSH) to the internet. For years, IT administrators would assign public IP addresses to VMs just to be able to log in and manage them, or they would configure complex VPN gateways that required client software and certificate management. Azure Bastion eliminates the need for both.

By allowing secure, browser-based access to VMs inside a VNet without any public endpoints, Bastion reduces the attack surface dramatically. This is especially critical for VMs that host sensitive data, such as domain controllers, SQL servers, or application servers, because automated botnets constantly scan the internet for open RDP and SSH ports. A single misconfigured NSG can expose hundreds of VMs to brute force attacks.

Bastion removes that risk entirely at the architectural level. Bastion simplifies compliance with security policies that require all administrative access to go through a secure, audited, and centrally managed gateway. Because all connections are logged and tied to Azure AD identities, organizations can enforce multi-factor authentication, conditional access policies, and even session recording (with the Premium tier).

This makes it easier to meet standards like SOC 2, ISO 27001, and HIPAA, which require strict access controls and auditing. From an operational perspective, Bastion eliminates the overhead of maintaining a bastion host or VPN server. You no longer need to patch a jump box, manage VPN certificates, or troubleshoot split tunneling.

Bastion is a PaaS service, so Microsoft handles the infrastructure, updates, and scaling. This frees up IT staff to focus on higher-value tasks. Bastion also improves productivity; administrators can manage VMs from any device with a browser, including tablets or thin clients, without installing any client software.

This is a huge advantage in modern, remote-first workplaces. Finally, Bastion integrates with existing Azure governance tools, such as Azure Policy and Azure Role-Based Access Control (RBAC). You can enforce that only users with specific roles (e.

g., 'Virtual Machine Contributor') can access VMs through Bastion, and you can even restrict which VMs they can access. Azure Bastion is not just a convenience tool; it is a fundamental security control that should be considered a best practice for any production workload running in Azure.

It turns a complex, risky process into a simple, secure, and auditable one.

Azure Bastion questions appear in several distinct patterns across Azure certification exams. The most common is the 'solution selection' scenario. For example: 'You have 20 Linux VMs and 10 Windows VMs deployed in a VNet.

You need to provide secure administrative access to these VMs without exposing any public IP addresses. Your solution must minimize administrative overhead. What should you deploy?'

The correct answer is Azure Bastion. The distractors might include a jump box VM with a public IP, a point-to-site VPN, or a site-to-site VPN. Candidates must identify that Azure Bastion is the only option that requires no public IPs on the VMs, provides browser-based access, and is fully managed.

Another pattern involves configuration and prerequisites. A question might state: 'You are deploying Azure Bastion. Which subnet requirement must be met?' The answer: the subnet must be named 'AzureBastionSubnet' and have a minimum size of /27.

A variation could ask about NSG rules: 'What inbound rule must exist on the AzureBastionSubnet NSG?' Answer: Allow inbound HTTPS (port 443) from the internet. There are also troubleshooting questions.

For instance: 'Users cannot connect to a VM through Azure Bastion. The VM is running and has the Bastion agent installed. What could be the issue?' Possible answers include: the VM does not have a private IP, the NSG on the VM subnet is blocking port 3389 or 22, or the user does not have the 'Virtual Machine Contributor' role.

Candidates need to know that Bastion connects to the VM over the private network, so the VM's NSG must allow inbound traffic from the AzureBastionSubnet on the appropriate port. Another question type: 'A company wants to use Azure Bastion to connect to VMs but also wants to enforce multi-factor authentication. How can this be achieved?'

The answer: configure Azure AD authentication for the VMs and enable conditional access policies. A more advanced question might involve the Premium tier: 'Which Azure Bastion tier supports session recording and scaling up to 50 concurrent RDP sessions?' Answer: Premium tier.

For the AZ-900, questions are simpler: 'True or false: Azure Bastion requires a public IP address on each VM.' Answer: false. Or 'Which service allows you to connect to a VM through the Azure portal with no client software required?'

Answer: Azure Bastion. In AWS context, the equivalent scenario might appear in the AWS Solutions Architect Associate exam: 'A company wants to provide secure RDP access to EC2 instances in private subnets without using a VPN. Which solution meets these requirements?'

The recommended answer would be AWS Systems Manager Session Manager, which is the AWS analog to Azure Bastion. Understanding Azure Bastion helps you draw the parallel. In Google Cloud exams, a similar scenario would ask about using IAP TCP forwarding.

The key is that across all exams, the underlying principle is secure, identity-based, browser-accessible management of compute resources without public exposure.

Azure Bastion is a service that many IT professionals encounter early in their cloud journey, but its depth goes beyond just 'click connect in the portal'. Understanding how it works in practice is essential for both exams and real-world implementation. First and foremost, you must plan the subnet carefully.

The AzureBastionSubnet must exist in the same VNet as your target VMs. If you have VMs in multiple VNets, you need a separate Bastion host for each VNet, or you can use VNet peering and configure the Bastion in a hub VNet. However, even with peering, each VNet can have its own Bastion, which is useful for isolation.

When you create the subnet, the name is case-sensitive and must be exactly 'AzureBastionSubnet'. A common mistake is using a different name or a smaller subnet, which causes deployment failure. The subnet size is critical because Azure reserves several IPs for the Bastion infrastructure itself.

For example, a /27 subnet gives you 32 IPs, but only about 25 are usable for scaling units. If you plan to have many concurrent users, consider a /26. Next, the public IP address you create must be in the same region as the VNet.

It is a standard SKU public IP, and you cannot change it after creation. You cannot use a basic SKU IP. The Bastion host listens on port 443 for HTTPS traffic. When a user connects through the portal, the Azure portal initiates a WebSocket connection to the Bastion host's public IP.

The Bastion host then verifies the user's Azure AD token and IP address. After authentication, it creates a secure channel to the target VM using its private IP. This is why the VM's NSG must allow inbound traffic from the AzureBastionSubnet's address range.

If the VM's NSG blocks port 3389 or 22 from that subnet, the connection will fail. Also, if the VM is in a different subnet, the VM's NSG rule must explicitly allow the Bastion subnet. A very practical aspect is the authentication flow.

For Windows VMs, you can enable Azure AD authentication. This is a game-changer because it allows you to manage VM access using Azure AD identities and conditional access policies. Without it, you must use local VM credentials, which can be cumbersome to manage across many VMs.

For Linux VMs, you can use SSH public key authentication stored in the VM or use Azure AD authentication if you configure the SSHd with the Azure AD extension. In practice, you should use Azure AD authentication whenever possible for better security and auditability. Another practical consideration is cost.

Azure Bastion is billed per hour plus data transfer. The Basic tier is cheaper but lacks scaling and session recording. The Premium tier is more expensive but allows up to 50 concurrent RDP sessions per scaling unit.

If you have only a few administrators, Basic is sufficient. However, if you need to support a large operations team, Premium is necessary. Also, be aware that Bastion charges for outbound data transfer from the Bastion host to the user's browser.

This can be significant if you transfer large files over RDP. It is better to use other methods for file transfers, like Azure Files, to avoid high data costs. Performance-wise, Bastion introduces some latency because the traffic goes through the browser and the Bastion host.

For typical administrative tasks like running PowerShell commands or making configuration changes, the latency is acceptable. But if you need to perform graphic-intensive work or video editing, Bastion is not suitable. Also, keep in mind that Bastion does not support clipboard or drive redirection in all scenarios, though the browser-based client supports some features.

In a production environment, you should also set up monitoring. Use Azure Log Analytics to track Bastion connection logs. You can set up alerts for failed login attempts, which could indicate a brute force attack, even though the Bastion host itself is hardened.

Also, consider integrating Bastion with Azure Policy to enforce that all VM connections must go through Bastion. For example, you can create a policy that denies the creation of VMs with public IPs in critical subnets. This enforces the principle of least exposure.

Finally, always test the connection after deployment. Connect to each VM type (Windows and Linux) to ensure the NSG rules are correct and authentication works. If you encounter issues, check the VM's guest OS firewall, as it may block RDP or SSH even if the NSG allows it.

For Linux VMs, ensure the SSH service is running and the port is not being blocked by iptables or firewalld. Azure Bastion is a powerful tool that, when configured correctly, can significantly improve your security posture. But it requires careful planning around subnet sizing, NSG rules, authentication, and cost.

The practical professional knows to always remove public IPs from VMs, use Azure AD authentication, monitor logs, and test thoroughly.