7 posts tagged with "networks"

Azure service endpoints have always been the budget-friendly option for locking down PaaS access from a virtual network — no DNS changes, no private IPs to manage, just a route and an ACL. The catch is that they don't scale well. Each subnet gets its own entry in the storage account or SQL firewall, and when you have dozens of spoke VNets the ACL list becomes unmanageable.

The new standard service endpoint, now in public preview, fixes that. Instead of registering every subnet individually, you assign a single public IP address as a network identifier and use that one IP across all your subnets in a region. The PaaS resource sees one ACL entry, not one per subnet.

This is still service endpoint territory — traffic goes over the Azure backbone, not over a private endpoint — but the management story is dramatically simpler at scale.

Azure VPN Gateway IPv6 support is now generally available. You can run dual-stack VPN designs and carry IPv6 traffic between on-prem and Azure without staying in preview.

For teams moving to IPv6, this is a useful step. It means you can keep one platform pattern for remote connectivity instead of building awkward side paths for IPv6 workloads.

I also like that this lines up with existing VPN Gateway workflows. If you already know how to build site-to-site or point-to-site with Azure VPN Gateway, the IPv6 setup feels familiar.

Microsoft is retiring Inbound NAT Pools for Azure Virtual Machine Scale Sets on 30 September 2027. This is the VMSS-specific part of Inbound NAT rule V1 on Azure Load Balancer.

That sounds narrow, but it matters if you still use load balancer frontend port ranges to reach scale set instances for SSH, RDP, or similar admin access. Microsoft also says you won't be able to create new Inbound NAT Pools from 15 November 2026.

The key point is simple: single VM Inbound NAT rule V1 isn't being retired. This change is only for the old VMSS pattern, and the replacement is Inbound NAT rule V2 that targets a backend pool instead.

Microsoft is retiring the Azure VPN Client for Linux (Preview) on 31 August 2026. If you still rely on the microsoft-azurevpnclient package for point-to-site access into Azure, you've now got a clear deadline to move.

The important detail is what isn't changing. Your VPN Gateway or Virtual WAN gateway isn't being retired, and neither are the Windows or macOS Azure VPN clients. This is only about the Linux preview client.

If you've got Linux users connecting with Microsoft Entra ID, this matters more than it first appears. The supported Linux replacements don't offer that same Entra ID path, so this isn't just a package swap. For some teams it's a small tidy-up. For others it's a design change.

Microsoft has made managed virtual network support for evaluations in Microsoft Foundry generally available. You can now keep evaluation workloads inside a Microsoft-managed private network boundary without having to build and run your own virtual network just to get started.

If you work in a regulated environment, or you simply want tighter control of outbound traffic, this is a useful step. It gives you a cleaner path to private connectivity for evaluation runs, while still letting you use Foundry's hosted evaluation features.

The nice part is that Microsoft handles most of the plumbing. You still choose the isolation mode and approve access to the services you need, but you don't have to manage the underlying network estate yourself.

Microsoft has raised the default Azure Virtual Network limits for both Network Security Groups (NSGs) and route tables. This is now generally available, so you get the new limits without opening a support request.

For teams running large hub-and-spoke estates, or anyone segmenting traffic with lots of explicit routes and rules, this removes a common scaling pain. You can keep cleaner designs with fewer workarounds.

The new defaults are 2,000 rules per NSG, up to 6,000 addresses or ports in an NSG rule, 1,000 routes per route table, and 600 route tables per subscription by default.

Microsoft has put summarized advertised gateway prefixes into public preview for Azure hybrid gateways. In plain terms, you can now tell Azure to advertise a smaller, cleaner set of CIDRs to on-prem instead of every hub and spoke prefix.

This matters when your hub-and-spoke estate gets large and your route table starts to look like a junk drawer. Fewer advertised prefixes can reduce operational noise and help you stay under ExpressRoute advertised prefix limits.

The update applies to Azure VPN Gateway and ExpressRoute Gateway scenarios where route advertisement scale and control are both pain points.