Hey everyone, I've been running Absolute Secure Access for a few months now, primarily to secure access to our internal Kubernetes clusters and a few legacy on-prem applications. It's been solid from a security standpoint, but I kept wondering: what's the actual performance cost when we go from a baseline config to "paranoid mode" with every available security feature turned on?
I decided to run some benchmarks, because in DevOps, if you can't measure it, you can't manage it (or justify the potential latency to the dev team). My goal was to simulate a real-world scenario—a developer accessing an internal web app through the ASA gateway—and measure the impact on latency and throughput at each security tier.
**My Test Setup:**
- **Tooling:** `k6` for load testing, custom Python scripts to orchestrate and log.
- **Scenario:** Simulated 100 virtual users over 5 minutes, hitting a simple `nginx` service behind ASA.
- **Metrics Collected:** Request latency (p95, p99), throughput (requests/sec), and connection establishment time.
- **ASA Configuration Tiers:**
1. **Baseline:** Just TLS termination and basic routing.
2. **Tier 2:** + Device Posture Check (via a lightweight agent) + Geo-IP filtering.
3. **Tier 3 (Full Suite):** Tier 2 + Continuous authentication (token re-validation every 30s) + Deep packet inspection for a set of allowed protocols + Full session recording/logging enabled.
**Key Findings (Averages from 10 test runs):**
* **Latency (p95):**
* Baseline: ~12ms
* Tier 2: ~48ms
* Tier 3: ~210ms
The jump to Tier 3 was significant, largely traceable to the continuous auth checks and the overhead of deep inspection.
* **Connection Establishment Time:**
* Baseline: ~100ms
* Tier 2: ~850ms (posture check dominates here)
* Tier 3: ~1200ms
* **Throughput:** Surprisingly, throughput didn't degrade as much as latency, only dropping about 15% from Baseline to Tier 3. This tells me ASA handles scale well, but individual user experience will feel the latency hit.
**Config Snippet for the "Full Suite" Test:**
I used the ASA Terraform provider to script the policy changes between test runs. Here's a fragment showing the more aggressive settings:
```hcl
resource "absolute_secure_access_policy" "paranoid_web_app" {
name = "benchmark-tier3"
description = "All security features enabled for performance test."
continuous_auth {
enabled = true
interval = 30 # seconds
strict_mode = true
}
inspection {
mode = "deep"
protocols = ["http", "https", "ssh"]
}
logging {
session_recording = true
level = "verbose"
}
posture_check {
provider = "agent"
require_healthy = true
}
}
```
**Takeaways & Recommendation:**
The performance hit is non-linear. Enabling every feature might be overkill for all resources. My suggested workflow is:
* **Classify your resources:** Not every internal service needs session recording and deep inspection. Use risk-based tiers.
* **Baseline first:** Measure performance with your expected normal load *before* enabling advanced features on a critical path.
* **Beware of continuous auth on short intervals:** For highly interactive apps, the latency from 30s re-validation was noticeable. Consider longer intervals or step-up authentication for sensitive actions only.
* **Cost implication:** The logging and recording at verbose levels generated 10x more data, impacting your storage backend costs.
Has anyone else done similar benchmarking, maybe with different tools or against other ZTNA solutions? I'm curious if these deltas are in line with community experience.
automate everything
automate everything
Good on you for actually measuring instead of just speculating. Too many teams get sold on security theater without understanding the operational cost.
One thing you didn't mention that I'd be very interested in: memory and CPU overhead on the ASA nodes themselves when you start layering on those checks. Sometimes the latency hit is minor, but the real cost is in how many concurrent sessions a single gateway instance can handle before it falls over. That scaling factor is what kills budgets.
Also, make sure your "simple nginx service" isn't just returning a 200 OK on `/`. It needs to simulate a real app response size - even 50KB of dummy data - because some of the advanced inspection features will have a much bigger impact on throughput with actual payloads to scan.