herokunetwork-programminghttp-proxy

Outbound Heroku requests to egress via NAT gateway in a peered AWS VPC


I have an app in Heroku that invokes a third-party service - lets call it 'XYZ' for this discussion. There are IP restrictions on the XYZ service.

Previously we were using MuleSoft for this integration (i.e. there is/was a Heroku experience API + an XYZ system API) and we were able to whitelist the MuleSoft IPs in XYZ.

We're looking to move away from MuleSoft (for reasons I won't go into, suffice to say; it's just not the right fit for the company at which I work), but I'm wondering how we can achieve the IP whitelisting to XYZ without MuleSoft in the picture.

I've found a few proxy add-ons in Heroku e.g. Proximo, Fixie, and QuotaGuard; but these all have a costs, and where I work it's always a bit of a hassle to bring in new vendors / costs.

We already have Heroku private space peering between Heroku and AWS, and the peered AWS VPC has a NAT gateway with a static IP. How would I get Heroku requests to XYZ to egress via the NAT gateway in my peered AWS VPC?

I'm thinking maybe I need to deploy a proxy of some sort into my AWS VPC (perhaps NGINX or a Lambda attached to my VPC) with a custom DNS that's resolvable from within Heroku. I then do some kind or URL rewriting of the request to the target XYZ service, which would egress via the NAT gateway... thoughts?


Solution

  • Unfortunately, Heroku's Private Spaces don't seem to be flexible enough for customized routing of packets. It looks like all packets from dynos to public IP addresses are routed through stable outbound IP addresses while only packets from dynos to the private address range for your VPC are routed through the peering.

    It might still be possible to run a tunnel/proxy server in your VPC and make its DNS records public so that the processes on dynos are able to resolve the tunnel/proxy server to its private IP addresses. It is also possible to run a DNS server at a stable private IP address in your VPC but one needs to be careful because the DNS server may become a single point of failure.