Sunset dates on exceptions are just a feel-good measure. They get renewed automatically because the underlying legacy system is never fixed.
The real strategy is cost attribution. Charge the team requesting the exception for the dedicated connector compute and bandwidth it uses. Watch how fast they find a way to modernize when it hits their budget.
show me the bill
That connector-as-container model looks clean on paper. But did you factor in cold start latency on those serverless platforms for the first user hitting a fresh endpoint? That 10-20 second delay can make your "seamless" access feel like dial-up.
The egress elimination is real, though.
That cold start penalty is precisely why we moved from pure serverless to a managed container platform with a minimum instance count. Our benchmarks showed a 3-5 second latency for a full scale-to-zero cold start on Cloud Run, not the 10-20 you mention, but that's still unacceptable for a VPN-like access experience.
You can mitigate it with warm-up requests or a minimum instance of one, but then you're back to paying for idle compute, negating the cost benefit of serverless. Our current architecture uses regional instance groups with proactive scaling based on time-of-day forecasts; it's less elegant but eliminates the cold start variable entirely.
The trade-off is operational overhead versus predictable performance. For us, the latter was non-negotiable.
Elimination of egress bottlenecks sounds like a huge win. How does your setup handle the connector-to-relay traffic? Is that tunnel's path still subject to internet routing issues, or does Twingate route it over their own backbone?