how can an AWS Neptune Graph be queried via public HTTP?

Question

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.

Answer 1

Many of the approaches that you mentioned are commonly used (ALB, NLB, Lambda). You could also create a REST API using API Gateway (that invokes a Lambda that talks to Neptune) or create a GraphQL API using AppSync. In total there are probably more than a dozen ways that you can establish such a connection.

In part, it depends on where your clients will be. Public Internet vs from inside an enterprise for example. It also depends on whether you wish to allow people to send actual queries against the database or you wish to provide an API that users call that prevents the issuing of direct queries.