Virtual Network – Get Practical

Azure Networking Tips & Techniques - Part 1

Azure recently announced the general availability of Private Subnet, a new feature that allows you to disable the implicit outbound Internet connectivity for virtual machines in a subnet. In this blog post, we’ll cover:

What Azure Private Subnets are and why they matter
Key benefits of disabling default outbound access
Step-by-step instructions to configure a private subnet via the Azure Portal
Verifying that default outbound has been disabled

What Is an Azure Private Subnet?

Traditionally, when you create a subnet in an Azure Virtual Network (VNet) without any explicit outbound connectivity (such as a NAT gateway, Public IP, or Load Balancer), Azure automatically provides a default outbound access IP for those VMs. While this is convenient, it introduces an implicit egress path—VMs can communicate with public endpoints without you having explicitly configured any egress resources.

A Private Subnet in Azure is simply a subnet where this default outbound access is turned off. Consequently:

Any VM deployed within that subnet cannot reach the Internet by default.
You must explicitly configure an alternative egress mechanism if VMs need outbound connectivity (e.g., NAT Gateway, Standard Load Balancer, Firewall, or a Public IP assigned directly to the NIC).

By removing the implicit outbound IP, Azure Private Subnets enforce a “zero trust” approach: no VM can communicate externally until you grant it an explicit, auditable path.

Why Disable Default Outbound Access?

Secure by Default
Default outbound IPs are not customer-owned and can change unpredictably. By disabling implicit egress, you ensure VMs only send traffic externally when you explicitly allow it, reducing your attack surface.
Prevent Data Exfiltration
In regulated or highly sensitive environments (for example, PCI-DSS or HIPAA workloads), any unsolicited outbound route can pose compliance or security risks. Private Subnets eliminate unexpected data exfiltration channels.
Encourage Explicit Egress Configuration
When default outbound is disabled, you must provision a known, managed egress mechanism (like a NAT Gateway), which can be tightly monitored for logging, analytics, and cost control. This “explicit-over-implicit” model aligns with best practices for cloud network security.

Continue reading “Introducing Azure Private Subnets: Enhancing Security by Disabling Default Outbound Access”

When managing cloud-based virtual machines, ensuring secure access is critical. Exposing RDP/SSH ports over the internet introduces potential security vulnerabilities. Azure Bastion provides a secure, fully managed solution to connect to Azure VMs without needing to expose these ports to the public internet.

What is Azure Bastion?

Azure Bastion is a PaaS service that allows you to securely connect to your Azure Virtual Machines (VMs) using RDP or SSH, directly from the Azure Portal without the need to expose these ports via a public IP.

Minimum Required RBAC Roles for Azure Bastion Access

To connect to a VM using Azure Bastion, the user must have the appropriate permissions. At a minimum, they will need the following role assignments:

Reader role on the target VM: This grants read access to the VM, allowing the user to see the VM’s configuration but not modify it.
Reader role on the network interface (NIC) associated with the VM’s private IP address: This ensures the user can read network information for the VM.
Reader role on the Azure Bastion resource: This grants access to the Bastion host itself, allowing the user to initiate connections through Bastion.

If the VM is in a peered virtual network (cross-VNet connections), the following additional role assignment is required:

Reader Role on the virtual network (VNet) of the target VM: This is necessary if you are connecting to a VM across VNet peering.

Continue reading “How to Implement Azure Bastion to Securely Access Azure Virtual Machines”