AWS Client VPN auth: IAM permissions are not a login method
Console permissions do not authenticate a tunnel. Compare certificate, AD and SAML methods, then see when SSM port forwarding fits one private database.
Granting a user permission to create or describe an AWS Client VPN endpoint does not let that user connect to it. The two are different kinds of identity: IAM governs AWS API calls, and the endpoint accepts only the client-authentication methods configured on it. So a user can hold broad console rights and still have nothing the VPN client can present. Decide which method the endpoint trusts, then decide whether a full tunnel is the right shape for the access you are granting.
An API identity is not a tunnel identity
When someone says "the IAM role is attached, why is the VPN still failing", the answer is usually that no step in the connection flow ever reads that role. The client presents a certificate, an AD username and password, or a SAML assertion. The endpoint validates one of those and then assigns an address.
IAM still matters, just later and elsewhere: creating the endpoint, associating subnets, publishing routes and writing authorization rules are API actions. Keep those permissions scoped to the operators who need them instead of handing every user the ability to rewrite the endpoint's access rules.
Pick from the methods the endpoint supports
AWS Client VPN accepts certificate-based mutual authentication, Active Directory authentication, and SAML-based federated authentication. A server certificate is required no matter which client method you choose, and a configuration that combines methods requires both to succeed, not either.
| Client method | What the user presents | Where the work sits |
|---|---|---|
| Mutual certificate | A client certificate the endpoint trusts | Certificate authority, issuing and revoking per user |
| Active Directory | Domain credentials | Directory reachable from the endpoint's VPC |
| SAML federation | An assertion from an identity provider | IdP application, attribute mapping, client support |
Certificates are the cheapest to stand up and the easiest to get wrong at scale, because every user needs a credential and every departure needs a revocation. Directory authentication moves that lifecycle to an existing system. Federation moves it to an identity provider and adds a browser step to the client.
Read the endpoint's own configuration before debugging the client. If mutual authentication is enabled alongside a user-based method, a client with a valid certificate but no directory account will still fail, and the error usually looks like a generic handshake problem.
Federation is not passing access keys
A SAML setup does not feed IAM access keys or an assumed-role token into the tunnel. The identity provider authenticates the person, returns an assertion, and the endpoint accepts it under the trust you configured. The session that results is a VPN session, not an AWS API session.
That distinction decides who can troubleshoot what. IdP problems show up as a browser or client error before any tunnel exists, while tunnel problems show up after a successful assertion. Ask which of the two you are looking at before opening either console.
After login, routes and authorization still decide
Authentication gets a session an address; it does not get the session a destination. Endpoint routes tell the client which subnets to send, authorization rules decide which users may reach which of those subnets, and security groups plus the target's own permissions decide the rest.
This is why a user who authenticates successfully can still fail to reach a database. Check the route table association for the subnet, the authorization rule for the user's group, and the security group on the target in that order, because each one produces a different kind of timeout.
For one private database, compare with port forwarding
If the real task is one approved connection to one private database, a full network tunnel is a choice rather than a requirement. AWS Systems Manager Session Manager can open a port-forwarding session to a managed node through IAM, and that node reaches the database on the private network. The user never receives a VPC address. The managed node becomes the only host that can reach the database port, which is usually what the security review was asking for. Users then need a local client and a session command rather than a VPN profile.
The trade is scope against prerequisites. Port forwarding needs the SSM agent on the managed node, network reachability from that node to the database, the Session Manager plugin on the user's machine, and permission to start that specific session. It is not a route into every subnet, and it will not carry arbitrary protocols the way a tunnel does.
Keep the database's own identity in place either way. TLS verification and database authentication do not disappear because the path was authorized by IAM, and an approved session says nothing about which tables the user may read.
Choose on scope and lifecycle: a tunnel when many users need many destinations and you can run certificate or directory lifecycle, a forwarding session when a handful of people need one service and you would rather not hand out network addresses. Either way, record the authentication method, the authorization rule and the database login as three separate facts, because they fail separately.