Cloud Updates

If you're running self-hosted AI models on AKS, routing inference traffic is a different problem to routing web traffic. A standard HTTP load balancer doesn't know about GPU queue depth or KV cache utilisation — it just sees HTTP requests. The new inference gateway for Application Gateway for Containers changes that.

Microsoft put this feature into public preview on 24 June 2026. It brings the Kubernetes Gateway API Inference Extension into Application Gateway for Containers, giving you model-aware routing decisions at the ingress layer without building your own sidecar logic.

The short version: your gateway can now pick which model server pod handles a request based on real-time signals from the model itself, not just round-robin or connection count.

Azure WAF has long had exclusion lists — a way to tell the firewall to skip inspecting a specific part of a request, like a header or a cookie. Exceptions are different. They let you skip entire rules, rule groups, or managed rulesets for specific requests, based on attributes like the request URI, the caller's IP address, or a specific header value.

Both Azure Application Gateway and Azure Front Door now support this in public preview.

Think of it this way: an exclusion says "ignore this cookie when running all rules", but an exception says "don't run the SQL injection rule group at all when the request comes from 10.0.0.1". That's a meaningful difference in how precisely you can tune the WAF without weakening protection broadly.

Microsoft has made Network Security Perimeter (NSP) support for Azure Event Hubs generally available. If you've been waiting to use this in production, the wait is over.

NSP lets you draw a logical security boundary around your PaaS resources. Instead of managing individual service firewalls for every resource, you define access rules at the perimeter level and let Azure handle the rest. Event Hubs now joins the growing list of services that support it.

This matters because Event Hubs is often the front door for high-volume data pipelines — telemetry, logs, Kafka topics, IoT streams. Securing that front door without a tangle of per-namespace firewall rules is a real improvement.

Azure StandardV2 NAT Gateway now supports outbound ICMP Echo Request and Echo Reply traffic. In plain English, that means ping now works for workloads that leave the internet through a StandardV2 NAT Gateway.

I like this update because it fixes a small but real gap in day-to-day troubleshooting. Before this, NAT Gateway handled TCP and UDP well, but basic reachability tests with ping were off the table.

The feature is live by default. If your subnet already uses a StandardV2 NAT Gateway, you don't need to switch on a setting or add a rule to start using it.

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.