Recommend a Solution to Optimize Network Performance — Lesson

A global e-commerce platform with users on five continents finds its $p99$ checkout latency creeping past 2 seconds. The team's first instinct is to scale up the App Service plan to a higher SKU. The architect runs a network path trace instead and quickly finds the latency is not in compute at all — it's in network hops: clients in Sydney are routed to a single regional Application Gateway in West Europe via the public internet, adding $\sim 300$ ms of round-trip latency to every single request. The architect's fix touches three things at once: deploy Azure Front Door Premium at the global edge to terminate TLS close to clients, enable Accelerated Networking on every supported VM (configurable but not previously set anywhere), and switch the backend regional load balancer to a zonal Standard SLB configuration with reduced cross-zone packet hops. Checkout latency drops to roughly 480 ms at $p99$ — well inside the team's 1 second target. This lesson is about deliberately tuning Azure network performance — using AnyCast, hardware bypass, proximity placement, global peering, and protocol upgrades — instead of throwing more compute at fundamentally network-shaped latency problems.

We will work through Azure's network-performance optimisation story the way the AZ-305 exam expects you to: Azure Front Door AnyCast, Azure Front Door Standard (retired but still exam-tested), Accelerated Networking, Proximity Placement Groups, ExpressRoute FastPath, Global VNet Peering, and receive-side scaling techniques. Reference: the AZ-305 exam study guide, particularly Chapter 4 Skill $4.4 on network performance, plus the Azure Well-Architected Framework's Performance Efficiency pillar.

Why This Matters

Network latency is the silent tax on user experience and the most common silent failure mode in apparently-healthy systems. A 50 ms network delay roughly costs 5% of conversion in e-commerce; a 200 ms delay can halve API throughput on chatty protocols. The AZ-305 exam tests this LO because architects regularly misdiagnose latency problems as compute problems and pick the wrong fix — adding cores when the issue is a missing edge POP, or scaling up the SKU when the bottleneck is a missing AN flag on the NIC.

The career payoff is concrete: every "the app feels slow globally" complaint, every $p99$-latency review, every HPC-class workload, every "we need to add a region for one user community" discussion, and every customer SLO retrospective touches this LO at some point.

Prerequisites

• Layer-4 vs layer-7. Can you describe the difference and where each operates? — Self-check: which one parses HTTP headers?
• AnyCast. Are you familiar with how AnyCast routes packets to the nearest edge? — Self-check: which service uses it in Azure?
• Accelerated Networking concept. Do you know what AN does? — Self-check: which family of SKUs supports it?
• Proximity Placement Group. Have you used PPG? — Self-check: what guarantee does it give?
• Latency vs bandwidth. Can you describe both and which dominates user experience at various distances? — Self-check: which one matters most for chatty protocols?

If any of these feels shaky, pause and review LO-26 (HA for compute) and LO-45 (internet connectivity) before continuing — both touch performance-adjacent topics.

Learning Objectives

1. Analyse a network-performance problem (latency, throughput, jitter, packet loss) and identify the bottleneck layer in the call path.
2. Recommend edge / AnyCast solutions (Front Door Standard / Premium) for global low-latency.
3. Configure VM-level acceleration with Accelerated Networking, Proximity Placement Group, and right-sized SKUs.
4. Apply ExpressRoute FastPath for very-high-throughput hybrid workloads that exceed the standard gateway's throughput cap.
5. Design Global VNet Peering for cross-region private VNet connectivity at Microsoft-backbone latency.
6. Recognise common anti-patterns — using Basic Load Balancer for global workloads, missing Accelerated Networking on chatty workloads, reaching for cross-region peering when same-region zonal would suffice, ignoring HTTP/2 for chatty APIs — and rewrite each one with the appropriate fix.

Building Blocks

AnyCast — Routing technique where the same IP address is announced from multiple locations; BGP picks the topologically nearest. Formally, the foundation of Azure Front Door's global edge. It matters because AnyCast gives single-IP global ingress with automatic geo-proximity routing.

Accelerated Networking (AN) — SR-IOV-based bypass of the host networking stack on Azure VMs. Formally, a NIC property (enableAcceleratedNetworking: true) that maps the VM's NIC directly to host hardware. Reduces latency by $\\sim 10\\times$ and CPU per packet. Supported on D, E, F, L, M, N, H families at $\\ge 2$ vCPU. It matters as the cheapest network performance win in Azure — and the most often missed.

Proximity Placement Group (PPG) — A logical grouping that asks Azure to keep members physically close. Formally, Microsoft.Compute/proximityPlacementGroups. Co-locates VMs in the same datacentre row / rack. It matters when microsecond inter-VM latency is needed (HPC, SAP HANA scale-out, low-latency trading).

ExpressRoute FastPath — A feature that bypasses the VNet gateway in the data path. Formally, requires Premium / Ultra performance SKU + Direct port. Reduces hybrid-traffic latency and offloads gateway. It matters for heavy data egress workloads where the gateway is the bottleneck.

Global VNet Peering — VNet peering across Azure regions via the Microsoft backbone. Formally, virtualNetworkPeerings between VNets in different regions. Provides sub-region-pair latency between VNets. It matters for cross-region private workloads (cross-region replicas, hub-spoke spans).

Azure Front Door — Already covered. In this LO, it's the global edge service used to bring traffic close to users via AnyCast.

Receive-Side Scaling (RSS) — A Windows / Linux feature that spreads packet processing across CPU cores. AN-enabled VMs receive RSS-style spread natively. It matters for throughput-bound workloads.

Latency tax — Common phrase for the user-experience cost of network round-trips. Each extra 100 ms of round-trip latency typically translates to a measurable conversion or engagement loss in user-facing applications and to lower throughput on chatty inter-service protocols.

Deep Dive

1. Where the latency budget goes

A request from a client to a backend traverses several layers. Each adds latency.

The architect's job is to compress the avoidable layers. The biggest single wins are: terminate TLS at the edge (Front Door), use AN on VMs, and place stateful services in the same region as compute.

2. Front Door AnyCast for global ingress

Without Front Door, the Sydney user's TCP handshake and TLS negotiation happen over a $\\sim 300$ ms public-internet path. With Front Door, the handshake terminates at the Sydney POP and the HTTP request is sent over Microsoft's optimised backbone to the origin. Net latency reduction: typically $30{-}60\%$.

[!TIP] For static / cacheable responses, the saving is larger because the response is served from the POP cache itself. Match the cache rules to content type for maximum benefit.

3. Accelerated Networking on VMs

Accelerated Networking is the cheapest single network-performance win on Azure. The bicep:

[!WARNING] AN is supported on most D/E/F/L/M/N/H series VMs at $\\ge 2$ vCPU but is NOT supported on B-series burstable VMs. If the workload is on B-series and needs AN, change family.

4. Proximity Placement Groups for low-latency clusters

When inter-VM latency must be microseconds — HPC, SAP HANA scale-out, low-latency trading — Proximity Placement Group keeps VMs physically close.

[!IMPORTANT] PPG and Availability Zones are partially exclusive — PPG keeps everything together; AZ spreads everything apart. The compromise is a "zonal PPG" pinning the group to one zone. Use PPG only when latency demands; otherwise prefer AZ.

5. ExpressRoute FastPath

For very-high-throughput hybrid workloads, FastPath removes the VNet gateway from the data path. The gateway still handles BGP / control plane, but data packets go directly to backend VMs.

6. Global VNet Peering vs gateway-routed cross-region

Cross-region private connectivity has two options:

Global VNet Peering wins for cross-region private workloads. Limitations: NSGs apply; some service edge cases (e.g., Basic LB) do not support peered traffic.

7. CDN — retired, prefer Front Door

Azure Front Door Standard profiles (Standard from Microsoft, Verizon, Akamai) are retired or retiring. The AZ-305 exam still tests recognising the migration path: any new edge / cache scenario should use Front Door Standard or Premium. Existing CDN workloads need migration plans (covered in LO-37).

8. MTU and TCP tuning

Beyond service choices, OS-level network settings can move performance. Two levers:

MTU (Maximum Transmission Unit). Azure VMs default to 1500 bytes. Jumbo frames (9000 bytes) are not supported in Azure VNets — do not enable them. The exam tests recognising this constraint: workloads coming from on-prem jumbo-frame environments must reset MTU on migration.

TCP window scaling. Long-distance flows benefit from larger TCP windows. Modern OS defaults are usually adequate; for $> 1$ Gbps over $> 50$ ms RTT, verify net.core.rmem_max (Linux) or registry equivalent (Windows) is sized for the bandwidth-delay product.

[!NOTE] The bandwidth-delay product for a 1 Gbps link with 100 ms RTT is $1{,}000{,}000{,}000 \times 0.1 / 8 = 12.5$ MB. The TCP receive buffer should be at least this large to allow full-bandwidth utilisation.

9. Cross-zone traffic charges and latency

In multi-zone deployments, traffic between zones incurs both latency ($\sim 1{-}2$ ms) and per-GB charges. For latency-sensitive workloads that don't strictly need cross-zone HA, prefer single-zone deployments. The exam often hides this nuance: a workload that requires "low latency" and "high availability" may not require zonal HA — a same-zone Availability Set may suffice with lower cost and latency.

10. Front Door's edge selection algorithm

Front Door uses AnyCast + a private routing algorithm to select origin. Key features:

Combine with backend availabilityProbes to ensure POP-to-origin health is monitored continuously. Set intervalInSeconds: 30 for fast detection of regional outages.

11. Connection multiplexing — HTTP/2 and gRPC

For chatty APIs, the protocol matters as much as the network. HTTP/$1.1 opens a new TCP connection per request (or limited keepalive). HTTP/2 multiplexes many streams over one connection — reducing handshake overhead dramatically. gRPC uses HTTP/2 natively.

Front Door supports HTTP/2 inbound by default. Application Gateway supports HTTP/2 inbound from clients (when enabled), and backend HTTP/2 is available in newer versions. Configure end-to-end HTTP/2 where the workload uses chatty APIs.

[!TIP] For internal microservice meshes, gRPC over HTTP/2 via Application Gateway or Container Apps ingress is the fastest pattern. Convert REST-over-HTTP/$1.1 APIs to gRPC when the inter-service call rate exceeds 100 rps per pair.

Worked Examples

Easy — pick the global edge

Problem. Customers in Asia complain of slow page loads. The site is hosted in West Europe. Recommend.

Solution. Deploy Front Door Premium in front. AnyCast routes Asian users to the nearest POP; backbone delivers requests to West Europe origin with lower latency than public internet. Enable caching for cacheable responses.

Medium — VM throughput problem

Problem. A VM-based proxy is bottlenecking at 3 Gbps of throughput; the SKU advertises 10 Gbps capability. Diagnose.

Solution. Check Accelerated Networking. If enableAcceleratedNetworking: false, packet processing goes through the host's vSwitch and caps far below NIC capability. Enable AN; expect $\\sim 3{-}5\\times$ improvement.

Hard — HPC cluster needing microsecond latency

Problem. A 40-node HPC cluster runs MPI workloads. Inter-node latency over standard VMSS deployment is $\\sim 2$ ms; target is $< 100 \\mu s$.

Solution. Switch to HPC VM SKUs (HB/HC series with InfiniBand). Place all nodes in a Proximity Placement Group. Use SR-IOV and RDMA for MPI inter-process communication. Result: inter-node latency drops to $\\sim 3{-}5 \\mu s$, MPI workloads scale linearly.

12. Region pair and latency-aware design

Different Azure regions have different latency profiles to each other. Microsoft publishes a latency matrix; some pairs that look geographically close have surprising hops. For multi-region designs, choose the latency-paired region rather than the geographically nearest. Some examples:

Cross-region replication latency directly drives RPO for async-replicated data services (Cosmos DB, ZRS storage with paired region, etc.).

13. Per-VM bandwidth caps and tuning

Every Azure VM SKU has a documented expected network bandwidth. The exam tests recognising that throughput claims are per VM, not per port:

A workload hitting its VM bandwidth ceiling needs a bigger VM, not just AN. Read the spec sheet before sizing.

[!IMPORTANT] A common cause of "throughput stuck at $X$" is that $X$ is the per-VM cap. Upsizing the SKU or distributing across more VMs is the only path through it.

14. DNS and split-horizon performance

DNS resolution latency contributes to first-byte time. Azure private DNS resolution from within a VNet is sub-millisecond; cross-region resolution adds backbone hops; external DNS resolution depends on the resolver path. For sub-second user experiences, ensure:

15. End-to-end performance checklist

A practical pre-launch performance checklist:

Visual Explanations

Figure 1 — Performance decision flow

Figure 2 — End-to-end latency stack

Figure 3 — Quick chooser

Figure 4 — Visualising the latency-tax compounding effect

Each retry, redirect, and chain hop multiplies the user-perceived latency. A flow with 3 HTTP redirects (each adding one round-trip) and 5 database queries (each 20 ms) on a 250 ms RTT path totals: $$3 \times 250 + 5 \times 20 = 750 + 100 = 850$$ ms before any actual processing. The exam tests recognising that retries and chained calls are far more expensive than people intuit.

Figure 5 — Backbone topology

Microsoft's global backbone connects every Azure region. Front Door traffic and Global VNet Peering both ride on this backbone, which is engineered for lower latency and higher reliability than the public internet. A common rule of thumb: trans-Atlantic latency on Microsoft backbone is roughly $65{-}80$ ms (London $\leftrightarrow$ New York), while typical internet equivalents are $100{-}150$ ms with higher variance.

Figure 6 — When not to optimise

Premature optimisation costs design effort and operational complexity. Some workloads genuinely don't need every lever pulled:

The right level of optimisation matches the workload's user-experience requirement and budget. Don't waste a Premium Front Door on an internal tool with five users.

Common Mistakes

❌ Myth: "Scaling up the VM SKU fixes latency." ✅ Reality: Latency problems are usually network problems, not compute. Trace the path; tune AN, PPG, edge first.

❌ Myth: "Accelerated Networking is on by default." ✅ Reality: AN is supported by default for most SKUs, but enableAcceleratedNetworking: true must be set explicitly on the NIC. Bicep templates often miss it.

❌ Myth: "Azure Front Door Standard is the right answer for new edge caching." ✅ Reality: Azure Front Door Standard profiles are retired / retiring. New workloads use Front Door.

❌ Myth: "PPG and AZ work together transparently." ✅ Reality: PPG keeps things together; AZ spreads things apart. They are partially exclusive — pick the dominant requirement (proximity for latency vs spread for HA) or use a zonal PPG compromise.

Practice Exercises

🟢 Exercise 1. A site has 300 ms TLS handshake from Asian clients to a West Europe origin. Recommend.

▶✅ Solution

Front Door. AnyCast terminates TLS at the Asian POP; backbone carries requests onward.

🟡 Exercise 2. A VM throughputs 3 Gbps when the SKU supports 10 Gbps. Diagnose.

▶✅ Solution

Check Accelerated Networking. Enable on the NIC.

🟡 Exercise 3. An HPC simulation runs 5\\times$$ slower than on bare-metal on-prem. Recommend.

▶✅ Solution

Use HPC VM SKUs (HB / HC) with InfiniBand, placed in a Proximity Placement Group. Enable RDMA for MPI.

🔴 Exercise 4. An ExpressRoute gateway saturates at 10 Gbps but the workload needs 25 Gbps. Recommend.

▶✅ Solution

Enable FastPath. Requires Premium / Ultra performance SKU + Direct port. Packets bypass the gateway data path; throughput limited only by backend capacity.

🔴 Exercise 5. Two VNets in different regions communicate via VPN-over-internet. Latency is \\sim 200$$ ms. Recommend.

▶✅ Solution

Global VNet Peering. Direct VNet-to-VNet over Microsoft backbone; latency drops to backbone-only.

🟢 Exercise 6. True or false: Front Door includes WAF and DDoS protection at no extra charge in Premium tier.

▶✅ Solution

True. Front Door Premium includes WAF, bot management, and enhanced DDoS protection.

🟡 Exercise 7. Sketch Bicep enabling AN on a NIC.

▶✅ Solution

bicepCopy

resource nic 'Microsoft.Network/networkInterfaces@2024-03-01' = { name: 'nic-app' location: location properties: { enableAcceleratedNetworking: true ipConfigurations: [ { name: 'ipcfg', properties: { subnet: { id: subnetId } } } ] } }

Figure 7 — Diagnostics workflow for a latency complaint

When a customer reports "the app is slow", run this workflow:

Latency complaints have layered causes. The first job is to identify which layer; the second is to apply the right fix for that layer. Front Door fixes client-side TLS handshake latency but does nothing for slow database queries. Accelerated Networking fixes VM packet processing but does nothing for cross-region call chains. The architect's discipline is to diagnose before prescribing.

Summary & Concept Map

• Diagnose latency layer-by-layer. Client-to-edge, edge-to-origin, in-VNet, in-VM packet processing — different layers, different fixes.
• Front Door AnyCast brings the edge close to clients. $30{-}60\%$ latency reductions typical.
• Accelerated Networking is the cheapest VM-level win. Enable everywhere supported.
• Proximity Placement Groups for HPC / SAP HANA scale-out.
• ExpressRoute FastPath bypasses the gateway for $> 10$ Gbps hybrid workloads.
• Global VNet Peering for cross-region private connectivity at backbone latency.