# AWS Well-Architected Framework
Fecha de publicación: **20 de octubre de 2022** ([Revisiones del documento](document-revisions.md))
AWS Well-Architected Framework le ayuda a comprender las ventajas y desventajas de las decisiones que toma al crear sistemas en AWS. Mediante el uso del marco, conocerá las prácticas recomendadas de arquitectura para diseñar y operar sistemas en la nube que sean seguros, eficaces, rentables y de confianza.
## Introducción
AWS Well-Architected Framework le ayuda a comprender las ventajas y desventajas de las decisiones que toma al crear sistemas en AWS. Mediante el uso del marco, podrá conocer las prácticas recomendadas de arquitectura para diseñar y operar cargas de trabajo en Nube de AWS que sean seguras, eficaces, rentables y de confianza. Proporciona una forma de medir sus arquitecturas de forma constante en función de las prácticas recomendadas e identificar áreas que se puedan mejorar. El proceso para revisar una arquitectura representa una conversación constructiva sobre decisiones arquitectónicas y no se trata de un mecanismo de auditoría. Creemos que contar con sistemas de buena arquitectura aumenta en gran medida la probabilidad de éxito empresarial.
AWS Solutions Architects goza de años de experiencia en soluciones de diseño de arquitecturas para una amplia variedad de sectores de negocios y casos de uso. Hemos ayudado a diseñar y revisar miles de arquitecturas de clientes en AWS. A partir de dicha experiencia, hemos identificado las prácticas recomendadas y estrategias centrales para sistemas de diseño de arquitecturas en la nube.
AWS Well-Architected Framework documenta un conjunto de cuestiones fundamentales que le permiten comprender si una arquitectura específica se corresponde con las prácticas recomendadas de la nube. El marco proporciona un enfoque coherente para evaluar los sistemas frente a las cualidades que espera de los sistemas modernos basados en la nube y la solución necesaria para lograr dichas cualidades. A medida que AWS continúa evolucionando y seguimos aprendiendo más al trabajar con nuestros clientes, continuaremos perfeccionando la definición de una buena arquitectura.
Este marco está destinado a aquellos que ocupan puestos en tecnología, como los directores de tecnología (CTO), arquitectos, desarrolladores y miembros del equipo de operaciones. Describe las prácticas recomendadas y las estrategias de AWS para diseñar y operar una carga de trabajo en la nube y proporciona enlaces a más detalles sobre implementación y patrones arquitectónicos. Para obtener más información, consulte [la página de inicio de AWS Well-Architected](https://aws.amazon.com/architecture/well-architected/?ref=wellarchitected-wp).
AWS también proporciona un servicio para revisar sus cargas de trabajo de forma gratuita. La [herramienta AWS Well-Architected Tool](https://aws.amazon.com/well-architected-tool/?ref=wellarchitected-wp) (AWS WA Tool) es un servicio en la nube que proporciona un proceso coherente para que revise y mida su arquitectura con AWS Well-Architected Framework. AWS WA Tool proporciona recomendaciones para lograr que sus cargas de trabajo sean más fiables, seguras, eficientes y rentables.
Para ayudarle a aplicar la prácticas recomendadas, hemos creado los [laboratorios de AWS Well-Architected](https://www.wellarchitectedlabs.com/?ref=wellarchitected-wp), que le proporciona un repositorio de código y documentación para brindarle experiencia práctica en la implementación de las prácticas recomendadas. También nos hemos unido a socios selectos de la AWS Partner Network (APN), que son miembros del [programa de socios de AWS Well-Architected](https://aws.amazon.com/architecture/well-architected/partners/?ref=wellarchitected-wp). Estos socios de AWS tienen grandes conocimientos sobre AWS y pueden ayudarle a revisar y mejorar sus cargas de trabajo.
# Definiciones
Cada día, los expertos de AWS ayudan a los clientes con la arquitectura de sistemas para aprovechar las prácticas recomendadas en la nube. Trabajamos con usted para lograr compensaciones arquitectónicas a medida que sus diseños evolucionan. A medida que implementa estos sistemas en entornos en directo, descubrimos el excelente rendimiento de dichos sistemas y las consecuencias de dichas compensaciones.
Con lo aprendido, hemos creado AWS Well-Architected Framework, que proporciona un conjunto coherente de prácticas recomendadas para que clientes y socios evalúen arquitecturas y un conjunto de cuestiones que puede utilizar para evaluar en qué medida está una arquitectura alineada con las prácticas recomendadas de AWS.
AWS Well-Architected Framework se basa en seis pilares: excelencia operativa, seguridad, fiabilidad, eficiencia del rendimiento, optimización de costes y sostenibilidad.
**Tabla 1. Los pilares de AWS Well-Architected Framework**
| **Nombre** | **Descripción** |
| --- | --- |
| Excelencia operativa | Capacidad de apoyar el desarrollo y ejecutar cargas de trabajo eficazmente, conocer sus operaciones y mejorar continuamente los procesos y procedimientos de soporte para ofrecer valor empresarial. |
| Seguridad | El pilar de seguridad describe cómo sacar partido de las tecnologías de la nube para proteger datos, sistemas y recursos de una forma que pueda mejorar su nivel de seguridad. |
| Fiabilidad | El pilar de fiabilidad abarca la capacidad de una carga de trabajo para realizar su función prevista de forma correcta y coherente cuando se espera que lo haga. Esto incluye la capacidad de utilizar y probar la carga de trabajo a lo largo de todo su ciclo de vida. En este documento se incluyen consejos exhaustivos y de prácticas recomendadas para la implementación de cargas de trabajo fiables en AWS. |
| Eficiencia del rendimiento | Es la capacidad de utilizar de forma eficaz los recursos informáticos para satisfacer los requisitos del sistema, así como el mantenimiento de la eficiencia a medida que la demanda cambia y las tecnologías evolucionan. |
| Optimización de costes | Es la capacidad de ejecutar sistemas para ofrecer valor de negocio al menor precio posible. |
| Sostenibilidad | Es la capacidad de mejorar constantemente las repercusiones en la sostenibilidad reduciendo el consumo de energía, así como mejorar la eficiencia en todos los componentes de una carga de trabajo maximizando los beneficios de los recursos aprovisionados y minimizando el número total de recursos necesarios. |
En AWS Well-Architected Framework, usamos estos términos:
+ A **componente** es el código, la configuración y los recursos de AWS que cumplen con un requisito de carga de trabajo. Un componente suele ser la unidad de responsabilidad técnica y está desvinculado de otros componentes.
+ El término **carga de trabajo** define un conjunto de componentes que, en conjunto, proporciona valor de negocio. Una carga de trabajo suele ser el nivel de detalle sobre el que hablan los líderes tecnológicos y comerciales.
+ Pensamos en la **arquitectura** como la forma en que trabajan conjuntamente los componentes en una carga de trabajo. La forma en la que interactúan y se comunican los componentes es, a menudo, el foco de los diagramas de arquitectura.
+ **Los hitos** marcan los cambios clave en su arquitectura a medida que evoluciona a lo largo del ciclo de vida del producto (diseño, implementación, prueba, lanzamiento y producción).
+ Dentro de una organización, la **cartera tecnológica** es el conjunto de cargas de trabajo necesarias para que opere la empresa.
+ La **nivel de esfuerzo** mide la cantidad de tiempo, esfuerzo y complejidad que requiere la implementación de una tarea. Cada organización tiene que considerar el tamaño y la experiencia del equipo y la complejidad de la carga de trabajo para obtener contexto adicional para determinar correctamente el nivel de esfuerzo de la organización.
+ **Alto:** el trabajo podría llevar varias semanas o meses, lo que podría desglosarse en múltiples historias, versiones y tareas.
+ **Medio:** el trabajo podría llevar varios días o semanas, lo que podría desglosarse en múltiples versiones y tareas.
+ **Bajo:** el trabajo podría llevar varias horas o días, lo que podría desglosarse en múltiples tareas.
Al diseñar cargas de trabajo, se hacen concesiones entre pilares según el contexto del negocio. Estas decisiones de negocios pueden impulsar sus prioridades de ingeniería. Podría optimizarlas para mejorar el impacto en la sostenibilidad y reducir los costes en detrimento de la fiabilidad en los entornos de desarrollo o, si se trata de soluciones cruciales para el negocio, podría optimizar la fiabilidad con incremento de costes e impacto en la sostenibilidad. En las soluciones de comercio electrónico, el rendimiento puede afectar a los ingresos y a la tendencia de los clientes a comprar. La seguridad y la excelencia operativa generalmente no se negocian contra los otros pilares.
# Sobre la arquitectura
En entornos locales, los clientes suelen contar con un equipo central dedicado a la arquitectura tecnológica que está por encima de otros equipos de productos o características para garantizar que sigan las prácticas recomendadas. En los equipos de arquitectura tecnológica suelen haber distintos roles como el de arquitecto técnico (infraestructura), arquitecto de soluciones (software), arquitecto de datos, arquitecto de redes y arquitecto de seguridad. A menudo, estos equipos usan [TOGAF](http://pubs.opengroup.org/architecture/togaf9-doc/arch/?ref=wellarchitected-wp) o [Zachman Framework](https://www.zachman.com/about-the-zachman-framework?ref=wellarchitected-wp) como parte de una capacidad de arquitectura empresarial.
En AWS, preferimos distribuir capacidades dentro de los equipos en lugar de tener un equipo centralizado con esa capacidad. Existen riesgos cuando elige distribuir la toma de decisiones, por ejemplo, para garantizar que los equipos cumplan con los estándares internos. Mitigamos estos riesgos de dos maneras. En primer lugar, tenemos *prácticas* (formas de hacer las cosas, procesos, estándares y normas aceptadas) que se centran en permitir que cada equipo tenga esa capacidad y contamos con expertos que se aseguran de que los equipos eleven el nivel de los estándares que deben cumplir. En segundo lugar, implementamos *mecanismos* que realizan comprobaciones automáticas para garantizar que se cumplan los estándares.
****
«Las buenas intenciones nunca funcionan; hacen falta buenos mecanismos para que todo suceda», Jeff Bezos.
Esto significa reemplazar los esfuerzos humanos por mecanismos (a menudo automáticos) que controlan el cumplimiento de las normas y los procesos. Este enfoque distribuido está respaldado por los [principios de liderazgo de Amazon](https://www.amazon.jobs/en/principles?ref=wellarchitected-wp)y establece una cultura entre todos los roles que *tiene en cuenta* las necesidades del cliente. Pensar en el cliente es esencial en nuestro proceso de innovación. Comenzamos con el cliente y lo que quiere, y dejamos que eso defina y guíe nuestros esfuerzos. Los equipos centrados en el cliente crean productos como respuesta a una necesidad del cliente.
Para la arquitectura, esto significa que esperamos que cada equipo tenga la capacidad de crear arquitecturas y seguir las prácticas recomendadas. Para ayudar a los nuevos equipos a obtener estas capacidades o a los equipos existentes a aumentar las exigencias, habilitamos el acceso a una comunidad virtual de ingenieros principales que pueden revisar sus diseños y ayudarlos a comprender cuáles son las prácticas recomendadas de AWS. La comunidad de ingenieros trabaja para que las prácticas recomendadas sean visibles y accesibles. Una forma de hacerlo es, por ejemplo, a través de charlas a la hora del almuerzo centradas en la aplicación de las prácticas recomendadas a casos reales. Estas charlas se graban y pueden utilizarse como parte de los materiales de incorporación para los nuevos miembros del equipo.
Las prácticas recomendadas de AWS surgen de nuestra experiencia con miles de sistemas a escala de internet. Preferimos usar datos para definir las prácticas recomendadas, pero también recurrimos a expertos en la materia, como ingenieros principales, para establecerlas. A medida que los ingenieros principales ven emerger nuevas prácticas recomendadas, trabajan como una comunidad para garantizar que los equipos las sigan. Con el tiempo, estas prácticas recomendadas se formalizan en nuestros procesos de revisión interna, así como en mecanismos para el cumplimiento. Well-Architected Framework representa la implementación orientada al cliente de nuestro proceso de revisión interna, donde hemos codificado la forma de pensar de nuestros ingenieros principales en roles de campo, como los de la Arquitectura de soluciones y de los equipos de ingeniería internos. Well-Architected Framework es un mecanismo escalable que le permite aprovechar estos aprendizajes.
Al seguir el enfoque de una comunidad de ingeniería con propiedad distribuida de la arquitectura, creemos que puede surgir una arquitectura empresarial Well-Architected impulsada por las necesidades del cliente. Los líderes tecnológicos (como CTO o directores de desarrollo) que realicen revisiones Well-Architected en todas sus cargas de trabajo le permitirán comprender mejor los riesgos en su cartera de tecnología. Con este enfoque, puede identificar temas en todos los equipos que su organización podría abordar mediante mecanismos, formaciones o charlas a la hora del almuerzo donde los ingenieros principales pueden compartir sus ideas sobre áreas específicas con múltiples equipos.
# Principios de diseño generales
El Marco de Buena Arquitectura identifica un conjunto de principios generales de diseño que facilitan un buen diseño en la nube:
+ **No conjeture más sobre la capacidad que necesita**: si opta por poca capacidad al implementar una carga de trabajo, puede terminar con recursos inactivos caros o lidiando con las implicaciones de rendimiento de una capacidad limitada. Con los servicios informáticos en la nube, estos problemas pueden desaparecer. Puede usar tanta capacidad como necesite y escalar automáticamente hacia arriba y hacia abajo.
+ **Ponga a prueba sistemas a escala de producción**: en la nube, puede crear un entorno de prueba a escala de producción bajo demanda, completar sus pruebas y retirar los recursos. Debido a que solo paga por el entorno de prueba cuando se ejecuta, puede simular su entorno en directo por una fracción del coste de las pruebas en las instalaciones.
+ **Automatice para facilitar la experimentación con la arquitectura**: la automatización le permite crear y replicar sus cargas de trabajo a bajo coste y evitar los gastos del esfuerzo manual. Puede rastrear cambios en su automatización, auditar su impacto y volver a los parámetros anteriores cuando sea necesario.
+ **De rienda suelta a las arquitecturas que permiten la evolución**: en un entorno tradicional, las decisiones arquitectónicas a menudo se implementan como eventos estáticos y solo se desarrollan algunas versiones principales de un sistema durante su vida útil. A medida que una empresa y su contexto evolucionan, estas decisiones iniciales pueden dificultar la capacidad del sistema para cumplir con los requisitos cambiantes de la empresa. En la nube, la capacidad de automatizar y probar bajo demanda reduce el riesgo de impacto de los cambios en el diseño. Esto permite que los sistemas evolucionen a lo largo del tiempo para que los proyectos puedan aprovechar las innovaciones como una práctica estándar.
+ **Impulse arquitecturas mediante el uso de datos**: en la nube, puede recopilar datos sobre cómo afectan sus decisiones arquitectónicas al comportamiento de su carga de trabajo. Esto le permite tomar decisiones basadas en hechos sobre cómo mejorar su carga de trabajo. Su infraestructura en la nube es código, por lo que pueden utilizar esos datos para notificar sus elecciones de arquitectura y mejoras a lo largo del tiempo.
+ **Mejora mediante días de juego**: pruebe cómo funcionan su arquitectura y sus procesos programando regularmente días de juego para simular eventos en producción. Esto ayudará a comprender dónde se pueden realizar mejoras y a desarrollar la experiencia organizacional en la gestión de eventos.