Networking

Secure Your VNets with Private Subnets

Secure Your VNets with Private Subnets

A couple of weeks ago we talked about how Microsoft is deprecating default internet access for VMs](https://samcogan.com/retiring-default-internet-access-for-vms/) in September 2025. This change is being done because it doesn’t meet Microsoft’s “secure by design” approach. However, you don’t need to wait till 2025 if you want to get ahead of the game and secure your outbound traffic due to the introduction of private subnets. By declaring your subnet as private you disable default outbound access and out of the box any VMs in that subnet will not have access to the internet.
Retiring Default Internet Access for VMs

Retiring Default Internet Access for VMs

There’s a big change coming to Azure VM networking in September 2025. Yes, that’s a way off, but it will pay to plan for this now. VM networking in Azure has differed from AWS for a long time, in that Azure VMs are automatically able to make outbound connections to the internet, with no configuration required from the user. AWS on the other hand, takes the opposite approach. By default, AWS VMs have no internet access, and you have to explicitly configure it if you need it, through something like a NAT Gateway.
Static IP Ranges with Azure Public IP Prefixes

Static IP Ranges with Azure Public IP Prefixes

Azure has offered the ability to get static public IP addresses for many years now, however when you request an IP you will receive one from the general pool of available addresses and it is very unlikely you will receive multiple IPs in the same range. A new preview feature announced at Ignite changes this, called Public IP Address Prefixes. Instead of requesting a single static IP you can request a Prefix, which will give you a contiguous range of IP addresses.
Troubleshoot Azure NSG issues with Network Watcher

Troubleshoot Azure NSG issues with Network Watcher

At some point, I imagine most people working with Azure VMs have hit issues with being able to connect to services running inside a vNet. A lot of the time these issues boil down to the configuration of Network Security Groups to allow traffic into the VM. The process of troubleshooting these issues and determining which NSG and which NSG rule is at fault can be time-consuming, especially with complex networks.
Simplify Azure NSG Rules With Augmented Rules and Service Tags

Simplify Azure NSG Rules With Augmented Rules and Service Tags

Historically Azure Network Security Groups (NSG’s) have only allowed you to enter a single value for things things like source or destination IP and source or destination port. This has meant that for complex setups you end up with a very large amount of NSG’s. This is especially if you are trying to filter a large amount of IP’s, for example the Azure Data Center IP ranges, which is a common requirement if you want to restrict outbound access but allow access to PaaS resources.