I have 3 web servers (ec2 instances) in a vpc public subnet, and they all have EIPs.
I have the usual Internet Gateway with the route to ensure those instances will be able to call external services, and a load balancer (ELB) rotating incoming traffic between those instances.
The main issue is that the application on the servers will connect to a lot of external services/APIs, but some of those services requires IP whitelisting. What we do now is to assign an EIP to an instance, go to the control panel of said service, add the new EIP and live on, but we're hitting a limit, both in numbers of EIPs available to our account (yes, I know it can be bumped, but still) and in how many IPs are whitelistable in those external services.
Given that we would like to keep things autoscalable I would like to ask for ideas on how to route all the instance generated traffic through a single EIPs without losing the current inner workings.
A fixed special route towards those services is not really flexible unless it's going to use DNS, mostly because we can't know in advance all their IP pools.
I've read up about NAT gateways, but I'm not sure if the Load Balacing portion of the architecture will remain up, if the web servers will be able to respond back to requests, etc.
Best Answer
Yes, you can use either a NAT Gateway or a NAT instance, in conjunction with an ELB... and that is the most sensible way to whitelist your internally-initiated, outbound traffic with external services.
A NAT gateway always has a static public IP address.
This configuration requires that the instances NOT have public IP addresses of their own, and NOT be on a public subnet with the default route pointing to Internet Gateway. The default route for the instance subnet needs to point to the NAT device, once it's configured.
In turn, this means your ELB cannot be on the same subnet as the instances, since the ELB subnet MUST have the Internet Gateway as its default route.
Response traffic from the instances is directed at the ELB's internal IP address, so it's not affected by the instances' subnet's default route, thus this configuration does not break reply traffic to ELB requests.
As strange as it seems to some, it is the standard configuration to place the ELBs on different subnets from the instances behind them. Unlike a conventional network where the router can be a bottleneck, there is no negative performance consideration related to the ELB and its balanced instances being on different subnets from each other. The entire VPC network is a software-defined, virtual network, so being on different subnets does not mean the traffic will be going through an unnecessary router, as it would mean on a physical Ethernet network. All traffic between instances follows a similar path through the VPC infrastructure.
See also Why do we need private subnets in VPC? on Stack Overflow.