Quick Note — Recommend a Solution to Optimize Network Performance
AZ-305 › Unit 4: Design infrastructure solutions › Design network solutions › Recommend a solution to optimize network performance
Quick Note — Recommend a Solution to Optimize Network Performance
A global e-commerce platform with users on five continents finds its 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 ms of round-trip latency to every single request.…
Retrieval target
- Recommend a Solution to Optimize Network Performance
- Closed-book recall
- 5 minutes
- Open the full lesson after a miss
Decision anchors
| Prompt | Compact answer |
|---|---|
Accelerated Networking | SR-IOV on the VM's NIC — bypasses the hypervisor's software switch so packets go from the physical NIC straight to the VM. Result: higher throughput, lower latency, lower CPU overhead. Available on most D / E / F / M / N sizes with vCores. Off by default on legacy images; turn on at NIC create time. Always enable for any latency-sensitive or high-throughput workload. |
VNet Peering — Regional vs Global | Regional peering — two VNets in the same Azure region connected via the Microsoft backbone. Throughput limited only by VM NIC; sub-ms latency. Global peering — VNets in different regions. Same backbone path but higher latency (geographic distance) and no transit through a remote VNet's NVA / VPN GW. Costs slightly more per GB. Both are non-transitive: A↔B + B↔C does NOT give A↔C. |
Private Link / Private Endpoint | A NIC inside your VNet that gives you a private IP for an Azure PaaS service (Storage, SQL DB, Key Vault, App Service, etc.). Traffic stays on the Microsoft backbone — no public endpoint, no SNAT, no internet egress. Lowest-latency path to PaaS from inside Azure. Solves both perf (avoid public path) and security (no public exposure). |
Proximity Placement Group (PPG) for network | A logical pin that keeps selected VMs physically close (same data-center row / building) for minimum inter-VM latency. Pair with Availability Zones / Sets to maintain HA. Use for chatty multi-tier apps where every microsecond matters — HPC, SAP HANA scale-out, latency-critical financial systems. Trade-off: less placement flexibility — Azure may not be able to fulfil the PPG in a full zone. |
Read the answers once, then cover the right-hand column and reconstruct each one from the prompt. A useful answer names the requirement, the recommended control or service boundary, and the nearest alternative it rejects. If you can only recognize the answer after seeing it, retrieval is not yet secure.
Ninety-second explanation
Without notes, explain:
- What requirement signals this learning objective rather than a neighbouring one?
- Which two solution families are most likely to be compared?
- Which hard constraint eliminates the strongest distractor?
- What identity, network, data, or failure boundary must appear in the design?
- Which operational test would prove the recommendation works?
Then compare your explanation with the full lesson. Record the missing decision rule—not merely the missed product name—in your error log.
When to open the full lesson
Open the curriculum-linked lesson when you cannot explain a comparison, when a scenario depends on a numeric limit or SKU feature, or when the service is on a retirement path. Use current Microsoft Learn documentation for availability, limits, pricing, naming, and migration milestones; the quick note is intentionally compact.
Source and freshness
Derived from the linked AZ-305 lesson and retrieval deck, grounded in both attached course sources. Reviewed 2026-08-02. Current Microsoft documentation controls changing product contracts.