1. Introducción
Crear recursos en la nube es relativamente sencillo. Podemos lanzar una máquina virtual, crear una base de datos, subir archivos a un bucket o configurar una red privada en pocos minutos. Sin embargo, eso no significa necesariamente que hayamos diseñado una buena arquitectura.
Una cosa es configurar servicios y otra muy distinta es diseñar una arquitectura cloud.
Configurar sería, por ejemplo: crear una instancia EC2, crear una base de datos, abrir un puerto, subir archivos a S3, crear una función Lambda.
Diseñar arquitectura es algo más profundo: decidir cuántas instancias hacen falta, en qué zonas de disponibilidad deben estar, cómo se comunican los servicios, qué ocurre si una instancia falla, cómo se protegen los datos, cómo escalar si aumenta el tráfico, cómo se controlan los costes, cómo se monitoriza el sistema y cómo se recupera la aplicación ante un desastre.
La arquitectura en la nube consiste en organizar y relacionar correctamente los distintos servicios cloud para construir un sistema completo. No se trata solo de que funcione hoy, sino de que pueda seguir funcionando mañana cuando tenga más usuarios, más datos, más tráfico, más riesgos y más necesidades.
Una arquitectura mal diseñada puede provocar caídas, pérdida de datos, brechas de seguridad, costes innecesarios o sistemas difíciles de mantener. Una buena arquitectura, en cambio, reduce riesgos antes de que aparezcan.
La arquitectura cloud no consiste en crear más servicios. Consiste en tomar mejores decisiones.
2. Concepto clave
El concepto clave de este tema es que una arquitectura cloud debe diseñarse siguiendo principios de calidad técnica.
No basta con preguntarse “¿Funciona?”. Hay que preguntarse también: ¿Es segura? ¿Resiste fallos? ¿Puede escalar? ¿Es fácil de operar? ¿Tiene costes controlados? ¿Está monitorizada? ¿Se puede recuperar si algo falla? ¿Usa correctamente los servicios administrados? ¿Evita infraestructura innecesaria?
Para responder a estas preguntas, AWS propone el AWS Well-Architected Framework, un marco de buenas prácticas que ayuda a evaluar y mejorar arquitecturas cloud basado en seis pilares.
AWS Well-Architected Framework │ ├── 1. Excelencia operativa │ └── Ejecutar, monitorizar y mejorar sistemas │ ├── 2. Seguridad │ └── Proteger datos, accesos e infraestructura │ ├── 3. Fiabilidad │ └── Recuperarse ante fallos y mantener continuidad │ ├── 4. Eficiencia del rendimiento │ └── Usar recursos adecuados y escalar correctamente │ ├── 5. Optimización de costes │ └── Evitar gasto innecesario │ └── 6. Sostenibilidad └── Reducir impacto ambiental y desperdicio de recursos
| Pilar | Pregunta clave |
|---|---|
| Excelencia operativa | ¿Podemos operar y mejorar el sistema de forma controlada? |
| Seguridad | ¿Estamos protegiendo usuarios, datos y recursos? |
| Fiabilidad | ¿Qué ocurre si algo falla? |
| Eficiencia del rendimiento | ¿Estamos usando los recursos adecuados? |
| Optimización de costes | ¿Estamos pagando solo por lo necesario? |
| Sostenibilidad | ¿Estamos evitando desperdicio de infraestructura y energía? |
Estos pilares no son independientes. Se relacionan entre sí. Por ejemplo, una arquitectura más fiable puede ser más cara. Una arquitectura más barata puede sacrificar disponibilidad. El trabajo del arquitecto cloud consiste en equilibrar estas decisiones.
Arquitectura frente a configuración
| Configuración | Arquitectura |
|---|---|
| Crear recursos | Diseñar el sistema completo |
| Definir parámetros | Analizar riesgos |
| Activar opciones | Definir comunicación entre servicios |
| Poner servicios en marcha | Preparar escalabilidad, mejorar seguridad, controlar costes, diseñar para fallos |
Una mala arquitectura puede estar perfectamente configurada técnicamente y aun así ser un problema. Por ejemplo, una EC2 puede estar bien creada, pero si es la única instancia de producción, no tiene backup y aloja también la base de datos, el diseño es débil.
Los seis pilares del AWS Well-Architected Framework
Pilar 1: Excelencia operativa
Capacidad de ejecutar, supervisar y mejorar sistemas de forma eficiente. No basta con desplegar una aplicación y dejarla funcionando. Hay que poder observarla, mantenerla, actualizarla, corregirla y mejorarla.
Principios:
- Automatizar tareas repetitivas: crear entornos, desplegar aplicaciones, configurar alarmas, crear backups, escalar recursos. La automatización reduce errores humanos.
- Usar infraestructura como código: definir recursos cloud mediante archivos versionados (CloudFormation, Terraform, CDK). La infraestructura queda documentada, los cambios pueden revisarse y se puede repetir el entorno.
- Monitorizar constantemente: medir estado de servicios, uso de CPU, memoria, tráfico, latencia, errores, costes y disponibilidad. En AWS, el servicio habitual es CloudWatch.
- Documentar procesos: arquitectura, despliegue, recuperación, decisiones técnicas, responsables, costes y riesgos.
Pilar 2: Seguridad
La seguridad debe integrarse desde el diseño, no al final como un parche. Protege usuarios, datos, aplicaciones, redes, credenciales, servicios, logs y comunicaciones.
Principios:
- Aplicar mínimo privilegio: cada usuario, servicio o aplicación debe tener solo los permisos necesarios.
- Segmentar redes: separar subredes públicas y privadas, capa de aplicación, capa de datos y accesos administrativos.
- Cifrar datos: en reposo, en tránsito, en backups, en bases de datos, en buckets y en discos (KMS, TLS).
- Detectar amenazas: alertas por acceso sin MFA, cambios en políticas IAM, buckets públicos, aumento inesperado de tráfico (CloudTrail, GuardDuty, WAF, Security Hub).
Seguridad cloud │ ├── Identidad → Usuarios, Roles, MFA, Políticas IAM ├── Red → VPC, Subredes privadas, Security Groups, WAF ├── Datos → Cifrado, Backups, Versionado, Control de acceso └── Auditoría → Logs, Alertas, Revisión periódica
Pilar 3: Fiabilidad
Capacidad de un sistema para seguir funcionando o recuperarse ante fallos. En cloud, una idea esencial: los fallos ocurrirán. La arquitectura debe estar preparada para ellos.
Puede fallar una instancia, una zona de disponibilidad, una base de datos, una red, un despliegue, una actualización o un servicio externo.
Alta disponibilidad: minimizar el tiempo de inactividad mediante múltiples zonas de disponibilidad, balanceadores de carga, Auto Scaling, RDS Multi-AZ, replicación, backups automáticos y monitorización.
Mal diseño: Internet → EC2 única → Base de datos en la misma EC2 (Si falla la EC2, cae todo)
Buen diseño: Internet → Load Balancer → EC2 Zona A + EC2 Zona B → RDS Multi-AZ → Backups (Si una EC2 falla, otra responde; si una AZ falla, la otra sigue)
Diseñar para el fallo: preguntarse qué pasa si una instancia falla, si falla una AZ, si la BD no responde, si el tráfico se duplica, si un despliegue introduce un bug.
RTO y RPO:
- RTO (Recovery Time Objective): ¿cuánto tiempo puedo estar caído?
- RPO (Recovery Point Objective): ¿cuántos datos puedo perder?
Pilar 4: Eficiencia del rendimiento
Utilizar correctamente los recursos para obtener buen rendimiento sin desperdiciar capacidad. No se trata de usar siempre la instancia más grande, sino de elegir recursos adecuados y adaptarlos a la carga real.
Principios:
- Seleccionar recursos adecuados: no todas las cargas necesitan el mismo tipo de cómputo.
- Escalar automáticamente: el autoescalado permite adaptar recursos a la demanda.
- Usar servicios adecuados: Lambda para tareas puntuales, S3+CloudFront para contenido estático, RDS para bases de datos relacionales.
- Probar y optimizar: medir latencia, tiempo de respuesta, rendimiento de consultas, CPU, memoria, errores y capacidad ante picos.
| Necesidad | Servicio posible |
|---|---|
| Aplicación tradicional | EC2 |
| Web administrada | Elastic Beanstalk |
| Tarea puntual por evento | Lambda |
| Microservicios | ECS / EKS |
| Contenido estático | S3 + CloudFront |
| Base relacional | RDS |
| Análisis masivo | Redshift |
Pilar 5: Optimización de costes
En la nube se paga por uso. Una arquitectura mal diseñada puede generar costes innecesarios. La optimización de costes consiste en conseguir los objetivos técnicos gastando lo justo. No significa elegir siempre lo más barato, sino evitar desperdicio.
Errores habituales: instancias sobredimensionadas, recursos encendidos sin uso, bases de datos demasiado grandes, almacenamiento en clases caras, backups duplicados, logs retenidos demasiado tiempo, Multi-AZ activado donde no hace falta.
Buenas prácticas:
- Monitorizar consumo con Cost Explorer.
- Apagar recursos no utilizados (especialmente en desarrollo y pruebas).
- Elegir clases de almacenamiento adecuadas (S3 Standard → IA → Glacier).
- Usar reservas y planes de ahorro para cargas previsibles.
Optimización de costes │ ├── Medir → Cost Explorer / informes ├── Detectar → Recursos infrautilizados ├── Ajustar → Tamaños, clases de almacenamiento, modelos de precio ├── Automatizar → Apagado, escalado, lifecycle └── Revisar → Proceso continuo
Pilar 6: Sostenibilidad
Reducir el impacto ambiental mediante un uso más eficiente de los recursos. En cloud, se relaciona con evitar infraestructura innecesaria, reducir sobredimensionamiento y usar escalado bajo demanda.
Principios:
- Evitar infrautilización: un servidor al 3 % de CPU durante meses es un recurso mal aprovechado.
- Escalar bajo demanda: más recursos solo cuando hacen falta.
- Usar servicios administrados: el proveedor optimiza infraestructura de forma global (RDS, Lambda, S3, CloudFront).
- Eliminar recursos innecesarios: un recurso olvidado consume dinero e infraestructura.
Servicios administrados como principio arquitectónico
| Necesidad | Menos recomendable | Más administrado |
|---|---|---|
| Base de datos relacional | MySQL en EC2 | RDS |
| Archivos estáticos | Disco en EC2 | S3 |
| Tarea puntual | EC2 siempre encendida | Lambda |
| Contenido global | Servidor único | CloudFront |
| Backups históricos | Disco propio | Glacier |
Evaluar una arquitectura
Preguntas clave sobre fiabilidad: ¿Qué ocurre si falla una instancia? ¿Y si falla una AZ? ¿Hay backups? ¿Se han probado las restauraciones? ¿Hay balanceador? ¿La BD tiene alta disponibilidad?
Sobre seguridad: ¿La BD es pública? ¿Hay MFA? ¿Se aplican permisos mínimos? ¿Los datos están cifrados? ¿Los secretos están fuera del código?
Sobre rendimiento: ¿Los recursos están bien dimensionados? ¿Hay autoescalado? ¿Hay CDN? ¿Las consultas son eficientes?
Sobre costes: ¿Hay presupuestos y alertas? ¿Hay recursos sin uso? ¿Se usan clases de almacenamiento adecuadas? ¿Se apagan entornos de pruebas?
Herramientas de apoyo: AWS Well-Architected Tool, AWS Trusted Advisor, CloudWatch, Cost Explorer.
3. Ejemplo mínimo
Imaginemos una academia online que despliega su primera versión así:
Internet → EC2 única ├── Aplicación web ├── Base de datos local └── Archivos subidos
A primera vista funciona, pero arquitectónicamente tiene muchos riesgos.
Excelencia operativa: no hay monitorización clara, despliegue automatizado ni documentación.
Seguridad: la BD está en la misma máquina, puede haber puertos abiertos, no hay separación de red ni cifrado claro.
Fiabilidad: si falla la EC2, cae todo. No hay alta disponibilidad, réplica ni recuperación automatizada.
Rendimiento: una sola instancia soporta toda la carga. No hay escalado. Los archivos se sirven desde la misma máquina.
Costes: puede estar sobredimensionada o siempre encendida sin necesidad. No hay alertas de gasto.
Sostenibilidad: recursos siempre encendidos, no hay escalado bajo demanda, no se usan servicios administrados.
Arquitectura mínima mejorada: Usuarios → CloudFront/CDN → Load Balancer ├── EC2 Zona A └── EC2 Zona B │ ▼ RDS privado │ ▼ Backups automáticos S3 → Materiales, imágenes y documentos CloudWatch → Métricas, logs y alarmas
4. Ejemplo completo
Supongamos que un centro educativo quiere crear AulaArquitectura Cloud con: acceso de alumnos y profesores, publicación de materiales, subida de tareas, base de datos de usuarios y entregas, descarga de documentos, informes básicos y crecimiento progresivo.
Usuarios → DNS → CloudFront/CDN ├── Contenido estático desde S3 ▼ Load Balancer │ ┌─────────┴─────────┐ ▼ ▼ App Zona A App Zona B EC2/ECS EC2/ECS │ │ └─────────┬─────────┘ ▼ RDS Multi-AZ │ ▼ Backups automáticos
S3 → PDF, imágenes, entregas, exportaciones CloudWatch → logs, métricas, alarmas IAM / KMS / Security Groups → seguridad transversal Cost Explorer / Budgets → control de costes
Evaluación por pilares:
| Pilar | Medidas propuestas |
|---|---|
| Excelencia operativa | CloudWatch, logs, documentación, automatización |
| Seguridad | IAM, MFA, cifrado, subred privada, HTTPS, buckets privados |
| Fiabilidad | Multi-AZ, Load Balancer, backups, health checks |
| Rendimiento | CDN, Auto Scaling, recursos adecuados |
| Costes | Budgets, Cost Explorer, clases S3, revisión mensual |
| Sostenibilidad | Escalado bajo demanda, eliminar recursos sin uso, servicios administrados |
5. Errores frecuentes
- Pensar solo en que “funcione”: funcionar es el mínimo. Arquitectura es pensar más allá (crecimiento, fallos, costes, seguridad).
- Usar una única instancia para todo: punto único de fallo, difícil escalado, mala separación de responsabilidades.
- Ignorar la alta disponibilidad: hay que decidir conscientemente qué disponibilidad se necesita.
- No automatizar: configuraciones inconsistentes, errores humanos, dependencia de una persona.
- No monitorizar: sin métricas ni logs, la arquitectura está “ciega”.
- No controlar costes: crear recursos sin presupuestos ni alertas puede generar sorpresas.
- Diseñar sin seguridad: BD pública, buckets públicos, contraseñas en código, sin MFA, sin cifrado.
- Usar demasiados servicios sin necesidad: más piezas aumentan coste, complejidad, mantenimiento y riesgo.
- No documentar decisiones: si nadie sabe por qué se eligió una arquitectura, será difícil mantenerla.
- No revisar la arquitectura con el tiempo: las necesidades cambian; la revisión debe ser periódica.
6. Buenas prácticas
- Diseñar antes de desplegar: dibujar la arquitectura antes de crear recursos.
- Usar los seis pilares como guía: para cada diseño, revisar operación, seguridad, fiabilidad, rendimiento, coste y sostenibilidad.
- Preferir servicios administrados cuando encajen (RDS, S3, Lambda, CloudFront).
- Separar responsabilidades: capa de presentación, aplicación, datos, almacenamiento, seguridad y monitorización.
- Diseñar para fallos: varias AZ, balanceadores, backups, replicación, health checks, Auto Scaling.
- Aplicar seguridad desde el inicio: MFA, IAM mínimo privilegio, cifrado, subredes privadas, logs de auditoría.
- Monitorizar todo lo importante: estado de aplicación, errores, latencia, CPU, memoria, BD, costes, seguridad.
- Controlar costes desde el primer día: presupuestos, alertas, etiquetas, revisión periódica.
- Documentar la arquitectura: diagrama, servicios, justificación, riesgos, costes, seguridad, backups, recuperación.
- Revisar y mejorar continuamente: cuando aumentan usuarios, cambian requisitos, suben costes o hay incidentes.
7. Ejercicio propuesto
Caso práctico: diseño de arquitectura cloud para una academia online
Una academia online quiere desplegar ArquitecturaAula Cloud con: acceso de alumnos y profesores, publicación de materiales, subida de tareas, base de datos de usuarios/cursos/entregas, descarga de PDF e imágenes, posibles picos de tráfico, control de costes, protección de datos personales y disponibilidad razonable.
Tareas (responde de forma razonada):
- Arquitectura frente a configuración: explica la diferencia. Pon dos ejemplos de cada una.
- AWS Well-Architected Framework: explica qué es y enumera sus seis pilares.
- Diseño inicial: propón una arquitectura usando DNS, CDN, balanceador, servicios de aplicación, BD administrada, S3, monitorización, control de costes y seguridad IAM.
- Diagrama de arquitectura: dibuja un esquema similar al del ejemplo completo.
- Pilar de excelencia operativa: medidas para operar correctamente (monitorización, logs, alarmas, documentación, automatización).
- Pilar de seguridad: MFA, IAM mínimo privilegio, RDS en subred privada, cifrado, HTTPS, buckets privados, logs de auditoría.
- Pilar de fiabilidad: varias AZ, Load Balancer, RDS Multi-AZ, backups, health checks, recuperación ante fallos.
- Pilar de eficiencia del rendimiento: CDN, Auto Scaling, instancias adecuadas, separación app/BD, monitorización de latencia.
- Pilar de optimización de costes: Cost Explorer, Budgets, alertas, apagado de entornos de prueba, clases de almacenamiento.
- Pilar de sostenibilidad: escalado bajo demanda, servicios administrados, eliminación de recursos no usados, evitar sobredimensionamiento.
- Comparación mal diseño vs buen diseño: analiza por qué el buen diseño es mejor (balanceador, Multi-AZ, S3, CloudFront, CloudWatch, backups).
- Preguntas de evaluación: responde qué ocurre si falla una instancia, una AZ, si el tráfico se duplica, si alguien accede a la BD desde Internet, si el coste se dispara, si se borra un archivo por error.
- Errores a evitar: indica al menos cinco.
Solución orientativa: ArquitecturaAula Cloud ├── DNS → Dominio de la plataforma ├── CloudFront → Entrega de contenido estático ├── S3 → PDF, imágenes, materiales, entregas ├── Load Balancer → Distribución de tráfico ├── Aplicación → Instancia Zona A + Instancia Zona B ├── RDS Multi-AZ → Usuarios, Cursos, Tareas, Entregas ├── Seguridad → IAM, MFA, Security Groups, Cifrado, HTTPS ├── Monitorización → CloudWatch, Logs, Alarmas └── Costes → Cost Explorer, Budgets, Etiquetas
Conclusión
La arquitectura en la nube consiste en diseñar sistemas completos, no simplemente en crear recursos. Un sistema cloud bien diseñado debe ser seguro, fiable, eficiente, operable, sostenible y económicamente razonable.
El AWS Well-Architected Framework ayuda a estructurar estas decisiones mediante seis pilares: excelencia operativa, seguridad, fiabilidad, eficiencia del rendimiento, optimización de costes y sostenibilidad. Estos pilares permiten revisar una arquitectura desde distintos ángulos y detectar problemas antes de que se conviertan en incidentes reales.
Una buena arquitectura no es la que usa más servicios, sino la que usa los servicios adecuados de la forma correcta. En definitiva, diseñar arquitectura cloud es aprender a pensar antes de desplegar. Porque en la nube, crear recursos es fácil; construir un sistema sólido, seguro y preparado para crecer exige criterio.