Miscellaneous 4 min. read

What is the Best AWS VPN?

Pango Team

With Amazon Web Services’ dominant position in the cloud services industry, AWS is a natural choice for companies’ cloud computing strategies. But how do you provide secure access to resources hosted on AWS? And what are the drawbacks to an AWS VPN?

What is an AWS VPN?

AWS’s commitment to security only goes so far. Companies can count on Amazon to protect its data centers and network infrastructure. However, managing access to company resources hosted on Amazon’s cloud is not AWS’s responsibility. Whether it is connecting an on-premises network to AWS-hosted resources or providing access to remote workers, a company’s IT department must develop its own access management system.

Of course, Amazon offers a full suite of security tools that companies can license. Amazon Virtual Private Network, for example, comes in two flavors. The AWS Client VPN lets end users access a company’s AWS resources and on-premises networks from anywhere in the world. This fully-managed service scales quickly since it is not dependent on physical hardware.

AWS Site-to-Site VPN lets companies connect their Amazon Virtual Private Clouds to their on-premises networks. The redundant, high-performance connections are fully encrypted and are supported by AWS’s management tools.

Standardizing on Amazon’s security tools may make sense for a company that has gone all-in on AWS virtualization. However, in a more heterogeneous network, AWS Client VPN and AWS Site-to-Site VPN add more complexity for IT departments and end-users.

Common AWS VPN Alternatives

Rather than treating AWS as a proprietary platform, Amazon enables an ecosystem of solutions providers who have integrated their software with AWS. Companies can license and deploy these services quickly and benefit from consolidated billing through their AWS account.

Networking powerhouses like Cisco are prominent sellers in the AWS Marketplace with solutions like Cisco Adaptive Security Virtual Appliance (ASAv). This is the same software that runs on Cisco’s hardware-based Adaptive Security Appliance ported to AWS. Companies can set up site-to-site and remote access VPN services and use the same policies from their physical ASAs. 

That integration is the main benefit — and limitation — of using enterprise-class solutions like Cisco’s ASAv. Enterprises that build their network and security infrastructure upon Cisco solutions get the most benefit from using Cisco’s cloud solutions to secure AWS resources.

At the other end of the spectrum is OpenVPN Access Server, the proprietary, business-centric version of the twenty-year-old OpenVPN open source project. This solution promises simplified client deployment, automated infrastructure for resource setup, and integration with common authentication methods like LDAP and Active Directory. However, as with many open source projects, OpenVPN’s UI/UX is not as user-centric as its competitors. Setup and configuration can be difficult and connections unreliable. OpenVPN Access Server is an affordable way for small businesses to get AWS VPN security for their cloud resources.

Between these two extremes, you can find AWS VPN solutions from Barracuda Networks, Aviatrix Systems, and other enterprise security providers. However, all of these solutions rely on traditional VPN technologies which impose limits on the flexibility and security of your AWS-hosted resources.

VPN Shows its Age

Traditional VPN technologies were first developed when corporate networks were much more centralized and only a relatively small number of trusted employees needed remote access. By relying on a trust-based security paradigm, VPN architectures assume that the on-premises network is safely protected by a secure perimeter. Furthermore, they assume that anyone and any device authenticated to access the network remotely has the same level of trust as anything in your server rack.

This approach no longer works in the modern IT environment. The strategic benefits of AWS and other cloud services make the security perimeter more nebulous as more company resources move beyond on-premises networks. The question of trust has become just as nebulous. The devices attempting to connect remotely to the network may not be managed devices as more employees take advantage of bring-your-own-device policies. And remote access, once limited to a handful of trusted employees, must now be granted to a dynamic mix of employees, individual contractors, and third-party partners.

Faced with the demands of this complex and dynamic environment, administrators must devote an increasing amount of time to managing VPN-based security systems. DevOps teams, in particular, suffer from the inefficiencies that brittle, inflexible VPN policies impose on their operations.

Remove Trust for Better AWS Security

Rather than relying on VPN’s thirty-year-old security paradigm, modern security systems based on the principle of zero-trust deliver more flexible, responsive, and scalable access to both on-premises and cloud-based resources.

The zero-trust paradigm assumes that nothing on a network, or even the network itself, is trustworthy. Every incoming connection request – whether from an on-premises computer or a remote device, from an employee or a contractor – must be authenticated and its compliance with access control policies evaluated. Only with authentication of the device and the end-user will a zero-trust security system permit a connection to the company’s resources. Zero-trust is the framework used to build software-defined perimeter (SDP) network security systems. In an SDP, all resources are “black” and hidden from anything on the network until an authorized connection is made.

Twingate Provides Frictionless AWS Security

Twingate’s implementation of a zero-trust SDP operates on a need-to-know basis. All resources, whether on-premises or in the cloud, are hidden behind Twingate’s SDP Access Nodes. Whereas AWS VPNs must advertise their presence on the public internet, the SDP Access Node is invisible. Even if an Access Node gets a connection request, it only accepts requests coming from the Twingate SDP Controller. It is the Controller that handles authentication and evaluates compliance with the access control policies set in your existing security stack. 

The SDP Client app running on end-users’ devices has no information about the existence of company resources, much less their location. When the Client initiates a connection request, it provides the end-user’s MFA credentials and the device’s status. Once authenticated and approved, the Access Node and Client connect through an encrypted tunnel. Once the session ends, the Client loses all information about the resource. Any attempt to reconnect requires re-authentication and approval from the Controller.

Unlike traditional VPN technology’s inflexible constraints, Twingate’s SDP solution is ideal for the dynamic environment of modern DevOps teams. Administrators can onboard and offboard end-users with a single click as they join and leave projects. Provisioning the Client is touch-free as end-users follow a consumer-like installation process.

Another advantage of Twingate’s security solution is support for all TCP or UDP traffic. This makes Twingate’s Access Nodes easy to deploy without modifications to resources like AWS-hosted services. No modifications are needed on the end-user’s side either. Device settings do not need to change and the users themselves do not need to change the way they access and use resources.

From the end-user’s standpoint, Twingate’s SDP solution is much easier than VPN security. They don’t have to connect to different VPN gateways to access different resources. The SDP Controller evaluates end-users’ permissions and connects them to the specific resources they are allowed to access. And since their connections are not being backhauled by a single VPN gateway, they experience faster connections to AWS and can be more productive.

To learn more about how Twingate makes your AWS resources more secure, contact us.

Get the latest stories and tips from Hotspot Shield in your inbox