We are running n8n inside an AWS VPC, on private subnets, as we would like to avoid giving n8n a public IP.
We’d also like to use SNS as a workflow trigger, but considering that the underlying SNS topic triggers use HTTPS subscriptions that post to the n8n webhook API under the hood, Amazon SNS will be unable to route packets to our non-Internet facing n8n server.
One solution I can think is adding support for Interface VPC Endpoints on the AWS n8n nodes types. This would inherently allow an internal n8n host to communicate to AWS APIs without ever leaving the VPC network.
In case anyone is unfamiliar with AWS VPC interface endpoints, you can read more about them here: Amazon Virtual Private Cloud
I glanced over the code to establish if this would be a simple enough change that I could make, and I came across the generic S3 node type allows for a custom endpoint to be specified.
Presumably, the incentive for a separate “S3” node type was for supporting non-AWS backends. However, looking at it now, it should also handle custom AWS endpoints (such as VPC interfaces/gateway endpoints in this case) since the hostname can be set to anything.
If an equivalent of that generic S3 node type existed for SNS, that would, in theory, allow me to do what I want.
What do you guys think is the right approach - add more generic AWS node types or add support for custom endpoints to the existing implementations such as AWS SNS, AWS SES, AWS S3, etc.? (potentially making the generic S3 node type obsolete in the process)
Hi @jan / @RicardoE105 - thanks for having a look at the PR. I’ve left a comment on it and was wondering if either of you have any thoughts so I can go ahead and add in the requested changes.
