Los clientes de AWS no pueden escapar de IPv4

• AWS anunció que cobrará por las direcciones IPv4 públicas a partir de febrero de 2024. A una tarifa de $0.005 por hora, esto genera un costo de $4 al mes o más de $40 al año.
• Esta tarifa afectará servicios como Elastic Load Balancers, instancias EC2, Elastic IPs, tareas de ECS Fargate con IP pública, IPs de Global Accelerator, IPs de VPN Site-to-site y Managed NAT Gateways. Las direcciones IPv4 compartidas y las direcciones IPv4 públicas usadas en funciones Lambda fuera de VPC no se verán afectadas.
• Aunque muchos recibieron bien este anuncio porque se esperaba que impulsara la adopción de IPv6, el autor sostiene que la tarifa no tendrá un gran impacto en esa adopción debido a la falta de soporte de IPv6 en muchos servicios de AWS.
• El autor señala que patrones ineficientes, como tener varios Load Balancers por VPC o configurar intencionalmente IPv4 pública en instancias EC2 y tareas de Fargate para evitar Managed NAT Gateway, se verán muy afectados por la nueva tarifa.
• El autor afirma que ejecutar solo IPv6 en AWS es prácticamente imposible por la falta de soporte de IPv6 en servicios clave como API Gateway, Lambda, ECS y App Runner. Incluso al operar internamente en doble pila, la mayoría de los servicios de AWS solo pueden conectarse a destinos IPv4.
• El autor critica que AWS presente la nueva tarifa como una forma de fomentar la adopción de IPv6 y sostiene que no hay manera de evitar este cobro porque AWS ha ignorado en gran medida IPv6 durante años.
• El autor concluye que, aunque la tarifa de IPv4 puede ser necesaria considerando el reciente aumento en los costos de adquisición de IPv4, no solo no impulsará la adopción de IPv6, sino que también podría frenar la innovación y hacer menos atractiva la idea de tener una cuenta personal de AWS.
• Esta es la primera parte de una serie del blog. En futuras publicaciones, se abordarán con más profundidad las opciones relacionadas con la adopción de IPv6 en AWS para tráfico de ingreso e intra-VPC, tráfico de egreso y problemas de programación de aplicaciones.

[GN⁺]

Opiniones de Hacker News

• Amazon está llevando a cabo un proyecto a gran escala para dividir todos los sistemas internos en versiones regionales debido al agotamiento de las direcciones IPv4 internas
• La transición a IPv6 no es posible porque hay muchos dispositivos de red internos que no pueden soportar IPv6
• Dado que las herramientas de AWS recomiendan fuertemente construir redes que direccionan de forma ambigua redes 10.x RFC1918, los incentivos de AWS no favorecen ofrecer un v6 funcional
• Un problema importante para usar solo IPv6 en AWS es que mucho software que intenta acceder a GitHub todavía no soporta IPv6
• Algunos clientes de AWS expresan el deseo de alejarse por completo de las IP debido a la complejidad de administrar estos sistemas de red
• Que servicios como Lambda y S3 no soporten IPv6 es un problema importante, y AWS debió haberlos hecho de doble pila y accesibles por IPv6 antes de hacer cambios de precios
• El soporte principal de IPv6 en AWS se debe en parte a la orden del gobierno de EE. UU. de comenzar la migración
• Que CloudFront no soporte IPv6 para orígenes personalizados es un problema para quienes ejecutan muchos contenedores Fargate separados como orígenes
• La falta de competencia entre los ISP en EE. UU. obstaculiza la adopción de IPv6
• Si configuras una VPC solo IPv6 en AWS, muchas cosas pueden dejar de funcionar, desde varios servicios de AWS hasta repositorios de paquetes
• Como en IPv6 no existe el concepto de direcciones privadas, hay que despedirse del Managed NAT Gateway y de su precio