What is AWS VPC Traffic Mirroring? The quick answer

AWS VPC Traffic Mirroring is an out-of-band packet-copying feature for Amazon VPC. It mirrors traffic from supported source network interfaces, applies ingress and egress filter rules, encapsulates accepted packets in VXLAN, and sends them to a traffic mirror target for analysis.

AWS describes Traffic Mirroring as a feature for copying network traffic from network interfaces attached to instances and delivering matching traffic to monitoring appliances. For a concise AWS overview, see How Traffic Mirroring works.

Source, target, filter and session: the four components

The feature becomes easier to design when you separate it into four objects. A common configuration error is to focus on the target appliance before confirming that the correct ENI and filter actually cover the traffic you need.

Traffic Mirroring is not available on every EC2 instance type. AWS maintains the current supported-source list in its traffic mirror session concepts documentation. Check the source instance type before designing a rollout around a particular ENI.

How VXLAN works in AWS VPC Traffic Mirroring

After the filter accepts a packet, AWS wraps the mirrored copy in a VXLAN header and routes it to the configured target. The original production packet continues on its normal path; the monitoring copy follows the mirror path.

Production path
Client  -------- original packet --------> Application

Mirror path
Source ENI
  -> filter match
  -> VXLAN encapsulation
  -> UDP destination port 4789
  -> traffic mirror target
  -> monitoring / security appliance
  -> original inner packet is analyzed

What is inside the mirrored packet?

AWS documents the traffic mirror packet with a VXLAN ID (VNI), an outer source IP, an outer source port derived from a hash of the original flow, a target destination IP, and destination port 4789. The appliance must remove the VXLAN wrapper before analyzing the original inner packet.

GWLB has an important double-encapsulation detail

When mirrored traffic reaches an appliance through a Gateway Load Balancer, AWS documents an outer GENEVE encapsulation from GWLB and an inner VXLAN encapsulation from Traffic Mirroring. The receiving appliance must understand both layers to recover the original packet. This is easy to miss when a tool works with a direct ENI target but fails after moving behind GWLB.

See AWS's current traffic mirror packet format documentation and RFC 7348 for the VXLAN protocol.

Choose the right traffic mirror target architecture

AWS supports three target types: a network interface, a Network Load Balancer, and a Gateway Load Balancer endpoint. AWS specifically recommends NLB or a GWLB endpoint when high availability is required.

Same VPC, cross-VPC and cross-account designs

The source and target can be in the same VPC. AWS also supports connected VPC designs using intra-Region VPC peering, Transit Gateway, or Gateway Load Balancer endpoint connectivity. Traffic mirror targets can also be shared across accounts. The mirror path still depends on route tables and network controls, so "the target exists" is not enough—the source must have a valid route to it.

For topology details, use AWS's source and target connectivity options and traffic mirror target concepts.

How to deploy AWS VPC Traffic Mirroring step by step

A reliable rollout starts with the visibility requirement, not with a blanket "mirror everything" configuration. Use a small known traffic set first, prove packet delivery and parsing, and only then expand coverage.

1. Identify the traffic you need. Write down the source workload, protocol, direction, ports, expected request/response path, and whether the payload is encrypted at the candidate ENI.
2. Verify the source is supported. Confirm the source network interface and instance type can be used for Traffic Mirroring.
3. Create the target. Choose a monitoring ENI, NLB, or GWLB endpoint based on availability and scale.
4. Make the target reachable. Validate routing and allow VXLAN UDP 4789 on the destination path as required.
5. Create the filter. Add explicit ingress and egress rules for the traffic you intend to mirror.
6. Create the session. Select the source, target, filter and priority. Configure VNI or packet length only when you have a reason.
7. Generate known test traffic. Use a controlled request whose source, destination, protocol and timestamp are known.
8. Validate at the receiver. Confirm VXLAN arrives, decapsulation works, the inner packet is present, and both directions are visible when required.
9. Watch for packet loss and capacity limits. Test realistic peak traffic before expanding the mirrored scope.
10. Document cost and data handling. Mirrored packets may contain credentials, tokens, personal data or regulated information.

AWS CLI session example

The following is a safe skeleton based on the current AWS CLI v2 command. Replace the example IDs with resources from your environment:

aws ec2 create-traffic-mirror-session \
  --network-interface-id eni-SOURCE \
  --traffic-mirror-target-id tmt-TARGET \
  --traffic-mirror-filter-id tmf-FILTER \
  --session-number 1 \
  --description "Security monitoring"

Omit --packet-length when you want the full packet. If you set a packet length, AWS mirrors only that number of bytes after the VXLAN header. For the complete syntax, see the AWS CLI v2 create-traffic-mirror-session reference.

Filter and session behavior that often causes mistakes

Filter rules are ordered and directional

A traffic mirror filter has separate inbound and outbound rules. AWS evaluates rules from the lowest rule number upward, and the first matching rule decides whether the packet is accepted or rejected for mirroring. If you do not add outbound rules, outbound traffic is not mirrored. A filter with no applicable rules does not magically capture everything.

Session number is a priority, not just a label

When the same source interface has multiple traffic mirror sessions, AWS evaluates them in ascending session-number order. Valid session numbers are 1 through 32,766, with 1 as the highest priority. AWS states that each packet is mirrored once, so the first session with a matching filter determines where that packet is mirrored.

Packet truncation can remove the context you care about

Packet length can reduce mirrored volume, but it can also remove application data from the copied packet. AWS notes that truncation can affect checksum calculation on the mirrored packet. For API security, forensics, or protocol analysis, decide the packet length from the evidence you actually need—not from a generic "smaller is faster" assumption.

See AWS's traffic mirror filter concepts and session configuration documentation.

Current limits, packet-loss behavior and cost considerations

Traffic Mirroring is not an unlimited copy of every packet. Capacity and quota behavior should be part of the design review, especially when a single target collects traffic from many high-volume workloads.

These are the values in the AWS Traffic Mirroring quota documentation at the time of this update; always verify the current AWS page before a production design because service limits can change. See Traffic Mirroring quotas.

Mirrored packets can be dropped under pressure

AWS documents that if traffic exceeds an instance's bandwidth or packets-per-second limits, mirrored traffic is dropped before production traffic. Small average packet sizes can also cause mirrored traffic to be dropped at lower bandwidth levels. That means "the session is configured" is not the same as "the monitoring tool sees every production packet."

Monitor capture loss, receiver CPU, queue pressure and packet rates. For incident response or compliance use cases, document whether packet loss is acceptable and how you will detect it. AWS's current limitations are described in Traffic Mirroring limitations.

Traffic Mirroring has direct and indirect costs

AWS charges for active traffic mirror sessions. Data transfer charges can apply, and when targets sit behind Network Load Balancer or Gateway Load Balancer, related load-balancer data-processing charges can also apply. AWS also notes that session charges continue until active mirror sessions are deleted, including cases where the source interface is detached or the source instance is stopped or terminated. Cost therefore depends on both session lifecycle and the architecture carrying mirrored traffic.

What VPC Traffic Mirroring can—and cannot—provide for API security

Traffic Mirroring can be a useful acquisition method for monitoring-first API security because it observes production traffic without adding a new inline hop. The security value, however, depends on what is visible at the selected ENI and what the receiving tool can reconstruct.

Where to capture encrypted API traffic

Do not assume a mirrored HTTPS flow provides readable API bodies. Identify where TLS terminates, whether traffic is re-encrypted, and which ENI sees the request in a form useful to the monitoring tool. If the required payload remains encrypted, combine mirroring with gateway, reverse-proxy, application, service-mesh or other approved application-layer telemetry instead of weakening TLS.

Where Ammune fits

Ammune can use monitoring-first traffic visibility as one input for runtime API discovery and analysis. Where the selected traffic source provides sufficient application context, Ammune can help inventory APIs, inspect requests and responses, identify sensitive-data exposure and abnormal behavior, and forward security events into SOC/SIEM workflows. Where prevention is required, findings should be connected to an appropriate enforcement point or Ammune can be deployed in an inline architecture designed for blocking.

AWS VPC Traffic Mirroring troubleshooting: follow the packet

Troubleshooting is faster when you work from the source outward. A healthy session object does not prove that a packet matches the filter, reaches the target, is decapsulated, or survives receiver overload.

A simple validation sequence

1. Generate one known test request.
2. Confirm it traverses the intended source ENI.
3. Confirm the filter should accept that direction/protocol/port/CIDR.
4. Confirm this session has the expected priority.
5. Confirm UDP 4789 reaches the target.
6. Confirm the receiver can decode VXLAN.
7. If using GWLB, confirm GENEVE + inner VXLAN parsing.
8. Confirm the original inner packet is visible.
9. Repeat for the response direction.
10. Repeat under realistic load and watch for packet loss.

When should you use VPC Traffic Mirroring?

Traffic Mirroring is a strong fit when packet-level observation is valuable and you want the monitoring system out of the application forwarding path. It is less suitable when the use case requires guaranteed payload decryption, application identity that packets do not contain, or immediate inline blocking.

Production-readiness checklist

1. Confirm the source ENI and instance type support Traffic Mirroring.
2. Map the real request and response path before selecting the source.
3. Choose ENI, NLB, or GWLB endpoint target based on HA and scale requirements.
4. Confirm a valid route from the source VPC to the target.
5. Allow required VXLAN UDP 4789 traffic on the target path.
6. Define explicit inbound and outbound filter rules.
7. Review session-number priority if a source has more than one session.
8. Use full packets unless truncation has a documented reason and has been tested.
9. Validate VXLAN decapsulation; validate GENEVE + VXLAN for GWLB designs.
10. Test TLS visibility at the chosen capture point.
11. Measure packet loss under expected peak traffic.
12. Protect mirrored data with access, retention, masking and storage controls appropriate to its sensitivity.
13. Monitor active-session cost, data transfer, load-balancer processing, receiver compute and downstream storage/SIEM costs.
14. Tag sessions, filters and targets with environment, owner and purpose.
15. Revalidate the design after major routing, encryption, instance-type or application changes.

Related Ammune guides

For adjacent architecture decisions, see Network TAP vs Port Mirroring, Out-of-Band Network Traffic Monitoring for API Security, Monitoring Mode vs Inline Mode, East-West vs North-South Traffic, API Runtime Security Protection Platform, and Centralized SIEM Log Forwarding Formats.

Primary references used for this guide

This article was reviewed against current AWS and protocol documentation rather than relying on secondary summaries.

• AWS: How Traffic Mirroring works
• AWS: Traffic mirror packet format
• AWS: Traffic mirror target concepts
• AWS: Traffic mirror filter concepts
• AWS: Traffic mirror session concepts
• AWS: Source and target connectivity
• AWS: Traffic Mirroring limitations
• AWS: Traffic Mirroring quotas
• RFC 7348: Virtual eXtensible Local Area Network (VXLAN)

Frequently asked questions

Conclusion

AWS VPC Traffic Mirroring is most useful when treated as a packet-visibility building block rather than as a complete security control. The source ENI determines what can be observed, the filter determines what is copied, the session determines priority and transport settings, and the target architecture determines how reliably the monitoring system can receive and process the data.

For a production deployment, pay particular attention to UDP 4789 reachability, VXLAN parsing, GWLB double encapsulation, request/response coverage, TLS visibility, packet truncation, current AWS quotas, packet-loss behavior, and the full cost of collecting and retaining mirrored traffic.