Alright, so my team’s been piloting Appgate SDP for a Zero Trust overlay, and the sales deck was all about "security without compromise" and "user experience." Fine. But my brain, being permanently warped by AWS Cost Explorer, immediately wondered: what's the *latency tax* of all this cryptographic hairpinning? If my devs are waiting an extra second every time they need a database session, that’s a productivity sink, which is just cost with a different name.
I decided to stop guessing and built a crude but effective test harness. The goal: measure the wall-clock time from initiating a connection request to a protected resource (a test EC2 instance behind Appgate) to the moment a simple TCP socket is established. I compared it against a direct connection (security groups only) and a boring old OpenVPN setup we still have lying around.
**The setup:**
* Appgate SDP v5.4 Collector + Gateway in AWS us-east-1.
* Test Client (my laptop) in a different region, on residential broadband.
* Target: A tiny `t3.micro` running a custom TCP echo server.
* Measured: Time from executing connection script to `socket.connect()` success. Ran 100 iterations, tossed outliers, took median.
**The script core (Python, because it's quick and dirty):**
```python
import socket, time, statistics
def time_connection(host, port):
start = time.perf_counter()
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.settimeout(5)
sock.connect((host, port))
elapsed = time.perf_counter() - start
sock.close()
return elapsed
times = []
for i in range(100):
# The host here is either the Appgate Gateway IP, VPN endpoint, or direct EC2 IP
t = time_connection("10.10.10.100", 8443)
times.append(t)
print(f"Run {i}: {t:.3f}s")
print(f"nMedian: {statistics.median(times):.3f}s")
print(f"Mean: {statistics.mean(times):.3f}s")
print(f"Stdev: {statistics.stdev(times):.3f}s")
```
**The results (in milliseconds, median):**
| Connection Method | Median Setup Time | Notes |
| :--- | :--- | :--- |
| **Direct (Security Groups)** | 22 ms | Baseline. It's just the network hop. |
| **Legacy OpenVPN** | 480 ms | TLS tunnel setup, auth. Feels clunky. |
| **Appgate SDP** | 1850 ms | **Yikes.** Nearly 2 seconds. |
**Breakdown of the Appgate delay (from logs and wireshark):**
* ~200ms: Initial API call to Appgate Controller for claim check/entitlements.
* ~1100ms: The real killer. DTLS handshake with the Gateway. Multiple round trips, and from a cold start, it's punishing.
* ~550ms: Gateway-to-Target routing and final TCP setup.
Now, *subsequent* connections to the same gateway are faster (~300ms) because of session reuse, but if the session expires or you need a new resource, you're back in the penalty box. Compare that to OpenVPN where once the tunnel is up, new TCP connections are negligible.
**The takeaway for anyone considering this:** The security model is solid, no argument. But for workflows that require frequent, short-lived connections to different back-end services (think: microservices, jumping between databases, bastion hosts), that session setup overhead is a very real hidden cost. It's not in your cloud bill; it's in your team's idle time waiting for terminals to connect. For us, it means we might segment: use Appgate for long-lived admin sessions, but look at something like Tailscale or even SSM Session Manager for quick, ephemeral tasks.
Your cloud bill is too high, but your latency bill might be higher.