Best Practices for Connector Placement
Let's explore where Connectors should live based on your environment.
As you get started with Twingate, you may be wondering where you should deploy your Twingate Connectors in your environment. This guide will help you determine what is possible and what you should consider when making those decisions.
What you should know about Connectors
Regardless of whether you intend to deploy Connectors on-premises or in a cloud environment, keep in mind the following:
- Connectors can be deployed on virtual machines or in containers
- Connectors offer load balancing and high availability when installed in pairs or other multiples
- Connectors serve connections from Clients to Resources and from Resources to Clients
- Many Remote Networks can be created and there is no cap on the number of Connectors you can create in Twingate
- Connectors should ideally be as physically near as practicable to the Resources they serve and a network path must exist between them
- Connectors (and the machines hosting them) should be able to resolve the FQDNs of Resources they allow access to. For instance, in order for users to access
myprivatewebapp.corp.intremotely, the machines hosting Connectors within the Remote Network serving the corresponding Resource need to be able to resolvemyprivatewebapp.corp.int
Before going over available options, remember that you can use a combination of them - you do not have to stick to a singular approach. The best design typically depends on the complexity of your environment and is never set in stone – you can always change your approach as you grow.
Connectors in Cloud Environments
If you want to grant end users access to assets behind a firewall in your cloud environments, several options are available.
Placement Options
-
Within individual VPCs/VNets
Connectors can be deployed within a VPC/VNet containing Resources. They can be either in a dedicated subnet or a subnet already containing Resources:
-
Within a dedicated VPC/VNet (peered to other VPCs/VNets)
Connectors can be deployed in their own VPC/VNet and provide access to Resources in peered VPCs/VNets:
-
Within a transit gateway or VNet gateway
Connectors can be deployed in a transit gateway (AWS) or VNet gateway (Azure) and provide access to underlying VPCs/VNets:
On-Premises Environments
If you want to grant end users access to assets behind a firewall in your on-premise environments, many options are available.
Placement Options
-
Within individual subnets
Connectors can be deployed within subnets containing Resources:
-
Within dedicated subnets
Connectors can be deployed within dedicated subnets as long as those subnets can reach the subnets containing Resources:
Last updated 2 months ago