Traffic mirroring stress testing

Use cases

Many enterprises have stringent requirements for the security and stability of their production workloads. Before you release a new feature or run a stress test, you cannot operate directly in the production environment without affecting the production workload. At the same time, you need real production traffic to verify the correctness of the new feature and evaluate service performance. Manually generated test data often fails to cover the actual distribution of production requests, which results in inaccurate test results.

Limitations

• Both Internet-facing ALB and internal-facing ALB support traffic mirroring.

• Basic Edition ALB instances do not support traffic mirroring.

Prerequisites

• Create a production server group and a staging server group. The backend protocol for both server groups is set to HTTP. For more information, see Create and manage server groups.

• Create a listener. For more information, see Add an HTTP listener, add an HTTPS listener, or add a QUIC listener.

Simulate production traffic by using traffic mirroring

1. Log on to the ALB console.

2. In the top menu bar, select the region of the ALB instance.

3. On the Instances page, click the ID of the target instance.

4. On the Listener tab, find the target listener, and then click View/Modify Forwarding Rule in the Actions column.

5. On the Forwarding Rules > Inbound Forwarding Rules tab, click Add New Rule.

6. In the Add Forwarding Rule section, configure the forwarding conditions to specify the scope of traffic to be mirrored.

   Forwarding conditions are used to match the requests to be mirrored. You can match requests as needed based on conditions such as Domain Name and Path. To mirror all production traffic under the listener (for example, to collect all real production requests from the Internet-facing entry point), set the Path to /* (which matches all paths). To mirror only part of the traffic, set the Path to a specific path. This topic uses an example in which traffic is mirrored to the staging server group if the Path is /test.

7. Configure the Action and add the following two actions to the forwarding rule in sequence.

   1. Add a Forward to action and select the production server group to ensure that the matched production traffic is forwarded to the production workload as usual, without affecting the production service.

   2. Click Add Action, add a Mirror traffic to action, and select the staging server group to copy the matched traffic and mirror it to the staging environment.

   Important

   Because ALB discards response data from the staging server group, you must add a Forward to action for the production server group to this forwarding rule to avoid affecting your production workload.

8. Click OK. After the configuration is complete, the production traffic that matches the forwarding rule is mirrored to the staging server group.

Verify the mirroring result

After the configuration is complete, you can use the following methods to confirm that the production traffic is actually collected and mirrored to the staging server group:

• View the access logs on the staging servers (such as Nginx or Tomcat application logs) to confirm that they receive real requests consistent with the production workload, and that the request content matches the clients' actual access.

• In the monitoring data of the staging server group, observe that metrics such as the number of requests and connections change with the production traffic, which indicates that the mirrored traffic has successfully reached the staging environment.

• Confirm that the responses that clients receive when they access the production workload are normal and free of abnormal latency, which verifies that traffic mirroring does not affect the production workload.

References

Manage forwarding rules for a listener