Saltar a contenido

PR701 — Mejorar un diagrama frágil

Qué es esto

Guía de apoyo al lab. No sustituye el enunciado ni la rúbrica del Tema 7. Entrega: Cómo entregar → PR701.md.

Antes de empezar

  • Práctica de texto: no montas el diagrama completo en consola.
  • Anti-patrón de partida (enunciado): EC2 t3.large en una AZ; MySQL en la misma instancia; AMI manual; SG 0.0.0.0/0 en 3306; backups en /home.
  • Entregas cinco cambios distintos: Problema → servicio/práctica Foundations → pilar → trade-off.
  • Opcional: knowledge check Academy M9.
  • Well-Architected Tool: solo contexto (visión general); no es el entregable.

Recorrido orientativo

  1. Inventaría el anti-patrón. Lista mental: una AZ; estado (MySQL) en disco local; secretos/config en AMI; SG abierto; backups en /home sin versionado/objetos.

  2. Prioriza seguridad y fiabilidad antes que adornos de rendimiento o «más grande = mejor».

  3. Elige cinco problemas distintos del anti-patrón (o derivados claros). Un cambio = un pilar principal (puedes mencionar un segundo).

  4. Estudia dos filas ejemplo (distintas; no copies solo una y dejes el resto vacío):

# Problema Servicio / práctica Foundations Pilar Mejora / qué empeora (trade-off)
1 MySQL en la misma EC2; SG 3306 a 0.0.0.0/0 RDS en subnet privada + SG solo desde el SG de la API Seguridad (+ fiabilidad) Mejor aislamiento y parches del motor; más coste y un poco más de red que gestionar
2 Una sola AZ: si cae el edificio, cae todo EC2 (o ASG) en dos AZ detrás de un ALB Fiabilidad Aguantas fallo de AZ; más instancias/ALB = más coste y un health check que cuidar
  1. Plantilla para tu PR701.md (cinco filas; sustituye los … y no dejes vacías):
| # | Problema | Servicio / práctica Foundations | Pilar | Mejora / qué empeora (trade-off) |
| ---: | --- | --- | --- | --- |
| 1 | … | … | … | … |
| 2 | … | … | … | … |
| 3 | … | … | … | … |
| 4 | … | … | … | … |
| 5 | … | … | … | … |

  1. Completa filas 3–5 con ideas Foundations típicas (elige y justifica): AMI → IaC/plantilla; backups /home → S3 + política; sin alarmas → CloudWatch; IAM/roles en lugar de keys en disco; etc. Declara siempre el trade-off (coste, complejidad).

  2. Revisa pilares. No etiquetes las cinco como «rendimiento». Seguridad / fiabilidad / excelencia operativa / optimización de costes / sostenibilidad según el cambio.

  3. Cierre. No hace falta dibujar el diagrama entero ni lanzar recursos. KC M9 opcional: evidencia breve si lo haces.

Evidencia ↔ rúbrica

Criterio Qué dejar en el .md
Cinco cambios Tabla con 5 filas completas y distintas
Pilares Etiqueta correcta por fila
Trade-off Qué mejora / qué empeora en cada fila
Claridad Formato legible (tabla del enunciado)

Capturas

Las figuras de esta página son de apoyo. En tu .md del lab usa capturas propias del mismo paso; sin Account ID, claves ni contraseñas.

Errores frecuentes

  • Cinco frases vagas sin pilar ni trade-off.
  • Etiquetar todo como «rendimiento».
  • Proponer landing zone multi-cuenta (fuera de Foundations de este módulo).
  • Copiar solo una fila ejemplo y dejar el resto vacío.
  • Entregar la Well-Architected Tool como si fuera la práctica.

Limpieza

Nada en consola. Si abriste la Well-Architected Tool por curiosidad, no dejes workloads de lab sin sentido; no es obligatorio usarla.