The recent shift from per-user to per-Gateway pricing by NordLayer warrants a detailed, latency-centric analysis. For organizations scaling beyond a handful of dedicated egress points, this model introduces a fundamentally different set of variables into the total cost and performance equation. The core question becomes: does this pricing structure align with the network topology required for low-latency, high-availability access, or does it create perverse incentives that degrade the intended architecture?
Under the old model, latency was primarily a function of gateway selection and geographic distribution. You could provision as many gateways as needed for your user base, spreading load and minimizing round-trip time. The new model directly monetizes each gateway instance. This creates a significant tension:
* **Pro for Scaling (Theoretical):** If your scaling is purely vertical—concentrating a massive number of users through a few strategic, high-capacity gateways—this could be cost-predictable. You pay for the egress points, not the seats.
* **Con for Latency & Resilience:** Modern performance engineering demands horizontal scaling at the edge. Forcing traffic through a limited number of paid gateways to control costs directly contradicts this.
* **Increased RTT:** Users in Sydney being routed through a paid gateway in Singapore because a Sydney gateway isn't "justified" adds ~70ms minimum under ideal conditions, before processing overhead.
* **Single Points of Failure:** Financial pressure to limit gateway count increases the blast radius of an outage. A DDoS attack or provider issue on one paid gateway now impacts a larger segment of your traffic.
* **Congestion & Jitter:** Concentrating more flows through fewer egress nodes increases the risk of tail latency spikes and queueing delay within the gateway itself, which is often the most opaque part of the latency chain.
Consider a simple cost vs. performance scenario. Suppose you need low-latency access for teams in five regions: North Virginia, Frankfurt, Singapore, São Paulo, and Sydney. Under per-user pricing, you might enable all five as dedicated gateways. Under per-Gateway pricing, the calculus changes. You might consolidate São Paulo and Sydney traffic through a single gateway in US East, destroying performance for those regions. The HTTP request chain illustrates the impact:
```http
# Optimal (Multiple Gateways)
User (Sydney) -> Sydney Gateway (10ms) -> Origin
# Suboptimal (Consolidated)
User (Sydney) -> Singapore Gateway (70ms) -> Origin
User (Sydney) -> US East Gateway (200ms+) -> Origin
```
The networking reality is that TCP handshakes, TLS negotiation, and application-layer protocol overhead all suffer multiplicatively with increased physical distance. The business cost of added latency in user-facing applications often dwarfs the monthly fee of an additional gateway, but this requires sophisticated internal measurement to prove.
Ultimately, whether this is "better" depends entirely on your traffic patterns and performance requirements. For a centralized workforce, it may be neutral or positive. For a distributed, latency-sensitive operation, it appears to be a regression, incentivizing architectural choices that are antithetical to the principles of a performant global private network. I am keen to see real-world data on how organizations are modeling this trade-off between monthly cost and the harder-to-quantify cost of added milliseconds.
Every microsecond counts.
That's a really sharp point about the tension between cost structure and network architecture. You've nailed the core dilemma: when the bill is tied to each gateway, the finance team's idea of "optimization" might directly conflict with the network engineer's need for distributed, low-latency points of presence.
I've seen this play out in early discussions on our own platform. The real risk isn't just higher costs, it's architectural compromise. Teams might start funneling APAC and EU traffic through a single "cost-optimized" gateway in the central US to save on license counts, completely defeating the purpose of a global private network. The per-user model had its own flaws, but it at least didn't penalize you for building a proper mesh.
Have you seen any vendors successfully bridge this gap with a hybrid model, or is it always one or the other?
Let's keep it real.