1. Introducción
Una de las grandes ventajas de la computación en la nube es la posibilidad de adaptar los recursos a la demanda real de una aplicación.
En un entorno tradicional, si una empresa esperaba recibir muchos usuarios, tenía que comprar servidores con capacidad suficiente para soportar los momentos de mayor carga. El problema es que esos servidores podían estar infrautilizados durante muchas horas, días o incluso meses.
Por ejemplo, una tienda online puede tener muchísimo tráfico durante una campaña especial, pero mucho menos durante una madrugada normal. Un aula virtual puede recibir muchas conexiones antes de una entrega o examen, pero muy pocas durante el fin de semana.
Si se dimensiona la infraestructura para el peor caso, se pagan recursos que muchas veces no se usan. Si se dimensiona para el uso medio, la aplicación puede colapsar en los picos.
La nube ofrece una solución a este problema mediante la elasticidad.
Una arquitectura elástica es capaz de crecer cuando aumenta la demanda y reducir recursos cuando la carga baja. Para que esto funcione hacen falta tres piezas fundamentales:
- Balanceo de carga — para repartir el tráfico.
- Monitorización — para medir qué está ocurriendo.
- Autoescalado — para ajustar recursos automáticamente.
La idea principal: la infraestructura no debería ser estática si la demanda no lo es.
2. Concepto clave
El concepto clave de este tema es la elasticidad. Una arquitectura elástica es aquella que puede adaptarse automáticamente a los cambios de demanda: añadir recursos cuando aumenta la carga, eliminarlos cuando baja, mantener un rendimiento estable, evitar pagar por recursos innecesarios y reducir la intervención manual.
Escalabilidad frente a elasticidad
| Concepto | Significado | Ejemplo |
|---|---|---|
| Escalabilidad | Capacidad de aumentar recursos | Añadir más servidores |
| Elasticidad | Capacidad de aumentar y reducir recursos automáticamente | Añadir servidores en hora punta y quitarlos por la noche |
Demanda baja → 2 instancias activas Demanda alta → 6 instancias activas Demanda vuelve a bajar → 2 instancias activas
Arquitectura elástica: piezas principales
Arquitectura elástica │ ├── Balanceador de carga │ └── Reparte tráfico entre instancias │ ├── Monitorización │ └── Mide CPU, tráfico, latencia, errores │ └── Autoescalado └── Añade o elimina instancias según reglas
En AWS:
| Necesidad | Servicio AWS |
|---|---|
| Balanceo de carga | Elastic Load Balancing (ELB) |
| Monitorización | Amazon CloudWatch |
| Autoescalado | Amazon Auto Scaling |
| Servidores virtuales | Amazon EC2 |
Balanceo de carga
El balanceo de carga distribuye el tráfico entrante entre varios servidores, permitiendo mejorar el rendimiento, evitar sobrecarga, aumentar disponibilidad, retirar instancias con problemas y facilitar el escalado horizontal.
Sin balanceador: Usuarios → EC2 única (punto único de fallo)
Con balanceador: Usuarios → Load Balancer → EC2 A, EC2 B, EC2 C
Elastic Load Balancing: en AWS, los tipos principales son:
- Application Load Balancer (ALB): para aplicaciones web HTTP/HTTPS, APIs REST, microservicios.
- Network Load Balancer (NLB): para tráfico TCP/UDP de alto rendimiento y baja latencia.
Health checks: comprobaciones periódicas para saber si una instancia está sana. Si una instancia deja de responder, el balanceador la marca como no saludable y deja de enviarle tráfico.
Load Balancer ├── EC2 A: saludable → recibe tráfico ├── EC2 B: saludable → recibe tráfico └── EC2 C: no saludable → no recibe tráfico
Monitorización
“No se puede mejorar lo que no se mide.” La monitorización permite detectar problemas, analizar rendimiento, activar alertas, ejecutar acciones automáticas y entender el comportamiento real del sistema.
Amazon CloudWatch recoge métricas, logs y alarmas de servicios como EC2, Load Balancers, Auto Scaling Groups, RDS, Lambda, entre otros.
| Métrica EC2 | Qué indica |
|---|---|
| CPU Utilization | Porcentaje de uso de CPU |
| Network In/Out | Tráfico de entrada/salida |
| Disk Read/Write | Lecturas/escrituras de disco |
| Status Check | Estado básico de la instancia |
| Métrica ALB | Qué indica |
|---|---|
| Request Count | Número de peticiones |
| Target Response Time | Tiempo de respuesta |
| HTTP 4xx/5xx | Errores de cliente/servidor |
| Healthy/Unhealthy Host Count | Instancias saludables |
Alarmas en CloudWatch: permiten reaccionar cuando una métrica supera un umbral. Por ejemplo: “Si CPU media > 70 % durante 5 minutos → enviar alerta y activar escalado”.
Servicios cloud → CloudWatch → Métricas, Logs, Dashboards, Alarmas
Autoescalado
El autoescalado permite añadir o eliminar recursos automáticamente según la demanda. En AWS se utiliza Amazon Auto Scaling con Auto Scaling Groups.
Componentes:
- Launch Template: configuración base de las instancias (AMI, tipo, Security Group, scripts de arranque).
- Auto Scaling Group: gestiona el conjunto de instancias (mínimo, deseado, máximo, subredes, balanceador).
- Políticas de escalado: reglas para crecer o reducir.
- Métricas de CloudWatch: datos usados para tomar decisiones.
Ejemplo de configuración:
- Mínimo: 2 instancias (nunca menos)
- Deseado: 2 instancias (estado normal)
- Máximo: 8 instancias (control de costes)
Políticas de escalado:
- Escalado hacia fuera: “Si CPU media > 75 % durante 5 minutos → añadir 2 instancias”.
- Escalado hacia dentro: “Si CPU media < 30 % durante 10 minutos → eliminar 1 instancia”.
La clave está en definir umbrales razonables. Si escalamos demasiado rápido, generamos costes innecesarios; si escalamos demasiado tarde, los usuarios sufren lentitud.
Escalado horizontal frente a vertical
| Aspecto | Escalado vertical | Escalado horizontal |
|---|---|---|
| Acción | Hacer más grande una máquina | Añadir más máquinas |
| Ventajas | Sencillo de entender | Mejora disponibilidad, reparte carga |
| Inconvenientes | Tiene límite, punto único de fallo | La app debe estar preparada |
| En cloud | Menos recomendado para elasticidad | Priorizado en arquitecturas cloud |
Integración completa
Usuarios → Application Load Balancer │ ┌─────────┼─────────┐ ▼ ▼ ▼ EC2 A EC2 B EC2 C │ │ │ └─────────┴─────────┘ Auto Scaling Group
CloudWatch → mide CPU, peticiones, latencia → activa alarmas Auto Scaling → añade instancias si sube la carga, elimina si baja
Flujo completo:
- Los usuarios acceden a la aplicación.
- El ALB recibe el tráfico y lo reparte entre instancias sanas.
- CloudWatch mide CPU, tráfico y latencia.
- Si se supera un umbral, se activa una alarma.
- Auto Scaling crea nuevas instancias.
- El ALB empieza a enviar tráfico también a las nuevas instancias.
- Cuando baja la carga, Auto Scaling elimina instancias sobrantes.
3. Ejemplo mínimo
Aplicación web en una única instancia EC2:
Usuarios → EC2 única
Problemas: si aumenta el tráfico se satura, si falla la instancia cae todo, no hay reparto de carga, no hay elasticidad, se paga por la instancia aunque esté infrautilizada.
Mejora mínima:
Usuarios → Application Load Balancer → EC2 A + EC2 B CloudWatch monitoriza Auto Scaling ajusta número de EC2
Ahora, si la CPU sube demasiado, el sistema puede añadir instancias. Si una instancia falla, el balanceador deja de enviarle tráfico. Si la carga baja, se eliminan instancias.
4. Ejemplo completo
Un centro educativo quiere desplegar ElasticAula Cloud con: acceso de alumnado y profesorado, publicación de materiales, entrega de tareas, descarga de documentos, picos de tráfico antes de entregas, periodos de baja actividad por la noche, control de costes y buena disponibilidad.
Usuarios → DNS → CloudFront/CDN ├── S3 para contenidos estáticos ▼ Application Load Balancer │ ▼ Auto Scaling Group │ ┌────────┴────────┐ ▼ ▼ EC2 Zona A EC2 Zona B │ │ └────────┬─────────┘ ▼ RDS privado
CloudWatch → CPU, latencia, peticiones, errores, alarmas Auto Scaling → escala hacia fuera si sube la carga, hacia dentro si baja
Políticas de escalado propuestas:
- Hacia fuera: CPU media del ASG > 70 % durante 5 min → añadir 2 instancias.
- Hacia dentro: CPU media < 30 % durante 15 min → eliminar 1 instancia.
Flujo durante un pico de entrega:
22:00 → 2 instancias activas 22:30 → aumenta tráfico 22:35 → CPU supera 70 % 22:40 → Auto Scaling añade 2 instancias 22:45 → ALB reparte tráfico entre 4 instancias 23:30 → tráfico empieza a bajar 00:00 → CPU baja de 30 % 00:15 → Auto Scaling elimina 1 instancia 01:00 → vuelve a 2 instancias
Beneficios:
- La plataforma soporta el pico.
- Los usuarios tienen mejor experiencia.
- No se pagan 4 instancias toda la noche.
Relación con los pilares arquitectónicos
| Pilar | Contribución de la elasticidad |
|---|---|
| Fiabilidad | Balanceador y autoescalado mejoran disponibilidad |
| Rendimiento | Añade recursos cuando hacen falta, evita cuellos de botella |
| Costes | Reduce recursos cuando baja la demanda |
| Operación | Monitorización detecta problemas, genera alarmas, automatiza respuestas |
| Sostenibilidad | Evita mantener recursos innecesarios encendidos |
5. Errores frecuentes
- Confundir elasticidad con tener muchos servidores: si siempre hay diez servidores aunque solo se necesiten dos, hay capacidad pero no elasticidad.
- No usar balanceador: si hay varias instancias pero no hay balanceador, el tráfico no se reparte.
- No configurar health checks: el balanceador podría seguir enviando tráfico a instancias con problemas.
- No definir mínimo y máximo: un ASG sin límites puede no escalar lo suficiente o disparar costes.
- Escalar solo verticalmente: una instancia grande sigue siendo un punto único de fallo.
- No probar las alarmas: una alarma mal configurada puede no activarse nunca.
- Usar métricas incorrectas: no siempre la CPU es la mejor métrica (peticiones, latencia, cola pueden ser más adecuadas).
- Escalar hacia dentro demasiado rápido: reducir instancias pronto puede provocar inestabilidad.
- No diseñar la aplicación para varias instancias: sesiones en memoria local, archivos en disco local, cachés inconsistentes.
- Guardar archivos en el disco local de EC2: si una instancia se elimina, los archivos locales se pierden. Usar S3 o EFS.
- No controlar costes: el autoescalado puede añadir recursos automáticamente y aumentar la factura.
6. Buenas prácticas
- Diseñar sin puntos únicos de fallo: varias instancias, varias AZ, Load Balancer, RDS Multi-AZ, backups, health checks.
- Usar balanceador de carga: debe ser la entrada principal; no conectarse directamente a una instancia concreta.
- Configurar health checks útiles: deben comprobar que la aplicación realmente responde, no solo que la máquina está encendida.
- Definir límites mínimos y máximos (ej: mínimo 2, deseado 2, máximo 8).
- Elegir métricas adecuadas según el tipo de aplicación:
| Tipo de aplicación | Métrica útil |
|---|---|
| API web | Peticiones por instancia |
| App pesada en CPU | CPU Utilization |
| Sistema con cola | Longitud de cola |
| App sensible a usuario | Latencia |
| Sistema con muchas conexiones | Conexiones activas |
- Separar estado de la aplicación: archivos en S3/EFS, sesiones en almacén compartido, BD externa.
- Usar varias zonas de disponibilidad: si una AZ falla, la otra puede seguir respondiendo.
- Probar escenarios de carga: ¿Escala a tiempo? ¿El balanceador reparte bien? ¿La BD soporta el aumento?
- Monitorizar también el coste: presupuestos, alertas de gasto, límites máximos, etiquetado.
- Automatizar respuestas: añadir/retirar instancias, enviar alertas, reiniciar servicios, escalar según horario.
7. Ejercicio propuesto
Caso práctico: diseño de arquitectura elástica para una plataforma educativa
Un centro educativo quiere desplegar ElasticCloud Aula con: acceso de alumnos y profesores, descarga de materiales, subida de tareas, picos de tráfico antes de fechas límite, baja actividad durante la madrugada, buena disponibilidad, control de costes y monitorización continua.
Tareas (responde de forma razonada):
- Elasticidad: explica qué es una arquitectura elástica. Diferencia escalabilidad y elasticidad con ejemplos.
- Balanceo de carga: explica qué es y qué problema resuelve frente a una única instancia EC2.
- Application Load Balancer: explica qué es y por qué sería adecuado para una aplicación web educativa.
- Health checks: explica qué son y qué debería hacer el balanceador si detecta una instancia no saludable.
- Monitorización: explica por qué es necesaria. ¿Qué servicio de AWS se utiliza?
- Métricas: propón métricas para monitorizar EC2, ALB, Auto Scaling, aplicación y costes.
- Alarmas: define tres alarmas útiles (CPU alta, errores 5xx, instancias saludables bajas).
- Auto Scaling: explica qué es un ASG. ¿Qué significan mínimo, deseado y máximo? Propón valores razonables.
- Escalado horizontal y vertical: diferencia. ¿Cuál se prioriza en arquitecturas elásticas y por qué?
- Política de escalado: propón una política hacia fuera y otra hacia dentro. Justifica por qué la reducción debe ser prudente.
- Arquitectura completa: dibuja un esquema con DNS, ALB, ASG, EC2 en varias AZ, CloudWatch y políticas de escalado.
- Picos de tráfico: explica qué ocurre si el tráfico se multiplica por cinco antes de una entrega (con y sin elasticidad).
- Bajada de tráfico: explica qué debería ocurrir durante la madrugada y cómo ayuda a reducir costes.
- Errores a evitar: indica al menos cinco.
Solución orientativa: ElasticCloud Aula │ ├── DNS → www.elasticcloudaula.es ├── Application Load Balancer → HTTPS, health checks, reparto de tráfico ├── Auto Scaling Group → mínimo: 2, deseado: 2, máximo: 8 ├── EC2 Zona A, Zona B, Zona C ├── CloudWatch → CPU, peticiones, latencia, errores, alarmas └── Políticas de escalado ├── CPU > 70 % → añadir instancias └── CPU < 30 % → reducir instancias
Arquitectura completa: Usuarios → CloudFront/CDN ├── S3 para contenidos estáticos ▼ Application Load Balancer ▼ Auto Scaling Group ├── EC2 Zona A ├── EC2 Zona B └── EC2 Zona C │ ▼ RDS privado
CloudWatch + Alarmas + Auto Scaling
Conclusión
El escalado automático y la monitorización son elementos esenciales para construir arquitecturas cloud modernas.
El balanceo de carga permite repartir tráfico entre varias instancias y evitar que una sola máquina soporte todo el trabajo.
La monitorización permite saber qué está ocurriendo: uso de CPU, número de peticiones, latencia, errores, estado de instancias y comportamiento general del sistema.
El autoescalado permite añadir o eliminar recursos automáticamente según la demanda.
La combinación de estos tres elementos crea arquitecturas elásticas: sistemas capaces de crecer cuando lo necesitan y reducirse cuando la carga baja. Esto mejora la disponibilidad, el rendimiento, la experiencia de usuario y el control de costes.
En definitiva, una arquitectura elástica no consiste en tener muchos servidores. Consiste en tener los servidores necesarios en cada momento. Y esa es una de las grandes promesas de la nube: que la infraestructura deje de ser rígida y empiece a comportarse como el propio uso real de la aplicación.