Packet Loss

Packet loss occurs when packets transmitted by a source do not arrive at their intended destination. Causes include congestion, exhausted buffers, physical link errors, interface limits, routing failures, and intentional drops by security controls. Loss can be intermittent, sustained, or concentrated in short bursts. Its impact depends on the application: TCP normally retransmits missing data but may reduce its sending rate, while UDP applications must tolerate missing data or implement their own recovery.

A basic loss percentage is the number of missing packets divided by the number transmitted, multiplied by 100. Measurements must use matching traffic populations and account for packets still in transit, duplicates, and the observation window. For example, if 1,000 uniquely identified probes are sent and 990 arrive within the defined measurement period, measured loss is 1%. Request-and-response probes measure round-trip success, so missing responses alone do not identify whether the forward path, return path, or destination caused the failure.

In cloud and hybrid networks, monitoring should cover representative paths between workloads, Availability Zones, Regions, and on-premises locations. Collect packet-loss measurements alongside round-trip latency, jitter, throughput, interface utilization, errors, discards, and TCP retransmissions. Preserve source, destination, protocol, packet size, and timestamps so that incidents can be correlated with routing changes, deployments, or traffic spikes. Establish application-specific thresholds and retain sufficiently granular data to expose bursts that long averaging periods can hide.

Use active probes to test delivery and passive telemetry to investigate causes. Tools such as ping and mtr can reveal symptoms, but ICMP filtering or response rate limiting can make a healthy application path appear lossy. A router that fails to answer diagnostic probes may still forward transit traffic normally. Apparent loss at an intermediate hop is not proof of forwarding loss, especially when later hops and the destination respond reliably. Validate findings with application-relevant TCP or UDP tests and, where possible, measurements in both directions.

AWS telemetry provides complementary evidence rather than one universal packet-loss metric. Amazon CloudWatch Network Monitor supports active monitoring between AWS-hosted subnets and on-premises destinations. VPC Flow Logs show traffic metadata and ACCEPT or REJECT decisions, but they are not packet captures and cannot establish an end-to-end loss percentage. An ACCEPT record does not guarantee destination delivery. AWS Transit Gateway exposes counters for packets dropped because of missing routes or blackhole routes. On supported EC2 instances, ENA allowance-exceeded counters help identify instance-level bandwidth or packet-rate constraints.

For example, when a hybrid application's throughput falls during backups, compare active loss measurements with AWS Direct Connect utilization, on-premises interface discards, and host retransmissions. If a link or instance allowance is saturated, increasing capacity or shaping competing traffic may help. If only larger packets fail, investigate path MTU and blocked ICMP messages required for path MTU discovery rather than assuming congestion. Configuration analysis can identify routing or security-policy problems, but it does not measure live packet delivery.

Monitoring itself has trade-offs. More frequent probes improve detection but add traffic and cost; packet capture provides detail but introduces storage, privacy, and processing requirements. Retries can conceal loss from users while increasing latency and load. Define alarms around sustained degradation and application impact, while retaining short-window measurements for burst analysis. Do not assume that a healthy link state, an established VPN tunnel, or low average utilization proves that packets are being delivered successfully.