Sometimes you need to reach a database or internal service that sits in a private subnet. AWS has managed solutions for this - Client VPN, Site-to-Site VPN, PrivateLink - but they come with configuration overhead and cost that doesn’t make sense for a solo developer or small team.
A t3.micro running OpenVPN does the job.
Why a bastion VPN
Private subnets exist for a reason. RDS instances, internal APIs, and admin dashboards shouldn’t have public IPs. But you still need to reach them from your laptop for development, debugging, and database management.
SSH tunnels work for one-off access to a single port. When you need to access multiple services across private subnets - a database on one, an internal API on another, an admin panel on a third - tunnelling each one individually gets tedious fast.
A VPN connection routes your traffic through the bastion and into the VPC. Every private resource becomes reachable as if you were inside the network. One connection, all services.
The setup
An EC2 instance in a public subnet with OpenVPN Access Server installed. Security groups restrict inbound traffic to the VPN port and SSH from known IPs. The instance gets an Elastic IP so the VPN endpoint doesn’t change on restarts.
OpenVPN Access Server handles user management, certificate generation, and client configuration. You download a .ovpn profile from the admin panel, import it into any OpenVPN client, and connect. No manual certificate wrangling.
The instance itself is small. VPN traffic for a few developers doesn’t need compute power. A t3.micro handles it with headroom to spare.
Routing
The key configuration is telling the VPN to push routes for your VPC CIDR range. When connected, your laptop’s traffic to 10.x.x.x addresses routes through the VPN tunnel to the bastion, which forwards it into the VPC. Traffic to everything else goes through your normal internet connection.
Split tunnelling keeps things fast. Only traffic destined for the VPC goes through the tunnel. Everything else - web browsing, video calls, package downloads - uses your local connection.
What it replaced
Before the VPN, access to private resources meant SSH tunnels through a bastion. Each service needed its own tunnel command. Forget to start one and your database client throws a connection error. Start too many and you lose track of which local port maps to which service.
The VPN replaced all of that with a single connection toggle.
Cost
A t3.micro in eu-west-2 costs a few dollars a month. The Elastic IP is free while the instance is running. OpenVPN Access Server is free for up to two concurrent connections, which covers solo development. That’s cheaper than AWS Client VPN’s per-connection-hour pricing.
When to use something else
This approach works for small teams and solo projects. If you need to support dozens of concurrent connections, enforce per-user access policies, integrate with corporate SSO, or meet compliance requirements for network access logging, look at AWS Client VPN or a proper zero-trust solution.
For reaching your staging database from your laptop, the EC2 bastion does the job without the overhead.