Topología de red hub-and-spoke: diagramas de Azure y AWS

La primera red en la nube es fácil. Para la décima hay una maraña de conexiones de peering, tres túneles VPN a la oficina configurados cada uno de forma un poco distinta, un firewall copiado en cada red y nadie puede decir con seguridad qué llega a qué. Hub-and-spoke es la salida estándar: una red central para la conectividad compartida y la inspección, y las cargas de trabajo en spokes aislados que solo se conectan a través de ella.

Este artículo explica la topología y luego la construye dos veces, con diagramas: en Azure con una red virtual hub y peering, y en AWS con Transit Gateway. Cubre el enrutamiento y la segmentación, la inspección del tráfico, la salida centralizada, los costes que sorprenden a los equipos y cuándo es mejor opción un hub gestionado.

Por qué una malla deja de funcionar

Conectar cada red directamente con todas las demás requiere n(n−1)/2 conexiones. Diez redes necesitan 45; cincuenta necesitan 1225, cada una con sus propias rutas y reglas de seguridad. Además, el peering no es transitivo en ninguna de las dos nubes: si A está emparejada con B y B con C, A sigue sin poder llegar a C a través de B. Un diseño hub-and-spoke necesita una conexión por spoke, y el hub se convierte en el único lugar donde viven el enrutamiento y la política de seguridad.

Qué va en el hub

Las cargas de trabajo no van en el hub. Los spokes alojan las aplicaciones, normalmente uno por aplicación, equipo o entorno, para que un error en uno no se extienda a los demás.

Hub-and-spoke en Azure

La arquitectura de referencia hub-spoke de Microsoft coloca Azure Firewall, una puerta de enlace VPN o ExpressRoute y Azure Bastion en una red virtual hub, cada uno en su propia subred dedicada. Azure Firewall necesita una subred de al menos /26. Los spokes se conectan al hub con peering de redes virtuales, que Microsoft describe como no transitivo: las redes emparejadas hablan entre sí, no a través de las otras.

Eso tiene dos consecuencias:

• El uso compartido de la puerta de enlace es explícito. El peering del hub permite el tránsito por puerta de enlace y cada spoke usa la puerta de enlace remota, de modo que los spokes llegan a la red local a través de la puerta de enlace del hub.
• El tráfico entre spokes necesita rutas. Las rutas definidas por el usuario en cada spoke envían el tráfico destinado a otros spokes, y normalmente la ruta por defecto, a la IP privada del firewall. El firewall reenvía lo que permite la política. Como alternativa, Azure Virtual Network Manager puede gestionar peerings y grupos conectados a escala, y el peering directo entre dos spokes sigue siendo una opción para casos especiales.

Para un hub gestionado por Microsoft, Azure Virtual WAN ofrece hubs con enrutamiento integrado, puertas de enlace y firewalls opcionales, a cambio de menos control sobre los detalles.

Hub-and-spoke en AWS

En AWS, el hub suele ser un Transit Gateway, un router regional al que se conectan VPC, conexiones VPN y puertas de enlace de Direct Connect:

• Los spokes son adjuntos de VPC. Un Transit Gateway admite 5000 adjuntos por defecto, según las cuotas de Transit Gateway, así que escala mucho más allá de las mallas de peering.
• La segmentación sale de las tablas de rutas del Transit Gateway. Los adjuntos de producción se asocian a una tabla de rutas y los de desarrollo a otra, así que nunca aprenden las rutas del otro, aunque ambos pueden llegar a una VPC de servicios compartidos.
• La inspección ocurre en una VPC de inspección dedicada que ejecuta AWS Network Firewall o appliances de terceros detrás de un Gateway Load Balancer. Las tablas de rutas de los spokes apuntan al Transit Gateway, y las rutas del Transit Gateway envían el tráfico a través de la VPC de inspección.
• El modo appliance, en el adjunto de la VPC de inspección, mantiene los dos sentidos de un flujo en la misma zona de disponibilidad, algo que exigen los firewalls con estado.
• Salida centralizada: una VPC de salida con puertas de enlace NAT sirve a todos los spokes, en lugar de tener puertas de enlace NAT en cada VPC.

Para redes globales que abarcan muchas regiones, AWS Cloud WAN cumple el papel que Virtual WAN cumple en Azure: una red troncal gestionada con segmentos basados en políticas.

Las dos nubes lado a lado

Enrutamiento, segmentación y simetría

Tres reglas mantienen predecible una red hub-and-spoke:

1. Las rutas por defecto apuntan al hub. Los spokes envían al hub todo lo que no es local, para que nada se salte la inspección por accidente.
2. Los segmentos son explícitos. Decide qué spokes pueden hablar con cuáles: producción y desarrollo normalmente no, los servicios compartidos suelen ser accesibles desde todas partes y el acceso a la red local pasa por el firewall.
3. El tráfico de vuelta debe tomar el mismo camino. Un firewall con estado descarta las respuestas cuya ida no vio. Las rutas asimétricas son la causa más común de «la regla del firewall está ahí, pero nada funciona».

Escribe el plan de direcciones antes de que exista el primer spoke. Los rangos CIDR solapados entre spokes, o con la red local, no se pueden enrutar a través de un hub y son difíciles de corregir después.

Lo que cuesta

Cada byte que cruza el hub se factura en algún sitio. En AWS, en el momento de escribir esto (noviembre de 2026), los precios de Transit Gateway en US East (N. Virginia) son 0,05 USD por adjunto y hora y 0,02 USD por GB de datos procesados. Diez adjuntos de spokes cuestan unos 10 × 0,05 USD × 730 horas, aproximadamente 365 USD al mes, antes de cualquier tráfico. Diez TB de tráfico entre spokes añaden unos 10 240 GB × 0,02 USD, aproximadamente 205 USD de procesamiento, más los cargos de procesamiento del propio firewall. En Azure, el tráfico emparejado se cobra por GB en ambos extremos del peering, y Azure Firewall añade su propio cargo de procesamiento.

La optimización habitual es puntual: mantén el hub para la política y añade peering directo para un par concreto de spokes que intercambian volúmenes muy grandes y no necesitan inspección.

Cuándo no usar hub-and-spoke

• Dos o tres redes no necesitan un hub; el peering directo es más sencillo.
• El tráfico este-oeste sensible a la latencia paga un salto extra y un firewall en cada paquete. Mide antes de enviar un par de servicios muy conversadores por la inspección.
• Volúmenes internos enormes pueden convertir el procesamiento por GB en el mayor coste de red. Para esos flujos, el peering directo suele estar justificado.
• Las infraestructuras muy grandes y multirregión pueden estar mejor servidas por un hub gestionado, Virtual WAN o Cloud WAN, que por tablas de rutas hechas a mano.

El diagrama hub-and-spoke

Cómo leerlo:

• La red local, arriba, se conecta una vez con cada nube: con la puerta de enlace del hub de Azure y con el Transit Gateway de AWS.
• El marco de Azure muestra la red virtual hub con su firewall y su puerta de enlace VPN, y dos spokes emparejados con ella. El tráfico entre spokes pasa por el firewall.
• El marco de AWS muestra el Transit Gateway en el centro, la VPC de inspección con su firewall y dos VPC spoke conectadas.
• Las etiquetas de las aristas indican el tipo de conexión: peering, adjunto, VPN o circuito privado.
• El bloque Markdown enumera las reglas de enrutamiento y las cifras de coste de arriba.

Dibujar topologías de red que superen la revisión

• Escribe el rango CIDR en cada red. Los solapamientos son lo primero que mira un revisor.
• Dibuja el firewall donde el tráfico pasa de verdad, y muestra la ruta por defecto que apunta a él.
• Etiqueta cada conexión con su tipo. Peering, adjunto y VPN se comportan distinto y cuestan distinto.
• Usa un diagrama por región. Las redes multirregión dibujadas en un solo lienzo suelen esconder los enlaces entre regiones que importan.

Para el interior de una sola red, consulta el diagrama de VPC de AWS. El diagrama de topología de red cubre las topologías físicas y lógicas en general, y el diagrama de arquitectura zero trust explica por qué la posición en la red no debería dar acceso por sí sola. Los diseños multirregión se tratan en el diagrama de arquitectura multirregión de AWS.

Constrúyelo en Archboard

1. Inicia sesión con Google o GitHub y crea un diagrama.
2. Añade arriba una Caja del pack Básico para la red local.
3. Añade un Marco del pack Básico para Azure. Dentro, añade un nodo VPC del pack Red para la red virtual hub, con un Cortafuegos y un nodo Dispositivo para la puerta de enlace VPN en su interior, y dos nodos VPC más para los spokes, cada uno con su CIDR.
4. Añade un Marco del pack Básico para AWS. Dentro, añade un Enrutador del pack Red para el Transit Gateway, un nodo VPC para la VPC de inspección con un Cortafuegos dentro y dos nodos VPC para los spokes.
5. Conecta la red local con la puerta de enlace de Azure y con el Transit Gateway, los spokes con sus hubs, y etiqueta cada arista con su tipo de conexión.
6. Añade un bloque Markdown del pack Básico con las reglas de enrutamiento y los costes.

El ejemplo usa 14 nodos de diagrama, dentro del plan Free.

Preguntas frecuentes

¿Qué es una topología de red hub-and-spoke? Un diseño en el que una red central, el hub, aloja la conectividad, la seguridad y los servicios compartidos, y cada red de cargas de trabajo, un spoke, se conecta solo al hub. El tráfico entre spokes y hacia la red local pasa por el hub.

¿El peering de redes virtuales es transitivo? No, ni en Azure ni en AWS. Dos spokes emparejados con el mismo hub no pueden llegar el uno al otro a través de él, salvo que las rutas envíen su tráfico a un firewall o a un router del hub.

¿Qué diferencia hay entre Transit Gateway y el peering de VPC? El peering de VPC conecta dos VPC directamente y no es transitivo. Transit Gateway es un router regional al que se conectan muchas VPC y conexiones locales, con tablas de rutas para la segmentación.

¿Debería usar Azure Virtual WAN en lugar de una red virtual hub? Virtual WAN encaja en infraestructuras grandes o multirregión que quieren que Microsoft gestione el enrutamiento del hub y las puertas de enlace. Un hub autogestionado da más control y es habitual para unos pocos spokes en una o dos regiones.

¿Cuánto cuesta hub-and-spoke? Las conexiones al hub y el tráfico procesado se facturan por hora y por GB, más el procesamiento del firewall. En AWS, en el momento de escribir esto, un adjunto de Transit Gateway cuesta 0,05 USD por hora y el procesamiento de datos 0,02 USD por GB en US East.

Empieza gratis — un puesto, sin tarjeta de crédito.