Single NAT Gateway with multiple public IPs-CodePudding

I have a project that involves running several hundreds lambdas fetching data from internet.

These lambdas are running inside a private subnet of my VPC.

I would like these lambdas to not all have the same IP for their internet traffic.

My understanding is that I should create a NAT gateway in a public subnet, but I cannot find how to have multiple public IPs on that NAT gateway to have some sort of randomization.

Is that even possible? How should one proceed to achieve this?

CodePudding user response：

It's not possible with a NAT gateway, since you can only attach one public IP per NATG.

However it is possible if you are willing to use NAT instances (more manual configuration and admin overhead). You can set up multiple NAT instances. Correspondingly deploy your lambdas into multiple private subnets, each one configured to go to one of the NAT instances.

CodePudding user response：

Unfortunately, this is impossible as you cannot associate multiple Elastic IPs with a public NAT gateway.

A public NAT gateway can only use 1 assigned Elastic IP, according to the documentation:

The NAT gateway replaces the source IP address of the instances with the IP address of the NAT gateway. For a public NAT gateway, this is the elastic IP address of the NAT gateway.

You can associate exactly one Elastic IP address with a public NAT gateway.

To use a different Elastic IP address for your NAT gateway, you must create a new NAT gateway with the required address, update your route tables, and then delete the existing NAT gateway if it's no longer required.

Having multiple Elastic IPs & multiple NAT gateways also won't really be feasible as the default (but adjustable) limit on Elastic IPs is 5 per region & on NAT gateways, 5 per AZ.

If you're using IaC (e.g. Terraform, CloudFormation etc.) you could theoretically create multiple private NAT instances (after increasing the per-region service quota) however I would advise creating your own NAT AMI in that case.

Raising the service quota to hundreds of instances as well as purchasing hundreds of Elastic IPS will definitely raise some alarms.

I would look to rearchitecting your application if possible (unless the nature of your application requires it in which case, AWS may not be the best option).