BYOIP en AWS y Azure: requisitos y configuración de IPv4

¿Qué es BYOIP y por qué importa en AWS y Azure?

BYOIP en AWS y Azure (Bring Your Own IP) consiste en importar un rango propio de direcciones IPv4 a una nube pública y usarlo como si fuera espacio del proveedor. ¿Por qué alguien querría hacer eso? Las razones suelen ser tres: conservar la reputación de esas IPs en listas de correo y allowlists corporativas, no tener que reescribir reglas de firewall en clientes y partners, y mantener el servicio intacto durante una migración desde un datacenter propio o colocation.

Sin BYOIP, al moverte a la nube pierdes tus direcciones públicas. Y con ellas, todo lo que cuelga de ahí: registros PTR, SPF, la reputación en ReputationAuthority, esas integraciones con proveedores que solo aceptan tráfico desde IPs conocidas. Para un ISP o un operador de hosting, esto no es un inconveniente menor. Puede ser directamente el motivo por el que el proyecto se bloquea.

Requisitos previos comunes a AWS y Azure

Ambos hiperescaladores exigen que demuestres control estricto sobre el rango que quieres traer. Lo que piden en común:

• Tamaño mínimo /24: el prefijo más pequeño admitido es un /24 (256 direcciones). Rangos más específicos no se pueden anunciar de forma fiable en la tabla global de BGP.
• Propiedad registrada: el rango debe figurar a nombre de tu organización en el RIR correspondiente (RIPE NCC, ARIN, APNIC, LACNIC o AFRINIC). AWS y Azure verifican los datos del registro WHOIS/RDAP.
• ROA (Route Origin Authorization) en RPKI: tienes que crear un ROA que autorice al AS del proveedor a anunciar tu prefijo, con longitud máxima igual al prefijo (por ejemplo, max-length 24 para un /24).
• LOA (Letter of Authorization): un documento firmado que autoriza al proveedor a originar el anuncio BGP. Ambos tienen plantillas propias.
• Rango no anunciado: durante la verificación, el prefijo no debe estar anunciándose desde otra ubicación, ni puede estar asignado a otra cuenta cloud.

Requisitos y cuota en AWS

AWS admite BYOIP en EC2, ELB, CloudFront, Global Accelerator y Outposts. Lo que conviene saber:

• Los rangos deben venir de uno de los cinco RIR y estar registrados a tu nombre; en algunas verificaciones de ARIN se exige una antigüedad mínima de 90 días.
• Creas un objeto de aprovisionamiento con aws ec2 provision-byoip-cidr, incluyendo la firma del mensaje (CIPC, basada en certificado X.509 del RIR o en un hash del mensaje).
• Puedes anunciar el /24 completo o subrangos más específicos (hasta /26 en algunas regiones) mediante anuncios parciales, algo útil si divides el uso entre on-premise y AWS.
• Cada cuenta puede traer hasta 5 prefijos por región por defecto. Ampliable, solicitando cuota.
• AWS cobra por mantener el rango traído (aproximadamente 0,01 dólares por hora, unos 7 dólares al mes por CIDR), además del uso normal de IP elásticas.

Pasos de configuración en AWS

1. Crea el ROA en tu RIR autorizando al AS de AWS de la región (por ejemplo, AS16509 o los AS regionales que indique la documentación) con max-length igual al prefijo.
2. Firma el LOA de AWS y súbelo junto con el certificado del RIR durante el aprovisionamiento.
3. Ejecuta provision-byoip-cidr con el CIDR y la firma. El estado pasará de pending-provision a provisioned. Puede tardar varias horas.
4. Anuncia el rango con advertise-byoip-cidr una vez aprovisionado.
5. Asocia el rango a Elastic IPs con allocate-address –domain vpc indicando el pool de tu CIDR, y úsalas en instancias, NLB o ALB.

Requisitos y configuración en Azure

Azure llama a esto Custom IP Address Prefix, y solo está disponible en regiones con Availability Zones. ¿En qué se diferencia de AWS?

• Azure exige que el rango no se haya anunciado en los 30 días previos, ni esté asociado a otra suscripción.
• El proceso pasa por crear un custom IP prefix, subir el LOA firmado y las pruebas de registro (la asignación del RIR), y esperar una validación que incluye un periodo de comprobación de 24 a 72 horas sin anuncios. Sí, hay que esperar.
• Los prefijos personalizados admiten rangos de /24 a /21 (global) y pueden separarse en prefijos hijos regionales, con mínimo /24.
• Se factura por prefijo activo, con un coste aproximado de 0,05 a 0,08 dólares por hora según la región (unos 40-60 dólares al mes por un /24). Notablemente más caro que AWS.

Pasos de configuración en Azure

1. Delegación: crea el ROA en tu RIR autorizando al AS 8075 (Microsoft) con max-length 24.
2. Crea el recurso Custom IP Prefix en el portal o con Azure CLI (az network custom-ip prefix create), indicando región y CIDR.
3. Sube el LOA firmado y la documentación de asignación del RIR (el fichero firmado del registro).
4. Espera la validación del estado (validating, provisioning, provisioning succeeded) y después comisiona el prefijo. Detalle curioso: Azure exige primero comisionar en modo decommission durante las pruebas; el anuncio solo se activa al pasar a estado commissioned.
5. Deriva direcciones IP públicas estándar desde el prefijo y asígnalas a Load Balancers, Firewalls o VMs.

Errores frecuentes y cómo evitarlos

• ROA mal configurado: si el max-length permite prefijos más largos de los que anuncia el proveedor, la validación RPKI puede fallar o dejar tu rango como inválido (invalid) para terceros. Ajusta el max-length exactamente.
• Anuncios solapados: si sigues anunciando el rango desde tu propio AS, AWS o Azure no completarán la verificación. Planifica la ventana de migración y corta los anuncios previos.
• WHOIS desactualizado: el contacto de abuso y la organización registrada deben coincidir con la entidad que firma el LOA. Parece obvio, pero pasa mucho.
• Olvidar el PTR: ya en la nube, configura los registros PTR para tus IPs si envías correo; en ambos proveedores esto requiere solicitud al soporte o automatización vía API.

¿No tienes tu propio rango? Comprar IPv4 para BYOIP

Quizá tu organización no dispone de un bloque propio. En ese caso la vía habitual es comprar un /24 en el mercado secundario. Los precios de un /24 IPv4 rondan los 25-35 dólares por dirección (entre 6.000 y 9.000 dólares por bloque), y la transferencia entre RIRs puede tardar de semanas a meses según el registro. Existe la alternativa de alquilar, que sale por unos 100-150 dólares mensuales por /24; aunque para BYOIP en nube, ser propietario simplifica el LOA y te ahorra renovaciones incómodas.

En IP4 Market encontrarás una plataforma con vendedores verificados, escrow de transferencias y precios competitivos, con bloques /24 listos para registro limpio en RIPE NCC u otro RIR. Ese registro limpio es justamente lo que AWS o Azure van a exigirte para aceptar la solicitud.

Conclusión

BYOIP en AWS y Azure es una solución madura que elimina la principal fricción de migrar a la nube: perder tus direcciones IPv4. Los requisitos son estrictos, pero claros: propiedad registrada en un RIR, un /24 como mínimo, ROA en RPKI y LOA firmado. La diferencia práctica está en el proceso. AWS lo automatiza vía CLI con firma criptográfica y cuesta menos (unos 7 dólares al mes por CIDR); Azure exige validaciones más largas y un desembolso mayor, aunque integra bien con Firewalls y Load Balancers estándar. Antes de lanzarte, audita tus anuncios BGP actuales, prepara la documentación en el RIR y planifica bien la ventana de corte de anuncios. Y si necesitas comprar un bloque, hazlo con un marketplace fiable como IP4 Market, para asegurar un rango limpio y transferible que supere las verificaciones de ambos proveedores.