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.


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.

You must [...] specify an Elastic IP address to associate with the NAT gateway when you create it.


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.

| improve this answer | |
  • Will a NAT Gateway work when the outbound IP needs to be whitelisted? Are NAT Gateway public IP addresses static? – Matt Houser Feb 26 '16 at 21:25
  • Thanks, @MattHouser. Good point, and worth an explicit mention. Added. NAT instances also "can" have a static IP, or can be used with one from the pool that changes every time the NAT instance is stopped and started, so for NAT instances, it isn't mandatory as it is with a NAT Gateway. – Michael - sqlbot Feb 26 '16 at 22:20
  • Some extra notes: The instances CAN still have public IP addresses, but they will be inaccessible. And I was confused about the line "Your ELB cannot be on the same subnet as the instances" and stupidly moved my ELB to different Availability Zones, which breaks things. The trick is to manually create new (or already have), Public subnets within the same Availability Zone as the subnets that are going private. This makes everything copacetic. – Offlein Apr 15 at 0:51

Good News - Amazon added a new type of Load Balancer for this (Network Load Balancer). You can assign an Elastic IP Address to it and voila - static IP for the load balancer!

It works on the TCP protocol rather than HTTP so you can't do SSL on the load balancer (each web server will need certificate) and it doesn't have the "Stickiness" option (but it's very sticky). Other than that it works just like the "Application" load balancer.

| improve this answer | |
  • 2
    NLB is the complete opposite of what the question is asking about. – womble Jan 12 '18 at 5:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.