**TL;DR:** Lambda in a VPC has no internet route by default, so connections to Neon hang until timeout. The fix is networking, not the connection string. Agents rotate passwords, switch pooled/direct, and raise timeouts, but the packets never leave the VPC: no NAT gateway means no route to Neon's public endpoints. Checklist - Timeouts only from VPC-attached functions, fine from local: suspect NAT. - Keep the pooled connection string regardless; this is orthogonal to pooling. - Security groups must allow outbound 5432 and 443.

## The fix

1. Lambda in a VPC needs a NAT gateway (or VPC endpoints, which do not apply to Neon) in a public subnet, with the function's subnets private and routed through it.

2. If you do not need the VPC at all, take the function out of the VPC; it is the simplest fix.

3. Verify with a minimal test: from the same VPC config, `curl` an HTTPS URL. If that fails too, it is the network, not Postgres.

4. Timeouts only from VPC-attached functions, fine from local: suspect NAT.

5. Keep the pooled connection string regardless; this is orthogonal to pooling.

6. Security groups must allow outbound 5432 and 443.

## When to use this

- This covers exactly what the title says: Neon + Lambda in a VPC.
- You are setting this up for the first time, or auditing an existing setup.
- You want the key gotchas in one place before you start.

## When not to use this

- You are doing a different workflow with Neon; these steps are specific to the title above.
- You need the full reference docs; this is the short path, not the manual.

## Compatibility

- Not pinned to a specific version; follows current Neon behavior.