VNS3's main use-case is providing the application with an edge where the network services normally provided at the data center edge are run in a specialized form.


Because VNS3 is a software appliance it is limited to the resources provided by the hypervisor so don’t expect to get 10 GB of throughput on an instance where the underlying physical host doesn’t have access to that kind of bulk transport.


Throughput and performance are completely dependent on instance size. As you increase the size of the instance you get access to different types of underlying physical server hosts and different “shares” of those resources.


CPU and memory end up being the most important resources from a VNS3 controller point of view, depending on the use-case (like using the Overlay Network or not), given the encryption, and encapsulation/decapsulation. 


When using the Overlay Network with any moving data that isn’t voice or video you get a performance boost over what is normally available on the VPC VLAN. This is a result of VNS3 taking advantage of dynamic compression. So if the data you are planning on moving in the cloud is “normal” enterprise data, you’ll see a performance increase when using the Overlay Network.


 


Additional performance gains can be realized in cloud environments that allow jumbo frames (e.g. AWS 9001 byte MTU).  This allows more data to be moved inside the cloud without added fragmentation that can slow down throughput.  The VNS3 Overlay Network can be tuned to take advantage of the higher byte frame units in order to achieve faster speeds.


 


Finally VNS3 controllers can be peered in an n-mesh to build a horizontal network edge to handle more traffic. This mesh can spread the Overlay Network load as well as IPsec extranet tunnel load.


 VNS3 throughput matrix


With a few adjustments, you can:



  • Run your VNS3 mesh on as many big instance as you need

  • Spend more on larger Instance sizes (like t2.large, c4.large, or m4.large)

  • Shift the throughput bottlenecks to the AWS network backbone and your connecting party’s edge connectivity for any public internet IPsec VPN tunnels


IPsec connections over the public Internet are typically limited by the amount bandwidth you purchased at the data center or connecting-party end of the tunnel.  The typical way around this limitation is to purchase a throughput SLA in the form of an AWS Direct Connect (or ExpressRoute in Azure).  When using a Direct Connect or ExpressRoute layer 2 connection, VNS3 provides added encryption (VLAN tagging is private NOT secure), manageability, routing, and recovery features/functions.