Cloud Updates

Azure DDoS Protection has always used machine learning to auto-tune detection thresholds per protected resource. That adaptive approach works well for most workloads — but it can be a poor fit if your traffic has known, predictable patterns that don't match what the model expects. The new custom policy feature, now in public preview, lets you override the automatic thresholds with your own fixed values for specific protocols.

Think of it like this: adaptive tuning is the thermostat that learns your home's routine and adjusts itself. A custom policy is the moment you decide the thermostat is wrong and set the temperature yourself. For most people the thermostat is fine. For the person who hosts a gaming event every Saturday night, knowing exactly what "normal" looks like makes a manual override worth it.

The feature works at the protocol level — TCP, UDP, and TCP SYN — and applies to inbound traffic on Standard Load Balancer frontend IPs. Protocols you don't tune continue using adaptive mitigation, so you only take over what you specifically need to control.

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.

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.