OpenVPN on AWS¶

Part of the OpenVPN Comprehensive Guide. The original note here was a single link to a 2015 third-party blog post about running OpenVPN on an EC2 instance — that approach still works, but it's worth knowing there's now also a fully managed alternative. Pick based on how much you want to own.

Option A: Self-managed OpenVPN on an EC2 instance¶

Same setup as openvpn-installation.md and openvpn-server-configuration.md, just running on an EC2 box instead of on-prem hardware. AWS-specific bits to get right:

Security group: allow inbound UDP (or TCP, matching proto in server.conf) on your VPN port from 0.0.0.0/0 (or a narrower source if clients have stable IPs), plus SSH from wherever you administer it from. Everything else stays closed — the tunnel itself is what carries traffic to internal resources, not the security group.
Elastic IP: attach one to the instance so remote in client configs doesn't break on an instance stop/start (which changes the default public IP). Point a DNS record at the Elastic IP rather than hardcoding it in client configs, so you can rotate the underlying IP later without touching every client.
Source/dest check: if this instance is meant to route traffic onward into a VPC (not just terminate the tunnel for internet egress), disable "Source/Destination Check" on the instance — AWS drops traffic where the instance isn't the recognized source/destination by default, which silently breaks VPN routing otherwise.
IP forwarding: enable it at the OS level too (net.ipv4.ip_forward=1 in /etc/sysctl.conf) if clients need to reach anything beyond the instance itself.

This is the right choice if you want the exact same OpenVPN setup and config format across on-prem and cloud, or you're already running the rest of this guide set's config elsewhere and just want a cloud-hosted peer.

Option B: AWS Client VPN (managed service)¶

AWS also offers a managed OpenVPN-protocol-compatible service (Client VPN) that handles the server side, HA, and scaling for you — you configure endpoints, associate them with subnets, and authenticate via either mutual TLS (same cert-based model as this guide set) or federated identity (SAML/AD). No instance to patch, no systemd units, no manually managed CRL.

Trade-offs versus self-managed:

You lose direct config-file control — no hand-editing server.conf, hardening choices are whatever AWS exposes as options.
Billed per connection-hour plus per-subnet-association-hour, which adds up differently than a flat EC2 instance cost depending on usage pattern.
Client-side, AWS Client VPN uses a client compatible with standard OpenVPN config import, so the client-side steps in openvpn-client-configuration.md are largely reusable.

This is the better choice if you'd rather not own patching/scaling a VPN instance yourself and the reduced config flexibility is an acceptable trade.

OpenVPN on AWS¶

Option A: Self-managed OpenVPN on an EC2 instance¶

Option B: AWS Client VPN (managed service)¶

Further reading¶