Cuando se diseñan arquitecturas en AWS, uno de los errores más comunes es pensar en la VPC como un componente técnico aislado.
Pero en la práctica, la VPC es:
👉 La base sobre la que se construyen la seguridad, la conectividad y la escalabilidad de todo el sistema.
Y aquí es donde muchos diseños empiezan a romperse…
no el día uno, sino cuando la plataforma crece.
🧭 Antes de hablar de patrones hablemos de el error más común
La mayoría de arquitecturas empiezan así:
✔️ Una sola VPC
✔️ Subnets públicas y privadas
✔️ Un NAT Gateway
✔️ Todo funcionando… al inicio
Pero cuando aparecen múltiples equipos, múltiples entornos (dev, qa, prod), requisitos de seguridad estrictos o conectividad híbrida, esa VPC se convierte en un cuello de botella.
🧩 Entonces… ¿cómo se diseñan VPCs en el mundo real?
No hay una única forma correcta.
Pero sí hay patrones que aparecen constantemente en producción.
Aquí los más relevantes:
🔵 1. Hub-and-Spoke (el más usado en entornos enterprise)
Este patrón separa la conectividad central del resto de workloads.
Cómo funciona:
VPC central (hub): VPN / Direct Connect, NAT Gateways, firewalls e inspección de tráfico.
VPCs spoke: aplicaciones, microservicios, entornos aislados.
Conectadas mediante Transit Gateway (recomendado a escala) o VPC Peering en casos simples.
Cuándo usarlo:
Arquitecturas multi-account, control centralizado de red, requisitos fuertes de seguridad, conectividad híbrida.
Trade-offs reales:
Un Transit Gateway con 10 VPCs adjuntas en us-east-1 tiene un costo base de ~$219/mes solo en attachment fees, antes de procesar un solo byte. En arquitecturas con tráfico este-oeste intenso entre spokes, ese costo puede superar al de los propios workloads. A eso se suma la complejidad operativa de mantener route tables del TGW separadas de las route tables de VPC, y el riesgo de convertir el hub en cuello de botella si el dimensionamiento de tráfico no se hace bien desde el inicio.
Un punto que casi nunca se menciona: si añades inspección centralizada con AWS Network Firewall en el hub, las route tables se vuelven asimétricas. El tráfico entra por una ruta y sale por otra. Ese detalle rompe implementaciones en producción si no se diseña explícitamente desde el principio.
Opinión:
Funciona muy bien, siempre que el crecimiento del tráfico esté bien dimensionado y la inspección de tráfico esté considerada desde el diseño inicial, no como un añadido posterior.
🟣 2. Full Mesh (todo conectado con todo)
Cada VPC se conecta directamente con las demás mediante VPC Peering, sin punto central.
Cuándo usarlo:
Pocas VPCs, baja complejidad, latencia mínima entre servicios.
El problema real:
Escala muy mal. Con N VPCs necesitas N×(N-1)/2 peerings. Con 10 VPCs son 45 conexiones, cada una con sus propias route tables. Con 20 VPCs son 190. A eso se suma que no hay control centralizado, el troubleshooting es lento porque no hay un punto único de observabilidad, y las rutas son difíciles de auditar cuando hay múltiples equipos tocando distintos peerings.
Opinión:
Funciona en startups con 3-4 VPCs. Se rompe en enterprise antes de lo que parece.
🟢 3. Multi-Account (más que un patrón, una estrategia)
Paradójicamente, separar cuentas no ralentiza a los equipos. Les permite moverse más rápido sin interferirse.
Cómo funciona:
Separación por cuentas (producción, desarrollo, seguridad, networking) usando AWS Organizations, Transit Gateway y VPC sharing.
Cuándo usarlo:
Aislamiento real de blast radius, cumplimiento y auditorías, escalabilidad organizacional.
Trade-offs reales:
La complejidad inicial es real. El mayor dolor no es técnico sino de gobierno: ¿quién es dueño de la cuenta de networking? ¿Quién aprueba cambios en las route tables del TGW? Sin esas respuestas claras antes de desplegar, el modelo multi-account genera más fricción de la que resuelve.
Opinión:
A cierta escala no es opcional. Es inevitable.
Hub-and-Spoke y Multi-Account no son excluyentes
Este es el punto que más confusión genera en equipos que están adoptando estos patrones por primera vez.
No son patrones opuestos. Resuelven problemas distintos en capas distintas:
Multi-Account define los límites de confianza, gobierno y blast radius.
Hub-and-Spoke define cómo se conectan esas redes de forma controlada.
En entornos enterprise es muy común — y totalmente correcto — ver una arquitectura multi-account que utiliza una topología hub-and-spoke para la conectividad. Son complementarios.
🔥 Decisiones que realmente importan (y casi nadie menciona).
Más allá del patrón elegido, estas cuatro decisiones determinan si el diseño aguanta el crecimiento:
¿Dónde inspeccionas el tráfico?
Centralizado en el hub o distribuido en cada VPC. Impacta directamente en seguridad, latencia y coste. La inspección centralizada con Network Firewall es más barata operativamente pero introduce la asimetría de rutas mencionada antes.
¿Cómo sales a internet?
NAT por VPC o NAT centralizado en el hub. Aquí es donde muchas facturas explotan. Un NAT Gateway por VPC en una arquitectura con 15 spokes puede costar entre 3x y 5x más que un NAT centralizado, dependiendo del patrón de tráfico.
¿Cómo segmentas?
Por VPC, por subnet o por cuenta. El error más común: mezclar todo porque hoy funciona, sin pensar en cómo se auditará en 12 meses cuando haya un incidente de seguridad.
¿Cómo escalará esto en 6 meses?
Antes de elegir un patrón, responde estas preguntas: ¿Cuántas cuentas tendrás en 12 meses? ¿Tienes o tendrás conectividad híbrida? ¿Quién es el dueño técnico de la red? ¿Cuánto tráfico este-oeste esperas entre workloads? Las respuestas dictan el patrón, no al revés.
⚡ Ejemplo real (simplificado)
En un proyecto de pagos con 3 equipos y 8 cuentas AWS, el punto de quiebre llegó cuando un equipo de desarrollo desplegó un cambio en una route table compartida y tumbó conectividad en producción durante 40 minutos. No fue un problema técnico. Fue un problema de gobierno.
La solución no fue técnica tampoco: fue separar la cuenta de networking, transferir la propiedad de las route tables del TGW a un equipo dedicado, e implementar aprobación obligatoria para cualquier cambio de red mediante pipelines de IaC con revisión. Después de eso, cero incidentes de red por cambios no coordinados en 8 meses.
Esa evolución se ve constantemente:
Inicio: 1 VPC, todo dentro, funciona
Crecimiento: más servicios, problemas de seguridad y control
Evolución: multi-account + hub-and-spoke + networking centralizado
Resultado: mejor control, más seguridad, más complejidad — inevitable y manejable si se diseña bien
Un punto importante de aclarar es que Hub‑and‑Spoke y Multi‑Account no son patrones opuestos.
En arquitecturas reales, resuelven problemas distintos en capas distintas:
- **Multi‑Account **define los límites de confianza, gobierno y blast radius.
- Hub‑and‑Spoke define cómo se conectan esas redes de forma controlada.
Por eso, en entornos enterprise es muy común —y totalmente correcto— ver:
👉 Una arquitectura multi‑account que utiliza una topología Hub‑and‑Spoke para la conectividad.
🧭 Conclusión
Diseñar una VPC no es crear subnets.
Es decidir cómo se comunican los sistemas, cómo se aíslan, cómo escalan y cuánto cuesta operarlos. Y sobre todo, cómo evitar que tu arquitectura funcione hoy pero falle mañana.
El patrón correcto no existe en abstracto. Existe en función de cuántos equipos tienes, qué nivel de aislamiento necesitas y cuánto tráfico moverás. Empieza por esas preguntas, no por el diagrama.
Happy learning on AWS 🚀
Top comments (1)
Thanks for clarifying🎯
Hub-and-Spoke plus Multi-Account being complementary instead of either/or is a helpful distinction. They solve different problems at different layers.