Azure Bastion is often described as a way to RDP or SSH to virtual machines without assigning those VMs public IP addresses. That is accurate, but it understates the operational change. Bastion inserts a managed administration path between the operator and the workload. The design can reduce direct internet exposure, but it also creates dependencies on identity, RBAC, network security rules, Bastion SKU capabilities, session controls, and the health of the management plane.
For AZ-104, the useful mental model is a connection chain. An authorized user starts a Bastion session. Azure validates access to the Bastion and target resources. Bastion reaches the VM over the private network using the required RDP or SSH path. The guest operating system still authenticates the session according to the connection method. Removing the VM’s public IP reduces exposure; it does not eliminate the need for secure credentials and guest hardening.
Imagine an operations team that currently exposes TCP 22 and 3389 through tightly restricted public IP rules. Moving to Bastion can remove those public VM endpoints, but only if the team also updates NSGs, access roles, break-glass procedures, logging, and automation. Otherwise the new service is simply added alongside the old risky path rather than replacing it.
Bastion changes where remote administration enters the network
With direct RDP or SSH, the target VM is itself the internet-facing administration endpoint when it has a public IP. With Bastion, the user connects through the managed Bastion service and Bastion reaches the VM using its private address. The workload VM no longer needs a public IP solely for administration.
This reduces the attack surface exposed to internet scanning and password attacks against remote-management ports. It also centralizes an access path that can be governed and monitored more consistently than many independently exposed VM endpoints.
The broader principles in remote-access policies are relevant because technology does not replace the need to define who may administer systems, from where, for what purpose, and under what approval or monitoring conditions.
The target VM still needs an authentication and authorization model
Bastion transports the administrative connection; it does not turn an unauthorized operator into an authorized guest user. The target operating system still needs a valid authentication method and appropriate local or domain privileges. SSH keys, passwords, directory-backed authentication, and other supported methods still carry their own security requirements.
For Linux administration, the existing explanation of SSH is useful because the protocol and credential model still matter even when the network path is mediated by Bastion. A weak reusable password remains weak merely because port 22 is not public.
Administrative privilege should also be separated from the ability to view or configure the Azure resource. Azure role-based access control governs access to management operations, while the guest operating system controls what the connected account can do inside the VM. Both layers need deliberate design.
This separation should be reflected in privileged-access reviews. A person may legitimately be able to start a Bastion session without needing broad rights to modify the virtual network, delete the VM, or change Bastion itself. Conversely, an infrastructure engineer who can configure the network does not automatically need administrator rights inside every guest. Splitting those privileges limits the blast radius of both mistakes and compromised accounts.
NSGs should allow the Bastion path without reopening the old one
A migration is incomplete if the VM keeps its public IP and broad inbound RDP or SSH rule “just in case.” The intended state should be explicit: administration enters through Bastion, and the VM’s network security rules permit the required private management flow while denying unnecessary public management traffic.
Azure Bastion has specific subnet and NSG requirements. Administrators should follow current service guidance rather than copying generic rules from an old tutorial, because Bastion features and SKUs have evolved. After deployment, Network Watcher diagnostics can verify that the expected Bastion-to-VM flow is allowed and that an unintended internet-to-VM path is not.
This control placement naturally intersects with AZ-700 networking and SC-500 security topics. Bastion is secure administration only when identity and network policy agree on the boundary.
Browser access and native-client access create different operational choices
Bastion supports browser-based RDP and SSH experiences, and higher SKUs support additional capabilities such as native-client connectivity. Native clients can be valuable when operators need familiar tooling, file workflows, tunneling capabilities, or other supported client features.
The choice affects monitoring and control. Microsoft notes, for example, that Bastion session recording is a Premium capability and is not available for native-client sessions in the same way as supported web-session recording. An organization with a strict session-recording requirement therefore cannot select the client mode solely from administrator preference.
Security controls should be mapped to the actual connection mode used in production. A policy that assumes every privileged session is recorded can be undermined by allowing an alternate path that bypasses the recording capability.
SKU selection should follow the administration requirement, not an assumption that all Bastion is the same
Azure Bastion now has multiple SKU tiers with different features. Standard adds advanced capabilities such as native client support and other connection options. Premium adds features such as session recording and private-only deployment. Developer is a lightweight shared option intended for development and testing rather than a substitute for production architecture.
The feature boundary can become a hard requirement. If the organization needs private-only Bastion without a public IP on the Bastion host, Premium is relevant. If native-client connectivity is required, the selected SKU must support it. If the only need is occasional browser access in a small environment, a higher tier may add cost without operational value.
Cost is continuous as well. Bastion is a deployed service, not a fee that appears only while someone is connected. Teams should include its standing cost in the operating model and avoid leaving test deployments running without purpose.
Peered networks and IP-based connections can broaden the administration scope
Depending on SKU and configuration, Bastion can administer resources beyond a single simple VNet scenario, including supported peered-network and IP-based connection patterns. That can reduce the temptation to deploy an independent jump host in every subnet or application VNet.
But broader reach also broadens the trust boundary. A centrally shared Bastion must have clearly defined routing, NSGs, role assignments, and ownership. If every operations team can reach every spoke through one administration service, the convenience may exceed the least-privilege requirement.
Centralization should therefore be paired with segmentation and RBAC. The architecture should make it easy to answer which operators may use which Bastion instance to reach which classes of systems.
Session recording is evidence, not a substitute for least privilege
Recording a privileged session can support audit, investigation, and compliance, but it does not make the session safe by itself. An administrator with excessive permissions can still make a damaging change while being recorded. Recording helps reconstruct and deter behavior; authorization limits what behavior is possible in the first place.
The strongest model combines least-privilege roles, strong authentication, controlled access paths, change management, session evidence where required, and alerting for unusual administrative activity. These controls reinforce one another instead of assigning too much responsibility to a single remote-access product.
That is consistent with zero-trust network protection: the network location of the connection should not be the only reason it is trusted. Identity, device posture, privilege, session context, and resource sensitivity still matter.
Bastion availability becomes part of the recovery plan once it is the approved administration path
Removing direct public administration improves security, but it also means operators depend on Bastion during incidents. The team should know what happens if Bastion is unavailable, misconfigured, or unreachable from the operator’s context. A secure design needs an emergency administration strategy that does not quietly reintroduce permanent public RDP or SSH.
Break-glass procedures might include a separately controlled management path, infrastructure-as-code redeployment, serial console capabilities for supported VM troubleshooting, or another approved method appropriate to the environment. The important point is to design it before the incident.
Recovery exercises should test the administration path itself. Can responders reach a VM when the application subnet is degraded? Are the necessary roles available to the incident team? Does DNS or routing for the management path depend on the same failed component they are trying to repair?
Operational evidence should show both successful administration and blocked bypass paths
A successful Bastion session proves only that one path works. Security validation should also confirm that the target VM cannot be reached through an unintended public management endpoint, that NSGs permit only the necessary private management flow, and that role assignments limit who can initiate sessions.
Logging and monitoring should correlate Azure control-plane activity with guest events when possible. A session start, VM login, privilege elevation, and configuration change may appear in different data sources. Incident responders need a way to reconstruct those events as one administrative action.
The administrator’s goal is not merely connectivity. It is accountable connectivity: the organization knows who entered, through which approved path, what privileges were available, and what evidence remains afterward.
A practical migration starts by identifying every VM that currently has a public administration path. Deploy the appropriate Bastion architecture, validate browser or native-client access as required, update NSGs and operational procedures, and then remove unnecessary public IPs or inbound management rules. Monitor for teams that try to recreate the old path when they encounter friction.
Within the Azure Administrator Associate path, Bastion connects networking, identity, security, and operations. The feature is valuable because it changes the administration boundary, but its security outcome depends on the surrounding controls.
The durable mental model is to trace the session end to end: who is the operator, what authorizes access, which Bastion capability is used, how the private network reaches the VM, how the guest authenticates the user, what the user may do, and what evidence is retained. When every step is intentional, Bastion becomes part of a secure administration architecture rather than merely a more convenient way to open a remote desktop.
