How can I do more with AWS Virtual Private Cloud (VPC)?

Want to do more with your AWS virtual private cloud (VPC)? We have 10 ways you can enhance cloud networking with our virtual appliance, VNS3. 1. You control the cipher suites and keys The AWS VPC default (and only) encryption algorithm choice for VPN connections is AES-128. AES-128 is a good, but what if your industry regulations or internal policies need AES-256, or the partner you’re connecting to insists on 3DES? Then there’s the question of how exactly pre shared keys (PSKs) are shared – are you really happy to share keys with a 3rd party service provider? 2. Connect across availability zones, regions, and into other clouds Fault boundaries are there for a reason, and a resilient application should be spread across fault boundaries. The only good reason for VPC subnets being limited to a single availability zone (AZ) is simplicity for Amazon’s network engineers. VPC has provided VPC Peering but is limited in number of VPCs that can be peered, intra-region only, and security features. VNS3 subnets can span across AZs, regions or even into different clouds such as Azure, HP and Google Compute Engine. 3. Pay only once for IPsec connectivity and NAT (not twice) VNS3 providers IPsec and NAT capabilities in one virtual instance. With AWS VPC IPsec is one billable service, and the NAT AMI also runs up the EC2 bill. 4. Oh no – everybody picked the 10.0.0.0/16 default and now we can’t connect As previously mentioned, VPC now has a peering feature to join networks together. That great but bad luck if you picked the default VPC subnet and so did the person you’re connecting to. Beware the default network. VNS3 can map network address ranges, so you can connect to all those partners who didn’t know better than to pick the default. This also applies to IPsec end points, so you can connect to multiple parties with the same IP ranges on their internal networks. 5. You want to connect your VPN gateway to more than one VPC Once a public IP has been used for a remote endpoint for a VPC VPN connection that public IP can’t be used again in that region. Only one VPC VPN can connect to a specific endpoint’s public IP per region. Of course you could assign another IP at the gateway end, but that’s extra cost and hassle. 6. Your partners want to use IPsec over NAT-T VPC hardware gateways only support native IPsec, whilst VNS3 can deal with either native IPsec or IPsec with network address translation traversal (NAT-T) – just not both at once[1]. 7. Multicast (and other neglected protocols) AWS is not alone in having no support for multicast – most other clouds don’t either[2] – it’s pretty hard to make a multi endpoint networking protocol work in a multi tenant environment. Not only does VNS3 enable multicast in the cloud by using overlay networking, you can also connect to enterprise multicast networks. We can also use generic routing encapsulation (GRE) to get other protocols out of the data centre and into the cloud. 8. Monitoring VNS3 supports SNMP, and you can also dump traffic from network interfaces for additional logging and debugging. 9. Extensibility Want to add SSL termination, a proxy server, some load balancing or content caching. You could use a bunch of extra VMs on your network edge, or you could avoid the additional cost, complexity and security concerns by using some Docker containers on VNS3. 10. Reliability A major telco was finding that most of its cloud based customers had repeated connectivity problems, but a handful didn’t. It turned out that handful was running VNS3. Get started now in the AWS Marketplace: https://aws.amazon.com/marketplace/pp/B00THF220U