AWS VPC Traffic Mirroring | Overview.

AWS VPC Traffic Mirroring - Overview.

Scope:

• Intro,
• Core Concepts,
• Mirror Source,
• Mirror Target,
• Mirror Filters,
• Mirror Sessions,
• Packet Flow Internals,
• Mirroring Overhead & Performance,
• Traffic Mirroring vs VPC Flow Logs vs PCAP on instances,
• Real-World Enterprise Architectures,
• Advanced Topics,
• Security & Compliance Insights,
• Common Pitfalls & Anti-Patterns,
• Best Practices.

Intro:

• VPC Traffic Mirroring is AWS’s native capability to copy network traffic (Layer-3 packets) from an Elastic Network Interface (ENI) and send to a monitoring or inspection target.
• VPC Traffic Mirroring is a cloud-equivalent to SPAN/RSPAN/ERSPAN in physical networks.
• twtech uses VPC Traffic Mirroring to capture and inspect network traffic in its VPC.
• It is an integral part of monitoring, observability & troubleshooting for network traffic (Layer-3 packets)

1. Core Concepts

1.1 Mirror Source

• A mirror source is any ENI attached to:
• EC2 instance
• Nitro-based ENIs (required for source)
• ENIs on AWS services (e.g., Nitro-based services like AWS EKS EC2 nodes)

What is actually captured:

• Ingress traffic: packets entering the ENI before security group evaluation
• Egress traffic: packets leaving the ENI after security group evaluation
• Includes dropped packets (due to SGs/NACLs) on ingress
• Does not include VPC Flow Logs metadata—this is raw packet data

NB:

• Traffic Mirroring operates at the ENI driver layer inside the Nitro hypervisor. 
• There is no guest OS involvement.
•  which means mirrored packets:
• Are not constrained by instance CPU
• Cannot be filtered inside the instance
• Bypass iptables/nftables visibility
• Can reveal traffic before encryption at OS level (important for threat hunting)

1.2 Mirror Target

Targets can be:

• ENI Target → Sends traffic to another EC2 instance
• NLB Target → Mirrors packets to a Network Load Balancer
• GWLB Target → Sends to Gateway Load Balancer for distributed appliances

Why GWLB is often the enterprise choice:

• Centralized ingestion
• Auto scaling of inspection appliances
• Deep packet inspection (IDS/IPS)
• Vendor appliances (Palo Alto, FireEye, Fortinet, etc.)

1.3 Mirror Filters

• Filters are stateless packet filter rules applied before mirroring:
• source-cidr
• destination-cidr
• protocol
• port ranges (TCP/UDP)

They act like packet classification engines so you can mirror only:

• East–west traffic
• Specific subnets
• Only suspicious port ranges
• Only inbound/outbound
• Filtering occurs on the Hypervisor → negligible impact on instance performance.

1.4 Mirror Sessions

A mirror session binds:

• Source ENI
• Target
• Filter
• Session Number (1–32766, acts like priority)

twtech can have multiple sessions per ENI (e.g., different filters or different tools).

2. Packet Flow Internals

• Let’s trace what happens to a real packet.

Ingress Packet Path (From outside → ENI)

AWS Network → VPC Router → Subnet Route Table → ENI (mirror tap) → SGs/NACL → Instance

• Traffic Mirroring captures the packet at the ENI before SG checks.

This means:

• twtech can see packets that SGs block,
• twtech can capture scans, probes, and network attempts before the OS stack sees them.

Egress Packet Path (From instance → ENI → out)

Instance → SG evaluation → ENI (mirror tap) → VPC Router → Destination

• Mirroring captures the packet after SG evaluation.

3. Mirroring Overhead & Performance

• AWS offloads mirroring to the Nitro Card, allowing near-zero impact on:
• CPU
• Memory
• ENA driver

But there are limits to consider.

Latency impact:

• Mirroring itself does NOT affect source traffic
• However, heavy mirroring → throttling at the ENI

Mirror session limits:

• Max 3 mirror sessions per ENI (recommended max 1–2)

Bandwidth caps:

• Mirrored traffic is capped by the source ENI’s bandwidth, not instance network throughput.

For example:

• c5.large ENI bandwidth ~ up to 10Gbps
• m5n.24xlarge ENI bandwidth ~ up to 100Gbps
• Mirror traffic counts separately from instance traffic but is capped by the ENI hardware.

Packet Loss:

• If mirror bandwidth exceeds ENI capacity → mirror packets are dropped, not source packets.

4. Traffic Mirroring vs VPC Flow Logs vs PCAP on instances

Feature	Traffic Mirroring	VPC Flow Logs	tcpdump / Suricata
Packet payload	✔ Full	✖ No payload	✔ Full
Layer visibility	L3–L7	L3 metadata	L3–L7
Impact on instance	None	None	High
Real-time	Yes	No (batch)	Yes
Useful for security	IDS/IPS, malware, lateral movement	Audit, billing	Deep forensics

• Mirroring is the only method for cloud-native real-time packet-level analysis.

5. Real-World Enterprise Architectures

5.1 Centralized IDS/IPS with GWLB

ENI sources → Mirror sessions → GWLB Target → Inspection Fleet → S3/ES/SIEM

Use when:

• Want NIDS/NIPS (Snort, Suricata, Palo Alto)
• Multi-VPC or multi-account architecture
• Auto-scaling inspection layer needed

5.2 Lightweight Logging using ENI → EC2 Packet Collector

Simple:

• Mirror to a small packet capture instance
• Run Suricata in IDS mode
• Forward alerts to SIEM (Splunk/Elastic)

5.3 Traffic Mirroring across multi-account

This is tricky because:

• Traffic Mirroring does not support cross-account ENI-to-ENI mirroring
•  But GWLB support cross-account service insertion

Pattern:

Spoke Account: Mirror → GWLB endpoint  

Hub Account: GWLB → NIDS appliance → SIEM  

6. Advanced Topics

6.1 Mirroring Encrypted Traffic

Important detail:

• Traffic Mirroring captures packets as they appear on the ENI, not inside the OS.

So:

• TLS-encrypted app-level traffic is still encrypted
• But OS-level encryption (IPsec/VPN) may be visible pre-encryption depending on which interface is mirrored

NB:

• Mirroring is typically done on the primary ENI → meaning twtech sees packets before OS encryption or after OS decryption?
• ✔ No → the ENI sees traffic after OS has already encrypted outgoing packets
• ✔ Yes → the ENI sees incoming packets before OS decrypts
  

Bottom line:

• L7 visibility depends on encryption model.

6.2 Mirrored Traffic Format – ERSPAN-like Encapsulation

• AWS encapsulates mirrored packets in an Amazon-internal VXLAN-like wrapper:
• Added metadata (source ENI, timestamps, session ID)
• Delivered to the target
• Decapsulated by monitoring tools or via ENA driver
• Tools must support AWS mirroring encapsulation.

6.3 Multi-VPC scaling

At scale:

• Use AWS Organizations + SCPs
• Delegate GWLB across accounts
• Use a shared security VPC

7. Security & Compliance Insights

• Traffic Mirroring can expose sensitive packet contents, so:
• Lock down IAM roles
• Use encryption (TLS) between mirrored source → collector
• Restrict access to pcap logs
• Rotate and age out packet captures
• Apply strict segmentation for inspection appliances

8. Common Pitfalls & Anti-Patterns

Mistake	Why it’s bad
Mirroring 100Gbps of traffic to a single EC2 instance	Causes packet drops
Using NLB as target for L7 analysis	NLB does not preserve packet ordering
Mirroring entire VPC	Wasteful; filter at source
Running Suricata on the mirrored instance without enough CPU	Causes backpressure
Mirroring encrypted traffic expecting L7 visibility	twtech will only see ciphertext

9. Best Practices

Filtering first → mirroring second

• Mirror only what matters.

Use GWLB for real-scale deployments

• Allows horizontal scaling.

Use dedicated inspection VPC

• Network isolation and IAM boundary.

Enable structured telemetry

• Send alerts to SIEM
• Correlate with Flow Logs

Tag twtech mirror sessions

• For lifecycle management.