1. Introducción
Cuando hablamos de computación en la nube, muchas veces imaginamos algo abstracto: servidores “en Internet”, aplicaciones que funcionan desde cualquier lugar o archivos que se guardan en servicios como Google Drive, OneDrive o Dropbox.
Sin embargo, la nube no es algo mágico ni invisible. Detrás de cualquier servicio cloud existe una infraestructura física enorme formada por centros de datos, servidores, redes, sistemas de almacenamiento, conexiones de alta velocidad, sistemas eléctricos, refrigeración, seguridad física y herramientas de gestión.
La diferencia principal es que el usuario no necesita ver ni administrar directamente toda esa infraestructura. En lugar de comprar servidores o montar un centro de datos propio, utiliza recursos que el proveedor cloud pone a su disposición a través de Internet.
Proveedores como Amazon Web Services, Microsoft Azure o Google Cloud tienen centros de datos repartidos por todo el mundo. Estos centros están conectados entre sí mediante redes privadas de alta velocidad y permiten desplegar aplicaciones cerca de los usuarios, mejorar la disponibilidad y resistir fallos físicos o cortes en determinadas ubicaciones.
Por ejemplo, cuando una empresa despliega una aplicación en la nube, normalmente no sabe en qué servidor físico exacto se está ejecutando. Lo que elige es una región, una zona de disponibilidad o un conjunto de servicios. El proveedor se encarga de asignar los recursos físicos necesarios.
Dicho de forma sencilla: la infraestructura cloud es como una ciudad tecnológica global. Nosotros no construimos las carreteras, edificios, centrales eléctricas ni redes de comunicaciones; simplemente alquilamos espacios y servicios dentro de esa ciudad.
2. Concepto clave
El concepto clave de este tema es que la nube se organiza en una infraestructura global distribuida.
No existe “un único servidor cloud”. Lo que existe es una red mundial de centros de datos organizada en distintos niveles.
Los tres conceptos más importantes son:
- Regiones
- Zonas de disponibilidad
- Zonas de borde o edge locations
Estos niveles permiten conseguir tres objetivos fundamentales:
- Mejorar la disponibilidad.
- Reducir la latencia.
- Cumplir requisitos legales y de residencia de datos.
Esquema básico de infraestructura global
Proveedor cloud global │ ├── Región: Madrid │ ├── Zona de disponibilidad A │ │ └── Centro de datos / servidores / almacenamiento / red │ ├── Zona de disponibilidad B │ │ └── Centro de datos / servidores / almacenamiento / red │ └── Zona de disponibilidad C │ └── Centro de datos / servidores / almacenamiento / red │ ├── Región: Irlanda │ ├── Zona de disponibilidad A │ ├── Zona de disponibilidad B │ └── Zona de disponibilidad C │ └── Zonas de borde ├── Madrid ├── París ├── Londres └── Frankfurt
Este esquema representa la idea general: el proveedor tiene regiones en distintas partes del mundo, cada región tiene zonas de disponibilidad y, además, existen puntos de borde cercanos a los usuarios para entregar contenido con menor latencia.
Regiones
Una región es una ubicación geográfica donde un proveedor cloud agrupa varios centros de datos.
Por ejemplo:
| Proveedor | Región | Ubicación aproximada |
|---|---|---|
| AWS | eu-south-2 | Madrid |
| AWS | eu-west-1 | Irlanda |
| Google Cloud | europe-southwest1 | Madrid |
| Google Cloud | europe-west4 | Países Bajos |
| Azure | West Europe | Países Bajos |
| Azure | North Europe | Irlanda |
Elegir una región es una decisión importante porque afecta a:
- La latencia.
- El coste.
- La disponibilidad de servicios.
- La legislación aplicable.
- La residencia de los datos.
Por ejemplo, una empresa española que gestione datos personales puede preferir una región europea o española para facilitar el cumplimiento normativo relacionado con el RGPD.
Zonas de disponibilidad
Dentro de una región existen una o varias zonas de disponibilidad, conocidas también como Availability Zones.
Una zona de disponibilidad está formada por uno o varios centros de datos independientes dentro de la misma región. Estas zonas tienen energía, refrigeración y conectividad separadas, pero están conectadas entre sí mediante redes de baja latencia.
La idea es sencilla: si una zona falla, otra puede seguir funcionando.
Por ejemplo, en una región podríamos tener:
Región: Irlanda │ ├── Zona de disponibilidad 1 │ └── Servidores de la aplicación │ ├── Zona de disponibilidad 2 │ └── Servidores de respaldo │ └── Zona de disponibilidad 3 └── Base de datos replicada
Un sistema bien diseñado no debería depender de una única zona. Si todo está en una sola zona y esa zona falla, la aplicación puede quedar fuera de servicio.
En cambio, si la aplicación está distribuida en varias zonas, puede seguir funcionando aunque una de ellas tenga problemas.
Zonas de borde o edge locations
Las zonas de borde son ubicaciones más cercanas a los usuarios finales. No suelen usarse para alojar toda una aplicación completa, sino para entregar contenido de forma rápida.
Normalmente se utilizan con servicios de tipo CDN, como:
- AWS CloudFront.
- Azure Front Door.
- Azure CDN.
- Google Cloud CDN.
Una CDN almacena copias temporales de contenido estático, como imágenes, vídeos, hojas de estilo, archivos JavaScript o documentos.
Por ejemplo, imaginemos que una web está alojada en Irlanda, pero muchos usuarios acceden desde Madrid.
Sin una zona de borde, cada petición tendría que viajar hasta Irlanda.
Con una zona de borde en Madrid, parte del contenido puede servirse desde un punto mucho más cercano.
Esquema de acceso con CDN
Usuario en Madrid │ ▼ Edge Location en Madrid │ ├── Si el contenido está en caché: │ └── Se entrega directamente al usuario │ └── Si el contenido no está en caché: ▼ Región principal Servidor de origen
Este modelo reduce la latencia y mejora la experiencia de usuario.
Si lo explicamos con una analogía cotidiana: no tendría sentido traer una botella de agua desde una fábrica lejana cada vez que alguien tiene sed. Es más eficiente tener puntos de distribución cercanos. La CDN hace algo parecido, pero con archivos digitales.
3. Ejemplo mínimo
Imaginemos que queremos publicar una página web sencilla para una academia.
La web tiene:
- Página de inicio.
- Información de cursos.
- Imágenes.
- Archivos PDF.
- Formulario de contacto.
- Algunos archivos JavaScript y CSS.
Una forma sencilla de desplegar esta web en la nube sería la siguiente:
Usuario │ ▼ CDN / Edge Location │ ▼ Almacenamiento de objetos └── HTML, CSS, JS, imágenes y PDF
En este caso no necesitamos administrar un servidor tradicional. Podemos guardar los archivos estáticos en un servicio de almacenamiento de objetos, como Amazon S3, Azure Blob Storage o Google Cloud Storage, y distribuirlos mediante una CDN.
¿Qué infraestructura cloud interviene?
Aunque parezca una web sencilla, ya aparecen varios elementos importantes:
| Elemento | Función |
|---|---|
| Región | Lugar donde se almacenan los archivos originales |
| Edge location | Punto cercano al usuario para acelerar la entrega |
| Almacenamiento de objetos | Guarda HTML, CSS, JS, imágenes y PDF |
| CDN | Distribuye el contenido de forma rápida |
| DNS | Permite acceder con un dominio legible |
¿Qué gana la academia?
La academia consigue:
- Publicar una web sin comprar servidores.
- Reducir costes de mantenimiento.
- Mejorar la velocidad de carga.
- Servir contenido desde ubicaciones cercanas.
- Escalar si aumenta el número de visitas.
- Evitar administrar infraestructura física.
Este ejemplo es pequeño, pero ya muestra una idea fundamental: en la nube no solo usamos “servidores”, sino una combinación de servicios especializados.
4. Ejemplo completo
Supongamos ahora que una academia llamada AulaNova quiere desplegar una plataforma completa para sus alumnos.
La plataforma tendrá:
- Aplicación web.
- API backend.
- Base de datos.
- Almacenamiento de documentos.
- Sistema de autenticación.
- Monitorización.
- Copias de seguridad.
- Alta disponibilidad.
En este caso, una arquitectura cloud razonable podría ser la siguiente.
Esquema de arquitectura cloud para AulaNova
Usuarios │ ▼ DNS │ ▼ CDN / Edge Locations │ ▼ Balanceador de carga │ ├───────────────┬───────────────┐ ▼ ▼ ▼ Zona A Zona B Zona C Servidor App Servidor App Servidor App │ │ │ └───────┬───────┴───────┬───────┘ ▼ ▼ Base de datos Almacenamiento gestionada de objetos │ ▼ Copias de seguridad
Monitorización + Seguridad + Gestión de costes
Este esquema ya se parece más a una infraestructura profesional.
Vamos a analizarlo por partes.
DNS
El DNS permite que los usuarios accedan mediante un nombre de dominio, por ejemplo: www.aulanova.es
En lugar de recordar una dirección IP, el usuario escribe un dominio y el sistema DNS se encarga de dirigir la petición al servicio correspondiente.
Servicios asociados:
| Proveedor | Servicio DNS |
|---|---|
| AWS | Route 53 |
| Azure | Azure DNS |
| Google Cloud | Cloud DNS |
CDN y zonas de borde
La CDN sirve los contenidos estáticos desde ubicaciones cercanas al usuario.
Por ejemplo:
- Imágenes.
- PDF.
- Archivos CSS.
- JavaScript.
- Vídeos cortos.
- Recursos descargables.
Esto reduce el tiempo de carga y disminuye la carga sobre los servidores principales.
Si muchos alumnos descargan apuntes a la vez, la CDN puede entregar esos archivos sin que todas las peticiones lleguen directamente al backend.
Balanceador de carga
El balanceador reparte las peticiones entre varios servidores.
Si tenemos tres servidores de aplicación, el balanceador decide a cuál enviar cada petición.
Esto permite:
- Repartir carga.
- Evitar saturaciones.
- Detectar servidores caídos.
- Mejorar la disponibilidad.
- Facilitar el escalado horizontal.
Ejemplo:
| Petición | Servidor destino |
|---|---|
| Petición 1 | Servidor A |
| Petición 2 | Servidor B |
| Petición 3 | Servidor C |
| Petición 4 | Servidor A |
El usuario no necesita saber cuántos servidores hay detrás. Para él, todo funciona como una única aplicación.
Zonas de disponibilidad
Los servidores de AulaNova deberían estar repartidos en varias zonas de disponibilidad.
Por ejemplo:
- Zona A → Servidor 1
- Zona B → Servidor 2
- Zona C → Servidor 3
Si falla la Zona A, el balanceador puede dejar de enviar tráfico al Servidor 1 y continuar usando los servidores de las otras zonas.
Esto mejora la tolerancia a fallos.
No evita todos los problemas, pero reduce mucho el riesgo de caída total.
Base de datos gestionada
La base de datos es uno de los componentes más críticos.
En lugar de instalar MySQL o PostgreSQL manualmente en una máquina virtual, AulaNova podría usar una base de datos gestionada.
Servicios habituales:
| Proveedor | Base de datos relacional gestionada |
|---|---|
| AWS | Amazon RDS |
| Azure | Azure Database |
| Google Cloud | Cloud SQL |
Ventajas:
- Copias de seguridad automáticas.
- Actualizaciones gestionadas.
- Monitorización integrada.
- Alta disponibilidad opcional.
- Escalado más sencillo.
- Menos carga administrativa.
La base de datos gestionada no elimina la responsabilidad de diseñar bien los datos, proteger accesos o hacer consultas eficientes. Pero sí reduce mucho el trabajo de administración del servidor.
Almacenamiento de objetos
Los archivos subidos por alumnos y profesores pueden guardarse en almacenamiento de objetos.
Por ejemplo:
- Apuntes PDF.
- Imágenes.
- Entregas de tareas.
- Recursos multimedia.
- Informes generados.
- Copias exportadas.
Servicios habituales:
| Proveedor | Almacenamiento de objetos |
|---|---|
| AWS | Amazon S3 |
| Azure | Blob Storage |
| Google Cloud | Cloud Storage |
Este tipo de almacenamiento está diseñado para ser escalable, duradero y accesible mediante API.
No es lo mismo que un disco duro tradicional. No se organiza como una carpeta local de un ordenador, sino como contenedores o buckets donde se guardan objetos.
Seguridad e identidad
La seguridad es transversal a toda la infraestructura.
AulaNova necesitaría controlar:
- Quién puede acceder a cada recurso.
- Qué permisos tiene cada usuario o servicio.
- Cómo se cifran los datos.
- Qué tráfico está permitido.
- Qué acciones quedan registradas.
- Cómo se protegen las credenciales.
Servicios habituales:
| Necesidad | Ejemplo de servicio |
|---|---|
| Gestión de permisos | IAM |
| Cifrado de claves | KMS |
| Firewall de aplicaciones | WAF |
| Protección frente a ataques | Shield, Defender, Cloud Armor |
| Registro de actividad | CloudTrail, Logging |
Una mala configuración de permisos puede ser más peligrosa que un servidor pequeño. En cloud, dar permisos de más es como entregar las llaves del instituto entero porque alguien necesitaba abrir solo el aula de informática.
Monitorización
Una infraestructura profesional debe poder observarse.
No basta con desplegar la aplicación y confiar en que todo funcione.
Hay que medir:
- Uso de CPU.
- Memoria.
- Tráfico.
- Errores.
- Tiempo de respuesta.
- Estado de servidores.
- Consumo de base de datos.
- Costes.
- Alertas de seguridad.
Servicios habituales:
| Proveedor | Monitorización |
|---|---|
| AWS | CloudWatch |
| Azure | Azure Monitor |
| Google Cloud | Cloud Monitoring / Cloud Logging |
Por ejemplo, se podría crear una alerta si la CPU supera el 80 % durante varios minutos o si el número de errores HTTP 500 aumenta de forma anormal.
Herramientas de desarrollo y despliegue
Además de ejecutar la aplicación, la nube ofrece herramientas para automatizar despliegues.
Por ejemplo:
- Repositorios.
- Pipelines de CI/CD.
- Construcción automática.
- Despliegue continuo.
- Pruebas automatizadas.
- Gestión de versiones.
Servicios habituales:
| Proveedor | Herramientas DevOps |
|---|---|
| AWS | CodePipeline |
| Azure | Azure DevOps |
| Google Cloud | Cloud Build |
Esto permite que el equipo de desarrollo pueda subir cambios de forma controlada, repetible y segura.
Categorías principales de servicios cloud
Los proveedores cloud ofrecen cientos de servicios, pero se pueden agrupar en grandes categorías.
1. Cómputo
El cómputo proporciona capacidad para ejecutar aplicaciones y procesos.
Incluye:
| Tipo | Descripción | Ejemplo |
|---|---|---|
| Máquinas virtuales | Servidores virtualizados configurables | EC2, Azure VM, Compute Engine |
| Contenedores | Ejecución ligera de aplicaciones empaquetadas | ECS, AKS, GKE |
| Serverless | Ejecución bajo demanda sin gestionar servidores | Lambda, Azure Functions, Cloud Functions |
2. Almacenamiento
El almacenamiento permite guardar datos de forma escalable.
Tipos principales:
| Tipo | Uso habitual | Ejemplo |
|---|---|---|
| Objetos | Imágenes, vídeos, documentos, backups | S3, Blob Storage, Cloud Storage |
| Bloques | Discos para máquinas virtuales | EBS, Managed Disks, Persistent Disk |
| Archivos | Sistemas compartidos tipo carpeta de red | EFS, Azure Files, Filestore |
| Archivado | Backups antiguos y datos de baja consulta | Glacier, Archive Storage, Coldline |
3. Redes
Las redes cloud conectan recursos entre sí y con los usuarios.
Incluyen:
- VPC o redes privadas virtuales.
- Subredes.
- Direcciones IP.
- Gateways.
- VPN.
- Balanceadores.
- DNS.
- CDN.
- Peering entre redes.
Una red cloud bien diseñada permite aislar servicios, controlar accesos y mejorar la seguridad.
4. Bases de datos
La nube ofrece bases de datos gestionadas para distintos tipos de necesidad.
| Tipo | Uso | Ejemplo |
|---|---|---|
| Relacionales | Datos estructurados con SQL | RDS, Cloud SQL, Azure Database |
| NoSQL | Datos flexibles o de alta escala | DynamoDB, Cosmos DB, Firestore |
| Analíticas | Grandes volúmenes y consultas complejas | BigQuery, Redshift, Synapse |
5. Seguridad e identidad
Esta categoría permite proteger recursos y controlar permisos.
Incluye:
- Gestión de usuarios.
- Roles.
- Políticas.
- Cifrado.
- Firewalls.
- WAF.
- Gestión de secretos.
- Auditoría.
- Protección frente a ataques.
En cloud, la seguridad no es un producto aislado. Es una capa que debe estar presente en todos los servicios.
6. Monitorización y gestión
Sirve para observar qué ocurre en la infraestructura.
Incluye:
- Métricas.
- Logs.
- Alertas.
- Paneles.
- Trazas.
- Recomendaciones de optimización.
- Informes de costes.
Sin monitorización, una arquitectura cloud funciona “a ciegas”.
7. Inteligencia artificial, Big Data y analítica
Los proveedores cloud también ofrecen servicios avanzados.
Por ejemplo:
- Machine Learning gestionado.
- Reconocimiento de imágenes.
- Traducción.
- Chatbots.
- Análisis de sentimiento.
- Procesamiento masivo de datos.
- Data lakes.
- Data warehouses.
Estos servicios permiten a empresas pequeñas acceder a tecnología avanzada sin tener que construir toda la infraestructura desde cero.
5. Errores frecuentes
Pensar que la nube es solo “un servidor en Internet”
Este es uno de los errores más habituales.
La nube no es simplemente alquilar un servidor remoto. Es una infraestructura global formada por regiones, zonas, redes, servicios gestionados, almacenamiento, seguridad, monitorización y automatización.
Una máquina virtual es solo una pequeña parte del ecosistema cloud.
Elegir una región sin pensar
La elección de región afecta a:
- Latencia.
- Coste.
- Legislación.
- Disponibilidad de servicios.
- Residencia de datos.
No es lo mismo alojar una aplicación para usuarios españoles en una región europea que en una región lejana.
Elegir mal la región puede aumentar la latencia o complicar el cumplimiento normativo.
Desplegar todo en una sola zona de disponibilidad
Si una aplicación crítica se despliega en una única zona, un fallo en esa zona puede dejarla fuera de servicio.
Para aplicaciones importantes, conviene distribuir componentes en varias zonas de disponibilidad.
Esto no siempre es necesario en proyectos pequeños o de prueba, pero sí debe tenerse en cuenta en sistemas reales.
No usar CDN para contenido estático
Si todos los usuarios descargan imágenes, vídeos o documentos directamente desde el servidor principal, la aplicación puede volverse más lenta y cara.
Una CDN ayuda a acercar el contenido a los usuarios y a descargar trabajo del origen.
Confundir almacenamiento de objetos con un disco tradicional
Un bucket de almacenamiento de objetos no es exactamente lo mismo que una carpeta local.
Está pensado para guardar objetos accesibles mediante API, con alta durabilidad y escalabilidad.
No siempre sirve para los mismos usos que un disco de bloque o un sistema de archivos compartido.
Dar demasiados permisos
En cloud, los permisos deben darse siguiendo el principio de mínimo privilegio.
Esto significa que cada usuario o servicio debe tener solo los permisos que necesita.
Dar permisos de administrador “para ir más rápido” puede acabar generando problemas graves de seguridad.
No monitorizar
Una infraestructura sin monitorización puede fallar sin que nadie se entere a tiempo.
La monitorización permite detectar problemas antes de que afecten gravemente al usuario.
Además, también ayuda a optimizar costes y rendimiento.
No entender la responsabilidad compartida
En cloud, el proveedor se encarga de muchas cosas: centros de datos, hardware, red física, disponibilidad de servicios gestionados.
Pero el cliente sigue siendo responsable de otras:
- Configurar permisos.
- Proteger credenciales.
- Diseñar bien la aplicación.
- Cifrar datos cuando corresponda.
- Configurar redes correctamente.
- Revisar logs y alertas.
La nube delega parte del trabajo, pero no elimina la responsabilidad técnica.
6. Buenas prácticas
Elegir la región adecuada
La región debe elegirse teniendo en cuenta:
- Dónde están los usuarios.
- Dónde deben residir los datos.
- Qué servicios están disponibles.
- Qué latencia es aceptable.
- Qué coste tiene cada región.
Para una aplicación dirigida a usuarios españoles, una región en España o en Europa suele tener más sentido que una región lejana.
Diseñar con alta disponibilidad cuando sea necesario
No todas las aplicaciones necesitan una arquitectura compleja, pero las aplicaciones importantes deben evitar puntos únicos de fallo.
Buenas prácticas:
- Usar varias zonas de disponibilidad.
- Usar balanceadores.
- Replicar bases de datos críticas.
- Automatizar copias de seguridad.
- Diseñar mecanismos de recuperación.
- Probar escenarios de fallo.
Alta disponibilidad no significa “nunca se cae”. Significa que el sistema está diseñado para resistir fallos razonables.
Usar CDN para contenido estático
Una CDN es muy recomendable cuando se entregan:
- Imágenes.
- Vídeos.
- Archivos JavaScript.
- CSS.
- Descargas.
- Documentos PDF.
- Recursos públicos.
Ayuda a reducir latencia, mejorar rendimiento y disminuir carga sobre el servidor principal.
Separar recursos por capas
Una arquitectura clara suele separar:
- Capa de presentación.
- Capa de aplicación.
- Capa de datos.
- Capa de almacenamiento.
- Capa de seguridad.
- Capa de monitorización.
Por ejemplo:
Frontend ↓ API Backend ↓ Base de datos ↓ Backups y almacenamiento
Esta separación facilita el mantenimiento, la escalabilidad y la seguridad.
Usar servicios gestionados cuando tenga sentido
No siempre conviene instalar y administrar todo manualmente.
- Una base de datos gestionada puede ahorrar mucho trabajo de mantenimiento.
- Un servicio serverless puede ser ideal para tareas puntuales.
- Un almacenamiento de objetos puede ser mejor que guardar archivos en el disco de una máquina virtual.
La clave es elegir el servicio adecuado para cada necesidad.
Aplicar mínimo privilegio
Cada usuario, servicio o aplicación debe tener solo los permisos imprescindibles.
Por ejemplo:
- Una aplicación que solo lee imágenes no necesita borrar buckets.
- Un alumno no necesita acceso administrativo.
- Un proceso de backup no necesita modificar usuarios.
- Un servicio de monitorización no necesita cambiar la configuración de red.
Menos permisos significa menos riesgo.
Automatizar despliegues
En proyectos profesionales, no debería configurarse todo manualmente desde la consola web.
Es mejor usar:
- Infraestructura como código.
- Pipelines de CI/CD.
- Plantillas reutilizables.
- Scripts de despliegue.
- Control de versiones.
Esto permite repetir entornos, reducir errores y documentar la infraestructura.
Monitorizar desde el primer día
Aunque el proyecto sea pequeño, conviene activar monitorización básica.
Como mínimo:
- Estado de los servicios.
- Uso de CPU y memoria.
- Tráfico.
- Errores.
- Logs.
- Costes.
- Alertas.
La monitorización no es algo que se añade cuando hay problemas. Es lo que permite detectarlos.
Documentar la arquitectura
Un buen proyecto cloud debería tener documentado:
- Región elegida.
- Servicios utilizados.
- Diagrama de arquitectura.
- Flujo de datos.
- Permisos principales.
- Estrategia de backup.
- Medidas de seguridad.
- Estimación de costes.
- Procedimiento de despliegue.
La documentación evita que la arquitectura se convierta en un “misterio sagrado” que solo entiende una persona del equipo.
7. Ejercicio propuesto
Caso práctico: diseño de infraestructura cloud para una plataforma educativa
Un centro de Formación Profesional quiere crear una plataforma llamada FPCloud Aula.
La plataforma permitirá:
- Publicar contenidos para el alumnado.
- Subir y descargar documentos.
- Consultar ejercicios.
- Acceder desde casa.
- Registrar usuarios.
- Guardar datos académicos básicos.
- Recibir muchas visitas durante periodos de entrega.
- Mantener buena disponibilidad.
El centro quiere desplegar la plataforma en la nube y necesita una propuesta inicial de infraestructura.
Tareas
Responde de forma razonada a las siguientes cuestiones:
- Explica qué es una región cloud y qué región elegirías para una plataforma usada principalmente por alumnado de España.
- Explica qué es una zona de disponibilidad y por qué puede ser útil usar más de una.
- Explica qué es una zona de borde o edge location.
- Indica qué ventajas tendría usar una CDN en esta plataforma.
- Propón una arquitectura básica para la aplicación usando al menos: DNS, CDN, balanceador de carga, servidores de aplicación, base de datos, almacenamiento de objetos, monitorización, seguridad/IAM.
- Dibuja un esquema sencillo de la arquitectura propuesta.
- Explica qué tipo de almacenamiento usarías para:
| Tipo de dato | Servicio recomendado |
|---|---|
| Imágenes de la plataforma | Almacenamiento de objetos |
| Documentos PDF | Almacenamiento de objetos |
| Base de datos de usuarios | Base de datos relacional gestionada |
| Logs de la aplicación | Servicio de monitorización / logging |
| Copias de seguridad antiguas | Almacenamiento de archivo |
- Explica qué medidas tomarías para mejorar la alta disponibilidad.
- Explica qué permisos aplicarías siguiendo el principio de mínimo privilegio.
- Indica qué métricas monitorizarías para saber si la plataforma funciona correctamente.
Esquema orientativo que podría entregar el alumnado
Usuarios │ ▼ Dominio del centro │ ▼ CDN │ ▼ Balanceador de carga │ ├───────────────┐ ▼ ▼ Zona A Zona B Servidor App Servidor App │ │ └───────┬───────┘ ▼ Base de datos gestionada │ ▼ Copias de seguridad
Almacenamiento de objetos └── PDF, imágenes, entregas y recursos
Monitorización └── métricas, logs y alertas
IAM / Seguridad └── usuarios, roles, permisos y cifrado
Orientación para la respuesta
Una buena respuesta no debe limitarse a decir “lo pondría en AWS” o “usaría Azure”.
Lo importante es justificar las decisiones:
- Por qué se elige una región cercana.
- Por qué se usan varias zonas.
- Por qué una CDN mejora el rendimiento.
- Por qué los documentos van a almacenamiento de objetos.
- Por qué la base de datos debe estar gestionada.
- Qué elementos ayudan a mejorar la disponibilidad.
- Qué medidas protegen los datos.
- Qué métricas permiten detectar problemas.
El objetivo no es memorizar nombres de servicios, sino entender la lógica de una infraestructura cloud profesional.
Conclusión
La infraestructura en la nube es la base que permite que los servicios cloud funcionen de forma global, escalable y resistente.
Aunque para el usuario todo parezca sencillo —crear una máquina, subir un archivo o desplegar una aplicación—, detrás existe una arquitectura mundial formada por regiones, zonas de disponibilidad, zonas de borde, redes privadas, sistemas de almacenamiento, servicios gestionados y herramientas de seguridad.
Comprender esta infraestructura es fundamental para diseñar soluciones cloud correctamente.
Una buena arquitectura no consiste en usar muchos servicios porque sí. Consiste en elegir bien la región, distribuir los recursos cuando sea necesario, usar almacenamiento adecuado, proteger los accesos, monitorizar el sistema y diseñar pensando en disponibilidad, rendimiento y seguridad.
En definitiva, la nube no es solo “dónde está mi aplicación”. Es el conjunto de decisiones técnicas que permiten que esa aplicación funcione bien, sea segura, escale cuando lo necesita y siga disponible aunque algo falle.