- Newest
- Most votes
- Most comments
The ENIs used by Lambda functions you attach to your VPCs are a special type of ENI called a hyperplane ENI. They are owned by the Lambda service and shouldn't be possible for you to modify directly. It might not be completely outside the realm of possibilities for there to have been a bug in the service at some point that could've allowed you to associate an EIP with a hyperplane ENI, but it should never have worked.
If you need static, dedicated public IP addresses for your Lambda function to access the internet, the only AWS-native option available is, as you were thinking, to use a NAT gateway for IPv4 access and an egress-only internet gateway (EIGW) for IPv6 access. This is explained also in official documentation: https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc-internet.html
There's no data processing charge for IPv6 traffic passing through an EIGW, so if your target services are available over IPv6, you could forgo creating a NAT gateway that has both a fixed fee and traffic processing fees, as you were implying, and connect over IPv6 only through the EIGW that has no additional fees. The VPC and subnets where Lambda creates its hyperplane ENIs must still have internal IPv4 addresses (attempts to create them in IPv6-only subnets will fail), but they don't need to have internet access.
I apologize, but there seems to be a misunderstanding in your approach. It's not possible to directly associate an Elastic IP (EIP) with a Lambda function's Elastic Network Interface (ENI). Lambda manages its own ENIs, and you cannot modify or associate addresses with these ENIs directly.
Lambda functions running in a VPC use ENIs that are fully managed by AWS Lambda. These ENIs are not designed to have EIPs associated with them, which explains the errors you're encountering both through the CLI and the console.
For Lambda functions in a VPC that need to make outbound internet requests, the recommended approach is to use a NAT Gateway or NAT instance in a public subnet. While you mentioned wanting to avoid NAT Gateway costs, this is the standard and supported method for allowing Lambda functions in private subnets to access the internet.
If you previously had an EIP associated with a Lambda ENI, it's possible that you were actually associating it with a different type of resource, not directly with the Lambda function.
To resolve your issue and allow your Lambda function to make outbound internet requests without using a NAT Gateway, you have a few options:
-
Place your Lambda function in a public subnet with a route to an Internet Gateway. This allows direct internet access but may have security implications.
-
Use VPC endpoints for AWS services your Lambda needs to access, which doesn't require internet access.
-
If you absolutely need a static IP for outbound requests, consider using an EC2 instance as a proxy or NAT instance instead of a NAT Gateway.
Remember, Lambda's networking model is designed for scalability and security, which is why direct manipulation of its ENIs is not supported. If you need more control over the networking setup, you might want to consider using EC2 instances or containers instead of Lambda for your workload.
Sources
Troubleshoot networking issues in Lambda - AWS Lambda
Troubleshoot configuration issues in Lambda - AWS Lambda
answered 2 years ago
Relevant content
asked 4 years ago
asked 2 years ago
Thanks for the response. However, this still doesn't sit right to me. Shouldn't AWS be issuing a more informative error rather than "An internal error has occurred" when attempting to do this EIP to Hyperplane ENI association? And it still feels odd that it wasn't really a "very brief point in time" type of bug where people could associate one with another. There are literally multiple stackoverflow responses suggesting this approach, with people over the years replying it does work for them. As I need IPv4, redesigning my solution would give me extra hassle, increasing my costs needlessly.