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¶