El módulo anterior terminó con la arquitectura de MercadoFresco completa: elástica, segura, observable, desplegable desde un pipeline, descrita en código y repartida en cinco cuentas de trabajo. Y con una pregunta incómoda esperando al lunes por la mañana. Antes de responder cuánto cuesta, conviene responder algo previo: ¿está bien construida? No «¿funciona?» —funciona— sino «¿resiste una auditoría honesta?».

Esta lección presenta el método que AWS publica para hacer esa auditoría: el Well-Architected Framework. Verás qué es y qué no es, los seis pilares con sus principios de diseño y sus preguntas clave, la revisión real de MercadoFresco pilar por pilar con sus hallazgos y su riesgo, los compromisos entre pilares que nadie puede evitar, la Well-Architected Tool para llevar la revisión con método, y la conversación que casi nunca se tiene por escrito: RTO, RPO y las cuatro estrategias de recuperación ante desastres. Al final tendrás un plan de mejora priorizado, y el primer punto de ese plan es el que abre las cinco lecciones siguientes.

Aviso de coste. La AWS Well-Architected Tool es gratuita: no cobra por cargas de trabajo, revisiones, hitos ni lentes. Lo que cuesta dinero son las acciones que salen del plan de mejora —una réplica en otra región, un simulacro de carga, un plan de soporte superior— y eso es exactamente lo que esta lección te enseña a priorizar en vez de comprarlo todo. Datos, cuentas e identificadores ficticios.

1. Qué es el Well-Architected Framework y qué no es
2. La anatomía del marco: pilares, preguntas, buenas prácticas y plan de mejora
3. Pilar 1: excelencia operativa
4. Pilar 2: seguridad
5. Pilar 3: fiabilidad
6. Pilar 4: eficiencia del rendimiento
7. Pilar 5: optimización de costes
8. Pilar 6: sostenibilidad
9. Los compromisos entre pilares y cómo se documentan
10. El registro de decisiones de arquitectura
11. RTO, RPO y las cuatro estrategias de recuperación ante desastres
12. La decisión de recuperación de MercadoFresco
13. La AWS Well-Architected Tool: cargas de trabajo, hitos y lentes
14. La rutina: quién revisa, cada cuánto y qué se hace con los hallazgos
15. Revisión periódica frente a comprobación continua: Trusted Advisor y Config
16. El plan de mejora priorizado de MercadoFresco
17. Errores comunes y consejos
18. Ejercicios
19. Conclusión

El AWS Well-Architected Framework es un documento público —un conjunto de documentos, en realidad— que recoge lo que AWS ha aprendido revisando decenas de miles de arquitecturas de clientes. Su formato no es una lista de servicios recomendados, sino una colección de preguntas agrupadas en seis pilares, cada una con sus buenas prácticas asociadas.

La forma de las preguntas es siempre la misma: «¿Cómo hace usted X?». No «¿Usa usted el servicio Y?». Esa diferencia es toda la utilidad del marco:

• «¿Cómo protege los datos en reposo?» admite responder con KMS, con cifrado de cliente, o con una justificación de por qué esos datos no necesitan cifrado. Las tres son respuestas válidas si están razonadas.
• «¿Usa KMS?» solo admite sí o no, y convierte la arquitectura en una lista de la compra.

Conviene decir con claridad qué no es:

• No es una certificación. Nadie aprueba ni suspende. No hay un sello «Well-Architected» que colgar en la web.
• No es una lista de compras de servicios de AWS. Muchas de las mejores respuestas no cuestan dinero: escribir un procedimiento, hacer un simulacro, borrar un permiso.
• No es una auditoría de cumplimiento. No sustituye a un ENS, un ISO 27001 ni a la revisión de un profesional de protección de datos. Hay solape, pero el objetivo es distinto.
• No es un trabajo de una tarde ni de una sola vez. Una arquitectura que estaba bien hace un año puede no estarlo hoy: ha crecido, ha cambiado el negocio y han aparecido servicios nuevos.
• No exige arreglarlo todo. El resultado es una lista priorizada de riesgos aceptados conscientemente y riesgos que se van a mitigar. Aceptar un riesgo por escrito es una respuesta profesional; ignorarlo no.

Lo que sí es: una forma estructurada de encontrar lo que no sabías que te faltaba, y de convertirlo en una conversación con el negocio que no dependa de la intuición de quien habla más alto.

La estructura es jerárquica y conviene tenerla clara antes de abrir la herramienta:

Los elementos:

Los seis pilares —y su orden importa poco, porque no hay un pilar más importante que otro en abstracto, solo en tu contexto— son:

Un detalle práctico antes de empezar: la revisión se hace sobre una carga de trabajo concreta, no sobre «la empresa». MercadoFresco define una carga llamada mercadofresco-tienda-produccion, que abarca la tienda, el catálogo, los pedidos y el reparto en la cuenta 111122223333. La analítica de Sara será una segunda carga de trabajo con su propia revisión, porque tiene otros requisitos, otro riesgo y otro dueño.

Trata de cómo se ejecuta y se mejora la carga de trabajo: procedimientos, observabilidad, respuesta a incidentes y aprendizaje.

Principios de diseño:

• Realizar las operaciones como código: si se hace dos veces a mano, se automatiza.
• Hacer cambios frecuentes, pequeños y reversibles.
• Refinar los procedimientos con frecuencia, no dejarlos fosilizados en un documento de hace dos años.
• Anticipar el fallo: ensayarlo antes de sufrirlo.
• Aprender de todos los fallos operativos con post mortem sin culpables.
• Usar la observabilidad para obtener conocimiento accionable, no gráficos bonitos.

Preguntas clave: cómo se determinan las prioridades; cómo se estructuran los equipos para respaldar el resultado de negocio; cómo se diseña la carga para poder entenderla en ejecución; cómo se reduce el riesgo de los cambios; cómo se sabe que está lista para producción; cómo se sabe que está sana; cómo se gestionan los eventos operativos; y cómo se evoluciona lo aprendido.

Revisión de MercadoFresco:

Un detalle que suele pasar desapercibido: MercadoFresco tiene una observabilidad excelente y una operación floja. Sabe perfectamente qué está pasando y no ha escrito qué hacer cuando pasa. Es el patrón más habitual en equipos técnicos buenos.

Trata de proteger la información, los sistemas y los activos, con controles que detecten y respondan.

Principios de diseño:

• Base de identidad fuerte: mínimo privilegio, separación de funciones, nada de credenciales de larga duración.
• Trazabilidad: registrar, monitorizar y auditar todas las acciones.
• Aplicar seguridad en todas las capas, no solo en el perímetro.
• Automatizar las buenas prácticas de seguridad.
• Proteger los datos en tránsito y en reposo, y clasificarlos.
• Mantener a las personas lejos de los datos: si nadie necesita entrar, nadie entra.
• Prepararse para el incidente: tener plan, herramientas y ensayo.

Preguntas clave: cómo se gestiona la cuenta y las identidades; cómo se gestionan los permisos de personas y de máquinas; cómo se detectan eventos de seguridad; cómo se protegen las redes, el cómputo y los datos; y cómo se responde a un incidente.

Revisión de MercadoFresco:

Trata de que la carga haga lo que debe cuando debe, y se recupere de las interrupciones.

Principios de diseño:

• Recuperarse automáticamente del fallo, detectándolo con indicadores clave.
• Probar los procedimientos de recuperación, no solo escribirlos.
• Escalar horizontalmente para aumentar la disponibilidad agregada.
• Dejar de adivinar la capacidad.
• Gestionar el cambio mediante automatización.

Preguntas clave: cómo se gestionan las cuotas de servicio; cómo se diseña la topología de red; cómo se diseña la arquitectura de servicios para resistir el fallo de una dependencia; cómo se monitoriza; cómo se prueba la fiabilidad; y cómo se planifica la recuperación ante desastres.

Revisión de MercadoFresco:

Este pilar es el peor parado de los seis, y no por casualidad: todo lo que falta son ensayos, y los ensayos son lo primero que se aplaza cuando hay que entregar funcionalidad.

Trata de usar los recursos adecuados —no solo suficientes— y de seguir haciéndolo cuando el mundo cambia.

Principios de diseño:

• Democratizar las tecnologías avanzadas: consumirlas como servicio en lugar de operarlas.
• Llegar a escala global en minutos.
• Usar arquitecturas sin servidor donde encajen.
• Experimentar más a menudo, porque en la nube probar es barato.
• Tener afinidad mecánica: elegir la tecnología por cómo funciona por dentro, no por costumbre.

Preguntas clave: cómo se selecciona la arquitectura; cómo se seleccionan y usan los recursos de cómputo, almacenamiento, base de datos y red; y cómo se monitoriza el rendimiento para asegurar que sigue siendo el esperado.

Revisión de MercadoFresco:

Trata de obtener el máximo valor de negocio por dólar gastado. No es «gastar poco»: es «gastar bien y saberlo».

Principios de diseño:

• Implantar la gestión financiera de la nube (FinOps) como una capacidad, no como un susto anual.
• Adoptar un modelo de consumo: pagar por lo que se usa.
• Medir la eficiencia global: coste por unidad de negocio, no coste absoluto.
• Dejar de gastar en trabajo pesado indiferenciado: centros de datos, parcheo de anfitriones.
• Analizar y atribuir el gasto: que cada equipo vea el suyo.

Preguntas clave: cómo se implanta la gobernanza del gasto; cómo se monitoriza el uso y el coste; cómo se desmantela lo que ya no se usa; cómo se evalúan las opciones de compra y los tipos de recurso; cómo se planifica la demanda; y cómo se evalúan los cambios de coste a lo largo del tiempo.

Revisión de MercadoFresco:

Ocho hallazgos y cinco de riesgo alto. Es el pilar peor gobernado, con diferencia, y es coherente con la realidad: es el único que no da un error en producción cuando se ignora. Simplemente cobra.

Es el pilar más reciente y el peor entendido. Trata del impacto ambiental de ejecutar la carga de trabajo: energía, hardware y recursos consumidos.

Principios de diseño:

• Entender el impacto y medirlo.
• Establecer objetivos de sostenibilidad por unidad de trabajo.
• Maximizar la utilización: un servidor al 10 % consume casi lo mismo que al 60 %.
• Adoptar hardware y software más eficientes en cuanto están disponibles.
• Usar servicios gestionados, que agregan la carga de muchos clientes.
• Reducir el impacto aguas abajo: menos datos transferidos, menos dispositivos de cliente forzados a trabajar.

Preguntas clave: cómo se seleccionan las regiones según el objetivo de sostenibilidad; cómo se alinean los patrones de software con la demanda; cómo se aprovechan los datos; cómo se gestionan el hardware y el ciclo de vida; y cómo se optimizan los procesos de desarrollo y despliegue.

Revisión de MercadoFresco:

Un apunte honesto: en el 90 % de los casos, las acciones del pilar de sostenibilidad coinciden exactamente con las del pilar de costes. Apagar lo que nadie usa ahorra dinero y energía. Es el pilar con la mejor relación entre esfuerzo y resultado, precisamente porque va de la mano del siguiente.

Aquí es donde el marco deja de ser una lista y empieza a ser ingeniería. Los seis pilares no se maximizan a la vez. Cada decisión sube uno y baja otro. Ejemplos reales de MercadoFresco:

La lección no es «elige bien». Es más concreta: un compromiso solo es defendible si está escrito, cuantificado y firmado por quien asume el riesgo. Multi-AZ cuesta el doble; si el gerente entiende que ese doble compra no perder los pedidos de un viernes, la decisión es suya y está tomada. Si nadie se lo ha contado, la decisión no existe: solo hay una factura.

La herramienta para no perder ese razonamiento se llama ADR (Architecture Decision Record, registro de decisiones de arquitectura): un fichero de texto corto, versionado junto al código, por cada decisión relevante. MercadoFresco los guarda en mercadofresco-infra bajo docs/adr/.

Formato mínimo, cuatro secciones:

Tres reglas para que los ADR sirvan de algo:

1. Un fichero por decisión, y no se edita: si la decisión cambia, se escribe un ADR nuevo que sustituye al anterior y se marca el viejo como sustituida por ADR-027. El historial es el valor.
2. Se escriben cuando se decide, no cuando alguien pregunta seis meses después.
3. Incluyen siempre las alternativas descartadas y por qué. Es la parte que más se agradece cuando el contexto cambia: permite saber si la razón para descartar sigue siendo válida.

De todos los hallazgos de la revisión, el que más incomoda a Marta es este: nadie ha declarado nunca cuánto puede estar caída la tienda ni cuántos datos se pueden perder. Sin esas dos cifras no se puede diseñar la recuperación, porque no hay forma de saber si lo que se tiene es suficiente.

Las dos definiciones, que se confunden constantemente:

• RTO (Recovery Time Objective): cuánto tiempo puede estar el servicio caído antes de que el daño sea inaceptable. Se mide desde que empieza la interrupción hasta que el servicio vuelve a funcionar. Es una decisión del negocio, no de tecnología.
• RPO (Recovery Point Objective): cuántos datos se pueden perder, medidos en tiempo. Un RPO de 15 minutos significa que, tras el desastre, se acepta haber perdido como máximo los últimos 15 minutos de transacciones.

Dicho de otro modo: el RPO mira hacia atrás (qué perdí) y el RTO mira hacia delante (cuánto tardo en volver). Y ambos cuestan dinero de forma creciente y no lineal: bajar el RTO de 8 horas a 4 es barato; bajarlo de 30 minutos a 1 minuto es carísimo.

Las cuatro estrategias canónicas, de menos a más coste:

Aplicado a la factura mensual consolidada de MercadoFresco, que es de 2.237,60 USD (la desglosaremos en 11-03), el coste de cada opción es:

Nótese que estos números son de la región secundaria, y que a todos hay que sumarles el coste que nunca aparece en la tabla: el trabajo de mantener esa segunda región coherente con la primera. Una espera templada que lleva cuatro meses sin actualizarse no es una espera templada, es una falsa sensación de seguridad.

Marta lleva la conversación al gerente con dos preguntas concretas, no con una tabla de servicios:

1. «Si la región de Irlanda entera se cae —cosa que ocurre muy rara vez pero ocurre—, ¿cuántas horas puede estar la tienda cerrada antes de que el daño sea grave?»
2. «¿Cuántos minutos de pedidos podemos permitirnos perder?»

Las respuestas, después de discutirlas: 8 horas de RTO y 15 minutos de RPO para el sistema de pedidos. El razonamiento del gerente es defendible: MercadoFresco reparte producto fresco en 24 horas; una caída de 8 horas retrasa un día de reparto, molesta y cuesta, pero no cierra la empresa. Perder pedidos ya confirmados y cobrados, en cambio, sí es grave, porque implica cobrar sin servir.

Esas dos cifras eliminan solas dos de las cuatro estrategias:

• Activo-activo y espera templada están sobredimensionadas para un RTO de 8 horas. Pagar 780 o 2.200 USD al mes por bajar de 8 horas a 20 minutos no lo pide nadie.
• Copia y restauración encaja en el RTO (8-24 h está en el límite) pero falla en el RPO si las copias son diarias.

La decisión resultante es un híbrido razonado: copia y restauración reforzada.

Y aquí viene la parte que distingue un plan de un documento: el RPO real declarado es de 6 horas en caso de desastre regional, no de 15 minutos. Marta lo escribe así, con esas palabras, en el ADR-021, y lo lleva firmado. La opción de bajarlo a 15 minutos existe —replicación continua a la otra región— y cuesta unos 200 USD más al mes. Gerencia decide asumir el riesgo residual por ahora y revisarlo cuando abran fuera de España.

Tres compromisos adicionales que cierran el hallazgo:

1. Simulacro semestral de restauración completa en eu-west-3, con cronómetro y acta. Si el RTO medido supera las 8 horas, se replantea la estrategia.
2. Simulacro trimestral de fallo de AZ con AWS Fault Injection Service en preproducción, que es un riesgo mucho más probable que el regional.
3. La primera prueba se hace antes de diciembre, porque hacerla en campaña de Navidad sería temerario.

La Well-Architected Tool es un servicio gratuito de la consola que convierte el documento en un flujo de trabajo con estado. Los pasos:

1. Definir la carga de trabajo. Nombre, descripción, entorno (producción o preproducción), regiones, cuentas implicadas, sector y propietario. MercadoFresco define:

Comentario de las opciones que importan:

• --environment PRODUCTION cambia el peso de algunas recomendaciones: la herramienta es más exigente con una carga de producción.
• --account-ids incluye la cuenta de herramientas 555566667777 porque el pipeline forma parte de la carga de trabajo: no tiene sentido revisar la excelencia operativa ignorando quién despliega.
• --lenses aplica de entrada la lente base y la de serverless, porque MercadoFresco tiene Lambda y Fargate en el camino crítico.
• --tags etiqueta la propia revisión, coherente con la convención del curso. Sí: hasta la revisión se etiqueta.

2. Responder el cuestionario. Por cada pregunta se marcan las buenas prácticas que realmente se cumplen y se puede añadir una nota. Hay dos trampas clásicas:

• Marcar por optimismo. «Sí, tenemos copias» no es lo mismo que «hemos restaurado una copia con éxito el mes pasado». Si no se ha probado, no está marcado.
• No usar las notas. La nota es donde se escribe «lo hacemos parcialmente: solo en producción». Sin ella, la revisión de dentro de seis meses no tiene contexto.

También existe la opción «esta pregunta no aplica», con su justificación. Usarla es legítimo: las preguntas sobre gestión de flota de instancias no aplican a una carga íntegramente sin servidor.

3. Obtener el plan de mejora. La herramienta calcula el riesgo por pregunta (alto, medio o ninguno) y genera una lista de elementos de mejora con enlaces a la documentación. La lista se puede exportar y —esto es lo importante— convertir en tareas del backlog con dueño y fecha. Un plan de mejora que vive dentro de la Well-Architected Tool y no en el tablero del equipo no se ejecuta jamás.

4. Crear un hito (milestone). Un hito congela el estado de las respuestas en una fecha:

Seis meses después, tras una nueva revisión, la herramienta muestra la comparación entre hitos: cuántos riesgos altos había, cuántos hay, cuáles se resolvieron y cuáles aparecieron nuevos. Esa comparación es el único indicador honesto de si el equipo está mejorando o solo corriendo.

5. Aplicar lentes. Una lente añade preguntas específicas de un dominio, y cambia el listón. Las más útiles:

Un consejo sobre lentes: no aplicar más de dos. Cada lente añade decenas de preguntas y la revisión deja de terminarse. Es mejor una revisión completa con dos lentes que una revisión abandonada con seis.

6. Consultar los resultados por API, que es como se automatiza el seguimiento:

Qué hace este script, línea a línea:

• get_lens_review devuelve el estado de la revisión para una lente concreta; PillarReviewSummaries trae el recuento de riesgos por pilar, que es exactamente el resumen ejecutivo que pide gerencia.
• list_lens_review_improvements devuelve los elementos de mejora; se filtra por Risk == "HIGH" porque un plan con 60 puntos no se ejecuta y uno con 12 sí.
• El resultado se puede volcar a un fichero, abrir incidencias automáticamente o publicarse como métrica en CloudWatch para verlo evolucionar. MercadoFresco hace lo tercero: una métrica RiesgosAltosWA en el espacio MercadoFresco/Tienda, revisada en la reunión mensual.

Una revisión Well-Architected que se hace una vez es un informe. La que se repite es un proceso. La rutina que instaura Marta:

Dos reglas que evitan que el proceso muera:

1. Ningún elemento de mejora sin dueño ni fecha. «Habría que hacer pruebas de carga» no es una tarea; «Luis ejecuta una prueba de carga a 1.400 pedidos/hora en preproducción antes del 30 de octubre» sí lo es.
2. Máximo cinco mejoras en curso a la vez. Un plan de 40 acciones abiertas equivale a ninguna acción en curso.

La revisión Well-Architected es periódica, profunda y humana. No sirve para detectar que alguien abrió un grupo de seguridad al mundo el martes por la tarde. Para eso están las herramientas que ya conoces del módulo 5, y conviene ver cómo encajan las tres:

La relación correcta es de realimentación en las dos direcciones:

Un ejemplo concreto de MercadoFresco: la revisión descubre que no hay revisión periódica de permisos. La acción no es solo «revisar los permisos este trimestre», sino convertir el hallazgo en una comprobación continua: una regla de Config iam-user-unused-credentials-check y un informe mensual de IAM Access Analyzer. Así, el hallazgo no vuelve a aparecer en la revisión de dentro de seis meses.

La regla general: todo hallazgo que se pueda convertir en una comprobación automática, se convierte. La revisión humana debe reservarse para lo que ninguna herramienta puede evaluar: si el RTO es adecuado para el negocio, si el equipo sabe qué hacer a las 3 de la mañana, si la decisión de hace un año sigue siendo válida.

Sumando los seis pilares, la revisión inicial arroja este balance:

Catorce riesgos altos son demasiados para atacarlos a la vez, así que se priorizan cruzando impacto y esfuerzo:

Por qué el pilar de costes va primero, aunque fiabilidad tenga los mismos riesgos altos y suene más importante. Tres razones concretas:

1. Es el único pilar del que nadie tiene ni un dato. No se puede priorizar lo que no se mide, y las decisiones de fiabilidad que vienen después —¿pilot light o warm standby?— son decisiones de coste disfrazadas de decisiones técnicas.
2. Las acciones son de esfuerzo bajo y efecto inmediato. Activar etiquetas, borrar huérfanos y apagar entornos por la noche son horas de trabajo, no semanas, y liberan presupuesto.
3. El presupuesto liberado financia el resto del plan. El dinero que se deja de tirar en desarrollo por la noche es exactamente el que paga las copias entre regiones y las pruebas de carga.

Ese es el hilo de las cinco lecciones que quedan. 11-02 convierte la factura en algo legible mediante etiquetas y asignación. 11-03 la analiza con Cost Explorer y ejecuta las optimizaciones. 11-04 pone límites y avisos con Budgets. 11-05 compromete capacidad con Savings Plans y reservas. Y 11-06 cierra el curso con el proyecto integrador.

Error: tratar la revisión como un examen que hay que aprobar. El equipo marca buenas prácticas que no cumple del todo para que el informe salga verde. Consejo: el informe no lo lee nadie de fuera. Lo único que se pierde marcando de más es la oportunidad de encontrar el problema antes de que lo encuentre un viernes a las 19:00.

Error: revisar «toda la empresa» como una sola carga de trabajo. Sale un cuestionario imposible de responder porque la respuesta correcta es «depende del sistema». Consejo: una carga de trabajo es un conjunto de componentes que entregan valor de negocio juntos y comparten dueño. MercadoFresco tiene dos: la tienda y la analítica.

Error: convertir el plan de mejora en un documento y cerrarlo. Seis meses después, la nueva revisión encuentra exactamente los mismos hallazgos. Consejo: los elementos de mejora salen de la herramienta el mismo día y entran en el tablero del equipo con dueño y fecha, o no existen.

Error: confundir «tenemos copias» con «sabemos restaurar». Es el hallazgo más repetido del pilar de fiabilidad en todo el sector. Consejo: una copia no probada es una hipótesis. Restaura una vez, con cronómetro y en un entorno limpio, y anota el tiempo real: casi siempre triplica al estimado.

Error: fijar el RTO y el RPO desde tecnología. El equipo técnico decide «pongamos 15 minutos» sin preguntar a nadie, y luego diseña una arquitectura que cuesta tres veces más de lo necesario. Consejo: RTO y RPO los declara el negocio respondiendo dos preguntas en lenguaje llano, y se escriben en un ADR firmado.

Error: comprar la estrategia de recuperación más cara «por si acaso». Un activo-activo sin necesidad duplica la factura y, peor, duplica el trabajo de mantenimiento; suele acabar desincronizado y dando una falsa seguridad. Consejo: empieza por la estrategia que cumple el RTO y el RPO declarados, y súbela cuando el negocio suba las exigencias, no antes.

Error: aplicar seis lentes a la vez. La revisión pasa de 60 preguntas a 300 y se abandona en la segunda sesión. Consejo: la lente base más una o dos específicas. Se pueden añadir más en la revisión siguiente.

Consejo: usa las notas de cada pregunta como memoria. «Cumplido solo en producción, pendiente en preproducción, ver ADR-018» convierte la siguiente revisión en media hora de trabajo en lugar de dos horas de arqueología.

Consejo: mide el proceso, no solo la arquitectura. El indicador útil no es «tenemos 14 riesgos altos», sino «teníamos 14 y ahora tenemos 6». Los hitos existen exactamente para eso.

Consejo: acepta riesgos por escrito y con fecha de caducidad. «Aceptamos un RPO regional de 6 h hasta la apertura en Portugal, revisión en marzo» es una decisión profesional. «Ya lo miraremos» no lo es.

Una empresa ficticia, LibreríaAtlas, vende libros en línea con una arquitectura mucho más sencilla que la de MercadoFresco: dos instancias EC2 detrás de un ALB, una RDS MySQL de una sola AZ, S3 para las portadas, sin CDN, despliegues por SSH y copias diarias automáticas de RDS con 7 días de retención. Nunca han restaurado una copia. No tienen etiquetas. El equipo son dos personas.

1. Escribe cinco hallazgos del pilar de fiabilidad con su riesgo (alto o medio).
2. Indica cuál atacarías primero y por qué, sabiendo que el presupuesto es limitado.
3. Propón un RTO y un RPO razonables y di qué estrategia de recuperación encajaría.

MercadoFresco se plantea añadir inspección del cuerpo de las peticiones en el WAF del ALB para detectar intentos de inyección en el formulario de pedido. Medido en preproducción: añade entre 4 y 9 ms de latencia por petición y unos 12 USD al mes. La tienda tiene un objetivo de TiempoConfirmacionPedido p99 por debajo de 900 ms y actualmente está en 840 ms.

1. Identifica qué pilares suben y cuáles bajan.
2. Escribe el ADR completo con contexto, decisión, consecuencias y alternativas descartadas.
3. Indica qué métrica vigilarías después de aplicarlo y qué haría que revirtieras la decisión.

El gerente de MercadoFresco cambia de opinión: tras leer una noticia sobre una caída regional de un competidor, pide RTO de 1 hora y RPO de 10 minutos.

1. ¿Qué estrategias de la tabla siguen siendo válidas con esos objetivos?
2. Calcula el impacto sobre la factura mensual de 2.237,60 USD de la opción más barata que los cumpla, en valor absoluto y en porcentaje.
3. Prepara tres preguntas que le harías al gerente antes de aprobar el gasto.

Solución al ejercicio 1

(1) Cinco hallazgos de fiabilidad en LibreríaAtlas:

(2) Qué atacar primero: la restauración probada. No es la respuesta intuitiva —la intuición dice «Multi-AZ»— pero es la correcta con presupuesto limitado por tres razones: cuesta cero euros (solo tiempo), valida o invalida toda la estrategia de copias de golpe, y si resulta que las copias no sirven, cambia por completo la prioridad de todo lo demás. Multi-AZ es el segundo, y ya cuesta dinero: aproximadamente duplica el coste de la instancia RDS.

(3) RTO y RPO razonables. Una librería en línea no es un servicio crítico de vida: RTO de 4 horas y RPO de 24 horas son perfectamente defendibles si el negocio los acepta —con copias diarias, el RPO real ya es de 24 h—. Con esos objetivos, la estrategia adecuada es copia y restauración, reforzada con dos cosas baratas: replicar las instantáneas a otra región y tener la infraestructura descrita en CloudFormation para poder reconstruirla sin depender de la memoria de nadie. Si el negocio exigiera RPO de 1 hora, la respuesta no sería cambiar de estrategia sino activar copias más frecuentes o pasar a un motor con recuperación a un punto en el tiempo.

Solución al ejercicio 2

(1) Pilares afectados:

• Sube seguridad: protección adicional contra inyección en el punto exacto donde entran datos de usuario, en una capa distinta de la validación de la aplicación (defensa en profundidad).
• Baja eficiencia del rendimiento: entre 4 y 9 ms por petición. Con el p99 en 840 ms y el objetivo en 900, el margen restante pasa de 60 ms a unos 51 ms en el peor caso. Sigue cumpliendo, pero con menos holgura.
• Baja optimización de costes: 12 USD al mes, un 0,5 % de la factura. Marginal.
• Neutro para fiabilidad, con un matiz: una regla WAF mal ajustada que bloquee peticiones legítimas sí afecta a la fiabilidad percibida. Es el riesgo real de esta decisión, no la latencia.

(2) ADR:

(3) Qué vigilar y qué revertiría la decisión. Se vigilan tres cosas: el p99 de TiempoConfirmacionPedido en el panel mercadofresco-produccion, la tasa de peticiones bloqueadas por el WAF, y el número de pedidos confirmados por hora comparado con la semana anterior. La decisión se revierte si el p99 supera los 900 ms de forma sostenida, o si PedidosConfirmados cae de forma inexplicable, que sería la señal de falsos positivos bloqueando compras reales. La reversión es barata: volver la regla a modo conteo es un cambio de un campo.

Solución al ejercicio 3

(1) Estrategias válidas con RTO 1 h y RPO 10 min:

• Copia y restauración: no cumple. RTO típico de 8-24 h y, con copias entre regiones cada 6 h, un RPO de 6 h.
• Luz piloto: cumple justo. RTO de 1-4 h —hay que trabajar para quedarse en la banda baja— y RPO de 5-15 min con réplica continua de Aurora hacia la otra región.
• Espera templada: cumple con holgura (RTO 10-30 min).
• Activo-activo: cumple sobradamente y es innecesario para estos objetivos.

La respuesta honesta es que luz piloto cumple el RPO con seguridad y el RTO solo si se ensaya. Un RTO de 1 hora con luz piloto exige automatización total del arranque: nada de reconstruir a mano. Es la opción a proponer, con la condición explícita de un simulacro que lo demuestre.

(2) Impacto en la factura:

Y hay un coste que no está en esa cifra y conviene poner encima de la mesa: el trabajo recurrente. Mantener la segunda región alineada, ejecutar el simulacro semestral y arreglar lo que el simulacro rompa son del orden de 6 a 10 días de trabajo al año, que a coste interno superan al coste de infraestructura.

(3) Tres preguntas para el gerente:

1. «¿De dónde sale el requisito?» Si viene de una noticia sobre un competidor, quizá el riesgo real que preocupa no sea el regional —que es raro— sino uno mucho más probable: un despliegue malo, un borrado accidental o un ataque. Esos se mitigan con reversión automática, borrado con retención y WAF, que ya existen y cuestan mucho menos.
2. «¿Cuánto factura MercadoFresco en 8 horas?» Es el número que convierte la conversación en una decisión de inversión. Si son 4.000 USD y la probabilidad de una caída regional es de una vez cada varios años, gastar 3.222 USD anuales tiene que discutirse con esos dos números delante.
3. «¿Asumimos también el compromiso de ensayarlo dos veces al año?» Sin esa condición, la respuesta correcta es no montarlo: una luz piloto no probada da la misma disponibilidad que no tener nada, pero con factura.

MercadoFresco ya no tiene solo una arquitectura: tiene una auditoría de esa arquitectura, hecha con método y no con intuición.

Sabes qué es el Well-Architected Framework y, sobre todo, qué no es: no es una certificación, ni una lista de compras de servicios, ni una auditoría de cumplimiento. Es una colección de preguntas con la forma «¿cómo hace usted X?», agrupadas en seis pilares —excelencia operativa, seguridad, fiabilidad, eficiencia del rendimiento, optimización de costes y sostenibilidad—, cada una con buenas prácticas que se marcan solo cuando de verdad se cumplen. Y sabes que la unidad de la revisión es la carga de trabajo, no la empresa.

Tienes la revisión completa de MercadoFresco pilar por pilar, con 14 riesgos altos y 12 medios, y con un patrón que se repite en casi todos los equipos técnicos buenos: una observabilidad excelente junto a una operación sin runbooks, una arquitectura elástica que nunca se ha probado bajo carga, unas copias que nunca se han restaurado y un pilar de costes del que literalmente nadie tiene un dato. Con los hallazgos escritos como hallazgos —«no hay RTO declarado», «nunca se ha simulado el fallo de una AZ», «la cuenta de desarrollo no tiene límite de gasto», «nadie ha revisado los permisos desde que se crearon»— y con su riesgo y su acción al lado.

Tienes los compromisos entre pilares cuantificados en lugar de intuidos: Multi-AZ triplica el cómputo de Aurora, el WAF con inspección de cuerpo añade de 4 a 9 ms, Spot cambia coste por interrupciones, los endpoints de VPC compran seguridad y salen más caros que el NAT. Y la herramienta para que ese razonamiento sobreviva al paso del tiempo: el registro de decisiones de arquitectura, un fichero por decisión, versionado, que no se edita y que incluye siempre las alternativas descartadas y por qué.

Tienes RTO y RPO entendidos de verdad —uno mira hacia delante, el otro hacia atrás— y las cuatro estrategias de recuperación con su coste real sobre la factura: copia y restauración (+2-4 %), luz piloto (+10-15 %), espera templada (+30-40 %) y activo-activo (+90-110 %). Y la decisión de MercadoFresco, tomada por el negocio y no por el equipo técnico: RTO de 8 horas y RPO de 15 minutos, resueltos con copia y restauración reforzada, con el riesgo residual escrito sin adornos —el RPO regional real es de 6 horas— y con dos simulacros comprometidos en el calendario.

Y tienes la rutina: quién convoca, quién participa —incluido negocio, porque RTO, RPO y presupuesto no son decisiones técnicas—, cada cuánto, cuánto dura y qué sale de ella; los hitos para comparar la revisión de hoy con la de dentro de seis meses, que es el único indicador honesto de mejora; las lentes especializadas con el consejo de no aplicar más de dos; y el reparto de papeles entre la revisión semestral humana, las comprobaciones continuas de Config y los avisos de Trusted Advisor, con la regla que los une: todo hallazgo que se pueda convertir en comprobación automática, se convierte.

El resultado es un plan de mejora priorizado de diez acciones con dueño y fecha. Y su primer punto no es el más vistoso ni el más urgente en apariencia: es el pilar de optimización de costes, porque es el único del que no hay ni un dato, porque sus acciones son de esfuerzo bajo y efecto inmediato, y porque el presupuesto que libera es exactamente el que financia las pruebas de carga y las copias entre regiones del resto del plan.

Así que la pregunta del gerente sigue sobre la mesa, ahora con un método detrás para responderla. ¿Cuánto cuesta todo esto y está bien gastado? El problema es que hoy la respuesta sería una cifra única de una factura de una sola línea, y con eso no se puede decidir nada: no se sabe cuánto es producción y cuánto desarrollo, ni cuánto cuesta el catálogo frente a los pedidos, ni cuánto de esa cifra corresponde a Madrid y cuánto a Sevilla, ni qué parte se puede recortar sin que nadie lo note.

En 11-02, «Etiquetado y asignación de costes», se resuelve ese problema primero: las cinco etiquetas obligatorias del curso dejan de ser una convención escrita en un documento para convertirse en dimensiones activadas, impuestas por política y auditadas, capaces de responder por fin quién gasta qué. Sin ese paso, todo lo que viene después —analizar, presupuestar y comprometer— se hace a ciegas.