Is your feature request related to a problem? Please describe.
AWS has announced a new charge of 0.005 per hour for the use of IPv4 addresses. Typically this is allocated by Algo as an elastic IP and attached to the new EC2 instance. In the past the cost was zero. This will amount to approximately $3.6 per month for those no longer eligible for the first year free tier. The charge begins February 2024.
Though not addressed directly in the announcement, it is expected that AWS Lightsail will also increase the bundled cost if using ipv4. The Lightsail cloudformation StaticIp used by Algo will need similar changes as the ec2 ipv6 solution.
Describe the solution you'd like
An option to have not have Algo configure the EC2 cloud instance with a public IPv4 endpoint. Only a public IPv6 endpoint is required.
I have a proof of concept to resolve this issue, though manual steps are still required. Before continuing I thought there could be further discussion. I do not know if I have considered all Algo configuration of IPv6 on the server side. Additionally the client side ansible changes could greatly increase the amount of integration/regression testing required.
EC2 Cloudformation does not have the ability to reference the public IPv6 address from AWS::EC2:Instance as is done for IPv4 when outputting successful creation of the cloudformation stack. This is a known issue. There is a well known solution to create a CloudFormation Custom Resource as a lambda custom function to call the EC2 API API_DescribeNetworkInterfaces. I have proven this solution with Cloudformation template changes:
New ::SecurityGroupIngress resources to allow IPv6 SSH and Wireguard ingess. Have not implemented or tested ipsec enabled
Additional IAM permissions are required to allow Cloudformation access to additional resources (IAM role, and lambda, etc...)
Possible new configuration arguments
enable_ipv6_endpoint: true
enable_ipv4_endpoint: false
ipv6_support: true/false is already exists. Though not related to enabling an ipv6 endpoint
POC of Cloudformation does output the IPv6 address, allowing ansible client to use that fact
A ssh_config client configuration ipv6 file creation has been proven
The VPN client configurations have not been created by ansible to finish all that is required
Manual configuration of client VPN with the ipv6 endpoint has been proven to work
Ansible still uses the IPv4 endpoint to continue the SSH connection to complete cloud instance configuration
Describe alternatives you've considered
If Algo is moving away from Cloudformation as the infrastructure-as-code tool to instead use Terraform, then the solution will be different.
Instead of Cloudformation template changes, let the ipv4 address be created as currently done. Then have the ansible client get the ipv6 address from the ínstance meta-data. Ansible could then later request the ipv4 to be released. There will be a single hour charge instead of the life of the Algo VPN. This is not an ideal solution.
Is your feature request related to a problem? Please describe. AWS has announced a new charge of 0.005 per hour for the use of IPv4 addresses. Typically this is allocated by Algo as an elastic IP and attached to the new EC2 instance. In the past the cost was zero. This will amount to approximately $3.6 per month for those no longer eligible for the first year free tier. The charge begins February 2024.
Though not addressed directly in the announcement, it is expected that AWS Lightsail will also increase the bundled cost if using ipv4. The Lightsail cloudformation StaticIp used by Algo will need similar changes as the ec2 ipv6 solution.
Describe the solution you'd like An option to have not have Algo configure the EC2 cloud instance with a public IPv4 endpoint. Only a public IPv6 endpoint is required.
I have a proof of concept to resolve this issue, though manual steps are still required. Before continuing I thought there could be further discussion. I do not know if I have considered all Algo configuration of IPv6 on the server side. Additionally the client side ansible changes could greatly increase the amount of integration/regression testing required.
Describe alternatives you've considered