

# AWS Well-Architected Framework
<a name="welcome"></a>

Fecha de publicación: **10 de abril de 2023** ([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. El uso del marco le permitirá conocer las prácticas recomendadas de arquitectura para diseñar y operar sistemas en la nube que sean fiables, seguros, eficaces, rentables y sostenibles.

## Introducción
<a name="introduction"></a>

 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 la Nube de AWS que sean seguras, fiables, eficaces, rentables y sostenibles. Proporciona una forma de medir sus arquitecturas de forma constante en función de las prácticas recomendadas y de 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 cuenta con años de experiencia en soluciones de diseño de arquitecturas para una amplia variedad de sectores empresariales 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 que 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. [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 las prácticas recomendadas, hemos creado [Laboratorios de AWS Well-Architected](https://www.wellarchitectedlabs.com/?ref=wellarchitected-wp), que le proporcionan un repositorio de código y documentación para ofrecerle experiencia práctica en la implementación de las prácticas recomendadas. También nos hemos unido a determinados socios de la red de socios de AWS (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 exhaustivos conocimientos sobre AWS y pueden ayudarle a revisar y mejorar sus cargas de trabajo. 

# Definiciones
<a name="definitions"></a>

 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 preguntas que puede utilizar para evaluar en qué medida una arquitectura está 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 completo**  |  **Descripción**  | 
| --- | --- | 
|  Excelencia operativa  |  The ability to support development and run workloads effectively, gain insight into their operations, and to continuously improve supporting processes and procedures to deliver business value.  | 
|  Seguridad  | The security pillar describes how to take advantage of cloud technologies to protect data, systems, and assets in a way that can improve your security posture. | 
|  Fiabilidad  |  The reliability pillar encompasses the ability of a workload to perform its intended function correctly and consistently when it’s expected to. This includes the ability to operate and test the workload through its total lifecycle. This paper provides in-depth, best practice guidance for implementing reliable workloads on AWS.  | 
|  Eficiencia del rendimiento  |  The ability to use computing resources efficiently to meet system requirements, and to maintain that efficiency as demand changes and technologies evolve.  | 
|  Optimización de costes  |  The ability to run systems to deliver business value at the lowest price point.  | 
|  Sostenibilidad  |  The ability to continually improve sustainability impacts by reducing energy consumption and increasing efficiency across all components of a workload by maximizing the benefits from the provisioned resources and minimizing the total resources required.  | 

 En AWS Well-Architected Framework, usamos estos términos: 
+  Un **componente** es el código, la configuración y los recursos de AWS que conjuntamente cumplen con un requisito. Un componente suele ser la unidad de propiedad técnica y está desacoplado de otros componentes. 
+  El término **carga de trabajo** se utiliza para identificar un conjunto de componentes que proporciona valor empresarial. Una carga de trabajo suele ser el nivel de detalle sobre el que hablan los líderes tecnológicos y comerciales. 
+  Percibimos la **arquitectura** como la forma en que los componentes trabajan juntos 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). 
+  En una organización, la **cartera tecnológica** es el conjunto de cargas de trabajo necesarias para que opere la empresa. 
+ El **nivel de esfuerzo** mide el tiempo, el esfuerzo y la 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 como contexto adicional a fin de determinar correctamente el nivel de esfuerzo de la organización.
  + **Alto:** el trabajo podría durar varias semanas o meses. Esto podría desglosarse en múltiples historias, versiones y tareas. 
  + **Medio:** el trabajo podría durar varios días o semanas. Esto podría desglosarse en múltiples versiones y tareas.
  + **Bajo:** el trabajo podría durar varias horas o días. Esto podría desglosarse en múltiples tareas.

 Al diseñar cargas de trabajo, se hacen concesiones entre pilares según el contexto empresarial. 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 fundamentales, 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
<a name="on-architecture"></a>

 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 utilizan [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. Primero, tenemos las *prácticas* (formas de hacer 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 en todos los roles que *funciona a partir* 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 subir el listón, 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 equipos de arquitectura de soluciones y de ingeniería interna. 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, formación 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
<a name="general-design-principles"></a>

 El Well-Architected Framework 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, 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 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. 
+  **Dé 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 empresariales cambiantes. 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 sus elecciones de arquitectura afectan 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. 
+  **Mejore mediante días de juego:** pruebe cómo funcionan su arquitectura y sus procesos mediante la programación periódica de 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. 