# Lambda in a VPC: add a network path to Neon
## The trap
Put a Lambda function in a VPC (usually for ElastiCache or RDS access) and its Neon connections start timing out. 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.
## The rule
- 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.
- If you do not need the VPC at all, take the function out of the VPC; it is the simplest fix.
- Verify with a minimal test: from the same VPC config, `curl` an HTTPS URL. If that fails too, it is the network, not Postgres.
## 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.