Support IPv6 in beanstalk - NAT gateway avoidance

[Ottunger]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
• Please do not leave "+1" or "me too" comments. They generate extra noise for issue followers and do not help prioritize the request.

Tell us about your request What do you want us to build?

EBS should support to build an EC2 instance (for app) even if this instance only has an IPv6 stack.

Is this request specific to an Elastic Beanstalk platform? If so, which one(s)?

It al least affects nodejs12.x on ALBv2. I suspect broader scope.

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard? What outcome are you trying to achieve, ultimately, and why is it hard/impossible to do right now? What is the impact of not having this problem solved? The more details you can provide, the better we'll be able to understand and solve the problem.

For now, EC2 instances created by EBS have IP addresses depending on the VPC they run in. If the VPC they run in issues both IPv4/IPv6 addresses, they will have both. If the VPC only supports IPv6, so will the EC2 instances created.

A common pattern to design a secure application would be to have instances in a non-internet facing network, while load balancers would be put in an internet-facing network and managing requests. This means that, while setting up an app instance (and using it afterwards, if app needs internet connectivity), it will only have access to internet if there is a NAT gateway for IPv4. NAT gateways are an extremely cost prohibitive device in AWS, costing at least as much per day as medium sized EC2 instances!

Over IPv6, one can manage to have network access without requiring a gateway and avoid these costs.

However, EBS does not manage to set up properly an instance when this instance only has IPv6 address. Currently it fails while downloading scripts for self EBS set up (from S3 because not using S3 dualstack endpoints).

Are you currently working around this issue? How are you currently solving this problem?

We stick with IPv4 and pay the NAT gateway...

Additional context Anything else we should know?

Issue had been posted here https://forums.aws.amazon.com/message.jspa?messageID=994192#994192

Attachments If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)

[axyjo]

Bump - this is even more important as the IPv4 pricing changes roll out to AWS next February

[dennisvang]

@Ottunger I assume by "EBS" you mean Elastic Beanstalk, not Elastic Block Store?

[Ottunger]

Yes, of course.

TBH, I am still paying the AWS toll on this for now.

[vickyRathee]

Paying $$$ of bill unnecessary from 4 months due to the lack of this option. Please add this!

[msitms]

Possible workarounds:

• https://fck-nat.dev/stable/ Works very well for me, and much cheaper than AWS NAT Gateway, not just the cost per instance, but even more importantly no extra cost for the traffic! I host my EC2 instances in private dual-stack subnets, so that they can reach all IPv6 enabled endpoints directly, and for IPv4 only they go through the fck-nat instance in the local subnet (mostly AWS services sadly and also for downloading container images).
• The specific problem described in this ticket with Elastic Beanstalk scripts not using the S3 Dualstack endpoints might be possible to resolve by deploying a free VPC Gateway Endpoint for S3 (haven't tested it yet). However, I would assume that you would quickly run into the next problem. CloudFormation is an integral part of Elastic Beanstalk, and still seems to offer IPv4 only endpoints. This could be resolved by deploying VPC Interface Endpoints, but you need a payed interface for each service in each subnet. So the Elastic Beanstalk team alone will not be able to enable IPv6 only deployments. Nonetheless, it's a shame that the market leader for public clouds offers very sparse IPv6 support in 2024, while charging their customers for using public IPv4 addresses which they absolutetly need to use many of their own services.