When people talk about surviving a connection flood, the conversation usually jumps straight to rate limiting and network-layer mitigation. Those matter, but they don't explain why two services under the exact same flood, same packet rate, same source distribution, can show wildly different CPU graphs. That difference comes down to a decision made long before the flood ever starts: how the listener itself is architected to handle concurrent connections.

This matters directly to SREs and cloud architects because CPU footprint under load determines your autoscaling behavior, your bin-packing density, and ultimately your infrastructure cost during exactly the kind of event you can't schedule around.

1. How synchronous blocking engines spend kernel CPU

Synchronous, thread-per-connection listeners spend rising kernel CPU on context-switching as connection count grows, independent of how much real traffic those connections carry. A synchronous, thread-per-connection (or process-per-connection) architecture handles concurrency by handing each incoming connection its own thread, which then blocks on I/O until that connection has data to process. This model is simple to reason about, but it has a structural cost that only becomes visible under load: every thread the kernel schedules carries real overhead, independent of whether that thread is doing useful work.

• Context switching dominates under high concurrency. Once thread count climbs into the thousands, the kernel spends a growing share of every CPU cycle just deciding which thread runs next, rather than executing application code. This overhead scales with connection count, not with actual traffic volume.

• Each thread carries a fixed memory and scheduling cost. A blocked thread waiting on a slow or intentionally slow-drip connection, exactly what a flood does, still occupies a kernel scheduling slot and its full stack allocation, even while doing nothing.

• Lock contention compounds under pressure. Many synchronous frameworks serialize access to shared state, connection pools, logging buffers, rate-limit counters, behind a lock. As thread count rises, contention on that lock rises with it, and CPU that should be doing I/O work goes into spinning or waiting on the lock instead.

The practical result: CPU usage under a synchronous architecture rises non-linearly as connection count increases, because each additional connection adds fixed kernel-level overhead on top of whatever actual work it represents. A flood of mostly-idle, slow-drip connections, the kind a botnet is cheap to generate, is close to a worst case for this model, since it maximizes thread count while minimizing actual useful throughput per thread.

A useful diagnostic: if CPU usage during an incident tracks connection count more closely than it tracks request throughput, that's a strong sign the bottleneck is architectural, kernel scheduling and context-switch overhead, rather than application logic actually working harder.

2. How async event loops absorb the same flood

Async event-loop architectures decouple CPU cost from connection count, since a small fixed pool of threads multiplexes across thousands of connections via non-blocking I/O. An asynchronous, event-loop-based architecture handles concurrency differently: a small, fixed number of OS threads, often just one per CPU core, cooperatively multiplexes across thousands of connections using non-blocking I/O and an event notification mechanism like epoll on Linux.

• Connection count no longer drives thread count. Whether the event loop is juggling 100 connections or 100,000, it's still running on the same small, fixed set of OS threads, so the kernel-level context-switching cost that scales with connection count in the synchronous model simply doesn't apply here.

• Idle connections cost almost nothing. A connection with no data to process just sits in the kernel's I/O readiness table until it has something to report. It doesn't hold a thread, a stack, or a scheduling slot the way a blocked synchronous thread does.

• CPU usage tracks actual work, not connection count. Because the event loop only spends cycles on connections that have real I/O ready to process, CPU usage under an async architecture scales much more closely with actual request throughput than with the raw number of open connections.

This is precisely why a slow-drip flood, designed to maximize open connection count while minimizing real work per connection, is far less effective against an async architecture: the attack's core mechanism, exhausting per-connection kernel resources, doesn't have the same leverage when connections aren't consuming dedicated threads in the first place.

3. What this means for container CPU footprints specifically

A synchronous listener's container CPU limit must be sized for worst-case connection count, while an async listener's CPU footprint stays close to its normal-load baseline even under a flood. In a containerized environment, this architectural difference has a direct, measurable cost implication. A container running a synchronous, thread-per-connection listener needs its CPU limit sized for worst-case concurrent connection count, not average throughput, because that's what drives its actual CPU consumption under load. Undersize it, and a flood causes CPU throttling that degrades every other workload sharing that node; oversize it defensively, and you're paying for headroom that sits idle outside of incident windows.

An async architecture decouples those two numbers. Its CPU footprint under a connection flood stays much closer to its footprint under normal load, because the mechanism driving synchronous CPU spikes, kernel scheduling overhead scaling with thread count, isn't in play. This makes capacity planning materially simpler: you size for expected request throughput, not for a worst-case connection count that a botnet can generate for free.

4. Operational signals worth tracking

A synchronous listener's CPU usage tracks connection count under a flood, while an async listener's CPU usage stays tied to actual request throughput.

• Ratio of open connections to CPU usage. A synchronous listener will show this ratio climbing during a flood; an async one should stay comparatively flat, since connection count and CPU cost are decoupled by design.

• Kernel context-switch rate (visible via vmstat or /proc/stat on the host) during a suspected flood. A sharp rise here, disproportionate to actual request volume, points directly at thread-per-connection overhead rather than application-layer load.

• Container throttling events correlated with connection count rather than request rate. If your orchestrator's CPU throttling metric spikes in lockstep with concurrent connections rather than requests per second, the listener architecture is very likely the root cause, not insufficient CPU limits.

• Thread count inside the container during an incident. A synchronous architecture will show thread count scaling directly with connection count; an async one will show a flat, small thread count regardless of load.

This same asymmetry is what makes a lightweight async decoy service a useful tool for absorbing and studying flood traffic directly: because it doesn't spend a thread per connection, it can safely accept far more concurrent flood traffic on the same CPU footprint as a normal service, generating detailed telemetry on the attack instead of falling over from it. This is the same architectural principle Echidra OSS is built on.

The floods this architecture absorbs most often originate from the same botnet infrastructure covered in Analyzing SSH Brute-Force Patterns, the credential-spraying stage there and the connection-flood stage here are frequently run from overlapping pools of compromised hosts.

See it in action

We ran a live SYN flood against a deployed Echidra OSS honeypot and measured what actually happened to its CPU and memory in real time.

https://www.youtube.com/watch?v=7fJcO2ziX-4

Result: CPU usage rose by only 0.4% during the flood, and memory (RSS) stayed below its pre-flood baseline throughout. No container restarts, no degraded response times.

See Deception-Based Detection in Action

Echidra OSS is an open-source cyber deception engine (AGPLv3). Deploy a lightweight decoy alongside your real infrastructure and map unauthorized access attempts to MITRE ATT&CK in real time.

• Lightweight: 83MB RAM floor vs 180MB for legacy honeypots.

• Scales cleanly: <20% CPU under a 5,000-packet flood.

View the Deployment Guide · Star it on GitHub

Most honeypot evaluations compare feature checklists: protocol coverage, decoy realism, alerting integrations. Those details matter, but they skip the variable that actually decides whether a deception layer survives contact with the internet. That variable is simple: what happens to the listener process when a hundred connections arrive in the same second.

This isn't a hypothetical. Mass-scanning botnets, credential-stuffing swarms, and internet-wide research crawlers such as Shodan and Censys don't trickle in. They arrive in bursts. A deception system that can't absorb a burst doesn't fail gracefully. It drops connections, skips logging, or pins a CPU core, and that's precisely the moment you lose the session data the honeypot was deployed to capture.

We built EchidraOSS around that failure mode instead of treating it as an afterthought. This post breaks down why the dominant architectures in the honeypot space, including Cowrie's Twisted reactor, Thinkst Canary's managed appliance model, and the raw Twisted or socket listeners teams often build themselves, hit a concurrency ceiling. Then it covers what EchidraOSS does differently at the architecture level.

1. Asynchronous concurrency: the event loop is the whole story

Cowrie is built on Twisted's reactor pattern, an event-driven model that predates asyncio by over a decade. In practice, Twisted-based listeners accumulate per-connection state and callback chains that get expensive to schedule as connection count climbs. The reactor is single-threaded, so a burst of new SSH negotiations competes for the same loop turn as everything already in flight. Generic, self-built Twisted or raw-socket listeners inherit the same ceiling, usually a lower one, since they lack Cowrie's years of incremental tuning.

Thinkst Canary sidesteps the software problem by shipping a managed appliance. It solves concurrency by dedicating hardware or a locked-down VM to the problem, not by fixing the underlying model. That approach works, and it's also why Canary is priced and deployed as infrastructure rather than as software you drop into an existing box.

EchidraOSS's listeners and API run on Python 3.11+ with FastAPI's async event loop. Every connection handler is a coroutine, not a thread and not a blocking socket read. When a scanning bot opens fifty SSH connections in the same second, those connections don't queue behind each other waiting for a reactor tick to free up. They're all suspended on I/O at once, and the loop services whichever one has data ready, in the order the operating system delivers it. There's no thread-per-connection overhead, no GIL contention from spawning worker threads, and no context-switch cost that scales linearly with load.

The practical effect: connection spikes and automated bot floods move CPU utilization in small, bounded steps. There's no sawtooth spike, because the listener isn't fighting its own scheduler for cycles.

Fig. 1: CPU utilization over time under a simulated connection flood, thread-per-connection versus async event loop.

2. Low memory footprint: deployable on a $4 a month VPS

Concurrency headroom only helps if it doesn't cost you a fleet of memory. This is where Cowrie's process model and self-built Twisted listeners tend to sprawl. Every open session carries its own buffered state and protocol objects, and Cowrie specifically adds a simulated filesystem context per connection. That overhead adds up fast once you're running SSH, HTTP, FTP, and Telnet decoys side by side.

EchidraOSS keeps its footprint down through modular service design. Listeners, the classification engine, and the dashboard API are separable processes that share a single PostgreSQL instance instead of each maintaining redundant in-memory state. Session objects are short-lived: they exist as coroutine-local state for the duration of the connection, get classified, get written to Postgres, and are released. Nothing accumulates in a long-running process heap over the life of the deployment.

That design is exactly why the reference deployment path (see the Setup and Onboarding guide) runs comfortably as a single Docker Compose stack, honeypot listeners, dashboard API, and PostgreSQL together, on a 1 vCPU, 1GB RAM instance that costs about $4 a month from any major cloud provider. You're not provisioning for a worst-case memory ceiling that never gets hit. The architecture doesn't have one to provision for.

Fig. 2: RAM usage of the full stack, legacy Twisted/threaded honeypots versus EchidraOSS's FastAPI async stack.

3. Real-time log classification: no post-processing pipeline required

This is the gap that matters most once you're running one of these tools in production. Cowrie, generic Twisted listeners, and most self-built setups write unstructured text logs, whether that's JSON lines or flat text, with no semantic layer on top. Turning "attacker ran cat /etc/passwd, then downloaded a binary with wget" into "this was a credential-harvesting attempt followed by second-stage payload retrieval, MITRE T1552 and T1105" is left entirely to you: a Logstash pipeline, a Splunk query, or a homegrown script that somebody has to maintain and retune every time attacker tooling shifts. Thinkst Canary does better here with its own hosted console, but the classification logic is closed. You get an alert, not an inspectable rule trail.

EchidraOSS classifies sessions natively, at capture time, using a deterministic rule engine. It's not an LLM call and not a black box. Every closed session runs through classification rules that assign an actor label (for example, brute_force_bot), an intent such as reconnaissance, credential theft, or persistence, a risk score from 0 to 100, and one or more MITRE ATT&CK technique IDs, all before the session reaches a dashboard query. Because the rules are deterministic pattern matches over observed command and request behavior rather than a model inference call, classification resolves in the sub-millisecond range per session. There's no network round trip, no queueing on an inference server, and no variance from a probabilistic model changing its answer between runs.

The downstream result is what the Console Guide calls Intelligence. Instead of a flat firehose of logs, recurring actor-and-technique pairs get grouped into issues with evidence, a recommended fix, and an impact summary, pulled from the same built-in playbook that generated the classification. The reasoning behind every flag stays inspectable, not a mystery.

Fig. 3: The Intelligence view grouping recurring sessions into issues by actor and MITRE ATT&CK technique.

Head-to-head: architecture

The table below reflects the structural properties of each project's public architecture, plus EchidraOSS's own internal load testing on a reference 1 vCPU, 1GB VPS. Treat the figures as directional. The point isn't the third decimal place. It's the order of magnitude, and the order of magnitude comes directly from the concurrency model, not from tuning.

Methodology note: EchidraOSS figures come from Qyleron's own internal load testing described above. Cowrie and Thinkst Canary figures are drawn from each project's public documentation and community-reported deployment experience, not from independent lab testing we ran ourselves. Treat them as representative, not as a controlled benchmark.

Why this is an architecture problem, not a tuning problem

You can add more RAM to Cowrie, move Canary to a larger tier, or hand-tune a Twisted reactor's thread pool. None of that changes the underlying model. You'd be compensating for blocking I/O and unstructured logging with infrastructure spend instead of fixing what's actually blocking. EchidraOSS's advantage isn't a set of tuning flags. The async event loop and the deterministic classifier are load-bearing parts of the design from the first connection handler onward. There's no fast path that degrades to a slow path under load. The async model is the path.

That's also why the comparison holds up on cheap hardware. A honeypot that only performs well on generously provisioned infrastructure isn't solving the deployment problem most teams actually have: running deception at the edges of their network, cheaply, in enough places that coverage is real instead of symbolic.

📦 Run it yourself

EchidraOSS is open-source under AGPLv3. Clone it, point it at a $4/month VPS, and watch the classification engine work in real time.

👉 Clone the GitHub Repository