Saltar a contenido

PR701 — Mejorar un diagrama frágil

Qué es esto

Guía de apoyo. 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.
  • El Módulo 9 de Cloud Foundations no tiene laboratorio: la práctica de clase es este análisis.
  • Diseño frágil de partida (enunciado): EC2 t3.large en una AZ; MySQL en la misma instancia; AMI manual; SG 0.0.0.0/0 en 3306; copias de seguridad en /home.
  • Entregas cinco mejoras distintas en prosa (no en una fórmula fija de flechas).
  • Opcional: evaluación de conocimientos del Módulo 9 para fijar vocabulario.
  • Well-Architected Tool: solo contexto (visión general); no es el entregable.

Recorrido orientativo

  1. Repasa el diseño frágil: una AZ; estado (MySQL) en disco local; configuración en AMI; SG abierto; copias en /home sin objetos versionados.

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

  3. Elige cinco problemas distintos. Un cambio = un pilar principal (puedes mencionar un segundo).

  4. Lee estos dos ejemplos en prosa (distintos; no copies solo uno y dejes el resto vacío):

Ejemplo 1. El problema es MySQL en la misma EC2 con el puerto 3306 abierto a internet. La práctica Foundations es mover la BD a RDS en subred privada y dejar que el SG de RDS solo acepte el SG de la API. El pilar principal es seguridad (también gana fiabilidad). Mejora el aislamiento y deja que AWS mantenga y actualice el motor; empeora el coste y añade un poco de red que cuidar.

Ejemplo 2. El problema es una sola AZ: si cae esa zona, cae todo. La práctica es poner instancias (o un ASG) en dos AZ detrás de un ALB. El pilar es fiabilidad. Aguantas el fallo de una AZ; empeora el coste (más instancias y el ALB) y hay que cuidar la comprobación de estado (health check).

  1. En tu PR701.md, escribe cinco mejoras en párrafos. En cada una deja claro: el problema, el servicio o la práctica de Foundations, el pilar y qué mejora (y qué empeora: coste, complejidad). Ideas habituales: AMI manual pasa a IaC o imagen repetible; copias en /home pasan a S3; sin alarmas pasa a CloudWatch; claves en disco pasan a roles IAM; trabajos largos en el HTTP pasan a SQS.

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

  3. Cierre. No hace falta dibujar el diagrama entero ni lanzar recursos. Si haces la evaluación de conocimientos del Módulo 9, añade una nota breve; no sustituye las cinco mejoras.

Qué entregar para cada criterio de la rúbrica

Criterio Qué dejar en el .md
Cinco mejoras Cinco bloques en prosa, distintos y completos
Pilares Etiqueta correcta en cada mejora
Equilibrio Qué mejora y qué empeora (coste, complejidad)
Claridad Párrafos legibles, sin lista vacía de flechas

Capturas

No son obligatorias. Si usas capturas de la Well-Architected Tool por curiosidad, sin Account ID ni datos de cuenta.

Errores frecuentes

  • Cinco frases vagas sin pilar ni equilibrio coste/complejidad.
  • Etiquetar todo como «rendimiento».
  • Proponer un entorno de varias cuentas (landing zone) (fuera de Foundations de este módulo).
  • Copiar solo un 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.