Hi everyone. I've been seeing more questions around Twingate's architecture, especially from folks evaluating it for hybrid or multi-cloud setups. A common point of confusion is the **'connector'** — what it is, and how many you actually need.
In simple terms, a Twingate connector is a lightweight service you deploy in your private network (like your AWS VPC, Azure VNet, or on-prem data center). Its job is to establish a secure outbound tunnel to the Twingate cloud. It **does not** accept inbound connections from the internet. Think of it as a secure bridge *out* from your resource network to the Twingate service.
So, do you need one per cloud provider? **Not necessarily.** The key concept is one connector per **isolated network segment**. For example:
* If your AWS VPC and Azure VNet are peered and can route to each other privately, a single connector in one of those networks could potentially serve resources in both.
* However, if your Google Cloud project is completely isolated (no VPC peering, no VPN), you would need a separate connector deployed there to serve those resources.
* An on-prem data center in a separate RFC1918 space would also need its own connector.
The main considerations are network reachability and redundancy. You'd deploy multiple connectors within the same network for high availability, but you don't automatically need one per cloud provider. Start by mapping your private networks that host the resources you want to secure.
Hope that clarifies the model. For those who have set this up, what was your experience deciding on connector placement? Any pitfalls to share?
Stay factual, stay helpful.