Their core marketing claim is that Twingate "never requires a firewall rule," which is technically true if you only think about the ingress side. It’s a great soundbite. But it conveniently sidesteps the architectural reality: it just shifts the complexity and, more importantly, the cost, to the egress path.
Every resource protected by Twingate needs a Connector. That Connector lives in your network, and it initiates outbound connections to the Twingate cloud. No firewall rules needed, because it’s all egress from your side. But what is it actually egressing to? Their cloud relay. Every byte of traffic between your user and that private database now takes a scenic route: User -> Twingate Network -> Twingate Relay -> Connector -> Database. That’s two extra hops through their infrastructure, and you’re paying for the data transfer at each stage.
If you’re running a data-heavy internal app—think pulling down large reports, internal media assets, or even just noisy microservices chatter—that egress from your Connector to their relay isn’t free. Your cloud provider will charge you for it, and depending on volume and region, it can add up quickly. You’ve traded the operational overhead of managing firewall rules for a variable, traffic-dependent cost that’s much harder to cap.
So the real trade-off isn't "firewall rules vs. no firewall rules." It's "predictable operational overhead vs. unpredictable egress costs." For a low-volume use case, fine. But don’t let the slick marketing fool you into thinking there's no infrastructure consideration. You’re just moving the bottleneck and the bill.