How Can a VPC Lambda Access S3 Without Public IP Addresses?
A CloudOps engineer needs to give an existing AWS Lambda function access to an existing Amazon S3 bucket. Traffic between the Lambda function and the S3 bucket must not use public IP addresses. The Lambda function has been configured to run in a VPC. Which solution will meet these requirements?
Community Insight
The question tests private AWS service connectivity from Lambda inside a VPC, and the trap is assuming a NAT gateway or transit gateway can reach S3 without public IP addresses.
A VPC-attached Lambda function can reach Amazon S3 privately through an S3 interface VPC endpoint, which places an elastic network interface in the Lambda subnet and supplies endpoint-specific DNS names. This page explains why that design satisfies the no-public-IP requirement and why NAT, transit gateway, and VPC sharing do not.
A common wrong choice is C: a NAT gateway does let a private Lambda subnet reach S3, but the traffic exits through the NAT gateway's public IP, so it violates the no-public-IP requirement.
Community Discussion (1 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Option D creates an S3 interface VPC endpoint, which provisions an elastic network interface with a private IP address in the Lambda function's subnet. AWS PrivateLink routes S3 traffic through that endpoint, so the Lambda function can reach the bucket without using an internet gateway or NAT gateway. The interface endpoint also provides endpoint-specific DNS names, which is why the option includes changing the Lambda function to use the new S3 DNS name. Bad_Mat's comment endorses this exact approach with the phrase "Create an S3 interface endpoint" and the follow-up step of changing the Lambda function's S3 DNS name.Why the Other Options Are Wrong
Option A misuses VPC sharing, which shares subnets between AWS accounts; it does not attach an S3 bucket to a VPC or create private connectivity to S3. Option B introduces a transit gateway, but a transit gateway connects VPCs, VPNs, and on-premises networks, not the S3 service endpoint itself, so it does not provide private S3 access by itself. Option C uses a NAT gateway, which lets private subnets reach the internet through a public NAT IP address; that fails the explicit requirement that traffic must not use public IP addresses. Option D is the only choice that establishes private IP connectivity to S3 from the Lambda VPC.Community Comment Notes
Only one learner comment is present, from Bad_Mat, and it selects option D by quoting "Create an S3 interface endpoint" and then noting the need to change the Lambda function to use the new S3 DNS name. That comment aligns with the AWS design for interface VPC endpoints, where the endpoint ENI and endpoint-specific DNS name are the key operational details. There is no meaningful vote distribution to analyze, so the verdict rests on the networking behavior of Lambda, VPC endpoints, and S3.Official Reference
Exam Strategy
When a VPC resource must reach an AWS service without public IP addresses, look for a VPC endpoint rather than a NAT gateway or transit gateway. For S3, remember that gateway endpoints use route tables while interface endpoints use ENIs and endpoint-specific DNS names, and match the option to the endpoint type offered.
Frequently Asked Questions
Why is a NAT gateway wrong for private Lambda-to-S3 traffic?
A NAT gateway routes traffic through a public NAT IP address, so the Lambda function would still use public IPs to reach S3 and would violate the no-public-IP requirement.
Does an S3 interface endpoint require changing the Lambda's S3 DNS name?
Yes. Interface endpoints provide endpoint-specific DNS names, so the Lambda function must use the new S3 DNS name to resolve to the private endpoint ENI.
Related Analysis
Practice All SOA-C03 Questions
Access 100 questions with complete answers and detailed explanations.
View Full SOA-C03 Practice Test →