What is causing the issue?
Lambda is in a subnet that does not have a NAT gateway attached to it to connect to the SaaS provider.
The end-user application is misconfigured to continue using the endpoint backed by EC2 instances.
The throttle limit set on API Gateway is too low and the requests are not making their way through.
API Gateway does not have the necessary permissions to invoke Lambda.
Explanations:
Lambda functions in a VPC need a NAT gateway to access the internet for external requests. If the Lambda function is in a subnet without a NAT gateway, it cannot reach the SaaS provider, leading to 5xx errors since the requests never leave the VPC.
If the end-user application were misconfigured, it would affect all functionality tied to the endpoint, not just the new Lambda function. Since the same functionality works with EC2, the issue is more likely related to network configuration rather than application misconfiguration.
A throttle limit being too low would lead to rate-limiting errors (429), not 5xx errors. Since monitoring indicates that requests never reached the SaaS provider, this option does not explain the observed issue.
If API Gateway lacked permissions to invoke Lambda, it would result in authorization errors (403), not 5xx errors. The fact that CloudWatch logs are being generated suggests that API Gateway can invoke the Lambda function, ruling this option out.
In my experience, the answer is:
Lambda is in a subnet that does not have a NAT gateway attached to it to connect to the SaaS provider.
From what I’ve seen, the answer is:
Lambda is in a subnet that does not have a NAT gateway attached to it to connect to the SaaS provider.