To ensure the proper running of your business, refer to the following limits before using a traffic mirror.
The traffic mirror feature is in beta now. To try it out, please submit a ticket. Save the link to the Traffic Mirror console for later logins; otherwise, you may need to apply again.
Using the traffic mirror feature consumes CVM resources such as CPU, memory, and bandwidth.
The mirrored traffic counts towards the instance bandwidth based on the traffic size and type. For example, if a network interface has 1 Gbps inbound traffic and 1 Gbps outbound traffic, when you use the traffic mirror, the traffic to be processed will be 1 Gbps inbound traffic and 3 Gbps outbound traffic (including 1 Gbps outbound traffic, 1 Gbps mirrored inbound traffic, and 1 Gbps mirrored outbound traffic).
Flow logs cannot be used to capture traffic mirror data.
Security group limits:
Collection source: Mirrored traffic is not subject to security group policies.
Target: It is subject to security group policies.
Unsupported data:
ARP
DHCP
Instance Metadata Service
NTP
Windows activation
Supported source/target models:
Standard S1, Standard S2, Standard S3, Memory Optimized M1, Memory Optimized M2, Memory Optimized M3, High I/O I1, High I/O I2, Compute Optimized C2, Compute Optimized C3, Compute Enhanced CN3, and Big Data D1.
Limits on CVM ENIs
The upper ENI bandwidth limit of the target CVM must be at least 1/9 of the total ENI bandwidth of all CVM instances in the collection range.
For example, if there are six S3.6XLARGE48 instances in the collection range of a traffic mirror, and the total ENI bandwidth is 3 Gbps x 6 = 18 Gbps, then the inbound bandwidth at the target must be at least 2 Gbps (18/9 = 2), that is, at least two S3.MEDIUM8 instances or one S3.4XLARGE32 instance.
It's recommended to set the number of targets and CVM specifications a little higher than your actual business requirements to keep a buffer. For more information on CVM instance specifications, see Instance Types.