Networking

AKS now supports applying FQDN based network polcies to restrict traffic, however it’s part of the Advanced Container Networking Services product, which comes at an additional cost.

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.

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.

On the face of it, Service Endpoints and Private Link seem very similar, whats the difference and when would you use which?

If you need your outbound traffic from an Azure vNet to use a consistent IP address there are a few different ways to achieve it. Here’s what they look like.

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.

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.

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.