Network Performance Metrics and Troubleshooting is the skill that turns a pile of confusing numbers into a clear diagnosis of what is wrong with a network and exactly where the fault lives. For an ANS-C01 exam candidate, mastering these metrics is the difference between guessing blindly at a connectivity problem and systematically isolating the root cause in minutes because every AWS network service—from a simple VPC to a global Direct Connect link—generates standardised performance data that you must interpret correctly under exam pressure.
Jump to a section
A simple way to picture Network Performance Metrics and Troubleshooting
An air traffic controller at a major airport, working the final approach radar during a thunderstorm. Their job is not just to watch planes land—it is to detect the exact moment a flight deviates from its glide path, to measure how many seconds late it is, and to immediately diagnose whether the delay comes from wind shear, a slow aircraft ahead, or a runway closure. They monitor three critical metrics: spacing between planes (latency), the rate of arrivals per hour (throughput), and whether any aircraft has stopped transmitting its location (packet loss). When a flight drops off the radar for two sweeps, the controller does not reboot the aircraft; they examine the communications link, check for interference, and sequence a reroute around the storm cell. This maps precisely to network performance metrics: latency is the delay a data packet experiences crossing the network, measured in milliseconds. Throughput is the volume of data successfully transferred per second, like the number of cleared landings per hour. Packet loss is the percentage of data packets that never reach their destination—the equivalent of a transponder signal that simply vanishes. The controller’s troubleshooting process matches a network engineer’s: baseline normal performance, spot the anomaly, isolate the faulty segment, and apply a fix without disrupting the rest of the traffic.
Real air traffic controllers use something called the “sterile cockpit” rule during critical phases. Likewise, network engineers use common metrics like jitter (the variation in latency over time), retransmission rate, and utilisation percentage to separate genuine failures from transient blips. A single late arrival is a blip; a dozen late arrivals in ten minutes is a pattern that demands immediate investigation. The controller does not guess—they read the instruments and act on what the numbers reveal.
Network performance metrics are the numerical measurements that tell you how well your network is actually working. Think of them as the vital signs a doctor takes: pulse, blood pressure, temperature. Without these readings, you are operating blind and every diagnosis is a guess. The four essential vital signs of a network are latency, throughput, packet loss, and jitter. Each one reveals a different kind of problem.
Latency is the time it takes for a single data packet to travel from source to destination, measured in milliseconds (ms). One millisecond is a thousandth of a second. Low latency means a responsive network; high latency means sluggishness. When you click a link and the page hangs before loading, you are experiencing latency. It is caused by the physical distance the signal must travel (propagation delay), the time routers take to process the packet (serialisation delay), and the waiting time inside buffers when the network is congested (queuing delay). A ping tool measures round-trip time (RTT), which is the time for a packet to go to the destination and back—twice the one-way latency.
Throughput is the volume of data that successfully moves from one point to another in a given time period, measured in bits per second (bps), or more commonly in megabits per second (Mbps) or gigabits per second (Gbps). If latency is how fast one car travels, throughput is how many cars pass a checkpoint per hour. High throughput is good, but it is limited by the narrowest link in the path—that is called the bottleneck. AWS uses EC2 instance types that have different network performance characteristics; a t2.micro has much lower throughput than a c5n.18xlarge. Throughput is not the same as bandwidth. Bandwidth is the maximum theoretical capacity of a link (like the speed limit on a road), while throughput is the actual traffic moving (the cars that are actually driving). You can have 10 Gbps of bandwidth but only achieve 2 Gbps of throughput because of latency or packet loss.
Packet loss is the percentage of data packets that are sent but never arrive at the destination. Even 1% packet loss can cause severe problems for real-time applications like voice or video. Packets get lost when a router’s buffer is too full and it has no choice but to drop new arrivals (tail-drop), or when a link is physically damaged, or when a firewall blocks the traffic. TCP, the transmission control protocol that carries most web traffic, treats any packet loss as a signal of congestion and immediately slows down its sending rate—this is called congestion avoidance. The result is a dramatic drop in throughput, often far worse than the small percentage of lost packets would suggest. A good network should have zero per cent packet loss, or at least less than 0.1%.
Jitter is the variation in latency over time. Imagine your latency measurements are 20 ms, 25 ms, 20 ms, 100 ms, 22 ms. The spike to 100 ms is a jitter event. Consistent high latency is frustrating; jitter is worse because it breaks real-time applications. VoIP phone calls become garbled, video conferences freeze, and online gaming shows rubber-banding. Jitter is caused by variable queuing delays in routers, which happen when traffic is bursty and unpredictable. The standard jitter target for good voice quality is under 30 ms.
All four metrics interact. High latency increases jitter because of variable queue lengths. Packet loss causes TCP to reduce throughput drastically. Low throughput can hide jitter because the queues never fill enough to vary. Troubleshooting means identifying which metric is out of normal range, correlating it with the others, and isolating the cause.
How do you measure these metrics on AWS? Amazon VPC Flow Logs capture metadata about every packet entering or leaving a network interface—source/destination IP, port, protocol, packet count, byte count, and whether the action was accepted or rejected. CloudWatch metrics provide latency and throughput for Elastic Load Balancers (ELBs) and NAT Gateways. The AWS Reachability Analyzer can tell you if a path exists between two resources and, if not, which component is blocking it. For on-premises connections, you use tools like iperf for throughput testing, MTR (My TraceRoute) to see latency and packet loss hop-by-hop, and tcpdump or Wireshark to capture the actual packets.
The key principle is baseline comparison. You cannot know something is wrong unless you know what “normal” looks like. Set up CloudWatch alarms on threshold values: latency above 50 ms to an internal load balancer, packet loss above 0.5%, jitter above 30 ms. When the alarm triggers, you gather the metrics, look for correlated events (a new EC2 instance launch, a change in a Security Group rule, a spike in traffic), and then use Reachability Analyzer to confirm the path.
Establish baseline metrics
Before any problem occurs, measure and record normal values for latency, throughput, packet loss, and jitter during peak and off-peak hours. CloudWatch can store these as statistics over weeks. Without a baseline, you cannot distinguish an anomaly from normal fluctuation.
Detect and alert on metric drift
Set CloudWatch alarms on the metrics with thresholds based on your baseline. For example, alarm if average latency exceeds 150% of baseline for 3 consecutive data points. The alarm triggers an SNS notification, bringing your attention to a possible issue.
Gather all metrics for the affected path
When an alarm fires, do not jump to conclusions. Collect data from all relevant sources: VPC Flow Logs for the affected interfaces, CloudWatch metrics for any load balancers or NAT gateways in the path, and if applicable, Direct Connect or VPN metrics from AWS CloudWatch or on-premises tools like MTR.
Isolate the faulty component using Reachability Analyzer
Create a reachability analysis from the source ENI (Elastic Network Interface) to the destination ENI. If the path is broken, the tool returns the specific component (e.g., a Network ACL rule, a misconfigured route table, an internet gateway that is not attached) that is blocking traffic. If the path is complete, the problem is performance, not reachability.
Perform a hop-by-hop diagnostic with MTR or traceroute
Run MTR from the source to the destination. Look for intermediate hops that show high latency or packet loss. A single hop with 10% loss is the likely bottleneck. This step confirms where in the path the performance degradation is occurring.
Apply a targeted remedy and verify
Based on the isolated component and the metric values, apply a fix: increase instance size if throughput is capped by EC2 performance, adjust Security Group rules if reachability is blocked, add a second Direct Connect link if latency is due to circuit saturation, or enable connection draining on a load balancer if surge queues are overflowing. Then re-run the metrics to confirm they return to baseline.
Sarah is a network engineer at a mid-sized e-commerce company that runs its application on AWS. It is Cyber Monday, and traffic is 10 times the normal load. At 10:00 AM, the monitoring dashboard fires an alarm: the web tier’s Elastic Load Balancer latency has jumped from a baseline of 12 ms to over 400 ms. End users are reporting pages that take 30 seconds to load. Sarah needs to fix this now.
Step one: she opens CloudWatch and pulls up the ALB’s metrics. She sees a graph of RequestCount, Latency, TargetResponseTime, and HTTPCode_ELB_5xx. RequestCount is high—good, that is expected. Latency is spiking, but TargetResponseTime (the time the backend EC2 instances take to respond) is still normal at 10 ms. This tells her the delay is not in the application itself but in the ALB or the network path between the ALB and the clients.
Step two: she checks the ALB’s ActiveConnectionCount and NewConnectionCount. The number of new connections per second is three times normal, which means the ALB is working hard to handle the new traffic. She also checks SurgeQueueLength (connections waiting to be processed) and SpilloverCount (connections rejected because the queue is full). The SurgeQueueLength is 1024—the maximum—and SpilloverCount is climbing. That means the ALB cannot keep up; it is dropping connections.
Step three: she looks at the target group metrics. The EC2 instances behind the ALB show healthy CPU utilisation but high NetworkIn and NetworkOut. They are receiving more traffic than they can comfortably handle, but they are not failing. The bottleneck is neither the application nor the network link; it is the ALB’s capacity itself.
Step four: Sarah applies the fix. She adds two more ALB-scale listener rules to distribute traffic across a broader pool, but more importantly she increases the number of EC2 instances in the Auto Scaling group from 6 to 12, and she enables connection idle timeout reduction from 60 seconds to 20 seconds to free up ALB connections faster. Within 5 minutes, latency drops back to 15 ms, and the SurgeQueueLength empties.
This is exactly how AWS network professionals troubleshoot: gather the metrics, identify which layer is failing (client-to-ALB vs. ALB-to-instance vs. instance-to-database), check the queuing and loss indicators, and apply a targeted capacity or configuration change. They never guess. They follow the numbers.
The ANS-C01 exam tests network performance metrics and troubleshooting in several specific question patterns. The easiest to score if you know the metrics, but tricky if you confuse them.
First, scenario-based questions: they give you a description of a network problem (e.g., “Users in a branch office report choppy voice calls over Direct Connect. Latency is 45 ms, packet loss is 0.1%, jitter is 40 ms. Which metric is causing the issue?”). The correct answer is jitter, because 40 ms exceeds the 30 ms threshold for good voice quality. Latency is moderate, packet loss is low—they deliberately include misleading but normal values to distract you.
Second, definition matching: they ask which metric is measured in bits per second (throughput), which is time variation (jitter), and which causes TCP to reduce its window (packet loss). Memorise these definitions cold. A common trap: they use “bandwidth” when they mean “throughput”. Bandwidth is capacity; throughput is actual data moved. The exam will test the difference explicitly.
Third, troubleshooting tool questions: they ask which AWS service or tool you would use to isolate a specific problem. For example: “Which tool identifies the specific network component that is dropping packets between an EC2 instance and an on-premises server?” Answer: Reachability Analyzer. “Which service provides per-flow metrics for VPC traffic?” Answer: VPC Flow Logs. “Which tool tests maximum achievable throughput between two endpoints?” Answer: iperf (not AWS-native, but they test knowledge of common industry tools).
Fourth, baseline and alarm questions: the exam presents a metric graph over time and asks what threshold should trigger an alarm. They love the concept of “burst versus sustained” loss. A single spike of 2% packet loss for 30 seconds may be acceptable, but sustained 2% for 5 minutes requires action. Look for wording like “which alarm period is most appropriate?” Answer: “average over 5 minutes with a threshold of 1%” is safer than “average over 1 minute” because it avoids false positives.
Fifth, metric interaction questions: they ask what happens to throughput when packet loss increases. The exam expects you to know that TCP’s congestion control algorithm causes throughput to drop much more than the loss percentage alone would suggest. This is because TCP uses a multiplicative decrease: for each packet loss, it halves its sending rate. A 1% packet loss can reduce throughput by 50% or more.
Traps to avoid:
Confusing retransmissions with packet loss. Retransmissions are TCP’s response to loss; they are a side effect, not the root metric.
Thinking higher throughput is always better. The exam may present a scenario where high throughput causes excessive queuing latency, and the correct answer is to throttle bandwidth.
Assuming CloudWatch is the only monitoring tool. AWS also offers VPC Reachability Analyzer, Path Analyzer, Network Access Analyzer, and Traffic Mirroring. Know which one does what.
Forgetting to distinguish between one-way latency and round-trip time. The exam uses both terms; you must understand the difference.
Key concepts to memorise:
Latency = delay (ms)
Throughput = actual data rate (bps)
Packet loss = percentage of packets not delivered
Jitter = variation in latency (ms)
Bandwidth = maximum possible data rate (bps)
MTR = hop-by-hop latency and loss
iperf = throughput testing
Reachability Analyzer = path verification and bottleneck identification
Network performance metrics are latency, throughput, packet loss, and jitter—each measures a different dimension of network health and requires a different troubleshooting response.
Bandwidth is the theoretical maximum data rate of a link; throughput is the actual data rate achieved; a high-bandwidth link can still deliver low throughput due to latency, loss, or congestion.
Packet loss as low as 1% can cut TCP throughput by more than 50% because TCP halves its sending window on every detected loss event.
Jitter is the variation in latency over time and is the primary metric for ensuring the quality of real-time applications like VoIP and video conferencing, with a target under 30 ms.
VPC Flow Logs show metadata about network traffic (source, destination, action) but do not directly measure latency or jitter—use them for security rules, not performance troubleshooting.
A single metric out of range is rarely the answer; effective troubleshooting correlates multiple metrics to identify which layer of the network stack is failing.
Use CloudWatch alarms with sustained thresholds (e.g., average over 5 minutes) to avoid false positives from transient spikes in traffic.
Reachability Analyzer identifies the specific network component blocking a path, while iperf measures achievable throughput between two endpoints.
These come up on the exam all the time. Here's how to tell them apart.
Latency
Measures the total delay for a packet to travel from source to destination, expressed in milliseconds.
A consistent high latency causes uniform slowness in all interactions.
Latency is a single value per measurement (e.g., average RTT of 50 ms).
Jitter
Measures the variability in latency over time, ignoring the absolute delay.
High jitter causes inconsistent performance, breaking real-time applications like VoIP even if average latency is low.
Jitter is calculated as the standard deviation or average difference between consecutive latency samples.
Bandwidth
The maximum theoretical data transfer capacity of a link, e.g., 1 Gbps.
Bandwidth does not change based on traffic conditions; it is a fixed property of the medium.
Bandwidth is a capacity metric, not a performance metric.
Throughput
The actual data successfully transferred per unit time, often much lower than bandwidth.
Throughput varies with latency, packet loss, and congestion; it is the real performance measure.
Throughput is a performance metric that determines how fast an application actually operates.
VPC Flow Logs
Capture flow-level metadata: source, destination, ports, protocol, packets, bytes, action.
Are stored as log files in CloudWatch Logs or S3; not aggregated into time-series graphs by default.
Best for security audits, traffic analysis, and identifying which hosts are communicating.
CloudWatch Metrics
Capture numeric time-series data: averages, sums, percentiles of latency, request counts, error counts.
Are automatically plotted in CloudWatch dashboards and can trigger alarms on thresholds.
Best for real-time performance monitoring and alerting on operational metrics.
Packet Loss
The percentage of sent packets that never reach the destination, measured by the sender.
Caused by buffer overflow, physical errors, or firewall drops.
Packet loss is a direct metric of network reliability.
Retransmissions
The percentage of packets that TCP retransmits after not receiving an acknowledgement in time.
A symptom of packet loss or high latency, not a separate root cause.
Retransmissions are a corrective action taken by TCP, not a primary network performance metric.
Mistake
If the bandwidth of a link is 1 Gbps, I should always be able to achieve 1 Gbps of throughput.
Correct
Throughput is almost always lower than bandwidth due to protocol overhead, latency, packet loss, and congestion. Achieving 940 Mbps on a 1 Gbps Ethernet link is considered excellent; TCP overhead and headers consume the rest.
People treat bandwidth as if it were a guaranteed speed rather than a theoretical maximum. Real-world factors like application layer headers, TCP handshakes, and the sliding window protocol always reduce usable throughput.
Mistake
Latency and response time are the same thing.
Correct
Latency is the network delay for a packet to travel from point A to point B. Response time includes latency plus the server’s processing time to generate a reply and send it back. They are not interchangeable on the exam.
End users experience response time. Network engineers measure latency. Beginners conflate the two because both cause slowness, but isolating which is which is the whole point of troubleshooting.
Mistake
Packet loss always means a physical cable is broken or a device is faulty.
Correct
The most common cause of packet loss on modern networks is buffer overflow—routers and switches drop packets when their memory queues fill up because the incoming traffic rate exceeds the outgoing link speed. It is congestion, not hardware failure.
Newcomers think of loss as a “break” because that metaphor is intuitive. Congestion-based loss is counterintuitive because the device is working perfectly; it is simply overwhelmed.
Mistake
Jitter only matters for voice and video; it does not affect TCP traffic.
Correct
Jitter can increase TCP retransmissions and reduce throughput because TCP uses timers to decide when to retransmit. If the expected ACK arrives late due to jitter, TCP waits too long, then retransmits unnecessarily, wasting bandwidth.
The focus on voice in jitter discussions makes it seem like a niche problem. In reality, any application that relies on timely ACKs (which is every TCP application) is harmed by high jitter.
Mistake
You can accurately measure throughput using the ping command.
Correct
Ping measures latency and loss, not throughput. Ping sends tiny ICMP packets (typically 64 bytes) and measures their round-trip time, but throughput testing requires saturating the link with large data flows, which is what tools like iperf do.
Ping is the first tool everyone learns and it produces simple output. People assume it can measure “speed” because that is what they want to know. It cannot.
Mistake
If VPC Flow Logs show a high number of rejected packets, there is a network performance issue.
Correct
Rejected packets in VPC Flow Logs indicate traffic blocked by a Security Group or Network ACL—a security configuration, not a performance issue. Performance metrics (latency, throughput, loss) are measured on accepted traffic.
Flow Logs show “ACCEPT” or “REJECT” action codes. Beginners misread REJECT as packet loss and waste time troubleshooting the network when the problem is a firewall rule.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Within the same AWS Region, latency between EC2 instances in the same Availability Zone should be under 1 ms. Cross-AZ in the same region is typically under 5 ms. Cross-region (e.g., US East to EU West) can be 60–100 ms. For end users, aim for under 100 ms for good web browsing experience.
It checks whether a source and a destination in your VPC can communicate by simulating the network path. It identifies the specific component that blocks traffic—such as a missing route, a Security Group deny rule, or a Network ACL—so you know exactly where to fix.
Yes, sustained packet loss is always bad, but transient loss of 0.1% or less is often tolerable. Over 1% loss will severely degrade TCP-based applications and make voice unusable. Aim for zero packet loss in production networks.
Launch two EC2 instances in the same VPC and use a tool like iperf3. One runs as a server (iperf3 -s), the other as a client (iperf3 -c <server_IP>). The tool reports bandwidth and throughput in real time. For a more AWS-native approach, enable VPC Flow Logs and compute throughput from the byte counters and time intervals.
VPC Flow Logs capture metadata about every network flow (source, destination, ports, protocol, packet count, bytes, action). They are logs, not metrics. CloudWatch metrics are numeric time-series data (like latency, request count, CPU utilisation) that are aggregated and graphed over time. Flow Logs tell you what traffic flowed; CloudWatch metrics tell you the performance of that traffic.
TCP throughput is limited by the TCP window size and the round-trip time. The formula is throughput = window size / RTT. If your RTT is 100 ms and your TCP receive window is 64 KB, your max throughput is about 5 Mbps regardless of the 1 Gbps link bandwidth. To increase throughput, either enlarge the window or reduce latency.
Yes, there is a cost per analysis path created per hour. AWS charges a small fee per minute of analysis. For production troubleshooting, the cost is negligible. Use it anyway—it is the fastest way to isolate connectivity issues.
You've finished Network Performance Metrics and Troubleshooting. Continue through the ANS-C01 study guide to build a complete picture of the exam.
Done with this chapter?