KMS is a shared service. You are in a noisy neighbor environment. Your p99 latency is at the mercy of Amazon's load balancers.
In a volatility spike, 130ms is an eternity.
Every signing event is an HTTPS REST API call. This means: TCP Handshake + TLS Handshake + HTTP Header Parsing + JSON Serialization. This "userland" overhead is exactly what ZeroCopy's kernel bypass eliminates.
As a shared service, KMS performance fluctuates based on global AWS load. You have zero control over this variance. During high-demand periods (e.g., Black Friday, market crashes), your latency spikes. This is the "noisy neighbor" problem.
AWS KMS keys are region-specific. Multi-Region keys exist but are purely for disaster recovery replication, not simultaneous low-latency global signing. If you need to sign in Tokyo and New York simultaneously, you're managing two key sets.
No shared resources. You own the core. We use isolcpus + nohz_full to pin signing threads to specific physical cores and silence the OS scheduler.
Signing happens in-memory via AF_XDP. Our binaries are PGO-optimized, eliminating branch mispredictions and userland overhead. Just pure assembly-level execution.
Dedicated support for Solana Vote/Identity keys with PCR0-sealed isolation. AWS KMS cannot match the deterministic latency required for high-frequency voting.
Deploy ZeroCopy instances in any region with independent key management. Or use a single globally-accessible Enclave with encrypted Vsock tunnels.
AWS KMS charges per API request. At $0.03 per 10,000 requests, it seems "cheap."
But the real cost is opportunity cost. If KMS's 130ms latency causes you to miss 10% of profitable trades on a $100M target profit, you're losing:
You saved $500 on API fees. You lost $10M in execution quality.
This is the definition of "Penny wise, pound foolish."
AWS KMS is fine for storing credentials or encrypting S3 buckets.
It is not built for AI agents.
Our enclave signs transactions continuously. Every proof is cryptographically attested and publicly verifiable in real time.