# How Traffic Mirroring works
Traffic Mirroring copies inbound and outbound traffic from the network interfaces that are attached to your instances. You can send the mirrored traffic to the network interface of another instance, a Network Load Balancer that has a UDP listener, or a Gateway Load Balancer that has a UDP listener. The traffic mirror source and the traffic mirror target (monitoring appliance) can be in the same VPC. Or they can be in a different VPCs that are connected through intra-Region VPC peering, a transit gateway, or by a Gateway Load Balancer endpoint to connect to a Gateway Load Balancer in a different VPC.
Consider the following scenario, where you mirror traffic from two sources (Source A and Source B) to a single traffic mirror target (Target D). After you create the traffic mirror session, any traffic that matches the filter rules is encapsulated in a VXLAN header. It is then sent to the target.
![\[Traffic from source A and source B is mirrored to mirror target D using filter A.\]](http://docs.aws.amazon.com/vpc/latest/mirroring/images/traffic-mirroring.png)
The following procedures are required:
+ Identify the traffic mirror source (Source A)
+ Identify the traffic mirror source (Source B)
+ Configure the traffic mirror target (Target D)
+ Configure the traffic mirror filter (Filter A)
+ Configure the traffic mirror session for Source A, Filter A, and Target D
+ Configure the traffic mirror session for Source B, Filter A, and Target D
**Topics**
+ [Targets](traffic-mirroring-targets.md)
+ [Filters](traffic-mirroring-filters.md)
+ [Sessions](traffic-mirroring-sessions.md)
+ [Connectivity options](traffic-mirroring-connection.md)
+ [Packet format](traffic-mirroring-packet-formats.md)
# Understand traffic mirror target concepts
A *traffic mirror target* is the destination for mirrored traffic. In Amazon VPC, traffic mirroring allows you to copy network traffic from an elastic network interface (ENI) and send it to a traffic mirror target for monitoring and analysis purposes.
You can use the following resources as traffic mirror targets:
+ [Network interfaces](#traffic-mirroring-targets-eni) of type `interface`
+ [Network Load Balancers](#traffic-mirroring-targets-nlb)
+ [Gateway Load Balancer endpoints](#traffic-mirroring-targets-gwlb)
For high availability, we recommend that you use a Network Load Balancer or a Gateway Load Balancer endpoint as a mirror target.
You might experience out-of-order delivery of mirrored packets when you use a Network Load Balancer or Gateway Load Balancer endpoint as your traffic mirror target. If your monitoring appliance can't handle out-of-order packets, we recommend using a network interface as your traffic mirror target.
A traffic mirror target can be owned by an AWS account that is different from the traffic mirror source.
After you create a traffic mirror target, you add it to a traffic mirror session. You can use a traffic mirror target in more than one traffic mirror session. For more information, see [Understand traffic mirror session concepts](traffic-mirroring-sessions.md).
**Note**
If the underlying resource chosen as the target is deleted, we stop traffic mirroring for any sessions that use that target. To update a traffic mirroring target and resume the traffic mirroring session, you can use [modify-traffic-mirror-session](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/modify-traffic-mirror-session.html).
## Network interfaces
The following diagram shows a traffic mirror session where the traffic mirror target is a network interface for an EC2 instance. Traffic Mirroring filters the traffic from the network interface of the mirror source and sends the accepted mirrored traffic to the mirror target.
![\[A traffic mirror session where the mirror target is an EC2 instance.\]](http://docs.aws.amazon.com/vpc/latest/mirroring/images/get-started.png)
## Network Load Balancer
The following diagram shows a traffic mirror session where the traffic mirror target is a Network Load Balancer. You install the monitoring software on the target instances, and then register them with the load balancer. Traffic Mirroring filters the traffic from the network interface of the mirror source and sends the accepted mirrored traffic to the load balancer. The load balancer sends the mirrored traffic to the target instances.
![\[A traffic mirror session where the mirror target is a Network Load Balancer.\]](http://docs.aws.amazon.com/vpc/latest/mirroring/images/nlb-target.png)
**Considerations**
+ Traffic mirroring can't occur unless the load balancer has UDP listeners on port 4789. If you remove the UDP listeners, Traffic Mirroring fails without an error indication.
+ To improve availability and fault tolerance, we recommend that you select at least two Availability Zones when you create the Network Load Balancer, and that you register target instances in each selected Availability Zone.
+ We recommend that you enable cross-zone load balancing for your Network Load Balancer. If all registered target instances in an Availability Zone become unhealthy and cross-zone load balancing is disabled, the load balancer can't send the mirrored traffic to target instances in another Availability Zone. If you enable cross-zone load balancing, the load balancer can send the mirrored traffic to healthy target instances in another Availability Zone.
+ If you select an additional Availability Zone for your Network Load Balancer after you create it, Traffic Mirroring does not send mirrored traffic to target instances in the new Availability Zone unless you enable cross-zone load balancing.
+ When the Network Load Balancer removes a load balancer node from the DNS table, Traffic Mirroring continues to send the mirrored traffic to that node.
## Gateway Load Balancer endpoints
The following diagram shows a traffic mirror session where the traffic mirror target is a Gateway Load Balancer endpoint. The mirror source is in the service consumer VPC and the Gateway Load Balancer is in the service provider VPC. You install the monitoring software on the target appliances, and then register them with the load balancer. Traffic Mirroring filters the traffic from the network interface of the mirror source and sends the accepted mirrored traffic to the Gateway Load Balancer endpoint. The load balancer sends the mirrored traffic to the target appliances.
![\[A traffic mirror session where the mirror target is a Gateway Load Balancer endpoint.\]](http://docs.aws.amazon.com/vpc/latest/mirroring/images/gwlbe-target.png)
**Considerations**
+ A listener for Gateway Load Balancers listens for all IP packets across all ports, and then forwards traffic to the target group.
+ To improve availability and fault tolerance, we recommend that you select at least two Availability Zones when you create the Gateway Load Balancer, and that you register target appliances in each selected Availability Zone.
+ If all registered target appliances in an Availability Zone become unhealthy and cross-zone load balancing is disabled, the load balancer can't send the mirrored traffic to target appliances in another Availability Zone. If you enable cross-zone load balancing, the load balancer can send the mirrored traffic to healthy target appliances in another Availability Zone.
+ The maximum MTU supported by the Gateway Load Balancer is 8500. Traffic Mirroring adds 54 bytes of additional headers to the original packet payload when using IPv4, and 74 bytes when using IPv6. Therefore, the maximum packet size that can be delivered to an appliance without truncation is `8500 – 54 = 8446` when using IPv4, or `8500 – 74 = 8426` when using IPv6.
+ You can use the `BytesProcessed` and `PacketsDropped` CloudWatch metrics for VPC endpoints to monitor the volume of traffic being sent over the Gateway Load Balancer endpoint. You can also use CloudWatch metrics for Traffic Mirroring. For more information, see [Monitor mirrored traffic using Amazon CloudWatch](traffic-mirror-cloudwatch.md).
## VXLAN encapsulation
Mirrored traffic is encapsulated in VXLAN packets and then routed to the mirror target. The security groups for a traffic mirror target must allow VXLAN traffic (UDP port 4789) from the traffic mirror source. The route table for the subnet with the traffic mirror source must have a route that sends the mirrored traffic to the traffic mirror target. The monitoring software that you run on the mirror target must be able to process encapsulated VXLAN packets.
## Routing and security groups
Encapsulated mirror traffic is routed to the traffic mirror target by using the VPC route table. Make sure that your route table is configured to send the mirrored traffic to the traffic mirror target.
Inbound traffic that is dropped at the traffic mirror source, because of the inbound security group rules or the inbound network ACL rules, is not mirrored.
Mirrored outbound traffic is not subject to the outbound security group rules for the traffic mirror source.
## Processing mirrored traffic
You can use open-source tools or choose a monitoring solution available on [AWS Marketplace](https://aws.amazon.com/marketplace/). You can stream mirrored traffic to any network packet collector or analytics tool, without having to install vendor-specific agents.
# Understand traffic mirror filter concepts
A *traffic mirror filter* is a set of inbound and outbound rules that determines which traffic is copied from the traffic mirror source and sent to the traffic mirror target. You can also choose to mirror certain network services traffic, including Amazon DNS. When you add network services traffic, all traffic (inbound and outbound) related to that network service is mirrored.
We evaluate traffic mirror filter rules from the lowest value to the highest value. The first rule that matches the traffic determines whether the traffic is mirrored. If you don't add any rules, then no traffic is mirrored.
For example, in the following set of filter rules, rule 10 ensures that SSH traffic from my network to my VPC is not mirrored and rule 20 mirrors all other IPv4 TCP traffic.
| Number | Rule action | Protocol | Source port range | Destination port range | Source CIDR block | Destination CIDR block |
| --- | --- | --- | --- | --- | --- | --- |
| 10 | reject | TCP (6) | | 22 | my-network | vpc-cidr |
| 20 | accept | TCP (6) | | | 0.0.0.0/0 | 0.0.0.0/0 |
In the following set of filter rules, rule 10 mirrors HTTPS traffic from all IPv4 addresses and rule 20 mirrors HTTPS traffic from all IPv6 addresses.
| Number | Rule action | Protocol | Source port range | Destination port range | Source CIDR block | Destination CIDR block |
| --- | --- | --- | --- | --- | --- | --- |
| 10 | accept | TCP (6) | | 443 | 0.0.0.0/0 | 0.0.0.0/0 |
| 20 | accept | TCP (6) | | 443 | ::/0 | ::/0 |
Note that if you don't add outbound rules, then no outbound traffic is mirrored.
# Understand traffic mirror session concepts
A *traffic mirror session* establishes a relationship between a traffic mirror source and a traffic mirror target. Traffic mirror sessions are evaluated based on the ascending session number that you define when you create the session.
A traffic mirror session contains the following resources:
+ A traffic mirror [source](#traffic-mirroring-sources)
+ A traffic mirror [target](traffic-mirroring-targets.md)
+ A traffic mirror [filter](traffic-mirroring-filters.md)
Each packet is mirrored once. However, you can use multiple traffic mirror sessions on the same mirror source. This is useful if you want to send a subset of the mirrored traffic from a traffic mirror source to multiple tools. For example, you can filter HTTP traffic in a higher priority traffic mirror session and send it to a specific monitoring appliance. At the same time, you can filter all other TCP traffic in a lower priority traffic mirror session and send it to another monitoring appliance.
## Traffic mirror sources
A traffic mirror source is the network interface of type `interface`. For example, a network interface for an EC2 instance or an RDS instance.
A network interface can't be used as a traffic mirror source if the same Elastic network interface is already in use in an existing traffic mirror target.
**Note**
If the source network interface gets deleted, AWS deletes the traffic mirroring session.
Traffic Mirroring is not available on all instance types.
Virtualized instance types in the following instance families are supported as Traffic Mirroring source:
+ **General purpose:** A1 \$1 M4 \$1 M5 \$1 M5a \$1 M5ad \$1 M5d \$1 M5dn \$1 M5n \$1 M5zn \$1 M6a \$1 M6g \$1 M6gd \$1 M6i \$1 M6id \$1 M6idn \$1 M6in \$1 M7a \$1 M7g \$1 M7gd \$1 M7i \$1 M7i-flex \$1 Mac1 \$1 Mac2 \$1 Mac2-m1ultra \$1 Mac2-m2 \$1 Mac2-m2pro \$1 T3 \$1 T3a \$1 T4g
+ **Compute optimized:** C4 \$1 C5 \$1 C5a \$1 C5ad \$1 C5d \$1 C5n \$1 C6a \$1 C6g \$1 C6gd \$1 C6gn \$1 C6i \$1 C6id \$1 C6in \$1 C7a \$1 C7g \$1 C7gd \$1 C7i \$1 C7i-flex
+ **Memory optimized:** R4 \$1 R5 \$1 R5a \$1 R5ad \$1 R5b \$1 R5d \$1 R5dn \$1 R5n \$1 R6a \$1 R6g \$1 R6gd \$1 R6i \$1 R6id \$1 R6idn \$1 R6in \$1 R7a \$1 R7g \$1 R7gd \$1 R7i \$1 R7iz \$1 U-3tb1 \$1 U-6tb1 \$1 U-9tb1 \$1 U-12tb1 \$1 U-18tb1 \$1 U-24tb1 \$1 U7i-6tb \$1 U7i-8tb \$1 U7i-12tb \$1 U7in-16tb \$1 U7in-24tb \$1 U7in-32tb \$1 U7inh-32tb \$1 X1 \$1 X1e \$1 X2gd \$1 X2idn \$1 X2iedn \$1 X2iezn \$1 z1d
+ **Storage optimized:** D2 \$1 D3 \$1 D3en \$1 H1 \$1 I3 \$1 I3en \$1 I4g \$1 I4i \$1 I7i \$1 Im4gn \$1 Is4gen
+ **Accelerated computing:** DL1 \$1 DL2q \$1 F1 \$1 F2 \$1 G3 \$1 G4ad \$1 G4dn \$1 G5 \$1 G5g \$1 G6 \$1 G6e \$1 G6f \$1 Gr6 \$1 Gr6f \$1 Inf1 \$1 Inf2 \$1 P3 \$1 P3dn \$1 P4d \$1 P4de \$1 P5 \$1 P5e \$1 Trn1 \$1 Trn1n \$1 VT1
+ **High-performance computing:** Hpc6a \$1 Hpc6id \$1 Hpc7a
# Understand traffic mirror source and target connectivity options
Connecting traffic mirror sources and targets in different VPCs can be useful for monitoring and analyzing network traffic across multiple environments. This allows you to centralize your network monitoring and security analysis, even if your application infrastructure is spread across different VPCs or AWS accounts.
The traffic mirror source and the traffic mirror target (monitoring appliance) can be in the same VPC or different VPCs and can be connected using the following resources:
+ An intra-Region VPC peering connection.
+ A transit gateway.
+ A Gateway Load Balancer endpoint.
The traffic mirror target can be owned by an AWS account that is different from the traffic mirror source.
The mirrored traffic is sent to the traffic mirror target using the source VPC route table. Before you configure Traffic Mirroring, make sure that the traffic mirror source can route to the traffic mirror target.
The following table describes the available resource configurations.
| Source owner | Source VPC | Target owner | Target VPC | Connectivity option |
| --- | --- | --- | --- | --- |
| Account A | VPC 1 | Account A | VPC1 | No additional configuration |
| Account A | VPC 1 | Account A | VPC 2 | Intra-Region peering or a transit gateway or Gateway Load Balancer endpoint |
| Account A | VPC 1 | Account B | VPC 2 | Cross-account intra-Region peering connection, a transit gateway, or a Gateway Load Balancer endpoint |
| Account A | VPC 1 | Account B | VPC 1 | VPC sharing |
# Understanding traffic mirror packet format
Mirrored traffic is encapsulated with a VXLAN header. All appliances that receive traffic directly with this feature should be able parse a VXLAN-encapsulated packet, as shown in the following example:
![\[Traffic Mirroring packet.\]](http://docs.aws.amazon.com/vpc/latest/mirroring/images/traffic-mirroring-packets.png)
For more information about the VXLAN protocol, see [RFC 7348](https://tools.ietf.org/html/rfc7348).
The following fields apply to Traffic Mirroring:
+ **VXLAN ID** — The virtual network ID that you can assign to a traffic mirror session. If you do not assign a value, we assign a random value that is unique to all sessions in the account.
+ **Source IP address** — The primary IP address of the source network interface.
+ **Source port** — The port is determined by a 5-tuple hash of the original L2 packet, for ICMP, TCP, and UDP flows. For other flows, the port is determined by a 3-tuple hash of the original L2 packet.
+ **Destination IP address** — The primary IP address of the appliance, Gateway Load Balancer endpoint, or Network Load Balancer (when the appliance is deployed behind one).
+ **Destination port **— The port is 4789, which is the well known port for VXLAN.
Appliances that received mirrored traffic through a Gateway Load Balancer should be able to parse both outer GENEVE encapsulation (from Gateway Load Balancer) and an inner VXLAN encapsulation (from VPC Traffic Mirroring) to retrieve the original L3 packet. The following shows an example:
![\[Traffic Mirroring packets include Gateway Load Balancer\]](http://docs.aws.amazon.com/vpc/latest/mirroring/images/traffic-mirroring-gwlb-packets.png)