Traffic Mirroring limitations - Amazon Virtual Private Cloud
General limitationsMTU limitationsTraffic bandwidth and prioritization limitationsChecksum offloading limitations

Traffic Mirroring limitations

This section contains the limitations for Traffic Mirroring.

General limitations

This section contains general Traffic Mirroring limitations.

Instance types

The following limitations only apply to only the traffic mirroring source instance type.

  • Traffic Mirroring is not available on the following virtualized Nitro instance types:

    • General purpose: M8g, M6a, M6i, M6id, M6idn, M6in, M7a, M7g, M7gd, M7i, M7i-flex

    • Compute optimized: C8g, C6a, C6gd, C6gn, C6i, C6id, C6in, C7a, C7g, C7gd, C7gn, C7i

    • Memory optimized: R8g, R6a, R6i, R6id, R6idn, R6in, R7a, R7g, R7gd, R7i, R7iz, X8g, X2idn, X2iedn, X2iezn

    • Storage optimized: I4g, I4i, Im4gn, Is4gen

    • Accelerated computing: Inf2, P5, Trn1, Trn1n

    • High-performance computing: Hpc6a, Hpc6id, Hpc7a, Hpc7g

  • Traffic Mirroring is not available on bare metal instances.

  • Traffic Mirroring is available only on the following non-Nitro instances types: C4, D2, G3, G3s, H1, I3, M4, P2, P3, R4, X1, and X1e. Note that this does not include T2 instances.

IPv6 traffic

Traffic Mirroring is not supported for IPv6-only subnets.

Traffic types

Traffic Mirroring can't mirror the following traffic types:

  • ARP

  • DHCP

  • Instance metadata service

  • NTP

  • Windows activation

VPC Flow Logs

VPC Flow Logs do not capture mirrored traffic.

Shared VPCs and subnets

  • Participants cannot describe, create, modify, or delete a traffic mirror session or target that belongs to the VPC owner. Participants can describe, create, modify, and delete a traffic mirror session or target that belongs to them.

  • VPC owners cannot describe, create, modify, or delete a traffic mirror session or target that belongs to the participant.

For more information see, Share your VPC with other accounts in the Amazon VPC User Guide.

MTU limitations

We truncate the packet to the MTU value when both of the following are true:

  • The traffic mirror target is a standalone instance.

  • The mirrored traffic packet size is greater than the traffic mirror target MTU value.

For example, if an 8996 byte packet is mirrored, and the traffic mirror target MTU value is 9001 bytes, the mirror encapsulation results in the mirrored packet being greater than the MTU value. In this case, the mirror packet is truncated. To prevent mirror packets from being truncated, set the traffic mirror source interface MTU value to 54 bytes less than the traffic mirror target MTU value for IPv4 and 74 bytes less than the traffic mirror target MTU value when you use IPv6. Therefore, the maximum MTU value supported by Traffic Mirroring with no packet truncation is 8947 bytes.

For more information about configuring the network MTU value, see Network maximum transmission unit (MTU) in the Amazon EC2 User Guide.

Traffic bandwidth and prioritization limitations

Mirrored traffic counts toward instance bandwidth. For example, if you mirror a network interface that has 1 Gbps of inbound traffic and 1 Gbps of outbound traffic, the instance must handle 4 Gbps of traffic (1 Gbps inbound, 1 Gbps mirrored inbound, 1 Gbps outbound, and 1 Gbps mirrored outbound) and your packet size should be equal to or greater than 1500 Bytes. Note that the per flow limit for EC2 instances not in placement groups is 5Gbps. For instances not in placement groups, the per flow throughput should be lower than 2.5Gbps or mirrored packets will be dropped.

Production traffic has a higher priority than mirrored traffic when there is traffic congestion. As a result, mirrored traffic is dropped when there is congestion. The mirroring drops can occur at lower bandwidths also if the average packet size of your traffic is small.

By default, each Gateway Load Balancer endpoint can support a bandwidth of up to 10 Gbps per Availability Zone and automatically scales up to 100 Gbps. For more information, see AWS PrivateLink quotas in the AWS PrivateLink Guide.

Checksum offloading limitations

The Elastic Network Adapter (ENA) provides checksum offloading capabilities. If a packet is truncated, this might result in the packet checksum not being calculated for the mirrored packet. The following checksums are not calculated when the mirrored packet is truncated:

  • If the mirror packet is truncated, the mirror packet L4 checksum is not calculated.

  • If any part of the L3 header is truncated, the L3 checksum is not calculated.

If this causes issues, you can disable ENA checksum offloading on the ENA for the source. For example, use the following commands on Amazon Linux 2:

[ec2-user ~]$ sudo ethtool --offload eth0 tx off 
[ec2-user ~]$ sudo ethtool --show-offload eth0
Features for eth0:
rx-checksumming: on
tx-checksumming: off
     tx-checksum-ipv4: off
     tx-checksum-ip-generic: off [fixed]
     tx-checksum-ipv6: off [fixed]
     tx-checksum-fcoe-crc: off [fixed]
     tx-checksum-sctp: off [fixed]