AWS Client VPN rules belong at the resource, not the subnet

Staff need to reach one application in the VPC and must not reach the database listener on the same instance, so someone adds a second public subnet for the VPN endpoint and calls the requirement met. Subnet placement changes routing and availability. It does not grant or withhold a single port. The permission that expresses the requirement lives at the destination, in the resource's security group, and the VPN boundary supplies the handle that rule refers to.

Subnet placement is routing, not authorization

Where the endpoint's network association sits decides which route table carries the client traffic and which availability zones survive a failure. It says nothing about which port on which instance that traffic may reach. Two clients associated with the same subnet still arrive with the same source identity, and the resource cannot tell them apart by subnet name.

Start from the requirement instead: who calls, which resource, which service port, and which direction. Then choose the rule model that can express those four things at the destination. That framing usually removes the extra subnet from the design entirely.

The Client VPN association group is the handle

For a subnet-associated AWS Client VPN endpoint, the documented arrangement is specific. Apply the intended security group to the endpoint's target-network associations, then permit the required traffic in the resource's security group using that Client VPN group as the source.

Concretely, the application instance's group allows the application port from the association group, and nothing else. AWS's resource-access procedure describes that relationship, and it is worth keeping the same group policy across every subnet the endpoint associates with, because a stale association with a different group quietly widens the boundary.

That rule does not authenticate anyone. Login is a separate control, and the route to the resource is a third one. All three have to hold before a request arrives. Whichever one fails decides which fix is correct, and a rule change is the right answer for only the first.

What one association group cannot tell apart

Every client behind the same association group reaches the resource as the same security-group source. Two users with different roles are indistinguishable at that layer, no matter how the group is named or tagged. Client VPN's external-group authorization scopes access by destination prefix for a directory or SAML group, which is coarser than a resource role and should be treated as a network boundary rather than an identity system.

Finer distinctions belong to the application. A database listener that must stay closed to most staff is better protected by not being reachable on the permitted prefix at all than by hoping the group membership stays tidy.

Renaming the group does not create an identity, and duplicating it per team only multiplies the associations to audit.

Do not copy that rule to every VPN design

A self-managed EC2 VPN gateway, a routed inspection appliance and managed Client VPN are three different packet paths. Establish which source address actually reaches the resource, whether translation happens in between, and which reference mechanisms the service supports on that path.

Forwarding traffic through a middlebox does not preserve a source security-group reference the way direct instance-to-instance traffic does. AWS documents that such designs may need the appropriate private source addresses or CIDRs instead of a group reference. The managed Client VPN procedure is not evidence that every gateway's attached group works as a universal identity token for forwarded packets.

A NAT hop on the path is enough to break the assumption, and the failure looks like a rule that is present but never matches.

Review the effective boundary

Read every security group attached to the resource, because allow rules combine and a narrow rule does not cancel a broader one on another group. Then check the network ACL, the host firewall and the application's own authorization, which are separate layers with separate mistakes.

Finish with one permitted request and one deliberately excluded request against the same resource. The pair proves the boundary, while a single successful connection proves only that something is open. Confirm the route, the effective source and the intended service port rather than the subnet that contains the endpoint.

Order of work: write the four-part requirement, attach the group to the associations, scope the resource rule to the port, verify one allow and one deny, and only then consider dividing subnets for routing reasons.