AWS: Reference Network Architecture

This document provides a reference network architecture for deploying a secure network within an Amazon Web Services (AWS) Virtual Private Cloud (VPC) using Twingate. The primary objective of this architecture is to minimize the attack surface and implement a layered security approach for high isolation.

Technical Overview

The architecture includes one public subnet hosting a NAT gateway with an Elastic IP and an Internet Gateway for egress to the public Internet. Additionally, there is one private subnet that hosts a Twingate Connector, which allows for access control policies to be defined through the Twingate Admin Console for internal Resources.

Important Notes

• Routing and Security Groups should prevent any inbound connections into the VPC, with the NAT gateway being the sole resource possessing a public IP address.
• When building Security Groups, ensure that the NAT gateway is configured to allow outbound connections to Twingate’s servers. This is essential for the Twingate Connector to function correctly.
• It is recommended that the NAT gateway resides in a subnet devoid of private resources to further reduce the attack surface.
• The Connector can reach private Resources within the private subnet (TCP, UDP, ICMP), and network administrators can fine-tune access to those Resources.
• This architecture requires minimal configuration, leading to minimal AWS resource costs while offering a high level of protection.

At a high level, you generally have two main options for your Connector deployment:

• Public Subnet Deployment: Place the Twingate Connectors directly in a public subnet and assign them Elastic IP addresses. This allows for direct P2P connections from Client devices.
• Private Subnet with NAT: Deploy the Connectors in a private subnet alongside your Resources, but use a Network Address Translation (NAT) solution in a public subnet, which is then assigned an Elastic IP address. This NAT solution acts as the egress point for the Connectors.

In both scenarios, the same outbound rules need to be applied regarding specific ports and protocols for P2P traffic.

Peer-to-Peer (P2P) Connectivity Considerations in AWS

For enhanced performance and reduced latency, Twingate supports a “peer-to-peer” (P2P) connection between a user’s device running the Twingate Client application and the Twingate Connector deployed within the AWS environment.

It is important to note that the standard AWS NAT gateway product is not NAT traversal friendly in all situations, which is required for Twingate’s P2P connections.

Therefore, in these situations Twingate recommends using alternative NAT products or structures for robust P2P functionality in AWS. These alternatives offer greater deployment flexibility and can often lead to reduced costs compared to the AWS NAT gateway for this specific use case. Recommended solutions include:

• AMI-based NAT products: Such as Cohesive Networks’ VNS3 cloud NAT or alterNAT.
• Self-hosted EC2 instances: Running open-source NAT solutions like fck-nat.

These alternative NAT solutions provide the necessary capabilities for effective NAT Traversal, ensuring stable and efficient P2P connections between Twingate Clients and Connectors in AWS.

Deployment

For deploying Twingate Connectors within your AWS environment, you have several options, with common choices being Amazon EC2 instances and Amazon ECS. For production environments, it is strongly recommended to deploy a minimum of two Twingate Connectors for redundancy, and additional Connectors can be deployed to increase capacity for users accessing Resources.

• Amazon EC2 Instances: Twingate Connectors can be easily deployed on standard Amazon EC2 instances. This provides granular control over the underlying compute resources, allowing you to select instance types that best fit your performance and cost requirements. You can manually launch EC2 instances and install Twingate Connectors in them, or automate this process using AWS CloudFormation, Terraform, or user data scripts. This approach is suitable for scenarios requiring dedicated virtual machines and allows for extensive customization of the operating environment.

• Amazon Elastic Container Service (ECS): For containerized environments, Twingate Connectors can be deployed as tasks within Amazon ECS. This approach leverages the benefits of containerization, such as portability, scalability, and simplified deployment management. You can run Twingate Connectors on ECS using either the EC2 launch type (where you manage the underlying EC2 instances) or the Fargate launch type (for a serverless experience where AWS manages the infrastructure). Deploying with ECS simplifies scaling and integration into existing container workflows.

Terraform and Infrastructure as Code (IaC)

For robust, repeatable, and scalable deployments of Twingate Connectors and their surrounding AWS infrastructure, utilizing Infrastructure as Code (IaC) tools like Terraform is highly recommended. IaC allows you to define your infrastructure in configuration files that you can version, review, and reuse, ensuring consistency and reducing manual errors.

Twingate provides a Terraform configuration for this architecture documented at Terraform AWS Deployment Guide.

The Twingate Solutions Engineering team provides dedicated Terraform quick starts and example configurations to help you rapidly deploy and test Twingate across various environments in AWS and beyond. These scripts are designed to guide users toward building out secure network architectures with Twingate.

For more detailed examples and sandbox demonstrations, you can explore the official GitHub repository: Twingate Solutions Engineering Terraform Demo Repository.