Introduction
Le cadre AWS Well-Architected Framework décrit les concepts clés, les principes de conception et les bonnes pratiques architecturales pour concevoir et exécuter des charges de travail dans le cloud. En répondant à quelques questions fondamentales, vous découvrez si votre architecture est en harmonie avec les bonnes pratiques cloud et vous recevez des conseils pour vous améliorer.
Voici les principales caractéristiques du cadre AWS Well-Architected :
Les six piliers : Le cadre Well-Architected repose sur six piliers fondamentaux pour l’architecture cloud, qui sont l’excellence opérationnelle, la sécurité, l’efficacité de performance, la fiabilité, l’optimisation des coûts et le développement durable. Chaque pilier représente un domaine essentiel à considérer lors de la conception de votre architecture cloud.
Ateliers AWS Well-Architected : AWS propose des ateliers où les clients peuvent collaborer avec des architectes AWS certifiés pour examiner leurs charges de travail en cours et les comparer aux meilleures pratiques du cadre Well-Architected. Au cours de ces ateliers, les participants peuvent discuter de leur architecture actuelle, identifier les éventuelles améliorations et recevoir des recommandations personnalisées pour optimiser leur environnement AWS.
Questionnaire Well-Architected : Le cadre Well-Architected est également basé sur un questionnaire détaillé qui permet aux clients d’évaluer eux-mêmes leurs charges de travail en fonction des six piliers. En répondant aux questions du questionnaire, les utilisateurs peuvent obtenir un aperçu initial de la qualité de leur architecture cloud et identifier les domaines potentiels d’amélioration.
Ressources et guides : AWS met à disposition de nombreuses ressources, études de cas, guides et documentation sur le cadre Well-Architected. Ces documents offrent des explications détaillées sur chaque pilier, des exemples d’architecture, ainsi que des conseils pour optimiser les performances, la sécurité et les coûts de vos solutions cloud.
Objectifs
- An overview of the AWS Well-Architected (AWS WA) Framework
- The components of the framework
- The pillars and general design principles of the framework
AWS Well-Architected Framework Overview
A brief history of the Well-Architected Framework
Before we dive deeper into the components of the framework, we will take a look at how it started and how it evolved over time. AWS Well-Architected started in 2012.
- In 2013, AWS solutions architects started reviewing customer workloads.
- In 2014, AWS standardized the questions across four pillars.
- In 2015, AWS published a formal framework based on the four pillars. We dive deeper into the pillars in a later module of this course.
- In 2016, we added the operational excellence pillar to the Well-Architected Framework. To scale to more customers, AWS trained select AWS Partners to review customer workloads in 2017. In 2018, the AWS Well-Architected Tool launched in the AWS console making it available to all customers.
- In 2019, AWS launched the AWS WellArchitected Tool and the Well-Architected Partner Program, in multiple Regions.
- In 2020, AWS updated the framework, added more lenses, and launched API access to the AWS Well-Architected Tool. In 2021, the framework added the sustainability pillar and additional lenses.
- In 2022, the AWS WellArchitected Tool launched in AWS GovCloud Regions and the integration with AWS Trusted Advisor.
- In 2023, Well-Architected continues to add more features, lenses and integrations with other AWS services.
Components of the Well-Architected Framework
The Well-Architected Framework is composed of content, tools, and data. The framework includes content that you can use to learn AWS guidelines, such as pillars, design principles, and best practices.
The framework also includes the AWS Well-Architected Tool that you can use to measure your workload and teams against these best practices.
Another component of the framework is the data that you acquire during the Well-Architected Framework Review of your workloads. You can use this data to continuously improve your workloads and operations.
In this module, you will dive deeper into content. You will learn more about the AWS Well-Architected Tool and the Well-Architected Framework Review in future modules.
Well-Architected Framework content
The Well-Architected Framework is a set of questions and design principles across six pillars. Alongside the pillars of the framework are the lenses, which provide guidance with a focus on specific industry or technology domains.
To evaluate the health of your workloads, you answer a set of foundational questions, based on the framework, pillars, and lenses. These questions will validate if a certain best practice is in place in the workload or not.
Pillars of AWS Well-Architected
There are currently six pillars in the Well-Architected Framework:
- operational excellence,
- security,
- reliability,
- performance efficiency,
- cost optimization,
- sustainability.
These pillars are the foundations of the architecture for your technology solutions in the cloud.
Well-Architected lenses
The Well-Architected lenses extend the guidance offered by AWS Well-Architected to specific industry and technology domains. Examples of these domains are machine learning, data analytics, serverless applications, high-performance computing, Internet of Things, SAP, streaming media, the gaming industry, hybrid networking, and financial services.
To fully evaluate workloads, you use applicable lenses together with the framework and its six pillars. You can also create user-defined and managed custom lenses to best align with your organization’s industry, operational plans, and internal processes. You can create your own question sets and add context and best practices as they relate to your own organization and processes. Not all of the available lenses are in the tool currently, but all lenses are available as part of the framework.
General design principles
General design principles are applied across all workloads and all pillars. There are also design principles that are specific to each pillar, which you will learn more about next.
Cloud computing has opened up the technology space to a whole new world of thinking where constraints we had in the traditional environment no longer exist. When thinking about general design principles, it’s interesting to contrast with how you would think about this in a traditional environment. You would have had to guess how much infrastructure you needed, often based on very high-level business requirements and demand and often before a line of code is written. You could not afford to test at scale because a complete duplicate of production costs is hard to justify, especially with low utilization. So, when you went into production you normally found a whole new class of issues at high scale.
Any proof of concepts or architectural experimentation was done manually and was usually only done at the start of the project. You had static architectures and it was difficult to even think about making a change. You generally couldn’t generate data sets that made it possible to make informed decisions, so you probably used models and assumptions to size your architecture. Finally, in a traditional environment, you would only exercise your runbook when something bad happened in production.
In the cloud, constraints have been removed. You can use these principles to take advantage of that.
Design principles
Each pillar of the framework has its own design principles as well. These are called pillar-specific design principles and they apply only to specific pillars of the framework.
As you learned earlier, one of the general design principles is to improve through game days. Game days is a term that means testing your architecture and processes by regularly simulating events in production. This will help you understand where you can make improvements and can help develop organizational experience in dealing with events.
An example for a security pillar design principle is to prepare for security events. Prepare for an incident by having incident management and investigation policy and processes that align to your organizational requirements. Run incident response simulations and use tools with automation to increase your speed for detection, investigation, and recovery.
Questions and best practices
The last two components of the framework are questions and best practices. You can use questions to validate whether a specific best practice is in place or not. Each pillar has a set of questions and best practices to address those questions. These are best practices, or answers, that customers have been successful with. The answers are not black and white. The answer for the question may be valid given your context of the workload. You will still need to apply your architectural judgement. For example one of the security pillar questions is: How do you protect your data at rest? The framework shows you the context of the question and some of the best practices to be implemented.
