Lleve IPv4 arrendadas a Azure con un Custom IP Prefix
Azure admite BYOIP mediante un recurso llamado Custom IP Prefix, disponible con carácter general en todas las regiones públicas de Azure.
Artem Kohanevich
Cofundador y CEO de IPbnb
Última actualización
Índice
elemento
Dos semanas antes de la transición, el responsable de red abre una hoja de cálculo que nadie ha tocado desde 2019. Cuarenta y un cortafuegos de clientes, cada uno con las mismas ocho direcciones IP públicas configuradas de forma fija. Esas direcciones pertenecen a un /24 que la empresa lleva una década anunciando desde su propio rack. El plan de migración dice Azure. La hoja de cálculo dice que esas direcciones no pueden cambiar.
Es el momento en que la mayoría de los equipos descubre BYOIP, y después descubre el segundo problema: la factura. Azure le asignará sin problema 256 IP públicas nuevas. Y también le cobrará por cada una de ellas, cada hora, indefinidamente.
Hay un camino mejor, y funciona tanto con espacio de direcciones arrendado como propio.
Cuánto cuestan las IP públicas de Azure en 2026
Azure cobra las IPv4 públicas por dirección y por hora. Cuatro reglas de facturación importan más que cualquier tarifa concreta, y las cuatro proceden directamente de las preguntas frecuentes de precios de Microsoft:
Una fracción de hora se factura como una hora completa.
Una IP pública estática en el modelo ARM se cobra independientemente del recurso al que esté asociada: detener una VM no detiene el contador. Solo las IP públicas dinámicas dejan de cobrarse mientras la VM asociada está detenida y desasignada.
Un Public IP Prefix se factura por IP y por hora desde el momento en que se crea el prefijo: reservar un bloque «para más adelante» cuesta lo mismo que usarlo.
La facturación de una IP estática comienza en la segunda hora tras su creación y solo se detiene cuando se elimina el recurso.
En cuanto a la tarifa: el aviso de retirada de la SKU Basic de Microsoft indica que, a partir del 31 de marzo de 2026, Static IPv4 Basic (ARM) sube de $0.0036/h a $0.005/h y Dynamic IPv4 Basic (ARM) de $0.004/h a $0.005/h, en ambos casos para igualarse a Standard (ARM). Eso sitúa la IPv4 estática Standard (ARM) en $0.005 por hora. La tabla de precios de Azure se filtra por región y moneda y carga sus cifras de forma dinámica, así que confirme el importe para su región y su contrato en la página de precios de direcciones IP antes de incluirlo en un caso de negocio.
Partiendo de $0.005/hora y un mes de 730 horas, una IPv4 estática Standard cuesta unos $3.65 al mes:
Tamaño del bloque | Direcciones | Coste mensual aprox. |
|---|---|---|
/28 | 16 | $58 |
/26 | 64 | $234 |
/24 | 256 | $934 |
Por tanto, un /24 de direcciones asignadas por Azure supone aproximadamente $11,200 al año, antes de un solo byte de tráfico saliente.
Los niveles superiores cuestan más. Standard v2 y Global (ARM) son partidas independientes en la tabla de precios de Azure, y el nivel Global en particular tiene un precio superior por su capacidad entre regiones. Recomiendo consultar esas tarifas en la calculadora en vivo en lugar de citarlas aquí.
¿Qué es un Custom IP Prefix (Azure BYOIP)?
Custom IP Prefix es el nombre que Microsoft da a BYOIP. Es un bloque contiguo de direcciones IP propiedad de un cliente externo y aprovisionado en su suscripción, que Microsoft queda autorizado a anunciar. La titularidad no se transfiere. Usted conserva el registro en el RIR; Azure se encarga del anuncio.
Una vez incorporadas, las direcciones de un Custom IP Prefix se comportan como las IP públicas propiedad de Azure: se asocian a recursos de Azure, interactúan con IP privadas y redes virtuales, y alcanzan destinos externos en salida desde la red de área extensa de Azure.
El argumento comercial es breve. No hay cargo por aprovisionar ni por usar Custom IP Prefixes, ni por ningún Public IP Prefix o dirección IP pública derivados de ellos. La página de precios incluye la misma nota al pie: no se cobra por el uso de ningún Public IPv4 Prefix derivado de Custom IPv4 Prefixes (BYOIP).
El tráfico saliente no cambia en ningún caso. El tráfico con destino a un rango de Custom IP Prefix se factura a la tarifa de salida a internet, igual que una IP pública de Azure en la misma región. BYOIP elimina la partida de alquiler de direcciones. No afecta a la partida de ancho de banda, y quien prometa lo contrario está vendiendo algo.
Conviene entender el modelo de recursos antes de empezar:
Un Custom IP Prefix no puede asociarse directamente a un recurso. Se deriva de él un Public IP Prefix y, de este, las IP públicas individuales.
El límite predeterminado es de cinco Custom IP Prefixes por región, ampliable bajo solicitud.
Los Public IP Prefixes que usan IP Standard v2 no pueden derivarse de un Custom IP Prefix, y no se admiten ni Internet Routing Preference ni el nivel Global utilizado para el balanceo de carga entre regiones.
En regiones con zonas de disponibilidad, el prefijo debe declararse con redundancia de zona o fijarse a una zona concreta al crearlo.
Requisitos
El propio bloque
El rango debe estar registrado a su nombre en uno de los cinco RIR (ARIN, RIPE NCC, APNIC, LACNIC o AFRINIC) y no puede ser menor que un /24, porque es el prefijo más pequeño que aceptan los ISP. No hay forma de evitarlo. Un /25 no funcionará, ni en Azure ni en ningún otro punto de internet público.
Unificado o global/regional
Azure ofrece dos modelos de despliegue, y un bloque no puede migrarse de uno a otro una vez incorporado: debe desaprovisionarse por completo y volver a incorporarse. Elija con criterio.
Unificado es el sencillo: el mismo rango lo anuncian tanto la WAN de Microsoft como la región de Azure, y puede ir de /21 a /24. Si va a llevar un bloque a una sola región, elija este.
Global/regional es una estructura padre/hijo. La WAN de Microsoft anuncia el rango global (padre), mientras que cada región de Azure anuncia los rangos regionales (hijos). Los rangos globales van de /21 a /24, los regionales de /22 a /26, y un hijo debe ser al menos un nivel más pequeño que su padre: un padre /23 admite hijos de /24 a /26. Durante el aprovisionamiento solo se valida el rango global; los hijos se derivan de él. Los hijos pueden estar en suscripciones distintas, pero deben compartir inquilino (tenant). Es el modelo para una infraestructura multirregión repartida entre equipos.
La ROA
Debe crear una Route Origin Authorization en el portal o la API de su RIR, firmada digitalmente con la RPKI de su RIR. Hay tres aspectos que deben ser correctos:
El AS de origen debe ser 8075 para la nube pública, u 8070 para US Gov Cloud.
La longitud del prefijo debe coincidir exactamente con la que anunciará Microsoft. Si va a llevar un /24 y un /23, incluya ambos.
La fecha de fin de validez debe cubrir todo el periodo durante el que quiere que Microsoft anuncie el bloque. Algunos RIR fijan esta fecha por usted.
Cuente con al menos 24 horas desde el envío para que la ROA esté disponible para Microsoft. Si otro ASN anuncia actualmente el bloque, Microsoft recomienda también crear una ROA para ese ASN y evitar así problemas durante la migración.
El mensaje firmado
Este paso es independiente de la ROA y suele pillar a muchos por sorpresa. Azure demuestra que el bloque pertenece a su suscripción comparando un mensaje firmado con un certificado que usted publica en el registro público.
Se genera un certificado X509 autofirmado con OpenSSL y se pega en los comentarios públicos del registro Whois/RDAP del prefijo: el campo Comments en ARIN y el campo Remarks del objeto inetnum en RIPE, APNIC y AFRINIC. Los titulares de LACNIC deben abrir en su lugar un ticket de soporte con Microsoft. A continuación se compone una cadena con el formato subscription-ID|prefix|expiry-date, con la fecha de caducidad coincidente con la de validez de la ROA, y se firma con la clave privada. El resultado en base64 se introduce en el portal.
Paso a paso: del aprovisionamiento a la puesta en servicio
1. Prepare. Cree la ROA para AS8075. Genere el par de claves, publique el certificado en el registro Whois/RDAP y firme el mensaje de autorización. Espere las 24 horas de propagación de la ROA.
2. Aprovisione. En el portal, busque Custom IP, abra Custom IP Prefixes y seleccione + Create. Indique el CIDR, la fecha de caducidad de la ROA en formato yyyymmdd, el mensaje firmado y la configuración de zona. El rango se envía de forma asíncrona al IP Deployment Pipeline de Azure; siga el progreso en el campo Commissioned state. El aprovisionamiento tarda unos 30 minutos.
3. Derive direcciones. Cuando el prefijo alcance el estado Provisioned, ábralo y seleccione + Add a public IP prefix, en la misma región. A partir de ahí, asigne IP públicas de SKU Standard y asócielas a NIC o a front-ends de balanceadores de carga. Todavía no se anuncia nada, así que nada es accesible. Esta es la parte útil: puede construir y probar toda la topología de destino antes de que se mueva un solo paquete.
4. Ponga en servicio. Seleccione Commission y elija el ámbito. El estado pasa a Commissioning, durante el cual el rango se anuncia parcialmente, y después a Commissioned. El despliegue completo tarda unas 3 o 4 horas.
El riesgo de la migración está aquí. A medida que el prefijo se pone en servicio, Microsoft lo anuncia desde la región local de Azure y después a nivel global a través de su red de área extensa bajo AS8075. Anunciar el mismo rango desde cualquier otro lugar al mismo tiempo puede provocar inestabilidad en el enrutamiento BGP o pérdida de tráfico. Planifique la transición dentro de una ventana de mantenimiento o utilice la opción de puesta en servicio solo regional, que limita el anuncio a la región de Azure en la que está desplegado el prefijo.
La puesta en servicio solo regional es la función infrautilizada en este caso. Le permite validar la accesibilidad dentro de una región mientras su anuncio anterior sigue activo a nivel global.
Si el aprovisionamiento falla, el recurso muestra un atributo FailedReason, que aparece como un aviso en el portal. ASN8075NotAllowedToAdvertise significa que la ROA falta o es incorrecta; un fallo del mensaje firmado significa que el mensaje no se puede verificar con el registro Whois/RDAP del prefijo.
Llevar un bloque IPv4 arrendado: qué cambia realmente
Conviene ser preciso sobre lo que exige Microsoft. La documentación indica que el rango debe ser de su propiedad y estar registrado a su nombre en un RIR, y Azure lo controla a nivel de registro: comprueba una ROA y un certificado que residen ambos en el objeto del RIR. En un bloque arrendado, ese objeto pertenece al titular de las IP, no al arrendatario.
Por tanto, BYOIP con espacio arrendado no es un atajo. Es un procedimiento entre dos partes que solo funciona con la colaboración activa del titular, y el contrato de arrendamiento debe redactarse en consecuencia. El reparto siguiente refleja dónde recae en la práctica cada requisito de Azure, según quién controla cada registro:
Tarea | Quién la realiza | Por qué |
|---|---|---|
ROA que autoriza AS8075 | Titular de las IP | Posee el objeto del RIR y las credenciales RPKI |
Publicación del certificado X509 en Whois/RDAP | Titular de las IP | Controla el objeto inetnum o net |
Generación del par de claves y firma del mensaje | Arrendatario | El mensaje contiene el ID de suscripción de Azure del arrendatario |
Creación del Custom IP Prefix en el portal | Arrendatario | Se ejecuta en la suscripción del arrendatario |
LOA que cubre el plazo de arrendamiento | Emitida por el titular, en poder del arrendatario | Práctica habitual con los proveedores de tránsito |
Una nota práctica sobre la gestión de claves: el arrendatario puede generar el par de claves localmente y entregar al titular únicamente el certificado público para su publicación. La clave privada que firma el mensaje de autorización no tiene por qué salir nunca del lado del arrendatario.
Tres aspectos que deben fijarse en el contrato de arrendamiento antes de aprovisionar:
La validez de la ROA debe superar el plazo de arrendamiento, con un responsable designado para su renovación. Una ROA caducada no impide que Microsoft siga anunciando, pero Microsoft advierte de que los operadores externos pueden dejar de aceptar el anuncio, y recomienda crear una ROA de seguimiento si ya ha pasado la fecha de caducidad original.
Retire el servicio antes de que cambie la ROA. Microsoft es explícito: debe retirar el rango del servicio antes de modificar o eliminar la ROA, o Microsoft seguirá anunciando un rango que ya no está autorizado a anunciar. Incorpore esto al proceso de salida del arrendamiento, no a un manual de procedimientos que nadie lee.
Revise la reputación antes de firmar. El historial en listas negras acompaña a las direcciones, y corregirlo a posteriori es más lento que comprobarlo antes.
Como el tamaño mínimo de incorporación es un /24, para la mayoría de las cargas de trabajo en Azure el arrendamiento también encaja mejor en términos económicos que la compra: necesita al menos 256 direcciones para participar, las necesite o no.
El cálculo de costes: 256 IP de Azure frente a un /24 arrendado con BYOIP
IP Standard asignadas por Azure | /24 arrendado con BYOIP | |
|---|---|---|
Coste de las direcciones | 256 × $3.65 ≈ $934/mes | $77–$90/mes |
Cargo por Public IP Prefix | Por IP y por hora, desde su creación | Ninguno |
Cargo por Custom IP Prefix | n/a | Ninguno |
Tráfico saliente | Tarifas estándar de internet | Tarifas estándar de internet |
Gasto anual en direcciones | ~$11,200 | ~$925–$1,080 |
Con la tarifa de arrendamiento publicada por IPbnb de $0.30–$0.35 por IP al mes, sin cuotas de plataforma, un /24 cuesta entre $77 y $90 al mes. Frente a unos $934 en cargos de direcciones de Azure, eso supone unos $850 al mes, cerca del 90% de la partida de direcciones, antes de contar el valor operativo de conservar direcciones que ya figuran en las listas de permitidos de sus clientes.
No hay periodo de amortización, porque Azure no cobra nada por la incorporación.
Dos advertencias honestas. El tráfico saliente es idéntico en ambos casos, así que si el ancho de banda domina su factura, el cambio es menor de lo que sugiere el porcentaje. Y está cambiando un coste totalmente gestionado por una relación de cumplimiento entre dos partes: ROA, certificados y fechas de renovación de los que alguien debe responsabilizarse. Para un puñado de direcciones que nadie recuerda, el contador de Azure sale más barato que la coordinación. Para un /24 con una década de reputación, no hay comparación.
Calcule sus propias cifras con la calculadora de precios de IPv4 y consulte nuestra visión general de BYOIP para los equivalentes en AWS y Google Cloud.
Preguntas frecuentes
¿Admite Azure BYOIP?
Sí. Azure admite BYOIP mediante un recurso llamado Custom IP Prefix, disponible con carácter general en todas las regiones públicas de Azure. Usted aporta su propio bloque IPv4 o IPv6, mantiene el registro en su RIR y autoriza a Microsoft a anunciarlo bajo AS8075.
¿Cómo funciona BYOIP (bring your own IP)?
Usted autoriza al proveedor de nube a anunciar un bloque que controla. En Azure, eso significa publicar una ROA con AS8075 como origen, demostrar la titularidad con un mensaje firmado que se coteja con un certificado de su registro Whois y, después, aprovisionar el bloque como Custom IP Prefix. Una vez puesto en servicio, Microsoft anuncia el rango y usted asigna direcciones de él como de cualquier otro.
¿Custom IP Prefix es gratuito?
Sí. Microsoft no cobra nada por aprovisionar ni usar un Custom IP Prefix, ni por los Public IP Prefixes y direcciones IP públicas derivados de él. El tráfico saliente se sigue facturando a las tarifas normales de internet.
¿Cuál es el tamaño mínimo de prefijo para Azure BYOIP?
Un /24, es decir, 256 direcciones, porque es el bloque más pequeño que aceptan los ISP. Los rangos unificados y globales (padre) van de /21 a /24; los rangos regionales (hijo) van de /22 a /26 y deben ser al menos un nivel más pequeños que su padre.
¿Puedo usar rangos IPv4 arrendados con Azure BYOIP?
En la práctica sí, pero solo con la colaboración del titular de las IP. Azure verifica la titularidad con el registro del RIR, que controla el titular, por lo que este debe crear la ROA para AS8075 y publicar su certificado X509 en los remarks del objeto inetnum. Usted genera las claves, firma el mensaje de autorización con su ID de suscripción y aprovisiona el prefijo. Confirme que la LOA cubre todo el plazo de arrendamiento y que la validez de la ROA se extiende más allá de él.
