A network benchmark answers a specific question about a specific path and workload. There is no single “AWS network speed”: observed throughput depends on the EC2 instance, traffic direction and flow count, protocol, packet size, route, and the test hosts themselves. Measure the path your application uses, record the conditions, and compare like with like. For a broader before-and-after method, see how to benchmark AWS performance after a migration.

Choose the right performance signals

Start by defining what the application needs and how you will measure it. These signals answer different questions:

  • Throughput is the rate of useful data delivered over a period. A synthetic tool such as iperf3 measures traffic between its client and server; it does not measure application work such as database queries or request processing.
  • Latency is the time for a response. Ping reports ICMP round-trip time when the path permits ICMP. Application request latency should come from the application’s own metrics or tracing. Do not interpret an EC2 traffic counter as a latency measurement.
  • Jitter describes variation in packet delay and is especially relevant to real-time UDP workloads.
  • Packet loss is data that does not reach the receiver. UDP test results can report lost datagrams and jitter. TCP retransmissions are a useful signal, but they are not a direct packet-loss percentage.

EC2 sends basic CloudWatch network metrics such as NetworkIn, NetworkOut, NetworkPacketsIn, and NetworkPacketsOut. They show byte and packet volume for an instance, not the latency or loss of a particular flow. Basic data points generally cover five-minute periods; detailed monitoring provides one-minute periods for supported metrics. Brief bursts can be hidden by aggregated periods, so use test output and finer-grained host or application telemetry for short tests. See EC2 metrics available in CloudWatch.

For instance-level network allowances, inspect the counters published by the ENA driver. Counters such as bw_in_allowance_exceeded, bw_out_allowance_exceeded, and pps_allowance_exceeded count packets queued or dropped after an instance exceeds a defined allowance. The driver exposes these metrics locally; sending them to CloudWatch requires the CloudWatch agent and configuration, and CloudWatch bills imported values as custom metrics. Review the collection requirements and charges before enabling them.

VPC Flow Logs record metadata about IP traffic, including whether traffic was accepted or rejected. They help investigate traffic patterns and access decisions, but do not capture packet contents or provide per-packet latency measurements.

Understand instance and path limits

Use the current network specification for the exact EC2 instance type and size. Some instance types have a stated baseline and can use network I/O credits to burst above it for a limited time. Burst availability is best effort and can end when credits are depleted; a short peak is not evidence of sustained capacity. AWS documents these behaviors in its guide to EC2 instance network bandwidth.

An instance’s aggregate bandwidth is only one limit. Packet-per-second, tracked-connection, and link-local service allowances also apply. Separately, a single TCP or UDP flow may have a lower ceiling than the instance’s aggregate bandwidth, and traffic through an internet gateway, local gateway, or other network service can have path-specific limits. A test with one stream and a test with several streams therefore measure different cases. Check the instance and route documentation instead of assuming the advertised maximum applies to every flow.

Do not confuse account or service quotas with forwarding performance. Quotas limit resources or operations, while bandwidth, packets-per-second, connection-tracking, and per-flow limits constrain a particular instance or path. If a test stalls below the expected rate, look at both endpoints’ CPU and ENA allowance counters, the flow count, and the route before changing TCP settings. For Transit Gateway paths, the Transit Gateway capacity and limits guide covers the service-specific constraints.

Treat ENA and MTU as separate settings

Enhanced networking is an EC2 instance capability provided through a supported network adapter and guest driver. Current Nitro-based instances use the Elastic Network Adapter (ENA); older instance generations can use a different virtual-function interface. ENA is not a VPC toggle, and changing MTU does not enable ENA. Confirm that the selected instance supports the adapter and that the operating system has a compatible driver before comparing results. See AWS’s guide to enhanced networking on EC2.

MTU is the largest packet a network path can carry. EC2 instances support a 1500-byte MTU; current-generation types also support 9001-byte jumbo frames. The path may impose a smaller limit: AWS documents 1500-byte limits for traffic over an internet gateway or VPN and for many inter-Region paths, while inter-Region VPC peering has an 8500-byte limit. Transit Gateway and Direct Connect have their own path requirements. A 9001 MTU is therefore not a universal optimization. Check the full route and Path MTU Discovery behavior before changing it, using the EC2 MTU guidance.

Prepare a controlled test

  1. Choose the path. Use two hosts and the same route as the workload you want to understand. Record whether the path crosses subnets, Availability Zones, Regions, a Transit Gateway, VPN, Direct Connect, or an internet gateway. A VPC configuration review can help you confirm the subnet routes and security controls.
  2. Record the conditions. Capture instance types and sizes, operating systems, ENA driver versions, CPU use, MTU and address family, test direction, protocol, flow count, packet size, test duration, and background traffic. Keep the conditions the same when comparing runs.
  3. Allow only the test traffic. The iperf3 server listens on TCP port 5201 by default. Add a temporary inbound rule to the server’s security group for that port from the test client’s security group or private IP address. A UDP run also needs UDP access on the selected iperf3 port from that same peer. Keep the test on private addresses where possible, account for any restricted outbound rules, and stop the iperf3 server and remove the temporary rule when finished. AWS security groups let you scope a rule to a particular source; do not expose the test port to the whole internet.
  4. Keep the test isolated. Use hosts whose CPU, memory, and application workload will not distort the result. Run outside a busy production period or use a dedicated test environment. Benchmark traffic is real traffic and can affect the path or incur data-transfer charges.

For multi-VPC or cross-Region tests, note that the relevant attachment, routing, MTU, and transfer behavior may differ from an intra-VPC test. AWS Network Manager can help inventory a Transit Gateway topology; its map is not a throughput benchmark. See how to visualize Transit Gateway networks.

Run repeatable throughput tests

Install iperf3 on both test hosts using the packages supported by their operating systems, and record the version with iperf3 --version. Start the server on one host and run the client on the other. Replace <server-private-ip> below with the server’s actual private IP address before running a command. A basic TCP pass might look like this:

# On the test server
iperf3 -s

# On the test client; use the server's private IP address
iperf3 -c <server-private-ip> -t 30 -P 1

# Repeat in the reverse direction as a separate case
iperf3 -c <server-private-ip> -t 30 -P 1 -R

This is an example, not a target duration or a performance promise. The client sends data to the server by default. Run a reverse-direction pass separately when that matches your use case. Begin with one stream, then increase the stream count only if the workload or question needs it. Multiple streams can raise throughput when a single stream or host CPU is the bottleneck, but they also create a different workload. Consult the iperf3 command reference for the options supported by your installed version.

For UDP, set an intentional offered bitrate and increase it in controlled steps. Compare the sender’s offered rate with what the receiver reports, including jitter and datagram loss. Avoid an unbounded or unnecessarily high-rate test: it can overwhelm the receiver or compete with other traffic. Repeat each case, keep the raw results, and report the range or distribution rather than selecting the best run.

Measure latency and diagnose bottlenecks

Use a low-rate ping only as a basic round-trip check, and only when ICMP is allowed on the path. Ping does not measure an application transaction, and its behavior can differ from TCP or UDP traffic. For user-facing latency, instrument the request at the application boundary and compare percentiles under a representative workload.

When throughput or latency changes, compare both endpoints’ CPU and network counters, then check security-group and network ACL rules, subnet and Transit Gateway routes, and any intermediate appliances. Use Flow Logs to investigate accepted or rejected IP flows. Use ENA allowance counters to see whether the instance is queuing or dropping packets because of its own limits. If the test changes when you adjust MTU, verify the path MTU rather than assuming the larger frame caused the improvement.

Turn results into a useful baseline

Keep a short record for every benchmark: the question, path, endpoint types, conditions, command and tool version, raw output, CloudWatch time range, ENA counters before and after, and any costs or operational constraints. Compare repeated runs under the same conditions, then change one variable at a time. Tie a result to the tested path and workload; do not present it as a universal AWS network limit or a comparative result that was not measured.

If a test points to an undersized compute instance, use representative workload evidence before resizing. The EC2 right-sizing guide explains how to compare candidates against measured demand.

Frequently asked questions

Does the instance network speed equal my throughput?

No. Instance bandwidth is a ceiling that applies under documented conditions. Baseline and burst behavior, packet or connection allowances, a single-flow cap, the route, protocol, endpoint CPU, and competing traffic can all change the rate you observe.

Does CloudWatch show EC2 network latency?

EC2’s built-in network metrics show bytes and packets, not packet round-trip time or application request latency. Use application telemetry for request latency, and a suitable active test for the path-level question you need to answer. ENA allowance metrics help identify specific instance-level queues and drops.

Should I set every instance to MTU 9001?

No. Jumbo frames can help on supported paths, but the path’s smallest MTU governs. Internet, VPN, inter-Region, Transit Gateway, and Direct Connect paths have different requirements. Verify the full path and Path MTU Discovery before changing a production interface.