VNS3 is available in public clouds (VNS3:vpn and VNS3:net) and private cloud deployments (VNS3:turret) for a premium listed below. This premium does not include the runtime fees/costs associated with running VNS3 instances which vary from provider to provider (internal or external). The size of the instance deployed directly impacts the total throughput that is available for a particular VNS3 controller. If you would like to discuss which instance is right for your use-case or what the total cost of a VNS3 cloud network will be for your project, contact us.
The following VNS3 pricing includes the subscription premium charged by Cohesive Networks.
Controllers – the actual VNS3 instances that are included in a topology and are allowed to be peered in a mesh. VNS3 controller instances peer by making secure VPN connections to each other in a true mesh to share routing information and to pass traffic between each other based on the connections each Controller is servicing. Multi-Controller topologies allow for Overlay Network Traffic load balancing and failover. In the setup, if one VNS3 Controller instance fails all the Overlay Network client servers automatically connect to another VNS3 Controller in the topology.
Clientpacks – the X.509 credentials associated with a specific Overlay Network IP address. You can use a tunneling agent (e.g. OpenVPN) to connect to a VNS3 controller and into the Overlay Network. The number of clientpacks you use will determine how many servers can directly join the Overlay Network.
IPsec Endpoints – the remote devices you will negotiate an IPsec tunnel from your VNS3 controller instance. These are typically extranet devices like Cisco ASA, Juniper Netscreen, Palo Alto, etc. This number determines the number of remote devices you can define on the VNS3 instance. You can allow certain traffic to pass between those devices based on the tunnel definitions (see below).
Tunnels – the actual remote-to-local subnet definitions you are configure for the IPsec Endpoints. For example, a tunnel definition would be associated with an IPsec endpoint and would allow some local subnet (e.g. Overlay or unencrypted VPC VLAN) to connect to a remote subnet (e.g. your data center subnet, partner subnet, customer subnet).
Containers – the number of application containers you can run on your VNS3 controller instance to provide application delivery controller (ADC) network services. You can upload your containers to run most any open source, 3rd party-sourced, or proprietary-sourced application to provide the network service you might need for your use-case. Customers typically run services like proxy, reverse proxy, content caching, NIDS, and load balancing, but you can create any custom application container. The container system is base on Docker and you can upload Docker files or LXC/Libcontainer image files.
For more on VNS3 components and tips on VNS3 see our support FAQs.