Help: Nitro Enclave vsock throughput drops dramatically under agent load

Fatima Al-Rashid · 2026-06-22T14:07:07Z

I am conducting a series of performance evaluations for an agent runtime designed to operate within AWS Nitro Enclaves, with the primary goal of enforcing ephemeral data processing. The architecture is predicated on a strict separation between the untrusted parent instance (handling I/O and orchestration) and the enclave (handling sensitive computation). Communication is, of course, facilitated via vsock. The initial baseline throughput tests for the vsock channel, using simple echo patterns and `socat` for validation, yielded acceptable results—approximately 850 Mbps bidirectional transfer. However, upon deploying the actual agent workload, which involves a more complex exchange of structured data (serialized protocol buffers containing database query fragments and masked result sets), the throughput has collapsed to a nearly unusable 22 Mbps. This degradation is severe enough to question the viability of the enclave for any real-time analytical agent tasks. The agent runtime within the enclave is written in Go and performs the following primary operations: * Parsing incoming serialized messages. * Executing in-memory data masking and transformation routines on payloads (deliberately avoiding any persistent storage). * Formatting and serializing response messages. * The parent instance, also in Go, handles the network-facing side and the vsock client. I have instrumented the code and observed the following: * CPU utilization within the enclave remains surprisingly low (~15%). * There is no significant locking or channel contention in the Go code profiler. * The vsock connection is persistent for the duration of the session. * The message sizes are relatively consistent, averaging around 8KB per request/response cycle. My current enclave allocation configuration is: ```yaml MemoryMiB: 4096 CPUCount: 4 ``` I have already attempted the following mitigations, with negligible impact: * Increasing the enclave memory allocation to 8192 MiB. * Adjusting the `vsock` read/write buffer sizes in the Go code. * Testing with a simpler, raw byte payload to rule out serialization overhead as the sole culprit. This suggests a systemic interaction between the vsock driver, the Nitro hypervisor, and the scheduling of the enclave's vCPUs under a sustained, bidirectional load pattern. The dramatic disparity between synthetic and application-level throughput points to a fundamental bottleneck that only manifests under real workload conditions. My specific questions to the community are: * Has anyone observed similar performance cliffs with Nitro Enclaves when moving from benchmarks to actual multi-step agent workloads? * Are there known tuning parameters for the parent instance's kernel (`vsock` module parameters) or the enclave allocation that directly impact sustained throughput? * Could the root cause be related to the way the Nitro security model enforces memory encryption and isolation for every page access, thus penalizing the frequent, small I/O patterns characteristic of agent communication? If so, is batching at the application layer the only viable workaround, even if it increases latency for the first byte? I am particularly concerned because if the secure channel cannot sustain moderate data velocity, the entire premise of using enclaves for dynamic, ephemeral agent processing—where state must be frequently synchronized or validated—becomes untenable. We may be forced to reconsider our platform choice, perhaps toward a model with less isolation but predictable performance, which is a deeply unsatisfactory trade-off from a security perspective.

Summarize Topic

Page 2 / 2 Prev

TEE Platform Comparison for Agent Workloads

Last Post by Tomás G. 6 days ago

16 Posts

16 Users

0 Reactions

14 Views

RSS

Tomás G.

(@newbie_with_agent)

Active Member

Joined: 1 week ago

Posts: 12

Translate ▼

June 24, 2026 11:15 am

Yeah, that "real-time" point is something I'm wrestling with. My agent processes sensor data, and I naively assumed per-record processing was needed for quick reactions. But you're making me question if that's just my design reflex.

So if I'm waiting for a response after each write, I'm essentially paying the VM exit tax twice per record? Once for the request and once for the reply? That feels brutal.

Is there a rule of thumb for when you should switch from a request-response pattern over vsock to just streaming? Like, latency under X ms means you eat the tax, over X means you redesign?

ReplyQuote

Page 2 / 2 Prev

80 Forums
1,186 Topics
7,228 Posts
0 Online
508 Members

Forum Icons: Forum contains no unread posts Forum contains unread posts

Topic Icons: Not Replied Replied Active Hot Sticky Unapproved Solved Private Closed