🧩 Cómo funciona una aplicación web en AWS usando EC2, Load Balancer y Auto Scaling

✅ ¿Qué vamos a construir?

Una arquitectura web escalable, balanceada y resistente donde:

• Las instancias EC2 se crean y destruyen automáticamente (ASG).

• El tráfico se distribuye de forma eficiente (ELB).

• Las sesiones de usuario no se pierden aunque cambie la instancia.

---

🌐 Flujo general

1. Un usuario abre tu app (ej. www.miapp.com)

2. El tráfico llega al Elastic Load Balancer

3. El Load Balancer elige una EC2 (detrás del ASG)

4. La EC2 procesa la solicitud y responde

5. Si hay más tráfico o falla una instancia, el ASG escala o reemplaza instancias automáticamente

---

🔄 Analogía fácil

🧑‍🍳 Imagina un restaurante con:

• Una entrada con recepcionista (Load Balancer) que decide a qué mesa llevar a cada cliente.

• Un equipo de meseros (instancias EC2) que atienden las órdenes.

• Si hay muchos clientes, el jefe de sala (Auto Scaling) llama más meseros o reemplaza al que se enfermó.

Pero... ¿qué pasa si un mesero desaparece y se lleva el pedido? 🤔
Necesitamos una forma de no perder la orden (sesión). ¡Vamos a eso!

---

🧠 Cómo funciona cada componente

💻 Instancias EC2

• Corren tu app (ej. en Node.js, Django, Spring Boot, etc.)

• Deben ser stateless: no guardar información en la memoria local que dependa del usuario

---

⚖️ Elastic Load Balancer (ELB)

• Recibe todas las solicitudes entrantes

• Las reparte entre instancias vivas y saludables

• Puede hacer:

  • Health checks para no enviar tráfico a instancias fallando

  • Enrutamiento basado en URL o puertos (ALB)

  • Soporte para HTTPS y certificados (con ACM)

---

📈 Auto Scaling Group (ASG)

• Mantiene una cantidad mínima, deseada y máxima de instancias EC2

• Puede escalar:

  • Por CPU, tráfico, número de solicitudes, etc.

  • Manualmente o automáticamente

• Si una instancia falla, la reemplaza automáticamente

---

🔐 ¿Y los datos de sesión? ¿Cómo no se pierden?

💥 Problema clásico: si una sesión se guarda en memoria (ej. req.session.user = x) y el usuario es redirigido a otra EC2… ¡pierde la sesión!

🛠️ Soluciones comunes para manejar sesiones en apps escaladas:

🧠 Lo más escalable y recomendado es usar Redis o DynamoDB para guardar las sesiones de forma centralizada, o JWT si no necesitas guardar estado en servidor.

---

💡 Buenas prácticas para que todo funcione bien

1. Haz tu app stateless: no guardes sesiones, archivos o estados en disco local.

2. Guarda archivos en S3, no en EC2 (logs, imágenes, etc.).

3. Usa launch templates o launch configurations para definir cómo se crean nuevas EC2.

4. Configura health checks en el Load Balancer y en el ASG.

5. Activa Auto Scaling con políticas basadas en CPU, tráfico o métricas personalizadas.

6. Usa CloudWatch para monitorear el comportamiento de tu arquitectura.

---

📊 Arquitectura visual resumida

           Usuarios
               ↓
      ┌──────────────────┐
      │   Load Balancer  │
      └──────────────────┘
           ↓     ↓     ↓
   ┌────────┐ ┌────────┐ ┌────────┐
   │  EC2-1 │ │  EC2-2 │ │  EC2-3 │ ← Escaladas por ASG
   └────────┘ └────────┘ └────────┘
           ↓         ↓
        DynamoDB o Redis (para sesiones)
           ↓
         S3 (archivos estáticos)

---

📦 Resumen práctico

---

🧩 Relación con otros servicios

• 🔐 ACM para manejar certificados SSL gratis en el ALB

• 🔄 Elasticache (Redis) o DynamoDB para manejar sesiones compartidas

• 📦 S3 para servir archivos compartidos sin depender de EC2

• 🔔 CloudWatch + SNS para alertas cuando algo se cae

• 📍 Route 53 para enrutar tráfico global y manejar DNS