Accepting VPC Remote Access Needs Denial Tests

Acceptance for remote access is a table of expected outcomes, not a screenshot of a working page. For each group, write what should succeed and what should fail, then run both against dedicated test identities in a controlled window. The denials are the part that proves the boundary; a successful login only proves the tunnel exists. All of this works with the VPN product already chosen.

Use separate accounts for the tests, and label them so nobody mistakes a test identity for a real exception.

Write the Boundary as Expected Results

Start from the roles rather than the components: who needs which service, from where, and with which identity. Take an illustrative VPC: one group needs staging over HTTPS, another needs a production database, and a third and smaller group administers the gateway itself. Each row gets an expected allow and an expected deny, including the neighbouring service and the neighbouring account that should not work. That table is the acceptance criterion, and people who do not run the tests can review it.

Test the database login separately from the network path. A reachable TCP port should not make an unapproved database account succeed, and VPN membership should not create a cloud IAM role or grant administrative API access. Those are three independent controls, and they fail independently.

Route Is Not Authorization

A route makes a path possible; it does not grant permission. Withholding a route is a weak stand-in for a restriction enforced at the destination, since a client can always add a route of its own. The security group, the database grant and the application's own authorization remain the controls that decide. When a test unexpectedly succeeds, look first at the destination's policy rather than at the routing table you intended the client to have.

That is also why the deny tests target the server side: those results cannot be changed by editing the client.

Which Source Does the Control Actually See?

The source address a control evaluates depends on the gateway architecture. An EC2-hosted gateway may forward a routed pool, translate to its own address, or present a different address after NAT; managed Client VPN associates with a subnet and follows its own model. Security groups and network ACLs see whatever arrives after that processing. Inspecting a rule against the wrong source assumption is a common way to build a boundary that looks correct and admits the wrong traffic.

Correlate each result with the smallest useful event: identity and session, resource, operation, time and the decision. A CloudTrail API call, a VPC flow record and a VPN session log answer different questions, and none alone is an application audit.

Retire an Identity and Test It Again

Include retirement in the same table. Remove a test identity, confirm that a new session is refused, then confirm separately how existing sessions are treated, because those are different behaviours with different owners. Check what happens after a gateway restart or replacement, so a hand-added exception does not vanish silently or return broader. A boundary that lasts only until the next deployment is not a boundary.

None of this replaces patching, recovery or credential lifecycle work. It makes a narrower promise measurable: the right people reach the right services, while nearby routes, accounts and management surfaces stay outside the grant.

Keep the table with the deployment and re-run it when the gateway changes. The tests are cheap; the assumptions behind them are not.