Hi all, great replies. :) Let me clarify my initial question, and then respond one by one:
My intention is to run a web-crawling service on a public cloud. This service is geographically distributed, and therefore will run in multiple regions around the world inside AWS... this means there will be multiple AWS VPCs, each with their own NAT gateway, and traffic destined to websites that we crawl will appear to come from this NAT gateway's IP address.
The reason I want a predictable IP is to communicate this IP to website owners so they can allow access from these IPs into their networks. I chose IP as an example; it can also be a subnet, but what I don't want to provide is a list of 100 different IP addresses without any predictability.
I understand that this is not perfect, and would frankly not be my preferred approach to solve the problem.... but we've had requests of this nature from websites to create an allowlist of a limited number of predictable IPs so it doesn't trip their IDSs/other systems they might have... so we're trying to see how well it would work in practice. For the moment, let's set aside the issue as to whether AWS will even let me advertise the same IP on all my VPC NAT gateways, and just look at whether it's technically feasible. My gut feeling is that this wouldn't work well in practice, but I wanted to ask the experts here...
Also, pointers on what the best practices for solving this issue are most welcome, so I can reference those who ask for IP addresses to this discussion and follow recommendations here.
Onto the responses:
> Because there’s no good/reliable way to get the replies back to the correct initiating host.
> When my clients make connections outbound to anycast addresses, the destination is more-or-less stable, and the replies come back to the client's unique IP, so anycast works in that direction. The guarantees are not present in the reverse direction.
Yes, this makes sense as the destination can be anywhere around the world, and that routing is asymmetric as others mentioned. However, if the destination service is "close" (in the routing metric sense) to the initiating host, anycast return IP ought to work well, right? I understand this is a very important caveat and impractical to implement correctly in the real world.
> We use our IGP (IS-IS) for our Anycast services. We find it to be very
basic, and as such, very predictable.
This is interesting... I wonder whether Anycast will still have some failure modes and break TCP connections if routing (configuration) were to change? I checked the PDF linked by Bill Woodcock... while the methodology is the same from 20y ago, would the data still be the same (order of magnitude)? :)
"Limited operational data shows underlying instability to be on
the order of one flow per ten thousand per hour of duration."
> Unless you’re twisting knobs, egress traffic should already exit your network at the closest possible egress point to its origin. Is your intention to carry the traffic for longer than that?
No, but I hope my intention is more clear in this email. It's to have a predictable egress IP to simplify firewall rules.
thanks all!!