Azure Tenant Activation / Provisioning Secure VM access via Azure Bastion

Why “secure VM access” keeps turning into a slapstick comedy

There’s a special kind of comedy in cloud administration: the kind where you don’t notice the punchline until it’s too late. Maybe you meant to lock down a virtual machine, but you left RDP wide open because “we only need it for five minutes.” Maybe your jump box is running on an aging VM that you swear you patched last quarter. Maybe your VPN credentials are sitting in a spreadsheet somewhere, and the spreadsheet is named something innocent like “Passwords_FINAL_v7_reallyfinal.xlsx.”

Now multiply that by a team of humans, a few deployment pipelines, and the occasional late-night change request. Suddenly the question isn’t “How do we access the VM?” It’s “How do we access the VM without accidentally turning it into a public audition for hackers?”

That’s exactly why Azure Bastion exists. Think of it as a cloud-native doorman that never asks you to put your VIP credentials on a sticky note. Instead of exposing your VM to the internet or spinning up a traditional bastion host that you then have to harden, you route your RDP and SSH sessions through Bastion—directly from the Azure portal. It’s like having a secure tunnel built into the building, except the building is your subscription and the tunnel is powered by Microsoft’s networking.

The problem Bastion solves: public exposure, jump boxes, and general chaos

Let’s name the usual villains.

1) Public IPs and open ports

If your VM has a public IP and you open RDP (3389) or SSH (22) to the world, you’re not “being convenient.” You’re broadcasting an invitation. Even with Network Security Groups (NSGs), mistakes happen: a rule gets broadened, an IP range changes, or someone forgets that “just for testing” can become “forever.”

Bastion dramatically reduces the incentive to make your VM publicly reachable. The VM can remain private (no public IP required), while you still access it securely.

2) Traditional bastion hosts

Classic bastion strategies often involve a dedicated VM that sits in a perimeter network and you RDP/SSH into that machine, then hop again to your target VM. This adds layers of complexity: you must secure the bastion host, manage patches, handle OS hardening, and defend it like any other server.

More layers means more things that can go wrong. Bastion replaces the “extra VM that you must babysit” with a managed service that’s designed for secure browser-based access.

3) VPN dependencies and user friction

VPN access can be secure but operationally annoying. Users have to connect, manage clients, and troubleshoot network routes. If you’ve ever asked, “Why can’t I reach that VM?” and someone responds, “I think my laptop is still on airplane mode,” you already understand the joy.

Bastion doesn’t eliminate networking complexity entirely, but it can reduce how often users need a VPN just to get into a private VM.

So what is Azure Bastion, in plain English?

Azure Bastion is a managed service that provides secure RDP and SSH connectivity to your Azure virtual machines from the Azure portal over TLS. In other words, you connect to a “Bastion host” experience that lives inside your virtual network. Your RDP/SSH session is then relayed securely to the target VM.

Instead of opening inbound RDP/SSH directly to the VM’s public surface area, you use Bastion as the entry point. This keeps your VM’s exposure low and your workflow smoother.

It’s essentially: “You click from the portal, you authenticate, and your browser becomes the tunnel.” The tunnel is the important part. The tunnel is also the part attackers can’t easily replicate just by poking around the internet.

Key concepts you should know before setting anything up

Before you click the magical buttons, here are the terms that typically show up when people implement Bastion. Knowing them early helps prevent the classic scenario where you deploy Bastion and then discover you chose the wrong network or subscription scope.

Bastion subnet

Azure Bastion requires a dedicated subnet in the same virtual network (VNet) where it will connect to your target VMs. This subnet is typically named something like “AzureBastionSubnet.” It has rules about size and should not overlap with other services in ways that break network assumptions.

Think of this subnet as Bastion’s “parking spot” inside your VNet. If your parking spot doesn’t exist or isn’t set up right, Bastion can’t pull into the garage.

Virtual network and routing

Bastion connects to your target VMs over the VNet. That means your NSGs, routing tables, and any firewalls must allow the traffic needed for RDP/SSH. If your target VM sits behind restrictive rules, Bastion may happily connect… to a wall.

Authentication and RBAC

Access to Bastion and its ability to open sessions is typically controlled by Azure role-based access control (RBAC) and permissions for the Bastion resource and VM resource. In practice, you want to grant least privilege: users get just enough rights to use Bastion for session creation.

Also remember: Bastion sessions still need OS credentials unless you’re using an approach that supports key-based authentication or more advanced identity integration (depending on your VM configuration and extensions). The details depend on how you secure your VMs.

TLS and secure transport

The connection from your browser to Bastion uses secure transport, which helps prevent eavesdropping. You’re still dealing with a network path that can be observed, but encryption protects the actual session data.

It’s the network equivalent of wearing a raincoat with sealed seams rather than trusting your umbrella’s optimism.

High-level architecture: what connects to what

Here’s a simplified picture of how Bastion fits into the world:

• Your user opens the Azure portal.
• The user chooses a VM and selects “Connect” via Bastion.
• The portal directs the session to the Bastion resource.
• Bastion relays RDP or SSH traffic to the target VM using the VNet connectivity.
• NSGs (and any additional network security layers) must allow the necessary traffic paths.

The important takeaway: you’re not routing directly to the VM from the public internet. You’re routing through Bastion within Azure’s controlled environment.

Step-by-step: securely set up access to VMs using Azure Bastion

Now let’s walk through a practical setup process. Exact UI wording and portal steps can vary slightly over time, but the workflow is consistent.

Step 1: Confirm your network design

Start with your virtual network (VNet). Identify:

• Which VNet your target VMs are in
• Whether the VMs have public IPs (try to avoid that for the secure model)
• Whether they’re in subnets reachable from the Bastion subnet
• Any route tables, firewalls, or private endpoints that might affect connectivity

If you already have NSGs, check whether they allow RDP/SSH traffic from the Bastion subnet to the VM subnet. Bastion won’t “break physics.” It still needs network permissions like any other communication.

Step 2: Create or locate the Bastion subnet

In the VNet that hosts your target VMs, create a dedicated subnet for Azure Bastion. This subnet is often called “AzureBastionSubnet.”

Azure Tenant Activation / Provisioning Make sure:

• Azure Tenant Activation / Provisioning The subnet is in the correct region (Bastion and VMs should align geographically)
• The subnet name matches what Bastion expects
• You don’t accidentally associate it with policies that block Bastion-required traffic
• You respect the required subnet sizing guidance (Bastion has minimums)

If you skip this or configure it incorrectly, you may see errors when creating the Bastion resource or when attempting connections.

Step 3: Deploy the Azure Bastion resource

In the Azure portal:

• Azure Tenant Activation / Provisioning Create a Bastion resource
• Select the VNet containing your Bastion subnet
• Choose the region
• Complete the deployment

During deployment, you’re essentially wiring up the managed Bastion service into your VNet. Once complete, Bastion is ready to accept browser-based session requests.

Be patient. Deployments aren’t always instant. If anyone says “it should be quick,” they are either lying or living in a universe where cloud services are magically faster.

Step 4: Ensure NSGs allow access from Bastion to the VM

Next, verify network security rules.

For RDP connections, traffic generally targets the VM’s RDP port. For SSH, it targets the SSH port. You want rules that allow Bastion subnet traffic to reach your VMs on the appropriate ports.

Common secure pattern:

• Allow inbound RDP (3389) only from the Bastion subnet to the VM
• Allow inbound SSH (22) only from the Bastion subnet to the VM
• Keep other inbound rules tight (avoid “Allow from Internet” unless you enjoy dramatic security audits)

Also check if outbound restrictions on the VM subnet could interfere with session behavior. Usually the main concern is inbound to the VM, but network rules can be layered in ways that surprise you.

Step 5: Test connectivity using the Azure portal

With Bastion deployed and networking adjusted, test access:

• Open the VM in the portal
• Select Connect
• Choose the Bastion-based connection option
• Authenticate using the VM credentials method you’ve configured

If the session opens, congratulations: your network and permissions are aligned. If it fails, don’t panic. Panicking just wastes time. Use troubleshooting steps instead.

Step 6: Validate that you’ve reduced exposure (and didn’t just move it around)

One of the biggest wins with Bastion is reduced exposure. Confirm:

• The target VM doesn’t rely on a public IP for management
• NSGs do not allow inbound RDP/SSH from the public internet
• Only authorized users can initiate Bastion sessions (via RBAC)

If you see a public IP still attached and enabled “just in case,” ask whether you truly need it. “Just in case” has a habit of becoming “always.”

Common implementation mistakes (and how to avoid them)

Let’s save you from a few classic faceplants.

Mistake 1: Forgetting the Bastion subnet requirements

If your Bastion subnet name is wrong, missing, too small, or misconfigured, Bastion won’t behave. Make it a checklist item. Create the subnet carefully and treat it as a structural dependency, not a suggestion.

Azure Tenant Activation / Provisioning Mistake 2: NSGs block traffic from the Bastion subnet

This is the top cause of “I can deploy Bastion but I can’t connect to the VM.” Review NSG inbound rules on the VM’s subnet and ensure they permit required traffic from the Bastion subnet.

Azure Tenant Activation / Provisioning If you have multiple layers (subnet NSGs, NIC NSGs), remember that all relevant rules must allow the traffic path. In security-land, denial can be cumulative.

Mistake 3: Confusing regions and VNets

Bastion is deployed into a region and attaches to a VNet. Ensure your target VMs are reachable from that same VNet and that you’re not accidentally trying to connect across assumptions that don’t hold. If your VMs are in a different VNet, you may need Bastion in that VNet or additional network connectivity design.

Mistake 4: Over-granting permissions

Azure Tenant Activation / Provisioning It’s tempting to grant broad “owner” access so that everything works quickly. But secure VM access is the opposite of “quickly.” Use RBAC carefully: allow users to use Bastion session creation and view appropriate resources without giving more than necessary.

Mistake 5: Using weak VM credentials

Bastion can secure transport and entry. It doesn’t automatically make weak passwords strong. If your VM uses weak credentials, attackers may still succeed once they’re inside.

Follow your organization’s identity and credential standards. Rotate secrets when appropriate. Consider stronger authentication methods available for your OS configuration.

Best practices for secure Bastion-based access

Here’s a practical list of best practices that won’t win you a medal, but will help keep your environment from turning into a cautionary tale.

Use least privilege with RBAC

Azure Tenant Activation / Provisioning Grant only the permissions needed to start Bastion sessions and access required resources. Separate roles where possible (for example, VM admins vs. network operators). Keep a tight feedback loop: if nobody needs broad VM permissions, don’t give them.

Keep VMs private when feasible

Prefer private IPs without public inbound exposure for management. Bastion is designed for secure access without requiring public RDP/SSH availability.

Lock down NSGs to allow only what’s needed

Allow inbound RDP/SSH from the Bastion subnet to the VM subnet. Avoid “allow from anywhere” rules. Also ensure outbound rules won’t accidentally block return traffic or complicate connectivity.

Centralize logging and audit session behavior

Make sure your organization can audit access. Use Azure monitoring and logging tools to capture relevant events. Track changes to networking rules and Bastion configuration.

Even if Bastion reduces exposure, you still want visibility into who connected and when. Security without auditing is just a bedtime story with extra steps.

Use secure authentication patterns for the OS

For Linux VMs, prefer SSH keys and strong configurations. For Windows VMs, use secure credential practices. If your organization supports identity-based approaches, align Bastion access with those methods.

The key principle: ensure the “door” is secure and the “passwords inside the house” are also secure.

Document the dependency

Write down which VNet/subnets support Bastion and which NSGs rules allow access. Document it like you’d want future-you to read it during an outage. Future-you is always more tired.

Performance and user experience: what it feels like

From a user perspective, Bastion-based access generally means:

• Fewer client setup steps (no separate jump box VM to manage)
• RDP/SSH sessions initiated from the portal
• A more consistent connection path for users

From an admin perspective, it often means fewer “why is the bastion VM down?” emergencies and less OS maintenance for that intermediate host. That’s a win that’s hard to quantify until you’ve lived through the alternative.

Troubleshooting: when Bastion won’t let you in

Here’s a pragmatic troubleshooting approach. Don’t shotgun-patch everything. Follow a path.

Check 1: Bastion subnet and VM subnet connectivity

Confirm that your VM is in a subnet that can route traffic from the Bastion subnet. If you have custom routing or firewalls, validate the path.

Check 2: NSG rules

Look at NSG inbound rules on the VM’s subnet (and any NIC-level NSGs). Ensure they allow RDP or SSH traffic from the Bastion subnet address range. Also check for conflicting deny rules.

Check 3: VM status and service readiness

If the OS isn’t accepting RDP/SSH (service disabled, firewall blocking inside the VM), Bastion won’t fix that. Confirm:

• RDP service (Windows) is enabled
• SSH service (Linux) is installed, enabled, and listening
• Host-level firewall rules allow inbound connections from the Bastion subnet

If you tightened the guest firewall recently, that’s usually where the issue hides.

Check 4: Credentials and authentication

If you reach the VM but authentication fails, Bastion is doing its job. The issue is likely with credentials, account status, or password rotation. Verify that the account you’re using has access and that the credentials aren’t expired.

Check 5: RBAC permissions

If users can’t initiate sessions, it may be permission-related. Check Azure RBAC roles granted to the user and any restrictions on the Bastion resource.

Operational governance: making it sustainable

Setting up Bastion is one thing. Keeping it secure over time is where the real work happens. Here are governance patterns that scale.

Create a standard network template

For example: every app VNet includes:

• The correct Bastion subnet
• NSG rules that allow Bastion-to-VM management traffic only
• Consistent naming for easier auditing

Templates help reduce “human creativity” in network configuration. Humans are brilliant, but networks are unforgiving.

Define who can use Bastion

Set clear policies: which roles can access production VMs, which can access non-production, and when elevated access is allowed. Pair Bastion with your approval workflows if you have them.

The goal is simple: access should be intentional, logged, and reversible.

Pair Bastion with monitoring and incident response

When something looks off, you want to know quickly. Ensure your organization monitors:

• Changes to Bastion resources
• NSG changes affecting management ports
• Authentication failures
• Unexpected session activity

Security isn’t just prevention; it’s also detection. Bastion helps with prevention, but detection still needs you.

Cost considerations: the practical reality

Managed services are convenient, which usually means they cost money. Bastion typically has pricing based on features and availability, depending on the region and configuration. To avoid surprises:

• Review current pricing for Azure Bastion
• Estimate usage patterns (number of VMs, number of users, session frequency)
• Ensure your organization understands the cost drivers

The usual trade-off is worth it for many teams: you trade the cost of managing a bastion VM and the risk of misconfiguration for a managed service designed for secure access.

Frequently asked questions

Do I still need NSGs?

Yes. Bastion helps control the entry point, but NSGs and host-level firewalls are still essential. Secure VM access is a chain; Bastion is a strong link, not an entire necklace.

Do my VMs need public IP addresses?

Often, no. A common secure approach keeps VMs private and relies on Bastion for management. Your environment’s design may vary, but Bastion is typically used to avoid direct public RDP/SSH.

Can users connect from the Azure portal?

Yes—that’s one of Bastion’s core benefits. Users can initiate RDP or SSH sessions through the portal, usually from supported browsers and environments.

Is Bastion a replacement for VM hardening?

No. It’s a safer pathway to reach the VM, but you still must harden the OS, configure firewalls, apply patches, and follow credential best practices.

Conclusion: secure access without the “public internet bingo”

Secure VM access shouldn’t feel like rolling dice. Azure Bastion helps you reduce the need to expose RDP and SSH directly to the internet, replacing the risky “public port and hope” model with a controlled, managed entry point. It also eliminates the operational burden of maintaining a dedicated jump box VM, which is one less thing to patch, break, or forget.

If you implement Bastion correctly—dedicated Bastion subnet, properly configured NSGs, secure VM authentication, and good logging—you get a cleaner and safer workflow for administering virtual machines. You also get something precious in cloud operations: fewer late-night mysteries and fewer moments where you stare at a firewall rule like it’s written in a dead language.

So go ahead: build the Bastion tunnel, keep your VMs private, and let your connections be secure by design rather than secure by accident.