Lleve IPv4 arrendadas a Google Cloud: guía de BYOIP

La factura llega el día tres del mes y alguien por fin lee la partida de red.

Es una historia conocida. Un equipo migra unos cientos de cargas de trabajo a Google Cloud, todo funciona a la perfección y nadie piensa en las direcciones IP hasta que el responsable financiero rodea una cifra con un círculo y pregunta a qué corresponde. La respuesta es incómoda: la empresa alquila a Google direcciones IPv4 públicas por horas, además de la capacidad de cómputo a la que están asociadas. Y paga ese alquiler indefinidamente, porque las direcciones son de Google, no de la empresa.

Hay una segunda versión de la misma historia con un final distinto. En ella, el equipo ya dispone de un /24, propio o arrendado a un titular de IP, y lo lleva a Google Cloud. Las direcciones conservan su reputación, su historial en listas blancas y su DNS inverso. El cargo por hora de las IP externas desaparece. El único coste que queda es el propio arrendamiento, una partida previsible que controla la empresa.

El mecanismo de esta segunda versión se llama GCP BYOIP, y esta guía lo recorre de principio a fin: cuánto cuesta, cómo funciona el modelo de prefijos de dos niveles, qué verifica realmente Google, cuánto tarda el aprovisionamiento y qué cambia cuando el bloque de IP es arrendado en lugar de propio.

Precios de las IP externas de GCP en 2026: lo que realmente está pagando

Antes de entrar en la mecánica de la migración, conviene ver la cifra que la migración pretende eliminar. Los precios actuales de Google para direcciones IP externas son estos:

Dos detalles de esta tabla sorprenden a la mayoría.

El primero es que una dirección inactiva cuesta el doble que una en uso. Google subió el precio de las direcciones en uso en VM en febrero de 2024 (de $0.004 a $0.005 para VM estándar y de $0.002 a $0.0025 para Spot), pero mantuvo la tarifa de las estáticas sin asignar en $0.01. Así, una dirección reservada que no hace nada se factura a $7.30 al mes, mientras que la misma dirección asociada a una VM en ejecución se factura a $3.65. Los equipos que reservan grupos de direcciones «para más adelante» pagan un sobreprecio por ello.

El segundo detalle importa a quien tenga el tráfico detrás de un balanceador de carga: las direcciones asociadas a reglas de reenvío ya son gratuitas. Si toda su infraestructura está detrás de balanceadores de carga externos, el precio de las IP externas no es su problema y BYOIP no le ahorrará dinero en esa partida. BYOIP ahorra dinero cuando las direcciones se asocian a VM y a pasarelas Cloud NAT.

A escala, un /24 completo (256 direcciones) queda así si todas las direcciones están en uso en VM estándar:

256 × $0.005 × 730 = $934.40 al mes, o $11,212 al año.

En instancias Spot, el mismo bloque cuesta $467.20 al mes. Reservado y sin uso, cuesta $1,868.80 al mes. Son cifras máximas; los despliegues reales combinan estados. Pero dan una idea de la magnitud de lo que está en juego.

Frente a todo ello, la propia documentación de Google resume la posición de BYOIP en una frase: no hay cargos por direcciones IP inactivas o en uso. Una vez importado su prefijo, las direcciones que se obtienen de él son gratuitas en cualquier estado: asignadas, sin asignar, en una VM estándar, en una VM Spot o detrás de Cloud NAT.

Cómo funciona GCP BYOIP: dos prefijos, no uno

La causa de confusión más habitual con Google Cloud BYOIP es que existen dos objetos de prefijo distintos con funciones diferentes. Entender esta división simplifica el resto del proceso.

El prefijo anunciado público (PAP) es el bloque que Google anuncia a internet en su nombre. Es una unidad única de anuncio de rutas. Es el objeto al que se vinculan su ROA y la validación de su DNS inverso, y es el que tarda semanas en aprovisionarse. Para IPv4 en el nivel Premium, un PAP puede ir de /16 a /24, de modo que un /24 es el bloque más pequeño que puede llevar, igual que en cualquier otro programa BYOIP en la nube, porque /24 es el prefijo más pequeño que la tabla de enrutamiento global acepta de forma fiable.

El prefijo delegado público (PDP) es una porción de ese PAP asignada a un proyecto concreto y a un ámbito concreto: una única región o global. Aquí es donde las direcciones pasan a ser utilizables. Un PDP de primer nivel puede ir de /16 a /28 en la configuración regional v2 recomendada, y puede tener el mismo tamaño que su PAP padre o ser más pequeño. Después puede dividir un PDP en subprefijos hasta un mínimo de /28, y esos subprefijos pueden delegarse a distintos proyectos de su organización. Se permiten hasta tres niveles de subdelegación a partir de un mismo PAP.

El valor práctico de esta división es que la parte lenta, la que depende del registro, se realiza una sola vez a nivel de PAP, mientras que la parte rápida, la que afecta a la organización, se repite a nivel de PDP. Un /24 importado como un único PAP puede dividirse en dieciséis subredes /28, repartidas entre dieciséis proyectos y regiones, sin volver a tocar BGP.

Una restricción estricta condiciona todo lo demás: Google no admite anuncios BYOIP solapados. Si un prefijo, o cualquier parte de él, se está anunciando en cualquier lugar fuera de Google, Google no debe anunciarlo al mismo tiempo. Hacer ambas cosas provoca un enrutamiento impredecible y pérdida de paquetes. Esta única regla determina toda la estrategia de transición, y es la razón por la que el calendario siguiente está ordenado como está.

Hay además una capacidad más reciente que conviene conocer. Para los prefijos delegados y subprefijos IPv4 v2 creados después del 13 de diciembre de 2025, Google habilitó la asignación mejorada de direcciones IP, que permite crear direcciones individuales a partir de un prefijo delegado. Los prefijos más antiguos solo podían generar grupos de direcciones de /17 a /28, lo que suponía un mínimo de dieciséis direcciones cada vez. Si aprovisiona hoy, obtiene el comportamiento granular.

Requisitos: lo que Google comprueba antes de enrutar su bloque

Google valida la titularidad con dos elementos. Ambos deben estar listos antes de iniciar el aprovisionamiento, y son la causa más habitual de retrasos cuando no lo están.

1. Una Route Origin Authorization (ROA) que indique el ASN de Google. Se crea en su RIR: RIPE NCC, ARIN, APNIC, LACNIC o AFRINIC. La ROA debe cubrir el prefijo y la longitud de prefijo exactos de su PAP, y debe autorizar el ASN de Google correspondiente al nivel de red elegido:

• Nivel Premium (predeterminado): AS 396982

• Nivel Estándar (vista previa): AS 19527, ya sea mediante ROA independientes para el PAP y cada PDP de primer nivel, o con una única ROA con maxLength /24

Google también recomienda crear una segunda ROA para el mismo prefijo con su propio ASN como origen. No cuesta nada y garantiza que, si alguna vez necesita volver a anunciar el bloque usted mismo, las redes que validan RPKI no descartarán su ruta como no válida.

Tenga en cuenta que la ROA debe mantenerse durante un tiempo después de eliminar el PAP: no es algo que deba revocarse en cuanto termine una migración.

2. Un registro PTR de DNS inverso. Al crear el PAP, designa una dirección no utilizada del bloque como dirección de verificación. Google devuelve una cadena de nombre de host generada (expuesta como sharedSecret en la API). A continuación, publica un registro PTR para esa dirección que apunte a esa cadena dentro de la zona DNS utilizada para su bloque, y solicita a Google que lo valide. Si todo va bien, el estado pasa a VALIDATED, o a REVERSE_DNS_LOOKUP_FAILED si la consulta no se resuelve.

Este segundo requisito es el que suele dar problemas con los bloques arrendados, y se trata en su propia sección más abajo.

Hay otros dos requisitos previos de carácter organizativo más que técnico. Alguien necesita el rol Compute Public IP Admin (roles/compute.publicIpAdmin), y Google recomienda aislar la administración de prefijos en un proyecto dedicado en lugar de mezclarla con los proyectos que consumen las direcciones. Si utiliza VPC compartida, las direcciones pueden crearse en el proyecto host y usarse en los proyectos de servicio, pero no crearse en un proyecto de servicio.

También conviene confirmar algo antes de comprometerse: no todos los recursos aceptan direcciones BYOIP. Los nodos y Pods de GKE no las aceptan. Tampoco las direcciones externas de las pasarelas Cloud VPN, ni clásicas ni HA, aunque una dirección BYOIP puede servir como dirección peer de un túnel VPN clásico. Y los grupos de instancias gestionados que asignan direcciones automáticamente tampoco, aunque sí los MIG con estado con direcciones estáticas asignadas al crear la VM. Compare su arquitectura con la lista de recursos compatibles de Google antes de firmar el arrendamiento.

Paso a paso: el flujo de trabajo de BYOIP con gcloud

Los comandos de gcloud para BYOIP se encuentran en gcloud compute public-advertised-prefixes y gcloud compute public-delegated-prefixes. La secuencia completa:

Paso 1: cree la ROA en su RIR. Hágalo lo primero y con antelación. La tramitación del RIR no depende ni de Google ni de usted.

Paso 2: cree el prefijo anunciado público. Para la configuración regional v2 recomendada:

Los nombres no pueden cambiarse más adelante sin eliminar y volver a crear el recurso, así que utilice una convención genérica y duradera, como pap-203-0-113-0-24.

Paso 3: obtenga el nombre de host de validación y publique el registro PTR.

Publique el PTR y, a continuación, inicie la validación:

Paso 4: espere al aprovisionamiento y aproveche la espera. Mientras se aprovisiona el PAP, cree sus prefijos delegados públicos y subprefijos. En v2 tardan minutos, no semanas, y pueden crearse antes de que el prefijo padre termine de aprovisionarse.

Paso 5: cree direcciones y asócielas a los recursos. Las direcciones obtenidas de un PDP solo funcionan dentro del proyecto y el ámbito al que se delegaron. Tenga en cuenta que todas las direcciones del bloque son utilizables: no hay dirección de subred ni de difusión reservadas, por lo que un /28 ofrece dieciséis direcciones utilizables, no catorce.

Paso 6: anuncie. Con los prefijos v2 no se anuncia nada automáticamente. Primero se anuncia un PDP y después el PAP padre:

Calendario: qué esperar

La documentación de Google indica los tiempos de aprovisionamiento, pero no explica qué ocupa el calendario. Este es su perfil realista:

Una advertencia si consulta la documentación usted mismo: la página de comprobación de estado sigue indicando cuatro semanas fijas, una cifra anterior a la configuración v2. La tabla comparativa del mismo conjunto de documentación es la vigente. Planifique dos semanas para v2, pero no se sorprenda si la propia interfaz de Google le indica la cifra antigua.

La cifra clave, por tanto, es de dos a cuatro semanas, y la variable que decide en qué extremo se sitúa es la configuración que elija. La configuración regional v2 se aprovisiona en unas dos semanas. La configuración v1 anterior y la configuración global tardan unas cuatro, y la global exige además que su proyecto se añada a una lista de permitidos mediante un caso de soporte, lo que supone más tiempo antes incluso de que empiece a correr el plazo.

El desaprovisionamiento es aún más lento, y esto pilla a muchos por sorpresa. Mover un prefijo delegado de una región a otra exige eliminarlo y volver a crearlo, lo que Google estima en aproximadamente ocho semanas. Decida dónde deben estar sus direcciones antes de aprovisionar, no después.

Las dos formas en que los equipos se atascan son evitables. La primera es iniciar la ROA en el RIR después de crear el PAP, lo que añade días al principio. La segunda es descubrir durante la validación que nadie controla el DNS inverso del bloque, lo que añade el tiempo que haga falta para organizar la delegación.

La transición: mover el tráfico sin renumerar

Aquí es donde la configuración v2 demuestra su valor, y conviene entenderlo con precisión, porque internet no permite anunciar el mismo bloque desde dos lugares a la vez.

Con un prefijo anunciado público v2, el aprovisionamiento y el anuncio son eventos independientes. Google completa toda la configuración interna de su bloque y después espera. No se anuncia nada hasta que usted ejecuta el comando de anuncio. Eso le da una ventana de preparación: sus direcciones existen dentro de Google Cloud, asociadas a VM y balanceadores de carga reales, totalmente configuradas y listas para probar, mientras su proveedor actual sigue anunciando el bloque y cursando el tráfico real.

La transición en sí se convierte entonces en un par de acciones coordinadas, no en un proyecto de renumeración:

1. Construya y valide todo en Google Cloud, con el prefijo sin anunciar.

2. Retire el anuncio de su red actual o de su proveedor de tránsito.

3. Anuncie el PDP y después el PAP en Google Cloud.

El tráfico sigue a la tabla de enrutamiento. La configuración de las aplicaciones, los registros DNS, las listas de permitidos de los cortafuegos y las integraciones con socios que hacen referencia a sus direcciones no cambian nunca, porque las direcciones no cambian. La convergencia en la tabla de enrutamiento global es cuestión de minutos y puede planificarse en una ventana de mantenimiento en lugar de en un trimestre de migración. El mismo enfoque escalonado se aplica tanto si se traslada a una nube como entre redes: nuestra guía sobre cómo migrar a IPv4 arrendadas sin tiempo de inactividad trata la parte de DNS y TTL de la misma operación.

Un matiz útil para las migraciones por fases: puede anunciar un prefijo delegado público dentro de Google Cloud sin anunciar a internet el prefijo anunciado público padre. Eso le permite poner en servicio una porción de forma interna mientras el bloque en su conjunto sigue anunciándose en otro lugar.

Una precaución sobre material antiguo que pueda encontrar en internet. El caso de éxito de Bitly publicado por Google en 2019 se sigue citando mucho por su enfoque de transición BYOIP, pero Google ha añadido desde entonces una nota del editor a esa publicación en la que indica que el método de transición descrito ya no es compatible. Trabaje con la documentación actual.

Si su /24 es arrendado, no propio

Todo lo anterior da por hecho que usted puede actuar como titular del bloque de IP. Cuando arrienda en lugar de ser propietario, algunos de esos pasos corresponden a otra persona, y el contrato de arrendamiento debe redactarse en consecuencia.

La ROA la crea el titular registrado, no usted. La autoridad de firma RPKI corresponde a quien figura como titular del recurso en el RIR. Su arrendador debe estar dispuesto y en condiciones de crear una ROA que autorice el ASN de Google para su prefijo, y de mantenerla durante todo el plazo más el periodo de desaprovisionamiento. Un titular de IP que no ofrezca esto no puede dar soporte a un despliegue BYOIP en la nube, diga lo que diga el anuncio.

El DNS inverso debe delegarse en usted. La validación de Google exige un registro PTR en la zona DNS del bloque. O bien el arrendador delega la zona inversa en sus servidores de nombres, o bien se compromete a publicar el registro de validación concreto cuando se le solicite. Confirme cuál de las dos opciones antes de firmar, y confirme también el plazo de respuesta: un arrendador que tarda tres semanas en publicar un registro PTR ha añadido tres semanas a su migración.

El plazo de arrendamiento debe cubrir todo el ciclo de vida. De dos a cuatro semanas para aprovisionar, la vida operativa del despliegue y hasta ocho semanas si alguna vez hay que mover direcciones de región. Un arrendamiento de doce meses de un bloque que tarda un mes en aprovisionar es, en realidad, un arrendamiento de once meses.

La exclusividad y los derechos de anuncio deben ser explícitos. Como Google no puede anunciar un bloque que se anuncia en otro lugar, el arrendamiento debe garantizar que ninguna otra parte anuncie su prefijo durante su vigencia. Los bloques subarrendados o compartidos son incompatibles con BYOIP.

Los registros del RIR deben estar limpios y ser coherentes. Google verifica la titularidad mediante la ROA y el DNS inverso, no mediante RDAP o whois. Pero sus pares, los equipos de seguridad de sus clientes y los operadores de bases de datos de abusos sí consultan RDAP, por lo que unos registros precisos y actualizados siguen siendo un requisito práctico, aunque no sean un control formal de Google.

En IPbnb estructuramos los contratos de arrendamiento precisamente en torno a estos requisitos, porque un bloque arrendado que no supera la verificación en la nube no es realmente un bloque utilizable. Si está evaluando opciones de alquiler de IP o titulares de IP para una migración a la nube, trate el soporte de ROA, la delegación del DNS inverso y la exclusividad de anuncio como criterios eliminatorios, no como algo deseable.

Cálculo de costes: un /24 arrendado en GCP

Compare las cifras de un /24 desplegado por completo en VM estándar:

La comparación relevante es la de las dos últimas filas frente a la primera: el cargo de Google por IP externas pasa a cero y se sustituye por un arrendamiento que cuesta menos de una décima parte. En un /24 utilizado al completo, el ahorro ronda los $10,100 a $10,300 al año, y el bloque llega con una reputación consolidada y un historial limpio, algo que ninguna dirección de nube recién asignada tiene.

Como referencia, las tarifas de arrendamiento de mercado en la región de RIPE rondan los $0.30 a $0.35 por IP al mes, y pueden ser más altas en regiones con oferta limitada. Las tarifas también varían según la reputación del bloque: los bloques limpios tienen un precio superior, y los bloques con historial en listas negras se negocian con un descuento de alrededor del 40%. Las direcciones baratas son baratas por algo, y en una migración en la que las listas de permitidos de los socios son lo esencial, la reputación no es el lugar donde ahorrar.

Tres advertencias honestas sobre el cálculo. Las direcciones detrás de reglas de reenvío ya eran gratuitas, por lo que una infraestructura basada en balanceadores de carga ahorra menos. El ahorro crece con la utilización, de modo que un /24 medio vacío ahorra aproximadamente la mitad. Y las semanas de aprovisionamiento son tiempo real de ingeniería que debe figurar en el caso de negocio.

Calcule sus propias cifras con su número real de direcciones y su utilización en la calculadora de precios de IPv4 antes de comprometerse.

Preguntas frecuentes

¿Cobra Google Cloud por las direcciones BYOIP?

No. La documentación de Google es explícita: no hay cargos por direcciones IP BYOIP inactivas o en uso. Una vez importado su prefijo, las direcciones obtenidas de él son gratuitas tanto si están asociadas a un recurso como si están sin asignar, lo que supone una diferencia importante respecto a las direcciones estáticas asignadas por Google, en las que una dirección sin asignar cuesta $0.01 por hora. Se siguen aplicando los cargos habituales de transferencia de datos, balanceo de carga y cómputo.

¿Cuáles son los límites de BYOIP en Google Cloud?

Los principales: el prefijo anunciado debe estar entre /16 y /24 para IPv4 en el nivel Premium (/16 a /23 en el nivel Estándar, en vista previa), por lo que /24 es el bloque más pequeño que puede llevar. Los prefijos delegados van de /16 a /28 en el nivel Premium v2 (/17 a /24 en el nivel Estándar), los subprefijos llegan como mínimo a /28 y un prefijo puede subdelegarse hasta tres veces. El aprovisionamiento tarda varias semanas y no puede acelerarse. Las direcciones no pueden moverse entre proyectos. No se admiten anuncios solapados. Y varios tipos de recursos quedan excluidos: nodos y Pods de GKE, direcciones externas de pasarelas Cloud VPN y MIG que asignan direcciones automáticamente.

¿Cuánto tarda GCP BYOIP?

Aproximadamente dos semanas en la configuración regional v2 recomendada, y aproximadamente cuatro semanas en la configuración v1 anterior o para prefijos globales. Los prefijos globales requieren además, previamente, una solicitud de inclusión en la lista de permitidos mediante un caso de soporte. Sume al principio el tiempo de tramitación de la ROA en el RIR y prevea hasta ocho semanas si alguna vez un prefijo delegado debe trasladarse a otra región.

¿Puedo dividir un rango entre Google Cloud y mi propia infraestructura?

No dentro de un mismo prefijo anunciado. Google no puede anunciar un bloque que se anuncia simultáneamente en otro lugar, de modo que todo el PAP debe ser exclusivo de Google mientras esté anunciado. Lo que sí puede hacer es dividir en el límite del anuncio: si dispone de un /23, lleve un /24 a Google Cloud como su propio PAP y mantenga el otro /24 en su propia red. Dentro de Google Cloud, los prefijos delegados le permiten después repartir ese /24 entre regiones y proyectos con una granularidad de hasta /28. Y para traslados por fases, un prefijo delegado puede anunciarse dentro de Google Cloud mientras el prefijo padre sigue anunciándose desde su infraestructura actual.

¿Puedo usar direcciones IPv4 arrendadas para GCP BYOIP?

Sí. Google verifica el control del bloque mediante una ROA y un registro PTR de DNS inverso; no exige que usted sea el titular registrado. Lo que sí exige es que el titular registrado colabore: el arrendador crea la ROA que apunta al ASN de Google, delega o publica el DNS inverso y garantiza que nadie más anuncie el bloque. Un arrendamiento que incluya esas tres condiciones funciona con BYOIP sin complicaciones.

Llevar un /24 arrendado a Google Cloud no es un proyecto difícil, pero sí un proyecto secuencial. El esfuerzo de ingeniería es pequeño; la espera no lo es, y casi toda la espera se concentra al principio, en trabajos de registro y DNS que pueden iniciarse antes de que nadie toque la consola.

Si está comparando un bloque arrendado con direcciones asignadas por Google, empiece por su número de direcciones y su utilización, y después compruebe las condiciones del arrendamiento frente a los cuatro requisitos anteriores. Y si está haciendo la misma evaluación en otra nube, nuestra guía complementaria trata cómo llevar IPv4 arrendadas a Azure con un Custom IP Prefix, donde el modelo y la terminología difieren más de lo que cabría esperar.

Descubra bloques IPv4 preparados para BYOIP en IPbnb →