8.2 Azure Bastion Architecture & Secure Remote Access

Azure Bastion Architecture & Secure Remote Access

Traditional remote administration of cloud infrastructure often relied on deploying public-facing "jump boxes" or assigning public IP addresses directly to virtual machines. This approach exposed critical management protocols—Remote Desktop Protocol (RDP / TCP 3389) and Secure Shell (SSH / TCP 22)—to automated port scanners, brute force dictionary attacks, credential stuffing, and zero-day protocol exploits.

Azure Bastion solves this security challenge by providing a fully managed, platform-as-a-service (PaaS) bastion proxy deployed directly inside your Virtual Network. Administrators establish an encrypted TLS (HTTPS port 443) connection from their web browser or native client to the Azure Bastion host. The Bastion host terminates the TLS session and proxies the RDP or SSH stream over the private Azure SDN fabric to the target VM's private IP address.

+-----------------------------------------------------------------------------+
|                        AZURE BASTION ARCHITECTURE                           |
|                                                                             |
|   Administrator Workstation                                                 |
|         |                                                                   |
|         | (1) Encrypted TLS / HTTPS (Port 443)                              |
|         v                                                                   |
|   +---------------------------------------------------------------------+   |
|   | Azure Virtual Network (Hub-VNet: 10.100.0.0/16)                     |   |
|   |                                                                     |
|   |   +-------------------------------------------------------------+   |
|   |   | Subnet: AzureBastionSubnet (10.100.0.0/26)                  |   |
|   |   | [ Azure Bastion PaaS Scale Units (Standard SKU: 2-50) ]     |   |
|   |   | - Public IP: 52.183.40.50 (TLS Ingress)                     |   |
|   |   | - NSG: Mandatory Platform Inbound/Outbound Rules            |   |
|   |   +-------------------------------------------------------------+   |
|   |                                  |                                  |
|   |                                  | (2) Private RDP (3389) / SSH (22)|
|   |                                  v                                  |
|   |   +-------------------------------------------------------------+   |
|   |   | Subnet: Workload-Subnet (10.100.1.0/24)                     |   |
|   |   | [ Target VM: 10.100.1.4 ] (NO Public IP Required!)          |   |
|   |   +-------------------------------------------------------------+   |
|   +---------------------------------------------------------------------+   |
|                                      |                                      |
|                                      | (3) Cross-Peered VNet Reachability   |
|                                      v                                      |
|   +---------------------------------------------------------------------+   |
|   | Peered Spoke VNet (10.200.0.0/16)                                   |   |
|   | [ Target VM: 10.200.1.4 ] (Accessible via IP-Based Connection)      |   |
|   +---------------------------------------------------------------------+   |
+-----------------------------------------------------------------------------+

1. Dedicated Subnet Architecture: AzureBastionSubnet

Azure Bastion requires a dedicated, specially configured subnet within the host Virtual Network. Sizing and naming rules are strictly enforced by Azure Resource Manager:

• Subnet Name: Must be named exactly AzureBastionSubnet (case-sensitive). Any other name will cause deployment validation to fail.
• Minimum Subnet Sizing: Sized at /26 or larger (e.g., /26 provides 64 total IP addresses, /25 provides 128). Deploying in a /27 (32 IPs) or /28 (16 IPs) is explicitly rejected by the platform.
• Workload Isolation: No other resources (such as standard VMs, load balancers, or application gateways) can be deployed inside AzureBastionSubnet.
• Route Table (UDR) Restrictions: You must not attach a User-Defined Route (UDR) to AzureBastionSubnet that directs 0.0.0.0/0 internet traffic to a firewall or Network Virtual Appliance (NVA). Forcing default route egress through an NVA breaks Azure Bastion control plane management and health probing.

2. Azure Bastion SKU Comparison Matrix

Azure Bastion is available in four feature tiers: Developer, Basic, Standard, and Premium.

[!IMPORTANT] Scale Unit Capacity Planning: Each scale unit in Azure Bastion Standard and Premium supports approximately 10 concurrent RDP sessions or 20 concurrent SSH sessions. A deployment scaled to 10 scale units can handle ~100 concurrent RDP sessions or ~200 concurrent SSH sessions.

3. Advanced Bastion Capabilities Deep-Dive

Native Client Support

Standard and Premium SKUs allow administrators to connect to target virtual machines using their preferred local desktop tools—such as Windows Remote Desktop Connection (mstsc.exe), OpenSSH client, PuTTY, or Visual Studio Code Remote SSH—instead of being confined to a web browser tab.

Native client connectivity operates by leveraging the Azure CLI (az network bastion) to establish a secure local-to-remote TLS tunnel:

# Connect to a Windows VM via native RDP client through Bastion:
az network bastion rdp \
  --name "Production-Bastion" \
  --resource-group "RG-Networking" \
  --target-resource-id "/subscriptions/.../virtualMachines/Win-Server01"

# Connect to a Linux VM using native SSH client and SSH key:
az network bastion ssh \
  --name "Production-Bastion" \
  --resource-group "RG-Networking" \
  --target-resource-id "/subscriptions/.../virtualMachines/Linux-Worker01" \
  --auth-type "ssh-key" \
  --username "azureuser" \
  --ssh-key "~/.ssh/id_rsa"

# Open a local tunnel for arbitrary tooling (e.g., custom RDP port mapping):
az network bastion tunnel \
  --name "Production-Bastion" \
  --resource-group "RG-Networking" \
  --target-resource-id "/subscriptions/.../virtualMachines/Linux-Worker01" \
  --resource-port 22 \
  --port 50022

IP-Based Connection

In multi-VNet hub-and-spoke topologies, deploying an Azure Bastion host in every spoke VNet is cost-prohibitive. IP-Based Connection allows a centralized Azure Bastion Standard or Premium host deployed in the Hub VNet to connect to target VMs located across:

• Peered Spoke VNets (via Regional or Global VNet Peering)
• On-Premises Datacenters (reachable across ExpressRoute or Site-to-Site VPN)
• Non-Azure endpoints with routable private IP addresses

Instead of specifying an Azure Resource ID, the administrator enters the target's private IPv4 address (e.g., 10.200.1.10) directly in the Azure Portal or CLI.

Shareable Links

Shareable Links enable frictionless, secure remote access for third-party vendors, external contractors, or auditors who do not possess user accounts in your Microsoft Entra ID tenant or Azure RBAC permissions on the subscription:

1. An administrator generates a unique Shareable Link for a specific target VM.
2. The external user opens the URL in any standard web browser.
3. The user authenticates directly against the target operating system (using local VM credentials or domain credentials) over an encrypted HTTPS session without accessing the Azure Portal.
4. Administrators can view, audit, and revoke shareable links instantly at any time from the Azure Bastion management blade.

Session Recording (Premium SKU)

For highly regulated industries (such as banking, healthcare, and defense), Azure Bastion Premium provides built-in Session Recording:

• Automatically records all graphical RDP sessions and terminal SSH sessions.
• Stores recordings as append blobs directly into a designated Azure Blob Storage container in your subscription.
• Captures rich metadata (start time, session duration, username, source IP, target VM, protocol).
• Enables forensic security investigations, compliance audits, and non-repudiation verification.

4. Mandatory NSG Rules on AzureBastionSubnet

To ensure platform security, cluster synchronization, and control plane management, Azure enforces strict Network Security Group (NSG) rules on AzureBastionSubnet. If an associated NSG omits any required rule or blocks platform traffic, deployment will fail with a NetworkIntentPolicyValidationFailed error.

Inbound NSG Requirements

Outbound NSG Requirements

[!CAUTION] The Port 80 Outbound Requirement: Administrators frequently attempt to block outbound TCP Port 80 to the Internet on AzureBastionSubnet, believing HTTP is insecure. However, Azure Bastion requires outbound Port 80 for Certificate Revocation List (CRL) validation and session authentication. Blocking outbound Port 80 causes TLS handshakes to fail, completely disabling Bastion remote access.