I had everything working very nicely with a CloudFormation template that created an API Gateway with proxy integrations to Lambda functions, which in turn manipulated various DynamoDB tables.
Lately, though, I've started to experience the shortcomings of DynamoDB and it's read/write workers. So, I thought, I will enable DynamoDB DAX to speed things up with its caching.
I had no problems getting the CloudFormation template setup to build the DAX cluster.
But when I tried to connect to DAX from Lambda functions I get errors such as NoRouteException: not able to resolve address. Searching around, it turns out that since DAX is in a VPC, Lambda functions of course cannot access. The Lambda functions must also be in the VPC.
But if I put the Lambda functions in the VPC, then API Gateway cannot presumably access the Lambda functions via proxy integration.
So, how to orchestrate API Gateway -> Lambda -> DAX within the VPC?
It seems loopy that DAX cannot easily be used by the common API Gateway -> Lambda pattern. The VPC requirement is a real killer, and it really means that DAX is mostly only useful for EC2 instances, vs API -> Lambda.
Any ideas?
But if I put the Lambda functions in the VPC, then API Gateway cannot presumably access the Lambda functions via proxy integration.
That isn't correct. API Gateway accesses Lambda functions by invoking them using the Lambda service API, proxy or not, VPC or not.
API Gateway doesn't connect directly to the Lambda function container -- so the container placement (inside or outside VPC) doesn't impact API Gateway's ability to actually invoke the function -- it impacts what the function can access but not how it can be accessed.
Proxy integration modifies the behavior and handling of the payload, but not the way API Gateway actually connects to the Lambda service to invoke the function and receive the response.
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加