VPC connectivity for Lambda Managed Instances
Functions on LMI run in your VPC. You still need a deliberate path for outbound access: other AWS services (for example S3, DynamoDB), CloudWatch Logs, and X-Ray telemetry. Without it, those calls fail even when IAM allows them.
For step-by-step console flows and IPv4/IPv6 variants, use Networking for Lambda Managed Instances as the product reference.
Connectivity pattern
Section titled “Connectivity pattern”| Pattern | Idea | Typical trade-off |
|---|---|---|
| Public subnet + internet gateway | Instances reach the internet directly (IPv4 and/or IPv6; egress-only IPv6 if you want outbound-only) | Simple and low cost; mind inbound exposure if anything is truly public |
| VPC endpoints | Private attachment to supported AWS services; traffic stays on the AWS network | Strong isolation; per-endpoint and per-AZ cost; plan HA across AZs |
| Private subnet + NAT gateway | Private workloads; outbound IPv4 via NAT in a public subnet | Common enterprise shape; NAT hourly and data charges; IPv4-oriented |
Choosing
Section titled “Choosing”| If you prioritise… | Lean toward… |
|---|---|
| Speed and cost for experiments | Public subnet + IGW (with tight security groups) |
| Production isolation from the public internet | VPC endpoints for AWS APIs you use, and/or private subnets + NAT for general egress |
| No inbound from the internet | Private + NAT, or public subnet with controls; IPv6 egress-only IGW if IPv6 fits your services |
Subnet choice, route tables, security groups, and endpoint policies are part of capacity provider placement — see Placement & capacity.
See also
Section titled “See also” Placement & capacity Subnets, security groups, and provider boundaries where networking attaches.
Tenancy & isolation Trust boundaries and VPC posture for dedicated LMI capacity.
Decision guide & reference Patterns, constraints, and deeper comparison material.