Estimate the latency and CPU cost added by enabling mutual TLS between services.
mTLS cost has two components: a one-time handshake cost paid only by new connections, and a small per-request encryption cost paid on every request regardless of connection age: avg_latency = handshake_overhead_ms × (1 − reuse_rate) + per_request_encryption_us ÷ 1000. Connection reuse is the dominant lever for amortizing handshake cost — at a 95% reuse rate, only 1 in 20 requests pays the full handshake penalty, while all requests pay the much smaller steady-state encryption cost.
handshake_overhead_ms = handshakes_per_sec × handshake_duration_ms / connections_reused
The TLS handshake (asymmetric crypto, certificate exchange) is orders of magnitude more expensive than the symmetric encryption used once a session is established — amortizing that one-time cost across many requests on a reused connection is the single biggest mTLS performance lever.
Modern CPUs with AES-NI hardware acceleration can encrypt/decrypt payloads with very low overhead — often tens of microseconds per request for typical payload sizes — making steady-state encryption cost much smaller than handshake cost per new connection.
Short-lived connections (e.g. from serverless functions, connection pool churn, or aggressive idle timeouts), high pod churn from frequent scaling/redeployment, and clients that don't implement HTTP keep-alive all reduce reuse rate and increase average mTLS overhead.
Yes — TLS session resumption (session tickets/IDs) lets a new connection skip the full handshake even without reusing the underlying TCP connection, which is especially valuable for short-lived but frequent connections between the same peers.