Replacing a Bastion Host with AWS Client VPN
Bastion hosts were once a staple of an IT infrastructure, whether it be on-prem or in the cloud. They allow for a single ingress point into the network. Access to them can be restricted to a limited number of IP addresses and authentication can include MFA. Bastion hosts can host tooling such as database clients and they can be used to establish an SSH tunnel so that clients who connect to them can access non-public resources behind the bastion host, such as a database or application server.
While bastions offer a number of advantages, they carry with them a certain amount of operational overhead:
- Bastion hosts need to be patched and upgraded.
- They need to be monitored to make sure they are available and that they are secure.
- The list of IP addresses that can access them needs to be constantly maintained since we don’t want to open SSH to the world.
- Bastion user accounts need to be maintained.
If your organization has many separate environments that need to allow connectivity, maintaining a fleet of bastions can consume a lot of time.
If you’re running your workloads in AWS and use a bastion host to connect to them, you have a few different options to replace the function of a bastion. Each approach comes with their advantages and disadvantages.
In our particular use case, we primarily use a bastion host to remotely connect to an RDS Aurora cluster and an Elasticache cluster running in private subnets. We run each environment of our application in its own AWS account, so there are multiple bastion hosts since we don’t want environments to share connectivity.
We took a look at AWS Systems Manager Session Manager as that offers connectivity to non-public instances without the use of a bastion host. Authentication to the hosts is integrated with AWS authentication. Allowlisting IP addresses isn’t really relevant in this approach since Session Manager isn’t vulnerable like having SSH port 22 open to the world. As great as Session Manager is, it does not allow connectivity to RDS or Elasticache without using an intermediary jump server. So we kept looking for a suitable solution.
We settled on AWS Client VPN as that addresses each of the operational overhead concerns listed above and it provides the functionality we need. We were able to set up one Client VPN in a central account that is connected to the workload VPC in various accounts through a Transit Gateway. Using Client VPN authorization rules, integration with a SAML-based IdP (AWS Identity Center in our case), and security groups, we were able to allow access to certain workload VPCs to certain users. Additionally, we were able to allow access to certain subnets in the VPCs. There is nothing to maintain or patch with Client VPN and MFA is enforced through our IdP.
Simple Client VPN Setup:
Multi-VPC setup:
The only caveat with switching from bastion hosts to Client VPN is about cost. Bastions are a fixed cost as they are instances that run all the time and can frequently be run on very small instances. Client VPN charges a constant rate for their endpoints, but there is also a per-hour fee for each client that is connected. That can add up quickly. You’ll want to insert a line in the ovpn file you distribute to your users. Specify inactive 120 to have the connection disconnect after 120 seconds of inactivity. Of course you can specify a value that works best for you.
While bastions have served us well for many years, we are more than happy to have reduced the EC2 instance count in our environments which drives our operational burden down and security posture up!