AWS Client VPN client CIDR cannot overlap the VPC range

An AWS Client VPN endpoint hands out client addresses from a pool you choose, and AWS checks that pool against the target network before it creates the endpoint. The check is not whether a subnet looks free. It is whether the pool overlaps the VPC range, and the answer is the same whether or not an EC2 instance happens to use those addresses today. Overlap is a question about ranges, not about allocations.

Work through five checks in order. Stop at the first one that fails, because none of the later steps can repair an earlier decision.

Overlap is a range test, not a free-address test

Start from the VPC CIDR, not from the subnet you plan to associate. A pool of 172.20.0.0/22 sits inside a VPC of 172.20.0.0/16 and is rejected even when no subnet occupies it, because overlap is a property of the ranges rather than of current allocations. Then add the destinations the endpoint routes to: peered VPCs, a transit gateway, on-premises ranges over a site-to-site connection. Any range a client may need to reach belongs in the list.

Collect them from the account instead of from memory: aws ec2 describe-vpcs --query "Vpcs[].CidrBlock", plus the route table entries for the subnet you intend to associate.

The pool size is decided before you build

AWS accepts an IPv4 client pool between /22 and /12 on Client VPN. A /24 is too small, a /8 is outside the documented range, and both mistakes come from sizing the pool like a workload subnet. Size it by expected concurrent clients plus headroom, then round to a permitted prefix.

Check the arithmetic before typing it into the console, because a mistyped prefix changes the pool size without any warning:

python3 -c "import ipaddress; p=ipaddress.ip_network('172.16.0.0/22'); print(p.num_addresses, p.prefixlen, p.overlaps(ipaddress.ip_network('172.20.0.0/16')))"

That prints the address count, the prefix length and whether the candidate collides with the VPC range, which is faster than reasoning about netmasks at the end of a change window.

The resolver has its own address role

The VPC resolver answers at the base address of the VPC range plus two, which is not necessarily inside the subnet you associated. Assuming the resolver has to live in the client pool, or building a subnet around that address, adds objects without changing anything. What matters is that the endpoint carries a DNS setting the client can apply and that the resolver is reachable from the tunnel.

Record the resolver, the client pool and the associated subnet as three separate items in the address plan. They fail independently, and one being right says nothing about the other two.

Four fields you commit to at creation

The client IPv4 CIDR is fixed at creation. Changing the DNS server, adding an association, swapping the security group, editing authorization rules or altering split-tunnel routes are all ordinary edits, and none of them rename the pool. That asymmetry is the reason this deserves a review: the cheap settings are the ones you will want to change later, and the expensive one is the one you commit to first. Read the endpoint description before you plan a change window.

Inspect the deployed endpoint before assuming a rebuild. aws ec2 describe-client-vpn-endpoints returns the pool, DNS, split-tunnel flag and associations in a single response, which is usually enough to rule out a rebuild.

Replace the endpoint instead of patching it

A new endpoint is a new endpoint, not a migration. Existing sessions do not move to it, client profiles point at a different name, and every setting you took for granted has to be recreated: server certificate, authentication, associations, routes, authorization groups, logging. Validate with one client against a required private service and against a destination that must be denied, then widen access. Anything you skip becomes a support ticket later.

Keep the old endpoint running until that validation passes, and keep an administrative path that does not depend on the new one.

One boundary worth stating: this covers the IPv4 client pool. Dual-stack and IPv6 traffic settings on Client VPN follow their own addressing model, so do not copy this checklist across without reading the documentation for that mode.