What actually changes for an AWS Lambda function when you attach it to a VPC, and what network resources does Lambda create to make that work?

## What VPC attachment is for By default a Lambda function runs in AWS-managed network space, with outbound internet access and reachability to public AWS service endpoints. That is the right default for most functions. You attach a function to a VPC for exactly one reason: it needs to reach something that has only a private address — an RDS instance, an ElastiCache cluster, an internal load balancer, a service on-premises across a VPN or Direct Connect. Attaching for any other reason buys you constraints with no benefit. ## The configuration Attachment is a function-level setting: a `VpcConfig` containing subnet IDs and security group IDs. ```bash aws lambda update-function-configuration \ --function-name order-writer \ --vpc-config 'SubnetIds=subnet-0a1b,subnet-0c2d,SecurityGroupIds=sg-0e3f' ``` Give it private subnets in at least two Availability Zones. If one AZ becomes impaired, or one subnet runs out of addresses, Lambda can still place traffic through the others. A single-subnet function is a single-AZ function. ## The network interfaces Lambda does not run your code inside your VPC in the way an EC2 instance sits inside it. Instead it creates elastic network interfaces in your subnets and connects execution environments to them through AWS's Hyperplane layer, a shared NAT-style fabric. Two consequences follow, and both are commonly asked: - **The interfaces are shared.** One ENI is not one concurrent execution. Lambda creates interfaces per unique combination of subnet and security group set, and many execution environments — including environments of *different* functions in the same account that happen to have the same VPC configuration — multiplex over them. The number scales with throughput, but far more slowly than concurrency does. - **They are created at configuration time.** The interfaces are provisioned when you create or update the function's VPC configuration, not on the invocation path. That is why a `update-function-configuration` call that changes VPC settings takes a while to reach an active state, and why scaling up no longer waits on interface creation. Because interfaces are real ENIs in your subnets, they consume private IP addresses from those subnets. A function that scales hard against a /28 subnet shared with other workloads can exhaust the pool, and the symptom is invocation failures rather than a slow function. Sizing the subnets for the peak, and keeping Lambda's subnets separate from instance subnets, is the practical mitigation. ## What behaves differently afterwards **Egress is now yours to route.** The function's interfaces have private addresses only. You cannot assign a public IP or an Elastic IP to them. Anything on the public internet — a third-party payment API, a webhook, a package registry — is reachable only if the subnet's route table sends `0.0.0.0/0` to a NAT gateway sitting in a public subnet. Public AWS service endpoints count as "the internet" for this purpose, so a VPC-attached function calling S3, Secrets Manager or DynamoDB needs either that NAT route or a VPC endpoint for the service. **Security groups apply.** The security group you attach governs the function's traffic. Because security groups are stateful, egress-only rules are usually enough on the Lambda side; the more common mistake is on the other end — the RDS instance's security group must allow inbound on the database port *from the Lambda security group*, which is how you express "only my function may connect". **DNS changes.** The function resolves through the VPC's Route 53 Resolver, so private hosted zones, VPC endpoint private DNS names, and resolver rules for on-premises zones all start working. This is often the actual reason a name resolves differently before and after attachment. **The execution role needs more.** Lambda manages the interfaces using your execution role's credentials, so it needs `ec2:CreateNetworkInterface`, `ec2:DescribeNetworkInterfaces` and `ec2:DeleteNetworkInterface`. Attach `AWSLambdaVPCAccessExecutionRole` — which also carries the basic CloudWatch Logs permissions — rather than hand-writing them. Without those permissions the function will not transition to an active state after you set the VPC config, and the error points at EC2, not at Lambda, which throws people off. ## The judgment an interviewer is listening for Attach only when a private resource requires it; keep the rest of the fleet outside the VPC. When you do attach, use multiple private subnets, size them for peak address consumption, plan the egress path deliberately, and remember that the security-group relationship with the database is the thing that actually enforces least privilege on the network path.