We are trying to integrate Genesys Cloud with a strict third-party Quality Management tool via Web Services Data Actions.
The vendor’s infosec team is demanding a static IP address or a very narrow subnet range to whitelist in their firewall for incoming REST API requests from our Genesys Cloud org. I provided them with the AWS NAT Gateway IPs listed in the Genesys Cloud Resource Center, but they rejected them because the list covers multiple /18 subnets, which they deem ‘too broad’ for their security policy.
Is there a way to force Data Actions to route through a single static IP, or do we have to build our own proxy server?
I’ve explored this extensively for our biometric integrations. The short answer is: Genesys Cloud is a multi-tenant SaaS platform hosted on AWS. The Data Action microservices scale dynamically across multiple Availability Zones, which is why the published IP ranges are so broad. There is no native feature to assign a dedicated, static egress IP for your specific org’s Data Actions.
You absolutely have to build a proxy. We use an AWS API Gateway with an Elastic IP as a middleware layer. Genesys calls the proxy, the proxy presents the single static IP to the vendor. It’s the only way to satisfy rigid firewall policies.
We had this exact argument with our WFM vendor!
If building an AWS proxy is too much overhead, another alternative is to leverage a ‘Private Data Action’. If the third-party vendor can establish an AWS PrivateLink connection or a VPN tunnel to your corporate network, you can route the Data Action to a Genesys Cloud ‘Edge’ server (if you have BYOC-Premises) using a Local Data Action. The request will then egress from your corporate network’s static IP, which the vendor can whitelist. But for pure cloud-to-cloud integrations, The point above is correct: you need a middleware proxy.