Context
An EC2 server can drop packets while its average network graph looks comfortably below the advertised bandwidth. Small-packet bursts, tracked-connection pressure, and short bandwidth peaks are different limits. ENA allowance counters help identify which boundary the workload crossed, provided they are measured over the incident interval.
Treat allowance counters as interval evidence
ENA exposes counters for conditions such as inbound bandwidth, outbound bandwidth, packets per second, and tracked connections exceeding supported allowances. Depending on the counter, excess traffic may be queued or dropped. Check the current AWS definition and supported driver version for each metric.
Counters are cumulative since a relevant reset. Capture their change over a known interval instead of alerting forever because a historical value is nonzero. Record instance identity, interface, driver version, boot time, and collection gaps so counter resets are not mistaken for an improvement.
Find the real interface and driver
List network interfaces and identify the one carrying the affected traffic. Interface names differ between images and operating systems; a runbook hardcoded to eth0 can collect the wrong evidence. On Linux, ethtool -i and supported ethtool -S statistics provide useful driver and counter information.
Publishing these counters to CloudWatch requires the corresponding collection configuration; they are not interchangeable with ordinary aggregate EC2 byte metrics. Verify collection is actually working before interpreting an absent time series as zero allowance pressure.
Distinguish bytes, packets, and connections
Large transfers consume bandwidth. Many tiny messages can consume a packet-per-second allowance while transferring relatively few bytes. Large populations of concurrent or rapidly created connections can stress tracking capacity even when each connection carries little data.
Compare allowance deltas with request rate, connection creation, active connection count, payload size, retransmissions, and application latency. A server's local Linux conntrack table and EC2's tracked-connection allowance are separate observation points. Evidence from one does not automatically establish exhaustion of the other.
Inspect local-proxy-service traffic where relevant. Resolver or metadata request patterns can produce a different allowance problem from the public API's bandwidth. Cache appropriate results and reuse connections without weakening identity or freshness requirements.
An illustrative small-message incident
A telemetry gateway handles a sudden increase in very small events. Its one-minute byte graph remains low, so the first response is to add application threads. Packet-rate allowance counters rise, retransmissions increase, and the additional threads generate even more concurrent network work.
The team measures packets per accepted event, tests bounded batching, and compares a suitable instance type. The successful design reduces overhead while preserving delivery semantics. It verifies the actual event acknowledgment path rather than accepting a high sender throughput number that includes lost messages.
Quick diagnostic map
| Counter or symptom | Boundary to test | Next check |
|---|---|---|
pps_allowance_exceeded increases | Packet-rate pressure | Packet size and burst rate |
| Bandwidth allowance counters rise | Byte-rate ceiling | Short-interval ingress and egress |
| Connection allowance exceeded rises | Tracking pressure | Connection reuse and concurrency |
| No ENA series appears | Collection or support gap | Driver and agent configuration |
A focused operator exercise
Use a bounded traffic generator in a test environment. Compare a large-payload transfer with a small-message workload at similar byte throughput. Capture ENA counter deltas, packets per second, request latency, and accepted work for each run.
Test a connection-reuse change independently of an instance resize. Keep request semantics and failure accounting identical. If the application retries, report original requests and retry attempts separately so increased network work is not mistaken for useful throughput. Stop when the agreed load or error boundary is reached.
Choose a correction that fits the allowance
Potential corrections include a better-suited instance type, connection pooling, bounded concurrency, batching, reduced polling, or distributing traffic across independently provisioned capacity. Each has application and availability implications. Confirm the selected type's documented network characteristics rather than assuming more vCPUs always resolve every allowance.
After rollout, observe peak intervals and normal idle periods. Verify both counter behavior and customer outcomes. A driver reset that clears counters without changing the workload is not evidence that the bottleneck was removed.
Frequently asked questions
Is a nonzero allowance counter proof of the current incident?
Only an increase during the relevant interval supports that conclusion. Correlate it with traffic and application impact.
Will a packet capture always provide the best evidence?
A capture can help, but it adds overhead and may expose payloads. Start with bounded counters and use narrowly scoped captures when they answer a specific unresolved question.
Continue the investigation
- Linux conntrack pressure: investigate new connections that fail
- Small requests work but transfers stall: investigate path MTU
Browse the cloud, server and infrastructure guide library for related operational questions.
Explore Clouvenix Server & Website Performance Troubleshooting to discuss implementation, validation and operational handover.
Technical reference
Monitor network performance for ENA settings on your EC2 ...