IP Exhaustion inside VPC

Many organizations set up VPC in the cloud for security. When you set up the VPC, there are only limited number of IP addresses based on the CIDR range defined for the network. This becomes a problem when creating various lambdas, which can take many different security groups. In addition to lambdas, other entities take up IP addresses, such as EC2 instances, RDS instances, and VPCE endpoints. When spinning these resources up though terraform, behind the scenes AWS creates elastic network interfaces (ENIs) on your behalf. You can only remove theses ENIs by removing the resources associated with them, and then AWS removes them. In my experience, this does not always happen in a timely fashion, and so you should always be aware of how many ENIs and consequently IP addresses are available before you start running out. If you run out of IPs you will get and error such as this in your terraform:

It may be that your first thought is to expand the CIDR range of the network, create a new VPC to add more resources, or put the resource (lambda function in this case) onto a different subnet with available IPs. This may not be necessary, however. This has to do with how AWS creates new ENIs, which was modified in 2019:

https://aws.amazon.com/blogs/compute/announcing-improved-vpc-networking-for-aws-lambda-functions/

One thing to point out from this blog post is the following statement:

Every unique security group:subnet combination across functions in your account requires a distinct network interface. If a combination is shared across multiple functions in your account, we reuse the same network interface across functions.

Basically, if you reuse the same or a few different security groups across your resources that require IP addresses, then AWS will not spin up a new ENI for each one. It will reuse an existing ENI, and there is no need to expand the CIDR range or add a new VPC to host new lambda functions or other resources which require IPs inside of a VPC.