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 CDN Standard from Microsoft (classic) (retiring 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 most general-purpose and compute-optimised sizes 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 an ExpressRoute virtual network gateway of SKU Ultra Performance, ErGw3AZ, or ErGwScale with at least 10 scale units — it works over both ExpressRoute Direct and provider circuits, so no Direct port is required. 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 general-purpose and compute-optimised VM sizes at $\\ge 2$ vCPU (4 or more on hyperthreaded sizes). Support is listed per size, not per family — newer burstable sizes such as Bsv2 list Accelerated Networking as supported, and among the older B-series only the largest sizes do (B12ms, B16ms, B20ms). Check the size page before assuming.

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. Azure CDN (classic) — retiring, prefer Front Door

Azure CDN Standard from Microsoft (classic) and Azure Front Door (classic) profiles are retiring — Front Door (classic) on March 31, 2027 and CDN Standard from Microsoft (classic) on September 30, 2027; neither has accepted new profiles since August 15, 2025. Azure Front Door Standard is a current GA tier and the migration target, not a retiring one. 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, and the MTU is a configurable setting. Raising it can improve throughput inside a virtual network, but Microsoft advises against increasing the Azure VM MTU when traffic also leaves the VNet: a path whose MTU differs causes fragmentation and can cost more performance than the larger frames win. The exam tests recognising this trade-off: workloads coming from on-prem jumbo-frame environments should not assume jumbo frames survive end to end, and normally stay on the Azure default.

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 CDN Standard from Microsoft (classic) is the right answer for new edge caching." ✅ Reality: The classic profiles are retiring; Front Door Standard and Premium are the current GA tiers and the documented migration target. New edge-caching workloads use Front Door Standard or Premium.

❌ 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 an ExpressRoute gateway of SKU Ultra Performance, ErGw3AZ, or ErGwScale (10+ scale units); an ExpressRoute Direct port is not required, because FastPath also works on provider circuits. 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.