Lab: Análisis y Diseño de Arquitectura EC2
Objetivos del Lab
Este lab es un ejercicio de diseño y análisis. Usted va a:
- ✅ Analizar arquitecturas EC2 existentes
- ✅ Identificar buenas prácticas y errores
- ✅ Diseñar su propia arquitectura
- ✅ Justificar sus elecciones técnicas
Enfoque Teórico
Este lab no requiere acceso a AWS. Trabajará en papel/documento con esquemas y análisis.
Duración Estimada
2 horas
Parte 1: Análisis de Arquitectura Existente
Escenario: Sitio E-Commerce
Aquí está la arquitectura actual de un sitio e-commerce:
┌─────────────────────────────────────────────────────────────┐
│ RÉGION : us-east-1 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ AZ : us-east-1a │ │
│ │ │ │
│ │ ┌─────────────────────────────────────────────┐ │ │
│ │ │ Instance EC2 : i-web001 │ │ │
│ │ │ Type : t2.micro │ │ │
│ │ │ AMI : Amazon Linux 2 │ │ │
│ │ │ IP Publique : 52.1.2.3 │ │ │
│ │ │ │ │ │
│ │ │ Applications : │ │ │
│ │ │ - Apache (port 80) │ │ │
│ │ │ - MySQL (port 3306) │ │ │
│ │ │ - Application PHP │ │ │
│ │ │ │ │ │
│ │ │ Security Group : sg-default │ │ │
│ │ │ Règles : │ │ │
│ │ │ - Inbound: SSH (22) - 0.0.0.0/0 │ │ │
│ │ │ - Inbound: HTTP (80) - 0.0.0.0/0 │ │ │
│ │ │ - Inbound: MySQL (3306) - 0.0.0.0/0 │ │ │
│ │ │ │ │ │
│ │ │ Stockage : 8 GB EBS (gp2) │ │ │
│ │ └─────────────────────────────────────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
Preguntas de Análisis
Pregunta 1: Problemas de Seguridad
Identifique al menos 3 problemas de seguridad en esta arquitectura.
💡 Pista
Observe:
- Las reglas del Security Group
- La ubicación de MySQL
- La arquitectura de una sola instancia
Pregunta 2: Problemas de Disponibilidad
Identifique los riesgos de disponibilidad de esta arquitectura.
💡 Pista
Piense en:
- Número de zonas de disponibilidad
- Punto único de falla (SPOF)
- Capacidad de escalado
Pregunta 3: Problemas de Rendimiento
El sitio se vuelve lento durante las rebajas. ¿Cuáles son las posibles causas?
💡 Pista
Analice:
- El tipo de instancia
- La separación de componentes
- El almacenamiento
Parte 2: Corrección de la Arquitectura
Ejercicio: Proponer una Mejor Arquitectura
Rediseñe la arquitectura corrigiendo los problemas identificados.
Restricciones:
- Presupuesto moderado (sin instancias gigantes)
- El sitio debe estar disponible 99.9%
- La base de datos debe estar segura
- Debe soportar picos de tráfico (rebajas)
Plantilla de Respuesta
Complete esta plantilla:
NUEVA ARQUITECTURA PROPUESTA
============================
Región: _____________
Zonas de Disponibilidad utilizadas: ____________
COMPONENTE 1: Servidor(es) Web
------------------------------
- Número de instancias: _____
- Tipo de instancia: _____
- AMI: _____
- Ubicación: _____
- Security Group:
- Inbound: _____
- Outbound: _____
COMPONENTE 2: Base de Datos
---------------------------
- Servicio/Instancia: _____
- Tipo: _____
- Ubicación: _____
- Security Group:
- Inbound: _____
COMPONENTE 3: (Opcional)
------------------------
- _____
JUSTIFICACIONES
---------------
1. ¿Por qué este tipo de instancia? _____
2. ¿Por qué esta configuración de red? _____
3. ¿Cómo gestiona la alta disponibilidad? _____
Parte 3: Esquema de Arquitectura
Ejercicio: Dibujar la Arquitectura
Cree un esquema de arquitectura profesional que incluya:
Elementos obligatorios:
- La región AWS
- Al menos 2 zonas de disponibilidad
- Las instancias EC2 (web)
- La base de datos (separada)
- Los Security Groups con sus reglas
- Las conexiones de red
Herramientas sugeridas:
- Draw.io (gratuito): https://app.diagrams.net/
- Lucidchart (gratuito limitado)
- PowerPoint/Google Slides
- Papel y lápiz (foto a adjuntar)
Ejemplo de Estructura
┌─────────────────────────────────────────────────────────────┐
│ RÉGION : __________ │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────────────────────────┐ │
│ │ [Su componente] │ │
│ └──────────────────────────────────────┘ │
│ │
│ ┌───────────────────┐ ┌───────────────────┐ │
│ │ AZ : ____ │ │ AZ : ____ │ │
│ │ │ │ │ │
│ │ [Instancias] │ │ [Instancias] │ │
│ │ │ │ │ │
│ └───────────────────┘ └───────────────────┘ │
│ │
│ ┌──────────────────────────────────────┐ │
│ │ [Base de datos] │ │
│ └──────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
Parte 4: Estudio de Caso - Elección de Instancias
Escenario A: Startup - MVP
Contexto:
- Aplicación web simple (blog + formulario de contacto)
- 100 visitantes/día esperados
- Presupuesto muy limitado (< $20/mes)
- Equipo de 2 desarrolladores
Preguntas:
1. ¿Qué tipo de instancia recomienda?
2. ¿Qué región?
3. ¿Qué compromisos hace?
Escenario B: PyME - Aplicación Empresarial
Contexto:
- ERP/CRM para 50 empleados
- Base de datos PostgreSQL (20 GB)
- Uso 8h-18h, lunes-viernes
- Necesidad de rendimiento constante
Preguntas:
1. ¿Qué tipo de instancia para la aplicación?
2. ¿Qué tipo de instancia para la base de datos?
3. ¿Se requieren instancias Reserved?
Escenario C: E-Commerce - Black Friday
Contexto:
- Sitio e-commerce existente
- Tráfico normal: 1000 visitantes/hora
- Black Friday: 50000 visitantes/hora (pico)
- Catálogo de 10000 productos
Preguntas:
1. ¿Cómo gestionar el pico de tráfico?
2. ¿Qué estrategia de escalado?
3. ¿Qué tipos de instancias para cada nivel de carga?
Parte 5: Tabla Resumen de Elecciones
Complete esta tabla para cada escenario:
| Criterio | Escenario A | Escenario B | Escenario C |
|---|---|---|---|
| Instancia Web | |||
| Instancia BDD | |||
| Modelo de precios | |||
| Número de AZ | |||
| Costo estimado/mes | |||
| Justificación principal |
Entregables del Lab
Documento a Entregar
Cree un documento (Word, PDF o Markdown) que contenga:
1. Portada
- Nombre, fecha, título del lab
2. Parte 1: Análisis (20%)
- Lista de 3+ problemas de seguridad
- Lista de riesgos de disponibilidad
- Análisis de problemas de rendimiento
3. Parte 2: Corrección (25%)
- Plantilla completada con la nueva arquitectura
- Justificaciones detalladas
4. Parte 3: Esquema (25%)
- Esquema de arquitectura claro y legible
- Leyenda de los componentes
- Security Groups documentados
5. Parte 4: Estudios de Caso (20%)
- Respuestas para los 3 escenarios
- Justificación de las elecciones
6. Parte 5: Tabla (10%)
- Tabla resumen completada
Tabla de Evaluación
| Criterio | Puntos |
|---|---|
| Identificación correcta de los problemas | 4 |
| Arquitectura corregida coherente | 5 |
| Esquema claro y completo | 5 |
| Elección de instancias justificada | 4 |
| Tabla resumen completa | 2 |
| Total | 20 |
Corrección - Parte 1 (Consultar después de realizar el ejercicio)
📋 Ver la corrección
Problemas de Seguridad
-
SSH abierto a todo el mundo (0.0.0.0/0)
- Riesgo: Ataques de fuerza bruta
- Solución: Restringir a la IP del administrador
-
MySQL expuesto públicamente (0.0.0.0/0)
- Riesgo: Acceso no autorizado a la base de datos
- Solución: Cerrar el puerto, acceso solo interno
-
Todo en la misma instancia
- Riesgo: Si la instancia es comprometida, todo lo está
- Solución: Separar web y base de datos
-
Uso del SG por defecto
- Riesgo: Reglas no auditadas
- Solución: Crear SG específicos
Problemas de Disponibilidad
-
Una sola AZ
- Riesgo: Falla de zona = sitio caído
- Solución: Multi-AZ
-
Instancia única (SPOF)
- Riesgo: Falla de instancia = sitio caído
- Solución: Múltiples instancias + Load Balancer
-
Sin backup visible
- Riesgo: Pérdida de datos
- Solución: Snapshots EBS, RDS Multi-AZ
Problemas de Rendimiento
-
t2.micro demasiado pequeña
- Créditos burst se agotan rápidamente
- Solución: t3.small mínimo para producción
-
MySQL en la misma instancia
- Competencia por los recursos
- Solución: Instancia dedicada o RDS
-
8 GB de almacenamiento insuficiente
- Solución: EBS gp3, más grande
Recursos para el Lab
Iconos AWS
Documentación
Calculadora de Precios
¡Felicidades! Ha completado el lab de arquitectura EC2. Estas habilidades de diseño son esenciales para cualquier arquitecto cloud.