AWS Client VPN or a VPN on EC2: an operating runbook

Both options give your team a remote-access VPN, so the interesting question is not which one exists but which one you can operate. The difference is who owns the endpoint at 3 a.m. and which controls you can reach when something breaks. Work the five steps below in order, because each one can end the comparison early. Skipping the inventory step is how teams end up migrating twice.

Step 1: write the requirement before the bill

You need five facts on one page: who authenticates and against what, which client platforms must work, which private destinations are reachable, what availability you promised, and what the traffic actually looks like. Without those, every later comparison turns into a feature list argument.

Be concrete about destinations. "Access to the VPC" usually means three different things: the VPC CIDR, a peered network, and an on-premises range behind a Transit Gateway. A managed endpoint can reach all three, but each one needs a route and an authorization rule, and each one is a separate line in your requirement.

Step 2: enumerate what already runs

Before designing anything, list the existing endpoints and any EC2-hosted server with its security groups. These calls are read-only and safe to run from an account with describe permissions.

aws ec2 describe-client-vpn-endpoints
aws ec2 describe-client-vpn-authorization-rules --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-routes --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-client-vpn-connections --client-vpn-endpoint-id cvpn-endpoint-xxxx
aws ec2 describe-instances --filters Name=tag:role,Values=vpn

Read the output as a map of what clients can already reach. A missing authorization rule explains a failure that looks like a routing problem, and an endpoint associated with one subnet explains why a zone failure took the whole service down.

Record the security groups attached to any self-hosted instance as well. Those rules are part of the access model, and they are the first thing that silently breaks when someone rebuilds an instance from a template.

Step 3: split the responsibilities

The managed service owns the endpoint fleet, its patching and its availability inside the region. You own identity enrollment, authorization rules, the network paths behind the endpoint, logging configuration and the decision about how many subnets to associate.

Self-hosting inverts that. You own the guest operating system, the VPN daemon and its configuration, certificates and keys, backups, monitoring and recovery. The EC2 security model puts guest and application security on the customer, and a VPN server is a guest like any other.

Write the split down as a table with names in the right-hand column. If nobody's name lands next to certificate renewal, that is the finding, and it matters more than the hourly difference.

Step 4: compare against a workload you can describe

Cost follows shape, not size. For the managed option, count endpoint association hours, client connection hours, transfer, and the identity and logging services you enable. For self-hosting, count compute, storage, networking, licensing and the engineering time that keeps the server patched. Put both sets of numbers in one sheet with the same time horizon. A three-year comparison that ignores patching hours will always favour the server you already own.

Performance comparisons need the same discipline. One interactive desktop session, one large transfer and fifty concurrent small requests stress different parts of the path: CPU for encryption, the instance network capability, the client's own stack, and the destination. Test with representative clients and the same task on both designs.

A larger instance is not proof that a transfer will be faster, and one successful session is not a capacity plan. Treat any instance-family folklore you inherit as a hypothesis to test, not a purchasing rule.

Step 5: cut over with a rollback you have run

Run both endpoints in parallel for a defined period, distribute the new client profile to a small group first, and keep the old endpoint's authorization rules untouched until the group has used the new one for real work. Rollback is a profile switch, not a rebuild, so decide now where the old profile lives.

Verify in this order: authentication succeeds, the client receives the expected routes, an authorized destination answers, an unauthorized destination fails, and logs show both events. If any step fails, stop and fix that step rather than moving to the next client group. Write down the result of each check, because a cutover remembered only as worked cannot be debugged a month later.

After cutover, schedule the boring checks: certificate expiry, association count, authorization rules that no longer match a group, and the connection count against your expectation. The Client VPN administration guide is the reference for the endpoint, authentication and routing pieces you configured.