Traffic Shaping

Traffic shaping controls when packets leave a network interface or queue. Instead of transmitting every packet immediately, a shaper buffers packets and releases them according to a configured rate and burst allowance. This makes traffic more predictable when a fast sender feeds a slower connection, such as a cloud workload transferring backups across a constrained hybrid link.

A common implementation uses a token bucket. Tokens accumulate at a configured rate, and transmitting packets consumes tokens. The bucket capacity determines how much traffic can burst above the sustained rate. When insufficient tokens are available, a shaper delays packets until transmission is permitted. Buffers are finite, however, so sustained overload can eventually cause drops. A large burst allowance can overwhelm a downstream bottleneck, while an unnecessarily small allowance can impair throughput.

In cloud environments, engineers can implement shaping in operating systems, virtual routers, or network appliances they control. For example, Linux traffic control on an Amazon EC2 instance can limit backup traffic before it enters a shared network path. Classification and scheduling can give interactive traffic preferential access while keeping bulk transfers within a defined budget. These controls apply only where configured; they do not create an end-to-end bandwidth guarantee across a provider network.

Consider a cloud sender using a 1 Gbit/s hybrid connection that also carries business applications. An engineer might initially cap backup traffic at 700 Mbit/s, then validate whether the remaining capacity is sufficient for application bursts and protocol overhead. The correct setting depends on the actual bottleneck, other senders, packet sizes, and the units used by the shaping implementation. Increasing the queue size may reduce immediate drops but can also create bufferbloat, where interactive requests wait behind bulk traffic.

Troubleshooting requires packet-level evidence alongside counters and application measurements. Capture traffic before and after the suspected shaping point when possible, using synchronized clocks for comparisons across hosts. Examine packet spacing, short-interval throughput, round-trip time, retransmissions, duplicate acknowledgments, and advertised TCP receive windows. A stable departure rate with increasing delay can indicate queueing, whereas repeated loss near a rate boundary can suggest policing or buffer exhaustion. Neither pattern alone proves the cause; receiver limitations, congestion control, and CPU saturation can produce similar symptoms.

Amazon VPC Traffic Mirroring can copy traffic from supported network interfaces to a packet-analysis appliance. It supports investigation but does not shape production traffic. Its observation point matters: a mirrored capture does not necessarily show what happened at a downstream queue. Mirror-path congestion, capture-system overload, filtering, and packet truncation can also limit the evidence. A packet missing from a mirrored capture is not, by itself, proof that the production path dropped it.

Distinguish shaping from policing: shaping normally delays excess traffic, while policing typically drops or remarks traffic that exceeds a policy. Also distinguish both from routing, load balancing, and firewall filtering. Aggregate flow records can identify large conversations, but they cannot reveal individual packet timing or TCP sequence behavior. Correlate packet captures with queue statistics, interface counters, instance bandwidth limits, and application latency before changing a shaping policy.