Traffic Mirroring

For analysis.

What traffic mirroring is

Traffic mirroring duplicates production requests to a parallel system without affecting the production path. Real traffic with no risk to the user; the mirror analyses or tests the duplicate while the original response goes back to the user normally.

• Production-traffic duplicate. Mirror copy per request; original request is processed normally, mirror is processed for analysis.
• No production impact. Original response returns to the user; mirror's response is captured but not returned.
• Common workloads. Pre-prod load testing, security inspection, ML inference comparison, schema migration validation.
• Named purpose per mirror. Documented use case per mirror catches scope creep that turns experiments into permanent infrastructure.

AWS Traffic Mirroring

AWS Traffic Mirroring is the packet-layer option. Sources from an ENI, sends to an NLB or inspection fleet, controls cost via sampling. Useful when full-packet visibility is required.

• VPC Traffic Mirroring. Layer-4 packet capture per ENI; full packet contents delivered to a mirror target.
• Cost. Per-ENI hourly plus per-GB; can be expensive at high volume, sample 1-5% for coverage rather than mirror everything.
• Targets. NLB or fleet of inspection instances; each captures, processes, optionally reassembles into HTTP for application-level analysis.
• Retention policy per mirror. Captured-data lifecycle documented; compliance and cost both depend on it.

Application-level mirroring

Application-level mirroring processes requests rather than packets. Service mesh, Envoy proxy, and framework-level options give richer signal at the cost of higher coupling to the application stack.

• Service mesh. Istio or Linkerd HTTP-level mirroring per route; configurable per route, integrates with the mesh.
• Envoy proxy. request_mirror_policies filter per listener; specifies mirror destination cluster declaratively.
• Application logic visible. Request-shape processing rather than raw bytes; easier to derive value from than packet capture.
• Percentage control per mirror. Runtime fraction supports gradual rollout from 1% to full traffic.

Common use cases

Use cases drive the architecture choice. Load testing, security inspection, and ML evaluation each fit a different mirroring pattern.

• Pre-prod load testing. Real-traffic shadow per version; new version receives production traffic shape, original continues serving users.
• Security inspection. IDS/IPS deep analysis per mirror; full visibility without affecting latency on the production path.
• ML evaluation. Champion/challenger pattern per mirror; new model evaluates against real traffic, outputs compared to current production model.
• Named success metric per mirror. Documented outcome per mirror keeps the experiment purposeful and time-bounded.

Limits and gotchas

The limits are real. PII exposure, stateful-write risks, and cost at scale all need explicit handling; mirroring without thinking about them is how compliance incidents start.

• PII implications. Customer-data exposure per mirror; compliance review required, encryption in transit, restricted access for the captured data.
• Stateful systems are hard. Duplicate-write risk per mirror; use read-only mirrors or shadow databases to avoid corrupting state.
• Cost at scale. Data-volume cost per mirror; sample where statistical confidence is sufficient rather than capture 100%.
• Sunset plan per mirror. Time-bounded purpose per mirror catches forgotten experiments running indefinitely.