Syntropy Stack allows DevOps and application teams to leverage low-cost public internet to securely and rapidly deploy apps in AWS.
Using a decentralized P2P encryption technology (Wireguard), Syntropy Stack provides the ability to seamlessly create, automate, scale, and optimize encrypted connections between any devices or services running on, within, or between, cloud, on-premise, or edge locations.
Syntropy Stack also leverages Syntropy’s DARP relay network. DARP is an acronym for Distributed Autonomous Relay Protocol which is a new routing protocol developed by Syntropy who has deployed DARP nodes across the public Internet that form an overlay intelligence network with performance metrics Syntropy Stack references to override ISP default routes and send packets down the fastest path with the lowest amount of latency and packet loss.
Stack is made up of 2 components: agents and a web UI.
Agents currently are distributed as a container for use in on-prem and private data center endpoints. Soon it will be available in AWS Marketplace as an AMI that makes installing super fast and easy in AWS.
The web UI is operated and managed by Syntropy outside of the customer’s deployment and outside of AWS. It’s where customers configure their network environment and it also provides secure and isolated accounts, as well as workspaces, per team, or per user. The web UI is great for monitoring application and network health, and all of this can be done via Syntropy’s API too. More detailed information regarding Syntropy Stack can be found here
There are two main use cases for deploying Syntropy agents in AWS.
First is the security use case, which is similar to how AWS Security Groups (SGTs) work, in that it provides granular control over which specific machines are permitted to intercommunicate with other machines.
This whitelist model denies all communications between servers, in that what is not explicitly permitted, is implicitly denied. This provides administrators a powerful and intuitive tool that locks down communications between services running on and between servers, all the way down to the individual container (which is a step beyond what SGTs can do).
The second, and more prevalent use case, is for optimizing path selection over the global Internet between a service or service in an on-premise or edge location, and any AWS VPC, in any region. The only dependency is that EC2 is available in the region, which is a globally available service. No other AWS services are required, however it is up to the customer to employ AWS Well Architected best practices when designing and deploying the Syntropy agent in a VPC. This second use case is the one outlined in this document.
In all cases, the Syntropy agent software is provided in an AMI for deployment in the AWS Cloud. The AMI is hardened as per AWS CIS requirements. It is preconfigured with Docker and a container for the Syntropy agent. At initial boot, a dialogue requesting a Syntropy agent token and port range for Wireguard tunnels
is made. Customers do not need to install Docker or run Docker commands. By answering the initial dialogue questions, setup is automated.
The Syntropy agent AMI can run on any size machine, with recommended minimum network speed that aligns with the amount of data you expect to be passing through the agent. Syntropy agent AMI does not require storage, so hard disk requirements are minimal. 1 core, 512 MB RAM, 200 MB storage.
Familiarity with AWS VPC networking and security, along with EC2 instance creation (via AMI) is all that is needed to stand up a Syntropy enabled connection. No specific operating system knowledge is required.
Syntropy agent can be deployed in any AWS region in the world as it fundamentally requires ubiquitous EC2 and VPC services.
The application does not require the use of root privilege for deployment or operation. It is not recommended to use AWS root user for any deployment or operations.
Ensure following the policy of least privilege by creating an IAM policy for accessing and managing the instance, as well as an IAM policy for accessing VPC privileges.
Create a security group for the Syntropy Agent AMI that only allows the tight range of UDP ports that you define in the initial dialogue with the Syntropy agent AMI after its initial boot. Because all traffic is encrypted/decrypted via Wireguard, all traffic that is sent from services inside the VPC, through the Syntropy agent, to the Internet, as well as traffic coming from Syntropy endpoints at other locations, will only ever use the UDP ports defined, for both ingress and egress traffic.
When creating Syntropy agent tokens, store the token securely in a vault or hardware security module. Never store production agent tokens on any other devices.
Customer configuration data is stored in Syntropy’s web UI database and is inaccessible to users.
The annual license fee for a Syntropy agent is $50 per year, per endpoint. Customers must deploy one agent at each data center and a minimum of two agents per AWS VPC. Pay as you go data rates are $0.10 (ten cents)/Gigabyte of data transferred over Syntropy accelerated paths. When the default Internet path is being used, there is no pay as you go cost.
Currently licensing is based on backend processes that link a valid customer to the Syntropy controller.
The Syntropy Agent AMI requires EC2 instances. Always consider service and budget limitations inside your AWS account, when deploying a Syntropy Agent AMI.
The typical customer deployment is the installation of a Syntropy agent in the public subnets of each AWS VPC, as well as each corporate data center, requiring optimization between the on-premises, or edge locations, and the AWS regions. There is only a single corporate data center and AWS VPC depicted below. The process is repeated in each and every AWS VPC, as well as, each and every corporate data center or edge location, that is intended to leverage the Syntropy optimization technology.
Within the AWS cloud, a VPC containing a minimum of four public and two private subnets, is recommended for fault tolerance. It is at customer’s discretion if more than four public and/or private subnets are called for, based on cloud deployment architecture. Additionally, NAT gateways are created to enable private subnet traffic to reach the Internet.
Note there is a public subnet dedicated to Syntropy Agent AMI and NAT Gateway in each Availability Zone. These public subnets need to be explicitly associated with a routing table (RT) that has an Internet Gateway (IG). Create a /32 route to forward traffic from the Syntropy AMI to NAT Gateway.
Each of the additional public subnets are dedicated to services and instances that require public IPs. Each public subnet must be explicitly associated with a new RT. Within the RT, create a static route for that subnet’s traffic, to each of the Syntropy Agent AMI Network Interfaces. For example, 10.0.3.0/24 will be routed to the Syntropy AMI network interface in Public1A and another static route for 10.0.3.0/24 to the Syntropy AMI network interface in Public1B. This provides fault tolerance in the case a Syntropy agent goes offline.
Finally, create a routing table for each private subnet, associating the respective private subnet to it. Then add two more routes, forwarding that subnet’s traffic, to each of the Syntropy AMI network interfaces.
Now all the services and instances that exist in the private and public services subnets will have to flow through the Syntropy Agent AMI, to the NAT gateway, and out to the Internet.
At each of the corporate data centers, the Syntropy agent is also installed via Docker. Instructions can be found at here.
Once each VPC and each data center or edge location has agents running, the next step is to manage the endpoints in Syntropy Stack.
From there, customers can enable, manage and monitor connections between sites and the cloud.
Typical customer deployment of a Syntropy agent on premises is less than 30 minutes. Due to the additional steps of VPC creation and management, the typical customer deployment within AWS Cloud is less than 1 hour.
Managing endpoints: https://docs.syntropystack.com/docs/manage-your-endpoints
Connection Analytics: https://docs.syntropystack.com/docs/connection-analytics
SDN Connections https://docs.syntropystack.com/docs/connection-sdn
Syntropy backs up customer’s Syntropy Stack (controller) configuration twice daily. The controller gives the agent its required routing information dynamically. Therefore, backup of an agent’s config is not required.
Syntropy routinely updates the agent code. New Syntropy agent can be obtained from the Docker command line by issuing the following command:
sudo docker pull syntropynet/agent:stable
Or one can rerun the mandatory docker environment variable
SYNTROPY_AGENT_TOKEN=<Agent Token> -d syntropynet/agent:stable
Details on updating agents can be found here.
If agent software fails, it’s as easy as re-pulling the docker image and running the container. All the detail can be found here.
Updated 11 months ago