IPv4 en redes híbridas y multinube: guía técnica

Por qué IPv4 sigue siendo crítico en entornos multinube

IPv6 lleva años maduro, sí. Y sin embargo el modelo de direccionamiento IPv4 en multinube sigue siendo la columna vertebral de la mayoría de arquitecturas empresariales. ¿Por qué? Los motivos son técnicos y comerciales a partes iguales: gran parte del universo de clientes, socios, sistemas heredados y listas de permitidos (allowlists) en firewalls de terceros operan sobre IPv4. Y hay algo más. Muchos proveedores de nube limitan o encarecen la conectividad IPv4 nativa, así que cada dirección se convierte en un recurso escaso que conviene planificar con criterio.

El auge de la nube agravó la escasez. AWS, Azure y Google Cloud alquilan direcciones IPv4 públicas a precios que no han hecho otra cosa que subir. Desde el agotamiento oficial de los pools del RIPE NCC en 2019, el precio de mercado de un bloque /24 se ha movido en rangos aproximados de 30 a 60 USD por dirección, con un alquiler típico de entre 0,30 y 0,60 USD por IP y mes. Ahora piensa en un despliegue multinube con cientos de IPs públicas. La diferencia se traduce en miles de euros anuales. Solo por pagar sin pensar.

Los retos de gestionar IPv4 en arquitecturas híbridas y multinube

Fragmentación del direccionamiento por proveedor

Cada nube asigna direcciones desde sus propios pools. El resultado, en la práctica, es una red fragmentada: rangos distintos en AWS, otros en Azure, otros en el datacenter on-premise. ¿Y eso qué rompe? La creación de reglas de firewall coherentes, la reputación de correo (SPF, DKIM, rDNS) y la segmentación de servicios, sobre todo.

Coste creciente del alquiler de IPs de nube

Los proveedores aplican tarifas por IP pública que, acumuladas en cgws, balanceadores, NAT gateways y rangos de servicios, generan una factura recurrente considerable. Poseer un bloque propio (BYOIP) elimina ese alquiler. Sin rodeos.

Ausencia de portabilidad y vendor lock-in

Las IPs asignadas por un proveedor no se trasladan a otro. Punto. Migrar una carga de trabajo puede implicar cambiar direcciones, actualizar DNS con sus TTL, renegociar allowlists con partners y perder reputación acumulada, algo fundamental para el envío de correo o el scraping legítimo de APIs públicas. Quien ha pasado por eso lo sabe: es un dolor más lento de lo que parece en el papel.

Cumplimiento y trazabilidad

Tras el caso de las IPs reasignadas incorrectamente por algunos RIR, las auditorías de procedencia (chain of custody) son exigentes. En el espacio RIPE, la documentación de la asignación y la correcta gestión del contrato de mantenimiento son imprescindibles. No es burocracia por gusto.

BYOIP: la pieza clave de IPv4 en multinube

BYOIP (Bring Your Own IP) permite anunciar en la nube un bloque IPv4 del que eres titular registrado. AWS, Azure, Google Cloud y Oracle lo soportan, aunque con matices importantes:

1. AWS: admite BYOIP en todas las regiones principales, exigiendo la publicación de un ROA (Route Origin Authorization) en RPKI que autorice al AS de AWS a anunciar tu prefijo.
2. Google Cloud: requiere que el bloque esté anunciado previamente por tu propio AS al menos 90 días antes de la importación. Fíjate: 90 días. No es algo que se improvise la semana del despliegue.
3. Azure: permite traer rangos personalizados mediante certificados y validación de propiedad, con requisitos estrictos de documentación.

El flujo típico, una vez decidido, es este:

1. Adquirir o disponer de un bloque /24 (el tamaño mínimo generalmente admisible para BYOIP).
2. Crear un ROA en el RIR correspondiente que autorice el AS del proveedor de nube.
3. Aprovisionar el bloque en el proveedor y verificar su propagación BGP.
4. Repartir el prefijo entre regiones o servicios según la estrategia de direccionamiento.

Arquitecturas de referencia: IPv4 en entornos híbridos y multinube

Patrón de front global con un solo prefijo

Un único /24 propio se anuncia desde varias regiones mediante anycast o BGP multihomed. Resulta útil para APIs públicas, resolvers DNS y frontales web: misma IP de origen para todos los usuarios, con failover entre nubes sin cambios de DNS. Elegante, cuando funciona.

Patrón de bloque particionado por proveedor

Se divide un /24 en subbloques asignados a cada nube (un /26 en AWS, otro /26 en Azure y el resto en el CPD on-premise, por ejemplo). Mantiene coherencia documental y simplifica las reglas de seguridad corporativas.

Patrón de egress controlado mediante CGNAT

Para tráfico saliente masivo (crawlers legítimos, proxies de salida, integraciones), se usa un pool propio tras CGNAT o NAT44, asignando rangos específicos por función y manteniendo la reputación separada del tráfico de entrada.

Planificación del direccionamiento IPv4: buenas prácticas

He visto equipos estrellarse una y otra vez en los mismos puntos. Esta lista resume lo que casi nadie documenta hasta que es tarde:

• Reserva un bloque propio cuanto antes: el precio por dirección tiende a subir y las necesidades de BYOIP crecen con cada nueva nube incorporada.
• Documenta la cadena de custodia: conserva contratos, LOA (Letter of Authorization) y registros de transferencia para futuras auditorías o ventas.
• Publica y mantén ROAs (RPKI): sin validación ROA, tu prefijo es vulnerable a hijacking y varios proveedores rechazarán anuncios no validados.
• Minimiza la fragmentación: un /24 único es más valioso y operativo que varios /26 dispersos; piensa en la reventa futura, aunque hoy no te lo plantees.
• Controla los TTL de DNS: en entornos multinube con failover, un TTL de 300 segundos reduce el tiempo de conmutación si necesitas mover servicios.
• Revisa listas negras periódicamente: un bloque previamente contaminado puede arruinar la entregabilidad de correo y la confianza de APIs de terceros.

Coste real: comprar, alquilar o usar IPs de nube

Tomemos un /24 (256 direcciones en teoría, 251 útiles en la práctica por las reservadas por protocolo). Los referencias de mercado orientativos son estos:

• Compra: entre 7.500 y 15.000 USD por /24, según procedencia (RIPE, ARIN) y limpieza del bloque.
• Alquiler: entre 75 y 150 USD mensuales por /24 en plataformas especializadas.
• IPs de nube: unos 0,005 USD por IP y hora en AWS (≈3,6 USD/mes por IP), lo que equivale a ~900 USD/mes por 250 IPs. Y al final, ¿qué te queda? Nada. Sin patrimonio resultante.

A partir de 100 IPs públicas en uso continuo, la propiedad o el alquiler resulta claramente más rentable que las IPs gestionadas del proveedor, además de aportar portabilidad. Es aquí donde una plataforma como IP4 Market marca la diferencia: vendedores verificados, precios competitivos, asistencia en el proceso de transferencia y una herramienta de escrow que protege a ambas partes, ya sea para comprar, vender o alquilar bloques IPv4.

Checklist antes de integrar IPv4 propio en tu estrategia multinube

1. Confirmar titularidad registrada del bloque en el RIR y que no tenga contratos de mantenimiento caducados.
2. Verificar reputación (listas negras, historial de anuncios BGP en servicios como BGPlay o Hurricane Electric BGP Toolkit).
3. Definir el plan de particionado por nube y región antes de crear los primeros ROA.
4. Calcular el retorno: coste de adquisición frente a ahorro en IPs de nube a 24-36 meses.
5. Preparar la documentación (LOA, ROA, contratos) para cada proveedor de nube que vaya a anunciar el prefijo.

Conclusión

El IPv4 en multinube no es un residuo del pasado. Es un activo estratégico que determina la portabilidad, la resiliencia y el coste operativo de las arquitecturas híbridas modernas. Un bloque propio, gestionado con RPKI, documentación rigurosa y un plan de direccionamiento claro, elimina el vendor lock-in y reduce de forma sustancial la factura de IPs públicas de los proveedores de nube. En IP4 Market encontrarás una plataforma con vendedores verificados y precios competitivos para comprar o alquilar el bloque que tu estrategia multinube necesita, con acompañamiento experto en transferencias, LOA y escrow. La escasez no va a remitir. Quien asegure su espacio IPv4 ahora tendrá una ventaja competitiva difícil de replicar; el resto, seguirá alquilando. Mes a mes. Sin fin.