1. Concepto de elasticidad
La elasticidad permite que una arquitectura ajuste automáticamente su capacidad en función de la demanda real. En AWS se logra combinando Auto Scaling, Elastic Load Balancing y modelos de compra flexibles (On-Demand, Savings Plans, Spot).
EXAM TIP: Tráfico variable e impredecible → usa Auto Scaling Groups con target tracking + ALB y mezcla de instancias On-Demand/Spot.
2. Auto Scaling & Load Balancing
Un Auto Scaling Group (ASG) gestiona automáticamente la creación y terminación de instancias para mantener la capacidad deseada.
- Launch Templates con versioning para control granular.
- Mixed Instances Policy para combinar tipos y zonas con descuentos Spot.
- Health checks de ELB y EC2.
- Warm pools reducen el tiempo de arranque durante picos.
| Tipo de carga | Balanceador recomendado |
|---|---|
| HTTP / HTTPS | Application Load Balancer (L7) |
| TCP/UDP / IP fija | Network Load Balancer (L4) |
| Firewall/partners de red | Gateway Load Balancer (GWLB) |
3. Modelos de compra
Los modelos de compra permiten optimizar costes según la previsibilidad de la carga:
| Escenario | Modelo | Ventaja |
|---|---|---|
| Carga estable 24/7 | Savings Plans / RI | Hasta 72% de ahorro |
| Picos impredecibles | On-Demand | Sin compromiso, pago por uso |
| Batch / tolerancia a fallos | Spot | Hasta 90% de ahorro, pero con interrupciones |
4. Políticas y estrategias de escalado
- Target Tracking: ajusta instancias para mantener una métrica (ej. CPU a 50%).
- Step Scaling: incrementa o reduce por niveles según el umbral.
- Scheduled Scaling: programa ventanas previsibles (ej. horario laboral).
- Predictive Scaling: usa IA para prever demanda (CloudWatch + histórico).
# Ejemplo: Escalado basado en CPU promedio
aws autoscaling put-scaling-policy \
--auto-scaling-group-name web-tier \
--policy-name cpu50 \
--policy-type TargetTrackingScaling \
--target-tracking-configuration '{
"PredefinedMetricSpecification": {"PredefinedMetricType": "ASGAverageCPUUtilization"},
"TargetValue": 50.0
}'5. Blue/Green y despliegues canary
Blue/Green implica mantener dos entornos paralelos (actual y nuevo). AWS CodeDeploy y ALB permiten mover tráfico gradualmente o revertir instantáneamente.
- Canary: despliegue parcial (5-10%) → monitoreo → promoción total.
- Linear: incremento progresivo hasta 100%.
- All-at-once: cambio total, más rápido pero con riesgo.
EXAM TIP: Piden rollback inmediato → Blue/Green con cambio de target group.
6. Métricas y analítica de rendimiento
Integra CloudWatch con Application Insights o X-Ray para correlacionar métricas de cómputo y rendimiento de aplicación.
- Analiza métricas de CPUUtilization, NetworkIn/Out y RequestCount.
- Usa Composite Alarms para reducir ruido (ej. CPU + Latencia ALB).
- Guarda métricas históricas en S3 o CloudWatch Logs para predicción.
- Integra dashboards con Cost Explorer o CloudWatch Explorer para visibilidad FinOps.
7. Patrones de examen
- Tráfico impredecible → ALB + ASG target tracking + Spot/On-Demand mix.
- Requisitos TCP/IP fijo → NLB con cross-zone y health checks.
- Escalado predecible → Scheduled scaling.
- Rollback rápido → Blue/Green con CodeDeploy.
- Optimización de costes → Savings Plans o Spot para cargas no críticas.
Regla mental: “Escalado = ASG”, “Tráfico = ELB”, “Coste = modelo de compra”, “Seguridad de despliegue = Blue/Green”.