Redes nativas en la nube: diseño de VPC, Transit Gateway y Service Mesh en conjunto
En resumen El diseño de VPC con subredes segmentadas es la base de cualquier arquitectura segura en la nube. Transit Gateway conecta cientos de VPC y redes locales (on-premise) mediante un hub …
En resumen
- El diseño de VPC con subredes segmentadas es la base de cualquier arquitectura segura en la nube.
- Transit Gateway conecta cientos de VPC y redes locales (on-premise) mediante un hub central.
- PrivateLink permite acceder a servicios sin exponerlos a Internet.
- Las Network Policies en Kubernetes implementan microsegmentación a nivel de pod.
- Las estrategias multi-cuenta con VPC independientes por entorno aíslan el radio de impacto (blast radius).
El diseño de red en la nube es fundamentalmente distinto al de entornos locales (on-premise). En lugar de switches y routers físicos, se definen redes virtuales mediante código: más flexible, pero también más propenso a errores. Los grupos de seguridad mal configurados, los bloques CIDR demasiado amplios y la falta de segmentación son las causas más frecuentes de incidentes de seguridad en la nube. Quien diseña correctamente su VPC ya ha completado el 80 % del trabajo de seguridad.
Diseño de VPC: sentar bien las bases
Una VPC (Virtual Private Cloud) es una red aislada en la nube. Las decisiones de diseño tomadas durante su creación determinan la seguridad y la flexibilidad durante años. Tres reglas: primero, planificar los bloques CIDR con generosidad: un /16 (65.536 direcciones IP) por VPC y un /24 por subred. Su ampliación posterior está limitada. Segundo, separar subredes públicas y privadas: únicamente los balanceadores de carga y los hosts bastión deben ubicarse en subredes públicas. Tercero, utilizar al menos tres zonas de disponibilidad (Availability Zones) para garantizar alta disponibilidad.
Las estrategias multi-cuenta con AWS Organizations o Azure Management Groups aíslan entornos (producción, staging, desarrollo) en cuentas independientes, cada una con su propia VPC. Una violación de seguridad en el entorno de desarrollo no puede propagarse al entorno de producción.
Transit Gateway: el hub central de red
En entornos empresariales con 50-500+ VPC, la interconexión punto a punto entre redes se vuelve inmanejable. AWS Transit Gateway, Azure Virtual WAN y GCP Network Connectivity Center actúan como hubs centrales: todas las VPC y redes locales (on-premise) se conectan al hub, no entre sí.
Transit Gateway permite: enrutamiento centralizado entre VPC, terminación de VPN para la conexión con entornos locales, emparejamiento entre regiones (inter-region peering) para configuraciones multi-región y tablas de rutas (route tables) para un control granular del tráfico. Su coste es de 0,05 USD por hora más el procesamiento de datos: más económico y sencillo que gestionar cientos de emparejamientos entre VPC en configuraciones extensas.
PrivateLink y puntos de conexión (endpoints) de VPC
De forma predeterminada, las llamadas API a servicios de AWS (S3, DynamoDB, SQS) transitan por Internet público. Los puntos de conexión de VPC (VPC Endpoints) y PrivateLink mantienen el tráfico dentro del backbone de AWS: los puntos de conexión de tipo gateway (gratuitos para S3 y DynamoDB) y los de tipo interfaz (para todos los demás servicios) proporcionan direcciones IP privadas dentro de la VPC.
PrivateLink también permite el acceso privado a servicios de terceros y a sus propios servicios alojados en otras cuentas – sin Internet, sin NAT Gateway y sin dirección IP pública. Para cargas de trabajo críticas desde el punto de vista de cumplimiento normativo (compliance), PrivateLink es obligatorio.
DNS y descubrimiento de servicios en la nube
Route 53 Private Hosted Zones (AWS), Azure Private DNS y GCP Cloud DNS Private Zones permiten la resolución DNS interna dentro de las VPC. Los servicios se direccionan mediante nombres DNS en lugar de direcciones IP – fundamental en entornos dinámicos en la nube, donde las direcciones IP cambian constantemente.
En Kubernetes, CoreDNS asume la función de descubrimiento de servicios: cada servicio recibe automáticamente un nombre DNS (service-name.namespace.svc.cluster.local). External DNS sincroniza automáticamente los servicios de Kubernetes con Route 53 o CloudDNS para su accesibilidad externa.
Seguridad de red: defensa en profundidad
La seguridad de red en la nube sigue un modelo en capas: Security Groups (firewall con estado a nivel de instancia) → Network ACLs (firewall sin estado a nivel de subred) → WAF (capa de aplicación en el balanceador de carga) → Network Policies (comunicación entre pods en Kubernetes) → Service Mesh (mTLS y autorización entre microservicios).
La regla más importante: denegar por defecto (deny by default). Cada Security Group comienza sin reglas entrantes (inbound). Cada Network Policy bloquea todo el tráfico hasta que se definan explícitamente reglas de permiso (allow). Solo debe autorizarse lo estrictamente necesario.
Seguir leyendo en cloudmagazin.com
- Data Mesh en la práctica: arquitectura descentralizada de datos para empresas nativas en la nube
- Identidad nativa en la nube: OAuth 2.1, passkeys y el futuro de la autenticación
- El auge de la IA impulsa el mercado de servicios en la nube – Europa se queda atrás
Más sobre este tema: Más artículos en mybusinessfuture
Preguntas frecuentes
¿Cuántas VPC debería tener una empresa?
Al menos tres: producción, staging y desarrollo – idealmente en cuentas de AWS independientes. Las grandes empresas suelen tener entre 50 y 500+ VPC, organizadas según unidades de negocio, entornos y requisitos de cumplimiento normativo. Más VPC equivalen a una mejor aislación, pero también a una mayor carga de gestión.
¿Cuál es el coste de un NAT Gateway?
AWS NAT Gateway: 0,045 USD/hora (~33 USD/mes) más 0,045 USD/GB de procesamiento de datos. Con un tráfico saliente elevado, este coste puede dispararse. Alternativas: instancias NAT (más económicas, pero gestionadas por el usuario), puntos de conexión de VPC (eliminan la necesidad de NAT para el tráfico hacia servicios de AWS) o IPv6 dual-stack (no requiere NAT).
¿Es necesario Transit Gateway para configuraciones pequeñas?
No. Para 2-5 VPC, basta con el emparejamiento entre VPC (VPC Peering), gratuito y de conexión directa. Transit Gateway resulta rentable a partir de 10+ VPC o cuando se requiere conexión con entornos locales (on-premise) y enrutamiento centralizado.
¿Cómo se segmenta la red en Kubernetes?
Las Network Policies (Calico, Cilium) definen qué pods pueden comunicarse entre sí. La aislación basada en espacios de nombres (namespaces) es el punto de partida: los pods en distintos namespaces solo pueden comunicarse si una Network Policy lo permite explícitamente.
¿Cuál es la diferencia entre Security Groups y Network ACLs?
Los Security Groups son con estado (el tráfico de respuesta se permite automáticamente), operan a nivel de instancia y solo admiten reglas de permiso (allow). Las Network ACLs son sin estado (el tráfico de respuesta debe autorizarse explícitamente), operan a nivel de subred y admiten tanto reglas de permiso (allow) como de denegación (deny). En la práctica, los Security Groups son suficientes para la mayoría de los escenarios.
Fuente de imagen: Pexels / Brett Sayles
