1. Introducción
En cloud, las redes son la base de todo: sin red no hay comunicación entre usuarios, aplicaciones, APIs, bases de datos, almacenamiento, DNS, logs ni entrega de contenidos.
La diferencia frente a entornos tradicionales es que la red se define por software: podemos crear, dividir, aislar y proteger una arquitectura completa sin tocar un solo cable físico.
Esto da flexibilidad, pero también riesgo. Una red mal diseñada puede:
- exponer bases de datos a Internet,
- romper comunicaciones internas,
- aumentar superficie de ataque,
- y bloquear escalabilidad futura.
En cloud, una mala red puede romper una buena aplicación.
2. Concepto clave
El concepto central es que la red cloud es virtual, aislada y definida por software.
Cada proyecto vive en una red privada virtual:
- AWS: VPC
- Azure: Virtual Network
- Google Cloud: VPC Network
Dentro de esa red definimos:
- CIDR
- subredes públicas/privadas
- tablas de rutas
- gateways
- firewalls (Security Groups / NACL)
- DNS
- CDN
Conceptos básicos de red
Dirección IP
Identifica recursos dentro de una red.
- IP pública: accesible desde Internet
- IP privada: accesible solo dentro de la red privada
CIDR
Define rangos de red.
| CIDR | Tamaño aprox. | Uso típico |
|---|---|---|
10.0.0.0/16 | ~65.536 IP | VPC principal |
10.0.1.0/24 | ~256 IP | subred concreta |
Elegir bien CIDR es clave para crecer sin bloquear arquitectura.
Subred
División lógica de una red mayor.
Ejemplo en 10.0.0.0/16:
10.0.1.0/24→ pública10.0.2.0/24→ privada app10.0.3.0/24→ privada datos
Gateway y tablas de rutas
Una subred es pública si tiene ruta a Internet (normalmente 0.0.0.0/0 hacia Internet Gateway).
Subred pública ├── Ruta local: 10.0.0.0/16 └── Ruta Internet: 0.0.0.0/0 -> Internet Gateway
Subred privada └── Ruta local: 10.0.0.0/16
Esquema conceptual de red cloud
VPC: 10.0.0.0/16 │ ├── Subred pública: 10.0.1.0/24 │ ├── Balanceador de carga │ └── Servidor web │ ├── Subred privada: 10.0.2.0/24 │ └── Servidor de aplicación │ └── Subred privada: 10.0.3.0/24 └── Base de datos
3. Ejemplo mínimo
Diseño inseguro
Internet │ ▼ Servidor público ├── Web ├── Backend └── Base de datos
Problemas: sin separación de capas, exposición excesiva, poca resiliencia.
Diseño mejorado
Internet │ ▼ Balanceador / frontal web (subred pública) │ ▼ Backend/API (subred privada) │ ▼ Base de datos (subred privada)
Flujo correcto: Usuario -> Web pública -> Backend -> BBDD privada.
4. Ejemplo completo
Caso: plataforma AulaNet Cloud con web pública, API, BBDD privada, dominio propio, recursos estáticos y acceso desde diferentes ubicaciones.
Arquitectura objetivo
Usuarios │ ▼ DNS │ ▼ CDN / Edge Locations │ ├── Contenido estático (CSS, JS, imágenes, PDF) │ ▼ Balanceador de carga │ ▼ VPC: 10.0.0.0/16 │ ├── Subred pública: 10.0.1.0/24 (web/API) │ └── Subred privada: 10.0.2.0/24 (base de datos)
Diseño por capas
- Capa pública: balanceador/frontal
- Capa app: backend/API
- Capa datos: BBDD privada
- Capa contenidos: CDN + almacenamiento de objetos
Security Groups y NACL
| Elemento | Nivel | Uso |
|---|---|---|
| Security Group | recurso | reglas finas por servicio |
| Network ACL | subred | reglas generales por segmento |
Ejemplo SG:
SG-Web Inbound: 80/443 desde Internet
SG-DB Inbound: 3306 solo desde SG-App/SG-Web Nunca desde 0.0.0.0/0
DNS en cloud
El DNS traduce nombres (p. ej. www.aulanet.es) a destinos técnicos.
Servicios típicos:
- AWS Route 53
- Azure DNS
- Cloud DNS
Además puede apoyar HA: geolocalización, latencia, failover, weighted routing.
CDN y entrega de contenidos
Una CDN entrega recursos desde edge locations cercanas al usuario, reduciendo latencia y carga en origen.
Útil para:
- imágenes
- CSS/JS
- archivos descargables
Usuario │ ▼ Edge location ├── cache hit -> entrega inmediata └── cache miss -> origen (S3/Blob/Cloud Storage o LB)
5. Errores frecuentes
- Diseñar servidores antes que la red.
- CIDR mal planificado.
- BBDD en subred pública.
- Abrir puertos “por si acaso”.
- Mezclar todo en una sola subred.
- Confundir “subred pública” con “recurso público”.
- Autorizar por IP fija en lugar de referencias lógicas (SG).
- No usar CDN para estáticos.
- DNS mal configurado.
- No documentar red y rutas.
6. Buenas prácticas
- Diseñar red antes de desplegar recursos.
- Separar subred pública y privadas por capas.
- Aplicar mínimo privilegio también a nivel de red.
- Nunca exponer BBDD a Internet.
- Usar balanceadores para entrada de tráfico.
- Gestionar DNS con TTL y cambios controlados.
- Usar CDN para estáticos.
- Diseñar para escalabilidad (CIDR, AZ, entornos, naming).
- Defensa en profundidad (rutas + SG + cifrado + monitorización).
- Revisar reglas temporalmente abiertas y cerrarlas.
7. Ejercicio propuesto
Caso: plataforma EduRed Cloud.
Tareas
- Proponer CIDR de VPC y justificar tamaño.
- Diseñar subred pública/app privada/datos privada.
- Explicar diferencia subred pública vs privada.
- Explicar Internet Gateway y qué subred lo usa.
- Definir tablas de rutas pública/privada.
- Proponer Security Groups para web y BBDD.
- Diseñar DNS para
www.eduredcloud.es. - Definir recursos servidos por CDN y ventajas.
- Dibujar esquema de arquitectura.
- Listar al menos 5 errores a evitar.
Solución orientativa
VPC: 10.0.0.0/16 │ ├── Pública 10.0.1.0/24 -> Balanceador (ruta a Internet) ├── Privada app 10.0.2.0/24 -> Backend/API └── Privada datos 10.0.3.0/24 -> BBDD
Flujo: Usuario -> DNS -> CDN -> Balanceador -> Backend -> BBDD privada
Conclusión
La red es el sistema circulatorio de una arquitectura cloud. Si está bien diseñada, el sistema es seguro, escalable y eficiente. Si está mal diseñada, los problemas aparecen pronto.
En cloud no basta con “que funcione”: debe comunicarse de forma controlada, segura y performante.