Arquitectura hub-spoke escalable en la nube: la guía 2026
La arquitectura hub-spoke escalable en la nube resuelve el caos de conectar muchas VPC entre sí: en lugar de unir cada red con todas, conectás todo a un nodo central (el hub) que concentra firewall, DNS y enlaces híbridos. A medida que crece la cantidad de redes, sale más barata y más simple que la malla completa.
Hub-spoke (o “hub-and-spoke”, radial) es un patrón de red donde un único punto central, el hub, concentra los servicios compartidos (firewall, VPN, interconexión híbrida, DNS) y cada carga de trabajo vive aislada en su propia red, el spoke. El tráfico entre spokes pasa siempre por el hub, nunca de forma directa. Lo usan AWS, Azure, Google Cloud y Oracle como topología de referencia para escalar sin perder control.
En 30 segundos
- Una malla de 10 VPC necesita 45 conexiones; 20 VPC saltan a 190. El hub-spoke las baja a una por spoke.
- El hub centraliza firewall, DNS, VPN e interconexión; los spokes solo tienen la aplicación aislada.
- AWS Transit Gateway soporta hasta 5.000 attachments y unos 50 Gbps por VPC, según la documentación de AWS.
- Azure limita a 500 peerings por red virtual; ese número marca tu techo de spokes por hub.
- El error más caro es solapar rangos CIDR: si dos spokes comparten direcciones, el ruteo se rompe.
¿Por qué las redes planas no escalan en la nube?
Ponele que arrancás como casi todos: una VPC por servicio, las conectás entre sí cuando hace falta, y listo. Funciona para la primera docena de cargas. El problema aparece después.
El equipo de CapeStart lo contó sin filtro en un artículo del 4 de junio de 2026: su diseño plano parecía lógico hasta que llegó el momento de sumar conectividad híbrida hacia el datacenter on-premise. Ahí quedaron dos opciones, las dos malas. O armaban una VPN desde cada VPC (carísimo y un dolor de cabeza operativo), o elegían unas pocas VPC “privilegiadas” para rutear todo el tráfico, creando cuellos de botella y puntos únicos de fallo casi sin querer.
La matemática es despiadada. Para conectar todas las redes entre sí necesitás n(n-1)/2 conexiones. Con 10 VPC son 45 peerings. Con 20, ya son 190. ¿Y quién mantiene 190 reglas de ruteo sin equivocarse? Nadie, esa es la respuesta. Cubrimos ese tema en detalle en herramientas de CI/CD empresariales.
Sumá la inconsistencia: cada equipo configura su seguridad a su manera, las políticas no coinciden, y auditar todo eso se vuelve imposible.
¿Cómo funciona la arquitectura hub-spoke?
El modelo tiene dos piezas. El hub es la red central que concentra todo lo compartido. Los spokes son redes aisladas, una por carga de trabajo, que se cuelgan del hub.
La regla de oro: el tráfico entre dos spokes nunca va directo. Siempre pasa por el hub, que lo inspecciona, lo filtra y lo rutea. Eso te da tres cosas que la malla no te da fácil.
- Control centralizado. Toda regla de firewall, todo DNS y toda salida a internet vive en un solo lugar auditable.
- Escalabilidad lineal. Sumás un spoke con una sola conexión al hub, no con N conexiones a todos los demás.
- Consistencia. La política de seguridad se define una vez en el hub y aplica a todos por igual.
Si lo dibujás, es una rueda: el hub en el medio y los radios (spokes) saliendo hacia afuera. De ahí el nombre. Ya lo cubrimos antes en estrategias multi-cloud efectivas.
¿Qué incluye un hub y qué va en los spokes?
La separación de responsabilidades es lo que hace que esto funcione. Si metés cosas de aplicación en el hub, lo convertís en otro monolito.
En el hub va lo transversal:
- Firewall centralizado para inspeccionar tráfico este-oeste y norte-sur.
- VPN e interconexión híbrida (el enlace al datacenter o a otra nube).
- DNS centralizado y resolución de nombres compartida.
- Bastion hosts para acceso administrativo controlado.
- Servicios compartidos y monitoreo centralizado.
En cada spoke va solo lo de esa carga: la aplicación, sus subredes privadas, el NAT gateway si necesita salida, y nada más. Aislado del resto. Si un spoke se compromete, el blast radius queda contenido.
¿Cuáles son los métodos de conectividad entre hub y spokes?
Acá viene una decisión que define tu costo y tu latencia. No hay una opción universal: depende de cuántos spokes tengas y si necesitás híbrido.
| Método | Ancho de banda | Latencia | Costo | Cuándo usarlo |
|---|---|---|---|---|
| VPC Peering | Alto | Muy baja | Bajo | Pocos spokes, sin tránsito transitivo |
| VPN | Hasta ~1.25 Gbps por túnel | Media-alta | Bajo-medio | Conexión segura sobre internet, híbrido |
| Direct Connect / Interconnect | 1 a 100 Gbps | Muy baja | Alto | Híbrido de alto volumen y estable |
| Transit Gateway / Virtual WAN | ~50 Gbps por attachment | Baja | Medio (servicio administrado) | Escala real, muchos spokes |
El peering directo es barato y rápido, pero no es transitivo: spoke A no llega a spoke C pasando por B. Para escalar de verdad necesitás un servicio administrado que haga el ruteo por vos. Complementá con soluciones de automatización modernas.
¿Cómo implementar hub-spoke en AWS con Transit Gateway?
AWS lo recomienda en su Well-Architected Framework como topología preferida frente a la malla de peerings. El componente clave es el Transit Gateway.
Los pasos, en orden:
- Creá la VPC hub con los servicios compartidos (firewall, salida a internet, enlace híbrido).
- Creá las VPC spoke, una por carga, con rangos CIDR que no se pisen.
- Desplegá el Transit Gateway y hacé el attachment de cada VPC.
- Configurá las tablas de ruteo del Transit Gateway para que el tráfico entre spokes pase por el hub.
- Asociá y propagá rutas según qué spoke puede hablar con qué.
Un solo Transit Gateway reemplaza la maraña de peerings directos. Según la documentación de AWS, soporta hasta 5.000 attachments y entrega cerca de 50 Gbps por attachment de VPC. Ese número de 50 Gbps es justo el que mucha gente olvida cuando planea volumen alto.
¿Cómo implementar hub-spoke en Azure con Virtual Network?
Azure tiene su propia guía de referencia en Microsoft Learn, y el enfoque es parecido pero con piezas distintas.
- VNet hub con Azure Firewall y Azure Bastion adentro.
- VNets spoke conectadas por peering bidireccional al hub.
- Rutas definidas por el usuario (UDR) para forzar que el tráfico salga por el firewall del hub.
- Azure Virtual Network Manager para administrar la topología a escala sin configurar peering uno por uno.
El límite que tenés que tener en la cabeza: Azure permite hasta 500 peerings por red virtual. Suena mucho, pero si crecés rápido es tu techo real de spokes por hub. Cuando lo alcanzás, toca pasar a una estrategia multi-hub.
¿Cuáles son los errores más comunes al implementar hub-spoke?
La teoría es linda. Estos son los tropiezos que se ven en producción una y otra vez.
- Solapar rangos CIDR. Si dos spokes comparten direcciones IP, el ruteo no sabe a dónde mandar el paquete. Planificá el espacio de direcciones desde el día cero.
- No darle redundancia al hub. Centralizar todo en un único punto sin alta disponibilidad es crear el punto único de fallo que querías evitar.
- Asumir que el servicio administrado no tiene límites. El Transit Gateway tope cerca de 50 Gbps por attachment. Si pasás eso, hay que repartir la carga.
- DNS y firewall mal centralizados. Si cada spoke resuelve por su cuenta, perdés la consistencia que justificaba todo el diseño.
- Rutas innecesariamente complejas. Tablas de ruteo barrocas que nadie entiende terminan en agujeros de seguridad.
- No planificar el crecimiento. Diseñar para 5 spokes y descubrir a los 6 meses que necesitás 80.
- Forzar hub-spoke donde sobra un peering directo. Si dos cargas hablan mucho entre sí y nada más, a veces un peering directo es más simple y barato.
¿Cuáles son los límites de escalabilidad y costos de una red hub-spoke?
Los límites duros marcan el diseño. Máximo de peerings por red (500 en Azure), ancho de banda por attachment (unos 50 Gbps en AWS) y la cantidad de attachments soportados (hasta 5.000 en Transit Gateway). Cuando uno de esos topes se acerca, la respuesta suele ser una estrategia multi-hub: varios hubs interconectados, uno por región o por dominio de seguridad. Para más detalles técnicos, mirá herramientas de IA para infraestructura.
En costos, el cálculo es claro. La malla te ahorra el costo del servicio administrado, pero te explota en complejidad operativa y conexiones. El hub-spoke suma el overhead del hub (el firewall, el gateway), pero baja drásticamente el número de conexiones. A medida que crece la cantidad de redes, el radial sale más barato que la malla.
Si estás montando esta infraestructura y necesitás hosting o servidores en Argentina con baja latencia regional, podés apoyarte en donweb.com para la capa de alojamiento mientras la nube pública te resuelve la topología de red.
Preguntas Frecuentes
¿Qué es la arquitectura hub-spoke y cuándo conviene usarla?
Es un patrón de red donde un nodo central (hub) concentra los servicios compartidos y cada carga vive aislada en su propio spoke. Conviene cuando la malla de peerings se vuelve inmanejable o cuando necesitás conectividad híbrida centralizada.
¿Cuál es la diferencia entre hub-spoke y malla de VPC?
En la malla cada red se conecta directo con todas las demás, lo que escala como n(n-1)/2 conexiones (45 con 10 VPC, 190 con 20). En el hub-spoke cada red se conecta solo al hub, una conexión por spoke, y el tráfico entre ellos pasa por el centro.
¿Cómo implemento hub-spoke en AWS?
Se hace con AWS Transit Gateway: creás la VPC hub, las VPC spoke con CIDR que no se pisen, hacés el attachment de cada una al Transit Gateway y configurás las tablas de ruteo para que el tráfico pase por el hub. Reemplaza la necesidad de peerings directos uno a uno.
¿Cuáles son los límites de escalabilidad de hub-spoke?
Los topes principales son el ancho de banda por attachment (cerca de 50 Gbps en AWS Transit Gateway), el máximo de peerings por red (500 en Azure) y la cantidad de attachments (hasta 5.000 en Transit Gateway). Al acercarte a esos números, conviene pasar a un esquema multi-hub.
¿Cuánto cuesta implementar una red hub-spoke?
El costo suma el overhead del hub (firewall, gateway administrado y su tráfico procesado), pero reduce el número de conexiones frente a la malla. A medida que crece la cantidad de redes, el hub-spoke resulta más barato que conectar todo entre sí, además de bajar el costo operativo de mantener tantas rutas.
Conclusión
El hub-spoke no es una moda: es la respuesta directa al momento en que tu red plana choca contra la pared de los peerings. Lo que cambió es que hoy los servicios administrados (Transit Gateway en AWS, Virtual WAN y Virtual Network Manager en Azure) te resuelven el ruteo a escala sin que armes la maraña a mano.
Si tenés pocas redes y poca conectividad híbrida, no te compliques: un par de peerings alcanza. Si ya tenés muchas o ves que el datacenter on-premise va a entrar al juego, empezá a diseñar el hub ahora. Planificá los CIDR sin solapamientos, dale redundancia al nodo central y no asumas que el ancho de banda es infinito. Esos tres detalles separan una red que escala de una que se rompe en el peor momento.
