Restore required egress deliberately after connecting Lambda to a VPC

A public subnet selection alone does not provide internet access to the function.

Source facts

AWS explains that adding a customer VPC configuration changes a Lambda function’s connectivity to that VPC unless an appropriate internet path is provided. Its internet-access procedure uses private subnets and the necessary routing resources. Connecting the function to a public subnet does not itself give the function internet access.

Source: AWS Documentation.

Applicability

This concerns a VPC-connected Lambda function that needs approved external connectivity, with address-family and network design requirements checked separately.

DSE recommendation

DSE recommends listing external dependencies before changing the function network configuration. Distinguish private service access from public internet access, and review routes, NAT or relevant endpoint choices with the network owner. Keep security-group and DNS requirements alongside the subnet selection. Test the real dependency rather than only a generic website. Preserve the previous configuration and define how a failed deployment will be rolled back without exposing private resources more broadly. Create a dependency table that names the destination, DNS expectation and approved route owner. Have the application team identify which calls are essential during startup and failure recovery, then choose a bounded connectivity test for each before approving the network change.

Verification

Proposed verification: use an approved test function to reach its required private resource and harmless external endpoint. Inspect the selected subnet routes and observed failure stage if either call fails. Confirm an unapproved destination remains restricted according to the intended egress policy.

Official reference

AWS Documentation. Reviewed October 20, 2026.