Stable egress IPs for multi-region outbound traffic
controlling egress IPs at scale.
route outbound traffic through NAT gateways with allocated static IPs, or centralize egress so all regions exit through a fixed small IP set you can whitelist.
What's really being asked
The interviewer wants to see that you can decouple a stable, whitelistable egress identity from the dynamic, autoscaling instances that actually originate traffic across many regions.
The full answer
The problem is that instances behind autoscaling get ephemeral public IPs, which makes allowlisting impossible. The fix is to force outbound traffic through a managed egress point with statically allocated addresses. In each region, place workloads in private subnets and route their internet-bound traffic through a NAT gateway associated with one or more allocated static IPs, such as elastic IPs; the third party then whitelists that small, fixed set. To shrink the allowlist further, centralize egress: route all regions through a shared egress or inspection VPC, often via a Transit Gateway, so traffic from every region exits through a single, small pool of static IPs rather than a per-region set. This central pattern adds cross-region hops and a chokepoint to scale and monitor, but it minimizes the IPs the partner must trust and centralizes firewalling and logging. Whichever pattern you choose, the goals are the same: a small, stable, documented set of source IPs, and no reliance on addresses that change when instances cycle.
The mistakes people make
Assigning public IPs directly to instances, which change as the fleet scales and cannot be reliably whitelisted. Whitelisting an entire cloud provider's IP range, which is enormous and insecure. Forgetting that each region otherwise has its own egress addresses, bloating the allowlist.
What usually comes next
How does a NAT gateway preserve a stable source IP? What are the throughput and cost limits of centralized egress? How do you make the egress path highly available?
A concrete example
Workloads in three regions sit in private subnets and route through a central egress VPC whose NAT gateways carry two elastic IPs. The partner whitelists just those two addresses, and adding a fourth region requires no new allowlist entry.
Interview question
Why is assigning public IPs directly to autoscaling instances a poor way to satisfy a partner's IP allowlist?
- a.Instance public IPs change as the fleet scales, so the allowlist becomes staleCorrect
- b.Cloud providers forbid outbound traffic from instances with public IPs
- c.Public IPs are encrypted and cannot be read by the third party
- d.Instances cannot reach the internet without a load balancer in front
Why? this is the answer
Autoscaling cycles instances and reassigns ephemeral IPs, so an allowlist built on them breaks. Routing through NAT gateways with allocated static IPs gives a stable, whitelistable source set.
Just read this? Test yourself on what you have been reading.
Read the original → docs.aws.amazon.com
- #networking
- #nat-gateway
- #egress
- #multi-region
- #cloud
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on networking — each one lists the topics its interview covers.
See open roles