Deploying Trojan VPN on AWS for Secure Enterprise Remote Access

Overview

Enterprises increasingly need robust, low-latency remote access solutions for employees and services. Trojan (also referred to as Trojan-GFW / Trojan-Go in some implementations) is a modern proxy protocol that leverages TLS to evade detection and provide secure tunneling. Deploying Trojan on AWS gives organizations a scalable, controllable environment with deep networking and security controls. This article walks through an end-to-end plan for deploying Trojan on AWS for secure enterprise remote access, including infrastructure design, TLS provisioning, hardening, autoscaling, monitoring, and client configuration.

Architecture and design considerations

Before launching instances, decide the overall architecture. Common deployment patterns include:

• Single EC2 instance for small teams (development / testing).
• Multiple EC2 instances behind a Network Load Balancer (NLB) or Application Load Balancer (ALB) for redundancy and scale.
• Containerized deployment on ECS or EKS for easier lifecycle management.

Essential design goals:

• Confidentiality and integrity: Use strong TLS (TLS 1.3 if available) and certificate management.
• Availability: Multi-AZ instances behind a load balancer and autoscaling groups.
• Least privilege: Fine-grained security group rules and IAM roles for EC2.
• Auditability: Centralized logs (CloudWatch, S3) and alerts.

Core AWS components

Key AWS services used in this deployment:

• EC2 — compute for Trojan server instances (t3.small or t3.medium are common start points).
• VPC, Subnets, Route Tables — network segmentation and routing.
• Security Groups & Network ACLs — network access control.
• Elastic IP (optional) — static public IP for single-instance setups.
• ALB/NLB — balance traffic across backends; NLB preserves source IPs.
• Route 53 — DNS management for TLS certificates and consistency.
• ACM — AWS Certificate Manager for certificates tied to ALB (or use Let’s Encrypt on the instances).
• CloudWatch & S3 — logging, metrics, and retention.
• IAM — roles for EC2 to access CloudWatch and S3 (no long-lived credentials).

Networking: VPC and security groups

Create a dedicated VPC with at least two public subnets in different AZs (for high availability). Typical setup:

• VPC CIDR: 10.0.0.0/16
• Public Subnet A: 10.0.1.0/24 (AZ-a)
• Public Subnet B: 10.0.2.0/24 (AZ-b)

Security group guidelines:

• Trojan servers: allow inbound TCP on the proxy port (commonly 443 or a custom port) only from corporate IP ranges or from the load balancer’s SG. Deny broad 0.0.0.0/0 unless required.
• SSH: restrict inbound to administrator IPs, use bastion host pattern for access.
• Outbound: allow necessary egress (DNS UDP 53 to resolver, HTTPS to upstreams if using ACME).

TLS and certificate strategy

Trojan relies on TLS for obfuscation and authentication. Two approaches:

1) Use AWS ACM + Load Balancer

• Provision an ACM certificate for your domain (e.g., vpn.example.com) in the region of the ALB/NLB.
• Terminate TLS at the ALB/ALB+ACM and forward traffic to backend instances over plain TCP or TLS on a different port.
• This offloads certificate management to ACM and simplifies certificate rotation.

2) Use Let’s Encrypt or commercial certs on instances

• Install certbot on EC2 (or use acme.sh). Trojan benefits from direct certificate control (useful for XTLS or when bypassing ALB).
• Remember to provision a valid domain and ensure HTTP-01 or DNS-01 challenge can be satisfied (use Route 53 DNS API for automated DNS-01).

Important: If you terminate TLS at the load balancer, configure ALB/NLB to preserve client IPs (NLB preserves by default). Trojan’s proper functioning often expects TLS characteristics consistent with real HTTPS traffic (SNI, certificate chain). ALB can be configured to pass through TLS, or you may use NLB with TLS passthrough so Trojan sees the original TLS handshake.

Installing Trojan on EC2

This section assumes Ubuntu 22.04 but applies to other distributions with minor adjustments.

Instance initialization

• Choose an AMI like Ubuntu Server. Attach an IAM instance profile that allows CloudWatch PutMetricData and S3 PutObject (optional).
• Allocate an EBS volume (gp3) sized for logs and future needs, enable encryption by default.
• Harden SSH (change port, disable password auth, use key pairs).

Installing Trojan (trojan-go example)

Example steps (shell commands are illustrative):

• apt update && apt install -y curl socat nginx certbot
• Download trojan-go binary from trusted source or build from source and place in /usr/local/bin/
• Create configuration file /etc/trojan-go/config.json with TLS settings, password(s), and port. A minimal config portion:

Example JSON (trimmed and illustrative):

{“run_type”:”server”,”local_addr”:”0.0.0.0″,”local_port”:443,”remote_addr”:”127.0.0.1″,”remote_port”:80,”password”:[“your-strong-password”],”ssl”:{“cert”:”/etc/letsencrypt/live/vpn.example.com/fullchain.pem”,”key”:”/etc/letsencrypt/live/vpn.example.com/privkey.pem”,”sni”:”vpn.example.com”,”prefer_server_cipher”:true}}

• Adjust permissions on /etc/trojan-go and certificates so the trojan process can read them.
• Create a systemd service /etc/systemd/system/trojan-go.service to manage the daemon and enable it.

Systemd service example

A minimal unit (illustrative):

Then: systemctl daemon-reload && systemctl enable –now trojan-go

Security hardening

• Use iptables/nftables to restrict inbound traffic to only expected ports and sources. Example: allow 443 from ALB SG or corporate IP prefixes.
• Enable automatic OS updates or use a managed image pipeline.
• Limit process capabilities using systemd (CapabilityBoundingSet) and run trojan as an unprivileged user where possible.
• Enable CloudWatch Agent to ship logs and metrics; store long-term logs in encrypted S3 buckets with lifecycle policies.
• Use AWS WAF in front of ALB if terminating TLS at ALB to mitigate layer 7 attacks and filter malicious traffic.

Scaling and high availability

For production enterprises, do not rely on single-instance deployments. Recommended pattern:

• Create an Auto Scaling Group (ASG) across multiple AZs with a launch template that includes the trojan installation (use user-data or bake AMI).
• Attach instances to an NLB in TCP mode. Use health checks on the trojan port (custom TCP health check) or a small HTTP health check endpoint served by a local sidecar web server.
• Maintain session stickiness if needed (but for stateless proxy sessions, stickiness usually isn’t required).

Autoscaling triggers can be CPU/network based or schedule-based for predictable loads. Keep a minimum size of at least 2 instances for redundancy.

Monitoring, logging, and alerting

Implement observability:

• CloudWatch metrics: CPU, network in/out, disk, trojan process health via custom metrics.
• CloudWatch Logs: forward /var/log/trojan-go.log and system logs. Use a retention policy and export to S3 for audits.
• Implement alarms for high error rates, unusual connection spikes, or CPU/connection exhaustion.
• Integrate with PagerDuty/Slack for on-call alerts.

Client provisioning and security policies

For enterprise clients, manage credentials centrally:

• Use strong, randomly generated passwords or client certificates where trojan-go supports client certificate verification.
• Issue client configuration templates with the server address, port, password, and SNI. Example client config snippet points to vpn.example.com:443 and password.
• Integrate with SSO or a provisioning service if you need ephemeral credentials — e.g., generate time-limited passwords using a provisioning API and update server ACLs dynamically.
• Enforce split-tunneling or full-tunneling policies through the client configuration and network ACLs.

Backup, maintenance, and incident response

• Maintain AMIs of a validated golden image containing the trojan binary and agent configuration.
• Automate backups of configuration files to an encrypted S3 bucket; version the configs and restrict access via IAM policies.
• Have a documented incident response playbook that includes steps for certificate revocation/rotation, credential rotation, and scaling remediation.
• Perform regular penetration testing and traffic analysis to ensure Trojan traffic remains indistinguishable from legitimate traffic for obfuscation goals, while verifying no data leakage occurs.

Alternative deployment: Containers and orchestration

Using ECS or EKS simplifies lifecycle management:

• Pack trojan-go into a minimal container image; run as a non-root user and mount TLS certs from Secrets Manager or S3 via IAM roles.
• Use a Service with a Network Load Balancer target group (IP mode) to preserve client IPs and enable scaling via ECS Service Auto Scaling.
• Use Kubernetes Deployments with PodAntiAffinity across nodes and use ExternalDNS to manage Route 53 records automatically.

Conclusion

Deploying Trojan on AWS provides a secure, flexible remote access solution for enterprises when designed with careful attention to TLS, network segmentation, monitoring, and scaling. Key takeaways:

• Clarify certificate termination strategy (ACM + ALB vs. instance-level Let’s Encrypt).
• Harden access using security groups, bastion hosts, and IAM roles.
• Use ASGs and load balancers for availability and NLB when you need TLS passthrough.
• Automate logging, monitoring, and provisioning to maintain operational maturity.

For step-by-step scripts, hardened systemd unit files, and a sample trojan-go configuration tailored for AWS deployments, consult your internal security team and test thoroughly in a staging environment before rolling out to production.

Published by Dedicated-IP-VPN