If you run firewalls, routers, or SD‑WAN NVAs in Azure and your pain is connection scale rather than raw Mbps, there is a feature you should look at: Accelerated Connections.
Hello folks,
If you run firewalls, routers, or SD‑WAN NVAs in Azure and your pain is connection scale rather than raw Mbps, there is a feature you should look at: Accelerated Connections. It shifts connection processing to dedicated hardware in the Azure fleet and lets you size connection capacity per NIC, which translates into higher connections‑per‑second and more total active sessions for your virtual appliances and VMs.
This article distills a recent E2E chat I hosted with the Technical Product Manager working on Accelerated Connections and shows you how to enable and operate it safely in production. The demo and guidance below are based on that conversation and the current public documentation.
What Accelerated Connections is (and what it is not)
Accelerated Connections is configured at the NIC level of your NVAs or VMs. You can choose which NICs participate. That means you might enable it only on your high‑throughput ingress and egress NICs and leave the management NIC alone.
It improves two things that matter to infrastructure workloads:
- Connections per second (CPS). New flows are established much faster.
- Total active connections. Each NIC can hold far more simultaneous sessions before you hit limits.
It does not increase your nominal throughput number. The benefit is stability under high connection pressure, which helps reduce drops and flapping during surges. There is a small latency bump because you introduce another “bump in the wire,” but in application terms it is typically negligible compared to the stability you gain.
How it works under the hood
In the traditional path, host CPUs evaluate SDN policies for flows that traverse your virtual network. That becomes a bottleneck for connection scale. Accelerated Connections offloads that policy work onto specialized data processing hardware in the Azure fleet so your NVAs and VMs are not capped by host CPU and flow‑table memory constraints.
Industry partners have described this as decoupling the SDN stack from the server and shifting the fast‑path onto DPUs residing in purpose‑built appliances, delivered to you as a capability you attach at the vNIC. The result is much higher CPS and active connection scale for virtual firewalls, load balancers, and switches.
Sizing the feature per NIC with Auxiliary SKUs
You pick a performance tier per NIC using Auxiliary SKU values. Today the tiers are A1, A2, A4, and A8. These map to increasing capacity for total simultaneous connections and CPS, so you can right‑size cost and performance to the NIC’s role.
As discussed in my chat with Yusef, the mnemonic is simple: A1 ≈ 1 million connections, A2 ≈ 2 million, A4 ≈ 4 million, A8 ≈ 8 million per NIC, along with increasing CPS ceilings. Choose the smallest tier that clears your peak, then monitor and adjust. Pricing is per hour for the auxiliary capability.
Tip: Start with A1 or A2 on ingress and egress NICs of your NVAs, observe CPS and active session counters during peak events, then scale up only if needed.
Where to enable it
You can enable Accelerated Connections through the Azure portal, CLI, PowerShell, Terraform, or templates. The setting is applied on the network interface. In the portal, export the NIC’s template and you will see two properties you care about: auxiliaryMode and auxiliarySku.
Set auxiliaryMode to AcceleratedConnections and choose an auxiliarySku tier (A1, A2, A4, A8).
Note: Accelerated Connections is currently a limited GA capability. You may need to sign up before you can configure it in your subscription.
Enablement and change windows
- Standalone VMs. You can enable Accelerated Connections with a stop then start of the VM after updating the NIC properties. Plan a short outage.
- Virtual Machine Scale Sets. As of now, moving existing scale sets onto Accelerated Connections requires re‑deployment. Parity with the standalone flow is planned, but do not bank on it for current rollouts.
- Changing SKUs later. Moving from A1 to A2 or similar also implies a downtime window. Treat it as an in‑place maintenance event.
Operationally, approach this iteratively. Update a lower‑traffic region first, validate, then roll out broadly. Use active‑active NVAs behind a load balancer so one instance can drain while you update the other.
Operating guidance for IT Pros
- Pick the right NICs. Do not enable on the management NIC. Focus on the interfaces carrying high connection volume.
- Baseline and monitor. Before enabling, capture CPS and active session metrics from your NVAs. After enabling, verify reductions in connection drops at peak. The point is stability under pressure.
- Capacity planning. Start at A1 or A2. Move up only if you see sustained saturation at peak. The tiers are designed so you do not pay for headroom you do not need.
- Expect a tiny latency increase. There is another hop in the path. In real application flows the benefit in fewer drops and higher CPS outweighs the added microseconds. Validate with your own A/B tests.
- Plan change windows. Enabling on existing VMs and resizing the Auxiliary SKU both involve downtime. Use active‑active pairs behind a load balancer and drain one side while you flip the other
Why this matters
Customers in regulated and high‑traffic industries like health care often found that connection scale forced them to horizontally expand NVAs, which inflated both cloud spend and licensing, and complicated operations. Offloading the SDN policy work to dedicated hardware allows you to process many more connections on fewer instances, and to do so more predictably.
Resources
- Azure Accelerated Networking overview: https://learn.microsoft.com/azure/virtual-network/accelerated-networking-overview
- Accelerated connections on NVAs or other VMs (Limited GA): https://learn.microsoft.com/azure/networking/nva-accelerated-connections
- Manage accelerated networking for Azure Virtual Machines: https://learn.microsoft.com/azure/virtual-network/manage-accelerated-networking
- Network optimized virtual machine connection acceleration (Preview): https://learn.microsoft.com/azure/virtual-network/network-optimized-vm-network-connection-acceleration
- Create an Azure Virtual Machine with Accelerated Networking: https://docs.azure.cn/virtual-network/create-virtual-machine-accelerated-networking
Next steps
- Validate eligibility. Confirm your subscription is enabled for Accelerated Connections and that your target regions and VM families are supported. Learn article
- Select candidate workloads. Prioritize NVAs or VMs that hit CPS or flow‑table limits at peak. Use existing telemetry to pick the first region and appliance pair. 31
- Pilot on one NIC per appliance. Enable on the data‑path NIC, start with A1 or A2, then stop/start the VM during a short maintenance window. Measure before and after. 32
- Roll out iteratively. Expand to additional regions and appliances using active‑active patterns behind a load balancer to minimize downtime. 33
- Right‑size the SKU. If you observe sustained headroom, stay put. If you approach limits, step up a tier during a planned window. 34
Microsoft