---
title: "Traffic mirroring in Kubernetes: Istio vs Speedscale | Speedscale"
description: "Compare Istio traffic mirroring with Speedscale replay in Kubernetes. Use capture, redaction, and dependency isolation for repeatable regression tests."
canonical: "https://speedscale.com/blog/traffic-mirroring-options-kubernetes/"
---

![Traffic mirroring in Kubernetes: Istio vs Speedscale](https://speedscale.com/_astro/traffic-mirroring.LPlmcf8U_ZJg0rl.webp)

# Traffic mirroring in Kubernetes: Istio vs Speedscale

Jan 24, 2023 (Updated: Oct 12, 2026 )

[By Nate Lee](https://speedscale.com/blog/author/nate-lee/)

[Developer Productivity](https://speedscale.com/blog/category/developer-productivity/) [Kubernetes](https://speedscale.com/blog/category/kubernetes/)

* * *

A shadow pod can still write to your production database. Copying a request to a second deployment doesn’t change that deployment’s credentials or the services it calls. Before using traffic mirroring in Kubernetes, decide where those downstream calls will go.

Istio can copy live requests to another service as they arrive. With Speedscale, we record requests and responses, save a traffic snapshot, and replay it later against a test deployment. Captured outbound responses can supply mocks for supported dependencies. That makes replay useful when you need the same regression scenarios on successive builds, including changes written by coding agents.

Both approaches require an explicit boundary around production data. This guide compares them, then covers AWS VPC Traffic Mirroring and gateway shadowing as other options. For a broader look at the replay side, see [Kubernetes testing with traffic replay](https://speedscale.com/blog/mastering-kubernetes-testing-with-traffic-replay/).

## Istio mirroring and Speedscale replay

The choice starts with when you need traffic to run and how you’ll evaluate the result.

| Requirement | Istio traffic mirroring | Speedscale traffic replay |
| --- | --- | --- |
| Exercise a second deployment with current traffic | Copies a configured percentage of live requests | Replays a previously captured snapshot |
| Run the same inputs against successive builds | Mirroring alone doesn’t retain a reusable test set | Reuses saved snapshots for regression runs |
| Compare application responses | The mirror discards shadow responses; add comparison tooling | Replay reports compare responses against captured expectations and configured assertions |
| Handle downstream dependencies | Configure the shadow service’s dependencies separately | Mock supported captured dependencies or use isolated test instances |
| Protect sensitive fields | Add redaction controls outside the mirror rule | Configure and validate DLP rules before export |
| Prevent production writes | Isolate credentials, dependencies, and network access | Isolate credentials, dependencies, and network access; verify mocks and disable passthrough |

The [Istio mirroring task](https://istio.io/latest/docs/tasks/traffic-management/mirroring/) describes asynchronous request duplication and discarded shadow responses. Our [replay guide](https://docs.speedscale.com/guides/replay/) and [backend mocking guide](https://docs.speedscale.com/guides/replay/mocks/) explain saved snapshots, validation reports, and dependency selection.

The two approaches differ in where the copied request goes and what happens to the response:

```
flowchart LR
    subgraph Istio[Istio mirroring: live, in the request path]
        C1[Client] --> V1[v1 serves response]
        C1 -.->|async copy| V2[v2 shadow]
        V2 -.-> X1[Response discarded]
    end
    subgraph SS[Speedscale: capture now, replay later]
        P[Production traffic] --> Snap[Snapshot]
        Snap --> R[Replay at test deployment]
        R --> M[Mocks or test instances]
        R --> Rep[Validation report]
    end
```

## Live traffic mirroring with Istio

If Istio already handles your service traffic, mirroring is a small routing change. A `VirtualService` can route requests to one subset and mirror a percentage to another. This is useful for observing a candidate version under the requests currently arriving at the service.

The following example adapts Istio’s [mirroring task](https://istio.io/latest/docs/tasks/traffic-management/mirroring/) and [VirtualService reference](https://istio.io/latest/docs/reference/config/networking/virtual-service/). It assumes a development namespace named `mirror-demo`, an Istio sidecar mesh on version 1.22 or later (earlier releases serve these resources as `networking.istio.io/v1beta1`), and a Service named `httpbin` selecting pods labeled `app: httpbin`. Two deployments have `version: v1` and `version: v2` labels. Install those demo workloads first; this manifest only configures routing.

```
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: httpbin
  namespace: mirror-demo
spec:
  host: httpbin
  subsets:
    - name: v1
      labels:
        version: v1
    - name: v2
      labels:
        version: v2
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: httpbin
  namespace: mirror-demo
spec:
  hosts:
    - httpbin
  http:
    - route:
        - destination:
            host: httpbin
            subset: v1
          weight: 100
      mirror:
        host: httpbin
        subset: v2
      mirrorPercentage:
        value: 10.0
```

The [`mirrorPercentage` setting](https://istio.io/latest/docs/reference/config/networking/virtual-service/#HTTPRoute) copies 10% of requests to `v2`, while the main route sends requests to `v1`. Responses from `v2` aren’t returned to the caller. The example uses sidecar-mode APIs; check the appropriate routing configuration for your mesh mode and installed version.

Mirroring still executes application code in the shadow deployment. A mirrored `POST` can create a record, send a message, or call a payment API if that deployment retains access, and even a `GET` may have side effects. The response is thrown away, but the operations it came from have already run.

Cross-cluster mirroring only needs a network path from the source to the shadow destination, so configure routing and access for that direction explicitly. The shadow cluster doesn’t need credentials for production dependencies, and shouldn’t have them.

Mirroring also needs a way to judge correctness. Shadow logs and metrics can reveal errors or latency changes, but comparing responses takes additional tooling. A mirror rule on its own gives you traffic, not a regression result.

## Capture and replay with Speedscale

Speedscale can capture traffic with either an eBPF collector or a sidecar. To get started, follow the [Quick Start](https://docs.speedscale.com/getting-started/quick-start/). The [eBPF collector](https://docs.speedscale.com/reference/ebpf-traffic-collection/) runs as a DaemonSet and observes traffic for selected workloads without modifying your pods. The sidecar remains available if your nodes don’t meet the eBPF requirements or you prefer per-workload injection.

Check node kernel, architecture, host access, and runtime requirements before installation. TLS capture depends on the application runtime. JVM workloads use a Java instrumentation agent for supported socket and TLS paths and need new pods with a JVM restart to load it, because the agent is not attached to an already running JVM. See the [Java agent support matrix](https://docs.speedscale.com/reference/java/agent/) for coverage and known gaps.

Start with a service in a development cluster. Install the operator and collector, select a narrow capture target, and verify that the expected inbound requests and outbound dependency calls are visible. Capture coverage matters: a dependency response you didn’t record can’t supply a recorded mock.

Once collection is approved for the source environment, save a bounded snapshot of traffic. In the replay wizard, select the inbound requests, the outbound dependencies to mock, and the test cluster, namespace, and workload. We can replay the snapshot against a new build and inspect response differences in the validation report. [Transforms](https://docs.speedscale.com/guides/transformation/overview/) let you adjust authentication and variable data for the test environment. Our [Kubernetes traffic replay](https://speedscale.com/features/kubernetes-traffic-replay/) page covers the cluster workflow in more detail.

Stored snapshots remove the need for a live request path between the production application and the replay target. The test environment still needs access to the configured Speedscale services or storage. It also needs separate credentials and network controls for its own dependencies.

Replay covers the behavior present in the recording and nothing more. Scenarios nobody exercised stay untested, business journeys aren’t reconstructed automatically, and a mocked database tells you little about how a live one behaves. If you keep a dependency live for an integration test, point it at a disposable test instance with known initial state and reset that state between runs.

## Keep replay away from production data

Consider a service that accepts an application, writes to a database, and calls a third-party API. You want to check a new build against recorded requests without creating another production record. The test copy needs a controlled destination for every downstream interaction.

For an isolated replay, enable mocks for each supported dependency whose side effects you want to avoid. Route any dependency that needs to remain live to a test instance. Remove production secrets and production-capable cloud identities from the workload, including access inherited through its service account.

Keep mock passthrough disabled. Our [backend mocking guide](https://docs.speedscale.com/guides/replay/mocks/#disabling-some-mock-responses) documents that passthrough allows unrecognized requests to continue to their original destination. Disabling a mock or running in tests-only mode also changes which calls reach real services. Review those settings before a run.

Enforce an egress policy that blocks production databases and APIs independently of mock matching. A separate namespace is a placement boundary; its actual isolation depends on enforced network policy and access controls. Verify denied production access from the test workload, and allow only the mocks, test dependencies, and infrastructure endpoints it needs.

After replay, inspect outbound traffic and mock match results as well as response accuracy. Investigate missing captures and unmatched dependency calls before treating the snapshot as suitable for unattended regression testing. A passing response comparison can still hide external side effects.

## Configure and verify PII redaction

Traffic can contain sensitive data in headers and bodies, including credentials. Speedscale supports redaction through configured DLP rules. [Apply rules to the source forwarder](https://docs.speedscale.com/guides/dlp/applying-rules/) so the selected fields are redacted before traffic leaves your network. Test the rules in a development environment and inspect their output before approving production capture.

Redaction coverage depends on the rules and their scope. Review nested fields, free-text payloads, and application-specific formats rather than assuming a default detector finds everything. Check request and response data. Maintain consistency where identifiers must match across a sequence of requests.

A transform applied only during replay doesn’t remove sensitive data that was already exported or stored. Decide what may be collected, who may access snapshots, and how long recordings may be retained. Verify that decision against the actual captured output. Redaction and a security certification don’t automatically establish compliance for your organization’s use of production data.

Redaction also doesn’t prevent a database write or an API transaction. Dependency isolation needs its own configuration and verification.

## Other Kubernetes traffic mirroring options

### AWS VPC Traffic Mirroring

[AWS VPC Traffic Mirroring](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html) copies network traffic from supported network interfaces to a monitoring target. It is useful for network inspection and security analysis. It operates at a different layer from Istio’s request duplication or Speedscale’s application replay.

A packet copy doesn’t by itself issue an HTTP request to a test pod, compare application responses, or create dependency mocks. To build application regression testing from that feed, you need additional processing and replay tooling. Check AWS’s source and target requirements for your deployment.

### Gateway shadowing with Emissary-ingress

Emissary-ingress, from the Ambassador project, supports [traffic shadowing](https://emissary-ingress.dev/docs/3.10/topics/using/shadowing/). In its documented 3.10 configuration, a separate `Mapping` with `shadow: true` sends duplicate requests to a shadow service. The shadow response is discarded.

This is useful when the gateway already handles the traffic you want to copy. The shadow service still needs isolated dependencies, and response comparison needs separate tooling. As with Istio, you end up with copied requests, not a saved regression suite.

## Choose a starting point

Use Istio mirroring when you need to observe a second deployment against current requests and already have a controlled shadow environment. Use capture and replay when you need to preserve scenarios, rerun them against successive builds, and configure recorded dependency mocks.

For an evaluation, start with one service and a short snapshot in a development environment. Verify capture coverage and redaction, establish the dependency boundary, then compare repeated runs against the same build before introducing a change. The [replay tutorial](https://speedscale.com/blog/traffic-replay-tutorial/) and the [product tutorial](https://docs.speedscale.com/getting-started/tutorial/) walk through the workflow, and [`proxymock`](https://speedscale.com/proxymock/) lets you try recording and mocking locally; [book a demo](https://speedscale.com/demo/) to work through your service’s isolation requirements with us.

## Table of Contents

## See Speedscale in action

Book a 30-minute demo to see how Speedscale handles your specific stack — microservices, Kubernetes, or legacy Java services.

[Book a demo](https://speedscale.com/company/demo/) [Start free trial](https://app.speedscale.com/signup)