Los clientes de AWS no pueden dejar atrás IPv4
(tty.neveragain.de)- Desde febrero de 2024, AWS cobra $0.005 por hora por cada dirección IPv4 pública dedicada, pero debido a las limitaciones de los servicios de AWS, a los clientes les resulta difícil evitar ese costo migrando a IPv6
- El cobro abarca una amplia gama de recursos, incluidos Elastic Load Balancer, EC2/Elastic IP, tareas de ECS Fargate con IP pública asignada, Global Accelerator, Site-to-site VPN, RDS y Managed NAT Gateway
- EC2, VPN, Transit Gateway, Direct Connect y Network Firewall funcionan sobre IPv6, pero servicios clave como API Gateway, Lambda, ECS y App Runner rechazan las subredes solo IPv6 o no las soportan correctamente
- Incluso con una configuración dual-stack interna, más del 90% de los endpoints de API de servicios no soportan IPv6, por lo que es difícil usar S3, Systems Manager o SQS desde una VPC sin IPv4 pública
- Para clientes grandes, muchas veces representa menos del 1% de la factura, por lo que el incentivo para migrar es bajo; en cambio, las pymes, usuarios aficionados y startups pueden enfrentar aumentos de costo de entre 10% y 30%, lo que les afecta más
Cobro por IPv4 pública dedicada desde febrero de 2024
- Desde febrero de 2024, AWS cobra $0.005 por hora por cada dirección IPv4 pública dedicada
- Equivale a casi $4 al mes y más de $40 al año
- Aplica a IPs propiedad de AWS; las direcciones BYOIP en las que el cliente aporta su propio bloque IPv4 público enrutable no tienen cargo
- El cobro aplica a una amplia variedad de recursos principales que usan IPv4 pública de forma directa
- Elastic Load Balancer
- Usa una dirección por zona de disponibilidad
- Requiere al menos 2 y no se puede desactivar IPv4
- Instancias EC2 y Elastic IP
- Tareas de ECS Fargate con IP pública asignada
- IPs de Global Accelerator
- IPs de Site-to-site VPN
- RDS
- Managed NAT Gateway
- Elastic Load Balancer
- Las direcciones IPv4 compartidas quedan excluidas
- Las direcciones compartidas usadas en distribuciones de CloudFront o endpoints de API Gateway no están sujetas al cobro
- También quedan excluidas las direcciones IPv4 públicas usadas por funciones Lambda fuera de una VPC
Configuraciones donde el costo aumenta mucho
- Un Elastic Load Balancer público desplegado en 3 zonas de disponibilidad aumenta su precio base en más de 50%
- Managed NAT Gateway incrementa su precio base en alrededor de 10%
- NAT Gateway no ofrece redundancia por zona de disponibilidad
- Si la conectividad saliente es importante, se necesita un NAT Gateway por cada zona de disponibilidad
- Dos patrones que desperdician muchas direcciones se ven especialmente afectados
- Configuraciones con varios Load Balancer por cada VPC
- Esto ocurre al combinar varios templates de CloudFormation o módulos de Terraform, o cuando un controlador de ingress de Kubernetes crea un Load Balancer por servicio
- Un solo Load Balancer puede manejar varias URL y servicios
- Configuraciones que adjuntan deliberadamente IPv4 pública a instancias EC2 y tareas de Fargate para evitar Managed NAT Gateway
- Irónicamente, este enfoque sigue siendo más barato hasta llegar a unas 10 direcciones IPv4 públicas por zona de disponibilidad
- Configuraciones con varios Load Balancer por cada VPC
Cómo revisar el uso actual
- El uso de direcciones IPv4 públicas ya se está contabilizando en la cuenta
- Actualmente aparece como $0, pero desde febrero de 2024 se cobrarán $0.005 por hora
- Las rutas para revisarlo son las siguientes
- Billing Dashboard > Bills
- Aparece como
PublicIPv4:InUseAddressen la sección de Virtual Private Cloud
- Aparece como
- Cost Explorer
- Se puede filtrar para incluir solo
PublicIPv4:InUseAddressy ver el uso diario u horario - También permite agrupar por cuenta miembro
- Se puede filtrar para incluir solo
- VPC > VPC IP Address Manager > Public IP insights
- Permite ver un resumen del uso de IPv4 pública
- Esta parte de IPAM es gratuita
- Solo muestra datos por cuenta y por región, y no captura direcciones usadas temporalmente, por lo que los datos son incompletos
- Billing Dashboard > Bills
Dos formas de adoptar IPv6
- Como las direcciones IPv4 tienen costo y las direcciones IPv6 son gratuitas, a primera vista migrar a IPv6 parece la opción natural
- En IPv6 no existe el concepto de direcciones privadas, por lo que se puede evitar Managed NAT Gateway y su costo
- Hay dos formas principales de adoptar IPv6
- Dual-stack
- Se configuran direcciones IPv4 e IPv6 en todos los sistemas
- IPv6-only interno
- Internamente se usa solo IPv6, y la conectividad IPv4 se ofrece únicamente en el edge o CDN de cara a los usuarios generales
- Dual-stack
- Un memorando de la Oficina del Presidente de Estados Unidos señala que operar en dual-stack se ha vuelto demasiado complejo e innecesario de mantener, y que los organismos de estandarización y las grandes tecnológicas han comenzado a moverse hacia despliegues IPv6-only
- El soporte base de red IPv6 en AWS en sí está relativamente bien resuelto
- Se pueden configurar instancias EC2 solo IPv6 en subredes solo IPv6
- Funcionan capacidades esperadas en una red IPv6, como DNS local, servicio de tiempo, configuración del host y seguridad
- VPN, Transit Gateway, Direct Connect y Network Firewall también soportan IPv6
IPv6 se bloquea al usar servicios de AWS
- El cuello de botella aparece no tanto en la red en sí, sino en la etapa de conexión con otros servicios de AWS
- Servicios clave como API Gateway, Lambda, ECS y App Runner rechazan configuraciones en subredes solo IPv6 o generan errores
- Elastic Load Balancer puede arrojar errores como
Not enough IP space available
- Elastic Load Balancer puede arrojar errores como
- Incluso configurar el entorno interno como dual-stack no es suficiente
- Muchos servicios ignoran que la subred tenga IPv6 configurado
- En muchos casos solo pueden conectarse a destinos IPv4
- Hay muchos casos en los que usar APIs de servicios desde una VPC sin dirección IPv4 pública es difícil o imposible
- Falla ejecutar
aws s3 lsdesde una instancia EC2 - Systems Manager, el método recomendado para acceder y administrar instancias, no funciona
- Una tarea de ECS no puede acceder a SQS
- Falla ejecutar
- Según el estado del soporte de IPv6 en AWS, más del 90% de los endpoints de API de servicios no soportan IPv6
- Los endpoints de SES SMTP y de repositorios ECR tampoco funcionan, y CloudFront no puede conectarse a un origin IPv6
- No se pueden iniciar tareas de ECS desde ECR, pero sí desde Docker Hub, que sí soporta IPv6
- Docker Hub aplica rate limits a las descargas
PrivateLink es una alternativa, pero con restricciones de costo
- Muchos servicios pueden conectarse mediante PrivateLink
- Se conectan directamente a la VPC del cliente, por lo que no se necesita una dirección IP pública
- No todos los servicios están soportados
- PrivateLink cobra por servicio y por zona de disponibilidad
- Cuesta alrededor de $9 al mes por endpoint
- Por ejemplo, conectar Secrets Manager, EC2, SSM y SSM-Messages en 3 zonas de disponibilidad supera los $1,200 al año por VPC
- También se agregan cargos por tráfico adicional
Por qué es difícil que cobrar IPv4 lleve a una migración a IPv6
- Para clientes de cierto tamaño, el cobro por IPv4 suele representar menos del 1% de la factura, por lo que no se percibe como un cambio importante
- Solo con este costo es difícil que ocurra una inversión de ingeniería significativa
- Para pymes, usuarios aficionados y startups, la tarifa puede aumentar la factura entre 10% y 30%
- Ellos sí tienen un fuerte incentivo para adoptar IPv6 para evitar el costo
- Pero debido a las brechas en el soporte de IPv6 de los servicios de AWS, las formas de evitar el costo de IPv4 son limitadas
- Considerando el costo reciente de conseguir IPv4, el cobro por direcciones IPv4 puede ser necesario en sí mismo
- Si el soporte de IPv6 en todo el ecosistema de servicios de AWS fuera más maduro, más clientes podrían migrar a entornos IPv6-only
- Hoy en día es difícil considerar a IPv6 como un ciudadano de primera clase en AWS, y en esta situación cobrar IPv4 vuelve menos atractivo usar AWS para cuentas personales, aprendizaje, preparación de certificaciones y soporte a proyectos open source
1 comentarios
Opiniones de Hacker News
Hace mucho, cuando era desarrollador junior en Amazon, hubo un gran proyecto interno para dividir todos los sistemas internos en versiones por región y permitir llamadas entre regiones solo mediante gateways limitados
La razón era que se habían agotado las direcciones IPv4 internas
Ante la pregunta “¿no se podía simplemente cambiar a IPv6?”, el Principal PM a cargo respondió algo como: “Hay demasiado equipo de red interno actual que no soporta IPv6, así que para reemplazarlo tendríamos que haber comprado e instalado una cantidad de equipos cercana a la producción anual mundial”
Es fácil ver a Amazon como si estuviera actuando de mala fe con IPv4, pero si se piensa en la escala de los sistemas de AWS, también es bastante creíble que reemplazar todo el hardware de red antiguo haya sido un proyecto demasiado grande para hacerlo en poco tiempo
Sospecho que quizá era un poco de humo o, al menos, una forma creativa de presentar los hechos. Por ejemplo, puede que en realidad todo tuviera soporte para IPv6, pero que los ingenieros de red, llenos de miedo, incertidumbre y duda, no quisieran activarlo
La mayoría de los equipos de red que he visto ya eran dual stack mucho antes de que IPv6 se usara realmente a mi alrededor, y siempre pensé que eso venía por requisitos del gobierno o del ejército de EE. UU.
No recuerdo quién era el PM de ese proyecto, pero en ese momento llegué a respetar de verdad el valor que puede aportar un TPM
Es cierto que el costo y la necesidad de reemplazar equipos de red fueron una de las razones fuertes para no ir por IPv6. Amazon usaba equipos de red diseñados y fabricados por ellos mismos por varias razones, y probablemente aún lo hace
Todos esos equipos tenían una cantidad fija de memoria, así que para aumentar la memoria lo suficiente como para manejar tablas de ruteo IPv6 y demás, había que reemplazarlos. Incluso si hubieran elegido solo IPv6, el equipo existente no habría alcanzado, y de todos modos habría sido difícil aprobarlo sin dual stack IPv4/IPv6
Siempre parece estar trabajando en proyectos de escala enorme, e IPv4 ahora es de los más pequeños entre ellos. Lamentablemente no puedo compartir algunos de los grandes proyectos en los que trabaja ahora
Me ha dado algo de su tiempo varias veces y recibí consejos sensatos; se lo agradezco
Seguramente ya iniciaron el proceso
¿Verdad? Me cuesta imaginar que AWS esté metiendo la cabeza en la arena e ignorando esto
Que AWS ofrezca IPv6 que funcione bien parece ir claramente contra sus incentivos. Las herramientas de influencia de AWS, como los criterios Well-Architected o las certificaciones, empujan con fuerza a crear laberintos de redes 10.x RFC1918 con direccionamiento ambiguo, no arquitecturas al estilo Internet con direccionamiento de extremo a extremo
En el mundo de las recomendaciones de AWS, el concepto mismo de “dirección IP pública” es una señal de alerta, y AWS hasta recomienda herramientas que muestran esas direcciones y las “mitigan”, cobrando un extra
Hacer que los clientes gasten esfuerzo construyendo infraestructura compleja en nombre de la seguridad genera un fuerte efecto de lock-in. Y eso aunque en la práctica perjudique la seguridad con complejidad innecesaria, ambigüedad de direcciones, etc.
Ya ni se puede contar cuántos productos como “Private Endpoints”, “Private Links”, “Service Endpoints”, “Private Resolvers” y “Virtual WAN” han salido, y todos son para operar IPv4 a gran escala
Si hubieran hecho que IPv6 funcionara bien, literalmente no haría falta ninguno de esos productos
En cambio, Azure también aplica NAT a IPv6, así que ni siquiera puedes usar IPv6 para evitar el NAT al que IPv4 te obliga. Incluso en 2023 están lanzando productos nuevos que no soportan IPv6 y que probablemente seguirán sin hacerlo
En la documentación todavía queda una página entera de limitaciones: https://learn.microsoft.com/en-us/azure/virtual-network/ip-s...
Si uno imagina que esta fuera la transición de IPX a IPv4, se ve lo absurdo que es. Es como si en esa página dijera: “Limitaciones de IPv4: todas las VM deben incluir al menos una dirección IPX”
¿No suena raro? En 1999 se estaba migrando a los clientes de IPX a IPv4, y el soporte de IPv6 apareció aproximadamente entre 2001 y 2003. Han pasado décadas y aun así se siente como en la época de migración previa a Novell NetWare, cuando se decía “todavía no todo soporta IPv4, así que necesitamos IPX+IPv4”
Esta lista definitivamente no contiene todas las limitaciones. Como la mayoría de los productos PaaS no soportan IPv6, las soluciones IaaS+PaaS terminan teniendo que usar IPv4 en su mayoría
No entiendo por qué, pero hasta que alguna gran empresa tecnológica impulse el direccionamiento de extremo a extremo como buena práctica, no queda más que seguir la sabiduría convencional para no generar señales de alerta
Los clientes quieren su propia red privada para evitar intrusiones y filtraciones de datos incluso en máquinas que no son de su propiedad. Más aún, quieren meter en esa red servicios PaaS bien completos, tipo “con baterías incluidas”
Mi sospecha es que la razón es más mundana. Considerando incluso la cantidad de servicios de AWS, soportar IPv4 simplemente es más fácil
Como cliente de AWS, quisiera alejarme de las IP en sí. Administrar un sistema de redes complejo compuesto por protocolos antiguos como IP, BGP y DNS es una pérdida de tiempo.
Bastaría con asociar una identidad fuerte a las cargas de trabajo y aplicar mediante políticas qué cargas de trabajo pueden intercambiar datos con cuáles.
No debería importarme cómo llegan los datos de una carga de trabajo a otra; simplemente debería funcionar.
En lugar de caer en un zoológico de componentes de redes virtualizadas, es decir, networking imitado, lo abstraen todo.
En la práctica nunca han funcionado bien y no podrán hacerlo. Hay demasiados matices y detalles que considerar para ejecutar y optimizar cargas de trabajo reales.
En mi experiencia, el mayor problema al ir solo con IPv6 en AWS es que GitHub todavía no soporta IPv6. Muchísimo software asume que puede conectarse a GitHub para descargar algo.
Se puede usar un servicio público de NAT64, pero no es muy confiable para usos serios: https://nat64.xyz/
AWS cobra una barbaridad por el tráfico de NAT Gateway, y no sé si se puede configurar para interceptar solo el tráfico hacia hosts que son únicamente IPv4. Si me equivoco, agradecería que me corrigieran.
Fuera de eso, usar solo IPv6 en AWS funciona impecablemente y es más barato. El gateway de egreso para redes privadas es gratis. Claro, bajo la premisa de no preocuparse por IPv4.
En mi opinión, el verdadero problema es que Lambda y S3 no soportan IPv6, y AWS debería haberlos convertido primero en dual stack y hacerlos accesibles por IPv6 antes de cambiar los precios.
Técnicamente S3 sí tiene endpoints dual stack separados, pero no ayuda mucho, porque de todos modos hay que cambiar la configuración de la aplicación para adaptarse a este cambio.
Para empezar, la mitad de la razón por la que AWS está adelantado en soporte de IPv6 es el mandato de política del gobierno de EE. UU. para empezar la migración.
Desde el punto de vista de costos, es cierto que el nuevo cargo es menor para los clientes grandes, pero no hay que subestimar la fuerza que tienen los mandatos de política de sus clientes más grandes. La sola amenaza de crear alternativas propias para cumplir con las políticas puede hacer que AWS termine elevando la prioridad del soporte.
Del lado del cliente, es decir, de los usuarios finales, parece ir bien. Basta ver que Google reporta hoy en día casi 50% de tráfico IPv6 de usuarios finales.
Personalmente, lo peor es que CloudFront no soporta IPv6 para orígenes personalizados.
Si ejecutas muchos contenedores Fargate separados como origen, tienes que activar direcciones IPv4 públicas, y pronto el costo de los contenedores pequeños se duplicará.
Amazon debería hacer que su propia infraestructura realmente soporte IPv6 antes de cobrar extra por el uso de IPv4 heredado.
Entiendo que Amazon creó un monstruo enorme y que desplegar IPv6 en tantos servicios es una tarea gigantesca, pero no veo razón para que CloudFront no pueda soportar orígenes IPv6 ya mismo; de hecho, desde ayer.
Tampoco parece relativamente tan difícil, y podría ser una buena herramienta para sortear otras limitaciones.
Sinceramente, hasta ahora sentía que las decisiones de Amazon al final tenían en mente el mejor interés del cliente, pero ya no. Lo veo como una mala señal para el futuro.
Si en EE. UU. hubiera verdadera competencia entre ISP, habría ayudado mucho.
Vivo de alquiler en un suburbio cerca de Seattle y aun así solo hay un ISP de banda ancha real. No es una zona rural bajo ninguna definición, pero Comcast es la única opción. El precio y el servicio reflejan exactamente esa realidad.
No es casualidad que sea “solo Comcast”; por regulación legal terminó siendo “solo Comcast”.
Lo divertido de quejarse de Comcast es que, cuando yo usaba Comcast, tenía IPv6 nativo. Mi proveedor actual solo tiene IPv6 mediante NAT46.
Tiene desventajas, como degradación del rendimiento con lluvia intensa, pero he visto algunas reseñas positivas.
La mayoría no sabe que ahora mismo hay dos Internet IPv6. Está el lado de Cogent y el lado de Hurricane Electric; ambos tienen tamaños similares y se niegan a interconectarse. Así que hay que saberlo y comprar tránsito a ambos lados, o comprarlo a una red que compre tránsito a ambos lados.
Al menos un operador grande que conozco todavía corre v6 sobre túneles. En muchos lugares, el tráfico v6 toma rutas no óptimas, y una red corporativa puede tener conectividad v4 en cada centro de datos, pero enviar todo v6 a “esa caja debajo del escritorio de Dave”.
Aun así, miden la adopción de v6 en lugares como Google o Cloudflare, donde equipos dedicados garantizan que los paquetes lleguen, y se dan palmaditas en la espalda.
La frase “no pueden salir de IPv4” es adecuada. Puedes crear una VPC solo IPv6, pero demasiadas cosas se rompen, desde varios servicios de AWS hasta repositorios de paquetes: https://blog.devopstom.com/ipv6-only-ec2/
Al final tienes que habilitar IPv4, operar tú mismo un gateway NAT64 o confiar en un NAT64 que opere alguien más: https://nat64.net y http://v4-frontend.netiter.com
Puede que dentro de AWS sea cierto eso de “en IPv6 no existe el concepto de direcciones privadas, así que adiós al Managed NAT Gateway y a sus precios majestuosos”, pero en IPv6 existen las direcciones IPv6 locales únicas fc00::/7, y si de verdad amas NAT, también existe NAT66
Dicho eso, ULA no suele recomendarse, y NAT66… simplemente no va
Por lo que escuché recientemente, Microsoft hizo que todo el IPv6 de Azure esté centrado en NAT. Es realmente raro