AWS Certified Solutions Architect – Professional — Question 954

A company is migrating a subset of its application APIs from Amazon EC2 instances to run on a serverless infrastructure. The company has set up Amazon API
Gateway, AWS Lambda, and Amazon DynamoDB for the new application. The primary responsibility of the Lambda function is to obtain data from a third-party
Software as a Service (SaaS) provider. For consistency, the Lambda function is attached to the same virtual private cloud (VPC) as the original EC2 instances.
Test users report an inability to use this newly moved functionality, and the company is receiving 5xx errors from API Gateway. Monitoring reports from the SaaS provider shows that the requests never made it to its systems. The company notices that Amazon CloudWatch Logs are being generated by the Lambda functions. When the same functionality is tested against the EC2 systems, it works as expected.
What is causing the issue?

Answer options

• A. Lambda is in a subnet that does not have a NAT gateway attached to it to connect to the SaaS provider.
• B. The end-user application is misconfigured to continue using the endpoint backed by EC2 instances.
• C. The throttle limit set on API Gateway is too low and the requests are not making their way through.
• D. API Gateway does not have the necessary permissions to invoke Lambda.

Correct answer: A

Explanation

When an AWS Lambda function is configured to run inside a VPC, it does not have public IP addresses and cannot access the internet directly, even if placed in a public subnet. To access the external SaaS provider, the Lambda function must be placed in a private subnet with a route to a NAT gateway in a public subnet. Because CloudWatch logs are generated, we know API Gateway has the correct permissions to invoke Lambda, and the function is running but failing to establish an outbound network connection.