This would be for whitelist/whitelisting IPs. For example creating a security group on AWS that only allows 443 (https) traffic from a phabricator cluster to a jenkins instance.

Yes, that's correct.

@amckinley, I'd like to try to do this as part of T12798. Here's my rough understanding of what we need to do:

1. Launch something to serve as a gateway. Is this an actual instance, or some kind of virtual device that's more like an ELB? If it's an instance, do we run haproxy on it or, like, a perl script called nat.sh~.pl.bak or what?
2. Bind one of the spare EIPs to it to serve as its internet-facing public IPv4 address.
3. Configure some stuff on that thing (sorcery?).
4. Launch a new actual instance that we're going to NAT, which will eventually become repo025 or repo-ohtwentyfive or whatever if our luck holds, with no public IPv4 address.
5. Configure some stuff on the actual instance (wizardry?).
6. Now the instance connects to the internet through the NAT host/device, and the internet sees the instance as having the EIP. Networking!

Are those steps roughly accurate, as far as you know? In particular, some of my assumptions are:

• We can set up NAT on a host-by-host basis, and do not need to swap the whole VPC over at once.
• We can run multiple outbound NAT hosts in the same VPC if we want to for some reason (we don't today, AFAIK, but my understanding is basically that we aren't locking in anything for the whole VPC here).
• Some day we could maybe do a bunch of extremely fancy networking/routing nonsense and have redundant NAT gateways (so each host has multiple outbound routes, and losing a single NAT device does not prevent any host from reaching the public internet), but I don't expect we'll care about this until 2035 unless nat.sh~.pl.bak is really the state of the art and it needs to be restarted every 2 hours.
• Some kind of story exists for IPv6, and is "do the stuff above, but more magic", but our horizon for caring about that is more like 2050.