The Challenge: Capturing all traffic in cloud lab environments
One of our customers builds security software that analyzes network traffic in real time. To demonstrate and train users on their product effectively, their hands-on lab environments need access to all traffic flowing through the environment — not just packets addressed to a single machine.
On-premises, you can easily mirror traffic using a SPAN port and a NIC in promiscuous mode. But in the cloud, that’s not possible. You can’t just flip a flag and start listening to everything. Instead, cloud providers implement traffic mirroring by requiring you to manually define mirror sessions for each network source, eg AWS VPC Traffic Mirroring. That works fine for static environments, and there are even scripts to automate mirroring for known, long-lived targets.
But our customers don’t operate that way. They need dynamic labs that spin up and tear down on demand, each with its own architecture, topology, and inspection tools. We can’t assume fixed infrastructure, and we certainly can’t ask users to manage traffic mirroring by hand. It gets especially tricky when the mirroring target itself is dynamic, such as a disposable VM inside the same lab.
The business impact is clear. Without built-in traffic mirroring, training teams are limited in what they can teach — they can’t show how their product responds to real network traffic. With it, they can deliver richer, more effective labs that reflect real-world usage. For Sales Engineers, it means demonstrating full product value with live traffic, not canned scenarios.
The orchestration problem: Making cloud traffic mirroring just work
The core challenge was orchestration and abstraction.
AWS Traffic Mirroring isn’t hard to configure manually, if you know your subnets, ENI IDs, filter rules, and the destination interface. But our hands-on lab environments for training and demos are created dynamically. Customers can define whatever architecture they want, including multi-subnet environments that simulate real-world corporate networks, with different segments like public, private, and DMZ zones. VMs come and go. IPs are ephemeral. There’s no single topology to code against.
Every feature that we develop needs to support our multi-tenant SaaS platform. Our solution also needed to work across different deployment contexts, including environments launched into our own cloud accounts, customer-provided BYO cloud accounts, and disposable sandbox cloud accounts for short-term access.
We needed a solution that:
- Detects when a mirroring appliance is present in a lab.
- Identifies all other instances in that lab as potential traffic sources.
- Creates mirror sessions dynamically between source ENIs and the inspection target.
- Handles teardown gracefully when environments are deleted.
- Works across any network topology, even ones we haven’t seen yet.
And most importantly: it had to be invisible to the user. Just a toggle. No AWS console, and certainly no coding required.
Many of our customers are training managers or enablement teams who don’t have easy access to technical engineering resources. They can’t build out custom CloudFormation or Terraform modules just to make traffic mirroring work. They rely on us to provide a simple, reliable, and scalable solution that works out of the box in any environment, with minimal configuration and zero infrastructure expertise required.
How we solved it: Automating traffic mirroring with cloud events
We started with a common pattern in AWS automation: use event-driven Lambda functions.
Here’s the flow we built:
- The customer sets a flag in the environment template to indicate that a VM is a traffic inspection appliance (the mirror target).
- When the lab is launched, our backend listens for EC2 instance launch events via CloudWatch.
- When a new instance is created:
- We check its metadata to see if it’s marked as the mirror target.
- If so, we tag it accordingly and store its ENI as the destination.
- If it’s a regular instance in the same lab, we store its ENI as a source.
- Once the environment is fully launched, we orchestrate:
- A traffic mirror target on the destination ENI.
- Mirror sessions for each source ENI pointing to that target.
- Traffic filters allowing all packets (customizable later if needed).
- All of this happens within the context of the ephemeral environment, no shared state, no overlap, no manual wiring.
When the lab is torn down, the same automation removes the mirror sessions and targets to avoid resource sprawl.
From a customer’s perspective? It’s a single setting: “Enable traffic mirroring.” From our side? It’s a dynamic, zero-touch AWS network orchestration pipeline.
Why this matters for Training & Sales
For Technical Training
Without traffic mirroring, labs often rely on remote packet capture, forwarding scripts, or static datasets. These workarounds are fragile, inconsistent, and require ongoing engineering support. They don’t reflect how the product behaves in a real environment, which limits student understanding.
With Heropa’s traffic mirroring support:
Consistent lab experience: Every student lab is launched with mirrored traffic already flowing to the product. No manual setup is required. Labs work the same every time, at any scale.
Deeper engagement: Students interact with real network traffic. They trigger detections, build dashboards, and investigate incidents as they would in production.
Fully self-service: Training programs can run across time zones and teams without depending on live instructors or backend engineers to wire up each session.
Lower operating costs: Labs only consume resources while they are active. Shutdown automation and lifecycle policies reduce unnecessary cloud spend.
For Sales and Demos
Authentic product experience: Prospects can see the product in action, analyzing live traffic instead of canned examples or pre-filled alerts.
Rapid demo setup: Sales Engineers can launch fully functional labs in minutes, with mirrored traffic already configured.
Faster adoption: Partners and buyers gain confidence by using the product in realistic, dynamic conditions that reflect real-world usage.
Broader lessons: good abstractions make complex tech disappear
What started as a specific request, “Can we sniff all traffic in our hands-on training labs?”, became a broader lesson in platform design:
- Cloud primitives are powerful, but not user-friendly. Features like VPC Traffic Mirroring are great, if you’re an AWS architect. Most users don’t want to become one.
- You can’t predict topology, so embrace dynamism. Instead of trying to support N fixed architectures, we built a system that adapts to any lab shape.
- Event-driven infrastructure works beautifully for ephemeral systems. Using AWS events to react to instance lifecycle changes let us stay lean, fast, and responsive.
Great abstractions don’t just simplify technology, they unlock business value. By making complex orchestration invisible, we’ve turned a technical roadblock into a strategic advantage for training and sales teams.
Want to learn more?
With our Virtual IT labs for traffic mirroring, we’ve made the hard parts invisible so your team, or your prospects, can focus on what matters: Seeing your product in action.
If you’re building or selling network-aware software such as NDR, network observability, or packet inspection and want to see how to showcase how your product behaves in a real cloud environment with mirrored traffic and zero setup, let’s talk.
