AWS VPC Traffic Mirroring: Packet Capture, Filters, and VXLAN

AWS VPC Traffic Mirroring copies selected packets from an elastic network interface (ENI) to a monitoring appliance. It is useful for threat detection, packet-level troubleshooting, and traffic analysis when flow records do not provide enough detail. The copy is sent out of band, so it does not replace the original packet path, but it still consumes source capacity and can be dropped during congestion.

The useful mental model is a four-part relationship:

Source: the ENI whose inbound and outbound traffic can be inspected.
Filter: separate inbound and outbound rules that decide which packets are accepted or rejected for mirroring.
Target: the ENI, Network Load Balancer, or Gateway Load Balancer endpoint that receives the copy.
Session: the resource that connects one source, filter, and target and gives the session a priority number.

Use a narrow filter and a private, least-exposed target. Start with a short capture window, confirm the expected traffic, and remove the session when the investigation ends.

What Traffic Mirroring is good for

Security monitoring: send selected traffic to an intrusion detection, network detection, or packet inspection appliance.
Network troubleshooting: inspect packets when routing, security rules, or application logs do not explain a failure.
Traffic analysis: study protocols, ports, retransmissions, and connection behavior with a packet decoder.

Traffic Mirroring is a packet copy mechanism. It does not decrypt TLS, application-layer encryption, or IPsec for the collector. If the application payload is encrypted, the target receives the encrypted bytes unless the inspection design separately provides the keys and an appropriate decryption point. Treat captures as sensitive data and limit access to the appliance and its storage.

AWS VPC Traffic Mirroring basics

How the copy is made

Traffic Mirroring copies inbound and outbound traffic from an ENI of type interface. AWS applies the mirror filter, encapsulates accepted packets in VXLAN, and routes the copy to the target. The workload continues using its normal network path; the mirror is not an inline proxy or a replacement route.

The target must be able to parse the encapsulation. The outer destination port is UDP 4789, the well-known VXLAN port. The inner packet contains the traffic selected by the filter. Read AWS's Traffic Mirror packet format documentation before choosing or configuring a collector.

The four resources

Resource	What it controls
Mirror source	An eligible ENI, commonly an EC2 network interface. The same ENI cannot be both a source and an existing mirror target.
Mirror filter	Inbound and outbound rules with protocol, CIDR, port ranges, and an `accept` or `reject` action.
Mirror target	The monitoring destination: an ENI, a Network Load Balancer, or a Gateway Load Balancer endpoint.
Mirror session	The source/filter/target association. Lower session numbers are evaluated first when multiple sessions use one source.

Supported sources and targets

A mirror source is an ENI of type interface, such as the interface attached to an EC2 or RDS resource. Traffic Mirroring is not available on every EC2 instance type. AWS maintains the current allowlist of virtualized instance families and bare-metal families in its mirror source documentation. Do not infer eligibility from the word “Nitro”: the current list includes supported families across generations, and bare-metal support has its own Nitro v2 restriction. Check the exact family before designing a capture.

Requester-managed ENIs are restricted: AWS documents Amazon RDS and Amazon ElastiCache requester-managed interfaces as the supported requester-managed sources. A Network Load Balancer and a Gateway Load Balancer endpoint are mirror targets, not mirror sources.

Targets can be:

An ENI of type interface on a collector instance. This is simple for a focused investigation and gives the decoder direct access to the VXLAN packets.
A Network Load Balancer in front of a fleet of monitoring instances. It needs a UDP listener on port 4789; AWS warns that removing that listener stops mirroring without an error indication.
A Gateway Load Balancer endpoint for a monitoring service in another VPC. The appliance must handle the additional outer GENEVE encapsulation from the Gateway Load Balancer as well as the inner VXLAN packet.

AWS recommends a Network Load Balancer or Gateway Load Balancer endpoint for high availability, but those load balancers can deliver packets out of order. Use a direct ENI target when the collector cannot reassemble flows after out-of-order delivery. See the current target considerations before selecting a topology.

How to set up a short packet capture

The console and AWS CLI expose the same resources. The sequence below is intentionally small: create a target, create a least-broad filter, create one session, verify the capture, then clean up.

Requirements and safe defaults

Choose an eligible source ENI and record its VPC, subnet, Availability Zone, and instance family.
Put the target in the same VPC, or connect the VPCs with an intra-Region VPC peering connection, a transit gateway, or a Gateway Load Balancer endpoint. Traffic Mirroring does not turn an unrelated VPC into a reachable target.
Ensure the source subnet route table can reach the target. AWS sends the encapsulated copy using the source VPC route table.
Allow UDP 4789 on the target's security group from the source's expected address range. Keep management access in a separate rule or security group, and do not open the collector to the public internet just to receive mirrored traffic.
Check network ACLs and the target appliance's host firewall. They must allow the mirror packets, while management and software-update access can remain separately restricted.
Use an IAM identity with only the permissions needed to describe the source and create, modify, view, and delete the mirror resources. Creating a session requires ownership of the source network interface or its subnet.

For cross-VPC or cross-account designs, confirm ownership and sharing rules first. The AWS source and target connectivity guide lists the supported combinations.

Configuration steps

Create the mirror target. In the VPC console, open Traffic Mirroring > Mirror targets. Select the collector ENI, a Network Load Balancer with a UDP 4789 listener, or a Gateway Load Balancer endpoint. Keep the target private and tag it with the investigation owner and expiry time.
Create the mirror filter. Open Traffic Mirroring > Mirror filters, then add inbound and outbound rules independently. Match the protocol, source and destination CIDRs, and source or destination port ranges needed for the question. Rules are processed from the lowest number to the highest; the first match controls whether that direction is mirrored. A reject rule stops the copy, but it does not block the original workload traffic. If you add no rules, no traffic is mirrored, and if you add no outbound rules, outbound traffic is not mirrored. The AWS filter concepts page includes concrete rule examples.
Create one session. Open Traffic Mirroring > Mirror sessions, select the source ENI, target, and filter, and choose a session number. Lower session numbers have higher priority when multiple sessions share a source. Leave packet length unset when the decoder needs full packets; set an explicit length when you intentionally want to reduce capture volume. A VNI is optional; use a known value only when the collector needs it.
Verify the path and decoder. Generate only the test traffic needed for the question. On a direct ENI target, a diagnostic capture can start with sudo tcpdump -ni <collector-interface> udp port 4789 -w mirror.pcap. This records the outer VXLAN packets; configure Wireshark, tshark, or the monitoring appliance to decode VXLAN and inspect the inner packet. With a Gateway Load Balancer endpoint, the appliance must also understand the outer GENEVE layer. Confirm the source CloudWatch metrics and target or appliance counters before interpreting an empty capture as an application problem.

Verify with CloudWatch

Traffic Mirroring metrics are published in the AWS/EC2 namespace. At the source, compare NetworkMirrorIn and NetworkMirrorOut with NetworkSkipMirrorIn and NetworkSkipMirrorOut. The skip metrics show bytes that matched the filter but were not mirrored because production traffic had priority. The current CloudWatch guide lists the metrics and their monitoring intervals. VPC Flow Logs do not capture mirrored packets, so use the target capture and Traffic Mirroring metrics to verify this data path.

Practical use cases

Security monitoring

Mirror only the addresses, protocols, and ports that the detection question requires. A focused rule set reduces sensitive-data exposure and gives the appliance more capacity. Store captures with the same access controls, retention policy, and incident handling used for other security evidence.

Network troubleshooting

Use a capture to distinguish DNS, TCP handshake, retransmission, MTU, and application-response problems. Correlate packet timestamps with application logs and CloudWatch metrics. A mirror capture shows what reached the eligible ENI and matched the filter; it does not prove that every packet was delivered to the target or that a remote service processed the request.

Traffic analysis and performance testing

Traffic Mirroring is useful for observing a workload while a separate test measures throughput or latency. It is not itself a benchmark, and mirrored traffic adds load. For a broader test plan, see the site's AWS network performance benchmarking guide.

Limits, encapsulation, and operational tradeoffs

What can be missed or truncated

Bandwidth and packet rate: mirrored traffic counts toward source instance bandwidth. AWS gives production traffic priority when the source reaches bandwidth or packets-per-second limits, so mirror packets can be dropped. Under sustained saturation, production traffic can also be affected. Size the collector for the aggregate rate from all sources.
MTU: Traffic Mirroring adds 54 bytes of headers for IPv4 and 74 bytes for IPv6. With a standalone instance target, packets larger than the target MTU can be truncated; AWS documents 8,947 bytes as the maximum MTU that can be supported without truncation in the general case. For a Gateway Load Balancer path, AWS documents an 8,500-byte maximum MTU, which leaves 8,446 bytes for IPv4 or 8,426 bytes for IPv6 before truncation. A configured packet length can intentionally capture only the first part of a packet.
Traffic types: AWS documents that Traffic Mirroring does not mirror ARP, DHCP, instance metadata service, NTP, or Windows activation traffic, and it is not supported for IPv6-only subnets. Do not use an empty capture for those traffic types as proof that the session is broken.
Filtering: Inbound traffic already dropped by the source's inbound security group or network ACL is not mirrored. Mirrored outbound traffic is not subject to the source's outbound security group rules, but the target's route, security group, network ACL, and appliance firewall still matter.
Topology: Network Load Balancers and Gateway Load Balancer endpoints improve availability but can reorder packets. A single target can also receive traffic from multiple sources; calculate the aggregate load and watch for drops.

Quotas and supported families change. Use the live Traffic Mirroring quotas page instead of copying fixed account totals into a design document. The current quotas include limits per source, target, filter, and session, with some values depending on the target instance type.

Security, cost, and cleanup tips

Minimize exposure: use private subnets where possible, restrict UDP 4789 to the source path, isolate management access, encrypt capture storage, and give the capture role the smallest practical read and administration permissions.
Control performance: start with one source and a narrow rule set, choose a target that can handle the expected packet rate, and use the skip metrics and target counters to detect loss. Keep full-packet capture only when it is needed for the investigation.
Plan for encryption: document whether the evidence will contain plaintext, TLS ciphertext, or another encrypted protocol. Traffic Mirroring does not provide a decryption key or an application-aware interpretation.
Stop the bill: delete the mirror session as soon as the capture ends, then remove the filter and target when they are no longer needed. AWS charges for each active session by the hour, even if the source is stopped, terminated, detached, or changed to an unsupported instance type. Data transfer and load-balancer data-processing charges can also apply. Review the current Amazon VPC pricing page for the Region and target design.

A repeatable packet-capture checklist

Before enabling a session, confirm the source family, target type, VPC route, UDP 4789 access, filter direction and priority, and the collector's VXLAN decoder. During the capture, compare the target output with the source's mirror and skip metrics. Afterward, delete the session and its unused resources, then handle the capture according to its sensitivity.

For the surrounding network design, see the site's AWS VPC configuration guide. For dashboard and telemetry troubleshooting, see AWS network dashboard troubleshooting.