Let me start by saying I'm not surprised. I've seen this pattern before with every vendor that promises magical "zero trust" and "full inspection" without showing you the bill for the computational tax. My team inherited a Cato deployment after a "modernization" initiative that replaced a simple IPSec tunnel mesh with what feels like an entire security orchestra inspecting every packet.
The specific pain point is the TLS decryption overhead. We enabled it for outbound traffic to a subset of financial and high-risk SaaS applications. The architecture documents promised "negligible impact" and "scale on demand." Reality, as usual, is more interesting. Our egress proxies, which are just Cato's Sockets on decent EC2 instances (c5.2xlarge), are now consistently hitting 70-80% CPU utilization during business hours, specifically when the TLS inspection rules are active. The latency add isn't trivial either—we're seeing an additional 8-12ms on average for decrypted flows versus passthrough.
I've tried the usual suspects:
* Confirmed we're using the latest Socket version.
* Tuned the rule set to be as specific as possible, avoiding blanket decryption policies.
* Played with the cipher suites, though Cato doesn't give you a huge amount of control here.
The vendor's response is, predictably, to vertically scale the Socket instance or add more Sockets for load distribution. This feels like being told to buy a faster car because your trunk is inefficiently packed. Before I go down that road (and justify a 30% increase in our monthly commitment), I want to see if anyone else has done proper benchmarking.
My questions are concrete:
* Has anyone measured the actual packets-per-second or concurrent connection limits for a given Socket size with TLS decryption enabled versus disabled? I can share my rudimentary `iperf3` and custom Go client test results if there's interest.
* Are there any known bottlenecks with specific cipher suites (e.g., ChaCha20-Poly1305 vs AES-GCM) that hit the CPU harder on their software stack?
* Does distributing Sockets across more, smaller instances actually improve total throughput for this workload, or does the overhead of state synchronization eat the gains?
I'm particularly skeptical of the "just scale up" mantra. The cost curve for this should be linear, not a step function that requires a new support tier. If the architecture can't handle deep inspection at line rate for a modest 1 Gbps egress without demanding premium compute, then we might as well go back to a simpler model: plain old tunnels to a next-gen firewall cluster we actually control, and let the cloud vendor's WAF handle the SaaS stuff.
Attached is a sanitized snippet of our CloudWatch metrics for the Socket CPU. The correlation with TLS handshake spikes is unmistakable.
```json
{
"Metrics": [
{
"MetricName": "CPUUtilization",
"Dimensions": [{"Name": "InstanceId", "Value": "i-xxxx"}],
"Values": "[72.5, 68.3, 77.1, 80.4, 65.2]",
"Timestamps": ["2023-10-26T09:00:00Z", "2023-10-26T10:00:00Z", "2023-10-26T11:00:00Z", "2023-10-26T12:00:00Z", "2023-10-26T13:00:00Z"]
}
]
}
```
keep it simple