Comenzamos la Parte VII: Arquitecturas de referencia y patrones expertos, donde damos el salto de «saber usar servicios» a «diseñar sistemas bien construidos». Y empezamos por el marco que AWS ofrece precisamente para eso: el Well-Architected Framework (Marco de Buena Arquitectura). Es un conjunto de buenas prácticas destiladas de miles de arquitecturas reales, organizadas en seis pilares. En este subcapítulo vemos qué son esos seis pilares: las seis dimensiones que debes equilibrar para construir un buen sistema en la nube.

Ya conoces muchos servicios de AWS. Pero saber qué piezas existen no es lo mismo que saber combinarlas bien. ¿Cómo sabes si tu diseño es «bueno»? ¿Es seguro? ¿Aguantará fallos? ¿Es eficiente en coste? Sin un marco de referencia, es fácil olvidar dimensiones importantes y construir algo que funciona... hasta que falla, o se vuelve carísimo, o resulta inseguro.

AWS recopiló la experiencia de revisar miles de arquitecturas de clientes y la condensó en el Well-Architected Framework: una guía de buenas prácticas para que cualquiera pueda evaluar y mejorar sus diseños.

El Well-Architected Framework es un conjunto de principios y buenas prácticas de AWS para diseñar sistemas bien construidos en la nube. No es una herramienta ni un servicio: es un marco de pensamiento, organizado en seis pilares, que cubren todas las dimensiones que importan en una buena arquitectura.

Analogía: el Well-Architected Framework es como las normas de construcción de un edificio que un buen arquitecto debe respetar. No basta con que el edificio «se tenga en pie»: debe ser seguro (no se derrumba), habitable (funciona bien para vivir), eficiente (no derrocha energía), sólido (aguanta terremotos), etc. Los seis pilares son esas dimensiones de calidad que todo buen «edificio digital» debe cumplir. Reconoces que muchos de estos temas ya los hemos tratado en el libro; el framework los organiza en un todo coherente.

Trata de operar y mejorar el sistema de forma eficaz: automatizar tareas, monitorizar todo, responder bien a incidentes y aprender de los errores para mejorar continuamente.

• Pregunta clave: «¿Operamos nuestro sistema de forma eficiente y mejoramos constantemente?»
• Relación con el libro: la infraestructura como código (Parte II), CI/CD (Capítulo 22) y la observabilidad (Capítulo 24) son la base de este pilar.

Trata de proteger los datos, los sistemas y los accesos: controlar quién puede hacer qué, cifrar la información, detectar amenazas y cumplir las normativas.

• Pregunta clave: «¿Están protegidos nuestros datos y sistemas frente a accesos indebidos y ataques?»
• Relación con el libro: IAM (Capítulo 7), redes (Capítulo 6) y toda la seguridad en profundidad (Capítulo 23).

Trata de que el sistema funcione correctamente y se recupere de los fallos: soportar caídas, escalar ante la demanda y recuperarse de desastres.

• Pregunta clave: «¿Sigue funcionando nuestro sistema cuando algo falla?»
• Relación con el libro: balanceo y autoescalado (Capítulo 13), alta disponibilidad y disaster recovery (Capítulo 26).

Trata de usar los recursos de forma eficiente para cumplir los requisitos: elegir los servicios y tamaños adecuados, y adaptarse a medida que cambian las necesidades.

• Pregunta clave: «¿Usamos los recursos adecuados y rinden bien según evolucionan las necesidades?»
• Relación con el libro: elegir el cómputo adecuado (Lambda, contenedores, EC2), rightsizing (Capítulo 25), cachés y CDN (Capítulo 16).

Trata de obtener el máximo valor al menor coste: evitar el gasto innecesario, dimensionar bien y aprovechar los modelos de precio ventajosos.

• Pregunta clave: «¿Estamos obteniendo el máximo valor por lo que gastamos?»
• Relación con el libro: todo el Capítulo 25 (Cost Explorer, rightsizing, Savings Plans, FinOps).

El más reciente. Trata de minimizar el impacto medioambiental de tu infraestructura: usar los recursos de forma eficiente para reducir el consumo de energía y la huella de carbono.

• Pregunta clave: «¿Es nuestro sistema eficiente y respetuoso con el medioambiente?»
• Relación con el libro: usar recursos eficientemente (serverless, rightsizing, apagar lo que no se usa) también reduce el impacto ambiental. Eficiencia y sostenibilidad van de la mano.

Lo más importante: los seis pilares hay que equilibrarlos, porque a veces compiten entre sí. Mejorar uno puede afectar a otro, y el arte de la buena arquitectura está en encontrar el equilibrio adecuado para tu caso:

No existe una arquitectura «perfecta» en abstracto: existe la adecuada para tus necesidades y prioridades. Una startup quizá priorice coste y agilidad; un banco priorizará seguridad y fiabilidad por encima del coste. El framework no te dice qué priorizar, sino que te obliga a pensar en las seis dimensiones y a decidir conscientemente el equilibrio.

Ejemplo del mundo real: un equipo va a diseñar una nueva aplicación. En lugar de lanzarse a montar servicios, repasan los seis pilares como una lista de comprobación: ¿cómo la operaremos y monitorizaremos (excelencia operativa)?, ¿cómo protegemos los datos (seguridad)?, ¿qué pasa si una región cae (fiabilidad)?, ¿qué cómputo es el más eficiente (rendimiento)?, ¿cómo evitamos gastar de más (coste)?, ¿podemos usar recursos eficientes (sostenibilidad)? Este simple repaso les hace descubrir huecos que habrían pasado por alto, como que no tenían plan de recuperación ante desastres. Pensar en los seis pilares antes de construir les ahorra problemas graves después.

• El Well-Architected Framework es un conjunto de buenas prácticas de AWS (destiladas de miles de arquitecturas reales) para diseñar sistemas bien construidos, organizado en seis pilares. Es un marco de pensamiento, no una herramienta.
• Los seis pilares: Excelencia operativa (operar y mejorar), Seguridad (proteger), Fiabilidad (resistir fallos), Eficiencia del rendimiento (recursos adecuados), Optimización de costes (máximo valor) y Sostenibilidad (impacto ambiental).
• Cada pilar conecta con temas ya vistos en el libro; el framework los organiza en un todo coherente. Son como las normas de construcción de un buen edificio.
• Lo esencial es equilibrar los pilares, porque a veces compiten (más fiabilidad ↔ más coste, etc.). No hay arquitectura «perfecta», sino la adecuada a tus prioridades.
• El framework te obliga a pensar en las seis dimensiones conscientemente, ayudándote a descubrir huecos antes de construir.

En el siguiente subcapítulo veremos la herramienta que AWS ofrece para evaluar tus arquitecturas contra estos pilares de forma sistemática: la Well-Architected Tool.