Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EC2 will begin to charge for public IPv4 addresses #14644

Open
glennschler opened this issue Aug 25, 2023 · 0 comments
Open

EC2 will begin to charge for public IPv4 addresses #14644

glennschler opened this issue Aug 25, 2023 · 0 comments

Comments

@glennschler
Copy link
Contributor

glennschler commented Aug 25, 2023

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant