We currently employ a sequence of three lambda functions coordinated by SQS for passing details. These functions are:
Authentication Lambda: This handles authorization and forwards session details to the downstream SQS.
Metadata Lambda: It retrieves document metadata and forwards session details to the downstream SQS.
Download Lambda: Responsible for downloading documents.
Presently, we aim to utilize a web portal to access and download documents via an API. The issue arises when the Auth lambda transfers session details to the Metadata lambda, which results in a 403 error. However, when I consolidate all three lambdas into a single lambda code, it functions correctly. I suspect that there may be an IP address or CIDR range restriction implemented on the portal's side. When I submit requests from the same IP range, it directs me to the same web server. Yet, if I employ a different IP range for the Metadata or Download lambda, it routes to a different web server.
How can we address this challenge while adhering to the existing design pattern of using three lambdas?
I tried
Placed all the lambdas in same private subnet and routing all traffic to public subnet. Using NAT gateway, accessing the internet. This approach is working fine but we are using public subnet with limit range of IP address. So, there is a possibility that portal can block the requests from same ip range.
You already described the solution to the problem:
Placed all the lambdas in same private subnet and routing all traffic to public subnet. Using NAT gateway, accessing the internet. This approach is working fine...
There seems to be a misunderstanding though.
but we are using public subnet with limit range of IP address. So, there is a possibility that portal can block the requests from same ip range.
The NAT Gateway will always use the same public IP (it's an Elastic IP that you provision). That public IP is independent of your public subnet, AWS will just route traffic to the NAT gateway associated with it.
If the portal blocks that, you could create a new NAT gateway with a different elastic IP. It's unlikely that the portal will put all AWS CIDR ranges on the blocklist.