I would like an HTTP request to originate from outside of AWS and reach a Neptune Graph.
Since a Neptune Graph can exist only within a VPC (and within a private subnet, at that), I'm exploring options for non-AWS traffic to reach the graph. The intent is not to circumvent security or create data exposure risks, but rather to find one (or more) functional ways that a query can originate from a non-AWS resource, be evaluated by Neptune, and have response data transferred back to the client.
This was a promising lead, but looks to be outdated – it was last updated 3 years ago, and does not align with things I see in AWS console today. I'm unable to create either an ALB or NLB directly in front of a Neptune endpoint (specifically, the "target group" is the point where next step is unclear).
There are several potential ways forward, including:
- create a Lambda function in front of the graph (possibly following an architecture like this)
- create an Elastic IP and associate somehow to Neptune, then create an NLB or ALB with a target group tied to that IP
- create an EC2 instance running HAProxy, then NLB or ALB routing traffic to that EC2 instance (which in turn routes to the graph)
I'm not sure which of those might be better or worse (and for what reasons), or if there are other solutions that might work as well (or better).
So, how can this work?
EDIT: after Kelvin raising this in their answer below, I'll add that actual traffic would likely be in the form of non-Lambda cloud functions (such as Cloudflare Workers). No ad hoc queries allowed from clients, but instead pre-defined queries wrapped in a deployed function, with optional parameters.