Guía de dimensionamiento de subredes IPv4: cómo elegir el tamaño de bloque adecuado para su caso de uso

Hay dos formas de equivocarse al dimensionar un bloque IPv4, y ambas salen caras.

La primera es arrendar un bloque demasiado pequeño. Hace una estimación conservadora, el proyecto crece más rápido de lo previsto y, en el cuarto mes de un contrato de seis, vuelve a estar en el mercado con prisas: paga un sobreprecio por la urgencia, asume el coste operativo de incorporar un segundo bloque y funciona con capacidad reducida mientras tanto.

La segunda es arrendar un bloque demasiado grande. El bloque se queda al 30% de uso. Paga cada mes por direcciones inactivas, y esas direcciones inactivas no son neutrales: acumulan tráfico de sondeo, generan denuncias de abuso de escáneres automatizados y deterioran discretamente la reputación de las IP activas que tienen al lado.

El tamaño adecuado surge de combinar tres factores: su caso de uso, su horizonte de crecimiento y unas cuantas restricciones operativas que no resultan evidentes hasta que alguien se las explica. Eso es lo que hace esta guía.

Si necesita una introducción técnica a cómo funciona el arrendamiento de IPv4 antes de dimensionar, empiece aquí: cómo funciona el arrendamiento de IPv4 →

Tamaños de bloque IPv4 de un vistazo

Presupuesto y precios

Las tarifas de arrendamiento escalan de forma aproximadamente lineal con el tamaño del bloque: un /22 cuesta aproximadamente cuatro veces lo que un /24 con la misma tarifa por IP, porque contiene cuatro veces más direcciones. Un /22 suele costar $307-358/mes; un /21, $614-717/mes.

La comparación más relevante es la tarifa mensual frente al coste de equivocarse de tamaño: un segundo bloque de emergencia adquirido a mitad de proyecto, con precios de urgencia y un segundo proceso de incorporación, siempre cuesta más que dimensionar al alza desde el principio. Para conocer el precio exacto según tamaño, región y disponibilidad: calculadora de precios de IPv4 →

Las cuatro variables que determinan su decisión de tamaño

Antes de asociar un caso de uso a un tamaño de bloque, necesita un marco de referencia. Estas cuatro variables determinan la respuesta correcta en cualquier escenario.

Tasa de uso prevista

No todas las IP de un bloque arrendado estarán activas a la vez, y en algunos casos de uso es intencionado. Los proveedores de hosting suelen trabajar con un 60-80% de uso. Los remitentes de correo mantienen deliberadamente un número menor de IP activas para proteger su reputación como remitentes: un pool de 50 IP de envío activas dentro de un /24 es una práctica normal, no un desperdicio. La regla práctica es sencilla: si su uso previsto en régimen estable supera el 85%, suba un escalón de tamaño. Trabajar con un bloque cerca de su capacidad no deja margen para absorber picos de tráfico sin afectar a la reputación o a la calidad del servicio.

Horizonte de crecimiento frente a plazo de arrendamiento

Un bloque debe dimensionarse para el final del plazo de arrendamiento, no para el principio. Si firma hoy un contrato de 12 meses, dimensione para el mes 10 de ese contrato, no para lo que necesita ahora mismo. Si ese cálculo da como resultado un bloque que le parece demasiado grande para su situación actual, valore si un plazo inicial más corto con una ampliación planificada tiene más sentido operativo que un compromiso a largo plazo con un espacio que va a saturar enseguida.

Capacidad de gestión de la reputación

Los bloques grandes son más difíciles de supervisar. Un /19 (8.192 direcciones) gestionado por un equipo de infraestructura de tres personas significa miles de IP que podrían estar generando actividad abusiva sin que nadie se dé cuenta. Dimensione según lo que su equipo pueda supervisar activamente. IPbnb ofrece supervisión de abusos 24/7 en todos los arrendamientos, lo que eleva notablemente el techo de lo que puede gestionar un equipo pequeño, pero la supervisión de la plataforma no sustituye a su propio control operativo. La reputación del bloque influye directamente en las condiciones de renovación y en la flexibilidad futura, así que descuidarla tiene costes acumulativos.

Disciplina presupuestaria

Las tarifas de arrendamiento escalan de forma aproximadamente lineal con el tamaño del bloque. Un /22 cuesta aproximadamente cuatro veces lo que un /24 con la misma tarifa por IP. La pregunta no es solo qué tamaño necesita, sino cuánto le costaría quedarse corto si necesita un segundo bloque de emergencia, frente a lo que cuesta cada mes sobredimensionar en direcciones inactivas. En la mayoría de los casos, dimensionar correctamente desde el principio es más barato que cualquiera de los dos errores.

Dimensionamiento por caso de uso

Proveedor de hosting / hosting compartido

Recomendado: de /23 a /21

El hosting compartido asigna aproximadamente una IP por cuenta de cliente, y algunas cuentas necesitan IP adicionales para certificados SSL, dominios de envío dedicados o aislamiento entre clientes. Un /23 (512 direcciones) cubre aproximadamente 400-500 cuentas con un nivel de uso holgado. El crecimiento suele producirse en incrementos de /23 a medida que aumenta el número de clientes.

El hosting es uno de los entornos con mayor riesgo de abuso para el IPv4 arrendado. Los clientes envían correo, ejecutan aplicaciones web y, ocasionalmente, incumplen las políticas de uso aceptable de formas que afectan a la reputación de las IP vecinas del mismo /24. Por eso es especialmente importante supervisar la reputación por cada /24: un problema con el comportamiento de un cliente puede afectar a todos los demás del mismo rango. La supervisión de abusos de IPbnb cubre esto a nivel de plataforma, pero el operador de hosting sigue necesitando unas condiciones de uso aceptable claras para sus clientes y un proceso interno rápido de respuesta a las quejas.

El error habitual: arrendar un /24 para lanzar un negocio de hosting, asignar IP a 200 cuentas y descubrir que no queda espacio para crecer sin volver al mercado. Si tiene 150 clientes o más, empiece con un /23. Si prevé alcanzar esa cifra en seis meses, empiece igualmente con un /23.

Ver bloques /23 y /22 disponibles →

Despliegue en la nube / BYOIP

Recomendado: /24 como mínimo; /23 o /22 para despliegues multirregión o multiservicio

AWS, GCP y Azure exigen un mínimo de /24 para BYOIP. Es una restricción estricta: un /25 o menor será rechazado por el proceso de incorporación del proveedor cloud, por limpio que sea el bloque. No hay forma de evitarlo.

Más allá del mínimo: un único /24 basta para un servicio en una región. Si despliega en varias regiones, ejecuta servicios que necesitan aislamiento de reputación entre sí o está escalando un producto orientado al cliente, un /23 o un /22 le da margen para segmentar cargas de trabajo sin volver al mercado a mitad del despliegue.

El caso de uso de BYOIP en la nube tiene requisitos de reputación específicos que van más allá del arrendamiento estándar. AWS se reserva expresamente el derecho a rechazar prefijos con mal historial. La reputación del bloque debe poder verificarse antes de iniciar el proceso de validación del proveedor cloud, que puede tardar de una a dos semanas (y la incorporación en GCP suele tardar más), y que no puede repetirse rápidamente si se rechaza un bloque. Empezar con un bloque que no supera la validación significa volver a empezar.

El error habitual: arrendar el /24 mínimo para un despliegue en la nube que va a crecer y descubrir a mitad de proyecto que la ampliación requiere un bloque aparte, una LOA aparte y un nuevo proceso de incorporación BYOIP con el proveedor cloud. Si el crecimiento en la nube está en su hoja de ruta, dimensione para 12 meses de crecimiento desde el principio.

Para consultar los requisitos de configuración completos de cada proveedor: BYOIP con IPv4 arrendado en AWS, GCP y Azure →

ISP / pequeño operador de telecomunicaciones

Recomendado: de /21 a /18 según el número de abonados

Los ISP asignan IP a sus abonados: los clientes empresariales suelen recibir una dirección dedicada o un pequeño bloque, y los abonados residenciales comparten IP mediante NAT. El tamaño del bloque depende del número de abonados y de las previsiones de crecimiento, no de una fórmula fija.

Un punto de partida práctico: con una IP por abonado empresarial y un NAT de 8:1 para residenciales, un /21 (2.048 direcciones) da servicio a unos 500-800 abonados empresariales, o a una base mixta de varios miles de abonados residenciales. A partir de ahí, amplíe en incrementos de /21 o /20.

Los ISP suelen firmar plazos de arrendamiento más largos que otros tipos de operadores: los contratos anuales son lo habitual. Esto hace que el dimensionamiento inicial sea especialmente determinante. Quedarse corto en un contrato de 12 meses significa trabajar al límite de la capacidad durante todo el contrato o negociar un bloque adicional a mitad de plazo, lo que añade coste y complejidad operativa.

El error habitual: dimensionar según el número actual de abonados sin tener en cuenta los que están en proceso de alta. Si hoy tiene 200 clientes activos y 80 operaciones en curso, dimensione para 280, no para 200.

Operador de VPN / servicio de proxy de privacidad

Recomendado: de /22 a /20

Los operadores de VPN y proxy necesitan diversidad geográfica y de reputación en sus nodos de salida, y a menudo deben rotar IP a medida que algunas direcciones acumulan incidentes de reputación. Un /22 (1.024 direcciones) ofrece rango suficiente para una rotación y una diversidad significativas en despliegues pequeños y medianos.

El tráfico VPN genera, por su propia naturaleza, una tasa de quejas por abuso más alta que la mayoría de los demás casos de uso, no por negligencia del operador, sino porque los nodos de salida atraen escaneos de puertos, infracciones de las políticas por parte de los usuarios y falsos positivos automatizados. Por eso la supervisión activa y una respuesta rápida a los abusos son innegociables. También significa que el bloque necesita un margen por encima del número de IP activas, precisamente para absorber incidentes de reputación sin afectar a los usuarios que están en direcciones limpias.

Una nota sobre el uso aceptable: algunas plataformas restringen los casos de uso de VPN y proxy o exigen su aprobación previa. Compruébelo antes de firmar. El equipo de IPbnb puede asesorarle sobre configuraciones compatibles y parámetros de uso aceptable durante la incorporación.

El error habitual: arrendar un /24 para un servicio VPN sin margen. Después de que unos cuantos incidentes de abuso afecten a varias IP, el pool utilizable se reduce hasta el punto de que los usuarios activos notan el impacto.

Ver bloques /22 para despliegues VPN →

Envío de correo / infraestructura de ESP

Recomendado: un /24 por pool de envío

La mayoría de los grandes proveedores de buzones evalúan la reputación del correo a nivel de /24. Un /24 dedicado por flujo de envío (correo transaccional, correo de marketing, envíos específicos de un dominio) aísla los daños de reputación entre pools. Mezclar tipos de envío en IP compartidas significa que un problema de entregabilidad en un flujo los afecta a todos.

En el correo, dimensionar es más una cuestión de aislamiento que de cantidad. La mayoría de las operaciones de envío no necesitan 256 IP activas: necesitan IP limpias, dedicadas, correctamente calentadas y asignadas a fines concretos. Un /24 por pool, calentado gradualmente hasta el volumen de envío completo, es el enfoque estructural correcto.

El error habitual: arrendar un único bloque grande y enviar todo el tráfico de correo a través de él. Cuando una campaña de marketing provoca un pico de quejas por spam, afecta al correo transaccional que sale por las mismas direcciones, y la entregabilidad transaccional es mucho más difícil de recuperar que la de marketing.

Para un análisis detallado de cómo es en la práctica la supervisión de la reputación de IP: herramientas y buenas prácticas de reputación de IP →

SaaS / aplicación con uso intensivo de API

Recomendado: /24

Las cargas de trabajo SaaS suelen necesitar IP limpias y estables para la autenticación de API, los webhooks salientes y las listas de permitidos de los clientes empresariales. Aquí la estabilidad de las IP importa más que la cantidad. Un único /24 es suficiente para la mayoría de los equipos SaaS que operan en una región.

Una separación importante: si el producto también envía correo transaccional (recibos, alertas, restablecimiento de contraseñas), utilice un /24 dedicado para ese tráfico, separado del tráfico de API. Mezclar ambos en las mismas IP complica considerablemente la gestión de la reputación, porque los perfiles de riesgo del tráfico de API y del tráfico de correo son distintos y requieren enfoques de supervisión diferentes.

Ver bloques /24 limpios para despliegues SaaS →

Centro de datos / operador de colocation

Recomendado: de /21 a /20

Los centros de datos asignan IP a los servidores y servicios de sus clientes. Un /21 (2.048 direcciones) cubre una instalación de colocation de tamaño medio. En entornos multiinquilino, valore si arrendar varios /22 le ofrece más flexibilidad operativa que un único bloque grande: los rangos /24 no contiguos pueden asignarse por cliente para lograr un mejor aislamiento, lo que simplifica la gestión de la reputación y limita el alcance de los daños cuando un solo cliente causa problemas.

El error habitual: dar por hecho que un gran bloque contiguo siempre es más fácil de gestionar que varios más pequeños. A escala de centro de datos, el aislamiento de IP por cliente suele pesar más que la comodidad administrativa de un único prefijo grande.

Ver bloques /21 y /20 disponibles →

Proyecto a corto plazo / pruebas / staging

Recomendado: /24, mes a mes

Para cargas de trabajo temporales (pruebas de carga, entornos de staging, experimentos de infraestructura a corto plazo), un /24 ofrece espacio de direcciones suficiente para la mayoría de los casos de uso sin comprometerse en exceso. Los plazos mes a mes sin permanencia mínima mantienen bajos los costes de salida y le dan total flexibilidad para devolver el bloque cuando termine el proyecto.

Confirme que la plataforma admite plazos cortos y flexibles antes de firmar. IPbnb admite el arrendamiento mes a mes sin necesidad de compromiso a largo plazo.

Ver bloques /24 mes a mes →

Referencia rápida: tamaño de bloque por caso de uso

Qué ocurre si elige un tamaño equivocado

Equivocarse de tamaño, en cualquiera de los dos sentidos, tiene un coste previsible.

Demasiado pequeño: vuelve al mercado con prisas. En la región de RIPE, conseguir e incorporar un bloque adicional a mitad de proyecto lleva tiempo, y la urgencia obliga a pagar un sobreprecio. Trabajar al límite de la capacidad mientras tanto afecta a la calidad del servicio y a la reputación de las IP. Corregir un bloque infradimensionado a mitad de contrato casi siempre cuesta más que dimensionar correctamente desde el principio.

Demasiado grande: las direcciones inactivas no son neutrales. Un bloque al 20-30% de uso genera tráfico de sondeo y denuncias de abuso en todo el rango sin usar, lo que crea un riesgo de reputación sin ningún valor operativo que lo compense. En la región de RIPE, se espera que los operadores demuestren un uso eficiente del espacio de direcciones: un bloque infrautilizado puede complicar las negociaciones de renovación y atraer un escrutinio que preferiría evitar.

Cómo justificar internamente su decisión de tamaño

La mayoría de las decisiones de dimensionamiento implican a alguien que no es ingeniero de redes: un responsable financiero, un CTO o un responsable de compras que quiere entender por qué se ha solicitado un tamaño de bloque concreto antes de aprobar el gasto. Estos tres enfoques funcionan bien tanto con interlocutores técnicos como no técnicos.

El coste de quedarse corto. Volver al mercado a mitad de proyecto significa pagar un segundo bloque a precio de urgencia, asumir un segundo proceso de incorporación y, posiblemente, trabajar con capacidad reducida mientras tanto. Dimensionar correctamente desde el principio casi siempre cuesta menos que solucionar una escasez a mitad de contrato. Si le presionan para elegir un bloque más pequeño y ahorrar en el gasto mensual, calcule lo que costaría adquirir un bloque de emergencia (en tarifas, tiempo operativo y retrasos del proyecto) y compare ambas cifras.

El coste de sobredimensionar. Las IP inactivas cuestan dinero y generan riesgo. Un bloque al 30% de uso está generando exposición a abusos en el 70% de su espacio de direcciones sin ningún ingreso ni valor operativo que lo compense. Los equipos financieros responden bien al argumento de que el espacio de direcciones inactivo es un pasivo, no un colchón. El objetivo no es la máxima capacidad, sino la capacidad adecuada.

El modelo de ocupación. Plantee la decisión de tamaño como un gestor inmobiliario plantea la ocupación de un edificio: objetivo del 70-80% de uso en régimen estable, con holgura para picos o crecimiento. Por debajo del 60% hay desperdicio; por encima del 90% hay riesgo operativo y no queda margen de error. Este modelo ofrece a los interlocutores no técnicos un marco mental claro para evaluar la solicitud y hace que el razonamiento sea auditable si la decisión se revisa en el futuro.

Cuatro errores de dimensionamiento que conviene evitar

Dimensionar para hoy y no para el final del plazo de arrendamiento. El tamaño del bloque debe reflejar el uso en el mes 10 de un arrendamiento de 12 meses. Un bloque que encaja perfectamente el primer día pero se satura en el sexto mes es un fallo de planificación con un coste previsible.

Confundir el tamaño del bloque con su calidad. El /22 más barato del mercado puede serlo por algún motivo: historial de abusos, entradas en listas negras, irregularidades de enrutamiento. El tamaño y la reputación del bloque son decisiones distintas. No sacrifique calidad por tamaño para ahorrar en la tarifa mensual. Los costes posteriores de gestionar un bloque sucio (fallos de entregabilidad, gestión de quejas por abuso, tiempo de recuperación de la reputación) superan sistemáticamente el ahorro.

Para un repaso completo de lo que debe comprobar antes de arrendar: seis errores habituales al arrendar IPv4 →

Planificar la división de un bloque arrendado en anuncios más específicos sin verificar que el upstream lo admite. Muchas redes filtran los prefijos más específicos que /24. Si su plan depende de anunciar un /23 como dos /24 separados (por diversidad geográfica o separación de tráfico), confirme antes de firmar que su upstream lo admite expresamente. Es una configuración válida, pero requiere una coordinación con el upstream que no todos los proveedores ofrecen.

Arrendar un único bloque grande cuando varios bloques más pequeños serían más adecuados. En los casos de uso que necesitan diversidad de IP entre clientes, servicios o zonas geográficas (hosting, centros de datos, VPN), varios /24 o /23 suelen superar a un único /21 en aislamiento de reputación y flexibilidad operativa. La consolidación parece más sencilla sobre el papel. En la práctica, la segmentación limita el alcance de los daños cuando algo falla.

Acertar con el tamaño desde el principio elimina dos de los costes más habituales y más evitables del arrendamiento de IPv4. La mayoría de los equipos o bien saben aproximadamente lo que necesitan y buscan una confirmación, o bien ya cometieron un error de dimensionamiento y quieren un marco para no repetirlo. En ambos casos, la tabla de casos de uso y el marco de cuatro variables le dan lo necesario para tomar una decisión defendible y avanzar.

Consulte los bloques IPv4 disponibles por tamaño y región en IPbnb, o estime el coste de su arrendamiento antes de comprometerse: calculadora de precios de IPv4 →